Approaches to Web Services Choreography [was Same model for both Public and Private process ??]

Since this email where Assaf was asking me to reconsider my position I
exchanged multiple emails with him to try to come to a common
understanding and maybe a consensus.

In the blitz of messages that we exchanged (though it would be worth to
summarize it at some point), one comment from Assaf puzzled me. My main
point of contention with WSCI is that it models the choreography (c12y)
of APIs and then via a global model stiches them together leaving little
hope to get an overall view of the collaboration itself. Assaf admitted
that if the APIs were truly designed in isolation the probability of
being able to choreograph them together would be close to zero plus a
few monkeys.

If you take a closer look at BPEL and WSCI, they both take the approach
to use what would be otherwise an "internal business process definition"
to describe how a collaboration operates. The only reason for that is
because they are taking WSDL as a starting point and not as and end
point. BPEL claims without saying it that the "other" services are
mirror to the one they choreograph, therefore, no need to really talk
about the "other" side. Hence the concept of serviceLink which is just a
point to the "other" mirror service. WSCI goes a little futher and allow
for a little more flexibility by allowing somewhat differently designed
web services to work together but admitting that these services cannot
of course widely differ from each other.

In my opinion, using the concept of an "internal business process
definition" to choreograph a collaboration is a bad idea because you
then need to articulate how this special "internal business process
definition" (often labelled as abstract) works with my "concrete"
internal business process definition which I especially don't want to
share with my partners.

Now if the ws-chor group would consider an alternative approach of using
WSDL as an end point and not a starting point, I think it would greatly
simplify the "web service choreography" problem. In order to take it as
an end point, you need to invent a new concept that I call a message
exchange and what BPSS calls a business transaction. I mention message
exchange to show how close this is to the concept of message exchange
pattern being considered by WSDL. Of course in BPSS, a business
transaction is both a business message exchange (e.g. Request/Response)
and a series of signals as part of the business collaboration protocol. 

It is relatively easy to choreograph these MEPs or Business
transactions. BPSS is one example. Can be we do a better job? Of course.
The patterns of Prof. Van der Aalst could help up close on the control
flow once and for all for instance. Once this is done, this is were WSDL
comes to play (one for each side) and where you bind this choreographed
messaged exchange with each side's WSDL. A message exchange would
typically be bound to a port.

As I mentioned several times on this list and others I believe that
there are 3 entities that need to be modeled (at least):
- Collaboration (between business partners)
- Internal business processes
- long running behavior of components (such as order entry) when
participating in business processes and collaborations.

I have shown in a paper that this concept of "choreography of message
exchange" allows you to efficiently model collaboration and internal
business processes. Once you do that, specifications such as BPEL or
BPML can be used to model the long running behavior of components. 

Respectfully,

Jean-Jacques Dubray,
 

>>-----Original Message-----
>>From: Assaf Arkin [mailto:arkin@intalio.com]
>>Sent: Tuesday, February 04, 2003 2:07 PM
>>To: Jean-Jacques Dubray; 'Ricky Ho'
>>Cc: public-ws-chor@w3.org
>>Subject: 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 Sunday, 9 February 2003 12:45:47 UTC