Comments on your mark-up comments that haven't already been dealt with in
other mails. The issue of the Manager and coordinator-specific addressing is
very important for us to sort out. It's useful to consider your alternative
approach to the one contained in the current draft that Peter put together
after Boston.
Agreed, and as I'll try to indicate below, although
I believe the factory approach is more suited to web services, I don't believe
at this stage it's cut-and-dry either way. Therefore, what I'd like to see is a
protocol that can allow for both.
To save space I'll delete those things I don't have
a problem with or don't think there's anything more to add.
I might as well state a preference for "cancel" over "undo" here. CANCEL is
the message put into the draft protocol set after discussion with Mark, among
others, but of course any label will ultimately do, so we should just vote it
up and down.
Actually I prefer cancel too.
Agreed, and once again I don’t think we are arguing against this. The
point of difference is really whether or not a composer can call participants
directly.
Or an initiator. I think that the composer can stimulate the flow of
prepare messages, and that this is natural, not objectionable. In fact, to
generalize things a bit, much of this discussion is about whether an
application element (initiator or service), or a composer, should be able to
"prepare" a participant without going through the coordinator (tell the
participant that work has finished, and it's a good time to vote). Without
mandating sub-coordination it's extremely difficult to accomplish. What we
have to enforce is that the coordinator ensures that votes are gathered from
all enrolled participants. "Early", "out of band" preparation is not
dangerous, it just causes work to stop on some participants.
I'll leave this, as I think previous emails have
pretty much done-this-to-death, and we seem to be in agreement that an
application specific impetus ca stimulate an early prepare message being sent by
the BTP participant.
I think your confusion has arise from a misinterpretation of
“interface”.
No, it flowed from the fact that you had a begin with no
actor to send it to.
No, there was an actor: it was a coordinator
manager/factory service. I think it should be possible for us to have a protocol
where there is a logical coordinator actor, that may be implemented by a
separate service per coordinator, or a single service for lots of coordinators.
As I've indicated before, I think the former is more in line with current web
service thinking (coarse-grained components), and the latter is definitely a
CORBA/J2EE object model.
The interface was described as the "coordinator interface", which implies
messages sent to and from the coordinator. But you cannot send BEGIN to a
non-existent coordinator. And in all other discussions (and in the draft
terminology) I believe we have used Coordinator to mean the entity that
manages coordination for a single atomic BT, not a Coordinator Manager or
factory or the like.
See above.
This is an implied implementation in the email I sent: there is nothing
to prevent the atom id from having the same address as the service that
generated it.
Well, I'm not sure that's the best approach. If that is true then we have
to introduce the atom id into every message sent to a "Coordinator", so that
the receiver can work out which atom it's doing work for. If we have a unique
address per coordinator then we only need the atom id in the context.
However, as I said, we don't believe this is the
most valid model for web services. But in order to move things along we'd be
happy with a protocol that encapsulates both. When you consider the amount of
payload that will be accompanying any BTP message, adding the atom id to
PREPARE, CONFIRM, CANCEL (UNDO) isn't going to have much of an impact. If the
receiving service only knows about a single coordinator then it can either
ignore the extra information or (and probably more sensibly) check that it
refers to itself just in case!
We do need to define the Manager actor explicitly or the interoperable
protocol is not clear. I don't see this as an implementation choice: it's part
of the protocol. (An alternative would be to remove BEGIN/BEGUN from the
protocol altogether, and allow atom bootstrap to be non-interoperable, but I
think that is undesirable.)
I believe an interoperable protocol that supports
both is possible, and desirable.
I agree that the coordinator and the entity that created it need not be
the same service, and this was one of the other implementation choices I
alluded to in the email. As long as the message set does not preclude this or
collocation then we are not in disagreement. The main reason I selected the
co-located choice for the email is that it keeps the number of actors in this
to a minimum.
I disagree. You either have a BTP Manager (call it what you will) that
manufactures atom coordinators and gives out their addresses in response to
BEGIN, or you have to have an API or non-standard message/non-standard actor
to create the coordinator. The mandatory entity is the Manager, not the
Coordinator. Personally I prefer to have both in our scheme.
I don't care if we call the coordinator factory a
BTP Manager, as long as it has the same functionality. Where the coordinator
resides (either as a separate service that is visible to the user if he looks at
the URL, or hidden in some back-end [to the BTP Manager] service, can be
transparent).
I agree with you that BEGIN is useful/necessary, and its existence does not
preclude collocation, any more than any of the protocol messages precludes
collocation of any of the actors. Whether you want to truly send BEGIN in XML
from function A to function B in a collocated implementation depends on how
severe your definition of interoperable is, I guess.
What we want to see is the possibility for
third-party coordinators/coordinator factories to be plugged into the protocol.
That requires interoperability and hence agreement on the
message-set.
Yes, but the intention of my email was to try to move us from this
abstract notion of, for example, a VOTE to a more concrete implementation. If
you re-read the email and take the notion of interface as it was intended
(i.e., as a message set for a web service) then I do not think there is any
difference.
There is little difference in the abstractness or concreteness of the
proposed message set that we discussed before Peter put it out several weeks
ago, and the one you propose. Each gives a (frequently different) name to the
message, and each describes obligations/behaviours and gives some idea of
returned responses. However the current draft set is more precise and complete
in several areas. For example it actually states what the possible votes are,
it mentions auto-commit/rollback, timeout qualification etc. So I think your
message set should be compared with the original proposal, and absorbed only
where it adds something new (like BEGIN). Otherwise we go round and round
redrafting old work. Furthermore it turns out very, very little new is needed
to handle all the stuff we're discussing, as I described in the original
document you are commenting on.
Unfortunately I don't have the current draft to
hand. But from memory I believe that the error conditions and exceptions were
lacking.
More generally, we are only going to get concreteness when we define the
XML schema for these messages, and the encodings for particular carriers. The
current work is defining a more or less detailed abstract message set.
However, I believe that it is about time we moved
onto the concrete implementation of this protocol in, say, XML and
SOAP.
Certainly given a coordinator (atom) reference I should be able to get
the context. However, if I created the atom in the first place I’d like the
context to come back as part of that begin.
I think that improves things. Is BEGUN a synonym for CONTEXT? I suspect it
should be, because it supersets the coordinator's address. In which case we'd
see BEGIN/CONTEXT and GET_CONTEXT/CONTEXT. One less message.
I don't see why not.
In the case of a loosely coupled system which exists in a widely
dispersed network where independent failures of nodes and networks happen more
regularly than, say, on a LAN, having a subordinate coordinator know that its
time is up without having to wait for an explicit signal from the root is very
important.
Hmm. A sub-coordinator going heuristic because of a presumed timeout,
caused by time skew, is not a happy outcome.
I did not mention anything about heuristic.
Remember, you cannot generate a heuristic unless you have received a previoud
PREPARE message. Up until that point the only thing a participant can do is to
undo itself (c.f. transaction systems). If this is not your reading of the
current protocol then I suspect we have a further email debate to conduct.
However, assuming we take my reading of things, the timeout period is *only*
applicable up to PREPARE. Therefore, if a subcoordinator has not received
PREPARE and did get the original timeout, it can undo itself independently safe
in the knowledge that one it does, it will cause all other participants to undo
as well (eventually). I believe we discussed this fact briefly at the Mt Laurel
face-to-face, and there was general agreement that this was the
case.
In fact, this raises the question as to whether participant timeouts should
be allowed for sub-coordinator participants, as they may drag down a whole
tree, whereas leaf participants can only kill themselves. I guess you just
cannot prevent that. And as you say, in a discontinous environment, give or
take an accuracy factor, it's exactly what you want to see happen. In which
case coordinator timeout becomes a kind of C-P "I want you stay up for this
long" negotiation message, as you suggested at Mt Laurel? The relative
time/absolute time problem gets worse here, although the use of relative time
will just expand the time to expiry at the bottom of the tree (as Ed pointed
out) so I guess it's safe.
Agreed.
A web service, whose WSDL supports the following series of
web-methods.
I find that a rather confusing and unnecessary level of concreteness. I
don't think we have (or should have) decided to use WSDL. And if we are going
to debate that, can we get the issue out as a clear proposal or issue in its
own right. I thought that this had been rejected at Boston, but maybe I missed
something.
WSDL or an XML schema? There's very little
difference. If we are talking web services we are in the world of
WSDL.
We have hitherto spoken about actors (or actors-in-roles), or to be more
precise, the endpoints of protocol messages, which are addressable. The
interface you propose is logically a combination of two protocols: the I-M
relationship and the I-C relationship. (The M and the C must have different
addresses, or the contents of their messages must contain enough information
to allow the recipient to sort it out. If I send INFERIOR_STATUS to a
Coordinator then we have previously assumed that the Coordinator will know
"who it is", i.e. will not need to be told its atom id. Ditto with VOTE, etc.)
As I indicated above, I believe that M and C do not
have to have different addresses. This is a implementation choice, and should be
supported in the model.
This coordinator manager (or BTP manager if you want) will create atom
coordinators which may well be serviced from some other web service. However,
this should be transparent to the user: the atom id should be composed of some
URL and a unique id (unique in the context of the URL).
I think it would be cleaner to say: the atom id is a globally unique id
(and there are several ways of creating those). The Protocol Address (exactly
as defined in the Terminology section of the provisional draft) is a Carrier
Protocol Address (probably a URL for most bindings) and an opaque Address
Suffix. Now, an obvious scheme here is to make the address of say, a
coordinator, the URL and the GUID. This allows a carrier listener to handle
inbound messages for multiple coordinators. It allows the first part of the
address (URL alone) to be the address of the BTP Manager ... and it allows you
to do almost anything else you like with addressing.
Agreed.
I think it is unnecessary (wrong) to bind the atom id to the address
in the protocol spec.
I don't care how it's implemented as long as it's
unique. However, context relative uniqueness is a lot easier to achieve and
manage in a global environment - just take a look at the DNS and ip addressing
for a really good example.
All coordinator-specific methods should be directed to the URL, and if
this happens to be the same destination as the original creator than fair
enough. If it isn’t then that’s ok too. However, it is extremely unlikely that
each atom will be a separate web service: that simply isn’t the way in which
web
services work – they are coarse-grained and not fine-grained
entities.
See above. There is no problem with a two-part address in supporting either
"manager/table-keyed-by-id" implementations, or "direct-to-the-object"
implementations. No need for us to dictate.
Good. I think we're reaching
agreement.
Let’s not get into the mindset of putting individual objects on the web.
This isn’t CORBA or J2EE: these aren’t objects, they’re components. It is more
likely that individual participants may well be individual web services, and I
think this is an important distinction: although a coordinator may share some
of the attributes of a participant, it isn’t the same thing. I can write a
coordinator that can be used to coordinate any participant; I can’t write a
participant that can be used to drive any BTP web service. That’s a bit like
saying I can write a single OTS Resource that can be used for any
transactional resource!
I agree. In fact in my experience of real CORBA apps you often end up with
some kind of coarse, master object which manages a pool of fine objects which
are not advertised to the clients. Even inside the firewall you don't want to
clog a name service with a thousand objects per app.
Agreed. Currently many web service implementations
are going through exactly the same design issues that CORBA went through
initially: when CORBA came along, people had been writing C/C++ programs for
years and thought that the best thing to do when distributing them was to
distribute individual objects. However, it soon became apparent that (amongst
other problems) a) this didn't scale in terms of performance and manageability,
b) it was an implementation choice that made reconfiguration more difficult, and
c) it tended to expose implementation objects that users shouldn't see. It only
took a couple of years for people to move to coarser granularity
implementations/services.
However, it is quite common to export one factory or indirector, and then
have it give out references to the objects that we are manipulating as
a client (our own little pool, as it were). In our context we are not
compelled to advertise anything more than the Manager, as it is the bootstrap,
and this is another good reason for having one. We may then get an address for
an individual coordinator from the Manager, and communicate thereafter with
that specific address.
And as with some CORBA services, I'd like to be
able to keep my back-end implementation of a coordinator pool invisible from
users. If at a later date I decide to federate this pool and have different
services in, say, different parts of the world, or even a single service per
coordinator, then I'd like that to not require a rewrite of applications that
use the service.
I think that getting the status of an atom and a participant are identical.
>From the perspective of an initiator or composer the atom is nothing but a
participant.
Agreed. However, just because two services share
the same name for a set of "operations" shouldn't mean that the operations are
identical, and that the message payloads are the same.
Mark.
-----------------------------------------------------------------------
SENDER
: Dr. Mark Little, Architect (Transactions), HP Arjuna Labs
PHONE : +44
191 222 8066, FAX : +44 191 222 8232
EMAIL : mark@arjuna.com
|