I use
outlook and have no such problems.
No problems encountered here. But I don't use
Outlook, so can't say for sure.
Mark.
----- Original Message -----
Sent: Sunday, April 21, 2002 1:39
AM
Subject: RE: [bt-spec] FW: Issue
89
I'm trying to get caught up with this thread. For some reason
the last n (approx 4 - 5) emails from Geoff
are causing Outlook to crash for me. I'm gleaning what I can
from Mark's side of the conversation. Is this
a
problem with my system only or have others had any
problems?
Thanks,
=bill
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>
> > >
>
|