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

Assaf::

 

 

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.

[JJ] Assaf, figure 5-3 is really good, it shows precisely how WSCI work,
you should show it to everyone. It is very clear.  Looking at this
picture, and in the light of the discussion that we had, I keep
wondering what is the best way to design a WSCI collaboration
definition? Where do you start? Where do you end? Do you start by
designing WSDL? Then you design the choreography of this interface, but
as you told us the other interface choreographies cannot be designed in
isolation. Are each party responsible for its side? Or is it one party
that designs the whole thing? How do you make sure that the choreography
is doing what you want. Just looking at the global model is not enough
because contrary to what you are saying the global model has no
choreography information, the choreography is in the interface. Do you
need a simulation tool once you are finished to verify that the
definitions do what you need?

 

I have published over the summer a complete alternative to WSCI
including a simple but efficient notation.
(http://www.ebpml.org/ebpml.doc) This approach (based on BPSS of course)
allows you to express the same multiparty collaborations but from a
neutral point of view. This collaboration definition can then be bound
to WSCI, WSDL, BPML, BPEL,. I'd be happy to powerpoint the travel agent
example with the notation I proposed. It is also neutral from what is
being choreographed and message exchange patterns such as ebXML business
transactions or web service operations can be choreographed within the
same collaboration definition. 

 

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

 

 

[JJ] so here is what WSCI says:
"WSCI allows declaring exceptional behavior that is exhibited by a Web
Service at a given point in a choreography. The declaration of
exceptional behavior is part of the context definition, and associates
exceptions with a set of activities that the Web Service will perform in
response to those exceptions. It is possible to declare the occurrence
of the following kinds of exceptions:
  a.. Receipt of a particular message that is considered as exceptional
in that context.
 
  b.. Occurrence of a fault; this fault might correspond to the receipt
of a WSDL fault message, or to the generation of a fault by the service
itself.
 
  c.. Occurrence of a timeout"
 
Which I interpret as WSCSI is relying on a) WSDL fault mechanism and b)
adds another possible mechanism by declaring that a certain message
generates an exception but is not necessary modeled as a fault in WSDL.
 
This has nothing to do with business transaction/collaboration protocol,
unless you are implying that one could implement a collaboration
protocol with the fault mechanism of WSDL. It is not impossible but that
would be quite a stretch you would admit to systematically add fault
messages to every operations. By contrast, BPSS offers a business
transaction protocol completely independent of the semantic of an
operation fault (which is normally an application level exception not a
protocol level exception).
 
Again, you need to be able to express ALL possible exception that
influence the course of the choreography. WSCI is far from achieving
this result. As you were pointing out recently in an email, there is in
particular the need to signal whether a message has been processed
successfully by the receiving application like BPSS business transaction
protocol allows you to do.
 
Cheers,
 
JJ-

 

 

 

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: