Re: [business-transaction] HPs position on BEAs proposal and theChoreology response

[Mark Little <mcl@arjuna.com>]

>          I've been waiting for an opportunity to jump into this discussion
> that would not require an intimate knowledge of the technical state of the
> current specification and Mark's note seems to offer that opportunity.

Glad to offer assistance ;-)

> reasons. HP is the largest company to remain involved, and, with all due
> respect to my colleagues at HP, I don't believe that you have enough
market
> power to force the non-participants to comply with this technology.

Ed, you know as well as I do that HP are not in this to force people to do
anything. In our experience (HP, Bluestone, Arjuna) technology and code
talks more than white papers and vapour-ware do. Let's see what happens.

> As much
> as I would like it to be so, I don't believe that BEA can make this happen
> either. And, with all due respect to everyone else, you can't seriously
> believe that you can turn the market either.

Agreed. But we're not looking for instant take-up. And even if we simplified
to are hearts-content, no specification from this organisation can be
guaranteed to have the kind of take-up you might like.

>          1. Do we have critical mass among industry leaders which will
> guarantee success of the final product? - I suggest to you that the answer
> today is NO, regardless of the technical merits of the final product.

I think to answer this question correctly requires a crystal-ball. I know of
several (which I would call significant) players who may not be members of
the TC, but who have expressed interest in the BTP *as it currently stands*.
There is no way of knowing how this will playout at the moment. So, I would
suggest that the answer is WE DO NOT KNOW.

>          2. What is our plan to convince the non-participants that they
> should adopt this technology as opposed to something completely different
> and what is the prognosis for success?

Once we have a coherent and collective argument for BTP ourselves (i.e.,
once the specification is finalised) then we should be able to talk to
others.

>          3. Have we given them enough ammunition to reject the technology
> on technical grounds? I suggest the answer may be YES, because of the
> inherent complexity of our solution, regardless of whether or not it can
be
> technically justified. Remember this is NOT a technical argument.

Ed, can I confirm that you have in fact read the specification completely?
It's not complex at all if you understand the fundamentals of TP (which I
know you do), 2PC and interposition requirements. The protocol isn't
difficult to understand or explain (we've done this several times to people
who have had extremely different levels of transaction knowledge.) There is
an argument for a document to describe the protocol that is not the
specification, just as there is for telling people not to learn about
transactions from the OTS specification.

>          I'd suggest to the committee that we need a plan to get the rest
> of the industry on board and that complexity is not likely to be a
> successful strategy. Pal and I have been discussing this for a number of
> months, since it became clear that we would not have enough industry
muscle
> behind whatever comes out of the OASIS TC. It is in that spirit that Pal
> has made his simplification proposals. I can assure you that protecting
> BEA's current implementation is NOT our primary motive. We'd much rather
> have a successful standard emerge from an effort BEA initiated, even if it
> means product modifications, than a technically elegant solution that
> nobody implements. In fact, that's why we called this effort BTP, rather
> than our product technology which is called XOCP, because we expected
> things to change.

Glad to hear this. I think some of the problems we as a TC have had with
this issue is the confusing nature of the messages coming out of BEA with
regard to this simplification and your product. However, I don't want to go
back over old ground - let's move on.

>          1. Inter-business communication MUST be based on asynchronous
> protocols for business reasons. Companies will not allow other companies
to
> have a controlling influence on their business processes. This means
> loosely-coupled architectures, asynchronous messaging, and absolutely no
> hidden semantics between companies.

In our experience it's not as cut-and-dry as this. At the moment this is
definitely an area of shades of grey, rather than black and white. Hence the
fact that BTP is protocol agnostic.

> This is why I disagree with modeling
> BTP as a higher-level abstraction of traditional ACID transactions.

We're not doing this.

> Allison
> and I had a discussion on this topic at HPTS last week and basically
agreed
> to disagree. Another history lesson; it was not very long ago, we did the
> industry a massive disservice by selling RPC (and later CORBA and DCOM) as
> an extension of a language procedure call when in fact it was something
> completely different with considerably more failure modes.

