COP 4991 Component Based Software Development

COP 4991Component Based Software Development Lecture #7 Workflows/BPEL Onyeka Ezenwoye

Agenda • Workflow introduction • OASIS and WS-BPEL • Main Concepts • Examples • Status and support

Motivation • Application integration is a key problem facing businesses • Intra enterprise integration (Enterprise Application Integration) • Integrating with partners (Business Process Integration) • Web services  move towards service-oriented computing • Applications are viewed as “services” • Loosely coupled, dynamic interactions • Heterogeneous platforms • No single party has complete control • Service composition • How do you compose services in this domain?

Customer Customer Sales Service (workflow) Accounting Service Production Service Inventory Service Delivery Service Application Integration

Workflow • Workflows represent a set of activities to be executed, their interdependencies relations, inputs and outputs. input data1 activity1 activity3 output data input data2 activity2 input data3 activity4

What are workflows? The automation of a business process, in whole or part, during which documents, information or tasks are passed from one participant to another for action, according to a set of procedural rules. workflow management consortium

Step 1 Step 3 Step 2 Step 4 Step 0 Step 5 • Participants perform the work represented by a workflow activity instance and can be human or machine resources. Activities can execute in parallel or in sequence. Activity (human or machine) Condition / dependency

Main Concepts in Workflow • match-making between participants and activities, • Control flow of work between participants • providing information resources for activities, • designing processes, • managing processes, • the scope of the process environments which can be created

Two-level Programming Model • Programming in the large • Non-programmers implementing flows • Flow logic deals with combining functions in order to solve a more complex problem (such as processing an order) • Programming in the small • Programmers implementing functions • Function logic deals with a discrete fine-grained task (such as retrieving an order document or updating a customer record)

Workflow Management Systems • Workflow management systemsdate back to the late 1980. The are used to coordinate the work of multiple people in a project that has a fixed process. • Pure workflow software

Why workflow management? • Better, Cheaper faster businesses • Improved efficiency - mostly through automation of business processes. • Improved customer service – through consistency in the processes. • Flexibility – software control over processes enables their re-design in line with changing business needs

Workflow Systems should support - defining process in terms of finer-grained tasks or activities, - scheduling these activities and • dispatching (invoking) the activities • Passing of information between activities

Types of WFMS • Centralized (Orchestration) • Decentralized (Choreography)

Orchestration • A centralized mechanism that describes how diverse services can interact. This interaction includes message exchange, business logic and order of execution. • interacting components are not be aware of each other

Choreography • Choreography focuses on enabling the description of how to interact with services at a larger scale than the individual message exchange pattern • Interacting components are aware of each other.

Orchestration Centralized Approach Component Workflow Engine A C D B 1: 2a: * 2b: * 3a: * 3b: * 4:

Component Component X A B C D 1: 3a: * 3b: * 4: Choreography • Decentralized approach

Centralized Control • Problems with Centralized Control • Performance bottleneck • do not scale well • May not suitable if systems are inherently autonomous and distributed bs Central WFMS t2 t1 t4 bs t3 bf A1 (t1) A3 (t3) A2 (t2) A4 (t4)

Some Challenges for WfMS • Process Representation (control flow & data flow) • Process Specification • Process Definition Interoperability • Process Enactment (automated sequencing) • Process Monitoring & Control/Config. • Process Participant Modelling, Monitoring & Control

.net WAS RMI/IIOP Business Process SOAP Legacy integration MQSeries CICS MQSeries Delivery channels Application Integration

WS-BPEL Specifications • BPEL4WS 1.0 (7/2002) • Original proposal from BEA, IBM, Microsoft • Combined ideas from IBM’s WSFL and Microsoft’s XLANG • BPEL4WS 1.1 (5/2003) • Revised proposal submitted to OASIS • With additional contributions from SAP and Siebel • WS-BPEL 2.0 • Currently in OASIS undergoing standardization • Committee Draft specification available

