Re: [bt-spec] FW: Issue 89

[Mark Little <mark_little@hp.com>]

Tags again.

> 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.
> >
> > 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.
> >
>
> [ I see no 2PC transaction engines out there ( production today ) that
could
> cope with taking a cohesive datastructure, import it and continue to run
it as a
> cohesion .. That is why Oracle et al proposes a solution to 89 ... by your
own
> admission without this ONLY HP would have this feature on the market. ]

<ml>And I have to admit we have had no requirement for this. It just happens
to be the case. We can also do many other things that BTP can't but I
wouldn't want to try to add them to the specification at this late stage.
Perhaps later, but not now.</ml>

>
> >
> > >
> > > >
> > > > > 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.
> >
>
> [ I diagree, I think this is very possible ]

<ml>Based on experience? Please ellaborate because if it is then it's
something we as a committee should know about in order to make this
decision.</ml>

>
> >
> > >
> > > >
> > > > >
> > > > > 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.
> >
>
> [ I am not saying the state should be exported / imported to end points
(nodes)
> .. I am saying that the state should be proxied to the controlling TM's ]

<ml>OK, I think we need a diagram. What do you mean by "proxied"? Copied?
Shadowed? What's a controlling TM? The root of the transaction tree, a leaf,
...?</ml>

>
> >
> > >
> > > >
> > > > >
> > > > > 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.
>
> [ Mark, This is the difference between being a Client to a TM and being a
peer
> to a TM. You are describing 'binding" based behaviour.  ].

<ml>Definitely need a diagram. I thought from what you were describing that
you want the ability for some entity (X) to say to a coordinator "give me
your state" and then for that entity to say to another "blank" coordinator
"take some state" and then to tie the two together into the transaction tree
so that we can see the flow of the transaction. What I described is
certainly about subordinate TMs and not peers, but then if you are really on
about peers we're back to the requirement and use case.</ml>

>
> >
> > >
> > > >
> > > > > 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.)
> >
>
> [ As mentioned you still addressing "client-server" bindings .. the real
issue
> to TM Peer level interoperability ]

<ml>OK, but why. Sorry to belabour this point but we just don't see the
need. And we certainly don't see the need to add this complexity now to the
specification when we are supposed to be 3 weeks away from a final vote. Q:
Do we need this? A: who knows. Q: Do we need this now? A: no (IMO). Q:
Should we add this to the 1.1 list of things to do? A: why not (and make it
top of the list if we have to).</ml>

>
> >
> > >
> > > >
> > > > > 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.
> >
>
> [ As I said, and you admit to - the spec avoid security issues - this was
also
> confirmed at the Oracle FTF and the following conf calls ]

<ml>No, what you said was that "BTP is assumed to run on a trusted secure
network", which isn't the same thing as making no assumptions.</ml>

>
> >
> > >
> > > > >
> > > > > 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.
> >
>
> [ You not talking to ether .. and your comment was taken as a snide remark
not
> just by me but by others here ]

<ml>Unfortunately whether or not my previous emails of 3 weeks ago fell
through cracks, they did not get answered. Subsequent followup emails also
did not get answered. If you want to consider it as a snide comment the
sobeit, but in order to have a discussion on this or any issue we need to
have all parties engaged.</ml>

Mark.

-----------------------------------------------------------------------
SENDER : Dr. Mark Little, Architect (Transactions), HP Arjuna Labs
PHONE  : +44 191 206 4538, FAX : +44 191 206 4203
EMAIL  : mark@arjuna.com | mark_little@hp.com


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