IT2401 unit5

8/10/2019 IT2401 unit5

1/44

UNIT VBased On

Service-Oriented Architecture: Concepts, Technology, andDesign

By

Thomas Erl

Prepared By

N SARAVANAN

Asst. Professor / Department of Information

TechnologyVeltech Multitech Engineering College

8/10/2019 IT2401 unit5

2/44

WS-BPEL basics

The WS-BPEL language is used to demonstrate

how process logic can be described as part of

a concrete definition figure that can be

implemented and executed via a compliantorchestration engine.

8/10/2019 IT2401 unit5

3/44

WS-BPEL basics

A brief history of BPEL4WS and WS-BPEL Business Process Execution Language for Web Services (BPEL4WS) was first conceived in July,

2002, with the release of the BPEL4WS 1.0 specification, a joint effort by IBM, Microsoft, andBEA. This document proposed an orchestration language inspired by previous variations, suchas IBM's Web Services Flow Language (WSFL) and Microsoft's XLANG specification.

Joined by other contributors from SAP and Siebel Systems, version 1.1 of the BPEL4WS

specification was released less than a year later, in May of 2003. This version received moreattention and vendor support, leading to a number of commercially available BPEL4WS-compliant orchestration engines. Just prior to this release, the BPEL4WS specification wassubmitted to an OASIS technical committee so that the specification could be developed intoan official, open standard.

The technical committee is in the process of finalizing the release of the next version ofBPEL4WS. It has been announced that the language itself has been renamed to the WebServices Business Process Execution Language, or WS-BPEL (and assigned the 2.0 version

number). The changes planned for WS-BPEL have been made publicly available on the OASISWeb site at www.oasis-open.org.
http://www.oasis-open.org/http://www.oasis-open.org/http://www.oasis-open.org/http://www.oasis-open.org/http://www.oasis-open.org/http://www.oasis-open.org/http://www.oasis-open.org/http://www.oasis-open.org/http://www.oasis-open.org/

8/10/2019 IT2401 unit5

4/44

WS-BPEL basics

Prerequisites

Concepts relating toorchestration, coordination,atomic transactions, andbusiness activities are covered,and are therefore not repeated

here. The process element

Example A skeleton process definition.

...

...

...

8/10/2019 IT2401 unit5

5/44

WS-BPEL basics

The partnerLinks and partnerLink elements

A partnerLink element establishes the porttype of the service (partner) that will beparticipating during the execution of thebusiness process. Partner services can actas a client to the process, responsible forinvoking the process service. Alternatively,partner services can be invoked by theprocess service itself.

The contents of a partnerLink elementrepresent the communication exchangebetween two partnersthe process servicebeing one partner and another servicebeing the other. Depending on the natureof the communication, the role of theprocess service will vary. For instance, a

process service that is invoked by anexternal service may act in the role of"TimesheetSubmissionProcess."

Example The partnerLinks construct

containing one partnerLink element in

Which the process service is invoked by an

external client partner and four partnerLink

elements that identify partner services

invoked by the process service.

8/10/2019 IT2401 unit5

6/44

WS-BPEL basics

The partnerLinkType element

For each partner service involved in aprocess, partnerLinkType elementsidentify the WSDL portType elementsreferenced by the partnerLinkelements within the processdefinition. Therefore, these

constructs typically are embeddeddirectly within the WSDL documentsof every partner service.

The partnerLinkType constructcontains one role element for eachrole the service can play, as definedby the partnerLink myRole andpartnerRole attributes. As a result, a

partnerLinkType will have either oneor two child role elements.

Example A WSDL definitions construct

containing a partnerLinkType construct.

...

...

8/10/2019 IT2401 unit5

7/44

WS-BPEL basics

The variables element

WS-BPEL process services commonly usethe variables construct to store stateinformation related to the immediateworkflow logic. Entire messages and datasets formatted as XSD schema types canbe placed into a variable and retrieved

later during the course of the process. Thetype of data that can be assigned to avariable element needs to be predefinedusing one of the following threeattributes: messageType, element, ortype.

The messageType attribute allows for thevariable to contain an entire WSDL-

defined message, whereas the elementattribute simply refers to an XSD elementconstruct. The type attribute can be usedto just represent an XSD simpleType, suchas string or integer.

Example 16.4. The variables construct

hosting only some of the child variable

elements used later by the Timesheet

Submission Process.

...

8/10/2019 IT2401 unit5

8/44

WS-BPEL basics

The getVariableProperty and getVariableData

functions

WS-BPEL provides built-in functions that allowinformation stored in or associated withvariables to be processed during the executionof a business process.

getVariableProperty(variable name,property name)

This function allows global propertyvalues to be retrieved from variables.It simply accepts the variable andproperty names as input and returnsthe requested value.

getVariableData(variable name, partname, location path)

Because variables commonly areused to manage state information,this function is required to provideother parts of the process logicaccess to this data. ThegetVariableData function has amandatory variable name parameterand two optional arguments that canbe used to specify a part of thevariable data.

Example 16.5. Two getVariableDatafunctions being used to retrieve specificpieces of data from different variables.

getVariableData('InvoiceHoursResponse','ResponseParameter')

getVariableData ('input','payload','/tns:TimesheetType/Hours/...')

8/10/2019 IT2401 unit5

9/44

WS-BPEL basics

The sequence element

The sequence construct allows you toorganize a series of activities so that theyare executed in a predefined, sequentialorder. WS-BPEL provides numerousactivities that can be used to express theworkflow logic within the process

definition. The remaining elementdescriptions in this section explain thefundamental set of activities used as partof our upcoming case study examples.

Example 16.6. A skeleton sequenceconstruct containing only some of themany activity elements provided by WS-BPEL.

...

...

...

...

8/10/2019 IT2401 unit5

10/44

WS-BPEL basics

The invoke element

This element identifies theoperation of a partner servicethat the process definitionintends to invoke during thecourse of its execution. Theinvoke element is equipped withfive common attributes, whichfurther specify the details of theinvocation

Example The invoke elementidentifying the target partner servicedetails.

8/10/2019 IT2401 unit5

11/44

WS-BPEL basics

The receive element

The receive element allows us to establish theinformation a process service expects upon receiving

a request from an external client partner service. Inthis case, the process service is viewed as a serviceprovider waiting to be invoked.

The receive element contains a set of attributes,

each of which is assigned a value relating to theexpected incoming communication

8/10/2019 IT2401 unit5

12/44

WS-BPEL basics

Example 16.8. The receive element used in theTimesheet Submission Process definition to indicatethe client partner service responsible for launchingthe process with the submission of a timesheet

document.

8/10/2019 IT2401 unit5

13/44

WS-BPEL basics

The reply element

Where there's a receive element,there's a reply element when asynchronous exchange is beingmapped out. The reply element is

responsible for establishing thedetails of returning a responsemessage to the requesting clientpartner service. Because thiselement is associated with thesame partnerLink element as its

corresponding receive element, itrepeats a number of the sameattributes

Example A potential companionreply element to the previouslydisplayed receive element.

8/10/2019 IT2401 unit5

14/44

WS-BPEL basics

The switch, case, and otherwise elements

These three structured activity elementsallow us to add conditional logic to ourprocess definition, similar to the familiarselect case/case else constructs used intraditional programming languages. Theswitch element establishes the scope of

the conditional logic, wherein multiplecase constructs can be nested to check forvarious conditions using a conditionattribute. When a condition attributeresolves to "true," the activities definedwithin the corresponding case constructare executed.

The otherwise element can be added as a

catch all at the end of the switchconstruct. Should all preceding caseconditions fail, the activities within theotherwise construct are executed.

Example A skeleton case elementwherein the condition attribute uses thegetVariableData function to compare thecontent of theEmployeeResponseMessage variable to azero value.

...

...

8/10/2019 IT2401 unit5

15/44

WS-BPEL basics

The assign, copy, from, and to

elements

This set of elements simply gives us theability to copy values between processvariables, which allows us to pass arounddata throughout a process as informationis received and modified during the

process execution.

Example Within this assign construct, thecontents of theTimesheetSubmissionFailedMessage variable arecopied to two different message variables.

8/10/2019 IT2401 unit5

16/44

WS-BPEL basics

faultHandlers, catch, and catchAll

elements

This construct can contain multiplecatch elements, each of whichprovides activities that performexception handling for a specific type

of error condition. Faults can begenerated by the receipt of a WSDL-defined fault message, or they can beexplicitly triggered through the use ofthe throw element. The faultHandlersconstruct can consist of (or end with)a catchAll element to house defaulterror handling activities.

Example The faultHandlersconstruct hosting catch and catchAllchild constructs.

...

...

8/10/2019 IT2401 unit5

17/44

WS-BPEL basics - Other WS-BPEL elements

8/10/2019 IT2401 unit5

18/44

WS-BPEL basics

8/10/2019 IT2401 unit5

19/44

WS-Coordination overview

The overall coordination mechanism consists of the activation service, theregistration service, a coordinator, and participants that implementspecific protocols. It is likely that these underlying context managementservices will be automatically governed by the orchestration engineplatform for which you are creating a WS-BPEL process definition.

In terms of the WS-Coordination language and its two protocoldocuments, what may be of interest to you is the actualCoordinationContext header that is inserted into SOAP messages. You mayencounter this header if you are monitoring messages or if you need toperform custom development associated with the coordination context.

8/10/2019 IT2401 unit5

20/44


The CoordinationContext element This parent construct contains a series of child

elements that each house a specific part ofthe context information being relayed by theheader.

The activation service returns thisCoordinationContext header upon thecreation of a new activity. As described later,it is within the CoordinationType childconstruct that the activity protocol (WS-BusinessActivity, WS-AtomicTransaction) iscarried. Vendor-specific implementations of

WS-Coordination can insert additionalelements within the CoordinationContextconstruct that represent values related to theexecution environment.

Example A skeleton CoordinationContextconstruct.

8/10/2019 IT2401 unit5

21/44


The Identifier and Expires

elements

These two elements originatefrom a utility schema used toprovide reusable elements. WS-Coordination uses the Identifierelement to associate a unique IDvalue with the current activity.The Expires element sets anexpiry date that establishes theextent of the activity's possiblelifespan.

Example Identifier and Expires

elements containing values

relating to the header.

...

http://www.xmltc.com/ids/process/33342

2008-07-30T24:00:00.000

...
http://www.xmltc.com/ids/process/33342http://www.xmltc.com/ids/process/33342http://www.xmltc.com/ids/process/33342http://www.xmltc.com/ids/process/33342http://www.xmltc.com/ids/process/33342

8/10/2019 IT2401 unit5

22/44


The CoordinationType element

This element is described shortly in theWS-BusinessActivity and WS-AtomicTransaction coordination typessection.

The RegistrationService element

The RegistrationService construct simply

hosts the endpoint address of theregistration service. It uses the Addresselement also provided by the utilityschema.

Example The RegistrationService elementcontaining a URL pointing to the locationof the registration service.

http://www.xmltc.com/bpel/reg

Designating the WS-BusinessActivity

coordination type

The specific protocol(s) that establishes therules and constraints of the activity areidentified within the CoordinationType element.The URI values that are placed here arepredefined within the WS-BusinessActivity and

WS-AtomicTransaction specifications. This first example shows the CoordinationType

element containing the WS-BusinessActivitycoordination type identifier. This would indicatethat the activity for which the header is carryingcontext information is a potentially long-running activity.

Example The CoordinationType element

representing the WS-BusinessActivity protocol.http://schemas.xmlsoap.org/ws/2004/01/wsba

8/10/2019 IT2401 unit5

23/44


Designating the WS-AtomicTransaction coordination

type

In the next example, the CoordinationType element isassigned the WS-AtomicTransaction coordination type

identifier, which communicates the fact that the header'scontext information is part of a short running transaction.

Example The CoordinationType element representing theWS-AtomicTransaction protocol.

http://schemas.xmlsoap.org/ws/2003/09/wsat

8/10/2019 IT2401 unit5

24/44

WS-Choreography

This specification describes a formal method of defining a Choreographyusing a Choreography Definition Language. Choreographies describe thesequence and conditions in which messages are exchanged betweenindependent processes, parties or organizations in order to realize someuseful purpose, for example placing an order.

Choreographies need to be defined when two or more organizations or

processes need to cooperate as no single organization or process controlsor manages the complete process. For example a Buyer cannot directlycontrol what a Seller does and vice versa.

Note that this differs from a Process Execution Language that can be usedwhen there is a single organization or process in control that can issuecommands to other processes to carry out all the actions or activities

required.

8/10/2019 IT2401 unit5

25/44

WS-Choreography

If Choreographies are not defined and agreed between the organizationsor processes involved, then those organizations and processes will not beable to successfully interoperate to realize their shared objectives.

By providing a formal representation of a Choreography in an XML format,this specification allows the definition to be shared and therefore followedby all the organizations or processes that use it.

This specification is in two main parts: The first part describes how to define a Choreography in an abstract

way that is independent of: The format and packaging of the messages being exchanged, and

The technology used at each end to send and receive messages

The second part describes how to bind the messages in aChoreography to WSDL and SOAP (Ed: required but not included in thisversion spec).

Click Here
http://localhost/var/www/apps/conversion/tmp/scratch_4/Burdett-WSChoreographyJune032003.pdf

8/10/2019 IT2401 unit5

26/44

WS-Policy

WS-Policy language basics

The WS-Policy framework establishes a means of

expressing service metadata beyond the WSDL

definition. Specifically, it allows services tocommunicate rules and preferences in relation to

security, processing, or message content. Policies

can be applied to a variety of Web resources,

positioning this specification as anotherfundamental part of the WS-* extensions.

8/10/2019 IT2401 unit5

27/44

WS-Policy

The WS-Policy framework iscomprised of the following threespecifications: WS-Policy WS-PolicyAssertions WS-PolicyAttachments

These collectively provide thefollowing elements covered inthis section, which demonstratehow policies are formulated andattached to element ordocument-level subjects: Policy element TextEncoding, Language,

SpecVersion, andMessagePredicate assertions

ExactlyOne element All element Usage and Preference

attributes PolicyReference element PolicyURIs attribute PolicyAttachment element

8/10/2019 IT2401 unit5

28/44

WS-Policy

The Policy element and common policy assertions

The Policy element establishes the root construct used tocontain the various policy assertions that comprise the policy.The WS-PolicyAssertions specification supplies the following

set of common, predefined assertion elements: TextEncoding Dictates the use of a specific text encoding format.

Language Expresses the requirement or preference for a particularlanguage.

SpecVersion Communicates the need for a specific version of a

specification. MessagePredicate Indicates message processing rules expressed using

XPath statements.

8/10/2019 IT2401 unit5

29/44

WS-Policy

The ExactlyOne element

This construct surrounds multiplepolicy assertions and indicatesthat there is a choice betweenthem, but that one must bechosen.

Example The ExactlyOne constructhousing two alternative policy assertions,one of which must be used.

8/10/2019 IT2401 unit5

30/44

WS-Policy

The All element The All construct introduces a rule that

states that all of the policy assertionswithin the construct must be met.

This element can be combined with theExactlyOne element, where collections ofpolicy assertions can each be grouped into

All constructs that are then furthergrouped into a parent ExactlyOneconstruct.

This indicates that the policy is offering achoice of assertions groups but that theassertions in any one of the alternative Allgroups must be met.

Example The All and ExactlyOneconstructs used together to provide twoalternative policy groups.

8/10/2019 IT2401 unit5

31/44

WS-Policy

The Usage attribute

A number of WS-Policy assertion elements contain a

Usage attribute to indicate whether a given policy

assertion is required. This attribute is a key part of the WS-Policy

framework as its values form part of the overall

policy rules.

The Usage attribute actually has a number of settings

worth knowing about, as shown in Table

8/10/2019 IT2401 unit5