WS-BPEL Business Processes You are here WSDL, Policy, UDDI, Inspection Description Security Reliable Messaging Transactions Quality Of Service Coordination SOAP (Logical Messaging) Other protocols Transport and Encoding Other services XML, Encoding WS-BPEL in the WS-* Stack

Process Usage Patterns • Aiming for a single approach for both … • Executable processes • Contain the partner’s business logic behind an external protocol • Abstract processes • Define the publicly visible behavior of some or all of the services an executable process offers • Define a process template embodying domain-specific best practices

Process Model Requirements • Portability and Interoperability • Flexible Integration • Rich, and easily adaptable to changes in the services it is interacting with • Recursive, type-based composition, enables … • third-party composition of existing services • providing different views on a composition to different parties • inter-workflow interaction • increased scalability and reuse • Separation and composability of concerns • Decoupled from the supporting mechanisms (quality of service, messaging frameworks) • Stateful conversations and lifecycle management • Can carry multiple stateful long-running conversations • Recoverability • Business processes, and in particular long running ones, need a way to build-in fault handling and compensation mechanisms to handle and recover from errors

BPEL4WS 1.1 (*) BPEL4WS 1.1 authors Getting the Players Together (*)

OASIS Technical Committee • 288 committee members, incl. observers ~ 30 active voting members, attending weekly calls • Work on WS-BPEL (TC Charter) • Standardize it • Focus on • Common concepts for a business process execution language for usage patterns including both the process interface descriptions and executable process models • Explicitly do not address • Bindings to specific hardware/software platforms and other mechanisms required for a complete runtime environment for process implementation

OASIS Technical Committee • Issues Process • List of all issues available at http://www.choreology.com/external/WS_BPEL_issues_list.html • Issue discussion • Weekly calls • Quarterly face to face meetings • Status • Deadlines (need 2/3 majority to override) • No new feature issues since Aug 15, 2004 • No new feature issue resolution proposals since April 1, 2005 • Feature issues that are not resolved are marked as revisitable • Latest approved committee draft: September 1, 2005

WS-BPEL Language Structure • Process • Partner links • Data handling • Properties and correlation • Basic and structured activities • Scopes

WSDL Loan Approval PortType Web Service Loan Approval Process receive reply BPEL and WSDL • BPEL processes are exposed as WSDL services • Message exchanges map to WSDL operations • WSDL can be derived from partner definitions and the role played by the process in interactions with partners

Interfaces exposed by the BPEL process Interfaces consumed by the BPEL process WSDL Loan Approval PortType Web Service Web Service Loan Approval Process receive Financial Institution‘s Web Service (Loan Approver) invoke reply Recursive Composition • BPEL processes interact with WSDL services exposed by business partners

Service A Service P Service B receive invoke receive invoke invoke A’s WSDL P’s WSDL F B’s WSDL Partner Link Type Partner Link Type Composition of Web Services

Process 1 Process 2 Partner Link Type Port Type 1 Port Type 2 Partner Links • Partner link: instance of typed connector • Partner link type specifies required and/or provided portTypes • Channel along which a peer-to-peer conversation with a partner takes place

Scoped variables typed as WSDL messages or XML Schema elements/types Activities’ input and output kept in scoped variables receive . . . invoke 42 Assignment activities move data around assign . . . 0 reply 1 BPEL Data Model: Variables

Do a blocking wait for a matching message to arrive • Send a message in reply to a formerly received message • Invoke a one-way or request-response operation • Update the values of variables or partner links with new data • Validate XML data stored in variables • A “no-op” instruction for a business process receive Generate a fault from inside the business process Forward a fault from inside a fault handler Immediately terminate execution of a business process instance Wait for a given time period or until a certain time has passed Invoke compensation on an inner scope that has already completed throw reply rethrow invoke exit assign wait validate compensate empty Basic Activities

