Re: [business-transaction] HPs position on BEAs proposalandtheChoreology response

[Alastair Green <alastair.green@choreology.com>]

Dear Pal,

I think I answered your main contentions in advance in my document. The overlap between these two "protocols" is so nearly complete (on the core Superior:Inferior relationship) that the second specification for Cohesions would occupy two or three sheets of paper. If you really want to reduce the page count, go after the Coordination Hub. Personally, I think both are good and useful, and there is no well-motivated reason to drop either.

Your proposed layering feels artificial. Atoms and Cohesions belong in the same specification (as they are so intimately related). Allow partial conformance, and nobody is "forced" to do anything. Atoms for Atomists. (What a peculiar conception this "forcing" is, by the way. It reminds me of the Monty Python sketch about the Spanish Inquisition; "Oh no, not the comfy chair").

And if the terms offend, change the names. No-one here is bigoted about the nomenclature.

I've been searching for an analogy on this layering business. This is the best I can do for now:

SOAP does three things. Well Don Box says that it does two things:

"Most of what the 4Q1999 SOAP specs did was simply illustrate how to model typed references and arrays in the XSD type system. Period. We also had a model for adding optional/mandatory protocol headers (a la CORBA's service contexts and DCOM's ORPCTHIS/THAT), but that was it."

("A Brief History of SOAP", http://www.develop.com/dbox/postsoap.html)

I'd say SOAP also defines an RPC convention. (See another thread on bt-spec.)

OK, so we have encoding rules, payload composition (Header/Body, standard envelope) and RPC conventions.

In the "simple is beautiful" view of specification writing, we should start with SOAP Spec 0 (extensions to XSD). Upon which we layer SOAP Spec 1 (payload organization). Upon which we layer SOAP Spec 2 (RPC). It sure is layered. And each spec will be shorter than the last. This way we avoid forcing RPC down the throat of those looking to send oneways, and look after those who want typed arrays but couldn't be arsed about sending messages.

You cannot approach this question of "what should be in a protocol" in the abstract. Almost anything can be layered in some fashion. Why the Atom-Cohesion layering? Why not decouple the Superior-Inferior from the Client-Decider? Why not layer BTP on a communications-protocol abstraction layer?

Finally on length. There's an old market-trader's saying "Never mind the quality, feel the width". Usually this is taken to mean "feel the breadth". Here we are being asked to judge by the narrowness, the slimness. How about judging its intrinsic worth? Better still, why not let the customers decide? They can vote with their feet and their cash for or against Cohesions. Let's give them that chance.

Yours,

Alastair

PS. I thought Tyler Jewell's exposition of cohesions in his article for Web Services Journal was very clear, and showed how easy it is (if you are a talented BEA evangelist) to explain this useful concept.

Pal Takacsi-Nagy wrote:

Hi all,

just to clarify one thing. Our proposal was not against the Cohesion concept
per se, but it was against coupling Cohesions with Atoms in the same
specification and forcing concepts on people, like Superior/Inferior, who
otherwise would just be interested in Atoms. That's why I don't agree with
the compliance profile approach, since it does not eliminate the coupling.
One compromise can be to produce 2 specifications: BTP - Atoms and BTP -
Cohesions. And no coupling between the two. This approach is in line with
the layered protocols design principle. HTTP does not have any special
coupling with SOAP and vica versa. And that's why we all like and use them.

Pal

> -----Original Message-----
> From: Cho, Pyounguk [mailto:PCho@iona.com]
> Sent: Wednesday, October 24, 2001 3:39 PM
> To: 'Alastair Green'; Mark Little
> Cc: btp
> Subject: RE: [business-transaction] HPs position on BEAs proposal and
> theChoreology response
>
>
> Hi Alastair and Mark,
>     I am strongly against dropping the Cohesion concept out of the current
> BTP spec. And I agree with you that introducing conformance profiles will
> give options to the vendors as to  what kind of BTP services are available
> in their products.
>
> Best,
> Pyounguk
>
> -----Original Message-----
> From: Alastair Green [mailto:alastair.green@choreology.com]
> Sent: Wednesday, October 24, 2001 7:37 AM
> To: Mark Little
> Cc: btp; Mark Little
> Subject: Re: [business-transaction] HPs position on BEAs proposal and
> theChoreology 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>
>
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>
>

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