[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: Open-top coordinators and protocol
Savas, > 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 have to repeat something from one of my previous messages. I am not > suggesting that the spec should be described in terms of WSDL. The spec > should be defined, as you have proposed, in terms of message sets. I am > merely saying that the mapping of BTP to the Web Services arena also > needs to be specified. 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 think it would be restrictive and wrong to suggest that this protocol can only be used through WSDL-advertised interfaces. > > WSDL is actually an XML document in which you can specify XSD schemas. > Although I don't like the analogy, you can think it like the IDL of Web > Services. Let's not forget that Web Services are the "new" components > and as such they need to have an interface. WSDL allows us to specify > that interface. If I want to use a Web Service in my application, I have > to know its WSDL. Yes, like I said, it's an IDL. It is not necessary to use WSDL to define this protocol. It is not necessary to use WSDL to define a SOAP carrier mapping. It might be useful to do this, but I am loath to create more dependencies than is necessary, especially when the referred "standards" are not yet finalized. [...] > In this case and > if the Initiator and the Coordinator are not co-located, the messages > are the same (if not more:-) So, why further populate the protocol? Please see the analysis of WAN versus LAN messages that I sent in a reply to Mark on this topic. Performance is not the only reason, as I have also pointed out. The one-wire set up, for example. Collocation is not a prerequisite for this. > > > > [all CAPS like this means "BT protocol message"; <inanglequotes> means > > "API > > call". "I" means "initiator", "C" is "coordinator", "P" is > "participant", > > "S" means "service", "INT" means "interceptor", *REQ" means app > request, > > *RESP" means app response] > > > > In the "standard" case, you see this happen: > > > > I -- GET_CONTEXT -- C > > C -- CONTEXT -- I > > I -- CONTEXT -- INT > > I -- <sendrequest> -- INT > > INT -- *REQ* + CONTEXT -- S [net message 1] > > S -- ENROLL -- C [net message 2] > > 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. > I think you forgot the > following. Also, the Coordinator needs to reply to the Participant with > the result of the enroll request. > > S -- UNDEFINED -- P > P -- ENROLL -- C [ net message 2 ] Implementation choice, see above > > C -- ENROLLED -- P [ net message 6 ] (for counting purposes and not > ordering) Yes, I agree, the ENROLLED is needed in this case. > > > S -- *RESP* -- I [net message 3] > > I -- <prepare> -- C > > C -- PREPARE -- P [net message 4] > > P -- VOTE -- C [net message 5] > > C -- <outcome> -- I > > > > In the optimized case, you see this happen: > > > > I -- GET_CONTEXT -- C > > C -- CONTEXT -- I > > I -- CONTEXT -- INT > > I -- <sendrequestwithprepare> -- INT > > INT -- *REQ* + CONTEXT + PREPARE -- S [net message 1] > > S -- ENROLL + VOTE + *RESP* -- INT [net message 2] > > Ooops. Again. The Service does not enrol. It's the participant. See above. > 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). > if we forget that co-location is assumed and _if_ I was to agree with > you (which I don't), the last one would probably look like this: > > S -- UNDEFINED -- P > P -- ENROLL + VOTE -- INT [ net message 2] > INT -- ENROLL + VOTE -- C > C -- ENROLLED -- INT > INT -- ENROLLED -- P [ net message 3 ] > S -- *RESP* -- INT [ net message 4 ] > > Unless, of course, you assume there is another interceptor at the > service/participant side (again assuming co-location). (Please, remember > that I am just following your argument rather than agreeing with it :-) > > S -- UNDEFINED -- INT' > INT' -- UNDEFINED -- P > P -- ENROLL + VOTE -- INT' > INT' -- *RESP* -- INT [ net message 2 ] > > The flaw with this is that a service is allowed to respond without > knowing the result of the participant's registration with the atom > (security consideration?). I don't think we can count this as an > optimisation. See the discussion above. It's not a security issue, it's a protocol integrity problem. > If more participants had to be registered with the coordinator because > of the application request, the interceptor (INT') at the service side > would have to persist the enrolls and the votes until the response is > constructed and sent. Failure-recovery would have to be a requirement. Not really. If the service enrolls its participants (:-)) then the service gathers all enrollments and early votes into a bag and feeds them to the interceptor along with the request. In this case INT(S) may not even exist. Then the response is dispatched. It is true that all VOTES must be logged before sending (this is normal), and it is also true that a presumed abort protocol will not work without failure recovery (if we define that to mean retaining and collecting persistent information about transaction involvement after VOTEing). > > > Finally and I think very importantly, your optimisation is based on the > assumption that the service can proceed its execution without knowing > the result of the participant's registration with the coordinator. Are > we allowed to make such an assumption? > > The solution I proposed earlier, solves all the above. If an indication > is sent to the service, at the application rather than the BTP message > exchange level, then the service could instruct the participants to vote > when propagating the context (or by some other means that is > implemented-specific). Unlike your optimisation, this will work even > when the actors are not co-located and it has the significant advantage > that it has nothing to do with BTP (thus heeping us happy:-) > > I -- GET_CONTEXT -- C ( net msg ) > C -- CONTEXT -- I ( net msg ) > I -- <SendRequestTheOneAndOnly> + CONTEXT -- S [net message 1] > S -- UNDEFINED + UNDEFINED_YOU_CAN_PREPARE -- P > P -- ENROLL + VOTE -- C [ net message 2] > C -- ENROLLED -- P [ net message 3] > S -- *RESP* -- I [ net message 4 ] > > Now, this is again achieves the same optimisation in number of messages > as the (what I believe is the correct version above), it has the > advantage that it will also reduce the number of messages when the > actors are not co-located, and it doesn't even involve BTP at all (thur > putting a smile in my face :-) See another message on the application marker proposal. > > > > > > 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. > > > > I assume for this discussion that I, C and INT are colocated, and S > and P > > are colocated. That way we see the real likely impact. > > > > Oops. OK then. You are making the assumption! No, I making the assumption that cost(WAN) > cost(LAN), and which is what I meant by the "real likely impact". Colocated was the wrong term. co-LANed would be more like it. 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC