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

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

Received on Friday, 18 July 2003 16:58:28 UTC