Middleware for Heterogeneous and Distributed Information Systems Exercise Sheet 8

Size: px

Start display at page:

Download "Middleware for Heterogeneous and Distributed Information Systems Exercise Sheet 8"

Roberta Green
6 years ago
Views:

1 AG Heterogene Informationssysteme Prof. Dr.-Ing. Stefan Deßloch Fachbereich Informatik Technische Universität Kaiserslautern Middleware for Heterogeneous and Distributed Information Systems Exercise Sheet 8 Tuesday, December 20, :45 to 15:15 Room BPEL Web Service Composition 1) Figure 1: Control flow of the travel arrangements process 2) A <partnerlinktype> characterizes the conversational relationship between two services by defining the roles played by each of the services in the conversation and specifying the porttype provided by each service to receive messages within the context of the conversation. Each <role> specifies exactly one WSDL porttype. The extensibility mechanism of WSDL 1.1 is used to define <partnerlinktype> as a new definition type to be placed as an immediate child element of a <wsdl:definitions> element. This allows reuse of the WSDL target namespace specification and its import mechanism to import porttype definitions. The <partnerlinktype> definition can be a separate artifact independent of either service's Middleware for Heterogeneous and Distributed Information Systems 1

2 WSDL document. Alternatively, the <partnerlinktype> definition can be placed within the WSDL document defining the porttypes from which the different roles are defined. (See 6.1 Partner Link Types) Three partner link types are required and may be placed in the corresponding WSDL files. travellt is used to describe the interactions between the BPEL process and its client. This partner link type is defined in the WSDL of the BPEL process. employeelt is used to describe the interactions between the BPEL process and the employee travel status web service. This partner link type is defined in the WSDL of the employee web service. flightlt is used to describe the interactions between the BPEL process and the airline web service. This partner link type is defined in the WSDL of the airline web service. <plnk:partnerlinktype name="travellt"> <plnk:role name="travelservice"> <plnk:porttype name="tns:travelapprovalpt" /> <plnk:role name="travelservicecustomer"> <plnk:porttype name="tns:clientcallbackpt" /> </plnk:partnerlinktype> <plnk:partnerlinktype name="employeelt"> <plnk:role name="employeetravelstatusservice"> <plnk:porttype name="tns:employeetravelstatuspt" /> </plnk:partnerlinktype> <plnk:partnerlinktype name="flightlt"> <plnk:role name="airlineservice"> <plnk:porttype name="tns:flightavailabilitypt" /> <plnk:role name="airlinecustomer"> <plnk:porttype name="tns:flightcallbackpt" /> </plnk:partnerlinktype> 3) The services with which a business process interacts are modeled as partner links in WS-BPEL. Each <partnerlink> is characterized by a partnerlinktype. More than one <partnerlink> can be characterized by the same partnerlinktype. For example, a certain procurement process might use more than one vendor for its transactions, but might use the same partnerlinktype for all vendors. Each <partnerlink> is named, and this name is used for all service interactions via that <partnerlink>. [] Within a <partnerlink>, the role of the business process itself is indicated by the attribute myrole and the role of the partner is Middleware for Heterogeneous and Distributed Information Systems 2

3 indicated by the attribute partnerrole. When a partnerlinktype has only one role, one of these attributes is omitted as appropriate. (See 6.2 Partner Links) <partnerlinks> <partnerlink name="client" partnerlinktype="trv:travellt" myrole="travelservice" partnerrole="travelservicecustomer"/> <partnerlink name="employeetravelstatus" partnerlinktype="emp:employeelt" partnerrole="employeetravelstatusservice"/> <partnerlink name="americanairlines" partnerlinktype="aln:flightlt" myrole="airlinecustomer" partnerrole="airlineservice"/> <partnerlink name="deltaairlines" partnerlinktype="aln:flightlt" myrole="airlinecustomer" partnerrole="airlineservice"/> </partnerlinks> The basic control flow can be expressed by the following structured activities. <process> <partnerlinks></partnerlinks>   <flow>   </flow>  <switch></switch>  </process> Variables provide the means for holding messages that constitute a part of the state of a business process. The messages held are often those that have been received from Middleware for Heterogeneous and Distributed Information Systems 3

