Uses, Include and extends

uses, Include and extends

uses
The uses arrow (or uses edge as it would be called in traditional graph thoery) is drawn from a use case X to another use case Y to indicate that the process of doing X always involves doing Y at least once (although it may involve doing it many times, "at least once" is the only relationship guaranteed by this symbol.) This symbol can be referred to as an aggregation operator, because it indicates that a given use case is an aggregate (made up of parts) whose components are the use cases that it uses. If a certain use case uses several others, that means that all of the component use cases must be completed in the process of completing the aggregate use case, although there is no specification in UCDs of the order in which these are completed. A brief, mnemonic way to think about the uses arrow is that it it can be read X uses Y means that "X has a Y" as part of it's behavior.


Include and extends

The correct way to indicate a "include" or "extend" relationship is with a dashed line. Now the difference between the two is the following. Suppose A includes B. This means that whenever somebody does A she will do B too. On the other hand, if A extends B, than whenever somebody does A, B has nothing to do with it. But if you do B, you might do A additionally during the course of B. You should specify a condition under which A actually extends B.

In your case you could actually use both as long as you indicate in the condition of the extends version that this depends on the customer being new.

About your modeling of the new client. I do not believe that there is much value in expressing the difference between the two here. BTW "subclassing" is not the correct term, it is (again) generalization. Adding such a generalization implies that every new customer is a customer and can do whatever a regular customer can do.



Relationships are dependencies
The key to Include and extend use case relationships is to realise that, common with the rest of UML, the dotted arrow between use cases is a dependency relationship. I'll use the terms 'base', 'included' and 'extending' to refer to the use case roles.

include

Include is used to extract use case fragments that are duplicated in multiple use cases. The included use case cannot stand alone and the original use case is not complete without the included one.

A base use case is dependent on the included use case(s); without it/them the base use case is incomplete as the included use case(s) represent sub-sequences of the interaction that may happen always OR sometimes. ( This is contrary to popular misconception about this, what your use case suggests always happens in the main scenario and sometimes happens in alternate flows simply depends on what you choose as your main scenario; use cases can easily be restructured to represent a different flow as the main scenario and this should not matter).

In the best practice of one way dependency the base use case knows about (and refer to) the included use case, but the included use case shouldn't 'know' about the base use case. This is why included use cases can be: a) base uses case in their own right and b) shared by a number of base use cases.

extend

Extend is used when a use case conditionally adds steps to another first class use case.

The extending use case is dependent on the base use case; it literally extends the behaviour described by the base use case. The base use case should be a fully functional use case in its own right ('include's included of course) without the extending use case's additional functionality.

Extending use cases can be used in several situations: a) The base use case represents the "must have" functionality of a project while the extending use case represents optional (should/could/want) behaviour. This is where the term optional is relevant - optional whether to build/deliver rather than optional whether it sometimes runs as part of the base use case sequence. b) In phase 1 you can deliver the base use case which meets the requirements at that point, and phase 2 will add additional functionality described by the extending use case. This can contain sequences that are always or sometimes performed after phase 2 is delivered (again contrary to popular misconception). c) It can be used to extract out sub sequences of the base use case, especially when they represent 'exceptional' complex behaviour with its own alternative flows.

One important aspect to consider is that the extending use case can 'insert' behaviour in several places in the base use case's flow, not just in a single place as an included use case does. For this reason it is highly unlikely that an extending use case will be suitable to extend more than one base use case.

As to dependency, the extending use case is dependant on the base use case and is again a one way dependency, i.e. the base use case doesn't need any reference to the extending use case in the sequence. That doesn't mean you can't demonstrate the extension points or add a x-ref to the extending use case elsewhere in the template; but the base use case must be able towork without the extending use case.

• Association is a relationship where all objects have their own lifecycle and there is no owner.
  Let's take an example of Teacher and Student. Multiple students can associate with single teacher and single student can associate with multiple teachers, but there is no ownership between the objects and both have their own lifecycle. Both can be created and deleted independently.
• Aggregation is a specialised form of Association where all objects have their own lifecycle, but there is ownership and child objects can not belong to another parent object.
  Let's take an example of Department and teacher. A single teacher can not belong to multiple departments, but if we delete the department, the teacher object will not be destroyed. We can think about it as a “has-a” relationship.
