Re: Off topic but relevant

You left out addressing (to/from/reply to/fault to). Yes, IMO these are 
fundamental facilities. They are really below choreography in the 
overall WS stack, although choreography is a user of them. Ideally you 
need them closely integrated with WSDL, because there are WSDL 
constructs such as MEPs that cannot be reasonably implemented without 
them (see related thread in WSA).

But as to how best to make this happen, I am not sure.

--Jon

Burdett, David wrote:
> 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
>  >
> 
>

Received on Wednesday, 6 August 2003 20:18:20 UTC