RE: Definition of Choreography

Edwin
 
I also *very* much agree with you!
 
On the terms public/private, I also have difficulty knowing the right words
to use. Maybe clear definitions would be sufficient.
 
The value of a choreography language, that I can see, is that it can provide
a *precise* definition of the choreography and avoid (or at least reduce)
the ambiguities you get if you use a word document instead.
 
Standardized definitions of "public" choreographies (i.e. the instances)
will, IMO, significantly increase the interoperability between business
processes. However it will not make the excecution of business process
*within the enterprise* more portable. After all implementing a "better"
internal business process is one of the ways a business can make itself more
competitive. You can't expect businesses to always work the same way. So
really, business process portability is not an issue, unless you want to be
able to switch easily between workflow engines.

David

-----Original Message-----
From: Edwin Khodabakchian [mailto:edwink@collaxa.com]
Sent: Friday, October 18, 2002 1:44 PM
To: 'Burdett, David'
Cc: www-ws-arch@w3.org
Subject: RE: Definition of Choreography


David,
 
I *very* much agree on your point where the coordination of message
exchanges is different from the coordination of activities (which is what
workflow engine do) but this is not easy to explain.
 
Regarding public versus private, I was *not* talking about company
boundaries but component/service boundary. The public face of an ERP system
is the information you need to know about that system to integrate it into
your application (even if the application that is integrating the
functionality lives within your corporation). On the other hand, the private
implementation refers to how SAP delivers the service. 
 
Separating the 2 faces is important because you do not want to overwhelm the
application developer who is doing the integration with the details of how
SAP processes order. Also you want to be able to change the internals of SAP
without having to update all the applications that integrate to SAP. In the
Java world, an Interface is the public face of a component, a class is the
private implementation.
 
If you think that within that context, public/private separation is not the
right dicothomy, I am open to any other suggestion but I believe that we
need to make sure that there is a very clear understanding of the problem we
are solving and the value that a choreography spec will deliver: will it
increase interoperability between business processes or make the execution
of business processes more portable or both.
 
Best,
 
Edwin
 
 

-----Original Message-----
From: Burdett, David [mailto:david.burdett@commerceone.com] 
Sent: Friday, October 18, 2002 12:32 PM
To: 'edwink@collaxa.com'; Burdett, David; 'Mark Baker'; 'Champion, Mike'
Cc: www-ws-arch@w3.org
Subject: RE: Definition of Choreography


Edwin
 
I agree with your descriptions of the two problems that need to be solved.
 
I don't though, think of choreographies as the interface to a complex
service. Instead I think of them as "the sequence of messages exchanged
between two or more services in order to implement a (business) process".
Note that I said "sequence of messages". This means that you could have
different types of services with different WSDL definitions sending and
receiving those same messages in the same sequence. If you don't do it this
way, then you are stopping the re-use of a choreography as the choreography
will be tied to particular services.
 
I also think that this type of choreography needs to be defined using a
choreography language. This is diffferent from a business process language
which defines the sequence in which processes (in this context web services)
are excecuted - i.e. not messages.
 
I also don't think that public vs private processes is the best way of
thinking of this distinction. For example you could have an ERP system which
requires a pre-defined choreography that must be followed and can't be
changed if you want to interact with that ERP. This information may not be
"public" knowledge.
 
So really, I think of choreographies as constraints on what a business
process can do and something which business process languages should
recognize.

David

-----Original Message-----
From: Edwin Khodabakchian [mailto:edwink@collaxa.com]
Sent: Thursday, October 17, 2002 7:02 PM
To: 'Burdett, David'; 'Mark Baker'; 'Champion, Mike'
Cc: www-ws-arch@w3.org
Subject: RE: Definition of Choreography


David,
 
It seems that what you are sharing is the public interface of your
service/process. In the example described in [1], you are sharing that the
seller exposes a service that understands Order and ChangeOrder messages and
also that Change Order only makes sense after Order.
 
What you are not sharing is what happens when you get an Order (our private
implementation of this service): that private implementation could be
entirely manual or completely automated. It could itself include
asynchronous interactions with legacy mainframe application, batch
processing etc..
 
