BPML 1.0 (June 2002) Analysis
There has been a great quality improvement between BPML 0.4 and BPML 1.0. The
notions of a) a business process instance and b) a business process context have
finally blossomed in the spec.
The data flow has been greatly simplified via the utilization of properties
and assignments and is very elegant.
A global model has been added.
XLang and WSFL are clearly defined as "targets" (translation of
"subset" in French).
High level description
A process is viewed as a series of activities and an activity
represents a component that performs a specific function. Activities can be
composed into complex activities.
Activities execute within a context which is transmitted from parent
to child. In particular the context allows two activities to share properties.
Properties constitute the data flow of BPML.
The control flow has also been modeled as "activity". This
is a bit surprising at first but it is logical as the control flow uses a
block-structured (as opposed to activity-transition like WSFL) approach, each
block can itself be considered an activity. Blocks can be nested to arbitrary
levels. The control flow seems to be complete and reflects what was already
available in BPML 0.4. The fact that the control flow is expressed as activities
allows to manage the context of these activities at a very fine level. This is
also a good foundation for transactional semantics and provides a substrate for
monitoring the state of the process.
The primary instantiation mechanism of a process is based on the
receipt of a message. It is required that an action be defined at the top level
to receive this message. This is the equivalent of the "start"
element. Several actions can wait on different messages. What is not clear is
what happens if an action is specified with a request/response? how does the
response gets generated? It seems that there is no way to "insert" a
path in between as actions are atomic activities. That leads to another
question, there seem to be no way to relate a request (which initiates a
process) to a response that is returned after the appropriate activities have
been executed? Does that mean that any process "client" need to define
a notification and one way and cannot use the "solicit response" mode?
Clearly this is a very difficult problem and does not land itself very well to a
"block-structured" control flow.
BPML uses an interesting concept with the All element which enables a
process to start once "all" actions will have received their messages.
Of course the process instance is created when the first message is received.
This is a very nice feature.
BPML 1.0 talks about instantiating a business process via system events and
scheduling, but it seems that there is no specific support there. Scheduling
would have been relatively easy to put in place natively and probably very
A process can also be "spawned" or "called". The
"called" mode seems to be synchronous as the activity is a simple
activity. In particular that limits the ability of the "sub-process
process" to "collaborate" with the parent instance. This is very
close to the WfMC chained and nested models. The spec offers a loosely couple
version of process collaboration via "global models" (see below), but
it looks like you need two different engines.
Spawned processes can be joined via the "join" activity.
Process and complex activities provide a context in which their activities
execute. The current context of a complex activity consists of the parent
context and any local definitions.
Local definitions include: properties, exceptions, processes, transactions
A local process definition prevents other part of the parent process
definition to see this process.
A local connector definition allows to limit the scope of message exchange to
a particular complex activities such that other complex activities do not
"see" the corresponding messages.
Assignments enables the change of value of a property as a result to the
execution of an activity. When an action executes, any input message is
indirectly map to a property in the current context. A selector is used when the
assignment needs to be direct (bind a message or part of a message to a specific
property). When using an action in combination with WSDL, the action references
the operation name, but it is the message name specified in the operation
definition that will be used to create the automatic property.
Overall this approach of defining and managing the data flow of the process
instance is excellent and a great improvement from BPML
Exception and transactions
Event handlers specify the triggering event and the corresponding activity
set that will be executed in response to the exception. Three types of events
are possible: message, timeout, and fault.
In the case of timeout it appears that one has to define a property within a
context at a given time. The timeout will be calculated from this property.
There is no notion such as "this activity must complete in 'n' days".
A complex activity may operate in transactional mode. There are two types of
transactions: atomic and open nested. Atomic transactions are flat. Any levels
of nested transaction may be defined in an open nested transaction (both atomic
and open nested).
In the case of an atomic transaction, all its activities perform like a
single unit of work. It looks like the specification is trying to leverage
existing transactions protocols (BTP, XA, ...) to be able to roll back the
effect of the operations. In the case of an atomic transaction, the context of
the transaction is also managed transactionaly and will roll-back to the state
prior to the beginning of the transaction. This is not possible in the
open nested mode, as the context is not isolated. The success or failure of a
transaction also influences the way messages are produced and consummed. I must
admit that I am a little bit surprised by this behavior.
The open transaction model is using compensating activities to revert the
effects of the operations that were defined.
A transaction is associated with an activity set.
It looks like they ran out of time for this section. It is rather unbelievable
that WSCI provides also the notion of a Global Model and it is not related to
BPML global model. It looks similar, but from a definition perspective they look
So I will probably say it for the nth time, it is not a good
approach not to consider an independent collaboration definition to synchronize
the state of two processes. This assumes that a lot about each process is shared
in order to form the global model. This approach is only usable when two
processes have been designed in isolation and you need to stitch them together.
Again what is the likelihood of that happening?
This very point makes BPML difficult to use for B2B scenarios because what
parties agree on is a collaboration not their respective processes or
interfaces. At this rate, it will probably take another two years for the
author(s) of BPML to get that. It is also amazing that one cannot understand
(and extend) the principles of "isolation" and "interfaces"
that everyone thrive to use when designing and implementing components.
Typically, you want to keep things "isolated" such that when you
change something on one side, you do not impact the other side. Isn't it
more appropriate to define a "collaboration" as an
"interface" that does not change and that each process can be bounded
to? In a client server mode, the server exposes an interface because the server
only (well most often as well all know) responds to client requests. In a
peer-to-peer mode like in B2B or even in scenario where two business units run
independent BPMS, you need to design the "interface" as a
"collaboration" this is the only way to guarantee that each side will
remain in synch. Incidentally these collaborations are often defined by
industries and not even the parties that use them.
In addition, BPML views that "collaboration" only happens between
processes as "end-to-end" processes. This is actually a short sided
view. A business process management systems "collaborates" will all
roles in a process definition (systems, users, business partners). BPML reserves
atomic "operations" to deal with systems and global models to deal
with other process engines. In my opinion a business process is merely a
multi-party collaboration between components and roles (see ebpml paper). Each
of these roles or components would then expose an interface that you could model
with WSDL/WSCI or WSDL/a collaboration definition a la BPSS.
Missing in action
It looks like "roles" are totally absent of the BPML metamodel such
that one cannot specify the role that performs a given activity. You basically
have to re-invent that concept each time you need it with the notion of locator.
"User activities" and "work items" are the core of
business process definitions. My product management will clearly discard BPML
today as it does not support concepts that have been available for years in the
WfMC and OMG specifications (forwarding a work item, voting, watchdog, ...)
B2B Business transactions (e.g. ebXML business transactions) are not
considered good enough to be part of the BPML "club". There is an
"OtherActivity" type which maybe was reserved to that effect?
Produce and Consume have disappeared between BPML 0.4 and BPML 1.0. I had
related these concepts to publish/subscribe of message oriented middleware. This
is a regression as, I think, this kind of EAI semantics belong in the BP
At a minimum a fully conformant BPML implementation must support these
BPML WD https://www.bpmi.org/2002/6/bpml
WSCI 1.0 https://openuri.org/WSCI/2002/wsci10
WSDL 1.1 https://schemas.xmlsoap.org/wsdl
XPath 1.0 https://www.w3.org/TR/xpath
XSDL 1.0 https://www.w3.org/2001/XMLSchema
The dependency of BPML on WSCI are
quite strong in particular for the correlation mechanism (selector) and
identifying services based on a set of properties (locator).
We certainly must regret the (uncessary)
dependence of BPML on WSCI, a proprietary specification written outside of the
BPMI consortium in complete secrecy and which destiny is controlled by a small
number of players. We must also wonder what is the impact of SUN
viewing WSCI as a key technology for the web services stack (therefore
having its own lifecycle) and the dependency with BPML.
XLang and WSFL
The press release explains the
"BPML 1.0 was developed as a semantic superset of
previous releases of the BPML specification as well as the WSFL specification
developed by IBM and the XLANG specification developed by Microsoft".
XLang I would tend to agree as it would be hard to define a subset of XLang. I
hope you would allow me to express some doubts about WSFL. The control flow is
so different that I don't see by which magical transformation a WSFL definition
can be transformed and executed by a BPML compliant engine. This kind of claim
would require at least a short paper explaining the claim, unless... it is
designed to convince people to stop looking at XLang and WSFL. This is not very
There is a definite improvement between BPML 0.4 and BPML 1.0. I think that
the data flow is particularly well addressed. The control flow is good though we
might want to consider a "plug-able" control flow such that different
people can choose different approaches as well as different levels of complexity
in the control flow definition (this does not impact the interoperability).
Transactions are well treated as they were since the beginning of the BPML specs
(with some improvement too). It would have been nice to establish different
levels of compliance (with or without transactions, with or without global model
The unnecessary dependency on WSCI creates a vast shadow on the future of
BPML by moving the control of essential parts of BPML to a small group of
BPML continues to perform very poorly when it comes to B2B. The same must be
concluded when dealing with "user interactions". (check
the score card)
BPML seems to focus on web services only and thrives to compete head to head
with XLang and WSFL, of course BPML claims it does not compete. In my opinion,
BPML metamodel corresponds to the one of a "web services
broker". To that extend, BPML should be renamed WS something, maybe
WSCL: Web Service Choreography Language.
It is not because you call everything an "activity" that you are
capable of modeling "business processes". So yes, I know the answer of
some people at BPMI, "you don't understand this is the fundamental level at
which business processes can be defined, other semantics can be defined on top
of BPML". It the argument looks seducing, I now view it as a fatal weakness
since with so much functionality missing (who can define processes which don't
have User and B2B interactions?), it could not pass our product management
organization and I am probably not the only one in that case.
Other analysis available