Fw: Re: [business-transaction] HPs position on BEAs proposal and theChoreology response

[Sanjay Dalal <sanjay@bea.com>]

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
**************************************************************