OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

bt-spec message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: RE: [bt-spec] Oracle BTP Technical Proposal


Since Geoff isn't able to be with us in Newcastle (and I wasn't available to talk to him today when he was available to talk to me), I'm sending these comments to him and the list - otherwise these would just be comments at the f2f (and thus better explained, with luck).
 

Summary:

migration of BTP coordinators and nodes requires a means of representing the state of each node, but the details of how the transfer is triggered and performed is better considered as an application/management (or at least not a 1.0 btp) issue. The detailed mechanisms (including migrate messages etc.) in the oracle proposal should be considered as examples of use, rather than first-class btp features.

 

Particulars:

 

Although the basic pattern of the migration can fit with the rest of the BTP mechanisms, the feature of requiring all btp nodes (atoms, participants) to deliver their state to their superior would violate one of the key assumptions of BTP – that the internal workings of an Inferior, including exactly what it does in application terms, are invisible to the Superior. Part of the design target of BTP is that the Superior and Inferior belong to different organizations, and their shared understanding is limited to the application (and BTP) contract between them.  Adding a MIGRATE message to the Superior:Inferior relationship (with the effect, in the Oracle proposal, of causing the Inferior state to be sent to the Superior) would break this paradigm.

 

Related to this, and particularly for a Participant, the BTP state must be tied to some application information to define what the Participant will do in response to confirm or cancel. The serialisation of this application information must clearly be an application issue (xml is an obvious candidate for how to do it).  In general, once serialised, the application information could be contained in the BTP state or the BTP state could be contained within an application state structure. In the latter case, the requirement on BTP specification is only that the BTP elements within a wider application element can be serialised - the mechanism, triggers, messages and restrictions for the migration would be application concerns, not BTP concerns. (Similar considerations apply to migrating a cohesion composer or sub-composer and the controlling application, or indeed an atomic coordinator which is still in the active state, since the application state again needs to be associated).

 

 

Peter

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

 

 

-----Original Message-----
From: Geoffrey Brown [mailto:Geoffrey.Brown@oracle.com]
Sent: 14 May 2002 21:36
To: Little,Mark; William Z Pope; Peter Furniss; bt-spec@lists.oasis-open.org; William Z Pope; gixbrown@oracle.com
Subject: [bt-spec] Oracle BTP Technical Proposal

 

Please find attached the Oracle proposal for resolution of issue 89. As mentioned in the text, this proposal is for inclusion into v1.0 of the specification only.

Ideally, this proposal will not be viewed as (i) Complicated (ii) Troublesome, but more as an exciting opportunity for the BTP.

Can the Tech Chair please ensure that this formal submission is posted in the Documents -> initial submission section on the BTP web site.

A word about Newcastle, I will not be able to attend this important meeting in person due to events completely out of my control. I apologies in advance. However, based on various requests I would like to offer the next F2F at Oracle's Redwood Shores campus.

Thanks,

Geoff.



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC