P20CAI3201-SERVICE

ORIENTED
ARCHITECTURE

Dr.N.JAYAKANTHAN Lead Faculty

1

Department of Computer Applications

Dr.N.JAYAKANTHAN

Assistant Professor(SRG)
Department of Computer Applications
16 years of Teaching Experience
Two years of Industry Experience
B.Sc Computer Science
MCA
M.Phil – Computer Science
Ph.D – Detecting Malicious URLs using
Classification Algorithms
UNTI II – Service Oriented
Architecture
Considerations for Enterprise-wide SOA
• An enterprise include interdependent resources (people and technology)
that must coordinate their function and share information in support of a
defined version.
• Enterprise architecture is a collection of models that define the structure
required for organization to achieve its objectives. SOA is an architectural
style that when applied at enterprise level is consistent and supports
enterprise architecture.
• The following are the key consideration for developing enterprise
architecture.
1. Objectives, drivers and goal of business
2. Business to fulfil the goals
3. Alignment of IT with business goals
4. Change management and governance
The following dimensions of service model have to also be taken into account
for SOA at enterprise level.
1. Reusability : Reusable loosely coupled nature of service is fundamental to
the services model.
2. Agility : Application based on service model have their business process
externalized.
3. Integration: Service Providers and Service Consumers are loosely coupled
and communication between them is based on public contract.
 Strawman Architecture for Enterprise- wide SOA
• Strawman architecture is a initial architecture that server as a
starting point for developing target architecture.
• It is refined over a number of iteration and results in the
development of the target architecture.
• Figure 9.1 represents .Strawman Architecture for Enterprise-
wide SOA
• The business transformation dimension of SOA namely reuse, integration and
agility. Requires the reusable functionality is exposed as service , integrated
through the principle of loose coupling and orchestrated to implement the
agile business process.
• The operation dimension of SOA namely, governance and quality of services
that require design time and run time governance to be defined and enforced.
• Strawman architecture represents four types of services and their relation ship.
1.Activity Service or business Service:
It encapsulate the functionality exposed as service in various applications. These services
are reusable business level services that may be orchestrated as part of configured business
process. These services are referred as Type A Services
2. Business Process Services
Handle orchestration of business process implemented as a set of service. These services
control the flow and interaction of the different services. Referred as Type B Services.
Allows externalization of the business process through their specification as workflow and
orchestration by process orchestration engine resulting in agility for enterprise
3. Client Services:
It deliver the content to “front-end” application of the enterprise to enable users to
access fine-grained data(order information) and coarse grained data (e.g enterprise
dashboard data). These services are referred as Type C Services. API defined by an
enterprise for consumption by mobile and web clients may be implemented with this
category of services.
4. Data Services:
Data Services encapsulate access to data in various sources such as relational
database, spreadsheets, data warehouse or a system external to the organizational
context.
There are typically two types of data services that are defined in an enterprise ( will
be referred as type D services).
• Services that encapsulate access to data stored across the enterprise in various
data sources.
• Services that enable interaction with data source outside the enterprise.
Enterprise Service Bus (ESB)
Key feature of Strawman architecture . Enable smooth communication
between the service provider and service consumer.
This pattern abstracts the mediation and interaction element required for a
bus that is used for integration service.

In Strawman Architecture for Enterprise- wide SOA has the ESB as heart of
communication between the application.
• Another important aspect of the Strawman Architecture is that it address
definition of policies for key nonfunctional requirements and their
enforcement through governance and quality of service supports
operational dimension of SOA

1. Governance – In SOA implementation, service interaction( service call

from service consumer to service producer) needs to governed. To full fill
the needs the policies are defined in governance layer for non-functional
requirements such as security, message transportation, infrastructure
availability taking into account key performance indicators for business
and SLA for IT.
2. Quality of Service (QoS):
Service interaction also need to be monitored and secured as per policies
defined. This need is fulfilled by ensuring that service interactions are
monitored (application monitoring, business activity monitoring and IT
system monitoring) to enforce the polices at run time.
Strawman architecture presented above brings out three key aspects in
development of SOA at enterprise level.
1. Identification and development of different types of services (essentially
types A,B,C,D services mentioned earlier.
2. Implementation of an integration layer based on the ESB pattern.
3. Implementing of service governance and service monitoring/ policy
enforcement
Enterprise SOA for reference Architecture
• In this architecture has five horizontal layer and 4 vertical layer.
• Each layer represents the grouping of architecture building blocks (ABB) that
define the key responsibilities of the layer. The run time realization or
implementation of ABB is a solution building block(SBB). SBB and ABB is actual
realization by a set of products.
The five horizontal layers of SOA reference Architecture are:
1. Consumer Layer
It implements the presentation components and / or client services. A channel
independent frame work with a consistent interface for web, thick and mobile
clients of enterprise users in one possible implementation option to package the
functionality as client services whose end points are exposed by client API layer to
clients.
2. Business process layer:
Externalizes business process workflow for service orchestration. This layer
implements the process orchestration engine and associated workflow for the
business process services. The service invocation from consumer layer to business
process layer is mediated by integration layer.
3. Service Layer
Has service endpoints (Service contract and description) that will be used at
run time. This layer defines the service contract for the activity, business
process, client and data services in the Strawman architecture.

4. Service Component Layer

Comprises the service components that implement the service. Each service
components is composed of a functional component that provide the
functional capability(e.g JAVA POJO) and a technical component that
encapsulates the function component to comply with standards and ensure
technical support(e.g RESTful Web Service). The service is typically created
with IDE(e.g Eclipse) and bundled into a deployment unit (e.g EAR file).
When the deployment unit is deployed into the runtime environment(e.g IBM
WAS Server) it is referred as solution component.
5.Operational System Layer.
It holds infrastructural element of all layers including underlying
infrastructure software to run the infrastructural elements and deploy service
implementation.
It includes physical/virtual servers for on-premise/ cloud, their operating
system, virtualization software to manage the server, and web servers,
application servers and other run time environment.
• Four Vertical layers that deal with cross cutting concerns are
1.Integration Layer : Performs mediation which include transformation,
routing and protocol conversation implemented with the help of enterprise
service bus.
2.Information Layer: enables shared, common, integrated and consistent view
of data. This layer exposes data service from the underlying data in database
servers, semi structured data in spreadsheets, data warehouse and other data
sources.
3. Governance Layer: define policies and guidelines for non functional
requirements that need to be compiled with at both design and run time,
typically implemented with service registry and repository.

4. Quality of Service (QOS) layer: monitor service innovation and enforces

policies defined for non functional requirements (performance, security etc)
with service registry/ repository security tool and service monitoring tool
• The user interact through the end points of client services exposed by client
API layer. The client service provider response to the user requests through
calling other services to get the content user needed in channel independent
manner. An API Gateway may be used to implement client API layer to publish
a set of APIs that map to the client services in consumer layer.
• Alternatively, user may also interact with the user interface built with
presentation component in consumer layer.
• The consumer layer may call activity services (or business services) or
alternatively call business process services in the business process layer
through integration layer.
• The business process layer are externalized as business process services and
defined using language such as Business Process Execution Language (BPEL)
• A Process orchestration engine that forms part of a business process layer
executes the service exposed by the service layer as steps of business process.
• The service layer exposes the business service or activity services that are
realized in the service component layer and hosted in operational system layer.
• The information layer exposes the data services which are typically utility
services that are consumed by business services and activity services.
• Several ETL (extract-transform and load) , MDM and other reporting tools
having have the capabilities to explore structured and unstructured data in
the database and other data source as service.
• The Integration layer servers as central bus for integrating and
implementing the ESB capabilities. The quality of service layer enforces the
policies at run-time including those related to security and servers as
collection point for monitoring and management of NRF.
• The governance layer provides mechanism to set policies and manage the
overall governance. The governance and quality of service layers may be
implemented with registry and repository tools.
 Object Oriented Analysis and Design Process
• In software engineering process is a sequence of steps required to develop or
maintain software.
• A Process model deals with the ‘what’ of developing software.
• Methodology is a set of principles, practises and procedures that may repeatedly
applied to develop a specific category of application. Methodologies deals with
the ‘how’ of developing software.
• Object oriented applications are developed on the basis of the following
principles:
1. Encapsulation
2. Abstraction
3. Inheritance
4. Interface
5. Polymorphism
• Object oriented analysis and design process involves modelling real world
objects abstracted as a classes.
• The requirements are described as a set of use cases and realized through a
process that involves identification of analysis classes (boundary, control
and entity) and their mapping technology elements that consists that
constitute the design classes.
• Classes are fine-grained elements that are tightly coupled.
• Design classes and related software constructs are implemented using
programming languages to develop the required application.

• The key steps of OOAD process are given in figure 9.3

• OOAD is a powerful technique that leverage the modelling of objects based
on their class hierarchies
• It presents some difficulties when applying to service oriented applications.
• The software constructs in OO applications are tightly coupled. While
interface defined for object do provide for abstraction and information
hiding, and in principle can implement loose coupling , the nature of the
classes and interfaces do not yield the benefits that one could derive from a
service model.
• Further the class hierarchies are based on inheritance which brings strong
association and tight coupling.
• Service definition on the other hand , promotes loose coupling between the
service provider and service consumer.
• Also the run time environment for OO applications assume object
housekeeping services (such as Garbage collection, in Java EE applications.
No such dependencies or capabilities are either assumed, or planned for, in
service model.
 Service Oriented Analysis and Design (SOAD) Process
• In order to extend the OOAD process to support the service model,
consideration related to service model, namely, reuse, agility and
integration need to be addressed in the process.
• Service Oriented Analysis and Design Process is shown in the Figure 9-4.
• It is analysed to scope out the applications that would implement the
business process and their requirements as a set of use cases. The use case
identified determine the scope of the each applications for the future state
of the functional perspective. The activity services, business process
services, client services and data services exposed or consumed by
application are identified.
• Sub – Process A – Activity (or Business Services) Development: The
business application expose activity services (Referred Type – A service in
Strawman Architecture) that are developed through this sub process. Any
enterprise would have set of applications supporting the current state of
the business.
• Activity services are identified and specified by means of service and data
contracts. Exiting applications are analysed, changes to the design to expose
the required activity services are made and related coding and testing
activities are conducted.

• If analysis reveals that existing application cannot expose the required

service or other consideration require the development of new
applications, then the activity services are realized through analysis, design,
coding and testing steps in OOAD Process
• Sub – Process B Business Development.
The business process model specifies the workflows that may be expressed in
BPEL. configured and orchestrated to generate the business process services. A
Product that provides process orchestration capabilities is typically used as the
basis for the development of these services. (Referred Type – B service in
Strawman Architecture)
• Sub – Process C Client Service Development
Client services may expose functionality to both clients/parents and enterprise
users to meet two different kind of requirements:
1. Fine_ grained services are independent, self-contained, single responsibility,
each running in own process and communicating with lightweight APIs
providing specific business data. These are micro services.
2. Course-grained services that aggregate the content from other
services(activity, business process and data) to provide the enterprise view of
business to users. These users typically need an enterprise view of business
through dash-board, portal or CRM infrastructure.
• Sub-process D – Data Service Development
As organizations mature and bring alignment to business and IT and migrate
to service model of the enterprise. The first step in the development of the
data service is the creation of an enterprise data model after analysis of the
business process model.
Data services (referred to as type D service in Strawman Architecture are then
defined to store and access the core data in the enterprise(e.g those required
to provide the single view of customer). The rest of the steps in this sub-
process involves identification of tools, analysis, design, coding and testing of
data services.
 SOA Methodology for Enterprise
SOA methodology describes the how of the different process that need
implementation in a project context. Several approaches such as incremental/
iterative and agile can be chosen depending on the business and IT
consideration of the enterprise.
SOA methodology based on the incremental/ Iterative approach is shown in
the figure 9.5.

SOA methodology includes six overlapping phases to develop the SOA layers
identified for the enterprise.
1. Initial Phase
The initial phase results in Enterprise SOA Strategy (TO-BE) which SOA blue
Print.
2.SOA blueprint phase
In this phase SOA architecture for enterprise is defined and approval obtained from
the senior management.
3. Service enablement.
This phase involves development of services layer, service component layer,
Operations system layer, information and consumer layer in an iterative manner.
4. Service Integration Phase
The ESB and associated integration layer components are implemented in the
service integration phase.
5. Service Orchestration phase.
The process service are developed and the services(activity, client and data services)
developed in the earlier phase are orchestrated with a process execution engine.
6. Service Governance.
The governance and Quality of Service (QOS) are developed and service monitoring,
design time and run time governance processes put in.
CONSIDERRATION FOR SERVICE ORIENTED APPLICATIONS
Service oriented Model Consideration
1.Service exposed or consumed:
Activity, business process, client or data services that software application exposes or consumes need to be
identified.
2.Granularity of service exposed or consumed:
The granularity of service exposed must be at the right level effective integration and service orchestration.
3. Integration model of service exposed and consumed:
Enterprise service bus, API Gateway, and other pattern of integration are to be considered.
4. Business Process Model:
Business process model of the enterprise and specific business process implemented by the application
must be taken into account.
5. Enterprise data Model:
Data model for the application must be align with enterprise data models that may have been defined at
the organization level.
6.Governance:
Authentication and authorization pattern for service security and solution for design time and run-time
governance (including technologies for service registry and repository) are to be considered
The above consideration may be grouped under four categories:
1.Service Enablement
2. Service Integration
3. Service Orchestration & Choreography;
4. Service governance

Service Enablement:
The type of services, their granularity and technology used for service
enablement have a bearing on the extend to which services are reused, one
of the dimensions of SOA. Hence these consideration include:
1.Identification of service exposed or consumed: Activity, business process,
client or data service that application exposes or consumes must be identified
to maximize reuse.
Selection of technologies for service enablement:
Choice of XML web service or RESTfull web service needs to be making in
mind their relative Pros and Cons.

Service Integration
For service providers and consumers to effectively communicate with one
another, the concern of integration, another dimension of SOA must be
addressed by :
1. Identifying patterns for integration of service exposed or consumed,
2. Selecting the technologies that implement the patterns for integration :
several technology provide offer product that implement various
integration pattern. A careful selection of products will ensure trade-offs
are addressed appropriately.
Service orchestration and Choreography:
The third business transformation dimension for SOA, agility requires
orchestration & choreography of business process based on services defined.
The following must be considered to implement orchestration in several
business application.
1. Business process model: Business process model of the enterprise and the
specific business processes implemented by the application
2. Work flow: The human task based on workflow and automated workflows
involved in business processes that may either be orchestrated with a
central coordinator, such as workflow engine or orchestration engine or
choreographed by implementing the design logic for service invocation in
distributed manner in each of the services.
3. Enterprise data model: Data model for the application aligned with
enterprise data model that may have been defined at theorganization
level.
Service Governance:
In order that the services that are exposed/ consumed fulfil the service level
requirements, the following must be considered.
1. Design time service governance through use of service registry and
repository.
2. Run time service governance though the service level monitoring and
policy enforcement.
Security is one of key non-functional requirements for any application model
and this is true for service-oriented applications as well. To ensure the
security in service oriented application.
3. The nature of authentication, authorization, and other security
mechanisms have to be identified.
4. Products and solutions that support security have to be implemented.
 PATTERNS FOR SOA
Patterns for Service Enablement:
Patterns for service enablement may be applied to expose the functionality as
a service and also consume remote services. The pattern include the
following
1.Service Layer: Encapsulate applications business logic and controlling
transactions and coordinates responses with interfacing layers.
2.Service Proxy: Interface to the service consumer use to call the service.
When an external service needs to be called by a service consumer, this
pattern is used.
3.Service Gateway: Abstracts access to the functionality of a system(or
application) to an interface. When a service provider wishes to hide the
complexities of implementation and publish an interface then this patten is
used.
Pattern for Service Integration
Service integration pattern constitute the solution for the problem of
integrating service providers and service consumers. The major patterns for
service integration are:
1. Enterprise Service Bus: Mediation pattern for service communication,
transformation and integration.
2. Service Adaptor : Mechanism that allows systems that are not service
oriented to participate in SOA.
3. API Gate way: Single entry point for all clients to route requests to the
appropriate service or multiple services.
Patterns for Service Orchestration and Choreography
Service orchestration may be employed to orchestrate service exposed with
in an application context or across the application. The following are the key
patterns for service orchestration.
1. Orchestration Language: Pattern to specify activities of business processes
through a process definition language.
2. Orchestration Engine: Pattern to co-ordinate execution of activities of
business
3. Choreography Language : Pattern to specify from a global view point,
common and complementary behaviour for peer-to-peer collaboration
among services through exchange of order messages.
4. Compensating action: It is a pattern to cancel the effects of selected
actions with in an orchestration
Pattern for service Governance
Service Governance pattern enable design-time and run time governance.
From service oriented application perspective, the following are the key
patterns:
1. The validation Pattern: Design time governance pattern.
The introduction of services, their modules over the life time, until being
retired, must be managed based on set of policies and procedures in the
enterprise. The validation pattern address governance related design time
aspects of services. It can be implemented using service registry that
maintains the catalog of services and manages their life cycle, and a service
repository that holds the policies, rules and restrictions that may be applied
at the time of use of services.
The validation pattern may be implemented using service management tool
in conjunction with service registry and repository.
2. The Management Pattern : Run time monitoring and Policy enforcement
pattern.
The monitoring of execution of services and enforcement of policies ensures
that service level requirements in terms of security, performance throughput
and availability are met.
 Pattern based Architecture for Service-oriented
Applications
Reference Model of Service oriented Java EE Application.
Figure 10-1 shows the logical organization of a thin client web-based Java EE
application as layers.
A thin client Java EE application can be addressed using the model-view-
controller (MVC) pattern.
The request from the browser is passed to the controller, which then passes
the request to the classes implementing the model. The model calls the
classes implementing the session façade pattern. The MVC pattern may be
implemented with JSP, Servlets and JavaBean objects.
Other patterns such as model-view-view model (MVVM) may also be
considered for presentation layer and implemented with technologies such as
HTML, CSS and JavaScript.
• In order to optimize performance of the software application, the session façade
pattern is retained as the pattern to encapsulate the business logic and to decouple it
from the presentation layer.
Business Layer:
The business layer implements business processes in business components whose
implementation could include Java objects, Enterprise JavaBeans (EJBs) and
workflow/rule engine internal to the application.
Data access layer:
The data access layer connects to database using a persistence mechanism. The data
access objects wrap access to the persistence objects. The data access mechanism may
be implemented using any of the following technology options:
1. Java Database Connectivity (JDBC);
2. Object-Relational Mapping (ORM) tools (e.g., Hibernate);
3. Java Persistence API (JPA).
• A services layer
• A services layer is introduced in the reference model of a service-oriented
application based on the services layer SOA pattern described earlier to separate
the concerns of service orientation from those of the business layer.
• The service gateway pattern has been brought in as part of the services layer to
address the need for external applications to access services (e.g., activity services)
exposed by the application.
• This pattern helps to decouple the processing required to satisfy the requirements
related to security and communication.
• Service gateway interacts with a service exposed by the application.
• Gateway provides an interface for external applications to call the services exposed
by the application.
• Another pattern, service proxy, has also been introduced as part of the services
layer in order to represent each external service with proxy object that the
business layer uses to access the external service.
• The service proxy implements an interface that handles parameter passing, calling
the actual service and returning the results .
• Additional concerns such as security and communication may also be handled by
the service proxy class.
• In order to support asynchronous capabilities, a service activator pattern is used in
services layer to trigger processing on the arrival of asynchronous messages from
ESB.
• Message Driven Bean (MDB) is a component specified in Java EE to implement
asynchronous processing and invoke the component that implements the session
façade pattern.
• An enterprise service bus (ESB) pattern is used for service communication,
mediation, transformation, and integration. The ESB products from technology
providers have several capabilities to transform data and protocols for different
service providers and consumers.
• The orchestration engine pattern is used for Business Process layer to orchestrate
externalized business processes and workflows that are described using an
orchestration language such as Business Process Execution Language (BPEL).
• The governance layer and quality of service layers address concerns related to
policies for governance and enforcing them along with ensuring non-functional
requirements are met. The validation pattern in governance layer is used for
design-time governance for publishing services exposed by service provider
applications, managing different versions of services, retiring when not needed by
the enterprise and also to specify the policies and procedures for the use of
services published in the enterprise.

• The management pattern in quality of service layer enables run-time governance

of services through monitoring of service execution and policy enforcement to
ensure that the service level requirements are met
 Logical Architecture (Java EE Application)

• The reference model in Figure 10-1 may be implemented by appropriate choice of

software elements that are integral to Java EE platform. This results in the
reference logical architecture for service-oriented Java EE application shown in
Figure 10-2
Presentation layer
• The logical architecture shows the presentation layer with Servlets, JSPs and The
presentation layer may also be developed with Java frameworks, such as JSF, that
implement the MVC design pattern.
• The current trend is to develop presentation layer using HTML, CSS and supporting both
web and mobile channels.
Business layer
• JavaScript for The patterns in the business layer are best implemented with session beans,
which are Enterprise JavaBeans (EJBs) and Java objects that are deployed in the EJB
container.
Services layer
• In order that performance be optimal, the patterns in the services layer are also
implemented with EJBs and Java objects and container.
Integration layer
• The pattern for integration layer, namely the Enterprise Service Bus (ESB), is often
implemented with products for service integration and process integration. The ESB
enables integration of services by being a mediator between service providers and service
consumers and undertakes the following processes.
1. transforms message formats;
2. routes messages;
3. augments message content and converts transport protocols;
4.notifies registered message listeners about specific message requests.

Products that implement the ESB are available from:

1.Application Server Vendors (e.g., IBM Integration Bus)
2. ERP vendors (e.g., SAP PI);
3. Middleware vendors (e.g., Fiorano ESB);
4. Open Source (e.g., WSO2, ServiceMix, Mule).

Business Process layer

The orchestration engine in Business Process layer enables process integration through
orchestrating cross-application services . Business process orchestration (a key element of
business process management) allows for externalization of those individual processes that were
traditionally hardwired in individual applications.

The orchestration engines allow such business processes to be “long running" in that they may
run for days, weeks or months.

For this reason, these business processes are also referred to as workflows. Business process
orchestration, therefore, enables a configuration-based approach to automate and streamline
business processes for an organization. This brings agility to the enterprise.
The Governance layer and quality of service layer
• The governance layer enables service governance through policy specification
while the quality of service layer enforces governance including addressing non-
functional requirements such as security. Authentication/authorization patterns
may be implemented by specific products that implement identity management
and access management (e.g., IBM Tivoli Identity Management and Tivoli Access
Management).

• Service registry and service repository solutions implement validation and

management patterns and several products may be considered for implementing
the same (e.g., IBM WebSphere Registry & Repository, WSO2 Governance Registry,
etc.).
• Specialized governance tools have 2 become available that offer comprehensive
design-time and run-time governance (e.g., Oradea Business Transaction
Management, HP SOA Systinet).
 Reference Model of Service-Oriented .NET Application

• Figure 10-3 shows the logical organization of a thin client .NET application as
layers. It depicts reference model for a layered web-based service-oriented .NET
application.
Presentation layer
• Presentation layer shown in the reference model include the MVC pattern to
address the user interface concerns of the application .
• Other patterns such as model-view-presenter (MVP) and model-view-viewmodel
(MVVM) can also be applied to address the concerns of presentation layer.
ASP .NET, with the three programming modes (ASP. NET Web Pages, ASP.NET MVC
and ASP.NET Web Forms), handles HTTP requests and implements the presentation
layer.
Business layer
• The service interface pattern wraps the functionality of business layer. The
presentation layer and integration layer are decoupled from the business layer
using this pattern. It supports multiple transports such as Web Services, MSMQ
etc. and hence the same functionality can be exposed to different types of clients
by the use of service interface pattern.
• Windows Communication Foundation (WCF) or ASP.NET Web API may be used to
implement the service interface pattern.
• Alternatively, the service interface pattern may also be implemented by a .NET
component and is recommended when decoupling presentation layer from
business layer.
• Windows Workflow Foundation(WF) is an option for implementing human tasks
based workflows internal to the application.
Data access layer
• The data access components encapsulate access to the databases. ADO. NET, LINQ
to SQL and Entity Framework provide mechanisms for different operations on
databases and can be used by for data access components for efficient access.
The following description of services layer and integration layer is common to Java EE and NET
service-oriented applications.
Service Layer
A services layer is introduced in the reference model of a service-oriented application based on
layer SOA pattern described earlier to separate the concerns of the service orientation from those
of business layer.

The service gateway pattern has been brought in as of the services layer to address the need for
external applications to access services (e.g., activity services) exposed by application. This pattern
helps to decouple the processing required, to satisfy the requirements laid out by the application
related to security and communication.
Gateway provides an interface for external applications to call the services exposed by the
application.
Another pattern, service proxy, has been introduced as part of the services layer in order to
represent each external service with proxy object that the business layer uses to access the
external service.
he service proxy implements an interface that handles parameter passing, calling the actual Service
and returning results. Additional concerns such as security and communication may also be
handled by the service proxy class.
• In order to support asynchronous capabilities, an asynchronous design pattern is
used in the services layer to trigger processing on the arrival of asynchronous
messages from ESB. A.NET component may be used to implement asynchronous
processing and invoke the component that implements.

Integration layer

The integration layer is meant to establish connectivity with external systems and
messaging infrastructure essential for the service oriented applications.
An enterprise service bus (ESB) pattern is used for service communication,
mediation, transformation, and integration. The ESB products from technology
providers have several capabilities to transform data and protocols for different
service providers and consumers
Business Process layer
The orchestration engine is used for Business Process layer to orchestrate externalized business
processes and workflows that are described using an orchestration language such as BPEL.
Governance and quality of service layers
• The governance and quality of service layers, as in the case of Java EE application,
address concerns of service security and policies for governance and enforcing
them along with ensuring non-functional requirements.
• The validation pattern in governance layer is used for design-time governance for
publishing services exposed by service provider applications, managing different
versions of services, retiring when not needed by the enterprise and also to specify
the policies and procedures for the use of services published in the enterprise.
• The management pattern in quality of service layer enables run-time governance
of services through monitoring of service execution and policy enforcement to
ensure that the service level requirements are met.
 Logical Architecture(.NET Application )
• This results in the reference logical architecture for service oriented .NET
application shown in Figure 10-4.
The Integration layer
• The pattern for integration layer, namely the ESB, is often implemented with
products for service integration and process integration. Microsoft BizTalk with ESB
Toolkit provides the capabilities for service and process integration. The ESB
enables integration of services by being a mediator between service providers and
service consumers. It does the following:

• 1. transforms message formats;

• 2. routes messages;
• 3. augments message content and converts transport protocols;
• 4. notifies registered message listeners about specific message requests.
Business Process layer
• The orchestration engine in Business Process layer, as in the case of Java EE
application, enables process integration through orchestrating cross-application
services.
• Business process orchestration (a key element of business process management)
allows for externalization processes that were traditionally hard-wired in each of
the applications.
• In doing so, it has not only been possible to make the processes configurable
through BPEL, that most providers of orchestration engines support, but also
define business processes that can be realized through invocation of services
across multiple applications.
• Additionally, the orchestration engines allow such business processes to be 'long
running' in that they may run for days, weeks or months.
• One of the options implement long running workflows is to use the BPEL based
orchestration engine in BizTalk)
• The governance and quality of service pattern and technologies discussed for SOA
application for JAVA EE also applicable to Microsoft .NET platform.
• Authentication, authorization patterns may be implemented by specific products
that implement identity management and access management (e.g., Microsoft
Active Directory, CA Siteminder, IBM Tivoli Tivoli Access Management).
• Service registry and service repository solutions implement validation and
management patterns and several products may be considered for implementing
the same (e.g., IBM WebSphere Registry & Repository, WSO2 Governance Registry,
etc.)
• Specialized governance tools have also become available that provide
comprehensive design-time and run-time governance (e.g., Oracle Pack, HP SOA
Systinet).
 COMPOSITE APPLICATIONS
• A logical next step to developing applications that expose and consume services is
to develop an application that is built by combining multiple services. Such
applications is called as composite applications.
• A composite application can be developed by aggregation of other services or
orchestration of a stateful sequence of service invocations.
• Examples of composite applications include portal solutions that involve mashup
of aggregated content received from many services and workflow solutions to
enable business process management.
• WS-CAF(Web Services Composite Application Framework ) is a web services standard for composite
applications.
Composite application development involves the following:

1. services of right granularity that can be basis for building larger services;
2. configurable mechanisms for composition of services;
3. metadata repository for reusability;
4. assembly of services.
 COMPOSITE APPLICATION PROGRAMMING MODEL
• Implementation of a composite application based on the principles of SOA includes the
following:
• 1. Configuration: This can be achieved through declarative programming techniques.
• 2. Composition: The techniques to combine services through aggregation and
orchestration enable composition.
• 3. Customization: It is the ability to modify or enhance capability of a service without
change to the service interface definitions.
Service Component Architecture (SCA)

SCA is a set of specifications which describe a model for building applications based on
assembly of service components (or services).
SCA abstracts a service without tightly coupling with the details of the implementation
SCA also defines Service Data Object (SDO) to represent business data and to provide
uniform access regardless of the underlying data storage/model. The key aspects of SCA
are shown in Figure 10-5.
• The basic artefact in SCA is the module, which can be deployed in an SCA run-time
environment. SCA run-time is a framework (e.g., Apache Tuscanny) that includes
run-time support for components such as BPEL orchestration engine, service
registry, etc.
• The scope of SCA run-time corresponds to the SCA Domain. A module within an
SCA Domain specifies services which can be accessed remotely. Module holds one
or more components that contain business functionality.
• SCA components may be implemented using different technologies such as EJBs,
Java objects, BPEL and Spring Beans.
• SCA components can invoke applications outside SCA run-time (specified
declaratively as imports) or alternatively be invoked by non-SCA clients (specified
declaratively as exports)
• At development time, the SCA components can be composed by defining
references. The run-time characteristics (e.g., asynchronous/synchronous
invocation) of the components can also be specified.
• SCA run-time environment implements the run-time behavior on the basis of the
characteristics specified. Thus, the composite application may be implemented
using the SCA programming model.