Re: [bt-spec] FW: Issue 89

[Mark Little <mark_little@hp.com>]

> Using the tag standard ;-)

Ditto.

>
> Mark Little wrote:
>
> > 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>
> >
>
> <gb> Yes, based on experience ... purely in the interests of time, I ask
to
> cover this on a conference call .. </gb>

<ml>If we have to then it'll really need to be one of the regular tcs.</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>
> >
>
> <gb> Yes - I owe everyone a diagram. By "proxied" I mean that the
controlling TM
> ( TM that is responsible for the entire transaction chain ) *passes*
> responsibility to another Peer level TM. Proxy is probably the wrong word
here
> </gb>

<ml>OK, I got confused by the "proxy" term. But then, as I asked in a
previous email, when is this assumed to happen, how do we ensure multiple
coordinators don't try to terminate the same transaction, and I keep coming
back to the security implications. None of this is insurmountable; I just
don't think we can cover this in the time remaining.</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>
> >
>
> <gb> I understand fully your discussion about sub-coordinators and I do
mean
> PEERs so your quite right we need a use case </gb>

<ml>OK</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>
>
> <gb> Honestly, I can not make it any clearer - other than a use case </gb>

<ml>Fair enough. Can you cover the aspects of timing and TM-to-TM
coordination as well?</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>
>
> <gb> We need to get a vote on this as it is very important - in our world
when
> we mean secure we mean it to military level .. eitherway, clarification is
> needed </gb>

<ml>I'm sure we can all learn a lot from Oracle about security.</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>
> >
>
> <gb> Mark, other than the questions which we run though are there any
others I
> may of missed </gb>

<ml>I think I've put the main ones in the previous emails. However, what
kind of time frame would you expect for the 1.1 specification? We (HP) are
assuming it won't be as long as the 1.0 specification.</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>
> > > > > > >
> > > > > > >
> > > > >
> > > > >
> > >
> > >
>
>