• Composition is again specialised form of Aggregation and we can call this as a “death” relationship. It is a strong type of Aggregation. Child object does not have its lifecycle and if parent object is deleted, all child objects will also be deleted.
  Let's take again an example of relationship between House and Rooms. House can contain multiple rooms - there is no independent life of room and any room can not belong to two different houses. If we delete the house - room will automatically be deleted.

Configuration Maven and JBOSS

Configuration Maven and JBOSS


Configure Maven
Step1:
Open Environment Variables

Step2:
Create New System Variables
Maven Home parameter: M2_HOME
Value "maven root directory"

Step3:
Enter the below value in path ;%M2_HOME%\bin;

Step4:
Apply and ok

Verification:
Open maven bin directory and type command
mvn -version

Configure JBOSS 7.1

step1: download JDK1.6 or above

step2: install JDK

step3: create JAVA_HOME

step3.1 :
Open Environment Variables

Step3.2:
Create New System Variables
JAVA Home parameter: JAVA_HOME
Value "Java root directory"

Step3.3:
Enter the below value in path ;%JAVA_HOME%\bin;

Step3.4:
Apply and ok

After installing Java and Maven download JBOSS 7.1 and unzip and run the command standalone.bat from bin directory.

Now all set to use JBOSS.

http://www.youtube.com/watch?v=zkNyEXArwwI

http://www.jboss.org/jdf/quickstarts/jboss-as-quickstart/guide/GettingStarted/#_installing_and_starting_the_jboss_server_on_windows

Maven vs Ant

Maven vs Ant.

This article provides difference between two tools and why in one case you choose Ant and in another Maven. It help to make a choice between two Java build tools.

developers usually prefer one tool over another because:

1. Develop faster
2. Concentrate on real work
3. Generate all related document easy

developer also prefer one tool over another to keep our bosses happy, which means:

1. Reduce development costs
2. Reduce time to market
3. Frequent status reports, which can be easily presented to higher boss

Ant is older tool and it was deigned to have some Java-based build tool. Something similar to Make which most of C++ developers use.

Ant is different. Instead of a model where it is extended with shell-based commands, Ant is extended using Java classes. Instead of writing shell commands, the configuration files are XML-based, The power of Ant in practice results that you have to setup build process yourself. Each project can have different build process. New team members have to study this version of build which is probably they used to have in another project.

Maven (Maven)on another hand wants a standard way to build the projects, a clear definition of what the project consisted of, an easy way to publish project information and a way to share JARs across several projects.

Maven encourage best practices and some people can prefer Ant. Ant is less flexible than Maven and you have to be agree with making of some compromises.

Maven is not the next generation Ant!
Maven is not just a building tool, it provide an organization and a structure layer. All you do in ant can be done in Maven because you can call ant target.

The main advantage to migrate to Maven are : standardization of how to handle a project, dependencies are clearly defined, the concept of artifacts that can be shared to other projects, documentation and reports, remote and local repository concepts.

Maven will help you with:

1. Making the build process easy and provide uniform build environment
2. Generate quality project information

Major advantages/disadvantages - Maven vs Ant.

Maven
1. Description of project Development of a build script per project
2. Invocation of defined goals (targets) Invocation of project specific targets
3. Project knowledge "Just" the build process
4. build life cycle, standard project layout too complex scripts
5. reusable plugins, repositories scripts are not reusable
6. moving fast forward development are slowed down
7. Maven is declarative, Â Maven takes care of all the directories once the files are stored in the pom.xml file.
8. Maven has a life cycle.

Ant
1. Development of a build script per project
2. Invocation of project specific targets
3. "Just" the build process
4. too complex scripts
5. scripts are not reusable
6. development are slowed down
7. Ant is procedural. In Ants, you have to specifically order what should have to be done.
8. Ant does not have a life cycle.

The good thing with Maven that it is extremely flexible, because it consists of core and numerous plugins that are accessible in online repositories. Relations between different projects and subprojects are based on a single source of information POM (xml) file - Project object Model. One POM points to another POMs which can have flat or hierarchical structure.

A project produces an artifact - jar, ear, war...

Maven features:

1. Dependencies are downloaded automatically
2. Standardized, very consistent layout
3. Standardized, very consistent naming
4. Code coverage
5. Extensive reports
6. Maven easily works with JUnit tests


