RE: Open-top coordinators and protocol

[Peter Furniss <peter.furniss@choreology.com>]

Savas sent:

( deleting bits I'm not commenting on ... yet)

>
> 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 :-)

I don't follow this. In normal usage, an API is within-system (a Programming
interface) and interoperation between separate boxes requires a defined
message set. This is obscured in some ways where there is a general
underlying communication mechanism (as with CORBA) that maps between APIs at
each end - but you could get interworking by treating the IDL->IIOP as
defining the message set.  Or are the words all moved round in the web
services world ?

> 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

Not quite - you still need the prepare() (or equivalent) on the atom
coordinator, to induce the coordinator to report on the combined vote for
the whole atom.

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

I think we are agreed.

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

See my message sent yesterday evening  - the service doesn't know which
participants are involved, but it does know the sequence and completeness of
the application messages. The piggy-backed "prepare" (or implicit prepare)
refer to the completeness of the messages, and thus, by implication, the
appropriatness of a vote from anything receiving those messages.

There is then a separate question as to whether the indication that the
messages are complete should be in a BTP-defined construct or left to the
application. This is hard to give a firm answer on, but I inclinde to a
BTP-defined construct. This makes it easy to BTP-ise an application exchange
that does not itself have the concept of packaging its requests into groups,
without requiring additions to the application messages in an ad-hoc manner.
(arguably an application X + BTP isn't quite the same protocol as X alone
and doing so does add messages (the btp allow-vote) to the application
messages, but the advantage is that you can do exactly the same thing for
Y+BTP, Z+BTP etc).   A midway position is to have a BTP-defined
"allow-prepare" but also permit voting at any point (used with different
applications) - this is truly implicit prepare, but if a service+participant
believes it can vote, who are we to say it doesn't understand the
application protocol.

There's also a question of whether the initiator needs to know the
particular vote from a participant, as opposed to the atom. I'm inclined to
agree with you that it doesn't. The initiator is (usually) getting an
application response. Since the initiator has determined the packaging into
atoms, if it needs to know distinctly "will this operation really work", it
should ask the atom that includes it. It won't help it to know that the
first involved participant is ok, if there is another (directly registered)
participant it can't see lower down that will cause the operation to cancel.

Peter