32/44

WS-Policy

The Preference attribute Policy assertions can be ranked in

order of preference using thisattribute. This is especiallyrelevant if a service provider isflexible enough to provide

multiple policy alternatives topotential service requestors.

The Preference attribute isassigned an integer value. Thehigher this value, the morepreferred the assertion. When

this attribute is not used, adefault value of "0" is assigned tothe policy assertion.

The PolicyReference element The PolicyReference element(#) is

one way to simply link anelement with one or morepolicies. Each PolicyReferenceelement contains a URI attribute

that points to one policydocument or a specific policyassertion within the document.

If multiple PolicyReferenceelements are used within thesame element, the policy

documents are merged atruntime.

8/10/2019 IT2401 unit5

33/44

WS-Policy

Example SeparatePolicyReference elements

referencing two policy

documents.

The PolicyURIs attribute Alternatively, the PolicyURIs attribute

also can be used to link to one ormore policy documents. The attributeis added to an element and can beassigned multiple policy locations. Aswith PolicyReference, these policiesare then merged at runtime.Example 17.12. The PolicyURIsattribute referencing two policydocuments.

8/10/2019 IT2401 unit5

34/44

WS-Policy

The PolicyAttachment element Alternative way of associating a

policy with a subject is through theuse of the PolicyAttachmentconstruct.

The approach taken here is that thechild AppliesTo construct is

positioned as the parent of thesubject elements.

The familiar PolicyReference elementthen follows the AppliesTo constructto identify the policy assertions thatwill be used.

Example 17.13. The PolicyAttachment

construct using the child AppliesTo

construct to associate a policy with a

WS-Addressing EndpointReference

construct.

http://www.xmltc.com/tls/ep1

emp:EmployeeInterface

emp:Employee

8/10/2019 IT2401 unit5

35/44

WS-Policy

Additional types of policy assertions It is important to note that policy assertions can be utilized and customized

beyond the conventional manner in which they are displayed in the precedingexamples.

For example: Policy assertions can be incorporated into WSDL definitionsthrough the use of a special

set of policy subjects that target specific parts of the definition structure. A separateUsingPolicy element is provided for use as a WSDL extension.

WS-ReliableMessaging defines and relies on WS-Policy assertions to enforce some of itsdelivery and acknowledgement rules.

WS-Policy assertionscan be created to communicate that a Web service is capable ofparticipating in a business activity or an atomic transaction.

A policy assertion can be designed to express a service's processing requirements inrelation to other WS-* specifications.

WS-Policy assertions commonly are utilized within the WS-Security framework toexpress security requirements.

8/10/2019 IT2401 unit5

36/44

WS-Security

The WS-Security framework provides extensions that

can be used to implement message-level security

measures. These protect message contents during

transport and during processing by serviceintermediaries. Additional extensions implement

authentication and authorization control, which

protect service providers from malicious requestors.

WS-Security is designed to work with any of the WS-* specifications we discuss in this chapter, as shown

in Figure.

8/10/2019 IT2401 unit5

37/44

WS-Security

The WS-Security framework iscomprised of numerousspecifications, many in differentstages of acceptance and maturation.In this book we've concentrated onsome of the more established ones,namely: WS-Security XML-Encryption

XML-Signature

The Security element (WS-Security) This construct represents the

fundamental header block providedby WS-Security. The Security elementcan have a variety of child elements,ranging from XML-Encryption andXML-Signature constructs to thetoken elements provided by the WS-Security specification itself.

Security elements can be outfittedwith actor attributes that correspondto SOAP actor roles. This allows youto add multiple Security blocks to aSOAP message, each intended for adifferent recipient.

The SecurityTokenReference element( i )

8/10/2019 IT2401 unit5

38/44

WS-Security

The UsernameToken, Username,and Password elements (WS-

Security)

The UsernameToken elementprovides a construct that can be usedto host token information for

authentication and authorizationpurposes. Typical children of thisconstruct are the Username andPassword child elements, but customelements also can be added.

The BinarySecurityToken element

(WS-Security)

Tokens stored as binary data, such ascertificates, can be represented in anencoded format within theBinarySecurityToken element.

(WS-Security)

This element allows you to provide a pointer toa token that exists outside of the SOAP messagedocument.

Example The Security SOAP header used by

RailCo to provide user name and password

values.

rco-3342

93292348347

...

E l Th WS S it SOAP

8/10/2019 IT2401 unit5

39/44

WS-Security

Composing Security elementcontents (WS-Security)

The WS-Security specificationpositions the Security element as astandardized container for headerblocks originating from other securityextensions.

The following example illustrates thisby showing how a SAML block islocated within the Security construct.

Example. The WS-Security SOAP

header hosting a SAML authorization

assertion.

...

Execute

...

...

8/10/2019 IT2401 unit5

40/44

WS-Security

The EncryptedData element (XML-Encryption)

This is the parent construct that hosts theencrypted portion of an XML document. Iflocated at the root of an XML document,the entire document contents areencrypted.

The EncryptedData element's Typeattribute indicates what is included in theencrypted content. For example, a valueofhttp://www.w3.org/2001/04/xmlenc#Element indicates that the element and itscontents will be encrypted, whereas thevalue of

http://www.w3.org/2001/04/xmlenc#Content states that encryption will only beapplied to the content within the openingand closing tags.

The CipherData, CipherValue, andCipherReference elements (XML-

Encryption)

The CipherData construct is required andmust contain either a CipherValueelement hosting the charactersrepresenting the encrypted text or a

CipherReference element that provides apointer to the encrypted values.
http://www.w3.org/2001/04/xmlenchttp://www.w3.org/2001/04/xmlenchttp://www.w3.org/2001/04/xmlenchttp://www.w3.org/2001/04/xmlenchttp://www.w3.org/2001/04/xmlenchttp://www.w3.org/2001/04/xmlenchttp://www.w3.org/2001/04/xmlenchttp://www.w3.org/2001/04/xmlenchttp://www.w3.org/2001/04/xmlenchttp://www.w3.org/2001/04/xmlenchttp://www.w3.org/2001/04/xmlenchttp://www.w3.org/2001/04/xmlenchttp://www.w3.org/2001/04/xmlenchttp://www.w3.org/2001/04/xmlenchttp://www.w3.org/2001/04/xmlenchttp://www.w3.org/2001/04/xmlenchttp://www.w3.org/2001/04/xmlenchttp://www.w3.org/2001/04/xmlenchttp://www.w3.org/2001/04/xmlenchttp://www.w3.org/2001/04/xmlenchttp://www.w3.org/2001/04/xmlenchttp://www.w3.org/2001/04/xmlenchttp://www.w3.org/2001/04/xmlenchttp://www.w3.org/2001/04/xmlenchttp://www.w3.org/2001/04/xmlenchttp://www.w3.org/2001/04/xmlenchttp://www.w3.org/2001/04/xmlenchttp://www.w3.org/2001/04/xmlenchttp://www.w3.org/2001/04/xmlenchttp://www.w3.org/2001/04/xmlenchttp://www.w3.org/2001/04/xmlenchttp://www.w3.org/2001/04/xmlenc

8/10/2019 IT2401 unit5

41/44

WS-Security

Plain Text

2322

$32,322.73

07.16.05

Cipher Text

Example 17.21. An XML document

within a SOAP message containing

an encrypted element.

2322

R5J7UUI78

07.16.05

8/10/2019 IT2401 unit5

42/44

WS-Security

XML-Signature elements

A digital signature is a complex piece of information

comprised of specific parts that each represent an

aspect of the document being signed. Therefore,numerous elements can be involved when defining

the construct that hosts the digital signature

information. Table provides brief descriptions of

some of the main elements.

8/10/2019 IT2401 unit5

43/44

WS-Security

Example A SOAP message headercontaining a digital signature.

LLSFK032093548=

9879DFSS3=

...

...invoice document with total exceeding

$30,000...

8/10/2019 IT2401 unit5

44/44

THANK YOU

Documents

IT2401 unit5