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

I like this ideas of, for example, sending the RM messages to a separate
service. However, the question is what is the RM service associated with? It
could vary from one RM service for a one connector (SOAP node) to separate
RM services for each service.

This makes me think that you would have to specify the RM service to use
with a Service somewhere. However I think there are going to be two RM
"services" involved: at the sender - which would receive the acks, and the
receiver, e.g. to accept pings. However the WSDL would only define the
receiver side. Where would the "sender" RM service be specified - in the
original message?

Does this make sense?

David

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