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

[Pal Takacsi-Nagy <pal.takacsi@bea.com>]

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