WS-BPEL 2.0 is the dominant specification to standardize orchestration logic and process automation between Web services. The BPEL model is used to assemble a set of discrete, essentially disparate, services into an end-to-end process flow to transform the existing stateless and uncorrelated Web service infrastructure into cohesive, process-centric applications based on a service-oriented architecture.
Under this model, new applications are developed "on-the-fly" by wiring together external "partner" services that leverage existing enterprise assets. JBoss's jBPM product is an open source platform for BPEL as well as other graph-based execution languages and provides the runtime infrastructure: interpretion, extraction/WSDL document publishing, flow execution, analytics, transactional and persistence support for the deployed service composition model. A use case example demonstrates a simplified process domain comprising of a composite service that consists of two partner relationships: JAX-RPC synchronous and asynchronous service endpoints, respectively.
Web services represent the building blocks of a service-oriented architecture and use a loosely coupled, interoperable, reusable and discoverable model to allow for flexible integration of heterogeneous systems in a variety of domains: business-to-consumer, business-to-business and enterprise application integration.
With the maturity of the JCP specifications (popularly JAX-RPC, JAX-WS and JAX-RS) and various reference implementations and tools supporting the individual technology stacks (WS-* or REST), it is relatively easy to create single service endpoints [1] (or as in the case of REST, Web resources [2]), each encapsulating a unique functionality and have it invoked by one or more clients. However, for more complex systems that require coordinating between multiple services, for example, system integration efforts connecting home-grown legacy systems to ERP and other enterprise systems for fulfillment of a unique business goal require more than just the ability to conduct simple interactions by using standard protocols and the stateless WSDL-supported model of request-response or uncorrelated one-way interactions. What is required is a way for applications and business processes to integrate their complex interactions by using a standard process integration model. The real promise of SOA is not realized by building and consuming disparate services alone but by defining clear cohesive services that wholly describe their interactions that are then capable of being reused, through composition, in a variety of process-based services. Therefore, what you really need in such cases is a way to conveniently express the flow in business semantics, something that sufficiently abstracts away the individual services within a process context, executed on the server; and ultimately exposes a WSDL that can then be called on by a Web service client. In the world of SOA this is called an orchestration and often executed using BPEL, or Business Process Execution Language [3].
About BPEL
WS-BPEL 2.0, the latest underlying OASIS standard around which most current BPEL implementations are based, leverages Web services as the model for process decomposition and defines an XML-based "model and a grammar for describing the behavior of a business process based on interactions between the process and its partners. The interaction with each partner occurs through Web service interfaces" [4]. In essence, WS-BPEL defines how interactions with these partners are orchestrated (coordinated) to achieve a business goal.
A deployed BPEL application represents a new and complex composite service that is composed of basic services and the various interactions/message exchanges between them. BPEL defines an executable language for specifying interactions with these basic Web services that support some of the commonly used features of a WS-* process language construct: XML and WSDL typed variables, property-based message correlations, expressions and queries using XPath, transformations using XSLT, fault/event handlers along with structured logic constructs and flow directives and support for robust workflow features such as parallel execution, flow sequencing and chaining
Common representations are in an XML-formatted document with a .bpel extension that conforms to the WS-BPEL standard and executes within the BPEL engine environment, which provides the interpretion, execution, analytics, transactional support, and persistence store for the deployed model service composition. The interactions with the external entities are abstract in the sense that the dependence is on port type operations and message definitions represented via XML schemas, thereby abstracting business logic into flow directives, which encourages high cohesion and loose coupling between the service implementations.
About jBPM-BPEL
JBoss/RedHat's jBPM is an open source platform for graph-based execution languages [5]. Its pluggable architecture makes it possible to support different workflow languages (mainly jPDL and BPEL) that can be modeled as some kind of abstract flow directive. jPDL (Java Process Definition Language) is jBPM's native workflow language and is similar to BPEL in as much as it was created to model and assemble a discrete set of processes into an end-to-end process flow. This is where the similarity ends, with the main difference being that in jPDL the variable context for the process data is made up of Java POJOs whereas BPEL processes use XML constructs. BPEL is the focus of this article so I'll not delve further on the differences between the two process technology stacks. However, it's worthwhile to note that BPEL is more widely adopted and supported. The main reason being, most business processes involve frequent interactions with heterogeneous systems and partners with interoperability/platform independence being essential. Factor in XML as the populist (efficient, manipulable, interoperable and developer-friendly) message exchange mechanism along with QoS demands for an increasingly wired world and now you know why.
jBPM is built upon a persistence model with Hibernate as its default object-relational mapping solution [6]. This means that installation of the jBPM-BPEL software involves deploying an enterprise archive (.EAR) component (containing required libraries and configuration files) along with configuring a Data Source (pointing to a jBPM database) within the application server. Once successfully deployed, the jBPM-BPEL runtime is ready to extract new process definitions, create process service endpoints, publish WSDL contracts and orchestrate the composite service all of whose state is persisted within the jBPM database.
An Example Process Domain
Figure 1 shows a highly simplified Process domain comprising of a composite service that consists of two partner services: a POJO synchronous service endpoint represented by Forms and a POJO asynchronous endpoint represented by Imaging. In actuality, the partners represent our internal Forms Management and Imaging systems, respectively, whose interactions can be captured in a BPEL workflow and deployed to a jBPM-BPEL runtime engine to collectively work in rendering PDF documents that are then archived away as image files.
The Forms system consists of a JAX-RPC document-style POJO endpoint implemented by JBoss's very own JAX-RPC SOAP stack, the JBossWS framework. The Service Endpoint Interface (SEI) and implementation bean for this service are shown in Listing 1. (Listings 1 - 10 can be downloaded here.) JAX-RPC endpoints leverage the slightly older J2EE 1.4 programming model, which requires packaging of a number of deployable descriptors for the Web service [7] (newer specifications like JAX-WS does away with most descriptors by providing all endpoint associated metadata via annotations [8] that perform compile/runtime dependency injections, thereby greatly simplying the development model). However, WS-BPEL is not supported by JAX-WS, therefore we are limited to using JAX-RPC endpoints for our external service implementations for use by the BPEL composite process.
A number of deployment descriptors need to be created prior to packaging this endpoint and bean implementation (see Listing 1); the webservices.xml descriptor that identifies the deployment of a Web service endpoint, the abstract service WSDL contract and the jaxrpc-mapping.xml descriptor that maps the WSDL document schema elements to Java classes. JBossWS comes with a handy wstools utility that creates all the aforementioned artifacts either from the command line or at build time. The POJO endpoint is packaged as a Web application in a WAR file and is deployed as a servlet accessible via a URL pattern. Once the services are packaged this way and deployed to a JBossWS compliant application server, they are then visible via the Web service console at http://<machine>:8080/jbossws/services.
The Imaging system upon receiving the PDF rendered form (represented as binary stream data) will initiate the image archival process (internal details of which are best left out as they are beyond the scope of this article), an asynchronous component, which finally returns a response consisting of an image index and a system message on a JMS message queue. Other than this, development and packaging of the Imaging service endpoint (ImagingPT) is very similar to what was done earlier for the FormsPT SEI and Service implementation.
Once the partner or external system endpoints have been developed and deployed, we need to let jBPM-BPEL know about its existence. This is typically done through the Partner Sevices Catalog available under the jBPM-BPEL console (http://<machine>:8080/jbpm-bpel/partners.jsp) (refer to Table 1).
A process scenario would have the central orchestrating service call the Forms system with a set of parameters (form design number, form field data etc.) to render a pre-populated PDF form. Next, it would send the PDF form (represented as a byte array data) to the Imaging system to initiate the image archival process. The imaging system responds asynchronously on a JMS queue with the image index and a system message that is then picked up by a MessageDrivenBean (deployed along with the Imaging endpoint) listening on the same queue, which calls back into the orchestrating service, triggered upon receipt of the javax.jms.Message. The service then bundles all the return values into an invoice which is sent back to the calling client of the process.
BPEL Process Development Methodology
There are two main options for designing a business process: Top-Down or Bottom-Up [9]. Both methods lend themselves to a design approach using a visual BPEL process designer of which there are quite a few open source options.
The Top-Down approach is as its name suggests. Essentially, you model all the intermediary (partner) components that make up the composite service. This may involve interviewing business stakeholders and analysts to come up with the ideal service parameter definitions and return values. You basically would want to view the services and compositions from the invoker's point of view, which would necessitate keeping the service granularity at the appropriate level of abstraction. Once done, you can start adding technical details to the process such as port types, schemas, partner links, variables, scopes, sequences, conditional logic, error handling and other task activities to build out an orchestration of the composite service. This design method suits those enterprises that need to develop new partner services and processes from scratch and is what we used.
Alternately, using a Bottom-Up method involves using pre-existing services and the WSDL documents available within your environment to create out the orchestrated business processes wherin you would add the technical details to the process exactly the same way as in the Top-Down approach.
Creating the BPEL Process Definition Document
The BPEL process definition document models the entire workflow in XML, which upon deployment is interpreted and translated by the jBPM-BPEL runtime engine to provide the runtime infrastructure as a centralized orchestrating composite service with its own endpoint and service WSDL contract. This section goes over the basic structure and content of the BPEL document for the example process domain as illustrated in Figure 1.
a. Creating Partner Links and Defining Related Port Types
The <process> element is the root element of all BPEL process definition documents. It declares all the namespaces used within the process (including that of itself) and imports the namespaces for all external or partner services. The namespace declaration is http://docs.oasis-open.org/wsbpel/2.0/process/executable, which is the standard root namespace for all BPEL 2.0 processes. The <import> element is used to declare a dependancy on either an XML schema or the WSDL contract of an external or partner service that must exist in the same relative path (attribute "location") as the central process document and qualify all imported definitions with the namespace attribute. In our example described earlier, the process imports a WSDL file that defines the partner links that it uses and is available in the same directory as the BPEL file along with two other separate WSDL files, for the previously deployed Forms and Imaging endpoints (refer to Listing 2 - a section of the BPEL process document).
Partner links are made available within a BPEL document by adding the namespace of "xmlns:plnk=http://docs.oasis-open.org/wsbpel/2.0/plnktype" and can be thought of as analogous to business partners; they define the different external entities that are consulted during the execution of the business process and define the relationship between the Web services involved in the process fulfillment. The partner link represents an interaction between the central orchestrating service and the external service by indicating the port types used in the relationship (see Listing 3) and is characterized by a partner link type that defines the roles played by each of the services in the context of the conversation. Each partner link type defines essentially two roles: myRole, which indicates the role of the process itself in the relationship, and partnerRole, which indicates the role of the partner. The process document snippet in Listing 2 defines three partner link types (one for the orchestrating service workflowLT and one each for the external services that are invoked formsLT and imagingLT) described by their respective port types in the process WSDL document as shown in Listing 3. Note that the port types, which are an abstraction of the service endpoint interface (SEI) (frm:FormsPT and img:ImagingPT, respectively), are defined in the Forms and Imaging service WSDL definition files that were imported previously into the process context. Therefore, the formsLT partner link type is a conversational relationship, initiated by the process, with the Forms SEI that is defined by port type frm:FormsPT. The workflowLT is initiated by an external client that calls the process whose conversation involves the SEI for the process (defined as pos:workflowPT within the context of the process WSDL definition and shown in Listing 4). The imagingLT has two roles: one that is initiated by the process calling into the Imaging endpoint SEI that is defined by the port type img:ImagingPT and the other is a callback into the process initiated by the asynchronous Imaging service. How that callback exactly occurs is detailed in a later section. It's important to point out that upon deployment of this BPEL process document, each myRole definition on the partner link results in publication of as many port types all served by the same central composite service. Please refer to Listing 5 for a snippet of the composite service's WSDL document created by jBPM-BPEL upon deployment and available under http://<machine>:8080/jbossws/services.
b. Creating Process Flow Directives
A BPEL process runtime life-cycle in its most basic form involves receiving a SOAP message, working with the message data in the form of variables, invoking partner web services either in sequence or in parallel to complete different steps in the process, aggregating the response from the various partner services into an outbound message and then replying to the invoker. Let's go over how this can be modeled in the BPEL process definition document.
The <sequence> activity defines a collection of activities that should be executed sequentially. There can be multiple <sequence> activities, each representing an individual collection of sub-activities needing to be executed in sequence, embedded within the root <sequence> node (refer to the Listing 6 snippet of the BPEL process definition document). The <flow> activity describes parallel paths of execution and as shown in Listing 6 and embeds the partner sequences both of which will be executed concurrently at runtime. The <receive> activity is the port of entry for a process. It represents the first item in a process that will be invoked when a message arrives. Essentially, the process waits for the message to arrive that matches the definition in the <receive> activity particularly with regards to the port type and related operation, input, output and fault messages metadata (in our case the BPEL process will consist of a second <receive> activity defined to capture the asynchronous callback message on the process callback port imagingCallbackPT). This activity captures the incoming message into a global variable "WFRequest" that is available for the remainder of the process (refer to Listing 6). It's important to point out that variables used within a BPEL process must be WSDL message types described or imported within the process context, which once defined can be assigned, queried upon using XPath expressions, transformed or used as input to subsequent service invocations.
Listing 7 is a section of the BPEL document showing the process sequence for the conversation with the Forms service endpoint as described in Listing 1. The <assign> activity consists of copying variable data and can also be used to extract or create new data off message schemas based on XPath expressions. In the assignment PrepareFormsVariables the process is simply copying the message part from the global variable "WFRequest", defined earlier, into the message part of a new variable "formRenderRequest" that is used as the parameter message to that service. The <invoke> activity is what the name suggests, it invokes a partner service defined via the partner links construct as was described earlier. Listing 7 shows an example <invoke> activity in the flow sequence for the BPEL process to converse with the external Forms system that was described earlier as a partner link. The port type "frm:FormsPT" indicates the port type on the partner to use (described in the FormsPTService.wsdl document that was imported earlier), the operation "renderPDF" specifies the operation to invoke on the service while the inputVariable and outputVariable point to a variable containing the message or message part data that is used as parameter and response, respectively, from the service during invocation.
One of the message parts of the output variable "formRenderResponse" from the forms system <invoke> activity contains the PDF form content of the pre-populated form as a binary byte array. This needs to be assigned to a message part of the global variable "imagingRequest" that is of WSDL message type "img:ImagingPT_performImageArchival" and used as a parameter to the actual invocation of the Imaging service partner link (refer to Listing 8). Since the binary stream data (PDF) needs to be available before it gets imaged, the <invoke> activity to the forms system needs to be complete prior to the invocation on the Imaging system. Since both the "FormRendering" and "Imaging" <sequence> activities are defined to be part of the parallel <flow> activity, we cannot be absolutely certain that the "RequestFormRender" invocation be complete first. Therefore, we use a BPEL <link> activity "forms-to-imaging" within the <flow> to express this dependency exclusively. The elements <sources> and <targets> respectively contain <source> and <target> elements, which are used to establish this flow relationship for synchronizing the related activities (refer to Listings 7 and 8). Listing 8 also features a <receive> activity receiving the callback message on the callback port type defined by the partner links mechanism in the BPEL document (refer to Listings 3, 4 and 5).
The <reply> activity is usually the final activity within the BPEL process. Once the message has been received and the various intermediary partner links (forms, imaging) have been invoked, the callback has been received, in essence the entire message exchange processing is complete and you would want to send back a response of some kind aggregated with the message responses from the partner systems. This is done using the <reply> activity that is similar in definition to the process's root <receive> activity with regards to the port type and operation but happens in the opposite direction in replying to the calling client of the BPEL process.
Deploying the BPEL Process Definition
A BPEL process definition is comprised of the BPEL process document, the related WSDL contract defining the process port types/operations and partner links, the partner WSDL documents, and other relevant schema files. This mass of files, also called Process Archive, need to be bundled into a .ZIP file and deployed to the jBPM-BPEL runtime under your application server. jBPM provides an automatic discovery mechanism that looks for files under the zipped process archive for the .bpel process document that internally indicates the location of the interface WSDL and schema document. The jBPM DeploymentServlet will deploy the process definition by registering the process service endpoint and publishing the process WSDL files. The deployed process definitions are available under the jBPM-BPEL console http://<machine>:8080/jbpm-bpel/processes.jsp. At this point, the BPEL process is fully available to external clients as a composite service, aptly called WorkflowOrderService (please refer to Listing 5).
Imaging System Callback
In an earlier section I had mentioned the Imaging system responding in an asynchronous manner on a JMS message queue with the status of the image archival process. A MessageDrivenBean (MDB) listening on that particular JMS queue will upon receipt of the javax.jms.Message trigger a callback into the imagingCallbackPT (shown in Listing 5) of the deployed composite service (identified in the program listing by JNDI context "service/WorkflowOrder" and "WorkflowOrderService" in the generated composite service's WSDL document). Listing 9 describes how that works. The MessageDrivenBean is created in the standard J2EE 1.4 manner along with the required ejb-jar.xml descriptor (containing bean definitions, the message desination it must listen on and the JNDI service reference context that includes the WSDL document of the composite service) and deployed on the same server as the Imaging endpoint.
Developing the Client Assembly for the Process
There are a few different approaches in developing the clients for the composite service assembly we just created and deployed to the BPEL runtime engine. If you set up a JAX-RPC Web service endpoint, which our orchestration service eventually ends up as upon deployment to the server, you can leverage the J2EE 1.4 client programming model using any of the JAX-RPC implementing frameworks like JBossWS or the Java Web Services Developer Pack (JWSDP). The J2EE 1.4 platform supports the WS-I Basic Profile that basically ensures that the Web services developed are portable across any JAX-RPC implementation and interoperable with other Web services (like those created using .NET or other competing platforms) supporting the same profile.
For the purpose of illustrating this, I have described a client assembly developed using the JWSDP's wscompile tool to create the required client artifacts like SEIs, User Types, Exception Types, Serializers and the WSDL/Java mapping meta data jaxrpc-mapping.xml file (as stated earlier, you could just as well have used the JBossWS wstools utility to do the same). Essentially there are three types of Web service clients: Static Stubs, Dynamic Proxy and Dynamic Invocation Interface (DII) [10]. A static stub is essentially a Java class that is statically bound to an SEI. The stub, or client proxy object, is generated using the wscompile (or wstools) utility with the aid of a configuration file and defines all the methods that the SEI defines. Both utilities read the composite service's WSDL file (the location of which is specified in the configuration file) and generate the runtime files based on information in the WSDL file. I like the fact that the static stub approach requires less effort to create the plumbing in order to talk to Web service endpoints even though we must regenerate the stub and other infrastructure files each time our composite service's WSDL contract changes.
Among the mass of files that the wscompile tool generates is the stub (WorkflowPT_Stub) and Implementation WorkflowOrderService_Impl class. Listing 10 shows a simple Java client for our WorkflowPT composite service. Note that a stub object is created using the WorkflowOrderService_Impl object that maps Java to XML and assembles the SOAP message to be sent. The endpoint address that the stub uses to access the service is set and then the stub is cast to the WorkflowPT SEI. Next, the input and return parameter objects to the service are then defined and set. Last, the initiateWorkflow() method is called on the stub, passing in the input parameter objects, to begin the runtime process of assemblying the SOAP message to to be passed on to the appropriate SOAP handler and thereby on to the endpoint service implementation by the BPEL runtime which triggers the process workflow that was defined earlier.
Conclusion
BPEL is typically used for complex processes that require coordinating between multiple services to fulfill a centralized business goal and is currently the most portable way to integrate complex interactions by using a standard process integration model. BPEL supports some of the commonly used features of a WS-* process language construct such as XML and WSDL typed variables, property based message correlations, expressions and queries using XPath, transformations using XSLT, fault/event handlers along with structured logic constructs and flow directives and support for robust workflow features such as parallel execution, flow sequencing and chaining. The JBoss jBPM platform provides the runtime infrastructure and persistence model on which the compositions can be deployed and executed. Building composite services this way, abstracted into message interactions baked into platform-independent XML, all working towards the fulfillment of a common business goal showcases the key design principles of SOA: cohesiveness, loose coupling, interoperability and reusability.
References
- "An SOA Case Study: Integrating Adobe LiveCycle Forms using JBossWS" by Rizwan Ahmed, SOA Magazine July 2009.
- "RESTful SOA with Open Source" by Rizwan Ahmed, SOA Magazine August 2009.
- "Business Process Execution Language", Wikipedia.org.
- "Web Services Business Process Execution Language version 2.0", OASIS Standard.
- "Introduction to jBPM-BPEL", JBoss.com User documentation.
- "jBPM User Guide - Chapter 7: Persistence".
- "JBossWS- JAX RPC User Guide", JBoss.org.
- "JBossWS - User Guide", JBoss.org.
- "Java SOA Cookbook" by Eben Hewitt, O'Reilly Media Inc.
- "Developing Web Services with Java Enterprise Edition 1.4 Platform".