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


Hi Mark,

The only thing in your reply of a day or so ago that I have any fundamental difference with (as opposed to shadings and variations) comes right at the end:
 

"If you send two messages with the same context to the same service then why would you expect to get two enlistments? There's been an implicit assumption on my part that a service will only register a single participant for each transaction. Are you saying this is not the case?"


This is interesting, and perhaps relates to a note in Pal's write-up of the conclusions from the Boston F2F.

I certainly do not believe that you should impose a one service-one participant restriction as a _general_ rule. A service (however delimited) is always free to offer a single point of coordination for a given business transaction, if it wants to. Other configurations may be desired or negotiated. The protocol should allow them to be implemented, unless forced to forbid them by some overriding functional need (which I see no sign of in this case).

In any event it's quite hard to define what such a restriction actually means.

At present, as drafted, there is no such thing _at a protocol level_ as a "service". A service is an endpoint in an application message transmission.

We need to have a concept of "service" because we want to talk about how context augmentation or infection occurs. So it useful to be able to say "the initiator obtains the context from the coordinator and adds it as a header to an application message which is transmitted to a service. A service extracts the context from the header and is then able to use the coordinator address within that context as an input to the creation of an ENROLL message."

Participants and coordinators have identitfiers that appear in protocol messages. Initiators and services have no defined identities in the current draft protocol. If this is so then it follows that there is no way of knowing (let alone preventing) multiple participant enrollments by one "service" (or to say something which is equivalent: there is no way of knowing which service any operation belongs to, and no way of knowing which service is responsible for an enrollment).

Unless ... we start to allocate identities to services, so that we can identify protocol messages (enrollment, 2PC) by the application actors that stand behind the protocol actors. This then allows the service designer to tightly demarcate a service (which operations make up a service), and allows the coordinator to reject multiple registrations.

Alternatively, a service could agree to obey a flag which requests/insists upon "SingleParticipant", by undertaking not to register more than one participant with a given coordinator, for its own (private) understanding of what a service amounts to. It cannot tell from "MustInterpose" alone that this is the desired behaviour (which was my original point). And the utility of this flag depends on the utility of a private understanding, not shared with the initiator except perhaps at the application level, by prior discovery/negotiation. (Which is pretty questionable, in my view).

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