OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

business-transaction message

[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