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

Prasad,

I think we need to distinguish between two use cases here.

One is to describe the actual choreography that takes place between the
participants. Eventually you need to define which operations are being
performed in order to carry out the choreography, and that's something WSCI
does pretty well.

Another is to describe an incomplete abstract choreography that shows some
flow but doesn't describe which operations are used, or maybe describes some
but not all of them. This is something that happens during modeling before
you produce the choreogaphy definition which the services use for an
understanding of the definition.

I don't know if modeling is part of the scope of this working group. That
would be like allowing an incomplete XML Schema, e.g. one that has an
element with no content model, or references an undefined attribute group.
It might or might not be out of scope.

Clearly we have put most of the emphasis on addressing the former and not
enough on the later. Some solutions (e.g. defining an action without
referencing any operation) are possible but not explained or illustrated.
Some other solutions (e.g. open models and composing models together) are
not in WSCI but something I've been looking for in the context of a future
specification.

Clearly WSCI is just an input, and there are other inputs to this working
group from our collective experience and what we want to produce is a
specification that encompasses as many inputs as possible within the set
scope. So let's discuss what features we want to see in the spec, figure out
if they are in scope for this working group, and then fish for a solution.

If we are looking at incomplete choreographies for modeling purposes, then I
would like to see open models and composition of models, and I would also
like to see actions that do not reference operations. I don't remember who
caused me to think about open models, but it might have been someone at
WebMethods ;-)

arkin

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


  Assaf Arkin wrote:

      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?
  It is not a question of if you can *accomplish it* but, if it is naturally
supportive of the model. If you have to think in terms of how you map it to
Web services portTypes, operations and WSDL messages and schema types rather
than in terms of the collaborative aspects of the process as the centric
model, it is not directly designed for such purpose IMO.  To quote JJ "these
standards forces you to think single-side bottom-up as you always have to
design the "internal process" view of the collaboration."

  Perhaps an example representation of a simple collaborative business
process that proves this to be wrong would convince me.

      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.
  Agree that in general there would be cases where existing Web services
need to be pulled into a choreography and the model needs to accommodate it.
However, I am not convinced that a model that centers on that approach and
makes it also *possible* to model a collaborative process is adequate.

  Regards, Prasad

       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 in
terms 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