Qualifiers

Interface Qualifiers

• Data Validation

 Determines whether the input data should be validated against its definition (ie. the XSD that describes the data).

• Join Activity Session

Determines whether or not the hosting container will join any propagated (client) activity session.

• Join Transaction

Determines whether or not the hosting container will join any propagated (client) transaction.

• Security Permission

Specifies a role, which is a semantic grouping of permissions that a given type of users must have to use an operation in an interface. The identity of the caller must have this role in order to be permitted to call the interface or operation. If no security permission is specified, then no permissions are checked and all callers are permitted to call the interface or operation.

• Store And Forward

Determines if messages should be stored when an exception occurs.

Store and forward qualifiers may be be set on Interfaces of Components, Imports or SCA Exports that can potentially be invoked asynchronously.

Implementation Qualifier

• Activity Session

Determines if the component's processing will be executed under an activity session.  An activity session is an alternative unit-of-work scope to the one provided by global transaction contexts. An activity session context can be longer lived than a global transaction context and can encapsulate global transactions.

• Security Identity

Specifies the identity under which the implementation executes at run time.

• Transaction

Determines the logical unit of work that the component's processing executes. For a logical unit of work, all of the data modifications made during a transaction are either committed together as a unit or rolled back as a unit.

Reference Qualifier

• Asynchronous Invocation

Determines if asynchronous invocations should occur as part of any client transaction. 

• Reliability 

Determines the quality of an asynchronous message delivery. In general, better performance typically means less reliable message delivery. With an Assured specification, the client application cannot tolerate the loss of a request or response message. With a Best effort specification, the client application can tolerate the possible loss of the request or response message.

• Request Expiration

The length of time after which an asynchronous request will be discarded if it has not been delivered, beginning from the time when the request is issued.

• Response Expiration

The length of time that the runtime environment must retain an asynchronous response or must provide a callback, beginning from the time when the request is issued.

• Suspend Activity Session

Prevents the propragation of the activity session context to a target component.  This applies when the target is invoked using the synchronous invocation.

• Suspend Transaction

Determines whether the invocation of a target service runs completely within the client's global transaction.  This qualifier only applies to synchronous invocations.

SOA

SOA (Service Oriented Architecture)

D 1: Used to design and develop a wide range of services which can be inter-operable.
D 2: It adopts component based programming model.
D 3: It is a set of principles and methodologies for designing and developing software in the for of inter-operable
D 4: Service-oriented architecture (SOA) is an approach used to create an architecture based upon the use of services. Services (such as Restful Web services) carry out some small function, such as producing data, validating a customer, or providing simple analytical services.

SOA is an architectural concept and web service is one of the technical approach to complete it,

Services

D 1: Repeatable business task and composed in to a business process.
D 2: Reusable ,defined with particular articrafts
D 3: Services are the building blocks and they are composed in to a business process.
D 4: Services are used to help get the right information to the right people at right time.
D 5: Service is nothing but a task or a method that is used to execute an activity,
D 6: Services can be reused and combined to deploy composite application to address to address new opportunities.

Service Characteristics 

• Well defined interfaces.
• Well defined quality of service capabilities.
• Well known endpoints: As a destination on the n/w that receives service requests.

Service Register

Locating and publishing web services.

Architectural Components

Figure 1 shows the basic components of a service-oriented architecture. The components of a service-oriented architecture include:

• Service providers. A service provider is a component or set of components that execute a business function in a stateless fashion, accepting predefined inputs and outputs.
• Service consumers. A service consumer is a set of components interested in using one or more of the services provided by service providers.
• Service repository. A service repository contains the descriptions of the services. Service providers register their services in this repository and service consumers access the repository to discover the services being provided.

Figure 1. Service-oriented architectural components

Principles of SOA

Modularity: 

• Component of a larger system that operates independently from the operation of the other components.

Encapsulation:

•  A service hides information or implementation details by encapsulating the information into a construct which presents an interface
•  Many services which were not initially planned under SOA, may get encapsulated or become a part of SOA.

Loose Coupling :

• Incompatible system technologies can be joined ,dis assembled just as easily in to their functional components.
• Services minimize dependencies on each other. 

Separation of Concerns/ Service Composability :

• Services break down a complex problem in a series of smaller pieces. Each of the smaller pieces address a specific concern.
• Services break big problems into little problems. 

Reuse:

• SOA is enabled through pluggable components with standard interfaces.
• Logic is divided into services with the intent of maximizing reuse.

Service Interoperability :

• Services should use standards that allow diverse subscribers to use the service. This is considered so obvious these days that it is often dropped as a principle. 
• 

Service Discoverability :

• Services can be discovered (usually in a service registry).
• 

Service Autonomy :

• Services should have control over the logic they encapsulate. 
• 

Service Abstraction :

• Services hide the logic they encapsulate from the outside world. 

Challenges of SOA

• Managing service metadata(Information about data,Data About Data)
• Lack of testing in SOA space.
• Providing appropriate security
• Interoperability
• Early adoption and evolution of supporting technology 
• Organization change in necessary since SOA crosses system boundaries 
• The architecture is enterprise in scope encompassing dispersed and heterogeneous systems 
• The infrastructure is distributed requiring high availability and scalability 
• The project life cycle methodology requires changes due to complex system dependencies, SOA specific design patterns, and the change impact to the infrastructure and users 
• Program management is often complex due the project scope, interdependencies and new technology risks 
• Quality Assurance is difficult since services are distributed, have many interfaces, require new testing environments, and message based testing tools 
• New competencies must be developed spanning project management, analysis and design, development and operations. 

Challenges

While implementing a service-oriented architecture, a company faces up to eight key challenges. These challenges align to the steps in a typical project deployment plan:

1. Service identification. What is a service? What is the business functionality to be provided by a given service? What is the optimal granularity of the service?
2. Service location. Where should a service be located within the enterprise?
3. Service domain definition. How should services be grouped together into logical domains?
4. Service packaging. How is existing functionality within legacy mainframe systems to be re-engineered or wrapped into reusable services?
5. Service orchestration. How are composite services to be orchestrated?
6. Service routing. How are requests from service consumers to be routed to the appropriate service and/or service domain?
7. Service governance. How will the enterprise exercise governance processes to administer and maintain services?
8. Service messaging standards adoption. How will the enterprise adopt a given standard consistently?

https://msdn.microsoft.com/en-us/library/aa480029.aspx