RE: Correlation Requirements

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

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

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.