BPEL Glossary for Developers

[IvanaTrickovic]

Episode 2 in the BPEL podcast series. This short podcast is the second in a series of podcasts on BPEL. Following on from the previous edition which explained the business goal of BPEL and the problems it solves this podcast gives you an introduction to the important technical concepts behind BPEL by explaining the key terminology that is part of the BPEL specification:

• Partner Link Types
• Partner Links
• Abstract Processes
• Correlations
• Event Handlers
• Fault Handlers

In addition, the basic structure of BPEL is described, eliminating some of the fallacies associated with BPEL. The podcast is primarily intended for those who want to add BPEL to their vocabulary. Just download the media file and listen to it on your pc's speakers or transfer it to any mp3 player to accompany you on your next jog, shopping expedition... This is the complete series with new episodes following in the coming weeks:

1. BPEL in a Nutshell
2. BPEL glossary for developers (you're reading it)
3. WS-BPEL 2.0 from OASIS - How it has progressed since BPEL 1.1
4. BPEL4People White Paper Overview
5. BPEL-SPE - Explanation of the joint SAP/IBM sub-processes white paper

But - if you have other suggestions our ears are tuned-to-the-max so let us know what you want after you've listened to this introduction. To read these white papers or to find out about the other standards that SAP supports then you'll find all you want on the standards pages in SDN. Alan & Ivana *new 20.06.2007 we've added this transcript* Reasonable accurate transcript: BPEL glossary for Developers Good morning. My name is Alan Rickayzen and I’m here with Ivana Trickovic for the second in the series of podcasts aimed at preparing you for the latest developments taking place in BPEL. In the first podcast we gave a short overview of what BPEL is used for, why it is important in ERP software and how it completes the SOA picture. Today’s podcast goes into more detail about the inner-workings of BPEL by spotlighting the important and unique concepts behind BPEL in digestible nuggets. We’ll do this by explaining these nuggets in a step-by-step glossary approach. Ivana, lets just refresh our memories on the current status of BPEL in terms of transitioning from a de facto standard to a an open, sometimes known as, de jure standard. The Web Services Business Process Execution Language (WS-BPEL, BPEL4WS or BPEL for short) provides process definition capabilities in SOA and it is considered as one of the key building blocks of SOA. Version 1.1 published in May 2003 has been taken as input for an OASIS standardization process making it an open standard. The first version was an important step towards consolidating the area of business process execution languages. The language includes many concepts known from its predecessors – Web Services Flow Language (WSFL) and XLANG. Currently, the language is under an OASIS standardization process, in the public review phase, and will be finalized by the end of 2006 or beginning of 2007. Even before finalization of the standardization activity, many implementations of version 1.1 are available as open source or in commercial products such as SAP NetWeaver, making it a de-facto standard and development is underway to include the 2.0 changes in the existing SAP software. The BPEL language introduces the features needed to specify Web services-based business processes. It is an XML-based language which is built on top of WSDL, XPath, and XML Schema. Ivana, please say a few words about the overall structure of a BPEL definition. How restrictive is it? In order to reflect real world processes this standard can’t afford to be restrictive so it offers a choice of modeling approaches. The language uses both block-oriented and graph-oriented control flows. Block-oriented control flow could be understood as a special form of graph-oriented control flow. On one side it has less expressive power than graph-oriented control flow, but on the other side it is a simpler and more effective approach for process engineers because it is less error-prone. The modeling constructs assure per definition that the process definition at the end is well formed. Graph-oriented control flow requires some verification capabilities to be supported by modeling tools. However, using only the block-oriented approach may be too restrictive. It was a design decision to allow both approaches and leave it up to process engineers to use preferred one. So what sort of thing can you embed in the process itself. The correct term is an activity isn’t it? Yes, the language provides a set of primitive and structured activities. The set of primitive activities includes Web services interaction activities (consuming a message sent by an external service and sending a message to an external service by invoking a corresponding operation) and waiting. The set of structured activities includes activities known from other programming languages, such as ordered sequence of activities, iterations, conditional paths and parallel execution of multiple activities and deferred choice. A scope is used to define the context in which its enclosed activity is executed. The context may include different elements including process variables. The language also allows handling messages that may be received asynchronously within a certain time frame. For that event handlers are used. Besides messages, event handlers can trap user-defined timeouts. So we now know the terms, event handler, scopes and activities, let’s move onto partner links because this is a term that you’ll hear a lot when dealing with BPEL. The services with which a process interacts are modeled as partner links. Partner link types are used to describe the conversation relationship between two services by defining the roles played by each of the services. The language provides a mechanism to identify the target service dynamically, based on values in incoming messages. The set of services participating in a process as partners can vary during the execution of the process itself. For example, a process can start interaction with one service which will introduce another service as a partner during the process execution. For this a mechanism is provided that allows handling of services’ endpoint references. So an example of a partner link type is “Manufacturer” or “Customer” and the partner link would be Daimler Chrysler or a particular CRM system depending on whether this is a B2B (business to business) or A2A (application to application) scenario. Which leads me on to how BPEL reflects the real-world processes, in that sometimes things go wrong both on the technical or business side of things. Yes, there is a mechanism to partially “undo” a given set of activities. Web services are considered to be autonomous entities and their relationships with other Web services participating in the same business process are loose. This requires a different model for error handling and transactional behavior within the process context. The language provides a means to explicitly define which parts of the process must be managed in transactional way and which activities must be performed to partially undo the outcome of a set of activities. Fault handlers are used to specify activities that are going to be performed in order to reverse work, or to undo the partial and unsuccessful work of a scope in which the fault has occurred. In this case the scopes considered to be completed unsuccessfully. Okay – so we now know what fault handlers are. Now we move to my favorite term ‘correlation’. The language provides a mechanism to identify the target process instance. A service can be engaged in multiple conversations in parallel. A mechanism is needed to deliver messages to the correct instance of the process implementing such service. The language introduces the concept of correlation which describes values that must be carried in messages to identify the correct process instance. In other words, to identify the significance of incoming messages, you have to define business rules (correlations) which allow you to determine whether or not the message is relevant to an existing process or to trigger a new process. This is because in the real world the business documents in the messages coming from different partners will use different tags or even combinations of these to identify an identical entity. And in the real world you can’t force all participants in the process (here I’m thinking of legacy applications or big business partners here) to adapt their message structure to interoperate with the process. In BPEL, the flexibility is built into the process via correlations. Now lets look at the data itself. The language introduces data manipulation capabilities. Processes typically deal with process flow logic only, while application messages are generated by business logic encapsulated within Web services. However, process models must provide data manipulation capabilities in order to be able, for example, to aggregate a number of messages received from different source Web services and send the aggregated message to a target Web service. The language introduces some minimal data manipulation capabilities, and relies on other specifications which focus on the manipulation of XML documents for more advanced data manipulation features, such as XSLT. The language follows the idea of building Web services specifications in a composable and modular way. It is built on top of specifications which are considered to be the core of the XML technology and Web services stack. Technologies such as reliable messaging, distributed transactions on Web and security are absolutely necessary for executing processes both across enterprises and within an enterprise. Nevertheless, they are out of scope of the language and other specifications must be used in conjunction with the BPEL specification to provide these capabilities. Last but by no means least tell us about the term “abstract processes”. The language introduces the same concepts for both executable processes and observable behavior of Web services. With this approach it is easier to build valid executable completions of an abstract process, which provides the observable behavior of a Web service. A valid executable completion of an abstract process is an executable BPEL processes that follows the same order concerning the interactions with a particular partner or a set of partners as the abstract process it implements. The language provides in the upcoming version 2.0 a set of rules that must be followed in order to get a valid executable completion of an abstract process. For example, it is allowed to add additional Web service interaction steps but they must refer to partner links not used in the abstract process. Also, the presence or order of Web services interactions already present in the abstract processes must not be changed, and it is not allowed to change, using an explicit data manipulation activity, the endpoint references of partner links used in the abstract process. Whether or not a process is abstract or not is declared using tags within the BPEL definition. If this is an abstract process then certain other BPEL constructs such as the exit activity cannot be used. BPEL abstract processes complement abstract WSDL interfaces and the UDDI model. They define dependencies between service operations in the context of a message exchange. Technical note “Using BPEL4WS in a UDDI” describes the relationships between the three models and suggests how BPEL abstract processes can be used in a UDDI Registry. Ivana, we’ve said that this is a developer glossary but we haven’t talked about java or ABAP or any other language in this podcast at all. That is because BPEL is in itself a language – with an xml representation - which defines the way a process executes. So all that has to be done once you’ve composed the xml code (usually in a graphical editor such as the process editor in SAP NetWeaver, then you simply compile it and run it on the BPE engine. Thank you Ivana, that concludes this podcast – the next podcast will take you through the important differences between BPEL 1.1. and BPEL 2.0 which is now in the public review stage. Thank your for listening, and enjoy the rest of the day.

[Former Member]

Incorrect link or missing file?

[IvanaTrickovic]

There were some technical problems, so please try again. It should work now. If you experience the same problem again, or other problems, please contact the SDN support team at sapnetwork@sap.com.

[Former Member]

Still not possible to download media

[IvanaTrickovic]

This seems to be not a general problem. Please try again directly through SDN. If this still does not work please contact either the SDN support team at sapnetwork@sap.com or Craig Cmehil at craig.cmehil@sap.com.

Regards,

Ivana

[marilyn_pratt]

Looks like there was an https missing as one of our contributors thankfully pointed out.  Have just fixed it and it should be working now.
best,
Marilyn