Re: [bt-spec] IMPT : Oracle Technical Submission for the BTP

[Geoffrey Brown <Geoffrey.Brown@oracle.com>]

Mark,

First off, thank you for taking the time to review, comment and contribute to the proposal. You have helped clarify some further details.

I will post a revised proposal on the next mail.


Can you supply the JSR number? I’m assuming that we are not tying the two together (or at least the binding is unidirectional from the JSR to BTP)?

[gb] JSR 156

 Don’t quite understand what you’re trying to say here? Are you saying that we will require proprietary systems from now on to have knowledge of BTP?

[gb] Recommend that proprietary systems have visibility of the BTP.


 Think there might be a word missing here.


 OK, so this impacts other parts of the specification since we currently don’t make that assumption anywhere else. I’m not saying it is a bad thing to add, only that it does open up a whole set of other issues that
we need to address as well (e.g., authentication, capabilities, …). So, I’d really like to spend more time discussing this than we have at present.

[gb] I think the spec should clarify that the BTP is intended to run on a secure transport.

 So you are assuming we can implement/define one of these for all time across all proprietary implementations?

[gb] I think the specification should acknowledge and address the problem.

 This comes back to an earlier discussion we started to have: I don’t believe existing proprietary systems can cope with BTP state and maintain/use it in the manner it was meant for. If they can, then they’re BTP
implementations (or near as damn).

[gb] I agree with you here. Hence why I am addressing this issue with this proposal.

 Sorry, which aspect are you referring to?

[gb] The aforementioned proposal. Transaction migration across applications domains. Domain is a general reference.

 This sentence doesn’t make sense. Wrong word perhaps?

[gb] Thanks for catching the typo.

 Extra word?

[gb] Thanks for catching the typo.

 If this is the use case then I’m afraid it doesn’t help. You seem to change the argument as to why this is required from one message to another. Is it for high-availability (as was the case a couple of weeks ago),
for cross-domain transaction flow, or something else? I’m not trying to be awkward, but I (and others) really need to know in order to validate this proposal against what we know BTP can do now.

[gb] I change argument as I hit all the major points, the message has been consistent.

 In the attached diagram, which is based on your first figure, I’ve added a Coordinator Manager (CM), which as far as users go looks like a coordinator (atom or cohesion, it doesn’t matter). The actual location of
this manager and the number of them in the environment (I’ve shown 2, but there could be more or less and they could form a federation/tree structure) is a deployment decision. The CM knows about the coordinators
(both BTP and proprietary) in the environment and can, potentially, be updated with this information dynamically. The CM forwards requests to the real coordinator and may share information (e.g., messages) with
other CMs. It may also, depending on deployment requirements, forward messages to other coordinators in order that they may shadow a primary coordinator. Now, if we assume there is a single primary per domain as
you have drawn, then what happens if the primary fails or wants to migrate? We leave this to the CM to deal with: no effect on users. Importantly, all of this can be done within the current specification. If you
want me to go into more details then I will see if I can write a few pages on this. However, each implementer of a CM would be free to do whatever they want as far as protocol is concerned, since this all sits
behind the “coordinator interface”. If this all makes sense, then the next question is: what does this not accomplish that your original diagram required?

Still unsure of what this is supposed to do (e.g., who uses it, what are its consistency requirements, what is the interface to it, …?)

[gb] Mark the CM approach has a lot of merit .. in the diagram this functionality is represented by the BTP RM.

 So this is a new BTP message?

[gb] Yes. A bi-directional event message  - MIGRATE.

 In my diagram this would be sent to the CM which would then simply change its notion of who the primary is.

 Again, the CM would do this.
 If using the CM, then no state migration is required.

[gb] agreed.

 This is another message? In the case of the CM, no notification of the participants need occur.

[gb] No not a message, just describing the activity.

Mark Little wrote:

> Apologies, I attached the wrong document. This should be the right one ;-)
>
> Mark.
>
> -----------------------------------------------------------------------
> SENDER : Dr. Mark Little, Architect (Transactions), HP Arjuna Labs
> PHONE  : +44 191 2606216, FAX : +44 191 2606250
> EMAIL  : mark_little@hp.com
>
>   ------------------------------------------------------------------------
>                                                                                                              Name: Proposal for Transaction Coordinator Migration for the OASIS Business Transactions Protocol.doc
>    Proposal for Transaction Coordinator Migration for the OASIS Business Transactions Protocol.doc           Type: WINWORD File (application/msword)
>                                                                                                          Encoding: base64
>                                                                                                   Download Status: Not downloaded with message

Attachment: Geoffrey.Brown.vcf
Description: Card for Geoffrey Brown