4 partners or are to be sent to partners. Variables can also hold data that are needed for holding state related to the process and never exchanged with partners. WS-BPEL uses three kinds of variable declarations: WSDL message type, XML Schema type (simple or complex), and XML Schema element. (See 8.1 Variables) We define a variable for every message sent to the partners and received from them. That is, seven variables are required: TravelRequest, EmployeeTravel- StatusRequest, EmployeeTravelStatusResponse, FlightDetails, FlightResponseAA, FlightResponseDA, and TravelResponse. For each variable you have to specify the type. In this example WSDL message types are used for all variables. <variables>  <variable name="travelrequest" messagetype="trv:travelrequestmessage"/>  <variable name="employeetravelstatusrequest" messagetype="emp:employeetravelstatusrequestmessage"/>  <variable name="employeetravelstatusresponse" messagetype="emp:employeetravelstatusresponsemessage"/>  <variable name="flightdetails" messagetype="aln:flightticketrequestmessage"/>  <variable name="flightresponseaa" messagetype="aln:travelresponsemessage"/>  <variable name="flightresponseda" messagetype="aln:travelresponsemessage"/>  <variable name="travelresponse" messagetype="aln:travelresponsemessage"/> </variables> BPEL Fault Handling and Compensation 1) A <scope> provides the context which influences the execution behavior of its enclosed activities. This behavioral context includes variables, partner links, message exchanges, correlation sets, event handlers, fault handlers, a compensation handler, and a termination handler. Contexts provided by <scope> activities can be nested hierarchically, while the root context is provided by the <process> construct. (See 12. Scopes) 2) Middleware for Heterogeneous and Distributed Information Systems 4

5 The ability to declare compensation logic alongside forward-working logic is the underpinning of the application-controlled error-handling framework of WS-BPEL. WS- BPEL allows scopes to delineate that part of the behavior that is meant to be reversible in an application-defined way by specifying a compensation handler. (See 12.4 Compensation Handlers) <scope name="b"> <compensationhandler> <invoke partnerlink="airline" porttype="flightbookingpt" operation="flightcounterorder" inputvariable="" /> </compensationhandler> <scope name="c"> <compensationhandler> <invoke partnerlink="accountingdept" porttype="travelbudgetpt" operation="increasebudget" inputvariable="" /> </compensationhandler> 3) Termination handlers provide the ability for scopes to control the semantics of forced termination to some degree. The forced termination of a scope begins by disabling the scope's event handlers and terminating its primary activity and all running event handler instances. Following this, the custom <terminationhandler> for the scope, if present, is run. <scope name="b"> <terminationhandler> <invoke partnerlink="airline" porttype="flightbookingpt" operation="abortoperation" inputvariable="" /> </terminationhandler> <scope name="c"> <terminationhandler> <invoke partnerlink="accountingdept" porttype="travelbudgetpt" operation="abortoperation" inputvariable="" /> </terminationhandler> When a request-response <invoke> is interrupted and terminated prematurely, the response (if received) for such a terminated activity MUST be ignored. (See 12.6 Termination Handlers) Middleware for Heterogeneous and Distributed Information Systems 5

6 That is the above code snippet only makes sense if both partner web services are called asynchronously and provide an abort operation. 4) Fault handling in a business process can be thought of as a mode switch from the normal processing in a scope. Fault handling in WS-BPEL is designed to be treated as "reverse work," in that its aim is to undo the partial and unsuccessful work of a scope in which a fault has occurred. The completion of the activity of a fault handler, even when it does not rethrow the handled fault, is not considered successful completion of the attached scope. Compensation is not enabled for a scope that has had an associated fault handler invoked. (See 12.5 Fault Handlers) <scope name="a"> <faulthandlers> <catchall> <compensate/> <reply partnerlink="client" porttype="flightbookingpt" operation="abortoperation" variable="" faultname="" /> <terminate/> </catchall> </faulthandlers> Mind that the <terminate/> action does not call the termination handler. It stops the whole process! That is why it was renamed to <exit/> in a newer BPEL version. The termination handlers are called automatically when a fault occurs. 5a) Scope B has no explicit fault handler. In this case a default fault handler is assigned. <catchall> <compensate /> <rethrow /> </catchall> The <compensate> activity causes all immediately enclosed scopes to be compensated in default order. Since scope B does not have any enclosed scopes no operation is performed. The <rethrow> activity is used to rethrow the fault that was originally caught by the immediately enclosing fault handler. That is, the fault is passed on to scope A. Middleware for Heterogeneous and Distributed Information Systems 6

7 Consequently the scope s fault handler is invoked and invokes the <compensate> activity. Since scope B did not complete successfully no compensation handler was installed. Scope C, however, did complete successfully, thus its compensation handler is called. Finally, the fault handler of scope A replies with an error message to the client and terminates the overall process. 5b) In contrast to the scenario described above, scope C did not complete its operations successfully yet. Hence, no compensation handler has been installed. In fact, scope C is terminated and its termination handler is invoked. Middleware for Heterogeneous and Distributed Information Systems 7

Software Service Engineering

Software Service Engineering Lecture 4: Service Modeling Doctor Guangyu Gao Some contents and notes selected from Service Oriented Architecture by Michael McCarthy 1. Place in Service Lifecycle 2 Content