Web services are designed to solve one unit of work and make it accessible in a platform independent fashion, from calculating a shipping rate to obtaining a stock quote, but when aggregated each of these units goes on to form part of a greater whole: a business process. In the same technical context as SOAP, WSDL and WS-* standards play a role in creating individual Web services. Business Process Execution Language (BPEL) focuses on the technical requirements needed to materialize a business process made up from web services. Read on as we take a closer look at the relationship between BPEL, Web services and the actual domain experts behind business processes.
Prior to even being thought out in terms of software, a business process comes to life from a brainstorming session among the most senior people in an organization, those who are most familiar with a given business process and have decided to digitize it. Anything from the procurement of products, a hiring process, to supply chain logistics is a good candidate for BPEL's high-level description capabilities.
But high-level as BPEL's syntax is typically considered -- when compared to the individual programming of Web services -- BPEL is still programmatic in nature, which makes it susceptible to certain technical decisions. When introduced for the first time at an organizational or project level, BPEL can defeat its own purpose especially if the lines between individual Web services have not been properly drawn. A primary tenet of effective BPEL use is precisely fostering service reuse.
Case in point, it is essential prior to even tinkering with the idea of BPEL, that a business process be broken down into manageable units of work, allowing each unit to be owned, developed and tested separately, something that not only increases the manageability through the classical divide-and-conquer development approach, but also simplifies many design issues involved with Web services. After all its one thing to design SOAP, WSDL and WS-* logic for a "fat" Web service and quite another for numerous "thin" Web services, with the added benefit that each "thin" Web service can later be stacked in different order or with different providers if the business requirements change.
Once each Web service cog is in working condition, materializing a BPEL process requires contemplating two important infrastructure pieces: an executing environment and tools. A BPEL environment -- sometimes refered to as a BPEL engine or simply BPM -- can come in many forms. There are the open source kind like ActiveBPEL , then there are the big vendor versions and there are others from niche players.
The BPEL engine selection process can be daunting, but is a critical step, not only because many are tightly pegged to BPEL tools, but also because many are bundled with additional offerings. Rich as BPEL's capabilities are for stitching together services, many vendors realize support beyond BPEL is a must for many enterprise business processes, from those reaching a little above the current BPEL specification -- like management and monitoring of business process -- to more sophisticated integration scenarios like the human aspects of a workflow or ERP-type interactions, which are often non-Web services. How many or which non-BPEL capabilities will you need to acquire are questions which can be answered dissecting your business processes to determine if they can be structured with standard Web services or will require support from some other technology.
On the tools front, since BPEL is based on XML syntax and the inspection of WSDL contracts which make up the underlying Web services that will fulfill a business process, using a tool is often a must. But while you might get away structuring BPEL based processes with one or two Web services in a simple XML editor, anything beyond this amount often entails using a more specialized tool, given that design choices ranging from security, transactions or fall-back alternatives have to be incorporated in a BPEL contract.
As noted earlier, you will see a strong correlation between tools and a BPEL runtime. Most tools are aimed not only at facilitating the deployment and design of actual BPEL processes, but also at aiding the incorporation of many non-BPEL features supported in a particular BPM, something which more than likely will force you into a strong commitment -- both in tools and runtime -- with one particular provider for all your BPEL needs.
Business processes are a universally understood concept, but when implemented with the particularities of Web services there are a series of issues which have to be contemplated beyond the common association with the BPEL standard, from the proper breakup of a business process into individual units; using SOAP, WSDL and WS-* in more manageable ways; to the actual selection of tools and runtime to support your BPM initiatives. Each one makes up one factor to take into account beyond BPEL.
About the Author
Daniel Rubio is a software consultant with over 10 years of experience in enterprise software development, having recently founded Mashup Soft, a startup specializing in the use Web services for Mashups. He is a technology enthusiast in all areas related to software platforms and maintains a blog on these topics.
