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: Re: [business-transaction] HPs position on BEAs proposal andtheChoreology response


I would like to clarify one thing: the idea of conformance profiles actually
dates back to the June face-to-face meeting of the committee in London. I have
no idea whose idea it was -- I think it might have been James who came up with
this, in fact.

All that we in Choreology have done in this recent debate is concretize and make
specific the existing agreed position of "vertical" partial conformance
(implement which sides of the which interop relationships?), and add the
capability ("horizontal") partition: Atoms or Cohesions + Atoms.

This combination makes it completely straightforward for different vendors to
take on those parts of the spec they see as having value/attracting market
interest. In particular, no-one is compelled to implement coordination hubs
(heavily pushed for by BEA, HP, Bowstreet and others at the May meeting in Mt
Laurel), nor cohesions.

Put another way: it enables BEA's small is beautiful view to be enabled by a few
strokes of the specifier's pen, rather than by weeks of sprawling brawling.

According to me, the real issue currently in debate is therefore: "what's wrong
with conformance profiles?"

Alastair

PS A point in our response to BEA, page 8. The diagram shows one terminator, one
coordinator, and one inferior. In such a case one could clearly use single-phase
commit all the way down to the inferior, avoiding a full two-phase exchange
between coordinator and inferior. If > 1 inferiors are present then the full
exchanges are required.

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.
>
> 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>
begin:vcard 
n:Green;Alastair
tel;cell:+44 795 841 2107
tel;fax:+44 207 670 1785
tel;work:+44 207 670 1780
x-mozilla-html:FALSE
url:www.choreology.com
org:Choreology Ltd
version:2.1
email;internet:alastair.green@choreology.com
title:Managing Director
adr;quoted-printable:;;13 Austin Friars=0D=0A;London;;EC2N 2JX;
fn:Alastair Green
end:vcard


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


Powered by eList eXpress LLC