Re: Open-top coordinators and protocol

[Alastair Green <alastair.green@choreology.com>]

Hi Savas,

On WSDL: I agree with Pal that we should deal with this as a new proposal. I am not hostile to the use of WSDL. It's not _necessary_, nor should it be _mandatory_. As one route to carrier protocol mapping, I have no problem. Perhaps the messaging sub-group could take up this aspect of the discussion.

>  
> If the Service is allowed to use the messages that are assigned to
> the
> Participant actor, then why have the distinction in the first place?
> People at the Boston f2f will remember that I was arguing against having
> this kind of separation. I actually wanted the Service actor to "look
> like" a participant of a cohesion. However, the decision was to treat
> them separately. Because of that, distinct routes of (logical) message
> exchanges were identified. Of course, I accepted that decision and
> I am
> trying to support it.
>  
I think the relationship between I, S, C and P is slightly more subtle
than either your assumptions or my diagrams. If I am right then we should
improve our definition of what is going on. Thank you for raising the point.

The original reason (in my mind) for I and S was to allow app requests
and responses to flow back and forth, and for C and P was to allow 2PC
to occur. If you don't separate S and P then you can't create 1:M S:P relationships,
which would be unreasonably restrictive.

ENROLL/ENROLLED doesn't need to be a P-C relationship, as the example of the OTS Resource interface shows. In OTS any program can register a resource and receive the recovery_coordinator reference in return.

This flexibility is reasonable (and proven in another protocol). So I suggest we adopt that approach, and say that anyone can send ENROLL and receive ENROLLED. My earlier example of the service keeping track of n participants that it wants to enroll and vote for is relevant here.

There is a related issue. Why restrict the request for a SUPERIOR_STATUS to enrolled Participants? An admin monitor may want to track the status of any coordinator, quite independently.

> To my mind, you're suggesting that it is possible
> for the Service to use
> messages from the Participant's set, which is against Choreology's
> diagram of actor interactions. This was the original reason for this
> disagreement if you remember. At the Mt. Laurel f2f, I was given the
> impression that you were trying to utilise the Coordinator's message
> set
> from the Initiator. I objected then and continue to do so now :-)
See another thread.
> > No, that's not true. There is no need to delay
> or send
> > network messages up and down before the return of the
> > application response. The reason for ENROL/ENROLLED in the
> > standard (de-optimized case) is to ensure that the
> > application response will be a fault in the event that a
> > participant enrolment failed. This will prevent orphaned participants.
> >
> > In the optimized case you get a different mechanism, which
> > achieves the same checking effect. The INT(I) receives the
> > boxcarred messages. It must send ENROLL + VOTE to the C and
> > get an ack (which should be ENROLLED) before sending the
> > *RESP* to the I. This ensures, once again, that there is no
> > dangling participant. This would not be a network message in
> > a collocated environment, and would be (likely a LAN message)
> > in a distributed environment. If the enrollment on the
> > "initiator side" fails, there are two ways that the dangle is
> > overcome: either the participant times out (with the usual
> > consequences) or some failure recovery mechanism will inform
> > the participant that it should cancel (which is a normal part
> > of the protocol).
> >
I presume you agree with the above? And therefore agree that the total
# of WAN messages (left-side/right side messages, initiator-side/service-side
messages) can be two, not six? And that the whole protocol can be carried
between two endpoints, and does not require four endpoints?
>  
> However, you have still done all the work at the Service side. In order
> to avoid the exchange of a pair of messages, you may have allowed an
> one
> hour long method to execute at the Service.
I'm sorry, but I just don't follow this/don't understand it. If (and only
if) the application circumstances permit, is it possible to use a one-shot.
How long it works for is irrelevant. If it will block a client for an hour,
presumably it is not a great candidate for one-shotness, as you suggest.
The matter is to allow it, not to mandate it, or to prove that it is always
useful.

We have a use-case (the real-time trade execution) which requires one-shot atoms (lots of them: the idea that we send six messages back and forth to get each confirmed quote is not a good one). The expected duration of "getQuote" in this context is sub-second.

Yours,

Alastair

begin:vcard 
n:Green;Alastair
tel;cell:+44 795 841 2107
tel;fax:+44 207 670 1785
tel;work:+44 207 670 1780
x-mozilla-html:FALSE
url:www.choreology.com
org:Choreology Ltd
version:2.1
email;internet:alastair.green@choreology.com
title:Managing Director
adr;quoted-printable:;;13 Austin Friars=0D=0A;London;;EC2N 2JX;
fn:Alastair Green
end:vcard