Off topic but relevant

Jon

There's a whole bunch of things like "identification of choreography
instance" that can usefully be defined just once and then used by everybody.
I'd include in this the following additional information that needs to go in
a (SOAP) message (there are probably more):
1. Message Id - a unique id for a message
2. RefToMessage Id - a way of identifying an earlier message to which this
message relates - useful for identifying messages in error
3. Conversation Id - which is really a choreography instance id as it
identifies a set of related messages
4. Creation Time - the time a message was initially created
5. Expiry Time - the time after which the recipient of a SOAP message should
no longer process it.

These aren't new as ebXML Messaging identified them all several years ago -
but only in a way that could be used with ebXML.

I *totally* agree that these are not exclusively needed for Choreography and
therefore we could perhaps ignore the problem, but nobody seems to be
solving the problem either which means there is a severe risk that
definitions for these things will be reinvented multiple times which does
not make sense and could actually cause problems. For example what do you do
if you have two different "creation times" for a message. How do you decide
which to use?

I've actually got a couple of specs that define the above as SOAP headers.
Is anyone interested in taking them further ... to OASIS perhaps ... on a
royalty free basis of course?

David


-----Original Message-----
From: Jon Dart [mailto:jdart@tibco.com]
Sent: Wednesday, August 06, 2003 3:51 PM
To: Burdett David
Cc: 'Ugo Corda'; Cummins Fred A; public-ws-chor@w3.org
Subject: Re: simultaneous execution


These are not new objectives. IMO the only issue is, some of the 
facilities you were talking about (e.g. identification of choreography 
instance) are not a standard part of WSDL nor of common message formats. 
So there's potentially a problem there. One possibility (I think this 
was suggested) is that we decide these are abstract properties and we 
basically defer the problem of realizing them at a concrete message 
level, which I could support. If you want to go in a different direction 
than this, then I need convincing.

--Jon

Burdett, David wrote:
> I think we are actually agreed on two objectives:
> 1. The need to create choreography definitions that are indpendent of 
> the message format, and
> 2. To define how choreography definitions are bound to Web Services and 
> WSDL in particular.
>  
> I don't think these objectives are mutually exclusive and we should be 
> able to do both. Does anyone disagree?
>  
> David
> 
>     -----Original Message-----
>     *From:* Ugo Corda [mailto:UCorda@SeeBeyond.com]
>     *Sent:* Wednesday, August 06, 2003 3:06 PM
>     *To:* Cummins, Fred A; Burdett, David
>     *Cc:* public-ws-chor@w3.org
>     *Subject:* RE: simultaneous execution
> 
>>+1 to defining how WS-Choreography binds to Web services.
> 
>>The Charter specifically says: "The language(s) should build upon
>     the foundation of the WSDL 1.2".
> 
>>WSDL 1.2 defines interfaces and end points. If we don't at least
>     define some precise mapping between WS-Choreography and WSDL
>     interfaces, then I don't see in which >way we are building "upon the
>     foundation of WSDL 1.2".
>     [FAC] I believe we can do that without sacrificing broader
>     applicability of the choreography.  I'm more concerned that we not
>     link the choreography to the message formats. 
> 
>     If your concern is about about linking the choreography to the
>     message formats on the wire, I would like to point out, as I have
>     done before, that a portType/interface message structure does not
>     imply any commitment to a format on the wire. It's only when the
>     portType/interface is bound to a particular service that the wire
>     format is defined.
> 
>     Ugo
>