[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [business-transaction] HPs position on BEAs proposal and theChoreology response
Dear collegues, I would like to suggest that we stop accusing each other's companies as part of our discussions in the OASIS mailing list. I would also like to suggest that we keep this mailing list to technical discussions. I think that the BEA's proposal tried to stick to this principle. Along these lines I would like to re-iterate that according to my belief the current specification is too complex for wide adoption. I would like to point out SOAP as a positive example of simplicity. The SOAP 1.1 specification is only about 50 pages long. The current BTP spec draft is over 100. Thanks: Pal > -----Original Message----- > From: Mark Little [mailto:mcl@arjuna.com] > Sent: Wednesday, October 24, 2001 5:14 AM > To: btp > Cc: Mark Little > Subject: [business-transaction] HPs position on BEAs proposal and the > Choreology response > > > 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. > > 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. > > 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. > > (ii) an open completion protocol, that gives the flexibility to begin > completion at one time, and finish it later. > > 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. > > 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. > > 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. > > 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. > > 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. > > 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> >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC