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.