- From: Mark Little <mark.little@arjuna.com>
- Date: Tue, 12 Aug 2003 09:31:53 +0100
- To: <jdart@tibco.com>
- Cc: "Burdett, David" <david.burdett@commerceone.com>, "'Keith Swenson'" <KSwenson@fsw.fujitsu.com>, "'Monica Martin'" <monica.martin@sun.com>, "'Martin Chapman'" <martin.chapman@oracle.com>, "'Yves Lafon'" <ylafon@w3.org>, "'Ugo Corda'" <UCorda@SeeBeyond.com>, "'Cummins Fred A'" <fred.cummins@eds.com>, <public-ws-chor@w3.org>
Would it not be possible to say something like "we assume the presence of context" and just move on then? Mark. ----- Original Message ----- From: "Jon Dart" <jdart@tibco.com> To: "Mark Little" <mark.little@arjuna.com> Cc: "Burdett, David" <david.burdett@commerceone.com>; "'Keith Swenson'" <KSwenson@fsw.fujitsu.com>; "'Monica Martin'" <monica.martin@sun.com>; "'Martin Chapman'" <martin.chapman@oracle.com>; "'Yves Lafon'" <ylafon@w3.org>; "'Ugo Corda'" <UCorda@SeeBeyond.com>; "'Cummins Fred A'" <fred.cummins@eds.com>; <public-ws-chor@w3.org> Sent: Monday, August 11, 2003 7:00 PM Subject: Re: Correlation Requirements > > Yes, I have looked at WS-Context. It could be used for the purposes that > have been discussed in this thread. > > I don't think this is really a choreography requirement at all. > Correlation is a general requirement for effective use of Web services > in multiple ways, including composite applications, choreography, > transactions, and asynchronous processing. > > Unfortunately there are multiple emerging standards in this area (of > which WS-Context is one). > > I do not think WS-Choreography can, or should, take on this problem. > > In particular I do not think we should get specific about header > information required for choreography participants. This issue is going > to get resolved eventually, external to this group. (It would be nice if > there was one agreed-on resolution, but the outcome may be there's more > than one way to handle it). When that happens some re-alignment of > WS-Choreography with other standards may be necessary. > > But meanwhile IMO it is possible to make progress in the choreography > area without having a resolution to this issue (and IMO any resolution > at this point by this group would be premature). > > --Jon > > Mark Little wrote: > > Has anyone looked at the recently released WS-Context specification? > > It's aims seem to be in line with precisely this kind of correlation. > > > > Mark. > > > > ----- Original Message ----- > > *From:* Burdett, David <mailto:david.burdett@commerceone.com> > > *To:* 'Keith Swenson' <mailto:KSwenson@fsw.fujitsu.com> ; Burdett, > > David <mailto:david.burdett@commerceone.com> ; 'Monica Martin' > > <mailto:monica.martin@sun.com> > > *Cc:* 'Martin Chapman' <mailto:martin.chapman@oracle.com> ; 'Yves > > Lafon' <mailto:ylafon@w3.org> ; jdart@tibco.com > > <mailto:jdart@tibco.com> ; 'Ugo Corda' <mailto:UCorda@SeeBeyond.com> > > ; 'Cummins Fred A' <mailto:fred.cummins@eds.com> ; > > public-ws-chor@w3.org <mailto:public-ws-chor@w3.org> > > *Sent:* Monday, August 11, 2003 7:28 AM > > *Subject:* RE: Correlation Requirements > > > > I think you have two use cases: > > 1. Where there is *no* data inside the "payload" that can be used > > for corellation purposes, and > > 2. Where there *is* data inside the "payload" that can be used for > > corellation > > > > Now, since the first case will sometimes exist, when there is a need > > for corellation, then you really have no option but to put some type > > of "choreography instance identifier" in data that is carried with > > the message, or what, for the purposes of this email, I am calling > > message "metadata" (Note, for SOAP this would be almost be data in a > > SOAP header). > > > > However if you always insist that the "choreography instance > > identifier" is present in the message metadata, then, in the second > > case, there is a risk that the data inside the payload might be > > inconsistent with choreography instance identifier in the messsage > > metadata. This inconsistency is almost certainly incorret and so > > there is an error which would should be flagged. > > > > You can avoid this inconsistency, if, message metadata, you > > reference the data in the payload instead with a "choreography > > instance reference", but at the expense of more complexity in how > > the correllation is done since it will be impossible, for example to > > restrict the type of the correlation which could include a > > combination of different data of different types. For example you > > might need to do correllation based on a combination of "supplier > > identifier, year and order no". > > > > My *personal* $0.02c, would be to always have a "choreography > > instance identifier" in the data carried with the message, e.g. the > > SOAP header, as: > > a) There is always just one way to do correlation at "messaging > > middleware" level, i.e. in the software layer between the transport > > protocol software and the applicaiton > > b) The probability of inconsistency between the message > > c) It is *much* simpler! > > > > Now, before anyone says anything, I know this is talking about a > > design, but I think that sometimes thinking about design problems > > actually helps clarify the problems ... with the proviso that you a) > > record your design decisions (i.e. in emails like this) and b) you > > are prepared to revisit the problem in the light of a better > > understanding of the problems/issues. If we try and postpone *all* > > these things, then we are just creating more problems for later in > > my opinion! > > > > David > > > > -----Original Message----- > > *From:* Keith Swenson [mailto:KSwenson@fsw.fujitsu.com] > > *Sent:* Sunday, August 10, 2003 10:46 PM > > *To:* Burdett, David; 'Monica Martin' > > *Cc:* 'Martin Chapman'; 'Yves Lafon'; jdart@tibco.com; 'Ugo > > Corda'; 'Cummins Fred A'; public-ws-chor@w3.org > > *Subject:* RE: Correlation Requirements > > > > 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 > > > > > > > > >
Received on Tuesday, 12 August 2003 04:32:52 UTC