Re: Correlation Requirements

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