Managers, addressses and the like

[Alastair Green <alastair.green@choreology.com>]

Mark,

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.

It seems like there is complete agreement on the need for "open-top" coordinators, so I will shut up about that.

Just to clarify: there is no need for a composer to prepare an atom that it wants to undo anyway. Equivalent to calling rollback on a transaction.

Yes. It can cancel an atom any time it wants.

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.

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 used the term interface in its much more general meaning – don’t confuse it with IDL, or an object interface. It is a contract between two parties (the composer and the atom-service).

Actually I was encouraged in my misapprehension by the change of names to identify identical messages (contrary to established work which has been out for weeks), and the use of a naming style which is frequently associated with methods rather than messages. Savas' later use of the term API has added to this impression. I think we should avoid the term interface to avoid confusion. Protocol = message set + obligations upon senders/receivers. But there is a more fundamental reason why I thought you were talking API.

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. 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.

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. 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 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 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.

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.

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.

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.

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. 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.

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.

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.)

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. I think it is unnecessary (wrong) to bind the atom id to the address in the protocol spec.

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.

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. 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.

Whatever atom web-service is hosting this particular atom will need to be able to determine which atom it has to prepare. I’m assuming this is an attribute of the “prepare” message in the sent XML, for example.

And I assume we can cover this with coordinator-specific addressing.

I obviously forgot to cover the case where the service itself simply doesn’t exist (i.e., the URL is broken). However, that is a general problem for any web services application.

The two-part address and redirection are relevant here.

As you said, getting the status of the atom is pretty much the same as getting the status of the participant. This illustrates how they are similar in some cases.

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.

However, it’s important that we understand that they are not one and the same thing. As I said before, a (sub-) coordinator can be pretty dump w.r.t. the participants it coordinates: as far as it’s concerned they are abstract entities obeying the 2PC protocol, and what they do internally is up to them. So, I can have a write-once, use anywhere coordinator implementation. I can’t say the same thing for a participant.

No, but I can have a write-once, use anywhere participant interface, which is what (in this respect) we're discussing. The behaviour and purpose of the implementation is not strictly relevant.

This makes the provision of a coordinator service (farm) much more likely than a participant farm.

I totally agree.

Alastair
 

begin:vcard 
n:Green;Alastair J.
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
adr:;;13 Austin Friars;London;;EC2N 2JX;England
version:2.1
email;internet:alastair.green@choreology.com
title:Managing Director
fn:Alastair J. Green
end:vcard