W3C home > Mailing lists > Public > public-ws-chor@w3.org > August 2003

Re: Correlation Requirements

From: Steve Ross-Talbot <steve@enigmatec.net>
Date: Mon, 25 Aug 2003 15:03:31 +0100
Cc: Assaf Arkin <arkin@intalio.com>, public-ws-chor@w3.org, "'Cummins Fred A'" <fred.cummins@eds.com>, "'Ugo Corda'" <UCorda@seebeyond.com>, jdart@tibco.com, "'Yves Lafon'" <ylafon@w3.org>, "'Martin Chapman'" <martin.chapman@oracle.com>, "'Monica Martin'" <monica.martin@sun.com>, Keith Swenson <KSwenson@fsw.fujitsu.com>, "Burdett, David" <david.burdett@commerceone.com>
To: Andrew Berry <andyb@whyanbeel.net>, Jim Hendler <hendler@cs.umd.edu>
Message-Id: <E8D9C672-D704-11D7-925F-000393AD2AA6@enigmatec.net>

Sorry for not being around. I am picking this up on holiday so I'm not  
fully briefed. But from the tenor of the email exchange this sounds a  
lot like the semantics of the semantic web. This issue of what is an  
address and what are the line items sound strangely familiar to a lot  
of work done on semantic web services and so may well be tackled by  
DAML-S and of course SWSI. If I'm not barking up the wrong tree then  
I'd be interested to hear from the likes of Jim H and Frank Mc and  
others who have experience in this field. In particular how we can use  
ontologies to perform such mappings so that we only need to deal with  
semantics.

Cheers

Steve T

On Sunday, August 24, 2003, at 04:12  am, Andrew Berry wrote:

