RE: Open-top coordinators and protocol

[Savas Parastatidis <savas@arjuna.com>]

(Hoping this message will reach the list :-)

Dear all,

A comment on Alastair's document...

I agree with the description of the Initiator-Coordinator interaction as
a message-set rather than a specific API. However, since there has
already been a decision on using the Web Services world as a
proof-of-concept arena, it would be wise to agree on an API as well, for
those interactions between actors that we agreed to define (WSDL would
do just fine). If we do not do that, I cannot see our interoperability
demonstrator ever working :-)

Now, some comments on implicit prepare...

While looking again at the latest draft of the spec, I realised that the
example code included in the document may greatly assist our discussion
(a trimmed down version is included bellow for illustration purposes).
In the example, the prepare call is made on the atom. A message is sent
to the Coordinator rather than the service. The Coordinator knows the
participants registered with the atom and it is its responsibility to
collect the votes.

If my understanding of Alastair's proposal is correct, the
sendApplicationMessage() and prepare() calls should be replaced with a
sendApplicationMessageAndAllowPrepare() single call. This will result to
a (number of) participant(s) being registered with the coordinator of
the atom and at the same time, those who wish, they send their vote. But
where do they send the vote? In its original form, the example bellow
suggests that the Coordinator will return the result of the prepare (via
the atom interface). If we are to replace the two calls with just one
(as described above), who is going to receive the vote? If the result
goes to the Initiator, then we do not honour the spec that specifies the
interactions between actors (the participant sends the vote to the
initiator). If the vote goes to the Coordinator, then the Initiator does
not know the result of the vote. It needs to talk to the Coordinator to
find out. It has to call prepare on the atom. Granted, the prepare may
return faster in case the participants returned a vote at the time of
their registration. 

void cohesionComposer() // an application method
{
   Atom orderGoods = new Atom();

  // application work

  Quote quoteForGoods = 
    orderGoods.sendApplicationMessage ("quoteForGoods", arg, arg .)
  
  // ensure that the quotes are guaranteed (may be folded into app
messages)
  orderGoods.prepare();                // no exception, so it is ready
  orderGoods.confirm();
}


Having said all the above, I can see the rational behind this approach
:-)
I would be happier, though, if the optimisation utilised the fact that
the atom (or atom context or atom ID) need to be propagated to the
participants. Since the prepare is part of the atom's interface, we
could configure the atom so that it contains the information required
for participants to see that an implicit prepare is allowed. So the code
would like this:

void cohesionComposer() // an application method
{
   Atom orderGoods = new Atom(AllowImplicitPrepare);

  // application work

  Quote quoteForGoods = 
    orderGoods.sendApplicationMessage ("quoteForGoods", arg, arg .)
  
  // Check the status
  orderGoods.prepare();
  orderGoods.confirm();
}

Again, the same problem arises. The initiator does not know about the
vote so it needs to call prepare which could be faster. I think I am
happier with this though :-) This approach clearly shows that the
implicit prepare is part of the atom's context and has nothing to do
with application messages.

Lastly, if an implicit prepare was to be sent together with an
application message, how would the service know which participants must
receive it? Some of the participants may have already been registered
because of earlier application messages on the same service.

That's all for now :-)

.savas.