Re: [bt-spec] FW: Issue 89

[Mark Little <mark_little@hp.com>]

> " The fact that you continue not to answer these real issues does not do
this
> issue any good." and "in summary: even less convinced than I was prior to
> reading it " ....  ARE NOT CONSTRUCTIVE

I disagree. In any conversation there needs to be dialog between the
interested parties. You do not appear to want to enter in to such dialog
(please go back through the BTP archive and just see how many emails that
contain questions to you you have actually answered).

The "less convinced" statement is just that: a statement based on *reading*
the document and *responding* to it - as was indicated in the email, it is a
marked up document that has constructive comments within it too.

Mark.

>
> Mark Little wrote:
>
> > Geoff, I'd be happy if you could also answer all other queries in the
marked
> > up Word document and previous emails on this subject. They are all meant
to
> > be constructive, despite what you may feel. As I have said time and time
> > again, if you can show that this is a useful thing to do then I believe
we
> > should consider it. However, you have not done that and perhaps that is
> > simply down to mis-communication. I know that HP is not the only company
on
> > the committee that feels the same and that others have expressed this in
> > same concern in face-to-face meetings.
> >
> > The fact that you continue not to answer these real issues does not do
this
> > issue any good. I know that we are all busy with other things, but if
you
> > feel strongly about this issue then I hope you will find the time to try
to
> > convince myself and others.
> >
> > Mark.
> >
> > ----- Original Message -----
> > From: "Geoffrey Brown" <Geoffrey.Brown@oracle.com>
> > To: "WEBBER,JIM (HP-UnitedKingdom,ex1)" <jim_webber@hp.com>
> > Cc: "Bt-Spec" <bt-spec@lists.oasis-open.org>; "Brown,Geoffrey"
> > <GEOFFREY.BROWN@oracle.com>
> > Sent: Thursday, April 18, 2002 7:42 PM
> > Subject: Re: [bt-spec] FW: Issue 89
> >
> > > Hi Jim,
> > >
> > > As this is a constructive request from yourself (HP) I am happy to
> > elaborate
> > > elaborate. Considering that the BTP contains a huge amount of TP Gurus
> > this
> > > should make sense .. I hope ;-)
> > >
> > > 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.
> > >
> > > A natural by-product of this approach is that it provides much greater
> > levels of
> > > 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.
> > >
> > > 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.
> > >
> > > Again I propose this approach as an "optional" part of the BTP spec -
for
> > large
> > > scale complex transactional infrastructures. The BTP TM should only
render
> > its
> > > current state in XML on DEMAND and not for every single operation.
> > >
> > > If there are any constructive alternatives please let me know as I
will be
> > very
> > > happy to apply these to the real-world problems that the industry
faces.
> > >
> > > Geoff.
> > >
> > >
> > > "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>
> > >
> > >
>
>