Re: [bt-spec] FW: Issue 89

[Geoffrey Brown <Geoffrey.Brown@oracle.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

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

Attachment: Geoffrey.Brown.vcf
Description: Card for Geoffrey Brown