What’s the big deal about BPEL
Courtesy of this news release from InfoWorld, I found out that Microsoft Windows Workflow Foundation (WWF, which has nothing to do with endangered animals or professional wrestlers) is going to support BPEL. This is a good thing, but what does it really mean?
I’ll admit that I’ve never gotten very excited about BPEL. My view has always been that it’s really important as an import/export format. You should have a line item on your RFI/RFP that says, “supports import/export of BPEL.” You should ask the sales guy to demonstrate it during a hands-on section. Beyond this, however, what’s the big deal?
The BPM tools I’ve seen (I’ll admit that I haven’t seen them all nor even a majority of them) all have a nice graphical editor where you drag various shapes and connectors around, and they probably have some tree-like view where you draw lines between your input structure and your output structure. At best, you may need to hand code some XPath and some very basic expressions. The intent of this environment is to extract the “business process” from the actual business services where the heavy duty processing occurs. If you sort through the marketing hype, you’ll understand that this is all part of a drive to raise the level of abstraction and allow IT systems to be leveraged more efficiently. While we may not be there yet, the intent is to get tools into the hands of the people driving the requirements for IT- the business. Do you want your business users firing up XML Spy and spending their time writing BPEL? I certainly don’t.
What are the important factors that we should be concerned about with our BPM technologies, then? Repeating a common theme you’ve seen on this blog, it’s the M: Management. No one should need to see BPEL unless you’re migrating from one engine to another. There shouldn’t be a reason to exchange BPEL between partners, because it’s an execution language. Each partner executes their own processes, so the key concern is the services that allow them to integrate, not the behind the scenes execution. What is important is seeing the metrics associated with the execution of the processes to gain an understanding of the bottlenecks that can occur. You can have many, many moving parts in an orchestration. Your true business process (that’s why it was in quotes earlier) probably spans multiple automated processes (where BPEL applies), multiple services, multiple systems, and multiple human interactions. Ultimately, the process is judged by the experiences of the humans involved, and if they start complaining, how do you figure out where the problems are? How do you understand how other forces (e.g. market news, company initiatives, etc.) influence the performance of those processes. I’d much rather see all of the vendors announcing support for BPEL begin announcing support for some standard way of externalizing the metrics associated with process execution for a unified business process management view of what’s occurring, regardless of the platforms where everything is running, or how many firewalls need to be traversed.
6 Responses to “What’s the big deal about BPEL”
Leave a Reply
Hi Todd – I’m a BPM newbie and have a question about this comment:
“There shouldn’t be a reason to exchange BPEL between partners, because it’s an execution language. Each partner executes their own processes, so the key concern is the services that allow them to integrate, not the behind the scenes execution. ”
What about a scenario when businesses want Business process management (BPM) integration with supply chain partners – can BPEL play any part here at all? For eg,: a buyer and seller have BPM integrated their buy/sell process. The buyer’s user sends a PO to the seller, and his BPM system only allows him to cancel the order _until_ it is picked in the seller’s warehouse. What standards or frameworks would be used to achieve this level of process coordination?
BPEL can certainly be used in this scenario, but it would only orchestrate the services on each end, not across both. For example, in the order cancellation example you gave, the buyer may have no visibility into the rules regarding cancellation. From their perspective, it’s simply a service request of “Cancel Order”. In the automated processing behind the scenes at the seller (which could be done using BPEL), the business rules would be applied to determine whether to send a “Sorry, can’t cancel anymore” or “Cancellation successful” message.
Thanks for helping me out with that Todd!
Carrying on a bit with our example… (humor me 🙂
1. Wouldn’t it be better for the buyer’s BPM to indicate whether or not order cancellation was allowed for an order, prior to the action. For eg, a buyer may want to cancel two orders – one for a machine, the other for it’s fuel – but only if both could be cancelled together.
Perhaps the seller’s system could send generic ‘model-state-update’ document that enable/disable actions or even sections of specific process instances on the buyer’s system
Do you know of any technology to constrain or change model instances during execution?
2. For this to be possible, the seller’s system would need knowledge of the BPM model in the buyer’s system. What if the order fulfillment part of the model actually originated from the seller — i.e. at B2B integration setup time, the buyer’s IT personnel dynamically imported the order fulfillment part of the ordering model from the seller’s system and mapped it to stubs on their process model.
Something like this: (forgive formatting errors)
Buyer’s Ordering Model | Sellers’ Order Fulfillment SubModel
… Order Transmit Stub (o) (o) Receive Order Stub
… Other Stubs (o) (o) Other stubs
… Invoice Receive Stub (o) (o) Transmit Invoice Stub
Do you know of any technology to do this?
— Sonam
The challenge with this is in trying to capture the dynamic rules that may be applied. While this is probably best answered by a BPEL expert, my gut tells me that it’s going to difficult, because whether you’re using BPEL, Java, C++, or anything else, it’s based upon a design-time understanding of the service interfaces.
Using your example, if the supplier provided both a cancellation service, as well as a cancellation inquiry service, they could still keep the rules within the boundaries of their service, and yet provide the buyer the information they need. The key question is whether the whole buyer-supplier relationship is contingent on knowing these business rules ahead of time. For example, would the buyer avoid placing the order in the first place if they knew that orders must be cancelled one at a time?
While I’m not aware of any technologies, one area you may want to look into is choreography and WS-CDL. I have not had the chance to dig into it, but I do know that it approaches the interaction problem in a much different manner, not relying on a centralized thread of control that is common in BPEL based solutions. Steve Ross-Talbot is quite the expert in this area, I’m pretty sure he’s involved with Pi4Technologies (http://www.pi4tech.org) which is trying to develop some solutions around WS-CDL and pi-calculus.
Thanks Todd.
Yes, an ‘is cancellation possible’ service provided by the supplier would help the buyer achieve a coordinated cancellation using a traditional centralized solution — but he’d need to initiate ‘can-I-cancel-this’ check first (or his system must automatically poll it for him.)
I hope I didn’t convey the impression I favor exporting business rules (eg: order cancellation timeframes) outside organizational boundaries. Rather I’d like ways to export model runtime data and metadata — eg, information conveying the state of supplier order processing, additions to, or restrictions on, process submodel components or transitions, etc. From experience with B2B standards, this is only practical when the model being updated originated from the entity transmitting the model state updates.
I didn’t fully understand your point about avoiding placing the order, but the two orders may have different suppliers.
There’s also the side issue of transactionality – I guess things like WS-transactions can address that.
Many thanks for the links — look like this is my sphere of immediate interest.
BPEL as a source of application management metadata…
Let’s put aside for now all the discussions about whether BPEL is an appropriate tool to capture a “true” business process, i.e. to implement the business logic understood by a business analyst (a topic that has been discussed at leng…