First, can you give me a very quick summary of BPEL, BPEL4WS, BPM, and BPM?
First, go toss back a few and then come back here .
Business process modeling, also known as “business process choreography” or “service orchestration”, is a technology that allows semi-technical people to graphically program how information flows through a company’s various software processes to accomplish some kind of larger task. The programming is usually accomplished by making simple changes to flow-chart like diagrams . Business process modeling software allows business leaders to issue corporate process changes through software (such as “orders should flow from the order entry system to the accounting system first, then to manufacturing, and finally proceed to the shipping system”). Business process modeling software usually claims to support easy changes like “wait…on second thought…for very large orders get a manager’s written approval first before going to manufacturing.” It also provides a number of mechanisms to support error conditions and the correct handling of asynchronous events (like “hold your horses - we just got a new shipment of product X”).
So what's the promise of Business Process Modeling?
The emphasis in business process modeling is on connecting systems together rather than on implementing those systems. It allows business leaders to focus on problems at higher levels. They become more concerned with what information is getting shipped rather than the nuances of each supporting software system. They begin to see the company in terms of messages and available services. They create understandable business flows, can nest those flows inside of other flows, and can even publish business flows as new web services . The principle benefit here is that vast business processes are clearly presented and easily altered. A secondary benefit is that process modeling focuses entirely on interfaces and messaging and does not concern itself with service implementation. Focusing on interfaces is important since, after systems mature, far more coding effort is spent on connecting existing systems together than on altering algorithms inside of those systems. The claim of Business Process Modeling is that it’s the answer to the problem of making system integration flexible and fast.
So in a nutshell, how does BPEL work?
BPEL (also known as “BPEL4WS”) is one of a few competing programming languages that captures the information in business process models. The controlling software that ultimately executes each business flow is call the BPM (for Business Process Manager). That program reads BPEL files at runtime to execute each step (or “activity”) in the flow and determines what information should be passed to each successive process or web service. BPEL acts as the glue that holds the company’s web services together and gets them to interoperate, but in a comprehensible and reusable manner . It’s important to note that BPEL can’t do much on its own – it only coordinates the execution order and information exchange of remote web services. BPEL is generally regarded as too complex to read, although error messages often spit out raw BPEL.
But the sales guys tell us that the modeling software is separate from the business process execution software?
Some vendors (like IBM) separate the Business Process Modeling tool from the Business Process Execution tooling. That is, they provide a very high level tool to view the corporate flows and simulate the effect of various corporate flow changes without really having to make them in production. Executives use this tool to experiment with hypothetical scenarios such as simulating how customer response time will improve if inventory is checked just prior to shipping, for example. The modeling tool simulates anticipated work loads and even frequently encountered business hiccups. These kinds of high level modeling tools eventually export the final model to be imported by one of the BPEL tools. The BPEL tools then focus on the sundry details of web services. Supposedly the Business Modeling Tool output can be iterated back and forth with the BPEL tooling, but this is certainly a leading edge and untested technology in industry (as is BPEL itself). Other vendors simply consolidate modeling with BPEL tooling and make little distinction between process modeling verses the construction of BPEL flows.
Give me a 20 second lesson in BPEL.
BPEL, a programming language constructed entirely with XML, has a number of interesting features. There are provisions to use logic to decide which web service to call , to loop, to run operations in parallel, to respond to asynchronous events, to establish scope for variables, to throw exceptions, and in some implementations to allow for human intervention at certain steps (as would be the case in requiring a manager’s signature). BPEL provides a “pick” activity so that different logic can be executed depending on the type of message received. Using “correlation sets”, BPEL also has the ability to send asynchronous “fire and forget” messages to a web service, suspend the flow, and then much later receive a response, correlate that response back to the original sending flow, and awaken the flow to resume processing. BPEL has mechanisms to define “abstract” web services so that processes can be defined for services that have not yet been implemented, thus supporting an interface-first implementation approach, if desired.
Now give me a 10 second demo
Shown below is a vendor-neutral drawing of an extremely simple business flow as it might appear in a business process execution language tool. This particular flow receives a message, uses that information to prepare its own message to a remote web service, calls that web service, gets back a response, extracts the appropriate values for its own reply, and then stops. While the BPEL generation tools provided by IBM or Oracle would have much fancier graphics and icons, both tools would produce extremely similar looking flow diagrams. Both vendors would display a flow diagram that looks similar to this one:
A fragment of the actual BPEL file (an XML file) that implements this flow might look a little like:
Wrap it up, I'm out of time
Popular BPEL servers include IBM’s WebSphere Process Server, Oracle’s Business Process Manager, and Sonic’s BPEL Server. Microsoft’s Windows Workflow Foundation and Biztalk have the ability to import BPEL as well as other business process modeling languages.
The concepts of Business Process Modeling and Execution are frequently interleaved with the concepts of Enterprise Service Buses (see the ESB page). Without getting into the analysis of ESBs here, it’s worth noting that underlying any BPEL runtime engine is an Enterprise Service Bus. It’s the bus that allows the BPEL engine to talk to the services.
What are the common mistakes that business process modeling projects make, time after time, costing companies millions of dollars?
BPEL is a powerful but dangerous technology in the sense that it can be a very productive tool if used appropriately, but at least 85% of BPEL projects misuse the technology and end up in utter disaster. So what kinds of business problems are appropriate for BPEL and which ones are not? As you've read above in the excerpt from our book, modeling software comes with a lot of grand promises. Unfortunately it can only deliver on a few of those promises. But which ones? And where is BPEL going in the next few years? What are the alternatives to using it? Don't trust the people who deal with these products only in the proof-of-concept, optimistic, theoretical realm. Instead, leverage off the experience we've gathered from getting real business process modeling projects up and running at actual client sites. Hopefully, at the very least, you’ll get a chuckle or two from the read and you might save yourself a lot of headaches as well. Weigh the costs (only $65.00) against the benefits, and then click the “Buy Now” button below!