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! 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.
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. 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.
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.
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>
> >
>
>