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 Saturday, 23 August 2003 07:12:49 UTC