RE: Open-top coordinators and protocol

[Savas Parastatidis <Savas.Parastatidis@arjuna.com>]

Alastair,

> > I am not suggesting that we should define the spec in this 
> form. This 
> > is the mapping of the spec to the Web Services arena. A decision we 
> > took in the Boston f2f. There has to be a WSDL interface for every 
> > actor in BTP that participates in a defined-by the 
> model-interaction.
> 
> This is the first that I have heard of such a decision. I 
> have consulted the document issued by Pal as an update to the 
> document issued by me before the meeting. I see no reference 
> to WSDL. I have consulted the minutes issued by PAL. There is 
> no mention of WSDL. I have also consulted Peter (who attended 
> in person) and he does not remember any such decision.
> 

I hope others from the Boston f2f will remember this. There was never a
decision to use WSDL. I agree with that but, then again, I never
suggested that there was such a decision. There was a decision to map
the protocol down to Web Services as a proof-of-concept. That's why I
was asked to update the Use Cases document to talk about Web Services.

Having made the decision to target the Web Services world, I thought
that we had to agree on an interface to the actors (again a Boston f2f
decision) was required. That's why I suggested WSDL. It doesn't make a
difference whether XML schemas or plain text are used in the BTP specs
document to describe the protocol. I am suggesting (again) that there
has to be an agreement that is reflected by the specs document on the
interface of those actors that participate in a BTP-defined interaction
for the mapping of BTP to Web Services (Initiator-Coordinator,
Coordinator-Participant, Initiator-Service). Perhaps, it could be an
appendix.

When talking about the Web Services world, I think that WSDL is the
simplest way to go. I agree that it is possible to transfer XML
documents using SOAP without having a WSDL agreement on what interfaces
exist. If I want to switch my application from a BEA Coordinator Web
Service to an HP Coordinator Web Service, I will have to change my
implementation if there isn't an agreement on the interface used.

> Why don't we concentrate on what does have to happen, which 
> is defining the message sets using XML schemas? Let's leave 
> the WSDL issue as a second-order problem. WSDL levers on 
> schemas, so that road should be open, as I see it, if and 
> when required.
> 

I agree that WSDL is a secondary issue. We need to define the message
set for BTP before anything else.

> I think it would be restrictive and wrong to suggest that 
> this protocol can only be used through WSDL-advertised interfaces.
> 

I never suggested that. If that's what came across, I apologise.

> [...]
> 

[...] as well :-)

> >
> > The service does not enrol. The participants do.
> 
> Really? Why? You suppose (impose) a special case. This is 
> analogous to the argument that "applications shouldn't send 
> prepare". As I have pointed out, coordinators only send 
> prepare as servants to (delegates of) applications. Likewise, 
> the service is the active, controlling entity in this case. 
> There are several ways that I can think of, off hand, to 
> write a participant. (I'll assume I'm using an OO language: 
> it doesn't matter): its instantiation causes it to enroll 
> itself; a post-construction method causes it to enroll 
> itself, one can obtain via an accessor the information 
> (address/participant ID in this case) needed to enroll; one 
> instantiates via a factory, which returns the enrollment 
> information ...
> 
> Regardless of implementation details, the stimulus that 
> causes enrollment, the decision to enroll, the timing of 
> enrollment: all of these come from the application, in this 
> case the service. Like coordinators, participants don't self-start.
> 
> If you find that unpalatable, then I would say "it is 
> undefined who enrolls the Participant". It is not necessary 
> to stipulate who does it or why they do it. In practice the 
> service will "make it happen" when prodded by some other 
> application element, probably the initiator via an app request.
> 

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.

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

If you can provide an implementation of the protocol that can achieve
the optimisations you're suggesting at the application level, then
that's fine, provided the interactions between the actors are honoured.
If that means that an Interceptor (an actor that has to be
implementation-specific) is required in order to give applications the
'illusion' that they talk to the appropriate actor, then that's fine as
well.

[...]

> 
> > The
> > service call cannot continue until the participant is registered.
> 
> 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).
> 

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.

> > >
> > > 2 net messages between I and S, instead of 5 in the standard case.
> > >
> >
> > That should be 4 messages instead of 6 :-)
> 
> Actually, it should be 2 instead of 6, which would be really nice.
> 

:-) 


Best regards,
.savas.