RE: Correlation Requirements

Jon

I agree that we should not define a correlation solution, however I think
our success is dependent on the existence of one as described in "The specs
we need ..." email.

Do you agree?

David

-----Original Message-----
From: Jon Dart [mailto:jdart@tibco.com]
Sent: Monday, August 11, 2003 11:00 AM
To: Mark Little
Cc: Burdett, David; 'Keith Swenson'; 'Monica Martin'; 'Martin Chapman';
'Yves Lafon'; 'Ugo Corda'; 'Cummins Fred A'; public-ws-chor@w3.org
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
>              >
>