Carnets de bord
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.
Control flow
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.
Process instantiation
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 useful.
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.
Context
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 and connectors.
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 0,4
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.
Global Model
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 disjoint.
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 metamodel.
Dependencies
At a minimum a fully conformant BPML implementation must support these features:
BPML WD http://www.bpmi.org/2002/6/bpml
WSCI 1.0 http://openuri.org/WSCI/2002/wsci10
WSDL 1.1 http://schemas.xmlsoap.org/wsdl
XPath 1.0 http://www.w3.org/TR/xpath
XSDL 1.0 http://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 serious.
Conclusion
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 support ...).
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 companies.
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
http://www.emarketect.com/headlines/show_headlines.cfm?id=3350