http://www.javafaq.nu/java-article1168.html

http://www.scribd.com/doc/19172721/A-Brief-Comparison-of-ANT-MAVEN

Spring Framwork Tutorial

Spring Framwork Tutorial


http://www.youtube.com/watch?v=DfMjxfwV5_s&feature=relmfu

SAML and Security

SAML and Security


Federation:
Federation describes scenarios in which no group or organization manages all users and resources in a distributed application environment. Instead, administrators in diverse domains must manage local security policies that support mutually beneficial transactions among their respective spheres of operation. In the world of distributed network services, the term refers to the need for trust agreements among decentralized security and policy domains. Federation lets access-management functions span diverse organizations, business units, sites, platforms, products and applications. Federation requires that an organization trust each trading partner to authenticate its own users' identities. In a federated environment, a user can log on to his home domain and access resources transparently in external domains, such as those managed by customers or suppliers, subject to various policies defined by home and external administrators.Federation used with a new security standard, the XML-based Security Assertions Markup Language (SAML). The standard defines XML/Simple Object Access Protocol-based protocol interactions that support real-time authentication and authorization across federated Web services environments. The standard defines request and response messages that security domains use to exchange authentication, attribute and authorization information in the form of trust-assertion messages about named users and resources. Users log on to their home domains through authentication techniques such as ID/password or Kerberos, and this authentication is communicated to a federated destination site through a SAML authentication assertion.

How SAML works

One of the most important of those security issues is user authentication - specifically, allowing a user to sign on or use multiple Web services from separate but affiliated sites, without having to authenticate himself at every step of the process. That's the job of SAML (Security Assertion Markup Language), an XML-based standard for authentication and authorization that provides a "single sign-on" so that people can be authenticated once and then be able to access multiple Web services. SAML allows each individual site to have its own mechanism for sign-on and authentication, but will allow sites to accept authenticated users from other sites.

Why SAML is needed

Before we take a look at how SAML works, let's take a look at why it's needed. Let's say someone visits an airline site with a Web services architecture, and reserves tickets after signing on and being authorized to buy the tickets. The site offers special deals with partner sites on hotel stays and car rentals, and so the user decides to make reservations with them. In order to make reservations with each of those partner sites without SAML, the person will have to sign on separately to each site, using different user names, passwords and authentication information. He also might have to enter special codes that say he is entitled to the special deals. But with SAML, the person would only have to sign on to the first site, and he would then automatically be authenticated via SAML at the affiliated sites.Even more problematic are complex B2B transactions done via Web services. Web services will most likely be used in automated transactions that involve multiple business partners, including manufacturers, distributors, packagers, suppliers and retailers. With no way to authenticate each partner and what they can and can't do in a transaction, these transactions won't be able to be done automatically. With SAML handling authentication, complex transactions can be automated without worrying about authentication problems.

SAML Implementation

So how does SAML tackle all this? At its base, SAML is nothing more than a series of XML-based messages that detail whether users are authenticated, what kind of rights, roles and access they have and how they can use data and resources based on those rights and roles. It will work with HTTP, SMTP, FTP and SOAP, among other protocols and technologies.

The three main components of the SAML specification are:

Assertions SAML has three kinds of assertions:
1. Authentication assertions are those in which the user has proven his identity.
2. Attribute assertions contain specific information about the user, such as his spending limits.
3. Authorization decision assertions identify what the user can do, for example, whether he can buy an item.

Protocol:
This defines the way that SAML asks for and gets assertions, for example, using SOAP over HTTP for now, although using other methods in the future.

Binding: This details exactly how SAML message exchanges are mapped into SOAP exchanges.

The assertions are exchanged among sites and services using the protocol and binding - and those assertions are what authenticates users among sites.

SAML in real life

How does SAML work in real life? Let's take a real-life example. Say someone logs in and uses a Web service, is authenticated and then wants to go to a partner site. With SAML, he can be authenticated at the second site without having to sign on. The nearby figure shows each step of the process:

Step 1 the user has authenticated himself with Site 1 and wants to visit Site 2. He clicks on a link to go to Site 2.In

Step 2, instead of being sent straight to Site 2, he is instead sent to the SAML service for Site 1.

