Service Oa Unit II

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


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


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


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.


5/61


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.


6/61


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/61


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.


8/61


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.


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


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.


11/61


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


12/61


13/61


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.


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


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.


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)


17/61


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.


18/61


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


19/61


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


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.


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).


22/61


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.


23/61


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.


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.


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.


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.


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


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.


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.


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.


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.


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.


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.


34/61



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.


35/61


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.


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.


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


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.


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


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.


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.


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.


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.


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.


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.


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.


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.


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.


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.


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


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


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.


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


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


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.


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.


57/61


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.


58/61


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).


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.


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


61/61

THANK YOU

Documents

Service Oa Unit II