- From: Assaf Arkin <arkin@intalio.com>
- Date: Mon, 17 Mar 2003 12:12:28 -0800
- To: "Furniss, Peter" <Peter.Furniss@choreology.com>, <public-ws-chor@w3.org>
- Message-ID: <IGEJLEPAJBPHKACOOKHNAEKEDFAA.arkin@intalio.com>
MessageWe have four separate issues.
1. Do we need a model to define a conceptual relation between trading
partners that is not grounded in WS specifically?
I would say yes.
2. Do we need to do that in the WS Choreography working group?
I don't see why. There are other groups that are better equipped to deal
with this issue, e.g. ebXML is doing a lot of work around UMM and have a
stack the focuses on trading partners. I don't see the benefit of having two
open groups do overlapping work. In fact, does anyone think there is a valid
need for replicating the work done by the ebXML groups?
3. Are all form of communication between partners going to be of the SOAP
over Internet?
I would we are moving in that direction but it will never happen. There will
always be manual forms of communication, especially for those businesses
that want to deal with small entities like consumers. There are things that
you would like to do offline, and I can give a good example for why my
insurance company allows me to manage my policy, change it, make payments,
etc online but requires a phone call to cancel the policy. It has nothing to
do with technology or partner agreements: it has to do with business sense.
4. Is that an issue?
Not in practice, because what we see out there are tools that are well
equipped to deal with other forms of communication yet by virtue of tracking
them represent them through a Web service interface. So even though in this
particular case of my insurance company there is a step that is done not
using Web services technology, in fact there is a WSDL representation of
that communication which is used to build a choreography.
When you go out and try to get buyers and sellers to talk to each other
using SOAP over TCP you find that this approach works well but by definition
will always exclude some group of buyers or some group of sellers. And as
per the example above it may have nothing to do with techonology as much as
business sense.
But when, like us, you go and try to define choreographies between buyer and
seller you find out that all that information is in fact captured by WSDL
interfaces. How do you represent the user intent using WSDL? What I tell my
insurance company on the phone is captured down in their system, and their
system exposes a message exchange on my behalf (the proxy approach), which
is part of the choreography between the all center (representing me buyer)
and the back-end system (representing seller).
A year ago I had the same opinion and doubts as you, but after going into
accounts like these and worrying about the limitation of an approach that
could only describe automated forms of interaction, I learned that in
practice this is not a problem we stumble upon.
arkin
-----Original Message-----
From: Furniss, Peter [mailto:Peter.Furniss@choreology.com]
Sent: Monday, March 17, 2003 4:28 AM
To: Assaf Arkin; public-ws-chor@w3.org
Subject: 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
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
Received on Monday, 17 March 2003 15:13:25 UTC