OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

business-transaction message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: Re: Open-top coordinators and protocol


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

Correct, which was the implicit assumption behind the original email. A
message-set is no good if it's not implemented by someone!!

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

And this is immediately where I have an issue with this idea. Why should the
business logic that talks to the actual Web Service (e.g., the taxi booking
service) know anything about prepare/confirm/undo? It may be closely tied
with the cohesion logic, but it shouldn't be forced to. I have no problem
with "early prepare" if it is handled correctly, and in model. What I want
to see is a clean model, with clearly defined roles for actors in it - it
makes it easier to understand and reason about who does what and when. What
I don't want to see is a hack or bending of the rules to try to shoe-horn
something in that a) isn't a proven requirement for the majority of
applications, and b) can be achieved at the application level (with some
help from the back-end).

If we follow b) let's see just how we can accomplish what is desired by
Choreology. The application wants to do a one-shot operation (i.e., it knows
it will never call this web service again). First of all this is an
*application* level decision, based upon a number of different conditions.
So, rather than have the application send a PREPARE message to the Web
Service (or piggyback it, or whatever to accomplish the same effect) it
should IMO send some marked-up XML in its invocation, e.g., an attribute to
the operation being invoked that says ONE_SHOT, or somesuch like. When the
Web Service gets this operation, it is up to it to a) determine whether it
understands ONE_SHOT, and b) determine whether it wants to actually use it.
If it takes b) then it could talk to the participant registered on its
behalf (either registered from a previous operation, or registered from this
invocation) and tell it that it can prepare. From the Mt Laurel face-to-face
this is entirely in the jurisdiction of the Web Service-to-participant
protocol, which we aren't defining.

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

If this is done at the "application" level as described above then it's up
to the participant to do the right thing. Since it enlisted with the
coordinator, it should be able to talk to it directly.

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

This is a different issue. Whether or not the atom allows early prepare is
certainly something to consider, but the real issue here is how (and if)
this functionality is provided.

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

Mark.

----------------------------------------------
Dr. Mark Little (mark@arjuna.com)
Transactions Architect, HP Arjuna Labs
Phone +44 191 2064538
Fax   +44 191 2064203






[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC