OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

business-transaction message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: [business-transaction] HPs position on BEAs proposal and theChoreology 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





[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC