Mark,
Apologies .. I retract the comment about missing questions, find the spec
attached with answers to your comments ( annotations ). This supplements the
other email threads.
BTW - Don't feel you have to justify your position with vague comments like
.. " 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" .. I would expect the other participants to openly express their
opinions in a constructive manner, I have very thick skin and an equally open
mind. I feel the proposal I have made stands on it's own merits.
As far as I am aware they have. However, you are certainly correct in that
it would be good to hear from others on this subject.
Also your comment " The fact that you continue not to answer these real
issues does not do this issue any good " ... Other than a decent use
case requirement, which is well justified, I feel that I have answered ALL
your questions ..
With the last 2 emails you have certainly begun to answer those questions.
And for that I'm grateful.
now if you accept them or not is a different matter ... One could also say
that I was warned your resistance was to be expected for many reasons .. and
no doubt from the same sources you refer to. I will naturally let these
sources speak for themselves rather than use them as a justification for my
position.
We (HP) are not in a position that having Oracles support on BTP is so
important that we will bend-over backwards to accomodate all isues you may say
you require. That's not the way this committee has worked in the past and just
because we are close to finishing I don't think we should change. All I am
asking for is a good use case and a strong reason for why this should be added
*now*. If you read back through all of the emails I have sent on this subject
you will see that I have never said we should not discuss this or that it
shouldn't be added; only that it should be discussed *in detail* and deferred to
post 1.0 because there is a lot more required than just state serialisation. Not
having this in the 1.0 specification will not affect its take-up IMO, but having
it in in a potentially broken form may make it harder to correct later (note, I
am *not* saying that the XML we've seen is broken or anything, only that if this
is rushed through we run the risk of missing important things that may be
required to accomplish what you want.) This all seems reasonable to me.
And .. " I know that we are all busy with other things" .. as I
mentioned to the group - I am at the whim of Oracle's 4th Quarter and at the
scheduling of the BTP calls ... I do my best - period. I am truly sorry that I
can not make HP's FTF, however I have noted that we are both presenting at
NextWare (May 20-23) yourself on "transactions in a web services model" and I
on "GRID infrastructure" so hopefully we can finally meet F2F.
I look forward to it.
Anyway, keep it professional and not personal .. we all want the same
thing, a BTP that is valuable.
I hope so too.
Mark.
Geoff.
Geoffrey Brown wrote:
Mark,
Can you make your questions explicit .. I only see highlighted text ??
I very disappointed that you feel that I do not answer your questions ??
Always happy to elaborate .. I feel a conf call my serve as a better
medium ... I will be unable to make the conf call next Wednesday as I
will be with a client .. therefore, please provide some suitable dates /
times ....
9pm PST works on the 25th / 29th April.
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>
> > > >
|