- From: Assaf Arkin <arkin@intalio.com>
- Date: Tue, 19 Aug 2003 19:21:47 -0700
- To: "Burdett, David" <david.burdett@commerceone.com>
- Cc: Keith Swenson <KSwenson@fsw.fujitsu.com>, "'Monica Martin'" <monica.martin@sun.com>, "'Martin Chapman'" <martin.chapman@oracle.com>, "'Yves Lafon'" <ylafon@w3.org>, jdart@tibco.com, "'Ugo Corda'" <UCorda@seebeyond.com>, "'Cummins Fred A'" <fred.cummins@eds.com>, public-ws-chor@w3.org
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