----- Original Message -----
Sent: Friday, April 19, 2002 6:27
PM
Subject: Re: [bt-spec] FW: Issue 89
Comments intermixed []
Mark Little wrote:
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.
[ Mark I think you are in isolation here.
Fine, we shall see if we ever get to a vote.
First off, I am not asking anyone to bend over backwards ( ooh eerr ) ..
and if anyone is under the illusion that I am they are mistaken. You have
missed the core caveat that is in this proposal .. it is OPTIONAL ..
And you have missed the core point of pretty much every email I've sent on
this subject: whether or not it is optional, it should only be added to the
specification after we have had a chance to consider it in all of its detail. If
we had begun to discuss this significant change in January, say, then I think it
would be possible to say that it should be in 1.0 (assuming it passed the vote);
however, for whatever reasons it's only just come into the view of the entire
committee. I would have thought you would want this carefully considered before
we vote on it; that's all we're saying.
I do indeed want this in the spec, as I think it addresses a major
interop problem and thus is attractive to our collective customers.
We have quite a lot of customers for HP-WST and not a single one of them
has asked for this. That's not to say that they won't eventually (though I'm
still not sure), but by that time we will be well into the 1.x timeframe.
Now if I instisted that every vendor HAD to implement it - then that
would be unreasonable, however I am not.
But if it is not well thought out then adding something that is potentially
broken (again, I'm not saying it is, only that if we rush it through we might
miss something that is needed) will screw up the specification. The BTP spec.
has taken 12 months to get to this stage and we've spend many weeks on lots of
issues to try to iron the out now rather than find them when people actually
come to implement. Let's not throw that away now by adding something (anything,
not just this) in haste. I've said to various people on the committee that HP
have several things we'd like to see added to BTP but we have deliberately not
mentioned them just now in case it delays the specification further.
Yes, Oracle was late to the party, but at least we are here. This to the
best of my knowledge is the only major issue that Oracle has. Step in my
shoes Mark - I am asking Oracle to bend over backwards to support this spec.
And the proposal I put in has value and I am not dictating to anyone.
I don't think we're at odds here on Oracle believing there is value here.
Great. (If it's based on a business case then I'd love to see it so we can show
it to our sales guys too ;-) We've never said "remove the issue", only "defer it
until 1.1" and give us all time to consider it. Is that unreasonable?
This is a version 1 - ticket item. I am not going to drop this one Mark,
I feel it is to important ]
And we'll continue to disagree. We have many customers using (essentially)
version 1.0 and they don't miss this feature. And they are not using
BTP in a simple manner. However, as I said above, that's not to say
they won't ask for this later, but if (and when) they do I'd much
rather have a solid story for them in the BTP specification than something
that may not be as well thought out as we'd like.
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. [ it is a fact ]
Good.
All the best,
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.
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>
> > >
>
|