There seems to be 2 problems: 
[Problem #1] How do you describe the interface of a complex service such as
the seller service described in one where a client needs to send and receive
multiple message from the service to get its result.
 
[Problem #2] How do you code, execute and run the back end application that
implements the public protocol implemented using problem #1.
 
Problem #2 is about control logic and requires a programming language. That
programming language can be expressed in XML or a script, that is
irrelevant. Standardizing that language will only offer portability between
the workflow engines that execute that language, it will *not* increase
interoperability.
 
Problem #1 can be solved in various ways: 
- Extend WSDL so that it not only defines the port types but also the public
protocols defined 
  between the port types.
 
- "bake" the public protocol into the interface definition of the service.
In the example described in [1]
  this option would be implemented by having the Order operation return the
uri of the ChangeOrder
  operation forcing the Order to be invoked before the change order. [Paul
Prescod posted a couple 
  of email on the merit of that approach]
 
- Coming up with a low tech approach, where the protocol is only available
through a documentation:
  developers have to read the documentation to use the service correctly and
have to handle exceptions
  when they don't (JavaDoc ++ for web services).
 
There are probably many more ways to address this to.
 
 
By choreography, are we trying to solve problem #1 or problem #2?
 
Edwin
 
 
 

-----Original Message-----
From: www-ws-arch-request@w3.org [mailto:www-ws-arch-request@w3.org] On
Behalf Of Burdett, David
Sent: Thursday, October 17, 2002 6:30 PM
To: 'Mark Baker'; Champion, Mike
Cc: www-ws-arch@w3.org
Subject: RE: Definition of Choreography



Mark 

You said ... Why would I ever need to *share* a description with anybody? 

If you are inside your own business you don't. But choreographies can go
between businesses, in which case you definitely do - see [1].

Both sides **need** to know exactly what choreography they are following
otherwise you don't get interoperability. For example we have identified 14
different choreographies that can be used to place an order. Without a) a
precise definition of the choreography that is actually going to be used,
and b) a shared understanding of that choreography by both ends, it just
won't work.

... or am I missing something ... 

Regards 

David 
[1] http://lists.w3.org/Archives/Public/www-ws-arch/2002Oct/0217.html
<http://lists.w3.org/Archives/Public/www-ws-arch/2002Oct/0217.html>  

-----Original Message----- 
From: Mark Baker [ mailto:distobj@acm.org <mailto:distobj@acm.org> ] 
Sent: Thursday, October 17, 2002 6:15 PM 
To: Champion, Mike 
Cc: www-ws-arch@w3.org 
Subject: Re: Definition of Choreography 



On second thought, I'd like to focus on this part of your response, 
Mike; 

On Wed, Oct 16, 2002 at 09:50:12PM -0400, Champion, Mike wrote: 
> reason = prompt("why are you doing this to yourself?") 
> destination = prompt("where are you going") 
> departure = prompt("when do you leave") 
> return = prompt("when do you return") 
> tripId = TentativelyBookTravel(destination, departure, return) 
> estimatedCost = getCost(tripId) 
> if (estimatedCost > managerApprovalLimit) 
>    approved = getVPApproval(reason, estimatedCost) 
> else 
>    approved = getManagerApproval(reason, estimatedCost) 
> if (approved) 
>   confirmTrip(tripId) 
> else 
>   cancelTrip(tripId) 

This is a good example.  And one could certainly specify a language for 
describing such a flow of operations.  But why is a *standardized* 
language required?  Why would I ever need to *share* a description with 
anybody? 

As I see it, that flow (minus conditions, which are encapsulated within 
the service) can be observed at runtime, so doesn't need to be specified 
earlier, at least for interop reasons.  So I invoke "prompt()" on the 
first service, which returns "why are you doing this to yourself?", 
which I answer by invoking "answer('because I feel like it')".  The 
response to that invocation is then another question, or perhaps a 
pointer to the next service which I invoke prompt() on, etc, etc.. 

Behind the scenes, I could certainly be using some description language 
to drive this flow.  But again, why does it matter if it's standardized 
or not?  The only reason I could think of, is because we're trying to 
enable somebody to reuse their rules with different tools.  But that 
seems quite different than the motivation I've seen for some of the 
choreography specs out there.  For example, all of them integrate with 
WSDL, which suggests that choreography is part of the interface, not 
just the implementation. 

Can anybody shed some light on this? 

MB 
-- 
Mark Baker, CTO, Idokorro Mobile.  Ottawa, Ontario, CANADA. 
http://www.markbaker.ca <http://www.markbaker.ca>
http://www.idokorro.com <http://www.idokorro.com>