Re: choreography protocol

Jean-Jacques Dubray wrote:

>>>WSDL 1.2 has in-out and request-response. The distinction is that for
>>>request-response the response would be sent on the same channel as the
>>>request. There is no such constraint for in-out. So if you are using
>>>      
>>>
>the
>  
>
>>>in-out operation with some layer that supports reliable messaging or
>>>coordination you would in fact have signals travelling back and forth.
>>>
>>>      
>>>
>[JJ] Ok, but I still think that something has to be part of ws-chor and
>it does not require us to boil the ocean. I tend to think in terms of
>requirements first, and level of effort second, that's usually a better
>approach to build a functional system. It is not because something takes
>to long that we should not do it and conversely not because that
>something does not take any time that we should do it. 
>
The requirement definitely has to be part of WS-chor. How we solve it is 
a different issue. Maybe there's a solution already there, or a 
combination of technologies, or we need to solve it ourselves.

I think we're missing the point by discussing specific choreography 
languages (anyone listening?). We need to write down the requirements in 
general for choreography and then track the solutions. Let's look at the 
MEP you talk about. This is a requirement for the choreography language. 
Our three options to address this requirement:

1. We can invent a solution.
2. We can use a solution already provided by WSDL.
3. We can do #2 and actually document the solution and how to use it.

If we try and so #1 we're going to boil the ocean and never get much 
work done. There's already a big stack addressing many of these needs. 
If we try to do #2 we would get our job easier, but we won't make it 
easy on the world. We would be taking the shortcut but we won't explain 
to people how to make effective use of choreographies. If all we do at 
the end of the day is #3, with even the most basic rudimentary 
choreography language that only adheres to the 20/80 rule, I think we've 
accomplished something useful.

The same thing goes for abstraction of services, message families, 
reliable messaging, failure detection, coordination, and so forth. Let's 
just define the general requirement for what we want to achieve (not how 
we think it should be done), find any existing solution we can leverage, 
and then document the hell out of it.

>
>[JJ] This is a very common think that can happen where for instance,
>before an AckPo can be sent, someone has to look at it. As you can
>
Obvious. I'm assuming a significant delay between the message-received 
ack and the po ack.

>imagine, none of this is going to happen synchronously. However, you
>want to make sure that the state of the choreography is aligned in both
>parties by exchanging a message that says that the order is being
>processed.
>
I thought you ment that the message says 'the order has been processed', 
which is equivalent to AckPo. If I understand correctly the message 
would say 'the order is being processes starting now'. In RM terminology 
this would be a delivery ack.(Acknowledge that RM is delivering message 
to application).

So essentially the sender knows when the message was received (first 
ack), when the message is delivered (second ack) and when the message 
has been processed (response). Would this be of interest to the 
choreography at the choreography level? Assume these signals get 
exchanged between the lower level services, would that be something you 
explicitly write in the choreography or just depend on it being 
exchanged out-of-band? Second question, is this used for the 
coordination protocols?

If you used RM with a coordination protocol then effectively this 
message exchange would transpire. Once delivered to the application the 
coordination layer would send a message to enlist itself a a participant 
in the transaction.

But this goes back to the point I made above. There is no requirement 
from the choreography to exchange a message for the purpose of 
coordination. There is a requirement for the choreography language to 
support coordination when doing asynchronous (and possibly synchronous) 
messaging. Incidentally, there are two coordination protocols both of 
which would actually exchange these kind of messages (and others). We 
shouldn't care what messages they need to exchange, only that they give 
us the semantics we need.

arkin

Received on Friday, 20 June 2003 17:51:50 UTC