RE: [bt-spec] BTP Issue 82 : ENROL related to application message -solution in 0.9.0.3

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

My contribution to the unclosed discussion on issue 82. (I've reverted the issues status to "solution proposed" - I changed the issue colours again earlier this week to make the votes show up better, so 82 is now maroon.)

 

 

There is a link to the architectural question that Sanjay raised and I've put into issue 65 - see my message on that. The linkage is that if you allow propagation of a CONTEXT/cohesion, then the identification of which bits of application work are associated with of the Composer's Inferiors requires the relationship between ENROL and an application message arising from the application work. It's less significant in the case of propagated CONTEXT/atoms, because then the association between application work and enrolled inferior can be done by which application message the CONTEXT related to.

 

The case is most readily explained by a scenario. I'll base it on the Choreology demo at first.

 

The application design is to ask each of several market makers (services) to provide a binding quote on two items - a stock and an option. The quotes are "binding" in that each is associated to a prepared Inferior (Participant).  The client end will compare the quotes and choose the best stock and the best option - these need not be from the same market maker.

 

One way of implementing this is for the client application to create a cohesion, and pass that CONTEXT/cohesion with the "getquote" requests to each of the market makers - with two separate getquotes to each. For each quote, the market maker create a Participant, and enrols it in the cohesion, and returns the particular quote information to the client. 

 

It would obviously not work if the market maker just sent an ENROL to the Composer and the quote to the client but did not indicate back to the client+composer which enrol belonged to which quote.   The client, as terminator to the composer, can distinguish the different inferiors (we have more than one means for this - "inferior handle" qualifier being one of them), but needs to know which is which.

 

At abstract level, what has to be communicated from the market maker to the client is that ENROL(23), say, is for our option quote, and ENROL(25) is of the stock quote. The most obvious way to do that is to say that ENROL can be related to an application message. That's all that the proposed resolution of 82 was really saying : that it is a meaningful statement to say that. The particular text in the related groups section is concerned with making sure the ENROL goes near enough to the application to make this possible, given that the Composer may not actually be colocated with the client application (whereas the CONTEXT_REPLY's target is deemed to be sufficiently colocated that the relation can be perceived).

 

----

The particular example can in fact be worked differently (by making "local" atomic inferiors of the cohesion at the client, and putting different CONTEXT/atoms on the getquote(option) and getquote(stock).  However, an obvious extension of the example won't work that way, and needs the cohesion propagation above.

 

If, instead of the client deciding to get both quotes from every market maker, the decision of which quotes to submit is make by the market makers, who are just informed that quotes are desired, then some market makers may create one Participant, some two, and, if they perhaps wnat to make a special offer, three.  Or, given that this quotes are time-limited, they might wish to offer, at the same time, a very competitive price with a short timelimit, and a less good one, but with a longer timelimit. All of these require some way of saying "the application work implied by this message (in our case, a quote) has been put under the control of this BTP Inferior"

 

---

there are some other yet more intriguing things you can do down this path, but I think this gives the essence

 

 

Peter

------------------------------------------
Peter Furniss
Technical Director, Choreology Ltd
web: http://www.choreology.com
email:  peter.furniss@choreology.com
phone:  +44 20 7670 1679
direct: +44 20 7670 1783
mobile: 07951 536168
13 Austin Friars, London EC2N 2JX