OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

bt-spec message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: Re: [bt-spec] FW: Issue 89


Comments intermixed []

Mark Little wrote:

> > " 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, how can you expect to have a constructive dialog when you insult your
audience ? You comments are in the negative and have no positive result. ]

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



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC