----- Original Message -----
Sent: Monday, April 22, 2002 11:27
PM
Subject: Re: [bt-spec] FW: Issue 89
Comments intermixed <gb>
Mark Little wrote:
----- Original Message -----
Sent: Friday, April 19, 2002 8:52
PM
Subject: Re: [bt-spec] FW: Issue
89 Comments intermixed <gb>
Mark Little wrote:
----- 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
<gb> No, Mark the point considering the proposal in detail has
never been lost this I consider is all part of the process
</gb>
<ml>OK. At some point (and
fairly soon I'd expect), simply because I assume this issue is open, we as a
committee either need to decide to postpone it (and I'd expect you would
have more of a say in that) or vote on it. Now if you don't think sufficient
time has been spent exploring the issue would you consider postponing rather
than risk have a no vote?</ml>
<gb> Mark, I do think that we need
to spend more time discussing this before we vote on it
</gb>
<ml>Good. I kind of figured that but didn't want to put words
in your mouth. But this does re-raise the issue I've been making: there is
no guarantee we will have made enough progress on this before the
(self-imposed) 1.0 deadline, and in which case what do we do? Vote on what may
be insufficient knowledge, delay the spec or postpone
the vote?</ml>
.
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.
<gb> I think we are all in agreement on this
</gb>
<ml>Great, so I would assume that this means the answer
to my question above is yes?</ml>
<gb> Your understanding on this is correct </gb>
<ml>Again, great.</ml>
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?
<gb> From my viewpoint, as this proposal is not a major change,
(we) see no point at all in defering it to 1.1
</gb>
<ml>It is a significant change. It requires us to agree
on a serialisable form, to determine what the mechanism for getting the
state is (e.g., what's the message set extension?), to agree when this
message can be sent, what are the security implications, ...
</ml>
<ml>BTW, I'm not sure if
this has been made clear before, but we are not arguing against this
proposal from an implementation point of view - for us, implementing this
facility as it currently stands would be trivial. But that's not the point -
we still wouldn't have interoperable answers to all of the above
questions.</ml>
<gb> I am glad that you have clarified your position </gb>
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.
<gb> It would be inappropriate for I to comment on what your
particular customers want and what their thoughts are.
</gb>
<ml>Agreed, but are you saying you have customers now who
want to export from Oracle's implementation of BTP (I'm assuming there is,
or will be, one) to HPs to XYZs? I'd find that hard to believe since this is
such a new area *and* there's only one implementation out there at the
moment. Give it a few more months and there may be more implementations but
I still don't expect to see such an "export/import" requirement then. If it
happens, I'd assume it will be years down the line when these
implementations (or others) have really got some use and are becoming more
prevelant. By then, we will probably by way past 1.0.</ml>
<gb> Customers prefer seamless interoperability
between their vendors propriety TP technology and the BTP. </gb>
<ml>Show me proprietary TP implementations today that
can act as cohesion coordinators? Atoms are (just about) possible with some
systems, but not all. So, today's TPs will not interoperate at the
peer-to-peer level (they can via interposition, but as we already agreed, that
seems different from what you want.</ml>
Cheers, Mark.
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>
> > >
>
|