Now this point I do agree with to a certain exten :-) It simplifies
programming of distributed systems when things work, but when they don't it
can be hell-on-earth to figure out without at least some good tool support.
Distribution transparency isn't a good thing in general IMO. However, that
is no reason to shelve RPC. If you know entities are distributed, and
program accordingly, it's still a good and valid paradigm.

> Most
> applications failed to consider this and as a result we have a lot of
> fragile applications deployed worldwide today which companies are
> struggling to maintain and extend.

This is a combination of the way in which RPC was initially sold (as you
correctly point out), but also with the way in which it is learnt. However,
I don't believe this is a point that BTP (or any single body) can address.
Let's keep being protocol agnostic.

>          2. The last version of the document I attempted to review, leaves
> the reader with the impression that we are extending classical
transactions
> to use internet protocols (perhaps because IIOP and DCOM won't go through
> the firewall).

Can you give some specific examples? This is certainly something we can
tidy-up.

> If anybody believes this, they are doomed to fail in the
> marketplace. BEA does not believe this. I don't think IBM believes this
> either and I know Microsoft does not believe this. A specification based
on
> this premise will never be accepted.

Agreed, and see my comment above. From the outset all of the initial
submissions have stated categorically that we are not providing ACID
transactions, or building on them. If you are getting this impression we
need to check the text. Thanks for bringing this up.

>          3. Regardless of the reasons, we don't have a critical mass of
> industry support for the specification today. That means we will need to
> sell the by-standers on whatever we produce. Does everyone believe that
the
> current specification could be sold to companies like Microsoft, IBM, and
> Oracle, all of whom have chosen not to participate?

See Alastair's comments about Oracle.

> Primers work when you have complex technology with wide industry support.
> XML Schema is perhaps the best example. I'd argue that it is overly
> complex, but with all the major industry heavyweights behind it, it will
> undoubtedly be accepted anyway. BTP does not start from the same position
> of strength. Do you really believe that can be fixed by a primer? I don't.

Again, I disagree. The concepts behind BTP are extremely simple. The
specification isn't the best place to understand how to use them, but
certainly how to implement the protocol. Hence the need for a "primer". I
believe that such a document will work, if people are prepared to read it.
[If you're going to be at the next OMG meeting I'd love to meet up and try
to convince you ;-)!]

> A true technicians perspective. As a community we tend to enjoy
> specifications with lots of bells and whistles. We have a long history of
> producing them in a myriad of different standards bodies. What matters is
> what customers will buy, I'd be much more convinced by market research
> which claimed to show that customers demand these features and are willing
> to pay for them.

Agreed. But since there's no negative market research either (e.g., saying
that they don't want/need them) we're in the dark either way. All we can do
is keep wheeling out our own statistics.

> I'm not sure I understand what this means, much less why it is a benefit.
> If you do not have acidity and isolation, the only way to "undo" is to
> execute a compensating action. I'd argue that in all cases, that is
> application-specific, so the most the system can do is to allow you to
> specify the compensating action when the work-flow is defined, keep track
> of the status durably, and trigger the compensation in the event of a
> failure. Achieving this simply is the goal. 2PC is a "how" and not an
> inherent advantage or disadvantage.

