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

> -----Original Message-----
> From: public-ws-chor-request@w3.org
> [mailto:public-ws-chor-request@w3.org]On Behalf Of Jean-Jacques Dubray
> Sent: Tuesday, February 04, 2003 3:26 AM
> To: 'Ricky Ho'
> Cc: public-ws-chor@w3.org
> Subject: RE: Same model for both Public and Private process ??
>
> [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.

Yet, both BPEL and BPML allow you to model the "this order is the approved
state", whether it is the distinct context in which you perform actions, or
a value expressed in that context which you can communicate (send/receive),
evaluate, correlate, etc.


> [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.

In other words, if the buyer and supplier agree that an order is > $500 as
can be calculated from the message (if the schema was known) the buyer can
reject the message and the supplier will accept a reject message. But if the
supplier has determined that the buyer does not have sufficient credit to
purchase the product, the supplier proceed to accept the order since the
buyer may have a different opinion on the matter ("what do you mean
rejected? you know I'm good for it! I might not have money right now, but I
promise to pay you back!").


> 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.

Very well said!


> 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.

Not everyone has reached the conclusion that a choreography language should
allow you to manage 4 messages as part of the same business process
definition, but at least the languages we are talking about allow you to do
that. I think that's a base requirement for all of these languages. At least
something we all have in common ;-)


> c) user interactions are part of the process definition (BPEL/BPML
> completely ignore user interactions).

I like to think of Web services as presenting a model for user interaction,
I like to think of BPEL/BPML/WSCI as supporting any and all kinds of Web
services, in particular those representing user interactions, I know of a
few products that actually do that and so far with great success. So my
limited experience with the usage of this languages seems to contradict this
statement, but again YMMV.


> 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.

Very interesting.

In a previous e-mail I provided an example showing where pi-calculus is used
for inter-component context. I think that using pi-calculus in the
inter-process context brings tremendous value, so I highlighted that
possibility, but clearly the example illustrated two independent processes
executing at two different systems (trading partners, if you want to call it
that).

Will you consider revisiting that e-mail and commenting on that fact?

arkin


>
> 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 14:09:04 UTC