Re: Correlation Requirements

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.
>>
>
>
>

Received on Saturday, 23 August 2003 23:11:01 UTC