The arc following our steps from isolated systems, through data integration, function exposure, and composite services, has been quite a journey. Stepping back and examining our handiwork, we have created a supremely flexible web services data infrastructure, without disrupting out foundational applications and operations in the least. The last item in this series of articles will cover process management using the latest maturing standard for Web Services and SOA architectures, Business Process Execution Language for Web Services (BPEL4WS or BPEL).
Virtuoso Universal Server incorporates a BPEL engine that allows one to create a composite process layer one level of abstraction above the WSDL executable end-points explained in the previous articles. BPEL is a medium for creating composite WSDL processes with the added benefit of process coordination internally or with external partners.
BPEL is an evolving yet rapidly maturing standard; we naturally expect our tools to be as transparent as possible, hiding as much complexity as can be expected.
In this article, we will examine the strategic use of BPEL as an integration process enabling tool. BPEL4WS - Business Process Execution Language for Web Services
Drawing a page from current and past practices, we can see that the composite services we have created from individual executable application end-points are ready for invocation - yet where will these services be coordinated' Typical programs of yore would have master event loops pending on our partner processes. More contemporary, pre-web services applications have had applications call service container classes that handled messages in queues, etc.
Today, we have standardized Web Services built atop XML, SOAP, WSDL - in that order, and now BPEL. BPEL extends the WS model by allowing composition of your WSDL services into processes. BPEL is a W3C XML standardized language that directs business processes from the top down. Whereas one used to code the event loops or custom messaging scripts to pend or spawn processes, we now create BPEL Partner Links, Activities, and Ports, which call and combine our executable URI services. It's a very different paradigm, and one that seems to make more sense, as standardized XML language modules (BPEL) used to create and service processes can be archived and exchanged for commonly used services. BPEL allows a natural division of process orchestration separated from the application logic called in your WSDL executable URI's.
Bits of modular BPEL code are becoming increasingly available for all types macro processes, such as loan approval processes. This evolution mirrors the modular code library revolution, but from a top down and WS standards-based POV. It's an improvement over proprietary MOM [1] systems, DBMS EAI, and vendor specific processes orientation, such as MS BizTalk (Which is, as of the writing of this article, catering to BPEL, as is the Oracle J2EE camp!).
As a way to manage pending processes internally or between new partners or internal systems integrations, BPEL fits into a web services integration strategy quite nicely. BPEL deals only with business processes: control flow (branch, loop, parallel),asynchronous event handling, long-running nested units of work, faults, and recovery methods. Do not confuse BPEL with work-flow - there is no concept of users or people. Rather, think of BPEL processes as collections of web services enabled URIs, expressed as WSDL, and subjected to definitions of process, procedures, and partner relationships.
The meta model of BPEL is expressed as two types of partner process definitions: 1) Abstract Processes, and 2) Executable Processes.
Abstract Processes are BPEL services that expose only the public aspect of a business process, without regard to how partners might implement the execution of a service. An Executable Process exposes the complete state of the details involved in determining the sequence of interactions of the partners. Executable processes are likely found in integration scenarios where the partners (even internal departments), must have certain system and session dependent data shared, for expediency. Fully abstracting a process, in any system or programming model, may be difficult in certain circumstances.
There is no sharp division for the need of deciding between the Abstract and Executable, as processes need not be fully defined in private implementations. BPEL is merely a neutral web service class for business processes using XML data.
Merger dependent processes will execute against partner services consistently, no matter where you 'draw the line' in your infrastructure or code. In other words, one can compose and expose web services, couple these services to BPEL partner links and ports (services collections), and the rest is anyone's game - one is not required to fully define the process in BPEL.
The beauty of BPEL4WS is the incremental nature of how it fits the web services model. Harking back to the terminating paragraph of the last section, we can indeed envision certain simple processes defined for the dispatching of simple, synchronous processes that return ready results in a single session. As our maturity inevitably develops across the entire web services spectrum, and as we develop more exposed code and SQL procedures, our opportunity for deploying BPEL will increase and we can match up more complex business processes for receiving asynchronous results.
But the most exciting news is that BPEL4WS complexity will likely fade as more design-time tools hide the details from our tender hearts; UML, IDE's, and new front-ends will likely make the nitty-gritty of BPEL less irksome. Starting gently with the Virtuoso Forms based BPEL tool, and persevering, will likely net a GUI based design
[1] Messaging Oriented Middleware