RE: Correlation Requirements

Assaf

I can't think either of a situation where the data in the payload does not
contain information that can be used for corellation. So perhpas we should
not be concerned about that.

However, you also said ...
>>>Remember that the activity can't handle the wrong message type anyway, 
so you need to send it the right message type, which means you know 
where to look for the correlation information. And with WSDL/SOAP it's 
easy to match the incoming message type to the operation being performed 
and route it to the proper activity.<<<

Perhaps, but there is a use case where you might need to have the same
"logical" service accept multiple different message types. By a "logical"
service, I mean a service that provides the same functionality, for example
accepting/processing a purchase order, but is liberal in terms of the way
the order is presented, for example it might accept through the same port:
* SOAP 1.1 or SOAP 1.2
* WS Reliability as well as WS-Reliable Messaging
* UBL, OAG, RosettaNet & other order documents
* Variations on the above to allow for industry and regional requirements
* + more (probably)

The resulting possible permutations you can have is actually quite large.
If, as you suggest, that a service can only accept one variation, then you
will end up with multiple different WSDL definitions I think.

Can you see a way around this problem?

David

-----Original Message-----
From: Assaf Arkin [mailto:arkin@intalio.com]
Sent: Tuesday, August 12, 2003 2:29 PM
To: Burdett, David
Cc: Keith Swenson; 'Monica Martin'; 'Martin Chapman'; 'Yves Lafon';
jdart@tibco.com; 'Ugo Corda'; 'Cummins Fred A'; public-ws-chor@w3.org
Subject: Re: Correlation Requirements


Burdett, David wrote:

> 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?
>
The correlation specification (property, alias, etc) is helpful in 
letting the service know where to look for the information, so there's 
no confusion. There may be many different definitions out there in the 
world, but the service definition is written to use exactly one 
definition. The specification is very precise, there's no guessing where 
the correlation data comes from.

I can't think of a single case where you would want to correlate 
something and not have any data in the payload to use for correlation. 
In fact, in some cases you have more than one piece of data and you need 
to decide which one works best.

There are, however, simple cases like a request followed by a response 
where you would rather not bother with the details and let the RM 
protocol do the work. Of course, the RM protocol adds a field - and 
sometimes more than one field - you can use for correlation. But for the 
simple case you just let the RM protocol take care of it using something 
like WS-Addressing.

> 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.
>
Remember that the activity can't handle the wrong message type anyway, 
so you need to send it the right message type, which means you know 
where to look for the correlation information. And with WSDL/SOAP it's 
easy to match the incoming message type to the operation being performed 
and route it to the proper activity.

arkin

> Thoughts?
>
> David
>