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?
>
> Yes, although naturally I need it to interoperate with Oracle's DTC.

So how many strict 2PC transaction engines out there do you know could cope
with taking a cohesive datastructure and import it and continue to run it as
a cohesion? I can count only one (ours) but that's not a reason for adding
such a feature. I can see that you are proposing this from an implementation
point of view, which is fair enough. However, I'd much rather see a good
abstract case for this first and foremost. We don't see anyone calling out
for such a feature - I don't see many people (anyone) asking for
CICS-state-to-Tuxedo-state either.

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

We don't need this feature for high-availability. If you look back through
the archive you'll see one of the first emails I sent on this subject shows
that.

As for inter-operability, I don't think it's possible to take a BTP state
from a BTP coordinator and import it to a traditional TP system coordinator
and expect it to work. It's an interesting research topic, but it's
certainly not something that I would expect to work today: traditional TP
systems have their own internal data structures, assume certain things about
participants that aren't necessarily true about BTP participants, ... There
are lots of issues around this that simply cannot be solved by saying "let's
export a BTP coordinator state and import it elsewhere." It may be part of
the "solution", but it ain't the whole thing. I'd rather see us step back
and see what it is we (you) want to accomplish and start again from there.
If you really want to accomplish some kind of state-binding for Oracle's DTC
then that's a different issue again IMO.

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

Again, comments above apply and also the comments in the marked-up document
on security. The coordinator in any transaction is an implicit trusted
third-party and to now say that it can export its state to someone else who
the end-points in the business transaction don't necessarily know, is
definitely not a good idea.

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

No, not in the sense of "open" we'd like to continue to use (as the OMG, OSF
etc do.) "Open" in the sense that it's less secure, perhaps.

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

In the same way that I can interoperate between CICS and J2EE now (and in
fact, BTP makes this even easier by requiring all participants to have the
same interface): you use sub-coordination. A transaction started in one
domain (e.g., BTP) can flow to a J2EE domain, be imported, the J2EE domain
creates a sub-coordinator (looks like a JTS transaction as far as the
participants in the J2EE domain are concerned, but looks like a participant
as far as the BTP domain is concerned) and then flows within the J2EE
domain. Only the importing entity "knows" that there is a mapping between
BTP and J2EE. Simple.

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

See above. End-to-end transactionality is possible without requiring
modifications of BTP. If you are interested, I can point you at several
papers on the subject, a couple of which go into implementation detail
(there's even an OMG Success Story on this on the OMG web site.)

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

Erhm, no it isn't. Unfortunately due to time limitations we as a committe
decided pretty early on (way before Oracle joined) that we couldn't address
security but that we would need to eventually (post 1.0 probably). That's
why the spec avoids security issues. We can't make the assumption that the
network is trusted: this is a Web Services world afterall.

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

No, constructive remark: please go away and answer the emails. How can we
have a conversation if I keep talking to the ether? Please do not read
specific emotions into plain ASCII text: it invariably ends up being wrong.

Mark.

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