Step 3 the SAML service appends a partner ID and a special handle to Site 2's URL in the user's browser.
For example, if the user wants to go to the site http://www.buymenow.com, after the SAML service appends the extra information, the URL might now be https://www.buymenow.com?SAMLart=. Note that the protocol has changed to the secure https instead of http. The user is redirected now to Site 2's SAML service, which examines the URL with the appended information. Based on the information in the URL, Site 2's SAML service communicates with Site 1's, and Site 1 sends along the authenticated identity of the user, along with any rights that the user has.

Step 4 the user is sent to Site 2, fully authenticated. The user can now perform transactions on the site just as if he had logged directly into the site.

The future of SAML

SAML is not yet a fully accepted standard. OASIS, the consortium that develops XML standards, is expected to accept the first official SAML standard this summer or late spring. Sometime in the fall, you can expect products to be available that can make use of the accepted spec.As with all standards, though, expect some problems. It's unclear whether a Web service built using an early version of SAML will be able to completely work with a Web service built using a later version. Considering that SAML 1.0 hasn't even been accepted yet, it's a moot point right now, but could be problematic in the future.A bigger potential issue is whether Microsoft will buy in to the spec. Even though Microsoft is an OASIS board member, it's working on its own separate authentication protocols, known as WS Security and WS License. If Microsoft decides to continue work on them and use them as an alternate to SAML, all bets are off as to how useful the protocol will prove in the long run.

AD and LDAP


Active Directory is a database based system that provides authentication, directory, policy, and other services in a Windows environment

LDAP (Lightweight Directory Access Protocol) is an application protocol for querying and modifying items in directory service providers like Active Directory, which supports a form of LDAP.

Short answer: AD is a directory services database, and LDAP is one of the protocols you can use to talk to it


