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: