Post on 14-Apr-2018
transcript
7/29/2019 Service Oa Unit II
1/61
UNIT II
Based on
Service-Oriented Architecture: Concepts,
Technology, and DesignBy
Thomas Erl
Prepared By
S.Usha & J.Jeyalakshmi
Lecturer / Department of InformationTechnology
Rajalakshmi Engineering College
7/29/2019 Service Oa Unit II
2/61
Web services - Framework
The Web services framework is characterized by: an abstract (vendor-neutral) existence defined by standards
organizations and implemented by (proprietary) technologyplatforms
core building blocks that include Web services, servicedescriptions, and messages
a communications agreement centered around servicedescriptions based on WSDL
a messaging framework comprised of SOAP technology andconcepts
a service description registration and discovery architecturesometimes realized through UDDI
a well-defined architecture that supports messaging patterns andcompositions a second generation of Web services extensions
7/29/2019 Service Oa Unit II
3/61
Web services - Framework
Services in real world automation solutionsrequires the use of a technology capable ofpreserving fundamental service-orientation,while implementing real world business
functionality. Web services framework is flexible and adaptable.
Web services can be designed to duplicate thebehavior and functionality found in proprietarydistributed systems
This flexibility has allowed Web services to becomepart of many existing application environments andhas been one of the reasons behind their popularity
7/29/2019 Service Oa Unit II
4/61
Web services - Roles
Service roles
Service provider
The service provider role is assumed by a Web
service under the following conditions:
The Web service is invoked via an external source,
such as a service requestor
The Web service provides a published service
description offering information about its features
and behavior.
7/29/2019 Service Oa Unit II
5/61
Web services - Roles
Service requestor Any unit of processing logic capable of issuing a
request message that can be understood by theservice provider is classified as a service requestor. A
Web service is always a service provider but also canact as a service requestor.
A Web service takes on the service requestor roleunder the following circumstances:
The Web service invokes a service provider by sending it amessage.
The Web service searches for and assesses the mostsuitable service provider by studying available servicedescriptions.
7/29/2019 Service Oa Unit II
6/61
Web services - Roles
Intermediaries Web services and service agents that route and
process a message after it is initially sent and beforeit arrives at its ultimate destination are referred to as
intermediaries or intermediary services. two types of intermediaries
passive intermediary, is typically responsible for routingmessages to a subsequent location
active intermediaries also route messages to a forwardingdestination. Prior to transmitting a message, however, these
services actively process and alter the message contents.Typically, active intermediaries will look for particular SOAPheader blocks and perform some action in response to theinformation they find there.
7/29/2019 Service Oa Unit II
7/61
Web services - Roles
Initial sender and ultimate receiver
Initial senders are simply service requestors
that initiate the transmission of a message.
Therefore, the initial sender is always the firstWeb service in a message path. The
counterpart to this role is the ultimate
receiver. This label identifies service providers
that exist as the last Web service along a
message's path.
7/29/2019 Service Oa Unit II
8/61
Web services - Roles
Service compositions
As the name suggests, this particular term
does not apply to a single Web service, but to
a composite relationship between a collectionof services. Any service can enlist one or
more additional services to complete a given
task.
7/29/2019 Service Oa Unit II
9/61
Web Services Service Models
Service models
The manner in which services are being utilized in the real world, though, has ledto a classification based on the nature of the application logic they provide, aswell as their business-related roles within the overall solution. Theseclassifications are known as service models.
Business services are used within SOAs as follows:
as fundamental building blocks for the representation of business logic
to represent a corporate entity or information set to represent business process logic
as service composition members
Utility services are used within SOAs as follows:
as services that enable the characteristic of reuse within SOA
as solution-agnostic intermediary services
as services that promote the intrinsic interoperability characteristic of SOA as the services with the highest degree of autonomy
Controller services are used within SOAs as follows:
to support and implement the principle of composability
to leverage reuse opportunities
to support autonomy in other services
7/29/2019 Service Oa Unit II
10/61
Service descriptions (with WSDL)
Service Description are used to establish aconsistently loosely coupled form ofcommunication between services
implemented as Web services. Description documents are required to
accompany any service wanting to act asan ultimate receiver. The primary servicedescription document is the WSDLdefinition.
7/29/2019 Service Oa Unit II
11/61
Service descriptions (with WSDL)
Service endpoints and service descriptions
A WSDL describes the point of contact for aservice provider, also known as the service
endpoint or just endpoint.A WSDL service description (also known as
WSDL service definition or just WSDLdefinition) can be separated into two
categories: abstract description
concrete description
7/29/2019 Service Oa Unit II
12/61
7/29/2019 Service Oa Unit II
13/61
Service descriptions (with WSDL)
Metadata and service contracts
Three separate documents that eachdescribe an aspect of a service:
WSDL definition
XSD schema
policy
Each of these three service descriptiondocuments can be classified as service
metadata. Service description documents can be
collectively viewed as establishing a servicecontract set of conditions that must be metand accepted by a potential servicerequestor to enable successfulcommunication.
A service contract can refer to additionaldocuments or agreements not expressed by
service descriptions. For example, a ServiceLevel Agreement (SLA) agreed upon by therespective owners of a service provider andits requestor can be considered part of anoverall service contract.
Semantic descriptions
Examples of service semantics include: how a service behaves under certain
conditions
how a service will respond to a specificcondition
what specific tasks the service is most suitedfor
Most of the time service semantics areassessed by humans, either verbally bydiscussing the qualities of a service with itsowner, or by reading supplementarydocumentation published alongside servicedescriptions.
The ultimate goal is to provide sufficientsemantic information in a structured mannerso that, in some cases, service requestorscan go as far as to evaluate and choosesuitable service providers independently.
7/29/2019 Service Oa Unit II
14/61
Service description advertisement
and discovery The sole requirement for one service to contact another
is access to the other service's description.
As the amount of services increases within and outsideof organizations, mechanisms for advertising and
discovering service descriptions may become necessary. For example, central directories and registries become
an option to keep track of the many service descriptionsthat become available.
These repositories allow humans (and even servicerequestors) to: locate the latest versions of known service descriptions
discover new Web services that meet certain criteria
7/29/2019 Service Oa Unit II
15/61
Service description advertisement and
discovery Private and public registries
UDDI specifies a relatively acceptedstandard for structuring registries thatkeep track of service descriptions
Public registries accept registrationsfrom any organizations, regardless ofwhether they have Web services tooffer. Once signed up, organizations
acting as service provider entities canregister their services.
Private registries can be implementedwithin organization boundaries toprovide a central repository fordescriptions of all services theorganization develops, leases, orpurchases.
Business entities and business services
Each public registry record consists ofa business entity containing basicprofile information about theorganization (or service provider entity).Included in this record are one or morebusiness service areas, each of whichprovides a description of the servicesoffered by the business entity.Business services may or may not berelated to the use of Web services.
Binding templates and tModels
An interface definition that existedindependently from the transportprotocols to which it was eventuallybound. Registry records follow thesame logic in that they store binding
information in a separate area, calledthe binding template.
Each business service can referenceone or more binding templates. Theinformation contained in a bindingtemplate may or may not relate to anactual service. For example, a bindingtemplate may simply point to theaddress of a Web site. However, if aWeb service is being represented, thenthe binding template references atModel.
7/29/2019 Service Oa Unit II
16/61
Messaging with SOAP Messages - SOAP specification's main
purpose is to define a standard messageformat
Envelope, header, and body
Every SOAP message ispackaged into a container knownas an envelope. Much like themetaphor this conjures up, theenvelope is responsible forhousing all parts of the message
Each message can contain aheader, an area dedicated tohosting meta information. In mostservice-oriented solutions, thisheader section is a vital part of theoverall architecture, and thoughoptional, it is rarely omitted. Itsimportance relates to the use ofheader blocks through which
numerous extensions can beimplemented
The actual message contents arehosted by the message body,which typically consists of XMLformatted data. The contents of amessage body are often referredto as the message payload.
Header blocks
Message independence isimplemented through the use of headerblocks, packets of supplementary metainformation stored in the envelope'sheader area. Header blocks outfit amessage with all of the informationrequired for any services with which themessage comes in contact to processand route the message in accordance
with its accompanying rules,instructions, and properties.
Examples of the types of features amessage can be outfitted with using headerblocks include:
processing instructions that may beexecuted by service intermediaries orthe ultimate receiver
routing or workflow informationassociated with the message
security measures implemented in themessage
reliability rules related to the delivery ofthe message
context and transaction managementinformation
correlation information (typically an
identifier used to associate a requestmessage with a response message)
7/29/2019 Service Oa Unit II
17/61
Service description advertisement and
discovery - Messages Message styles
The SOAP specification was originallydesigned to replace proprietary RPCprotocols by allowing calls betweendistributed components to be serialized intoXML documents, transported, and thendeserialized into the native component formatupon arrival. As a result, much in the originalversion of this specification centered aroundthe structuring of messages to accommodate
RPC data. This RPC-style message runs contrary to the
emphasis SOA places on independent,intelligence-heavy messages. SOA relies ondocument-style messages to enable largerpayloads, coarser interface operations, andreduced message transmission volumesbetween services.
Attachments To facilitate requirements for the delivery of
data not so easily formatted into an XMLdocument, the use of SOAP attachmenttechnologies exist. Each provides a differentencoding mechanism used to bundle data inits native format with a SOAP message.SOAP attachments are commonly employedto transport binary files, such as images.
Faults SOAP messages offer the ability to add
exception handling logic by providing anoptional fault section that can reside within thebody area. The typical use for this section isto store a simple message used to delivererror condition information when an exceptionoccurs.
7/29/2019 Service Oa Unit II
18/61
Service description advertisement and
discovery - Nodes Nodes
Every major platform has its ownimplementation of a SOAPcommunications server, and as a resulteach vendor has labeled its ownvariation of this piece of softwaredifferently. In abstract, the programsthat services use to transmit andreceive SOAP messages are referredto as SOAP nodes
Node typesSOAP nodes are given labels that identifytheir type, depending on what form ofprocessing they are involved with in a givenmessage processing scenario.
The SOAP specification has a differentuse for the term "role" and insteadrefers to these SOAP types or labels asconcepts.
SOAP sender - SOAP node thattransmits a message
SOAP receiver - SOAP node thatreceives a message
SOAP intermediary - a SOAP node thatreceives and transmits a message, andoptionally processes the message priorto transmission
initial SOAP sender - the first SOAP
node to transmit a message ultimate SOAP receiver - the last
SOAP node to receive a message
SOAP intermediaries
The same way service intermediariestransition through service provider andservice requestor roles, SOAPintermediary nodes move throughSOAP receiver and SOAP sendertypes when processing a message
SOAP nodes acting as intermediariescan be classified as forwarding oractive. When a SOAP node acts as aforwarding intermediary, it isresponsible for relaying the contents ofa message to a subsequent SOAPnode.
Active intermediary nodes aredistinguished by the type of processingthey perform above and beyondforwarding-related functions. An activeintermediary is not required to limit itsprocessing logic to the rules andinstructions provided in the headerblocks of a message it receives. It canalter existing header blocks, insert newones, and execute a variety of
supporting actions
7/29/2019 Service Oa Unit II
19/61
Service description advertisement and
discovery Message Paths
Message paths
A message path refers to the route taken by amessage from when it is first sent until it
arrives at its ultimate destination.A message path refers to the route taken by a
message from when it is first sent until itarrives at its ultimate destination. Therefore, a
message path consists of at least one initialsender, one ultimate receiver, and zero ormore intermediaries
7/29/2019 Service Oa Unit II
20/61
Message exchange Patterns
Message exchange patterns (MEPs)represent a set of templates that provide agroup of already mapped out sequences
for the exchange of messages. The mostcommon example is a request andresponse pattern. Here the MEP statesthat upon successful delivery of a
message from one service to another, thereceiving service responds with amessage back to the initial requestor.
7/29/2019 Service Oa Unit II
21/61
Message exchange Patterns -
Primitive MEPs Before the arrival of contemporary SOA,
messaging frameworks were already well usedby various messaging-oriented middlewareproducts. As a result, a common set of primitive
MEPs has been in existence for some time. Request-response
The request-response MEP establishes a simpleexchange in which a message is first transmitted froma source (service requestor) to a destination (service
provider). Upon receiving the message, thedestination (service provider) then responds with amessage back to the source (service requestor).
7/29/2019 Service Oa Unit II
22/61
Message exchange Patterns -
Primitive MEPs
Fire-and-forget This simple asynchronous pattern is based on the
unidirectional transmission of messages from asource to one or more destinations
A number of variations of the fire-and-forget MEPexist, including:
The single-destination pattern, where a source sends amessage to one destination only.
The multi-cast pattern, where a source sends messages to a
predefined set of destinations. The broadcast pattern, which is similar to the multi-cast
pattern, except that the message is sent out to a broaderrange of recipient destinations.
7/29/2019 Service Oa Unit II
23/61
Message exchange Patterns -
Complex MEPsPrimitive MEPs can be assembled in various configurations to create different
types of messaging models, sometimes called complex MEPs.
publish-and-subscribe model.
The publish-and-subscribe pattern introduces new roles for the servicesinvolved with the message exchange. They now become publishers andsubscribers, and each may be involved in the transmission and receipt of
messages. This asynchronous MEP accommodates a requirement for apublisher to make its messages available to a number of subscribersinterested in receiving them.
The steps involved are generally similar to the following:
Step 1. The subscriber sends a message to notify the publisher that it wantsto receive messages on a particular topic.
Step 2. Upon the availability of the requested information, the publisherbroadcasts messages on the particular topic to all of that topic's
subscribers.
7/29/2019 Service Oa Unit II
24/61
MEP and SOAP, WSDL
MEPs and SOAP The SOAP standard provides a messaging framework designed to support single-direction
message transfer. The extensible nature of SOAP allows countless messagingcharacteristics and behaviors (MEP-related and otherwise) to be implemented via SOAPheader blocks. The SOAP language also provides an optional parameter that can be set toidentify the MEP associated with a message.
MEPs and WSDL MEPs play a larger role in WSDL service descriptions as they can coordinate the input and
output messages associated with an operation. The association of MEPs to WSDLoperations thereby embeds expected conversational behavior into the interface definition.
WSDL operations support different configurations of incoming, outgoing, and fault messages.These configurations are equivalent to message exchange patterns, but within the WSDLspecification, they often are referred to simply as patterns. It is important to note that WSDLdefinitions do not restrict an interface to these patterns; they are considered minimalconversational characteristics that can be extended.
In WSDL 1.1 terms, they are represented as follows: Request-response operation Upon receiving a message, the service must respond with a standard
message or a fault message. Solicit-response operation Upon submitting a message to a service requestor, the service expects a
standard response message or a fault message.
One-way operation The service expects a single message and is not obligated to respond.
Notification operation The service sends a message and expects no response.
7/29/2019 Service Oa Unit II
25/61
MEP and SOAP, WSDLRelease 2.0 of the WSDL specification extends MEP support to eight patterns (and also changes theterminology) as follows.
The in-out pattern, comparable to the request-response MEP (and equivalent to the WSDL 1.1request-response operation).
The out-in pattern, which is the reverse of the previous pattern where the service provider initiatesthe exchange by transmitting the request. (Equivalent to the WSDL 1.1 solicit-responseoperation.)
The in-only pattern, which essentially supports the standard fire-and-forget MEP. (Equivalent to
the WSDL 1.1 one-way operation.) The out-only pattern, which is the reverse of the in-only pattern. It is used primarily in support of
event notification. (Equivalent to the WSDL 1.1 notification operation.)
The robust in-only pattern, a variation of the in-only pattern that provides the option of launching afault response message as a result of a transmission or processing error.
The robust out-only pattern, which, like the out-only pattern, has an outbound message initiatingthe transmission. The difference here is that a fault message can be issued in response to thereceipt of this message.
The in-optional-out pattern, which is similar to the in-out pattern with one exception. This variationintroduces a rule stating that the delivery of a response message is optional and should thereforenot be expected by the service requestor that originated the communication. This pattern alsosupports the generation of a fault message.
The out-optional-in pattern is the reverse of the in-optional-out pattern, where the incomingmessage is optional. Fault message generation is again supported.
7/29/2019 Service Oa Unit II
26/61
MEPs and SOA
MEPs are highly generic and abstract in
nature. Individually, they simply relate to
an interaction between two services. Their
relevance to SOA is equal to theirrelevance to the abstract Web services
framework. They are therefore a
fundamental and essential part of anyWeb services-based environment,
including SOA.
7/29/2019 Service Oa Unit II
27/61
Coordination
The complexity of an activity can relate to anumber of factors, including:
the amount of services that participate in the activity
the duration of the activity
the frequency with which the nature of the activitychanges
whether or not multiple instances of the activity canconcurrently exist
A framework is required to provide a means for context
information in complex activities to be managed, preservedand/or updated, and distributed to activity participants.
Coordination establishes such a framework
7/29/2019 Service Oa Unit II
28/61
Coordinator composition
WS-Coordination establishes aframework that introduces a genericservice based on the coordinatorservice model This service controls acomposition of three other servicesthat each play a specific part in themanagement of context data.
The coordinator composition consistsof the following services:
Activation service Responsible for thecreation of a new context and forassociating this context to a particularactivity.
Registration service Allows
participating services to use contextinformation received from theactivation service to register for asupported context protocol.
Protocol-specific services Theseservices represent the protocolssupported by the coordinator'scoordination type. (This is further
explained in the next sections.) Coordinator The controller service of
this composition, also known as thecoordination service.
7/29/2019 Service Oa Unit II
29/61
Coordinator composition
Coordination types and coordination protocols Each coordinator is based on a coordination type, which specifies the nature and underlying
logic of an activity for which context information is being managed. Coordination types arespecified in separate specifications. The WS-Coordination framework is extensible and canbe utilized by different coordination types, including custom variations. However, the twocoordination types most commonly associated with WS-Coordination are WS-AtomicTransaction and WS-BusinessActivity.
Coordination type extensions provide a set of coordination protocols, which represent uniquevariations of coordination types and consist of a collection of specific behaviors and rules. Aprotocol is best viewed as a set of rules that are imposed on activities and which allregistered participants must follow.
Coordination contexts and coordination participants
A context created by the activation service is referred to as a coordination context. It containsa collection of information that represents the activity and various supplementary data.
Examples of the type of data held within a coordination context include:
a unique identifier that represents the activity
an expiration value
coordination type information
The activation and registration process
The coordination service composition is instantiated when an application service contacts theactivation service. Via a CreateCoordinationContext request message, it asks the activationservice to generate a set of new context data. Once passed back with the ReturnContextmessage, the application service now can invite other services to participate in thecoordination. This invitation consists of the context information the application serviceoriginally received from the activation service.
7/29/2019 Service Oa Unit II
30/61
Completion Process
The completion process
The application service can request that a
coordination be completed by issuing a
completion request message to thecoordination service. The coordinator, in turn,
then issues its own completion request
messages to all coordination participants.
7/29/2019 Service Oa Unit II
31/61
Coordination and SOA
A coordinator-based context management
framework, as provided by WS-
Coordination and its supporting
coordination types, introduces a layer ofcomposition control to SOAs. It
standardizes the management and
interchange of context information within avariety of key business protocols.
7/29/2019 Service Oa Unit II
32/61
Atomic transactions
Transactions have been around for almostas long as automated computer solutionshave existed. When managing certain
types of corporate data, the need to wrapa series of changes into a single action isfundamental to many business processrequirements. Atomic transactions
implement the familiar commit and rollbackfeatures to enable cross-servicetransaction support.
7/29/2019 Service Oa Unit II
33/61
The atomic transaction process
ACID transactions The term "ACID" is an acronym representing
the following four required characteristics ofa traditional transaction:
Atomic Either all of the changes withinthe scope of the transaction succeed,or none of them succeed. Thischaracteristic introduces the need forthe rollback feature that is responsiblefor restoring any changes completed aspart of a failed transaction to theiroriginal state.
Consistent None of the data changesmade as a result of the transaction canviolate the validity of any associateddata models. Any violations result in arollback of the transaction.
Isolated If multiple transactions occurconcurrently, they may not interferewith each other. Each transaction mustbe guaranteed an isolated executionenvironment.
Durable Upon the completion of asuccessful transaction, changes madeas a result of the transaction cansurvive subsequent failures.
Atomic transaction protocols WS-AtomicTransaction is a coordination type,
meaning that it is an extension created for usewith the WS-Coordination contextmanagement framework
The following primary transaction protocolsare provided:
A Completion protocol, which is typically used toinitiate the commit or abort states of thetransaction.
The Durable 2PC protocol for which servicesrepresenting permanent data repositoriesshould register.
The Volatile 2PC protocol to be used byservices managing non-persistent (temporary)data.
The atomic transaction coordinator When WS-AtomicTransaction protocols are
used, the coordinator controller service canbe referred to as an atomic transactioncoordinator. This particular implementation of
the WS-Coordination coordinator servicerepresents a specific service model. Theatomic transaction coordinator plays a keyrole in managing the participants of thetransaction process and in deciding thetransaction's ultimate outcome.
7/29/2019 Service Oa Unit II
34/61
The atomic transaction process
The atomic transaction process
The atomic transaction coordinator is tasked with the
responsibility of deciding the outcome of a
transaction. It bases this decision on feedback it
receives from all of the transaction participants.
The collection of this feedback is separated into two
phases. During the prepare phase, all participants are
notified by the coordinator, and each is asked to
prepare and then issue a vote. Each participant's voteconsists of either a "commit" or "abort" request.
7/29/2019 Service Oa Unit II
35/61
The atomic transaction process
Atomic transactions and SOA Much of the transactional functionality implemented in
service-oriented solutions is done so among thecomponents that execute an activity on behalf of a
single service. However, as more services emergewithin an organization and as service compositionsbecome more commonplace, the need to movetransaction boundaries into cross-service interactionscenarios increases. Being able to guarantee an
outcome of an activity is a key part of enterprise-levelcomputing, and atomic transactions therefore play animportant role in ensuring quality of service.
7/29/2019 Service Oa Unit II
36/61
Business activities
Business activities govern long-running, complex serviceactivities. Hours, days, or even weeks can pass before abusiness activity is able to complete. During this period,the activity can perform numerous tasks that involve
many participants. What distinguishes a business activity from a regular
complex activity is that its participants are required tofollow specific rules defined by protocols. Businessactivities primarily differ from the also protocol-based
atomic transactions in how they deal with exceptions andin the nature of the constraints introduced by the protocolrules.
7/29/2019 Service Oa Unit II
37/61
Business activities
Business activity protocols WS-BusinessActivity is a coordination
type designed to leverage the WS-Coordination context managementframework. It provides two very similarprotocols, each of which dictates how aparticipant may behave within theoverall business activity.
TheBusinessAgreementWithParticipantCompletion protocol, which allows aparticipant to determine when it hascompleted its part in the businessactivity.
TheBusinessAgreementWithCoordinatorCompletion protocol, which requires that aparticipant rely on the business activitycoordinator to notify it that it has nofurther processing responsibilities.
The business activity coordinator When its protocols are used, the WS-
Coordination controller serviceassumes a role specific to thecoordination type in this case itbecomes a business activitycoordinator
7/29/2019 Service Oa Unit II
38/61
Business activities
Business activity states During the lifecycle of a business activity, the business activity
coordinator and the activity participants transition through aseries of states.
A participant can indicate that it has completed the processing itwas required to perform as part of the activity by issuing a
completed notification. This moves the participant from an activestate to a completed state.
The coordinator may respond with a close message to let theparticipant know that the business activity is being successfullycompleted.
However, if things don't go as planned during the course of abusiness activity, one of a number of options are available.Participants can enter a compensation state during which theyattempt to perform some measure of exception handling.
Alternatively, a cancelled state can be entered. This typically resultsin the termination of any further processing outside of thecancellation notifications that need to be distributed.
7/29/2019 Service Oa Unit II
39/61
Business activities
Business activities and atomic
transactions
It is important to note that the use of a
business activity does not exclude the use ofatomic transactions. In fact, it is likely that a
long-running business activity will encompass
the execution of several atomic transactions
during its lifetime
7/29/2019 Service Oa Unit II
40/61
Business activities
Business activities and SOA Business activities fully complement the composable
nature of SOA by tracking and regulating complexactivities while also allowing them to carry on for longperiods of time. Service autonomy and statelessnessare preserved by permitting services to participatewithin an activity for only the duration they areabsolutely required to. This also allows for the designof highly adaptive business activities wherein theparticipants can augment activity or process logic to
accommodate changes in the business tasks beingautomated. Through the use of the compensationprocess, business activities increase SOA's quality ofservice by providing built-in fault handling logic.
7/29/2019 Service Oa Unit II
41/61
Orchestration
Organizations that already have employed
enterprise application integration (EAI)
middleware products to automate
business processes or to integrate variouslegacy environments will likely already be
familiar with the concept of orchestration.
7/29/2019 Service Oa Unit II
42/61
Orchestration
Business protocols andprocess definition
The workflow logic thatcomprises an orchestrationcan consist of numerousbusiness rules, conditions,
and events. Collectively, theseparts of an orchestrationestablish a business protocolthat defines how participantscan interoperate to achievethe completion of a business
task. The details of theworkflow logic encapsulatedand expressed by anorchestration are containedwithin a process definition.
Process services and partnerservices
Identified and described withina process definition are theallowable process participants.First, the process itself is
represented as a service,resulting in a process service(which happens to be anotherone of our service models.
7/29/2019 Service Oa Unit II
43/61
Orchestration
Basic activities and structuredactivities
WS-BPEL breaks down workflowlogic into a series of predefinedprimitive activities. Basic activities(receive, invoke, reply, throw,wait) represent fundamentalworkflow actions which can beassembled using the logicsupplied by structured activities(sequence, switch, while, flow,pick).
Sequences, flows, and links A sequence aligns groups of related
activities into a list that determines asequential execution order. Sequencesare especially useful when one piece ofapplication logic is dependent on theoutcome of another.
Flows also contain groups of relatedactivities, but they introduce differentexecution requirements. Pieces ofapplication logic can executeconcurrently within a flow, meaning thatthere is not necessarily a requirementfor one set of activities to wait beforeanother finishes.
Links are used to establish formaldependencies between activities thatare part of flows. Before an activity fully
can complete, it must ensure that anyrequirements established in outgoinglinks first are met. Similarly, before anylinked activity can begin, requirementscontained within any incoming links firstmust be satisfied. Rules provided bylinks are also referred to assynchronization dependencies.
7/29/2019 Service Oa Unit II
44/61
Orchestration
Orchestrations andactivities As we defined earlier, an
activity is a generic termthat can be applied to any
logical unit of workcompleted by a service-oriented solution. Thescope of a singleorchestration, therefore,can be classified as a
complex, and most likely,long-running activity.
Orchestration andcoordination Orchestration, as
represented by WS-BPEL,can fully utilize the WS-
Coordination contextmanagement framework byincorporating the WS-Business Activitycoordination type.
This specification definescoordination protocolsdesigned to supportcomplex, long-runningactivities.
7/29/2019 Service Oa Unit II
45/61
Orchestration
Orchestration and SOA Business process logic is at the
root of automation solutions.Orchestration provides anautomation model where processlogic is centralized yet stillextensible and composable.Through the use of orchestrations,service-oriented solutionenvironments become inherentlyextensible and adaptive.Orchestrations themselvestypically establish a common pointof integration for otherapplications, which makes animplemented orchestration a key
integration enabler.
These qualities lead to increasedorganizational agility because:
The workflow logic encapsulatedby an orchestration can bemodified or extended in a centrallocation.
Positioning an orchestrationcentrally can significantly ease themerging of business processes byabstracting the glue that ties thecorresponding automationsolutions together.
By establishing potentially large-scale service-oriented integrationarchitectures, orchestration, on afundamental level, can support theevolution of a diversely federatedenterprise.
7/29/2019 Service Oa Unit II
46/61
Choreography
All organizations would agree on how internal processesshould be structured, so that should they ever have tointeroperate, they would already have their automationsolutions in perfect alignment.
When interoperation requirements extend into the realmof collaboration, where multiple services from differentorganizations need to work together to achieve acommon goal.
The Web Services Choreography Description Language
(WS-CDL) is one of several specifications that attemptsto organize information exchange between multipleorganizations, with an emphasis on public collaboration.
7/29/2019 Service Oa Unit II
47/61
Choreography
Collaboration An important characteristic of
choreographies is that they areintended for public messageexchanges. The goal is toestablish a kind of organizedcollaboration between servicesrepresenting different service
entities, only no one entity(organization) necessarily controlsthe collaboration logic.Choreographies therefore providethe potential for establishinguniversal interoperability patternsfor common inter-organizationbusiness tasks.
Roles and participants Within any given choreography, a Web
service assumes one of a number ofpredefined roles. This establishes whatthe service does and what the servicecan do within the context of a particularbusiness task. Roles can be bound toWSDL definitions, and those relatedare grouped accordingly, categorized
as participants (services). Relationships and channels
Each potential exchange between tworoles in a choreography is thereforedefined individually as a relationship.Every relationship consequentlyconsists of exactly two roles.
Now that we've defined who can talkwith each other, we require a means ofestablishing the nature of theconversation. Channels do exactly thatby defining the characteristics of themessage exchange between twospecific roles.
7/29/2019 Service Oa Unit II
48/61
Choreography
Interactions and work units Interactions are the fundamental
building blocks of choreographiesbecause the completion of aninteraction represents actualprogress within a choreography.
Related to interactions are workunits.
Reusability, composability, andmodularity
Each choreography can bedesigned in a reusable manner,allowing it to be applied todifferent business taskscomprised of the samefundamental actions. Further,
using an import facility, achoreography can be assembledfrom independent modules. Thesemodules can represent distinctsub-tasks and can be reused bynumerous different parentchoreographies
Finally, even though a
choreography in effect composesa set of non-specific services toaccomplish a task,choreographies themselves canbe assembled into largercompositions.
7/29/2019 Service Oa Unit II
49/61
Choreography
Orchestrations andchoreographies An orchestration expresses
organization-specific businessworkflow. This means that anorganization owns andcontrols the logic behind anorchestration, even if that logicinvolves interaction withexternal business partners.
A choreography, on the otherhand, is not necessarilyowned by a single entity. Itacts as a communityinterchange pattern used forcollaborative purposes byservices from differentprovider entities
Choreography and SOA Choreography therefore can
assist in the realization of SOAacross organizationboundaries. While it nativelysupports composability,reusability, and extensibility,choreography also canincrease organizational agilityand discovery. Organizationsare able to join into multipleonline collaborations, whichcan dynamically extend oreven alter related business
processes that integrate withthe choreographies.
7/29/2019 Service Oa Unit II
50/61
Service layer abstraction
Introduction
The service interface layer islocated between the businessprocess and application layers.This is where service
connectivity resides and istherefore the area of ourenterprise wherein thecharacteristics of SOA aremost prevalent. To implementthe characteristics we just
identified in an effectivemanner, some larger issuesneed to be addressed.
We need to answer the following
questions:
What logic should berepresented by services?
How should services relate to
existing application logic? How can services best
represent business processlogic?
How can services be built and
positioned to promote agility?
SLA P bl l d b l i
7/29/2019 Service Oa Unit II
51/61
SLA - Problems solved by layering
services What logic should be represented by
services?
Enterprise logic can be divided into twoprimary domains: business logic andapplication logic. Services can bemodeled to represent either or bothtypes of logic, as long as the principlesof service-orientation can be applied.
However, to achieve enterprise-wide
loose coupling physically separatelayers of services are, in fact, required.
When individual collections of servicesrepresent corporate business logic andtechnology-specific application logic,each domain of the enterprise is freedof direct dependencies on the other.
This allows the automatedrepresentation of business processlogic to evolve independently from thetechnology-level application logicresponsible for its execution.
How should services relate to existingapplication logic?
This is based on
whether existing legacyapplication logic needs to beexposed via services
whether new logic is beingdeveloped in support of services.
Existing systems can impose anynumber of constraints, limitations, andenvironmental requirements
Applying a service layer on top oflegacy application environments mayeven require that some service-orientation principles be compromised.This is less likely when buildingsolutions from the ground up with
service layers in mind, as this affords alevel of control with which service-orientation can be directly incorporatedinto application logic.
Either way, services designedspecifically to represent applicationlogic should exist in a separate layer.We'll therefore simply refer to thisgroup of services as belonging to theapplication service layer.
SLA P bl l d b l i
7/29/2019 Service Oa Unit II
52/61
SLA - Problems solved by layering
services How can services best represent business
logic? Business logic is defined within an
organization's business models andbusiness processes.
When modeling services to representbusiness logic, it is most important toensure that the service representationof this logic is in alignment with existingbusiness models.
It is also useful to separately categorizeservices that are designed in thismanner.
Therefore, we'll refer to services thathave been modeled to representbusiness logic as belonging to thebusiness service layer.
How can services be built and positioned to
promote agility? The key to building an agile SOA is in
minimizing the dependencies eachservice has within its own processinglogic. Services that contain businessrules are required to enforce and actupon these rules at runtime.
This limits the service's ability to beutilized outside of environments thatrequire these rules. Similarly, controllerservices that are embedded with thelogic required to compose otherservices can develop dependencies onthe composition structure.
Introducing a parent controller layer ontop of more specialized service layerswould allow us to establish acentralized location for business rules
and composition logic related to thesequence in which services areexecuted. Orchestration is designedspecifically for this purpose.
It introduces the concept of a processservice, capable of composing otherservices to complete a businessprocess according to predefinedworkflow logic. Process services
establish what we refer to as theorchestration service layer.
7/29/2019 Service Oa Unit II
53/61
Service layer abstraction
Abstraction is the key The one common element to all of the
answers also happens to be the last of our
four outstanding SOA characteristics: layersof abstraction.
The three layers of abstraction we identifiedfor SOA are:
the application service layer the business service layer
the orchestration service layer
7/29/2019 Service Oa Unit II
54/61
Application service layer
The application service layerestablishes the ground levelfoundation that exists to expresstechnology-specific functionality.Services that reside within thislayer can be referred to simply asapplication services. Their
purpose is to provide reusablefunctions related to processingdata within new or legacyapplication environments.
Application services commonlyhave the following characteristics: they expose functionality within a
specific processing context they draw upon available
resources within a given platform
they are solution-agnostic they are generic and reusable
they can be used to achieve point-to-point integration with otherapplication services
they are often inconsistent interms of the interface granularity
they expose they may consist of a mixture of
custom-developed services andthird-party services that havebeen purchased or leased
Typical examples of servicemodels implemented asapplication services include thefollowing: utility service
wrapper service
7/29/2019 Service Oa Unit II
55/61
Application service layer
When a separate business servicelayer exists, there is a strongmotivation to turn all applicationservices into generic utility services.
Alternatively, if business logic does notreside in a separate layer, applicationservices may be required to implementservice models more associated with
the business service layer. Services that contain both application
and business logic can be referred toas hybrid application services or justhybrid services.
An application service also cancompose other, smaller-grainedapplication services (such as proxyservices) into a unit of coarse-grainedapplication logic.
Application services that exist solely toenable integration between systemsoften are referred to as applicationintegration services or simplyintegration services. Integrationservices often are implemented ascontrollers.
Wrapper services most often are
utilized for integration purposes. Theyconsist of services that encapsulate("wrap") some or all parts of a legacyenvironment to expose legacyfunctionality to service requestors. Themost frequent form of wrapper serviceis a service adapter provided by legacyvendors.
Another variation of the wrapperservice model not discussed in thisbook is the proxy service, also knownas an auto-generated WSDL.
7/29/2019 Service Oa Unit II
56/61
Business service layer
While application services are responsible forrepresenting technology and application logic,the business service layer introduces a serviceconcerned solely with representing business
logic, called the business service. Business services are the lifeblood of
contemporary SOA. They are responsible forexpressing business logic through service-
orientation and bring the representation ofcorporate business models into the Webservices arena.
7/29/2019 Service Oa Unit II
57/61
Business service layer
Application services canfall into different types ofservice model categoriesbecause they simplyrepresent a group of
services that expresstechnology-specificfunctionality. Therefore,an application service canbe a utility service, awrapper service, orsomething else.
Business services, on theother hand, are always animplementation of thebusiness service model.The sole purpose of
business servicesintended for a separatebusiness service layer isto represent businesslogic in the purest formpossible. This does not,however, prevent themfrom implementing otherservice models.
7/29/2019 Service Oa Unit II
58/61
Business service layer
Business service layer abstraction leads to the creationof two further business service models: Task-centric business service A service that encapsulates
business logic specific to a task or business process. This typeof service generally is required when business process logic is
not centralized as part of an orchestration layer. Task-centricbusiness services have limited reuse potential.
Entity-centric business service A service that encapsulates aspecific business entity (such as an invoice or timesheet). Entity-centric services are useful for creating highly reusable andbusiness process-agnostic services that are composed by anorchestration layer or by a service layer consisting of task-centricbusiness services (or both).
7/29/2019 Service Oa Unit II
59/61
Orchestration service layer
Orchestration is more valuable to us than a standardbusiness process, as it allows us to directly link processlogic to service interaction within our workflow logic. Thiscombines business process modeling with service-oriented modeling and design.
The orchestration service layer introduces a parent levelof abstraction that alleviates the need for other servicesto manage interaction details required to ensure thatservice operations are executed in a specific sequence.
Within the orchestration service layer, process services
compose other services that provide specific sets offunctions, independent of the business rules andscenario-specific logic required to execute a processinstance.
7/29/2019 Service Oa Unit II
60/61
Orchestration service layer
Therefore, all process services are also
controller services by their very nature, as they
are required to compose other services to
execute business process logic. Processservices also have the potential of becoming
utility services to an extent, if a process, in its
entirety, should be considered reusable.
In this case, a process service that enablesorchestration can itself be orchestrated
7/29/2019 Service Oa Unit II
61/61
THANK YOU