RE: Same model for both Public and Private process ??

Ricky:

>>I have some confusion as described below ...
>>
>>"Private process" is providing an internal implementation view of a
party
>>in a long running business interaction when the party is implementing
its
>>behavior using orchestration engine.  "Private process" is about
>>specifying
>>the activities he takes in responding to an event (which can be
receive a
>>particular message or send a particular message).  
[JJ] This is a bit limiting as most events are not sent in complete
isolation of each other and that private processes are more in charge of
running a conversation with business partners rather than just
responding to one event. Most relationships between business partners
are peer-to-peer (any partner should be able to initiate a
request/response when appropriate) rather than client/server (it is
always the same partner which initiates the requests). In general you
also want to avoid "slicing" your processes on a per "event" basis a la
Event/Condition/Action sauce. The problem of the ECA model is to be able
to build a wider context that spans multiple events.

The process variables,
>>routing decisions... etc, describe the detail implementation logic is
>>clearly specified.  The modeling language (e.g. BPEL, BPML) is
>>semantically
>>equivalent to a flow chart.
>>
>>"Public process" is providing an external view of a party in a long
>>running
>>business interaction regardless of whether that party is implementing
his
>>behavior using an orchestration engine.  Public process is about
>>specifying
>>all possible states of that party.  
[JJ] I assume you think of states in terms of "getting ready to
send/receive a given message", otherwise, clearly notions like "this
order is the approved state" is not necessarily part of the state of
public processes as BPEL or BPML think about it, let alone WSCI and
WSCL. You may want to read the eBTWG - Business Entity Types Technical
Specification (http://www.collaborativedomain.com/standards/index.htm
under the BETL section). These guys are working on modeling these kinds
of states. I find the concepts of this specification quite fascinating
actually.


And then for each state, what events
>>are legitimate (event can be receive a particular message or send a
>>particular message) ?  And after that, what is all the "possible" next
>>states ?  The major difference is "public process" is NOT to describe
>>which
>>route to take under what conditions.  
[JJ] This is actually incorrect. In BPSS for instance, you clearly have
business rules that allow you to specify that if a particular document
contains a certain value, then the collaboration ought to continue that
way, otherwise, it will continue this way. The key though (and of
course) is that the condition expression can only apply to a document
that both parties already successfully exchanged. You cannot specify
conditions expressions that only one party can evaluate. One big
difference between public and private processes is that public processes
do not have an underlying engine. It is merely the interaction between
the private processes that advances the state of the public process (aka
collaboration). However, one can formally demonstrate that a
collaboration is also a finite state machine.


Instead, it describe what are the
>>possibilities.  It seems to me a "state transition diagram" is a
natural
>>fit to describe the "public process".
>>
>>Therefore, I have a question if the "public process" should be based
on a
>>completely different model (a "state transition diagram") than the
>>"private
>>process" (a "flow chart diagram").  
[JJ] The problem really is first how do you decouple the "message flow"
from the "work flow". Work as in unit of work. In BPEL/BPML everything
is an activity, or actually everything is a message as units of work are
represented by the "invoke" that will initiate them. 

Once you have established such a model, one can think of how to
choreograph message exchange, work being done, user interactions, and
what not. Please, note that these will never express "states" but rather
"pseudo-state" since the same public/private definition will not refer
to a given state of the company but rather to the way state advances
within the company. It is only when a process instance is created that
in effect a "real" state is bound to the process definition, which then
controls how this "state" advances.

If you want to see how it is possible to decouple the message flow from
the work flow, you can read a paper I wrote last July
(http://www.ebpml.org/ebpml2.2.doc) , it shows how to model business
processes as a series of collaborations between components. A component
is either a partner, a user or a system component (order entry, billing,
shipping, Item Master...). The advantage of this approach is to provide:
a) a continuous definition of the process (no more public/private), it
just happens that one or more collaboration is "public" all the others
are private, but the same model applies. 
b) it enables unit of work to be more than "request/response" agents. In
the example I provide which is very realistic, the Order entry component
manages 4 messages as part of the same business process definition, not
just request/response. 
c) user interactions are part of the process definition (BPEL/BPML
completely ignore user interactions).

IMHO, this approach is much closer to Pi-calculus than BPML or BPEL will
ever be as it models the business process as an exchange of message
between independent components (running in their own system process).
Other specs like BPEL and BPEL use Pi-calculus in the inter-process
context not the inter-component context. I am not a specialist of
Pi-calculus so I'll leave this statement more as a question than a fact.

If the approach I suggest is proven correct, it could change the scope
of the WS-Chor group since it will result in a specification that spans
from (BPEL/WSCI/WSCL/BPSS) to (BPEL/BPML). In my opinion, it will also
yield significant simplification to the overall space.

Best regards,

Jean-Jacques Dubray,



Correct me if I misunderstand, it
>>seems
>>HP's WS-Conversation-Language is taking this approach.
>>
>>But I also hear that "public process" can be described as a subset of
a
>>"private process".  If you take out the "process variable", "assign
>>statements", and the "conditions" in the switch blocks and loops ...
etc
>>from the "private process", then you will have the "public process".
In
>>other words, public process can be just use the same model of "private
>>process".  It seems WSCI and BPEL-private process is taking this
approach.
>>
>>I also heard that the "flow-chart" is equivalent to "state diagram".
They
>>are just a dual-representation to each other.
>>
>>Any comments and thoughts ... ?
>>
>>Best regards,
>>Ricky

Received on Tuesday, 4 February 2003 06:27:32 UTC