[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: FW: Open-top coordinators and protocol
Hi all, first of all I 'd like to apologize, since I got a little dosconnected lately, but I also have my day job (:))... I'd like to address some of the points in this thread: - I don't think we explicitly decided in Boston to define a WDSL mapping. We did decide to focus on Web Services and on a binding to SOAP and ebXML TRP. Although WSDL has not been discussed explicitely, now that I think about it, it seems like a good idea to define the interface required from the non-application actors (coordinator, participant) in WSDL. We can vote on this at the next concall. - Can somebody write up a small summary of the list of agreed actors? Also I think it would be useful to use a tool like RR to draw sequence diagrams, instead of using text to draw them. Pal > -----Original Message----- > From: Alastair Green [mailto:alastair.green@choreology.com] > Sent: Tuesday, May 29, 2001 7:42 AM > To: Savas Parastatidis > Cc: business-transaction@lists.oasis-open.org > 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