- From: Assaf Arkin <arkin@intalio.com>
- Date: Tue, 12 Aug 2003 14:29:03 -0700
- To: "Burdett, David" <david.burdett@commerceone.com>
- CC: Keith Swenson <KSwenson@fsw.fujitsu.com>, "'Monica Martin'" <monica.martin@sun.com>, "'Martin Chapman'" <martin.chapman@oracle.com>, "'Yves Lafon'" <ylafon@w3.org>, jdart@tibco.com, "'Ugo Corda'" <UCorda@seebeyond.com>, "'Cummins Fred A'" <fred.cummins@eds.com>, public-ws-chor@w3.org
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 >
Received on Tuesday, 12 August 2003 17:30:39 UTC