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

I am convinced that you can do both approaches with WSCI/BPEL/BPML,
however, these standards forces you to think single-side bottom-up as
you always have to design the "internal process" view of the
collaboration. As you said, tools could fix this minor inconvenient. I
do see a much bigger issue which is what you agree on with your business
partners. I find it harder for me to agree on the view you have of the
collaboration rather than agreeing an a neutral view of the
collaboration like BPSS offers. As you can imagine we cannot agree on a
"picture" provided by a tool. What we agree on has to be machine
processable. The second issue I see is that if the choreography does not
rely on a a business collaboration protocol (I am surprised that years
of research on pi-calculus have not concluded to the importance of
business protocols to choreograph business collaboration) most of the
business choreographies cannot be expressed. As I say often, the paradox
of automation is exception handling: without a efficient and sufficient
exception handling mechanism you cannot automate. BPEL has no timeout on
invoke for instance. 

 

So what you are recommending to use (WSCI/BPEL/BPML) amounts to: a)
modeling choreography that need to be fixed by good tools (watch out,
tools could produce their metamodel which could replace your
specifications), b) something hard to agree on in a bi- or multi-party
collaboration c) a complete lack of business semantic witnessed for
instance by the lack of intersection with a business collaboration
protocol.

 

I don't know if everybody agrees that WSCI/BPEL/BPML is the right
approach, maybe there is a better one that can be built that would
address a), b) and c).

 

JJ-

 

-----Original Message-----
From: Assaf Arkin [mailto:arkin@intalio.com] 
Sent: Wednesday, February 12, 2003 1:07 PM
To: Prasad Yendluri; Martin Chapman; 'Jean-Jacques Dubray'; 'Ricky Ho'
Cc: public-ws-chor@w3.org
Subject: RE: Approaches to Web Services Choreography [was Same model for
both Public and Private process ??]

 

 

Precisely. 

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.

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.  

 

What would it take to dispel the myth that WSCI/BPEL/BPML force you to
do bottom-up modeling?

 

Durining training sessions we let customers play with our product and
what we see is that customers don't model choreographies strictly
bottom-up or strictly top-down. They do what feels natural and best
meets their needs.

 

You can see the customer pull a set of existing services to form a new
choreography, where these service are already defined and not subject to
change. Then the customer adds new activities specific to that
choreography for which not service definition exists. Once the
choreography is mapped out visually they start defining the message
schema, in effect defining the service after the choreography.

 

I'll call this 'the organic approach'. You can decide to only define
choreographies top-down or only bottom-up. But you can mix the two and
do things in the best way that meets your requirements.

 

arkin

 

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

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: