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 ).
Geoff, there's no disputing that this issue
is open. What I would dispute is the difference between mentioning something is
coming and actually providing the committee with details on what that "thing"
is. This definitely did not happen until the last f2f as far as I can see. I
remember you mentioning JMS-interop a couple of times on teleconferences but
that's it. If you can point me at the tc minutes or archived emails that show
different I'd certainly stand corrected.
Mark.
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>
> > >
>
|