RE: [bt-spec] BTP Issue 69 : prepared subcomposer with unpreparedinferiors ?

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

 

BTP Issue 69 : prepared subcomposer with unprepared inferiors ?

Category: minor technical
Submitter: Pyounguk Cho(Pyounguk.Cho@iona.com)
Detail: Can a subcomposer be prepared when some of its inferiors cannot be prepared?

---

 

Yes, but those inferiors are not in its confirm-set.

 

 We (currently) treat the choices made by a sub-composer among its Inferiors (i.e. the evolution of its confirm-set) as effectively part of the application:participant interface, which is not specified in BTP.  From the perspective of the superior, the sub-composer is just a single Inferior and indistinguishable from a simple participant that controls some local (single) resource.  How the application determines and communicates to the participant what the resource is, is not specified in BTP.

 

In the case of a sub-composer, the "resource" the application (as service) is making a PREPARED promise about is not a single thing, but some choice of things. But what they are, where they are and which of them might be needed to make valid a PREPARED promise to the Superior is known only to the service.

 

There are three cases, at application optoin:

 

The sub-composers choice could be set during the active phase - in which case it seeks to prepare onlty those, the others are cancelled. From then on, the sub-composer behaves exactly as a sub-coordinator - if any of the confirm-set return CANCELLED, it must cancel the others and report CANCELLED to its superior.

 

The sub-composers choice could be set at prepare time - it may attempt to prepare everything, but chooses the confirm-set from the inferiors that reply with PREPARED. It logs only those, and from then on behaves as a sub-coordinator - if it receives CONFIRM, it sends CONFIRM to all the Infeirors.

 

The sub-composers choice could be finalised only at confirm time - it chooses a kind of "short-list" of prepared Infeirors to log (cancelling others), according to application logic and logs those, replying PREPARED to its supeiror. If CONFIRM is received, it then, using some further piece of application logic, now finally makes its choice from the remaining candidates, CONFIRMing some, cancelling the others.

 

The last at least of those requires some kind of callback to get the application logic.  In all three cases, the controlling consideration is what the application is about.

 

 

As an illustrative analogy , imagine the "rent a car" leg of the usual unrealistic travel scenario. Rather than AVIS, you decide to go with a company that re-uses cars parked at the airport while their owners are away. (the owners get paid for this, recouping some of the cost of owning the car). When you first request, they ask all their members if their car will be available - some say they can. Conversation with you clarifies what size of car you want, so cancel the wrong ones, and solicit promises from the others that they are available (PREPARE). Some can't make the promise (CANCELLED), others can. Rental agent doesn't want to keep to many possibilites open, cancel all but three.  The confirmation doesn't happen till you actually turn up, when they finally decide which car you get.  (and note that if one of the cars went heuristic, because the owner drove it off, the rental company can cope).

 

 

Peter