ServiceOrientedArchitectureCaseStudy

Part3SOAImplementationoftheAVERSCaseStudy

Part3SOAImplementationoftheAVERSCaseStudy
1Introduction
This report aims at the description of the initial steps for the implementation of a top down Service Oriented Architecture (SOA) approach to the AVERS Supply Chain case study, whichwasdescribedindetailintheliteraturereviewofthefirstassignment. On the second assignment, a high level model of the whole AVERS supply chain has been built, depicting the business processes that rule the entire chain from the supply part to the distribution of the final products, passing through the manufacturing activities. The BusinessProcessModel&Notation(BPMN2.0)hasbeenusedtomodeltheprocessesand,asa second step, the business services needed to enable the interactions between the partners weredescribedintermsoftheirinterfaces,inputsandoutputs. Finally, when it comes to this third assignment, further details regarding the implementation of the proposed models are given. The Web Services Description Language (WSDL) files are designed for the business services, therefore identifying their constituent operations and required parameters, as well as the Business Process Execution Language (BPEL)filesfortheorchestrationofsuchservices. This document, thus, describes the results achieved on each step of the design of the initial implementation details for the AVERS SOA approach. First, the aforementioned WSDL and BPEL files are implemented. Then, the designed BPEL processes are enhanced with transactionorientedfeaturesbytheuseofscopes,faultandcompensationhandlers.Finally,a discussion of how the designed BPEL processes fit into the previously designed BPMN processesiscarriedout. Note: The processes Product inventory control and Product Shipment Administrationand Production Controlare identified to be the richest of the processes. They contain most possibilities to show, how BPMN processes can be refined and implemented using BPEL. They also contain interaction with external partners, thus providing transactions. Compensation is modelled explicitly, as well as fault handling. These processes are modelled with all needed assignactions, instantiating all variables correctly. All activities that imply any message exchange like the invoke and receiveactivity are implemented based on the corresponding WSDLfiles. Thus, correct operations are assigned to these activities. It should be possible to come up with an executable version of these BPEL processes, needing little effort. (The servicesneedtobeimplemented,ofcourse.) The other two processes (Order Processing and Production Scheduling and Material Control and Procurement) are only modelled as skeletons. They can be mapped properly to the BPMN models but they are not ready to execute. They do not contain valid assigncode and the operations are not mapped to the corresponding WSDLfiles. (But these files are provided and describedhere.)

ServiceOrientedArchitectureCaseStudy
Part3SOAImplementationoftheAVERSCaseStudy This thoughtful decision was taken because of external time constraints. Because it is truly believed that the two aforementioned BPEL processes (Product inventory control and Product Shipment Administration and Production Control) show in detail the pitfalls and mappings fromBPMNtoBPEL,thisapproachwastakenandtobeconsideredacceptable.

2ImplementationoftheWSDLDescriptionsandBPELProcesses
In this section, the various Web Services required for the AVERS Supply Chain are identified and designed corresponding to the core processes defined in Assignment 2 as per the ANSI/ISA95s functional flow data model.Then, fourBPELOrchestration processes are defined with respect to the four basic processes of the Supply Chain. A total of twelve Web Service DescriptionLanguage (WSDL)filesare definedcorresponding tothefourbasic processeslisted below: OrderProcessingandProductionScheduling: OrderManagementServices:OrderManagementService.wsdl CustomerRelationshipManagementServices:CRMService.wsdl ProductionControl: ProductionRequestServices:ProductionRequestWS.wsdl ProductionRuleServices:ProductionRuleWS.wsdl ProductionLineServices:ProductionLineWS.wsdl RawMaterialServices:RawMaterialWS.wsdl MaterialControlandProcurement: InventoryManagementServices:InventoryMgmtWS.wsdl MaterialRequestServices:MaterialRequestWS.wsdl SupplierRelationshipServices:SupplierRelationshipWS.wsdl NotificationServices:NotificationWS.wsdl ExternalSupplierServices:ExternalSuppliersWS.wsdl ProductinventorycontrolandProductShipmentAdministration: CustomerServices:ProductInventoryControlCustomerServices.wsdl CarrierServices:ProductInventoryControlCarrierServices.wsdl ProcessinternalServices:ProductInventoryControlProcessInternalOperations.wsdl For the Product inventory control and Product Shipment Administration process, a WSDL for internal services has been designed. BPMN provides the concept of tasks, which was used when modelling. This concept cannot be transferred to BPEL, since BPEL basically knows only theinvokeactivitytodosomeprocessing.Internalexecutionofscriptsordatacollectionisnot possible. Thus, the internal service provides operations like data collection for the BPEL process. Furthermore, the originally described WSDL (in Assignment 2) is split in two parts to clearly show the impact of external collaborators. In this case, there is a carrier services which provides interaction with external carriers and a customer service for the customer

ServiceOrientedArchitectureCaseStudy
Part3SOAImplementationoftheAVERSCaseStudy interaction. Note that there is only one WSDL for all carriers. It is assumed that all carriers providethesameoperationsanddataschema. All the WSDLs are designed using the TopDown approach with the help of the Eclipse WSDL Editor.Thedetailsregardingtheoperationsinputandoutputstructure,ofeachWebService hasalreadybeendescribedinAssignment2,andhasnotbeenexplainedhereagain. ModelingProcedure: This section describes the procedure that was followed to model the WSDLs using the Top Down approach using the Eclipse Editor. Only the Order Management Service has been described in detail here, and the same methodology was followed to model all the remaining WSDLs. DefinitionofOperations:

Figure1:WebServiceOperationsDefinition

ServiceOrientedArchitectureCaseStudy
Part3SOAImplementationoftheAVERSCaseStudy DefinitionofInputandOutput:

Figure2:InputandOutputDefinitioninWSDL

DefinitionofCustomTypes:

Figure3:MessageTypeDefinitioninWSDL

ServiceOrientedArchitectureCaseStudy
Part3SOAImplementationoftheAVERSCaseStudy

3ImplementationofTransactionsandCompensationsinBPEL
Themainfocusontransactionswasgiventotransactionswithexternalpartners.Scopesare definedaroundtheactivitiesthatexecutetransactions.Anexampleisgivenherebasedonthe ProductinventorycontrolandProductShipmentAdministrationprocess.

Figure4:ScopeandCompensation

Theredframeabovemarksthescopeinapartoftheprocess.Withinthescope,aselected routeisbookedwithanexternalcarrier.Thistransactionismodeledinanasynchronousstyle. Incaseanythinggoeswrongwithinthisscope(ortransaction),thisbookinghastobe compensated,whichisshownintherightpart.Compensationisdoneinthiscasebenotifying aninternalprogramaboutthiserror.Then,furthercompensationispropagated,incaseother activitieshavetobecompensated.Anerroristhrown,becausewithoutcarrier,theprocess cannotcontinueandterminatesuccessfully.Manualactionisneededinthiscase.

ServiceOrientedArchitectureCaseStudy
Part3SOAImplementationoftheAVERSCaseStudy

Figure5:Faulthandling

Anotherexampleiserrorhandling.Again,theleftsideshowsactivitieswithinascope. Productsarepreparedforshipmentandwhentheyarehandedovertothecarrier,theprocess getsanotification.Incasesomethinggoeswrongherewithinthisscope,e.g.theproductsare nothandedovertothecarrierforanyreason,afaultisthrown.Aninternalnotificationissent andcompensationistriggered.Thus,otheractivitiesorscopesthatimplementcompensation andarealreadycompletedarecompensatedthisway.Compensationaswellasfaulthandling ispropagatedfrombottomtotop.Consequently,thebookingofacarrieriscanceled automaticallybycompensationpropagation(seeexampleabove,whichisfromthesame process).

ServiceOrientedArchitectureCaseStudy
Part3SOAImplementationoftheAVERSCaseStudy

4RelatingtheBPELModelstotheBPMNModelsofAssignment2
This section explains how the BPEL processes that are designed fit into the BPMN processes that were modeled in Assignment 2. Four core processes were defined in Assignment 2 as per the ANSI/ISA95s functional flow data model, and one BPMN 2.0 diagram was modelled for each of these core processes. In this assignment, it was decided to relate each of these four BPMNdiagramstoacorrespondingBPELprocess. OrderProcessingandProductionScheduling ProductionControl MaterialControlandProcurement ProductinventorycontrolandProductShipmentAdministration

AllthefourBPELProcessesaremodelledintheAsynchronousmanner,withcorrelationsetsin order to maintain context for a single Purchase Order Request. The scope and compensation sphereshavealsobeenmodelledineachoftheseBPELprocesses. BPEL01OrderProcessingandProductionScheduling: The main functions of this BPEL process are the Customer Order handling, Order Acceptance and Confirmation. It involves verifying the order, registration of the order, verifying the customer liquidity, checking the type of customer in order to consolidate the order and finally preparingthefinalInvoice(orBill)fortheCustomer.

ServiceOrientedArchitectureCaseStudy
Part3SOAImplementationoftheAVERSCaseStudy

Figure6:OrderProcessingProductionSchedulingBPELProcess

ServiceOrientedArchitectureCaseStudy
Part3SOAImplementationoftheAVERSCaseStudy BPEL02ProductionControl: This BPEL process performs the main functions such as checking the accordance of schedule with production schedule and standards. It also involves performing plant engineering activities and update of process plan. Furthermore, it also issues requirements for raw materialsandtransformationofrawmaterialsintoendproducts.

ServiceOrientedArchitectureCaseStudy
Part3SOAImplementationoftheAVERSCaseStudy

Figure7:ProdutionControlProcess

BPEL03MaterialControlandProcurement:

ServiceOrientedArchitectureCaseStudy
Part3SOAImplementationoftheAVERSCaseStudy This process is primarily about managing the inventory. It also performs other functions like managing transfers of material and placing orders with suppliers for raw materials, supplies, spare parts, tools,equipment and other required materials. It also monitors progress of purchases and performs reporting to requisitioners. Furthermore is also handles receiptof incoming material supplies, and release incoming invoices for payment after arrival and approvalofgoods.

ServiceOrientedArchitectureCaseStudy
Part3SOAImplementationoftheAVERSCaseStudy

Figure8:MaterialControlProcurementBPELProcess

ServiceOrientedArchitectureCaseStudy
Part3SOAImplementationoftheAVERSCaseStudy BPEL04ProductinventorycontrolandProductShipmentAdministration: This BPEL process deals with managing inventory of finished products, making reservations for specific product in accordance with product selling directives and organizing transport for productshipmentinaccordancewithacceptedordersrequirements.Italsoinvolvesnegotiating and placing orders with transport companies, and releasing material for shipment.Finally, it preparestheshipmentconfirmationandperformsinvoicingtobesenttothecustomer.

ServiceOrientedArchitectureCaseStudy
Part3SOAImplementationoftheAVERSCaseStudy

Figure9:ProductinventorycontrolandProductShipmentAdministration

Basically, the BPEL process shows the same activities like the BPMN model. As mentioned before, BPMN provides the concept of tasks, which was used when modelling. This concept

ServiceOrientedArchitectureCaseStudy
Part3SOAImplementationoftheAVERSCaseStudy cannot be transferred to BPEL, since BPEL basically knows only the invokeactivity to do some processing. Furthermore, BPELdoes not understand the concept of multiple instance activities which are activities in BPMN that are executed multiple times and in parallel. In this BPEL process, this was modelled as a forloop that executes activities in parallel. Its range depends on the activity before, that means how many activities have to be run in parallel. The forloop loopsexactlythatmanytimes,thusitisdetermineddynamicallyusingvariables.

Figure10:MappingofmultipleInstanceactivitiesfromBPMNtoBPEL

Furthermore, some tasks in BPMN have been left out in BPEL because BPEL does not support this concept of tasks, as mentioned. These tasks in BPMN did mostly some data gathering, getting data from a database for example. The idea was to keep the data flow of each process instance low when data is not needed frequently. In BPEL however, data is often modelled using global variables, thus being available during the whole instance life. These activities are notrepeatedlymodelledintheBPELsincetheywouldnotaddanyvalue.

5Conclusion
TheSOAimplementationprovidesaBPELmodelforasupplychainscenario.Basedon previouslymodeledBPMNprocesses,BPELprocessesweremodeledandrefined.WSDLfiles forseveralservicesinthedescribedsupplychainscenariowerecreated. BPELisseenasavalidprocessmodelinglanguagetorefineaBPMNmodel.Executable solutionscanbeachieved.However,thisdoesnotgosmooth.BPMNandBPELhavedifferent scopesandthusdifferentcomplexity.BPMNinitsversion2.0providesmanynewmodeling artifactswhichcannotbemappedeasilytoBPEL,e.g.simpletasks,humantasks,ormore specifically,multipleinstanceactivities.Errorhandlingisevenmorecomplextomodelfrom BPMNtoBPEL.Thus,itwasnoteasytomapallconceptsmodeledinBPMNtotheBPEL processes. BPELismissingfurtherevolvement.Sinceitslastversionsomeyearsagotherehasnotbeen muchefforttoimprovethelanguagefurther,onlythroughextensions.Soanymodelingofa

ServiceOrientedArchitectureCaseStudy
Part3SOAImplementationoftheAVERSCaseStudy processisstillaquitecomplexandtimeconsumingprocess,howeverprocessescanbe modeledsuccessfully(tobeexecutable).

6Acknowledgements
Theauthorwishestoacknowledgethefollowingstudentsfortheimplementationofthe AVERSCaseStudy. AjaySagar FbioCardosoCoutinho HolgerEdgarOviedoCahuata RodrigoDeOliveiraMachado SuriChandramouli TobiasHberle