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
>