RE: [bt-spec] Relationship: Composer:Participant - assign to issue 65

[Peter Furniss <peter.furniss@choreology.com>]

Now the technical bit

 

I believe Sazi is taking an example of what can be and assuming it is the pattern that things always are. Involved in this are some different ways of thinking what an "atom" is. Or, you can look at it as we originally had a problem, to which we (jointly) developed a solution, but it turns out the same solution delivers more than that - *unless you actually go to effort to stop it*.

 

In thinking of the overall design or view of a business transaction, we a number of "nodes" connected by superior:inferior relationships. At the top of the tree, there may be an instance of the standardised "control" relationship, or the equivalent control may be exercised through a proprietary api.

 

Now each nodes relation with a superior is of exactly the same kind. At some point, as a result of receiving a PREPARE or from a direct stimulus from the "local" piece of the application, it gets itself in a prepared state, and sends PREPARED to that Superior. Whether that involves getting PREPARED's from any Inferior's of its own, or getting an xa_prepared out of a database or directly making sure it has a compensation operation safely persisted "up its sleeve" is unknown to our node's Superior. The Superior eventually sends CONFIRM or CANCEL and our node does what is appropriate. So our Superior cannot tell if we are a Participant (no BTP inferiors), a sub-coordinator (BTP inferiors, treated atomically) or a sub-composer (BTP inferiors, treated cohesivally)

 

Equally, from the perspective of our node, it cannot observe any difference in the behaviour of the Superior depending on its kind. We send PREPARED to it. We get either CONFIRM or CANCEL. If it's CANCEL, we can't tell if this is because everyone got cancelled, or we were singled out. We can't tell if the superior got us, and any other inferiors prepared, and reported on to its own Superior, or if it was driven directly by the application. So we can't tell if our Superior is a coordinator, composer, sub-coordinator or sub-composer.

 

Given those two paragraphs is why we hold that there is no fundamental reason why a Composer can't be an immediate Superior of a Participant - it is more or less impossible to stop it.

 

Of course, the cases can be distinguished if we look at the tree as a whole. But BTP generally assumes there is no-one with that knowledge (strictly, it assumes there *need* be no-one with that knowledge). Although, for a particular case, there will commonly be sections of the tree as a whole that are under single design (and quite likely in one machine), which will mean the different nodes do "know" what each other are.

 

One case of this is where the top of the tree is a cohesion, and the application that created the cohesion then creates new atoms as the immediate inferiors of the cohesion (so these are deemed sub-coordinators, since they have a Superior, which the designer knows is the Composer). The contexts for the those atoms may then be propagated with application messages that do some work, causing the creation of new nodes that enrol, each with the superior that is identified in the context (one of the sub-coordinators). These new nodes are probably Participants, directly controlling the application data, though they could have BTP inferiors of their own. (there's actully nothing to stop an implementation creating nodes that both control data and have btp inferiors - under our current definitions that is *not* a Participant - it may not be a very clean class structure, but that's its implementors problem, not ours)

 

One first variation on that might be that the work to be done for one of the legs of the cohesion is local to the originating system. There is no need to make a intermediate node - the work can be put directly under the control of the node that is enrolled with the composer. But that would make it a Participant, by our definitions.

 

It's worth noting that, by one use of the words, all Participants are atoms - that is they apply a single decision to all of their parts. Of course, if they don't offer the superior interface, have no corresponding CONTEXT and can't enrol inferiors, they aren't BTP Atoms with a capital A (or at least, their not sub-coordinators).

 

A greater variation on the example above - and one that is architecturally different in design, though it can end up delivering the same functionality - is for the application to create a cohesion and propagate the cohesion context itself with application messages. A receiving service that does some work in this case creates nodes that are enrolled with the superior identified in the received context, which in this case is the composer. Again, it is up to the service whether the new node has btp inferiors of its own or not. Whether you consider these as "atoms" is a question of definition again.

 

But what is important about this latter example is that it allows application uses that impossible otherwise. This is the example I mentioned in the conference call (in the discussion about issue 82), so I'll put in the relevant example under that discussion.

 

I think this is really what Sazi's is arguing against - that we disallow the propagation of a cohesion context. But that's really next to impossible. The existence of the concept of CONTEXT/cohesion means that we cannot in general control the location of the things enrolled with the Composer, and if we can't control their location, we (or rather the cohesion) can't control their type (in the sense of Participant or not). And we need CONTEXT/cohesion if we are to enrol sub-coordinators in the cohesion in the first place.

 

 

