In-Depth

Standards emerge from BPM stew

Just what is happening in the business process management (BPM) software standards arena? Business Process Execution Language for Web Services (BPEL4WS) -- backed by IBM, Microsoft and BEA -- has been battling the Business Process Modeling Language (BPML), proposed by BPMI.org, for supremacy (see ''Orchestration promise meets reality'' ).

It is generally agreed that BPEL4WS has won by sheer weight of industry support, but the dust has not yet cleared. Some, including BPMI.org, which developed BPML, say BPML's Business Process Modeling Notation (BPMN) will be layered on top of BPEL4WS, giving users a single unified stack of standards for Web services choreography. This stack will have the Web Services Conversation Language (WSCL) at the base, BPEL4WS layered on top of that, and graphical notation through BPMN.

Others say no such thing will happen. Meanwhile, IBM is hedging its bets, saying that BPMN is one of many possibilities for layering on top of BPEL4WS. If BPMN is layered on top of BPEL4WS, it will be a relatively simple task because BPML and BPEL4WS share many common underlying technologies. The layering will also resolve a major flaw of BPEL4WS: its lack of distributed processing. Software vendors such as Fiorano Software Inc. have done well by offering a distributed solution for business process management.

Meanwhile, another problem is about to hit users in the face: WS-BPEL, the OASIS working committee working on the BPEL4WS specifications, is creating a relatively loose set of specs that will leave a lot up to vendors developing tools for implementation. That could lead to fragmentation of the market.

Background
The victory of BPEL4WS was pretty much ordained in a world where bigger is better and market share has a higher rating than quality technology. While BPMI.org managed to pull support from a few large companies, BPEL4WS took the lead once the specifications were submitted to the OASIS WS-BPEL working group in August 2002 -- more than 100 vendors lined up to support it.

That created an irresistible pull. The reaction of Bedford, Mass.-based Sonic Software Corp. is typical: David Chappell, Sonic's chief technology evangelist, said the company ''did some strategic evaluations in the beginning of the year to look where to place our bets, and decided to put our time into WS-BPEL, not because it was technically superior but because it had industry support. It's really what the industry has rallied around and tends to focus on.''

Atul Saini, CEO at Fiorano Software Inc., Los Gatos, Calif., agrees with Chappell's view. ''BPEL has become the dominant standard because it's supported by IBM, Microsoft and BEA,'' he said. ''In that kind of situation, only the really big players can make influencing decisions.''

Once support began to jell around BPEL4WS, BPMI.org was quick to recognize which way the wind was blowing and took a conciliatory stance. In August 2003, it released a working draft of BPMN 1.0 and said in a press release that the standard ''allows different XML-based process languages, e.g., Business Process Execution Language for Web Services (BPEL4WS V1.1) and to be visualized using common elements.''

BPMI.org chair and co-founder Ismael Ghalimi, who is also co-founder and chief strategy officer at San Mateo, Calif.-based Intalio Inc., said that by the time BPEL 1.1 was submitted to OASIS in Q1/2003, BPMI.org had already decided to support BPEL and stop the development of BPML. Ghalimi is hurting over the BPEL4WS victory, but he takes the high road when talking about the standards issue. ''We have a choice. Either we complain and say our stuff is better or we say 'Guess what, we'll ride on their coattails and leverage their marketing ability and momentum because, at the end of the day, their work is similar to what we've done. And as long as we can work with them to add things that are missing, such as distributed transactions -- that's a showstopper -- in a productive way, we're perfectly happy with that.''' The second approach is ''what customers want because, at the end of the day, they have a single standard they can buy into,'' Ghalimi said.

To layer BPMN -- or not
Ghalimi said ''there's a very good likelihood that BPMN will be the standard graphical notation used to design BPEL processes.'' He said BPMN is being adopted ''by IBM and the five leading process modeling tool vendors: Casewise, Popkin, IDS Scheer, Mega and ProForma.'' This will give users a ''single unified stack of standards starting with WSCL for Web Services, BPEL above that and, right on top, BPMN,'' Ghalimi said.

Doron Sherman, chief technology officer at Collaxa Inc., Redwood Shores, Calif., is not so sure that there will be any effort to layer BPMN on top of BPEL. ''I agree that BPEL is taking over BPML, but I've never heard that BPMN will be a layer on top of BPEL,'' he said.

Sonic's Chappell agrees, in essence. ''I don't really see the merging of BPEL and BPMN,'' he said. ''I think there's a number of different specifications and organizations that have evolved or have been introduced to address similar issues. It's really a question of what the industry's rallied around and tends to focus on.''

IBM was, predictably, unwilling to be tied down on the question. ''From the IBM perspective,'' said Karla Norsworthy, director of technology, IBM Software Group, Raleigh, N.C., ''we believe it may be possible to use BPMN to do some modeling on top of the BPEL; we're experimenting with some of that now for a Web services orchestration language.''

Norsworthy said work on understanding how BPMN could be modeled on top of BPEL ''is happening in the public BPMI forum.'' Although things are in the early stage, she was willing to state that, should BPMN be layered on top of BPEL, it would be done in a way that ''we won't end up with conflicting things at the same layer.'' However, ''that doesn't exclude the possibility of other languages being used for modeling on top of BPEL,'' Norsworthy said, adding that the OMG is looking at a new UML business process meta model. ''I think you'll see lots of activity about how you can build modeling techniques on top of BPEL, and BPMI and BPMN will be a part of that,'' Norsworthy said.

Collaxa's Sherman does not agree that a separate modeling layer is required on top of BPEL. Collaxa has implemented the BPEL 1.0 specifications, published in February 2003, in the V2.0 beta of its Collaxa Orchestration Flow software. ''In the last six months, we have worked on developing a full-blown BPEL designer that gives you both text and graphical capabilities, and you can go back and forth between graphical and text representations of BPEL logic,'' Sherman said.

Intalio's Ghalimi is pretty sure that IBM will opt for BPMN, for the customers' sake. ''They have to say that they will work with other products because they have to work with other existing methodologies; but for the benefit of the customer, it's very likely that a single unified methodology will be made available, and that's likely to be BPMN,'' he said. ''BPMN is the UML of business process methodologies, in essence.''

Distributing transactions
Fiorano's Saini said that the main flaw of BPEL4WS is its centralized approach to transactions. ''BPEL breaks down in the implementation phase because all the people implementing it today have one big huge server, and what they're not telling you at the time of implementation is that you may have to do a lot of manual coding to synchronize and coordinate the work of the three or four different computer systems processing a quote,'' he said. ''So specifying the business process at a high level as BPEL does is very nice, and it is a very good standard for this, but the implementation requires distributed processing on different boxes. That isn't specified, but is left up to the vendors of the infrastructure like IBM, BEA or Fiorano. That's what's in the fine print.''

The preferable solution is distributed BPEL engines on different boxes with one meta-BPEL engine that coordinates everything, Saini said. Because BPEL engines generate straightforward code, mapping straight from high-level BPEL to low-level function calls means the function calls are made across different machines on the network, which impacts efficiency dramatically, Saini said. Fiorano's solution to this is the Fiorano Business Integration Suite, formerly known as Tifosi. It is an enterprise service that serves as an abstractive layer sitting beneath BPEL, but above the software code, and matches the two.

Fiorano has a BPEL engine in beta that will be released in February. This ''speeds up the time for the fully distributed implementation of BPEL processing'' because it maps a single BPEL process to different nodes on the enterprise network so that various processes can run on different boxes. Fiorano peers sit on all the boxes, and any task is routed to the appropriate local service on the appropriate box, eliminating hand-coding, Saini said. Instead of mapping business processes to C function calls, Fiorano's BPEL engine will ''map them out to enterprise and Web services in a distributed fashion and combine this with messaging, combining asynchronous distributed computing with BPEL and map it onto a grid,'' Saini said.

Sonic's Chappell does not agree that users have to rely on extensive manual coding to synchronize and coordinate the processing of complex BPEL requests. ''That's the importance of having tool support,'' he said. ''Nobody expects people to code things by hand, we expect lots of tool support. We see a world where you don't code any of this stuff, you visually draw things with a modeling tool, that's what UML is for; using UML types of interaction diagrams, you model your business processes, click a button and it generates a bunch of stuff underneath -- UBXML, BPSS [an EBXML term] or WS-BPEL,'' he said.

However, issues with the lack of distributed processing capability in BPEL4WS may soon be moot: According to Intalio's Ghalimi, BPMI.org and ''its key contributors for BPML are working with IBM and Microsoft to add distributed transactions to BPEL 1.2. So, sometime in the middle of next year, you'll get support for distributed transactions.''

Common underlying technologies
BPEL4WS and BPML share several technologies at their base. In Web services, they both rely on SOAP, WSDL and UDDI. They also take advantage of the same XML technologies -- Xpath and SXDI -- and are designed to leverage other specs such as WS-Security and WS-Transactions. And the Web Service Choreography Interface (WSCI), which was approved as a note by the W3C in August 2002, is ''the largest common denominator to BPMI and BPEL4WS.''

A BPMI.org position paper points out that BPMI ''supports the modeling of real-world business processes through its unique support for advanced semantics such as nested processes and complex compensated transactions, capabilities BPEL4WS has yet to address.'' It further states that the authors of the BPEL4WS specification ''acknowledge such limitations in Section 13 of their recent draft, thus identifying a clear path of convergence towards a model similar to BPML's.''

In short, the two specifications will work together or, at the very least, it will be relatively easy for BPEL to incorporate necessary pieces of BPMI.

Loose BPEL specs
The WS-BPEL specification leaves much in the hands of vendors. For example, it will leave modeling up to the tool vendors instead of specifying a set method or approach. ''We're not going to specifically define modeling for V1, although we expect that modeling tools will be used by people using BPEL,'' said Sonic's Chappell, who is also a member of the WS-BPEL committee.

''We're confident that vendors can take a reasonable UML tool and map to the vocabulary that people provide. We actually fully acknowledge that it's only going to be usable by a tool, and it's going to be cryptic, and we don't expect people using BPEL to write code using Notepad,'' he added.

This approach shows IBM's influence: Users of IBM's MQSeries middleware product will recall that IBM chose to leave the market open for third-party vendors to create tools for implementing MQSeries in a bid to attract support from ISVs.

The trouble is, it also brings back memories of the fragmentation of the Unix market, when every vendor had its own implementation of Unix: ''Different parties will have their own BPEL engines,'' Chappell said. He is confident that tool vendors will fill in any gaps in the specs. For example, V1 of WS-BPEL will focus on one-to-many transactions, he said.

However, ''there's nothing that will prevent a tool vendor from implementing the tool and infrastructure to do multi-party interactions; it's just that the spec does not map out how to do those multi-party interactions,'' Chappell noted.

Here is another hole: Because the goal is to use interoperable means of interaction, the spec will be multi-platform. One of the implications of that is the inclusion of SOAP-based communications, but again the committee is taking a laissez-faire attitude toward that. SOAP-based communications are ''not necessarily a requirement,'' Chappell said.

Will vendors do the noble thing and work to the common good? Past experience shows this to be unlikely; but anything is possible.

About the Author

Richard Adhikari is a widely published high-tech writer based in Silicon Valley. He can be reached via e-mail at radhikari@sbcglobal.net.

Featured

Upcoming Events

AppTrends

Sign up for our newsletter.

I agree to this site's Privacy Policy.