RE: Correlation Requirements

Assaf

You said ...

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

I totally agree. But I would separate this problem into three parts:
1. Define the relevant states - by specifying in the choreography, *what*
"states" are relevant. For example the fact that an order contained goods
that had export restrictions, might have a substantive effect on the flow of
the choreography. In this case, the state "ExportRestrictedOrder", or
something like it, would need to be defined.
2. Determine document formats compatible with the choreography. For example,
there will be rules that uses information about an order and the parties
involved to determine whether or not it is export restricted. This means
that, before you can use a particular choreography, you need to make sure
that the order document format (or information derivable from eleswhere
using data in the document) contains the required information. Once you have
done that analysis, you can specify which choreographies can be used which
document formats.
3. Define the choreography binding. Finally, once you have identified
compatible combinations of document format and choreography, you can build
an implementation and specify exactly which choreography, document formats,
message formats, security, RM protocol, etc. as well as the services you are
going to use. You can also bind the state, e.g. "ExportRestrictedOrder" to
an executable set of conditions that allows the value of the state to be
determined for any order instance. At this point, you are specifying the
"how".

David

-----Original Message-----
From: Assaf Arkin [mailto:arkin@intalio.com]
Sent: Tuesday, August 19, 2003 7:22 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 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.

> 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 Thursday, 21 August 2003 23:27:38 UTC