Re: [business-transaction] HPs position on BEAsproposalandtheChoreology response

[arkin <arkin@intalio.com>]

Hi all,

I have been following this discussion for quite a while.

I am looking at the BTP specification from the perspective of the BPML
specification, and one possible implementation. Since BPML can describe
the actions that make up a transaction, and where to draw transaction
boundaries within an encompassing process, while BTP specifies the
process for achieving reliable completion of the transaction, we see a
strong connection between these two specifications.

In BPML we distinguish between atomic transactions and extended
transactions. We expect BPML-compliant implementations to use BTP,
alongside OTS, X/Open XA and TIP, for the purpose of demarcating and
coordinating atomic transactions. We would like to refer the reader of
the BPML specification to the relevant transaction protocol
specification that discusses atomic transaction, and would favor BTP as
the source for concepts and terminology.

At the moment BPML does not deal with cohesive transactions, this is
reserved for a later version. Specifing support for atomic transactions
within BPML and assuring vendor conformance over four different
protocols is not a trivial manner, and we would like to complete this
part of the specification before proceeding.

It is extremely hard to reference the atom part of the BTP specification
as it currently stands, since the BTP specification is not broken into
two separate layers. To understand the atomic behavior, one must talk
about concepts and messages that are not relevant in the scope of an
atomic transaction, even if one is not required to implement them
(assuming conformance levels).

Unfortunately, that means that we must still rely on OTS and/or X/Open
XA as the primary source for defining atomic transactions.

It would be extremely helpful if a complete, self-contained discussion
of atomic transactions and specification of all actors, messages and
behaviors that only pertain to atoms was introduced as a standalone
document.

We will find this approach extremley helpful in building specifications
that leverage the work done on behalf of BTP, and would in fact allow us
to rely on the BTP specification for introducing terminology and
concepts.

In order to support this view, I would like to introduce as evidence
related specifications where the same approach has been taken. One is
the SOAP 1.2 specification, which has been broken off into two parts,
one dealing with the messaging framework [1] and one dealing with
encoding and protocol bindings [2]. The other is the XML Query
specification which consists of four different documents. XQuery itself
is fully specified in one document [4], while the XML syntax for XQuery
(XQueryX) is covered in another document [3]. (The other two specs deal
with the underlying model and function library)

I am fully aware that the separation into two documents will have an
affect on the work done by members of this group. At the very least it
will require the management of two separate documents. However, I urge
you to consider such a separation, for the benefit of a future body of
work that will rely on the BTP specification.

arkin

[1] SOAP Version 1.2 Part 1: Messaging Framework 
http://www.w3.org/TR/soap12-part1/
[2] SOAP Version 1.2 Part 2: Adjuncts 
http://www.w3.org/TR/soap12-part2/
[3] XML Syntax for XQuery 1.0 (XQueryX)  http://www.w3.org/TR/xqueryx
[4] XQuery 1.0: An XML Query Language  http://www.w3.org/TR/xquery/


Alastair Green wrote:
> 
> 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>

-- 
----------------------------------------------------------------------
Assaf Arkin                                          arkin@intalio.com
CTO,  Intalio Inc.                                     www.intalio.com
The Business Process Management Company                 (650) 345 2777