Just to be clear, the proposal is on the table for version 1.0 of the
specification - not for version 1.1 . I raised this well before the issues
list was closed ( issue 89 ).
Mark Little wrote:
[Mark
Potts] Geoff, Mark, Jim - Hi!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.
[Mark
Potts] Ok
I am I am sure it is me being discussed as the cloaked third party here!
There
are others, but I'd prefer to close that part of this topic now.
I
have not entered the foray as yet, since voicing my objection at the f2f,
because 1) I have been at the WS-I for last 3 days and am behind in e-mail
terribly 2) was waiting for the use cases that determine/define this features
so I can look at it in detail and bounce the concepts and see if our contacts
see a need, have pain or could benefit from this. I was asked at the f2f
to wait, in voicing objections, until we had this document and then discuss
the appropriateness of the proposal - now I have the docs and details I
will be reading them today.On
a less specific point, I have stated for a long time now that there are
some things I believe would add real value to the spec (we needed to look
at SOAP Intermediaries and SOAP routing, SOAP Referral because of
a cases similar to Geoff's ) however I have been told NO repeatedly, justified
by concerns that we cannot increase scope and the spec has to be finished
and put out there. As a committee
we all agreed to not only close scope but close issues last month and while
I think Geoff's suggestions would be good to look at in terms of future
work I think its exactly that - future work.
Agreed,
though that shouldn't come as a surprise given the emails that have flown
back and forth.
My
concerns with these issues run a little deeper in that, during the last
month or two, the spec is being driven by the concerns of a number of companies
now specifically regarding their product direction and needs.
Again
agreed. We've held off on adding anything to the spec. at this late stage
that might be seen as product related and we're quite happy to continue
to do that.
The
spec should not be driven this way. If I could take you back a month or
5, there were certain accusation about made about BEA in the past, regarding
product direction driving the spec, when they tried to de-scope and simplify! The
spec HAS to
be driven by problems the industry is facing, and in my mind specifically
transactionality for Web Services, although I agree the bindings could
be expanded to support other type of scenarios.
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.
[Mark
Potts] Agreed I think I see more clearly now what Geoff is defining in
terms of need - that however does not mean it has to be included
in the scope of the spec at this time - or it could if deemed IMPERATIVE.
The
discussion that has started to take place over the last day or so has definitely
been useful in beginning to clarify what the problem is, but it's still
a long way off defining what the solution should be. If it has taken us
this long to get to this stage then who knows how long it will take to
come to a resolution. Should we delay the spec. just to get issue 89 in?
I'd prefer not to. I'd also prefer not to have to vote on it just in case
the vote is no and it gets dropped *and* it turns out to have been a useful
thing afterall.
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
Potts] I
sort of agree with Mark here as per my last set of comments - What
happens if IBM decide to join the party tomorrow and add their take on
transaction and the WSTx - do we change the spec again to accommodate their
concerns too! Oracle bring great value to the effort and credibility to
TC but we need to get something closed.
The
longer we wait, the greater the chance that BTP will lose relevance. We're
already starting to see this with IBM and MSFT. We are seeing this with
some customers who now could care less about BTP compatibility. Once we
have a standard we can at least point to it as *the only* standard out
there. We can't do that as yet.
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. 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>
> >
> >
|