Active directory is a directory service provider, where you can add new user to a directory, remove or modify, specify privilages, assign policy etc. Its just like a phone directory where every person have a unique contact number. Every thing in AD(Active Directory) are considered as Objects and every object is given a Unique ID.(similar to a unique contact number in a phone directory.

Ldap is a protocol specially designed for directory service providers. Windows server OS uses AD as a directory server, AIX which is a linux version of IBM uses Tivoli directory server. Both of them uses LDAP protocol for interacting with directory.

Apart from protocol there are LDAP servers, LDAP browsers too.


reference: http://searchsoa.techtarget.com

ESB Tutorial

ESB Tutorial

Our ESB tutorial provides the tips, expert advice, definitions, implementation examples, trends and news you need to get started with or optimize the performance of an enterprise service bus.

Table of Contents
Introduction
What is an ESB?
ESB tips and expert advice
ESB news and trends
How to use an ESB
ESB products


Introduction
The enterprise service bus (ESB) is a software infrastructure that facilitates application integration. An ESB is valuable to the implementation of a service-oriented architecture (SOA) because it exchanges messages, executes transactions, orchestrates services, and performs publish and subscribe functions between disparate and distributed applications.

The ESB was created to meet demands and avoid common problems that other enterprise application integration (EAI) platforms could not. The popular hub and spoke EAI platform, in which all integrated applications work through a single message broker, creates a single point of failure, an incredible risk for a complex business system. The ESB, though, has numerous brokers, and so avoids this risk.

The ESB is also more suited for SOA. Unlike the hub and spoke platform, an ESB facilitates the loose-coupling of systems and the use of open-standards, two features of most successful SOA implementations. Despite these advantages, there were initial doubts about whether the ESB would be only a brief fad. Nicholas Farges' addressed this question when the ESB first appeared widely in 2003, and his assessment remains an excellent introduction to the ESB platform.

One of those doubts arose from the necessary intricacy of an ESB. Some viewers worried that implementing an ESB would only exacerbate the complexities of service orientation. As an SOA initiative matures, though, the myriad benefits of the ESB become evident: Security, agility, availability, and other key characteristics of EAI all improve once an ESB is in place. Contrary to common fears, the ESB can simplify SOA.

While an ESB can help, it's still important to choose the right one. A lightweight ESB can be implemented quickly and inexpensively, so it's often favored by developers working under tight deadlines and tight budgets. Their architect counterparts, though, may have a long-term vision and desire a more comprehensively functional ESB to support a broad SOA strategy. According to a recent Forrester Research report, the right lightweight ESB can satisfy developers and architects alike.

While many organizations are choosing which kind of ESB to implement, many vendors are choosing which kind of ESB to produce. The open-source ESB has grown popular with vendors as they face price pressure from the market and seek to cut development and support costs. Several significant mergers and acquisitions have accelerated the trend.
Back to the top

What is an ESB?

ESB definition
An enterprise service bus (ESB) is a software architecture for middleware that provides fundamental services for more complex architectures.

EAI
Enterprise application integration (EAI) is a business computing term for the plans, methods, and tools aimed at modernizing, consolidating, and coordinating the computer applications in an enterprise.

Enterprise Service Bus (ESB): Lasting concept or latest buzzword?
Nicholas Farges took a close look at the ESB shortly after it was conceptualized. His thorough introduction and analysis remain valuable six years later to anyone who considers using an ESB.

Open source and ESBs
The Enterprise Service Bus [ESB] has been intrinsic to many SOA programs in recent years. You can say you are doing SOA and not have done an ESB. But there is a high likelihood a successful SOA program includes successful ESBs.

Some notes on ESB configuration
For many people, "SOA" is "ESB." But, the definition of ESB is a moving target—it started rather as a "three-ring binder" of accepted corporate integration practices, and now has taken the form of a service architecture that holds various middleware types. The term "bus" is used to allude to the hardware bus that connects chips on printed-circuit computer boards in the realm of hardware. Messaging continues to be the primary service that ESBs provide, and many of them use Java as the language of choice.
Back to the top

ESB tips and expert advice

The ESB and its role in application integration architecture
Although enterprise service busses (ESBs) are not new, they can continue to be a nexus for confusion. After many years and many implementations, what they do, how they do it and whether specific products can help create a SOA are all still matters of contention. Understanding the ESB remains an industry-wide quest.

Jeff Genender on SOA infrastructure
Jeff Genender is an active committer and Project Management Committee (PMC) member for Apache Geronimo, a 'committer' on OpenTerracotta, OpenEJB, ServiceMix and Mojo (Maven plugins), and the author of several books. In this interview, Genender shares his take on SOA infrastructure. He includes message buses, containers, orchestrators and more in his definition, but pays particular attention to ESBs.

Open source licenses explained: caveats and comparisons
There are many pitfalls awaiting enterprise software development shops that use open source code without first setting down a clear strategy, according to Protecode CEO Mahshad Koohgoli. n this Q&A, Koohgoli discusses dual licensing and how companies use some of the more common open source licenses available.

Three tips for choosing an ESB
Jess Thompson, Research Vice President at Gartner, provides his top three tips on getting on the bus.

An open source ESB can cost you
Open source software can theoretically be acquired for free, and CIOs are attracted to products where they don't have to show a capital expense. However, an open source ESB can still have a cost. Read this to find out the risks of an open source ESB.

Use an ESB to simplify the complexity of SOA
Why add yet another moving part into the service-oriented landscape? Isn't management of service-oriented applications already too complicated? The reasons for introducing an enterprise service bus are the same as those applied when choosing to implement an enterprise application integration strategy some years ago. Learn how an ESB can simplify SOA.

Is a lightweight ESB right for your SOA?
It's a classic conflict: Developers focused on a project and facing deadline pressure want to use a lightweight enterprise service bus (ESB), while enterprise architects have to look at the long-term impact on the service-oriented architecture (SOA) environment. Learn when one is better than the other.

Data Services for ESB's
Some ESBs are adding MDM/data services capabilities (e.g. Sun, WSO2). We ask an expert: Do you think that's something an ESB should be doing or is this functionality that's best handled outside a service bus?
Back to the top

ESB news and trends

Cloud Silos and the role of ESBs in the cloud
MuleSoft is prepping its iON cloud platform for a public performance. It features an ESB engine that is said to support orchestration and more flexible data handling than point-to-point cloud computing integrations.

In 2010, cloud computing met ESBs, data caches, services and more
Cloud took on the look of middleware architecture in 2010. Cloud poster child Salesforce.com expanded beyond its original Apex language support, buying Ruby-based cloud house Heroku and forging a development deal with VMWare's Spring application framework group.

Forrester analysts: SOA still strong
Businesses that already use SOA are expanding their SOA initiatives and new businesses are starting to adopt SOA and to implement SOA technologies. The first-time SOA infrastructure purchase may be shifting from ESBs to other technologies.

ESBs in the cloud: Tricky in the early going
Stratos SOA platform maker WSO2 has announced a retooled version of its enterprise service bus (ESB) along with other middleware for cloud computing environments, it begged the question: What do IT shops need to know about ESB implementation in the cloud?

ESB watered down by EAI, but distinction remains
The definition of ESB has lost some of its distinction as a distributed architecture, says Progress software's Hub Vandervoort. Read what differentiates a barebones ESB from one that evolved from earlier EAI concepts.

Is open-source remaking the ESB market?
The enterprise service bus (ESB) market is evolving as open source players enter it, but as in biological evolution, it appears to be a matter of adapting to survive.

SOA complicated by ESB proliferation
Enterprise service bus (ESB) intermediation remains an issue despite the adoption of WS-* standards, argues John Michelsen, chief architect at iTKO Inc., the testing vendor specializing in service-oriented architecture (SOA).
Back to the top

How to use an ESB

Message brokering as part of an approach to flattening the problem of diverse mobile device support
Mobile devices keep growing more numerous. As they grow in numbers, they also grow in variety. It can be difficult to develop applications that work with all these devices. Employing an ESB as a message broker between the devices and the applications can simplify compatibility issues.

FAA uses open source ESB to handle flight data
Last year the Federal Aviation Administration (FAA) selected an open source enterprise service bus (ESB) to provide integration support for a system that uses Web-based services to handle flight and weather data for airlines. Earlier this year, a SWIM Prototype became operational at the FAA's William J. Hughes Technical Center in Atlantic City, NJ.

U.S. Coast Guard adopts SOA and ESB to better track ships at sea
As it moved in recent years to SOA and a full enterprise architecture, the U.S. Coast Guard sought to upgrade legacy systems' operation. The thinking was that, for a SOA implementation to be successful, an organization does well to get used to sharing data across multiple channels. With the SOA conversation beginning in early 2007, the USCG actually began producing new systems this past January with its new enterprise service bus (ESB).

User combines open source ESB with data services to speed customer reports.
Generating customer reports is the bane of most development operations. These requests flood development groups. The issue has only grown worse as organizations compile more and more data, and users more imaginatively ask 'what if?,' further taxing programmers' time. Read this article to learn how one company has taken a data services approach to solving the problem, at the same time implementing a type of Web services mashup to address user needs.

SOA integrates university's ERP project
Service-oriented architecture (SOA) allows departmental developers working on a variety of applications at the various campuses and facilities of the University of Illinois to provide data access without worrying about the data sources. Read why all that data is now available from the ESB for Ajax and rich Internet applications (RIAs) developed for the University of Illinois campuses in Champagne-Urbana, Springfield and Chicago, as well as the online campus.
Back to the top

ESB products

ESB IDE offers “round trip” editing
ESB developers could laboriously hand code or they could adopt tools from vendors that could speed up the process but at a cost – the tools could themselves be complicated and they tended to obscure access to underlying code. An IDE seeks to address this concern.

Oracle details SOA, Java roadmap with BEA
BEA customers will not be forced to migrate to Oracle Corp. middleware products, Charles E. Phillips Jr., Oracle's president, said when he outlined plans for the integration and support of the two companies product lines in July 2008. The integration includes in innovative convergence of Oracle's ESB and BEA's Aqualogic bus.

Eclipse group releases Swordfish, an open-source ESB
Recently at EclipseCon, the Eclipse Foundation formally released Swordfish, an enterprise service bus (ESB) based on OSGi. It joins a host of other open ESBs, including OpenFuse, Mule, and others.

Open source/commercial ESB hybrid reflects SOA reality
Iona Technologies Inc. today announced its own hybrid model for selling Artix, its closed source enterprise services bus (ESB), and FUSE, its open source ESB based on technology developed by the Apache Foundation.

FUSE ESB brings Apache ServiceMix 4.0 to market
In its first product release since formally becoming a division of Progress Software, Iona has announced FUSE ESB 4.0, a commercial version of the Apache ServiceMix 4.0, open source enterprise service bus (ESB). The software seeks to combine the openness of open source with the rigor of some commercialization.

http://searchsoa.techtarget.com/tutorial/ESB-Tutorial

ESB-Integration Comparison

soa-patterns