W3C home > Mailing lists > Public > public-ws-chor@w3.org > February 2003

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

From: Jean-Jacques Dubray <jjd@eigner.com>
Date: Wed, 12 Feb 2003 07:21:15 -0500
To: "'Prasad Yendluri'" <pyendluri@webmethods.com>, "'Martin Chapman'" <martin.chapman@oracle.com>, "'Assaf Arkin'" <arkin@intalio.com>
Cc: <public-ws-chor@w3.org>
Message-ID: <01f001c2d291$504ed630$0502a8c0@JJD>



The process-meta-models and specific process definitions based on the
meta-models that have seen acceptance in the industry in terms of
production use thus far have been based on top-down approach. You start
with a business process that you like to accomplish (B2B/B2C/A2A) such
as inventory-managment, order-processing etc., available at a business
definition level that you model in terms of the parties, messages
(documents/schemas) that are exchanged in a well-defined and controlled
order (choreography). We should expect this to be predominent and more
pragmatic case as it supports automating a business process that is
accomplished otherwise (partially or fully manual) in the industry.

[JJ] Yes I agree with you, RN and Start/XML are two very good example of
this, and there are plenty more. It is very efficient for an industry as
a whole to define its collaboration definitions.

It is also possible to take the bottom-up approach where existing Web
services can be composed into higher lever composite Web services and
choreographies, the approach taken by WSCI and BPEL mainly. 
I have always imagined though that a higher level collaborative process
modeling language descriptions (e.g. BPSS or PIP definitions) can be put
through a tool that can generate the BPEL or WSCI defintions either
fully or partially. 

[JJ] Yes, I think also that this can work reasonably well. Mega has done
a lot of work in this direction. I am sure other tool vendors have too.


Business will need a way to model their partners (parties) and
interactions with partners in a business process in a way that is
independent of how it is implemented in terms of Web services (or the
full blown details there in). It is more meaningful for them to speak
interms of sending a RequestForQuote and receiving a Quote rather than a
Web service port and operation etc.  

Hence the question for us is, if we want to define a language that
facilitates modeling at the business-level and then break-it down into a
Web service based choreography or limit to the latter only and leave it
upto the tools to bridge the gap.

[JJ] It is important to note that BPSS choreographies can rely on a
business protocol which guaranties that the business documents are
effectively processed by the receiver. On the other hand, a standard
like BPEL does not allow you to express that an "invoke" has to happen
within a certain time. The authors may have forgotten to assign a
timeout element (while it is available on other aspects of the spec).
These two kinds of exceptions, including also transport level exception
(message could not be delivered) are an integral part of the
collaboration definition and shape its ultimate path. I would even
content that without the ability to express a sufficient set of
exception directly related to the choreography definition,
collaboration's value is greatly diminished.

I guess questions have been raised on the need to model internal or
private processes, which have been mainly flow oriented. I think we need
to accommodate both to facilitate end-end process modeling, though IMO
they need to be clearly separted out and treated separtely instead of
mingling both aspects into one unified model as it seems to have been
done in some of the specs we have been looking at. 

Regards, Prasad

Martin Chapman wrote:

I really think it depends on the use case.
If I am starting from scratch and designing a new businees process, I
would start from the process defintion
and end up with the WSDL for each participant.
However, if I already have the WSDL defined and need to intgerate them
via a process then cleary the process comes second.
IMHO I think we should accomadate both approaches, and neither one
should be the sole design centre for our work.

-----Original Message-----
From: public-ws-chor-request@w3.org 
[mailto:public-ws-chor-request@w3.org] On Behalf Of 
Jean-Jacques Dubray
Sent: Sunday, February 09, 2003 9:42 AM
To: 'Assaf Arkin'; 'Jean-Jacques Dubray'; 'Ricky Ho'
Cc: public-ws-chor@w3.org
Subject: 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. 
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


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




under the BETL section). These guys are working on modeling these


of states. I find the concepts of this specification quite



Yet, both BPEL and BPML allow you to model the "this order is the


state", whether it is the distinct context in which you perform


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


business rules that allow you to specify that if a particular


contains a certain value, then the collaboration ought to continue


way, otherwise, it will continue this way. The key though (and of
course) is that the condition expression can only apply to a


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


do not have an underlying engine. It is merely the interaction


the private processes that advances the state of the 

public process

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

reject the message and the supplier will accept a reject 

message. But

supplier has determined that the buyer does not have 

sufficient credit

purchase the product, the supplier proceed to accept the order since


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,

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,


what not. Please, note that these will never express "states" but


"pseudo-state" since the same public/private definition will not


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


in effect a "real" state is bound to the process definition, which


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


manages 4 messages as part of the same business process 


just request/response.

Not everyone has reached the conclusion that a choreography 


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


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 


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


services, in particular those representing user interactions, I know

of a

few products that actually do that and so far with great success. So


limited experience with the usage of this languages seems to


statement, but again YMMV.

IMHO, this approach is much closer to Pi-calculus than 


ever be as it models the business process as an exchange 

of message 

between independent components (running in their own system


Other specs like BPEL and BPEL use Pi-calculus in the 


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


Very interesting.
In a previous e-mail I provided an example showing where pi-calculus


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


executing at two different systems (trading partners, if you want to


Will you consider revisiting that e-mail and commenting on 

that fact?


If the approach I suggest is proven correct, it could change the


of the WS-Chor group since it will result in a specification that


from (BPEL/WSCI/WSCL/BPSS) to (BPEL/BPML). In my opinion, it will


yield significant simplification to the overall space.
Best regards,
Jean-Jacques Dubray,
Correct me if I misunderstand, it

HP's WS-Conversation-Language is taking this approach.
But I also hear that "public process" can be described 

as a subset


"private process".  If you take out the "process variable",


statements", and the "conditions" in the switch blocks and loops



>from the "private process", then you will have the "public



other words, public process can be just use the same model of


process".  It seems WSCI and BPEL-private process is taking this


I also heard that the "flow-chart" is equivalent to "state



are just a dual-representation to each other.
Any comments and thoughts ... ?
Best regards,



Received on Wednesday, 12 February 2003 08:18:25 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:29:54 UTC