Let's address this from the bottom up. First of all, 2PC is essential when
coordinating multi-party "transactions" (ACID, business, ...) We have talked
to people in different parts of HP, our customers, people at conventions,
workshops, ..., (and I know other TC members have done so as well), and they
all agree that some form of consensus is essential. This need not be a 100%
guarantee (and I'll come to that later), but it needs to be present. Now, in
the presence of failures we can't guarantee consensus, just as we can't
guarantee ACID in the OTS. So, we allow heuristic-like effects, but we hope
these will be few and far between. Let's face it, if I have a service that
always generates a heuristic for every interaction, I'm pretty quickly going
to stop using it. But I need to accept the fact that sometimes failures of
disks happen, so I may not get all members of a protocol doing the same
thing.

Now, Two Phase Commit is used in places where Two Phase Completion would be
a better term. In the OTS, we use 2PC to mean backward compensation, and
hence the "rollback" operation. At one of the very first BTP meetings we all
agreed that backward compensation may be sufficient for some applications,
but not for others, and it's more likely going to be on a per-resource
basis. So, BTP uses 2PC(ompletion) to attempt to get consensus, and allow
individual participants to determine how they will attempt to restore their
states in the event that a cancel (c.f. rollback) occurs. This may require a
participant to fire off a complete workflow system to do, but that's a
back-end choice. I'd definitely agree that it's application-specific (which
should come as no surprise to you give the Activity Service work.)

So, in completion I'd like to reiterate that 2PC does not mean ACID Two
Phase Commit.

> I think I agree with this if what you mean is an industry-stand for
> completion which does not have inherent constraints in the time necessary
> for completion. Existing 2PC acid protocols have open completion
> specifications (in terms of required messages) but have time constraints
on
> their duration due to the side-effects of isolation.

Yes, that's exactly what I meant. In BTP I can begin a completion on a
Monday morning, and do other things within the scope of my business
transaction during the week, and based on that decide on Friday evening
whether I want to confirm (commit) or cancel (rollback). Obviously in taking
so long I run the risk of not being able to complete the business
transaction in the way I want (e.g., Amazon may well have sold the book I
reserved).

> I'd argue that in the web services context, a common API is the least
> important element. What we are after is interoperability, principally
> between two environments, J2EE and .NET. It's not possible to have a
common
> API between the two. .NET, by definition, has a common API. It may be
> possible to have a common Java API but that's secondary to having the
> interoperability protocol widely accepted.

XML is the common factor, and that is where we should aim. I did not mean a
common API across languages/environments. As long as the on-the-wire XML is
the same, who cares which language generated it?

> Nobody is suggesting that we cut down the specification to more closely
> match the original BEA specification. What has been suggested is reducing
> the scope to something which stands a better chance of being sold to the
> rest of the industry. If that could be done in a way that is incompatible
> with the initial BEA specification, it deserves consideration. Apparently
> nobody else is concerned about scope except us, so we have not seen such a
> proposal.

I disagree that no one else is concerned about scope. Quite the contrary.
From the discussions it should be obvious that we are all concerned about
scope! And from the votes it should be obvious that the majority want to
keep what we have in scope. This is not a complex protocol!

> What I want is a specification that has wide industry support. Whether is
> has 2PC, 1PC or 6PC is far less important than market acceptance. This is
a
> democratic process. The committee will do what the majority wants to do.
> Some of the companies that have walked away since the beginning have
> already made their judgements. That can't be a good sign. All I ask is
that
> we think of this before casting our votes.

Many of the companies you mentioned walked away after the very first
meeting. It could equally well be argued that they were put off by the
initial BEA submission, and not by what we have today.

> I actually looked at those slides which have their genesis in the BEA web
> services announcement at the time of our annual user conference this past
> February. This is after we shipped Weblogic Collaborate with a protocol we
> called XOCP which was a complete web services stack. We separated the
> transaction piece of the XOCP protocol and rename it BTP and it formed the
> basis for the original BEA submission to OASIS. Since we had a reasonable
> expectation that the ultimate standard (not visible in February
obviously),
> might bear some similarity to our Collaborate implementation, we
> highlighted our intention to make our BTP a standard. We also indicated
our
> desire to move to SOAP and/or ebXML TRP to replace those levels of the
> Collaborate XOCP stack. Incidentally, if he really believes there is that
> much difference between what we have now in the OASIS spec and what BEA
> called BTP in February, he gives credibility to the argument that the
scope
> may well have gotten out of hand.

Not at all, unless you think BEA had the scope right in the first place.
This is a subjective argument (as is anything *anyone* can say for or
against it!)

Mark.

----------------------------------------------
Dr. Mark Little
Transactions Architect, HP Arjuna Labs
Email: mark@arjuna.com | mark_little@hp.com
Phone: +44 191 2064538
Fax  : +44 191 2064203