Contained activities are executed in parallel, partially ordered through control links • Select exactly one branch of activity from a set of choices • Contained activity is repeated while a predicate holds • Contained activity is repeated until a predicate holds flow • Block and wait for a suitable message to arrive (or time out) • Contained activity is performed sequentially or in parallel, controlled by a specified counter variable • Contained activities are performed sequentially in lexical order • Associate contained activity with its own local variables, fault handlers, compensation handler, and event handlers pick if then else forEach while sequence repeatUntil scope Structured Activities

Nesting Structured Activities sequence <sequence> <receive .../> <flow> <sequence> <invoke .../> <while ... > <assign>...</assign> </while> </sequence> <sequence> <receive .../> <invoke ... > </sequence> </flow> <reply> </sequence> receive flow sequence sequence invoke receive invoke while assign reply

scope variables event handlers partner links fault handlers fault handler correlation sets . . . compensation handler . . . . . . termination handler . . . . . . Scopes and Handlers • Scope • Local variables • Local partner links • Local correlation sets • Set of activities (basic or structured) • Handlers • Event handlers • Message events or timer events (deadline or duration) • Fault handlers • Dealing with different exceptional situations (internal faults) • Compensation handler • Undoing persisted effects of already completed activities • Termination handler • Dealing with forced scope termination (external faults)

instance 1 instance 2 2 1 Process instance n BPEL Engine Correlation • Messages in long-running conversations are correlated to the correct process instance <message name=“requestMessage"> <part name="firstName" type="xsd:string"/> <part name=“lastName" type="xsd:string"/> <part name=“custID" type="xsd:int"/> </message>

receive invoke invoke invoke reply Process Instance Lifecycle • Business processes defined in BPEL represent stateful Web services • When a process is started, a new instance is created • The creation and destruction of BPEL process instances is by design implicit

Graph-Oriented Authoring Style flow riskAssessmentPT loanApprovalPT amount < 10000 amount >= 10000 receive loan assessor loan approver risk = "high" invoke invoke assign risk = "low" approved = "true" approved = "false" reply 1. A customer asks for a loan, providing name and amount info 2. Two services are involved: a) A risk assessor which can approve the loan if the risk is low b) A loan approver which checks the name and approves/disapproves the loan 3. The reply is returned to the customer

sequence flow if-then-else reply (seller) reply (buyer) if buyer$$ < seller$$ then else receive (buyer) assign "failure" receive (seller) assign "success" Structured Authoring Style

Fault Handling and Compensation Process flow fault handler notify manager scope scope compensation handler fault handler compensate charge credit card refund customer rethrow ship goods

1. Assign EPR from partnerLink (myRole) to variable 3. Receive variable with A‘s callback EPR from process A assign EPR 4. Assign EPR from variable to partnerLink (partnerRole) B-role assign EPR Partner Link Type partner link partner link A-role BPEL Partner Link Assignment Process A Process B 2. Pass variable with A‘s callback EPR to process B PortType-B invoke service receive request receive response invoke callback PortType-A 5. Invoke A‘s callback using the received EPR 6. Receive the callback from the other process

plan trip select airline reserve seats charge credit card A Travel Reservation Abstract Process View Executable Processes View Traveler Process Agent Process Airline Process get itinerary get order submit to agent order tickets receive confirmation receive tickets receive confirmation confirm flight send confirmation send tickets

result phrase Google Spell-checker WS Amazon Store WS <portType name="GooglePortType"> <operation name="doSpellingSuggestion"> <input message="type:String"/> <output message="type:String"/> </operation> </portType> result query <portType name=“AmazonPortType"> <operation name="ItemSearch"> <input message="type:ComplexType"/> <output message="type:Array"/> </operation> </portType>

phrase Google Spell-checker WS result assignment activity query result Amazon Store WS <portType name=“Google-AmazonPortType"> <operation name=“GoogleAmazonSearch"> <input message="type:String"/> <output message="type:Array"/> </operation> </portType>

COP 4991 Component Based Software Development