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

Burdett, David wrote:

> 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.
>
Implementation detail as far as we're concerned ;-)

If you are sending an ack back than all you care about is the end-point 
of the original sender so you can confirm receipt. If you are the 
original sender than you need to provide an end-point for acking, and 
you an decide whether to have one per connector, one per service, even 
one per sequence of messages. Hopefully the specification would let you 
choose the end-point that is right for your implementation, and of 
course, more experience and best practice would help here.

You may even use one endpoint address for both, since nothing precludes 
two services from having the same endpoint as long as you can identify 
what to do with the message. They could be distinguished by the 
interface/operation, or by some other data (e.g. properties in 
WS-Addressing).

> 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?
>
Yes, the "sender" would be specified in the original message.

The sender would pass the outgoing message through an RM protocol 
handler that would add the proper addressing information so a 
response/ack can be sent back. The RM protocol handler can do that 
generically for a bunch of services hosted on the same machine/cluster, 
or individually for each service, etc. At the receiver end, that header 
would be interpreted by the RM protocol handler, which can send the ack 
immediately and forward the body of the message to the application later on.

All you need are applicable headers to allow the RM protocol handler to 
do it's magic when it intercepts inbound/outbound messages.

arkin

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


-- 
"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 18:03:29 UTC