Re: [bt-spec] FW: Issue 89

[Mark Little <mark_little@hp.com>]

> 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?

> 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.

>
> 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?

>
> 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.

> 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?

> 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!

>
> 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).

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>
>
>