Re: [bt-spec] FW: Issue 89

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

Comments intermixed [ ] ...

Mark Little wrote:

> > The issue :
> > -----------
> >
> > It is very attractive to gain "peer" level inter operability with the BTP
> TM, by
> > "peer" level inter operability I mean the ability of a non-BTP TM to
> collect the
> > state ( on demand ) and therefore continue execution within a traditional
> TP
> > infrastructure.
>
> So you want to export a BTP TM state and import it to, say, CICS?

Yes, although naturally I need it to interoperate with Oracle's DTC.

>
> > A natural by-product of this approach is that it provides much greater
> levels of
> > HA.
>
> If this is why you would want to do this then we should look at HA
> techniques in general. If it's for "interoperability" then that's something
> else entirely.
>

Both "inter operability" and "HA".

>
> >
> > Where this comes from :
> > -------------------------
> >
> > My experience with integrating transactional application and navigating
> supply
> > chains ( i.e. vendors apps et al ) is that one has to "patch" together
> > transactional state across TPMs. This is a well known problem that many
> SIs
> > face, due to limitations with TP monitors this is usually addressed by
> > asynchronous messaging. Ironically this is exactly why TP monitors can not
> be
> > used across the web today ; I architected Oracle's Message Broker for this
> very
> > reason.
>
> What do you mean by "transactional state"? Do you mean tracking down where
> the context flows to? What the format of the context is? Do you have a
> worked use case on this?
>

[ Current TRX state for the controlling TM which inherently points to
transaction flow ]

>
> >
> > Summary :
> > -----------
> >
> > This is not rocket science .. this is common sense. Bindings allow
> > "client-server" inter operability only. Let me be clear that bindings are
> needed
> > but I feel they do not address the aforementioned problem .. *IF* the BTP
> > committee want a truly *OPEN* transaction infrastructure then this
> proposal
> > addresses the problem.
>
> Sorry, but we still don't get it. This definitely makes BTP more "open", but
> that's a bit like saying that in order to make operating systems open lets
> remove all security restrictions and give everyone root access: it's
> possible but why would we want to do that? BTP is "open" in the traditional
> sense of the word (the sense that, say, the OMG would use, or the OSF would
> use). This keeps boiling down to us not seeing the use case for it. And
> that's not to say that there isn't one, just that we can't see it. So, if
> there is such a beast, please show it in detail so we can examine the
> protocol implications. Simply saying that BTP isn't "open" without it isn't
> sufficient I'm afraid.
>

[ ??? you acknowledge that this approach makes the BTP more open. So let me be
explicit, BTP is an OPEN standard, however one can not operate on a peer level
as the TM's state is locked in the BTP infrastructure ... if I use J2EE TM /
CICs et al how can I actually inter operate between TMs ( not using bindings ).
]

>
> > Again I propose this approach as an "optional" part of the BTP spec - for
> large
> > scale complex transactional infrastructures.
>
> So why can't we leave this as deferred, discuss it in a lot more detail (I
> think it requires it) and then add it to the 1.1 version if we as a committe
> agree it's good?
>

[ So, please explain HOW I can inter operate at a peer level with other TM's ??
How do I daisy chain / proxy  TRX context ]

>
> > The BTP TM should only render its
> > current state in XML on DEMAND and not for every single operation.
>
> And what about the security implications? As I said in the previous email:
> please answer the questions in the marked-up Word document. We can only have
> an informed discussion if *both* parties engage in it!
>

[ What security implications are there ???? BTP is assumed to run on a trusted
secure network - The spec avoids security issues on purpose ]

> >
> > If there are any constructive alternatives
>
> Lots if you're just after HA (see email of about 3 weeks ago that you didn't
> respond to either).
>

[ Snide remark - being constructive again I see ]

>
> As for alternatives for other requirements - it's difficult to say since we
> still don't understand why you need this.
>
> > please let me know as I will be very
> > happy to apply these to the real-world problems that the industry faces.
> >
> > Geoff.
>
> Mark.
>
> ----------------------------------------------
> Dr. Mark Little, Distinguished Engineer,
> Transactions Architect, HP Arjuna Labs
> Email: mark_little@hp.com
> Phone: +44 191 2606216
> Fax  : +44 191 2606250
>
> >
> >
> > "WEBBER,JIM (HP-UnitedKingdom,ex1)" wrote:
> >
> > > Hi everyone,
> > >
> > > I've just read Geoff's document and Mark's comments. Now I am perfectly
> > > willing to accept that I might be being naïve here, but could someone
> please
> > > clarify for me what precisely the benefits of sharing state in a common
> > > format are? I can well enough see the drawbacks for myself, but I am
> rather
> > > finding the benefits difficult to quantify.
> > >
> > > I don't have an objection to J2EE (or any other platform for that
> matter)
> > > interop with BTP, but does sharing of state (as opposed to say defining
> > > standard bindings at the message level) really achieve that objective in
> a
> > > straightfoward way?
> > >
> > > Again, this isn't a rebuttal to the Oracle/Choreology suggestion, more
> of a
> > > plea for help in understanding its value.
> > >
> > > Ta.
> > >
> > > Jim
> > >
> > > ----------------------------------------------------------------
> > > To subscribe or unsubscribe from this elist use the subscription
> > > manager: <http://lists.oasis-open.org/ob/adm.pl>
> >
> >

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