FW: Open-top coordinators and protocol

[Pal Takacsi-Nagy <pal.takacsi@bea.com>]

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