>
> Assaf,
>
> A few comments about modelling data inline.
>
> AndyB
>
> On Wednesday, August 20, 2003, at 12:21  PM, Assaf Arkin wrote:
>> Burdett, David wrote:
>>> Assaf
>>>
>>> I agree with most of what you say although I have a few questions in  
>>> line but one point struck home ...
>>> >>>So we need some separation of concerns. We need to identify  
>>> concerns that are general to any kind of WS, and concerns that are  
>>> specific to choreography. Those that are specific to choreography,  
>>> we should deal with. Those that are general to any kind of WS,  
>>> should be forwared to the respective working group.<<<
>>>
>>> ... so let's try and build the list of areas of concern and classify  
>>> them as:
>>> 1. A WS-Chor concern which WS Chor needs to fix
>>> 2. A concern for WS-Chor and other groups which needs to be fixed.
>>>
>>> The first we must tackle for the second we need to approach other  
>>> groups.
>>>
>>> Here's a start of a list ...
>>>
>>> 1. WS CHOR ONLY CONCERN
>>> Defining a Choreography definition language that includes:
>>> a) Message format independence, i.e. a message is defined in terms  
>>> of its semantics rather than its structure
>>>
>> This needs better clarification. You have very specific structures  
>> like RN vs OAG and you want to avoid dependency on those so as to  
>> allow multiple over-the-wire formats (as you discuss below). But  
>> there's also the content model or information structure that is  
>> important to convey. If you send me some message that is semantically  
>> a PO, that's not very helpful if I can't find some line items,  
>> billing address, etc in there. For me, that's not just how I build  
>> the implementation, but also a deciding factor whether or not to use  
>> the choreography. If the choreography is so abstract I have no clue  
>> what's coming in in the PO, I'm not going to even consider using it.
>
> While I see your point, this must be approached with some care: each  
> system typically has a different way of modelling addresses and line  
> items.  While the concepts "address" and "line item" are well  
> understood by the humans, the realisation of these in a common  
> framework is particularly difficult and often requires the application  
> of external standards.  Consider the effort that has gone into  
> ontologies and data modelling for RosettaNet and OAGIS.  My preference  
> would be to have concrete "bindings" both to the underlying service  
> infrastructure and to the ontology in a manner independent of the  
> abstract choreography definition.  So for example, we "bind" PO from  
> an abstract choreography definition to the RosettaNet definition for a  
> particular community and infrastructure.
>
> That said, if the behaviour of participants in a choreography  
> definition explicitly references particular data, then it must be  
> modelled.  The approach I've taken in my model is to allow the  
> language to apply functions to typed items.  For example, the billing  
> address associated with a purchase order would be expressed as  
> BillingAddress(PO) in the choreography definition.  In this way, we do  
> not constrain the structure of the data, but explicitly reference  
> those aspects of data that are relevant in the choreography  
> specification.
>
>>
>>> b) Service implementation indpendence, i.e. the choreography is  
>>> defined in terms of the roles that take part in an implementation  
>>> rather than the specifics of a service implementation
>>>
>>> b) Feature implementation indpenendence, e.g. how you do  
>>> corellation, security, reliability etc.
>>>
>> Or anything that's protocol specific or service specific. Things you  
>> want to abstract should be allowed to be abstracted. But, I don't see  
>> how this is a choreography only concern. I can definitely see why the  
>> choreography language needs to be defined in such a way that it  
>> supports this level of abstraction (e.g. by using WSDL interfaces and  
>> not endpoint definitions). Maybe the two b's are just "service  
>> implementation and protocol implementation independent"?
>>
>>>
>>> c) Composable, i.e. you can build new a choreography out of existing  
>>> choreographies in a hierachical way
>>> d) Error handling, i.e. handling responses/compensation for problems  
>>> found in lower level choreographies or, at the lowest level, MEPs.
>>>
>>> e) Multi-role, i.e. you can involve more than two roles in a  
>>> choreography, e.g. buyer, seller and shipper
>>>
>> +1
>>
>>> 2. SHARED CONCERN
>>> WSDL and/or SOAP related:
>>> a) Binding abstract messages to their physical equivalents definition
>>> b) Services that can support hundreds of semantically equivalent  
>>> messages with different message formats
>>> c) Binding abstract service definitions (that WS-Chor expresses as  
>>> roles) to concrete service implementations
>>> d) Binding logical error handling to their physical implementations.
>>> e) Identifying a set of related messages (correllation).
>>>
>> +1
>>
>> I'm just back from vacation, so I can't think of any more right now  
>> ;-)
>>
>> arkin
>>
>>> I am sure there are more ...
>>>
>>> Once we have identified the shared areas of concern, we can then  
>>> work what, if anything, we do about them.
>>>
>>> David
>>>
>>>
>>> -----Original Message-----
>>> From: Assaf Arkin [mailto:arkin@intalio.com]
>>> Sent: Wednesday, August 13, 2003 2:44 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
>>> >
>>> > 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:
>>> >
>>> Types or formats?
>>> A service can perform any number of operations. The service knows  
>>> which
>>> operation to perform based on the incoming message and of course will
>>> reject messages targeting operations it does not perform.
>>>
>>> The full list
>>> of operations and their respective message types is given in the WSDL
>>> definition of its interface. An incoming message identifies an  
>>> operation
>>> unambigously. This is something you get when you use WSDL and the
>>> appropriate binding (e.g. SOAP but not just SOAP)..
>>>
>>> You may also want to support multiple message formats for the same
>>> message type. This is something that happens at the protocol binding
>>> layer. Once the message gets in, it turns into a message of the
>>> applicable type, and passed to the application, again, unambigously
>>> identifying the operation being performed.
>>>
>>> It's important to remember that the WS stack HAS to work that way.  
>>> This
>>> is not an issue specific to choreography, so it shouldn't be solved  
>>> by
>>> the choreography people. If it didn't work correctly, it wouldn't  
>>> just
>>> break choreographies, it would break a lot of other applications. So
>>> it's important that it works consistently. And it's helpful that we
>>> don't have to deal with it (no need to boil the ocean). Imagine what
>>> would happen if we had to tackle it, WSBPEL has to tackle it, the  
>>> Grid
>>> people would have to tackle it, WS-RM would have to tackle it so it  
>>> can
>>> use WS-TX, etc. We'll never get any work done.
>>>
>>> So we need some separation of concerns. We need to identify concerns
>>> that are general to any kind of WS, and concerns that are specific to
>>> choreography. Those that are specific to choreography, we should deal
>>> with. Those that are general to any kind of WS, should be forwared to
>>> the respective working group.
>>>
>>> > * 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.
>>> >
>>> You can support any number of wire-protocols (SOAP 0.9, SOAP 1.1,  
>>> SOAP
>>> 1.2, etc) on the same service. As far as we are concerned at the
>>> application level, they all end up being the same message. Since the
>>> input to the service as defined in WSDL does not include the SOAP
>>> envelope, it does not matter which envelope the wire protocol uses.  
>>> And
>>> that's also true for other wire protocols like RN.
>>>
>>> WS-RM, WS-TX, WS-whatever are all headers that are processes by the
>>> protocol handlers, but again, they are not part of the service
>>> interface. Whether you send a message with or withour WS-RM, with or
>>> without WS-TX, or any combination of protocol headers, the WSDL
>>> interface is still the same and does not reference any of them.
>>>
>>> If you look at specifications like WS-RM, WS-TX, etc you will see  
>>> that
>>> they do not ask you to write a WSDL interface that includes these
>>> specific headers, nor do you have to incorporate protocol specific
>>> operations (ack, commit, failure, etc) into your WSDL interface. This
>>> all happens transparently to the activity we are concerned with.
>>>
>>> UBL, OAG, RN can all be different encodings (formats) of the same
>>> message type. So at the protocol binding layers you can specify  
>>> multiple
>>> formats for the same abstract message. The actual message received  
>>> over
>>> the wire would conform to a specific format. The message sent to the
>>> activity would conform to the generic message type defined for that
>>> specific operation.
>>>
>>> So a lot of the complexity is taken away by the layer covered by  
>>> WSDL.
>>> What we should be concerned with is the abstract message defined as  
>>> part
>>> of the operation for a particular interface. You then let the WS  
>>> stack
>>> deal with all the complexities of protocols, headers, encodings,
>>> routing, etc.
>>>
>>> Does this help?
>>>
>>> arkin
>>>
>>> > 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
>>> > >
>>> >
>>>
>>>
>>> --  
>>> "Those who can, do; those who can't, make screenshots"
>>>
>>> --------------------------------------------------------------------- 
>>> -
>>> Assaf Arkin                                           
>>> arkin@intalio.com
>>> Intalio Inc.                                            
>>> www.intalio.com
>>> The Business Process Management Company                 (650) 577  
>>> 4700
>>>
>>>
>>> This message is intended only for the use of the Addressee and
>>> may contain information that is PRIVILEGED and CONFIDENTIAL.
>>> If you are not the intended recipient, dissemination of this
>>> communication is prohibited. If you have received this communication
>>> in error, please erase all copies of the message and its attachments
>>> and notify us immediately.
>>>
>>
>>
>>
>
> This email is confidential and may be protected by legal privilege. If  
> you are not the intended recipient,  please do not copy or disclose  
> its content but  delete the email and contact the sender immediately.  
> Whilst we run antivirus software on all internet emails we are not  
> liable for any loss or damage. The recipient is advised to run their  
> own antivirus software.
>

This email is confidential and may be protected by legal privilege. If you are not the intended recipient,  please do not copy or disclose its content but  delete the email and contact the sender immediately. Whilst we run antivirus software on all internet emails we are not liable for any loss or damage. The recipient is advised to run their own antivirus software.
Received on Monday, 25 August 2003 10:34:41 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:01:01 UTC