David,
I think the different document formats that you are talking about would correspond to different concrete bindings of the same abstract WSDL interface, probably corresponding to different ports (your point 1 below). So my assumption would be that the two parties exchanging the concrete document format would both be capable of dealing with that particular binding (otherwise they would not be talking directly to each other, and some kind of intermediary node would be interposed between them which would translate from one concrete message format to the other). Part of the binding definition would be the knowledge of how to find inside the concrete message the parts that were defined at the abstract level as components of the correlation.
Ugo
-----Original Message-----
From: Burdett, David [mailto:david.burdett@commerceone.com]
Sent: Tuesday, August 12, 2003 2:08 PM
To: 'Assaf Arkin'; Keith Swenson
Cc: Burdett, David; 'Monica Martin'; 'Martin Chapman'; 'Yves Lafon'; jdart@tibco.com; Ugo Corda; 'Cummins Fred A'; public-ws-chor@w3.org
Subject: RE: Correlation Requirements
Assaf
Having rechecked the BPEL spec, I agree that having multiple ways to identify a choreography instance makes sense. It also seems that the exact way in which you do correlation will depend on the implementation. For example a sales management application may accept orders in various different document formats, e.g. UBL, RosettaNet, EDI, etc.
I am wondering how this would work from a practical perspective as the service that receives the message MUST know where to look for the data that acts as the correlation. Also, what do you do if there is no data in the payload that can be used for correlation purposes?
For the first problem I can think of two ways of making it work:
1. You send the messages to different ports (URLs) depending on the format of the message, or
2. You have something in the header of the message that identifies the type of the message which can then be used to identify where to look for correlation purposes.
Thoughts?
David
-----Original Message-----
From: Assaf Arkin [ mailto:arkin@intalio.com]
Sent: Monday, August 11, 2003 5:05 PM
To: Keith Swenson
Cc: Burdett, David; 'Monica Martin'; 'Martin Chapman'; 'Yves Lafon';
jdart@tibco.com; 'Ugo Corda'; 'Cummins Fred A'; public-ws-chor@w3.org
Subject: Re: Correlation Requirements
If you can participate in multiple threads of discussion at the same
time, than a simple header is not going to buy you much. You need a more
extensible mechanism for correlation. Although you'll have to specify
that per choreography, specifying it means it's specified. Once
specified there is exactly one way to communicate it, and so you can
ensure interoperability.
The correlation mechanism in BPEL and WSCI is fairly generic but very
precise in its specification, and so allows for more complex use cases
that more simplified (one header) mechanisms can't deal with. Having
implemented it, I can attest that it's easy to use in a manner than
ensures interoperability.
However, in the simple case it's redundant. In the simple case you would
not use this mechanism, but rather get the correlation from the message
header. Two options that seem to work very well for us are using the
sequence group (RM), or using an addressing mechanism where each service
is addressed by a instance-specific address.
A header used specificaly to indicate the choreography instance seems
like the simple solution to a simple problem, but from the more
interesting use cases we have, it seems to be too restrictive and hard
on the implementation. Notice that other specifications that work that
way tend to create a gap between the interaction and the excutable, but
specifications that work in the "non intuitive" way (like BPEL and BPML)
can seamlessly do both things. Perhaps that's a lesson to be learned there.
Just my 2c
arkin
Keith Swenson wrote:
> I would like to understand why it is important to leave so many
> different ways of carrying correlation information. Our job is to
> produce a specification that will ensure interoperability. If there
> are an infinite number of ways to communicate correlation information,
> then we haven't really specified anything, have we?
>
> The reason I am probing this is because I want to understand what is
> the underlying "requirement" that we avoid being prescriptive. It
> clearly would be a benefit to the entire industry if we could stick
> with your requirements 1 & 2, except change 2 to specify exactly which
> header field MUST contain the choreography instance id. Why is it
> that "you don't want to have to be forced to use an identifier in the
> header."? Seems to me that the effort and cost to put this in a
> consistent place would be far less effort and cost that would be
> incurred by coding all the various point-to-point variations due to
> each implementation using a different way of coding correlation
> information.
>
> -Keith Swenson
>
> -----Original Message-----
> *From:* Burdett, David [ mailto:david.burdett@commerceone.com]
> *Sent:* Thursday, August 07, 2003 3:15 PM
> *To:* 'Monica Martin'; Burdett, David
> *Cc:* 'Martin Chapman'; 'Yves Lafon'; jdart@tibco.com; 'Ugo
> Corda'; 'Cummins Fred A'; public-ws-chor@w3.org
> *Subject:* RE: Correlation Requirements
>
> Monica
>
> The reason I included requirements 2 and 3 is that they reflect
> two use cases ...
>
> If we assume that there has to be some data in the message that
> can be used for correlation when the message is taking part in a
> choreography then requirement 2 arises becaus it is possible that
> there is no data in the payload (or anywhere else) that can be
> used for correlation purposes.
>
> Requirement 3 arises because there maybe data that can be used in
> the payload and therefore you don't want to have to be forced to
> use an identifier in the header.
>
> However, I can also see your point that the existing requirement
> definitions could be a bit too presrcriptive, so how about these
> as alternatives, I've added a fourth requirement which hopefully
> makes it clearer. The complete set is as follows ...
>
> Requirement 1 (not changed)
> If a message is being sent between roles as part of the
> "performance" of a choreography, then that message MUST identify
> the "choreography instance" to which it belongs.
>
> Requirement 2 (changed)
> A choreography instance MUST be identified by specifying a
> separate identifier associated with the payloads in the message
> where there is no combination of data in the "payload(s)" that can
> be used to uniquely identify the choreography instance that is
> being performed.
>
> Requirement 3 (changed)
> A choreography instance MAY be identified by referencing a
> combination of one or more items of data in the "payload(s)" of
> the message where that combination of data can be used to uniquely
> identify the choreography instance that is being performed.
>
> Requirement 4 (new)
> A choreography instance MAY be identified by specifying a
> separate identifier associated with payload(s) in the message even
> if there is a combination of data in the "payload(s)" that can be
> used to uniquely identify the choreography instance that is being
> performed.
>
> David
> -----Original Message-----
> From: Monica Martin [ mailto:monica.martin@sun.com]
> Sent: Thursday, August 07, 2003 3:03 PM
> To: Burdett, David
> Cc: 'Martin Chapman'; 'Yves Lafon'; jdart@tibco.com; 'Ugo Corda';
> 'Cummins Fred A'; public-ws-chor@w3.org
> Subject: Re: Correlation Requirements
>
>
> Burdett, David wrote:
>
> > A very good point Martin - I was presuming "a" solution which is
> > perhaps premature.
> >
> > So let's do this the "right" way and think about it in terms of
> > requirements so here's my $0.02c on what they might be ...
> >
> > Requirement 1
> > If a message is being sent between roles as part of the
> "performance"
> > of a choreography, then that message MUST identify the
> "choreography
> > instance" to which it belongs
> >
> > Requirement 2
> > A choreography instance MAY be identified by specifying a unique
> > identifier in "metadata" (e.g. a SOAP header) associated with
> the message.
> >
> > Requirement 3
> > A choreography instance MAY be identified by referencing a
> combination
> > of one or items of data in the "payload(s)" (e.g. the SOAP body
> and/or
> > attachments) of the message.
> >
> mm1: I would suggest on Reqt 2 and 3 that we specify the
> requirement not
> the solution, of which these requirements appear to do both.
> Particularly, a choreography instance may be referenced, - do we
> specify
> how?
>
> > To make these complete, we should also define, roles, performance,
> > choreography instance, metadata and payload, but that can come
> later!
> >
> > Thoughts?
> >
> > David
> >
>