|
Dear Ed,
Lots of good premises, but wrong and passive conclusions, in my view.
On the subject of vendor acceptance, it was interesting that Oracle's
rep joined as a full voting member at the quorate phone meeting just concluded,
and that Sun also have appointed a representative to replace Fred Carter
(who left Sun recently).
I was encouraged by support for JSR 156 (signed by HP, IBM, IONA and
Choreology). I think your low estimation of the importance of a Java API
is sorely misguided, from the standpoint of ease of use and adoption.
The BEA motion to remove cohesions was just voted down 9 - 3 with one
abstention. No company other than BEA voted for it.
I think the market will decide these issues, and I'm hoping customers
will get a chance to vote with their feet and cash for or against the features
developed in the work of the TC over these last months of hard collective
work.
Yours,
Alastair
Sanjay Dalal wrote:
On
behalf of Ed Cobb who is not able to post to BTP mailing list....
>Date: Thu, 25 Oct 2001
12:59:31 -0700
>To: Mark Little <mcl@arjuna.com>,
btp
><business-transaction@lists.oasis-open.org>
>From: Edward Cobb <ecobb@bea.com>
>Subject: Re: [business-transaction]
HPs position on BEAs proposal and the
>Choreology response
>Cc: Mark Little <m.c.little@ncl.ac.uk>,
pal Takacsi-Nagy <pal.takacsi@bea.com>
>Bcc: dorchard, dietzen
>
>
I've been waiting for an opportunity to jump into this discussion
> that would not require
an intimate knowledge of the technical state of
> the current specification
and Mark's note seems to offer that opportunity.
>
Let me begin by bringing everybody up to speed on how and why BEA
> started this effort in
OASIS in the first place and why I've been
> concerned about where
we seem to be heading for some time.
>
Some of you may be aware of a private club called XAML. XAML was
> founded by Bowstreet,
IBM, Oracle, Sun and HP to develop web standards
> for transactions. As a
result of our efforts in what was then called
> Weblogic Collaborate,
BEA believed it had useful technology to contribute
> in this space and saw
value in doing so in an open industry forum. We
> approached XAML and were
rebuffed and, as a result, we sought an
> alternative venue. But
we were realistic in our assessment of what it
> might take to be successful
so we were to determined to get a critical
> mass of key players engaged
in the OASIS effort in order to have some
> probability of success.
We convince three of the XAML parties to support
> the OASIS effort and were
ecstatic when the fourth (IBM) and then
> Microsoft both signed
up for the technical committee. We also understood
> why Oracle did not (for
non-technical reasons) so we thought we had the
> right group of vendors
to be successful, even if OASIS was less than an
> optimal venue.
>
For a variety of reasons, that membership has deteriorated. It
> turned out that somebody
from IBM India signed up for IBM and never
> participated. Even if
he had, it was obvious that he'd have no influence
> on what IBM products might
have done in this space. Microsoft showed up
> initially and, IMO at
least, concluded that this effort was not relevant
> and quietly disappeared
from the scene. Sun pulled backed for personnel
> reasons. HP is the largest
company to remain involved, and, with all due
> respect to my colleagues
at HP, I don't believe that you have enough
> market power to force
the non-participants to comply with this
> technology. As much as
I would like it to be so, I don't believe that BEA
> can make this happen either.
And, with all due respect to everyone else,
> you can't seriously believe
that you can turn the market either.
>
One of the most difficult things for technical people to accept
> is that the best technology
does not always prevail in the marketplace.
> Many of us enjoy knocking
Microsoft, but we'd all have to admit they have
> been eminently successful
in spite of valid technical criticisms of their
> technology. I personally
helped developed a particularly elegant
> multi-language component
model for CORBA, which will probably never see
> the light of day because
the market voted for Java and J2EE. I really
> believe we need to ask
ourselves the same kind of questions about BTP.
>
1. Do we have critical mass among industry leaders which will
> guarantee success of the
final product? - I suggest to you that the
> answer today is NO, regardless
of the technical merits of the final product.
>
2. What is our plan to convince the non-participants that they
> should adopt this technology
as opposed to something completely different
> and what is the prognosis
for success?
>
3. Have we given them enough ammunition to reject the technology
> on technical grounds?
I suggest the answer may be YES, because of the
> inherent complexity of
our solution, regardless of whether or not it can
> be technically justified.
Remember this is NOT a technical argument.
>
I'd suggest to the committee that we need a plan to get the rest
> of the industry on board
and that complexity is not likely to be a
> successful strategy. Pal
and I have been discussing this for a number of
> months, since it became
clear that we would not have enough industry
> muscle behind whatever
comes out of the OASIS TC. It is in that spirit
> that Pal has made his
simplification proposals. I can assure you that
> protecting BEA's current
implementation is NOT our primary motive. We'd
> much rather have a successful
standard emerge from an effort BEA
> initiated, even if it
means product modifications, than a technically
> elegant solution that
nobody implements. In fact, that's why we called
> this effort BTP, rather
than our product technology which is called XOCP,
> because we expected things
to change.
>
Since the effort started, I have been unable to keep up with the
> evolution of the technology
but I will offer several technical comments
> which I believe the committee
must consider, regardless of whether some
> of you consider this to
be old ground.
>
1. Inter-business communication MUST be based on asynchronous
> protocols for business
reasons. Companies will not allow other companies
> to have a controlling
influence on their business processes. This means
> loosely-coupled architectures,
asynchronous messaging, and absolutely no
> hidden semantics between
companies. This is why I disagree with modeling
> BTP as a higher-level
abstraction of traditional ACID transactions.
> Allison and I had a discussion
on this topic at HPTS last week and
> basically agreed to disagree.
Another history lesson; it was not very
> long ago, we did the industry
a massive disservice by selling RPC (and
> later CORBA and DCOM)
as an extension of a language procedure call when
> in fact it was something
completely different with considerably more
> failure modes. Most applications
failed to consider this and as a result
> we have a lot of fragile
applications deployed worldwide today which
> companies are struggling
to maintain and extend.
>
2. The last version of the document I attempted to review, leaves
> the reader with the impression
that we are extending classical
> transactions to use internet
protocols (perhaps because IIOP and DCOM
> won't go through the firewall).
If anybody believes this, they are doomed
> to fail in the marketplace.
BEA does not believe this. I don't think IBM
> believes this either and
I know Microsoft does not believe this. A
> specification based on
this premise will never be accepted.
>
3. Regardless of the reasons, we don't have a critical mass of
> industry support for the
specification today. That means we will need to
> sell the by-standers on
whatever we produce. Does everyone believe that
> the current specification
could be sold to companies like Microsoft, IBM,
> and Oracle, all of whom
have chosen not to participate? If not, what are
> we going to do about it?
I'd suggest reducing the scope is one possible
> alternative. I'm willing
to listen to other proposals.
>
All this discussion about process and revisiting decisions made
> previously does nothing
to address the above issues, which I believe are
> more important than the
actual technical ones. So rather than continue to
> throw stones at other
peoples motive, I suggest a serious discussion of
> these issues is in order.
>
Additional comments included below.
>At 01:13 PM 10/24/2001
+0100, Mark Little wrote:
>
>>This is a followup to
my previous email concerning BEAs proposal that we
>>will be voting on next
Friday (which I still won't be able to attend, and
>>vote NO to). We agree
that the current specification is more complex than
>>the original BEA submission
to BTP. We also agree that as a tutorial on how
>>to use BTP the specification
doesn't work, but then that's not really its
>>job. On this note, we
would definitely like to see a Primer aimed at
>>simplifying the introduction
to BTP for people.
>
>Primers work when you have
complex technology with wide industry support.
>XML Schema is perhaps the
best example. I'd argue that it is overly
>complex, but with all the
major industry heavyweights behind it, it will
>undoubtedly be accepted
anyway. BTP does not start from the same position
>of strength. Do you really
believe that can be fixed by a primer? I don't.
>
>>We have a significant
Web Services division within HP, and many of them know
>>about BTP in one way or
another. This is seen as a key component to the
>>evolving WS environment,
and both our WS division and customers are keen to
>>get their hands on a BTP
implementation. From our experiences, people do see
>>BTP as a complex protocol
initially, but once explained they quickly come to
>>understand the benefits
it offers to loosely coupled services. It's true
>>that not all of these
people (not the majority I hasten to add) will want to
>>use all of the features
of BTP, at least initially. However, it's also true
>>that those who do not
need them now tend to agree that they can see a use
>>for them in the future
and are excited that they are present.
>
>A true technicians perspective.
As a community we tend to enjoy
>specifications with lots
of bells and whistles. We have a long history of
>producing them in a myriad
of different standards bodies. What matters is
>what customers will buy,
I'd be much more convinced by market research
>which claimed to show that
customers demand these features and are willing
>to pay for them.
>
>>The important aspects
that distinguish BTP from other protocols that have
>>been proposed are:
>>
>>(i) two-phase completion
that does not imply a specific compensation
>>protocol to achieve consensus.
>
>I'm not sure I understand
what this means, much less why it is a benefit.
>If you do not have acidity
and isolation, the only way to "undo" is to
>execute a compensating
action. I'd argue that in all cases, that is
>application-specific, so
the most the system can do is to allow you to
>specify the compensating
action when the work-flow is defined, keep track
>of the status durably,
and trigger the compensation in the event of a
>failure. Achieving this
simply is the goal. 2PC is a "how" and not an
>inherent advantage or disadvantage.
>
>>(ii) an open completion
protocol, that gives the flexibility to begin
>>completion at one time,
and finish it later.
>
>I think I agree with this
if what you mean is an industry-stand for
>completion which does not
have inherent constraints in the time necessary
>for completion. Existing
2PC acid protocols have open completion
>specifications (in terms
of required messages) but have time constraints
>on their duration due to
the side-effects of isolation.
>
>>Cohesions and atoms combine
to create a powerful paradigm shift, and one
>>which can be explained
quite simply to users. There is an argument to be had
>>about complexity, but
the BTP specification is not meant to be read by
>>users. OK, SOAP is relatively
simple, but if I had to write the
>>specification for SOAP
taking into account *all* of the layers that make it
>>up, including TCP/IP,
ICMP, routing, ... it would be a complex
>>specification. We're not
intending people to use the BTP message set
>>directly. Until (and unless)
there is a common API for each implementation
>>language, vendors will
come up with their own to abstract away SOAP, XML and
>>BTP messages. Essentially
all the BTP specification is concerned with it the
>>on-the-wire protocol.
>
>I'd argue that in the web
services context, a common API is the least
>important element. What
we are after is interoperability, principally
>between two environments,
J2EE and .NET. It's not possible to have a
>common API between the
two. .NET, by definition, has a common API. It may
>be possible to have a common
Java API but that's secondary to having the
>interoperability protocol
widely accepted.
>
>
>>We do not agree that we
should take the current specification and cut it
>>down into something that
resembles the original BEA specification. Neither
>>do we agree that we should
remove cohesions, factories, redirection, and
>>anything else that affects
interoperability and improves the chances of
>>removing vendor lock-in.
We're in the business of open standards, and I
>>would hope that the majority
of others on the committee would agree.
>
>Nobody is suggesting that
we cut down the specification to more closely
>match the original BEA
specification. What has been suggested is reducing
>the scope to something
which stands a better chance of being sold to the
>rest of the industry. If
that could be done in a way that is incompatible
>with the initial BEA specification,
it deserves consideration. Apparently
>nobody else is concerned
about scope except us, so we have not seen such a
>proposal.
>
>>However, the Choreology
proposal of adding conformance profiles is something
>>we like. If people don't
want to support cohesions, for example, then they
>>needn't. Obviously at
the moment that would still be possible without
>>conformance profiles (CPs),
but such a vendor wouldn't be able to say they
>>were OASIS BTP compliant.
It would be preferrable to have several levels of
>>conformance (I'm not sure
about the number) and then let vendors say that
>>they are "Level X" compliant,
and still have interoperability on different
>>levels. I'd like to see
this approach adopted, and people working together
>>to come up with a representative
set of conformance levels that we can then
>>add to the specification.
>
>I've seen this profile
game played over and over again, usually as a way
>of making all the participants
happy without actually changing anything.
>Most people won't get to
the conformance chapter. They'll look at the
>whole package and make
their judgement based on everything available. I
>would observe, however,
that if it is possible to define conformance
>profiles for the complete
package, then it is equally possible to cut back
>the release 1.0 level of
the specification with certain knowledge that
>additional features could
be added in a release 2.0.
>
>
>>But I say again: as far
as coming up with a simplified protocol that only
>>has one-phase or even
two-phase completion, HP is firmly against this. What
>>we want is to move ahead
with the protocol and adopt it before the end of
>>the year so that we can
start to get traction within the industry for this
>>protocol. If we continue
to flounder around discussing minutiae or having
>>votes on all of our previous
decisions then we will never get the
>>specification out. A more
cynical person than I may think that that is
>>perhaps what some members
of the committee want, but I'd prefer to give the
>>benefit of the doubt!
We need to set a dealine *now* for the final version
>>of the specification,
and keep to it.
>
>What I want is a specification
that has wide industry support. Whether is
>has 2PC, 1PC or 6PC is
far less important than market acceptance. This is
>a democratic process. The
committee will do what the majority wants to do.
>Some of the companies that
have walked away since the beginning have
>already made their judgements.
That can't be a good sign. All I ask is
>that we think of this before
casting our votes.
>
>>When the specification
is finished, it is then up to each member company of
>>the committee to determine
whether or not it can accept it. Obviously
>>companies that know that
there is no way they can ever agree with BTP can
>>decide to leave the committee
at any point. After all, this is a democratic
>>body, and no one is being
forced to participate.
>>
>>Finally, I'd like to ask
for some clarification on a point Jim Webber raised
>>the other day. Can someone
please tell me what "BEA BTP" is in relation to
>>OASIS BTP, and why product
documentation and marketing material imply that
>>there is a one-to-one
mapping? There is not, and if it continues this will
>>only cause further confusion
in the market.
>
>I actually looked at those
slides which have their genesis in the BEA web
>services announcement at
the time of our annual user conference this past
>February. This is after
we shipped Weblogic Collaborate with a protocol we
>called XOCP which was a
complete web services stack. We separated the
>transaction piece of the
XOCP protocol and rename it BTP and it formed the
>basis for the original
BEA submission to OASIS. Since we had a reasonable
>expectation that the ultimate
standard (not visible in February
>obviously), might bear
some similarity to our Collaborate implementation,
>we highlighted our intention
to make our BTP a standard. We also indicated
>our desire to move to SOAP
and/or ebXML TRP to replace those levels of the
>Collaborate XOCP stack.
Incidentally, if he really believes there is that
>much difference between
what we have now in the OASIS spec and what BEA
>called BTP in February,
he gives credibility to the argument that the
>scope may well have gotten
out of hand.
>
>
>>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
>>
>>
>>
>>
>>----------------------------------------------------------------
>>To subscribe or unsubscribe
from this elist use the subscription
>>manager: <http://lists.oasis-open.org/ob/adm.pl>
>
>**************************************************************
>Edward Cobb, Vice President,
Architecture & Standards
>BEA Systems, Inc., 2315
North First St., San Jose, CA 95131
>Tel: 408-570-8264 / Fax:
408-570-8942 / Mobile: 408-464-0733
>E-mail: ed.cobb@bea.com
>**************************************************************
**************************************************************
Edward Cobb, Vice President,
Architecture & Standards
BEA Systems, Inc., 2315
North First St., San Jose, CA 95131
Tel: 408-570-8264 / Fax:
408-570-8942 / Mobile: 408-464-0733
E-mail: ed.cobb@bea.com
**************************************************************
|