RE: Approaches to Web Services Choreography [was 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: Wednesday, February 12, 2003 11:19 AM
  To: 'Assaf Arkin'; '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 ??]


  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.



  When we wrote the examples for the WSCI specification we didn't have any
modeling tools. We drew a picture of the choreography, then we wrote the
WSCI choreography, then we wrote the WSDL service definitions. So even if
you write all these documents by hand, you still take the organic approach
to writing the choreography. There is no "one right way for doing things".
And it's great that you can do it in the best possible way that meets your
needs.



  I do agree about the value of exceptions, especially those involving
communication and time. Of course you've read WSCI and BPML so you've
already seen that we paid attention to exceptions, interruptions, time-outs,
time delays, etc.



  arkin





  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: