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

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

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