RE: Dubray paper comments + questions

Jon:

Thank you very much for taking the time to read and comment the paper.
As it is self-refereed it is far from perfect. All I was attempting in
this paper was:
a) show that there are really three "concepts" that are generally folded
under the umbrella of web-service choreography (collaboration,
executable processes and long-running behavior of system components,
such as order entry, billing, ...). Maybe there is a need to distinguish
them
b) it might be easier to view executable processes as a series of binary
collaborations between any two 'components' (i.e. system component or
partner or user) rather than a flow of activities.
c) message flow could be explicit rather than folded behind
"activities". In particular, control flow, message flow, data flow, work
flow (as in unit of work), transaction flow, ... should all be well
decoupled in the model
d) this model naturally include "users" which is often left out of specs
like BPEL4WS or BPML (I don't want to restart a discussion with Assaf,
which claims that users are perfectly modeled in BPML)
e) that an engine that is too "centric" is not a good thing. An engine
need to be both an execution engine (provided services to the
components) as well as monitoring the interactions between these
components (control the advancement of the state of the process
instance)
 
The main advantage of this model is that there is no discontinuity
between collaboration and executable business process. However, the
discontinuity exists with system component.

Since I wrote this paper, I have also evolved after talking to Prof. Van
der Aalst and think that we can specify an "ultimate" control flow,
rather than a puggable one. 

>>If I can attempt a summary: Dubray's paper advocates separating
>>message flow, data flow, and control flow definitions. This provides a
>>separation of layers, without precluding the ability to model both
>>interior and exterior flows. The control flow model is "pluggable", so
>>that in fact the same framework could support different kinds of
>>control flow modelling - the examples use BPSS, but this isn't
>>required.
>>
>>A few comments:
>>
>>Generally, this seems to be an interesting and valuable approach. It
>>leverages some of the work that has gone into ebXML, which is one of
>>the more sophisticated B2B frameworks.
[JJ] I don't want to tie it specifically to ebXML, I just want to show
that there is another way to look at executable process models (via
collaboration) and by the way, it fits right in with ebXML BPSS. Of
course I got this idea while working on BPSS and staring at
"collaborations"
>>
>>The paper envisions that business transactions could involve an
>>exchange of multiple messages, that these could be asynchronous, and
>>that correlation between messages may therefore be necessary. I think
>>these are necessary features to support, but the examples don't really
>>demonstrate how to support them, as far as I can tell. Transactions
>>are also identified as being out of scope (p. 15).
[JJ] Typically I am a believer of a collaboration protocol (internal or
external) rather than using correlation using message elements. I find
them clumsy though necessary, until collaboration protocols are used
widely. In ebXML BPSS there is no transaction protocol per say. All is
explicit as part of the collaboration definition. I would not exclude to
extend the good work of Bob Haugen and Tony Fletcher to include these
concepts into this model.

>>
>>The DataFlow example (p. 15) seems to me overly simple. It shows data
>>inputs and outputs connected by XSLT transformations. This is useful,
>>but it's only one example of what could be a complex transformation,
>>possibly involving iteration and other workflow concepts. This being
>>the case, is it useful to distinguish a data flow from a control flow?
>>(The diagram on p. 15 actually confuses the two, because there's a
>>comment indicating that a "Control flow" is starting, but the tag that
>>begins it is called "DataFlow", although its end tag is
>>"ControlFlow").
[JJ] Sorry, I corrected, the end tag was meant to be DataFlow. Again,
the whole purpose of the paper was not necessary to detail the process
definition but rather to show the concepts and how they are related to
each other. (If there is an interest I can publish a more robust spec).
A separate data flow is proposed by BPSS and WSFL. BPML has a very good
data flow too.
 
>>
>>It would be interesting to see in more detail whether, and how,
>>something like BPEL4WS could be fit into this framework - I understand
>>that they're fundamentally different approaches, but to the extent
>>that they're attacking the same problem, it ought to be possible to
>>take a BPEL4WS model and re-express its essentials in this framework.
>>
[JJ] In my opinion, BPEL4WS is very well suited to implement the
long-running behavior of system components like order entry. In BPEL4WS
or BPML everything has to go through the engine, the engine is the
center of the universe (note that all examples are illustrating this
point). Another hint that argues in favor of that is that it is very
difficult to take the order entry component that I give in the paper's
example and make it fit in a BPEL scenario. However, if you look at this
process from the perspective of the component itself then everything
works and BPEL applies to model its behavior.

I don't have a mathematical proof of what I am proposing and I'd be
happy to be proven wrong.
 
>>There is mention at the end of the paper of three planned followup
>>papers - are any of these available?
[JJ] Sorry no time to work on this, this is not my primary activity (by
far).


JJ-
>>
>>
>>

Received on Tuesday, 25 February 2003 20:20:41 UTC