RE: Grounding Choreographies (the atoms) - WAS Simple Choreograph y composition suggestion

The OASIS Web Services Reliable Messaging TC has recently started to discuss the issue of describing RM interfaces in WSDL (see the long "WSDL for WSRM" thread in the June and July archives at http://lists.oasis-open.org/archives/wsrm/ - you might remember that the original WS-Reliability submission only dealt with SOAP, not WSDL).

It might be a good idea to rely on what the RM groups come up with, instead of replicating their work here.

Ugo

> -----Original Message-----
> From: Assaf Arkin [mailto:arkin@intalio.com]
> Sent: Friday, July 18, 2003 2:11 PM
> To: Burdett, David
> Cc: Frank McCabe; Martin Chapman; Steve Ross-Talbot; Champion, Mike;
> public-ws-chor@w3.org
> Subject: Re: Grounding Choreographies (the atoms) - WAS Simple
> Choreograph y composition suggestion
> 
> 
> 
> Burdett, David wrote:
> 
> >Assaf
> >
> >I agree that we need to agree on terminology, e.g. roles vs 
> agents, I have
> >no strong views on which is better.
> >
> >I also like the idea of using WSDL interfaces, however I can see some
> >issues, for example:
> >1. Both the RM specs use SOAP to send their acknowledgement 
> messages and
> >retries. So, for example, if you had a WSDL definition that 
> defined a PO as
> >input and generated a PO Response as output, then how would 
> the other RM
> >messages be defined in the WSDL?
> >
> Out-of-band.
> 
> You have one WSDL interface covering the operation you are trying to 
> perform. The PO request and PO response. That's the input to 
> the service 
> and the output from the service.
> 
> You have another WSDL interface covering the ack/resend/etc. 
> That one is 
> defined by the RM protocol. It is implemented by the RM 
> Service. The RM 
> Service is used in combination with the PO service, but as an 
> out-of-band interaction that is used only if a particular protocol is 
> chosen.
> 
>  From the pespective of the application you send a PO request and 
> receive a PO response. The recevier's protocol handler 
> recognizes the RM 
> protocol and uses the RM Service's endpoint to send back and ack.
> 
> This has three obvious benefits:
> 
> 1. You define the RM interface exactly once. You don't need to define 
> specific operations, messages, etc each time you use RM. More 
> reusability.
> 
> 2. You can decide if/when/which RM protocol to use without having to 
> change the interface definition. The protocol selection is carried in 
> the message.
> 
> 3. You can combine many different protocols in that way.
> 
> Now, for just using RM it's possible to come up with some MEP 
> that would 
> be generally efficient. But the out-of-band model has more 
> efficiency. 
> For example, if could ack multiple messages together, or request 
> multiple resends together. If you try to combine RM + coordination + 
> security context, your MEP would be hairy to define. But in 
> this model 
> you can easily turn these protocol features on & off without 
> having to 
> create all the possible MEPs.
> 
> >2. If you then wanted to layer an MEP on top of this which included
> >additional "signal" messages where each signal message was 
> also sent using
> >RM protocols then how would these be included in the WSDL?
> >
> Because you're making the protocol signals orthogonal to the 
> actual WSDL 
> interface, you let the protocol handler make the appropriate 
> decisions 
> which signals to make. This allows it not only support ack/resend 
> (easy), but also to couple that with multiple-message acks, is-alive 
> pings, flow control, combining/splitting messages, etc.
> 
> And you can combine any number of protocols like that. The RM would 
> typically be used for the duration of a single operation, while a 
> coordination protocol would involve multiple operations. 
> Establishing a 
> security context (single sign-on) would do both since the context may 
> last longer than one operation, but may expire and be re-established 
> before all operations are completed.
> 
> So that scheme seems to be the most efficient one in my opinion, and 
> also allows for proper layering of different protocols (business and 
> technical).
> 
> arkin
> 
> >3. How would you provide support for 1 and 2 above in WSDL 
> in a way which
> >allowed a single basic definition of the "business" 
> choreography, e.g. you
> >send a PO and get a PO response back, even though you could 
> get variations
> >in the actual signals and RM protocol used as well as the 
> physical message
> >format used?
> >
> >I'm not saying it can't be done, I just don't know how.
> >
> >Regards
> >
> >David
> >
> >-----Original Message-----
> >From: Assaf Arkin [mailto:arkin@intalio.com]
> >Sent: Friday, July 18, 2003 1:14 PM
> >To: Burdett, David
> >Cc: Frank McCabe; Martin Chapman; Steve Ross-Talbot; Champion, Mike;
> >public-ws-chor@w3.org
> >Subject: Re: Grounding Choreographies (the atoms) - WAS Simple
> >Choreograph y composition suggestion
> >
> >
> >It all boils down to terminology. I'm not suggesting any, 
> just pointing 
> >out a problem.
> >
> >If we say "roles" and the WSA says "agents" then there's a 
> mismatch. If 
> >the WSA defines an architecture in terms of agents 
> interacting, but a 
> >choreography can't involve agents (that would be an 
> orchestration) then 
> >we might have a problem there. We need to raise this and work out a 
> >terminology that is consistent across the board.
> >
> >So going back to Frank's original e-mail, either I didn't understand 
> >what was said, or we need to better align the usage of terminology 
> >between the two groups.
> >
> >
> >As for what the interaction is, I much prefer if we talk in terms of 
> >WSDL interfaces. Then we won't have to go down into the 
> details of HTTP, 
> >ack/resend, etc. When you express everything in terms of 
> WSDL interface 
> >you are talking about these roles/agents interacting with 
> each other. 
> >The protocol may end up using HTTP, it may include 
> additional signals 
> >for RM, out-of-band signals for coordination, establish security 
> >context, whatever.
> >
> >Since this is already taken care of by other specifications 
> that you can 
> >plug-in, I would much prefer to focus solely on use of WSDL 
> interfaces.
> >
> >arkin
> >
> >Burdett, David wrote:
> >
> >  
> >
> >>Assaf
> >>
> >>My take is that strictly speaking, a choreography is "A 
> definition of the
> >>sequence and conditions in which a set of interactions 
> occur between two
> >>roles".
> >>
> >>Where *interactions* include both individual (e.g. HTTP) 
> messages as well
> >>    
> >>
> >as
> >  
> >
> >>higher level concepts such as a single "reliably delivered 
> message" which
> >>actually requires several HTTP message to implement, or at 
> a even higher
> >>level, concepts such as a "Request for Quote". 
> >>
> >>Also roles can include, at a low level, general concepts 
> such as a "sender"
> >>and "receiver" which could be appropriate when defining the 
> choreography
> >>associated with a RM protocol, or such business level 
> concepts such as
> >>"buyer" and "seller" when defining a business level 
> protocol/choreography.
> >>
> >>In both cases roles defined in the choreography are 
> abstract and need to be
> >>mapped to the physical instances which will often, but 
> needn't be - as
> >>Martin mentioned, web services. If we say that 
> Choreographies *always* have
> >>to be *between* web services then it precludes the 
> choreography being used
> >>by something that is not a web service, which I don't think 
> we want to do.
> >>
> >>My $0.02c.
> >>
> >>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 Friday, 18 July 2003 17:48:25 UTC