RE: General Choreography and Bi-lateral Choreography

Arkin,
 
I'm afraid I don't follow some of this.  You seem to be saying something
more extreme than I would : that if a communication between components
(loosely termed) is not in practice mapped to a WSDL-able
representation, then it cannot be referenced in the choreography
description of either components' other interactions. That could be
taken as defining what a choreography description is - (and is for) -
that it covers a community whose members behaviour is sufficiently
completely described such that whole communities process can be studied
and determined. Obviously, to do that, the interactions and the
relationships between the interactions have to be reduced to a common
form.
 
But there is also description that defines an interaction by its effects
in semantic and contractual terms, regardless of how the other legs are
done. That was just applicable in the older world - the inter-party
contracts may not have been written down in the same way,  but you
usually know what it means to you to invoke a (remote) method on a
colleague's object, even if you have no idea how they are working it.
Even more with EDI, you would know what you asked and not have the
foggiest what was going to interpret it.
 
If Choreography is limited to expressing its semantics in terms of other
WS messages, it would seem to be rather limited. Somehow it has to climb
out of the arena and express real-world intent. 
 
An alternative test: is choreography useful for a scenario where there
are only two services talking to each other - both connected into their
own business systems (for any interpretation of "business"), but with no
other WS interactions.
 
 
(this may be based on misunderstanding of your message - I especially
didn't follow the bit about buyer and seller proxy - do you mean that
this is a bi-lateral case ?)
 
Peter
 
 
-----Original Message-----
From: Assaf Arkin [mailto:arkin@intalio.com] 
Sent: 17 March 2003 02:40
To: Furniss, Peter; Ricky Ho; public-ws-chor@w3.org
Subject: RE: General Choreography and Bi-lateral Choreography



 

-----Original Message-----
From: public-ws-chor-request@w3.org
[mailto:public-ws-chor-request@w3.org]On Behalf Of Furniss, Peter
Sent: Sunday, March 16, 2003 4:45 PM
To: Ricky Ho; public-ws-chor@w3.org
Subject: RE: General Choreography and Bi-lateral Choreography


I agree with the view that concentrating on the bilateral case will be
helpful.
 
One test against the utility of "general" choreography is to consider
the case where some of the communication is not web-services
(effectively, not usefully represented in wsdl).  Take the use case
Ricky started with , of buyer - seller -shipper.  If the seller-shipper
communcations were by phone/fax, or legacy edifact, the buyer-seller and
buyer-shipper conversations could well be exactly the same.  So the
Choreography description as known and used by the buyer need not (and
indeed should not) be dependent on how the other two talk to each other.
 
Most ERP vendors will tell you this is a non-issue. While they support
phone, fax and other forms of non-IP communication, that information is
fed into the system manually and therefore there is a representation of
the information exchange irrelevant of the protocol used. In fact, in
one of the scenarios we have been dealing with part of the information
is exchanged by fax. But form that point on it either vanishes into thin
air and neither buyer nor seller can use it, or it is fed into a system
which can track it, in which case it becomes part of the choreography
and a message described by WSDL. The fact that a lot of information is
carried over non-IP protocols seems to orthogonal to the fact that any
computer system dealing with that information can in fact describe it as
a message exchange.
 
They will also tell you it's a non-issue because most of the problems
they are trying to solve are not of the buyer-seller-shipper partner
variety, but more of the buyer-seller-shipper components/gateway
interaction, so the choreography is defined in terms of buyer proxy
talking to seller proxy, where one can be represented by the ERP and
another by an EDI gateway. I know of at least one big manufacturer who
views their partner relationships in exactly that way.
 
There's kind of a mental shift here. In the CORBA/DCOM/EDI world, if it
wasn't travelling over the wire in that one and only protocol then it
could not be described. If you used IIOP but it was travelling over EDI
it was invisible to you, and vice versa.
 
On the other hand with Web services, if you can proxy it, transform it,
scan it, or type it in, you can describe it. You don't need to talk to
your partner using HTTP, you can have someone feed the information to a
WS proxy HTML form, and you can define that WS proxy as representing the
interaction with that partner. Which says a lot about the revolutionary
approach of Web services*
 
arkin
 
* Needless to say if you were ever thinking of enabling road warriors to
conduct business online having just a PDA and base Internet link, or
even a Web-enabled phone, that's the way to do it.
 
Even the linkage between the conversations involving a single party is
rather limited. Much of it is kind of "typed reference" to another
service - if the buyer tells the seller the address of the buyers ws
that will be used by the shipper, then, if we have good bilateral
choreography descriptions, that passed address (uri) might be typed by
the appropriate description. And there is likely some data field passed
as well, so the buyer knows which incoming shipment corresponds to which
order. But again, that's fairly weak linkage.
 
one further comment inline

-----Original Message-----
From: Ricky Ho [mailto:riho@cisco.com] 
Sent: 16 March 2003 08:20
To: Burdett, David; public-ws-chor@w3.org
Subject: General Choreography and Bi-lateral Choreography


David,

I agree with everything you say.  However, I want to elaborate my view
on multi-party choreography.

Most real life B2B scenario are multi-party interaction.  But
"multi-party interaction" is NOT equivalent to "multi-party
choreography".  For example, a company (or "domain of control") can have
an orchestration that span multiple "bi-lateral" choreographies.  In
other words, "multi-party interaction" can be realized by multiple
"bi-lateral" choreographies linked together by orchestration.  The only
thing lost is the sequence dependencies between message exchanges within
choreographies is NOT captured externally.

I honestly don't think bi-lateral choreography is sufficient to capture
arbitrary public protocol sequence.  For example, the well-known 2-phase
commit protocol cannot be specified using bi-lateral choreography.  So I
agree with you that in a generic sense "choreography" should NOT be
restricted to 2 parties.
 
 
prf: on the 2-phase commit comment: I'm not sure if you mean
*bi-lateral" isn't sufficient, or "choreography" isn't sufficient. As I
said before, I think treating 2-pc as an example "application protocol"
- i.e. the subject for a choreography description - can be very
instructive.
 
2-pc can certainly be defined, precisely and fully, involving only two
parties. This was done in the OSI Commitment, Concurrency Recovery (CCR)
spec [ in fact, because standards politics meant it wasn't allowed to
have normative multi-party text, but also was required to have normative
semantic definition], and is also (I hope) complete in the BTP
specification of the "outcome" protocol (the superior:inferior bit).
There are implications for what is going on with other parts of the
transaction tree, but the fundamental protocol is in fact two-party. (my
diagram with the 3 dumbells and the box, on about my 4th slide was meant
to show this, but I fear may not have explained it well] (I mention CCR
and BTP because I know them - there may be other specs of similar
nature)
 
What you do need, beyond the simple message exchange rules, are
statements of the implied semantics of the messages. This is most
certainly part of the contract definition between the parties, and we
strongly believe any useful choreography specification needs to have
ways of stating the contractual implications (at least the
software-contractual implications) of the messages.
 
Peter

------------------------------------------
Peter Furniss
Chief Scientist, Choreology Ltd

   Cohesions 1.0 (TM)
   Business transaction management software for application coordination

web: http://www.choreology.com <http://www.choreology.com/> 
email:  peter.furniss@choreology.com
phone:  +44 20 7670 1679
direct: +44 20 7670 1783
mobile: +44 7951 536168
13 Austin Friars, London EC2N 2JX