Lesser point: this whole discussion gets very muddled if the terms get used differently, and some of the argument here is certainly because of inconsistent use. I believe the current draft is internally consistent in its definition and use of the role names. Obviously alternative uses are possible, but some questions about what can be done are really equivalent to changing the role names. 

 

To recap (and using the concept "node" which isn't a first-class concept in BTP, but useful. Maybe we should add it) -

:

  a Coordinator is a node that is not an Inferior; has an address-as-superior; and, if multiple inferiors enrol, will deliver the same outcome to all inferiors; it is controlled by an application element, either via the Decider interface, or by an equivalent means.

 

a Composer is a node that has not an Inferior; has an address-as-superior, and if multiple inferiors enrol, may deliver different outcomes to inferiors, as determined by the application, either as a Decider, or by an equivalent means

 

a Participant is a node that is an Inferior, and does not have an address-as-superior (so no-one can enrol with it)

 

a sub-coordinator is a node that is an Infeiror,  has an address-as-superior; and, if multiple inferiors enrol, will deliver the same outcome to all inferiors; it is not a decider (since it is controlled as an Inferior)

 

a sub-composer is a node that is an infeiror; has an address-as-superior, and if multiple inferiors enrol, may deliver different outcomes to inferiors; it is not a decider, but the application will be involved (by an undefined means) in determining which inferiors confirm if it is ordered to confirm by receiving CONFIRM.  

 

Peter

 

 

 

 

 -----Original Message-----
From: Sanjay Dalal [mailto:sanjay@bea.com]
Sent: 15 January 2002 15:02
To: 'Bt-Spec '
Subject: [bt-spec] Relationship: Composer:Participant

There seems to be an issue regarding relationship between Composer and Participant. I am attaching relevant discussion on mailing list. I am told that it was discussed in LC f2f but no conclusion was made. I am sending this formal request to open an issue on this topic to track it and close it.

 

thanks,

sanjay

 

Ref: mails:

 

http://lists.oasis-open.org/archives/business-transaction/200112/msg00045.html

http://lists.oasis-open.org/archives/business-transaction/200112/msg00041.html

http://lists.oasis-open.org/archives/business-transaction/200112/msg00035.html

 

-----Original Message-----
From: Sazi Temel [mailto:sazi.temel@bea.com]
Sent: Monday, December 31, 2001 8:20 PM
To: Sanjay Dalal
Cc: Peter Furniss; OASIS BTP (Main List)
Subject: RE: [business-transaction] FW: diagrams

At 11:47 PM 12/30/01 -0800, Sanjay Dalal wrote:

Peter,
 
Thanks for the reply and comments. I have made changes as per your comments.  Please see inline for other comments. Let me know if you have any suggestion for more diagrams too.
 
Wish you and BTPers a happy, healthy and peaceful new year.
 
thanks,
sanjay
 

----Original Message-----

From: Peter Furniss [mailto:peter.furniss@choreology.com]

Sent: Tuesday, December 18, 2001 10:10 AM

To: OASIS BTP (Main List)

Subject: RE: [business-transaction] FW: diagrams

Sanjay,

Sorry I didn't comment on your diagrams earlier - I think they will be really helpful, and some at least will get into the intended model section.

thanks. I hope these are also useful for primer apart from the specifications.

<snip>
[sanjay] What is the relationship between Composer and Coordinator?

[peter] Composer and Coordinator have direct S:I relation to sub-coordinator, to sub-composer and to participant

[sanjay] Sazi tells me that this was not resolved in f2f, esp. Composer-Participant and Composer-Sub-composer relationships. I understand your thinking too. I have kept the relationships at abstract level i.e. one can implement such that the same entity can play the roles of Composer and Coordinator. It means, that entity can directly talk to the Participant. In the same way Sub-coordinator and Sub-composer can be played by another entity. That way Composer-Coordinator entity can talk directly to Sub-composer-Sub-Coordinator entity.

 

[sazi] We have discussed the relationship between composer and participant at the f2f meeting. I have pointed out that Composer having a direct relationship to a participant is new in the current spec, and somehow invalidates the role of coordinator. Peter and I have given some examples of our understanding on this issue...

Although, I don't belive we have a final decision on the issue, it was an interesting discussion, we may be much closer to a final decision then it seems...

<snip>