[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [business-transaction] Response to Ed Cobb: Market & technical issues
|
Dear Ed,
I've considered your mail very carefully. I want to concentrate on the big issues, not the BTP minutiae. A "market to be turned" or a market to be made? The comparision between CORBA Components and BTP is misleading. CORBA Components (you'll have to forgive me here) was an extraordinary attempt to resist the already-apparent onrush of J2EE, strangely led by the company that had invented Java app servers, BEA. It might fairly have been labelled "doomed to failure", certainly by the time it was adopted. BTP has no current direct competitor, let alone an established and accepted competitor. BTP addresses an area which in the April W3C workshop was put on the "waitlist". There is no standard or accepted way of doing compensation-based multi-party outcome coordination. The models proposed for compensation (such as Open Nested Transactions, as conventionally understood) are not widely accepted or reflected in products, let alone in standards. There is a (wrong) view that a protocol in this space is actually unnecessary, and can be substituted for by workflow/business process definitions (like XLANG or WSFL) This lack of clarity, or definition, or accepted orthodoxy, signals a market that is to perhaps to be made, and not one to "turn". Hence my comment that your conclusions seem passive. You are rather critical of BTP, but it is not clear what you would replace it with, or how precisely the replacement would differ from BTP. Do you believe there is a place for a coordination protocol at all? Or do you perhaps believe that such a protocol can only usefully be authored by Microsoft and IBM? Our view is that the whole space of commercial collaboration (reflecting business contracts into software contracts, for inter-organizational commerce) is very open, and that its future shape will partly be determined by the paths of progress of Web Services. BTP (the coordination problem) is only one part of this picture. ebXML looks too slow and too large a suite to make it as an overall standard, although there are many parts and facets (and much very important thinking) that will find their way into commercial software in real use. So, we are in the early days, not in a mature market. In this context, there is worth in creating an entry-level standard which provides a key piece, low in the stack, that systems-builders can take advantage of. We cannot know how things will turn out (there are no "guarantees of success", to use your term). I think you place the pivot point far too close to caution and pre-positioning, and too far away from action, initiative and leadership. This is disappointing. BEA seemed to cut the Gordian knot of XAML, and to make a good initiative in the right area with the sponsorship of OASIS BTP. I think you are now in a posture which carries with it the danger of withdrawing from the field before the battle for the market even starts (if it is to be that). I hope I am proved wrong (I'm making a general point about the future and the wider market, not referring to the BTP committee wars). Our slant on history The relevance of what follows is this: I agree with you about markets and technology. You're misapprehending if you see the hand of technophiles lovingly polishing the third tier of bells. Our founders, Peter and I included, left HP/Bluestone at the beginning of this year, almost to the day that the BTP initiative was announced, having decided against a transition into HP. Our immediate prior background was working on the productization of the Arjuna JTS. Collectively we have many years of experience of distributed transactional environments, with threads running back through OTS and TIP to OSI/TP, CCR, Encina, Digital ACMS and all manner of networking and RPC mechanisms, often in the direct context of application infrastructure and deployment. We founded our company with some very tentative, general views, and with a very open mind. Our "CORBA Components" was called "nested transactions" -- a losing proposition which had burnt into our minds the pointlessness of flogging dead horses rejected by the market. We had in our mind a diagram that showed business process as a private matter for trading partners, and interchanges between them which escalated in certainty and value, a "condensation of certainty" as Peter put it. We had in mind the powerful, and unexploited, exactly-once property of transactional RPCs (allowing coordinated deposits of data on both sides). We thought XML was a fact, and Web Services likely to make it because they were Microsoft's answer to J2EE. And we thought that everything to do with collaboration was tied to security, but that hard "authenticate every principal" security is very hard to administer easily. We had as a backdrop: let's be serious about autonomy and contract-defined computing. What does that really imply in an inter-org world? We also figured that old-school transaction protocols were overly tied to only one specific carrier protocol. Our first month was spent (aside from accounts packages and equipping an office) on a discussion about what we called "cohesions" (looser than ACID). a) Is there any reason to factor out a coordinated outcome protocol? Can it all be done with workflow? No. The coordination problem is too complex to handle at an application level (especially the error cases), and is a good fit for protocolization because it is so general, and can be fitted as a rig underneath any visible "happy path" trading or application protocol. b) Can you (usefully) escape 2PC? No, 2PC is a good 90% case. You ask, you instruct. There will be special cases, but two-phase outcome as Sazi puts it, is good enough, most of the time. State undos are special cases of compensations. Everything in 2PC is compensations. The contract between the work-requester and the work-provider defines the relationship between prepare (do provisional work), confirm (give it final effect) and cancel (controvert it in some way). c) Can we use existing work such as the OMG Activity Service? Yes, but it's CORBA-centric, and more fundamentally, it standardizes how to do state-shifting protocols, and we felt that at entry level, there was only going to be one. Better suited for bespoke colloborative protocols, not a useful model for BTP. We also started to design a use-case scenario for cross-market maker trading via competitive guaranteed quotes for stocks and related options, with time limits characteristic of real-time trading. This is available for view in the demo on our web-site (www.choreology.com). It is, in our view, typical of any multi-party trading scenario, including less time-critical examples, such as supply-chain procurement. Through this case study came the concept of cohesions, which is a simple tool for making failure recoverable decisions about which competing offers you accept. (The more sophisticated edition, that allows rolling confirmation was rejected by us as overly complex for a first cut.) Autonomy and Shared State I absolutely agree with you that the inter-organizational trading world is characterized by autonomy. Companies will control their own inventory, their own business processes etc etc. But that autonomy is not unbounded. It is qualified by two factors -- inequality and interdependence. Seemingly autonomous entities are in fact deeply dependent on their suppliers and their customers. And not all business relationships are equal. VW or Tesco or GM can tell their suppliers exactly how to do business with them ... or they will not do business at all. These facts are expressed in implicit or explicit contractual terms and conditions and procedures that underpin trade. All of these factors conspire to constrain and channel the theoretically absolute autonomy of corporate persons, just as we individuals cannot escape our social existence. You say that there must be "absolutely no hidden semantics between companies". Well, yes and no. When I place a purchase order I usually enter into an agreement on standard terms and conditions. I certainly observe a definite protocol in terms of which bits of paper I exchange, in what order, and with what levels of obligation and certainty. There are certainly shared semantics, shared state transitions taking place. I don't know or care which accounting package my supplier uses, but I do care that they generate an invoice and that it states the correct payment terms, that we have previously agreed. And much of that may by custom or practice, or by longevity of the relationship, be assumed, implicit, "hidden" in that sense. They may also be "hidden" in a system protocol, while fully visible in the business understandings/contracts which that protocol is used to assist. It is critical to distinguish between privacy of implementation (which
is a business requirement) and non-sharing of state (which is the antithesis
of a business requirement). You cannot trade if you
Take any trading protocol. Messages are exchanged and contractually-defined reactions and processes with defined outputs occur.At some point in the process potential becomes actual, and a deal is done. At that point all parties (two or more) need to interlock to assure a common outcome. You can ignore this problem, and fix it manually when it goes wrong, which is a cost-benefit calculation. It is harder to ignore when the trade is done system-to-system, and it is harder to ignore when the manual repair involves cross-company collaboration. The manual repair approach does happen (e.g. among exchange members) because of the pressing need to work together through the exchange over the long run, but it is sub-optimal, and does not scale well. The technical expression of commercial inter-dependence is the fact
that there cannot be absoute asynchrony, which would amount to non-communication.
The exchanges between companies' systems will often occur asynchronously
(buffered by queues, based on one way messages). I absolutely agree, (although
Web Services and RPCs at the current stage of development tend to go hand-in-hand).
BTP is defined in terms of one-way messages, and is agnostic to the means
of communication (both
But when push comes to shove, one cannot avoid the need for acknowledgement of successful processing in order to create a guaranteed common outcome (coordination). The interlock may not be long-lived at all; it does not imply locking up inventory in an ACID manner; but it does have to happen. Analogy. In a complex M&A transaction the lawyers and business people on all sides work away, occasionally exchanging messages and drafts, hammering out a deal. Eventually, after aeons have passed, the deal is completed or closed, which involves "simultaneously" signing lots of bits of paper, which interlock with each other, and which form a mutually interdependent edifice. That moment involves either physical co-location, or open phone and fax lines all round, with signatures being observed and lawyers' undertakings being recorded, or in the future world, some kind of coordinated action by various computer systems. The asynchronous deal-hammering culminates in a shortish coordinated, interlocked set of actions. Other use cases show much longer-lived interactions. The general rule is: the longer-lived the interaction the more likely it is to operate on approximate or stale or reference data. But none of that affects the need to coordinate in the end. What's the Technical Alternative to Two-Phase Outcome? From the start of BTP Choreology opposed the use of the term "business transaction", because it creates or aids the mistaken perception that we are retreading ACID for the firewall-penetrating SOAP protocol. We have acceded to the majority view of the committee on this point. I think it is important to factor our this type of presentational aspect to get the discussion clear on the underlying requirement. I also think that this kind of problem is important at another level because first impressions are abiding impressions. On the strictly technical level, I suspect that there may be a failure to see beyond the ACIDic equation "two-phase commit equals two-phase locking" . The implicit conclusion is maybe the rejection of a "transactional" protocol, in favour of something else altogether (although what that might be is unstated). BTP is based on two axioms.. 1. Multi-party coordination which can survive failures of the networked system to achieve a common result (do, or don't do) requires a two-phase exchange, to ensure capability, and then to ensure uniform execution. 2. State undo is a special case of compensation. I agree: who cares how many phases, if it delivers what is needed. But at some point one has to come down to the practical, precise issue of the interop protocol. The BTP approach has been to use a well-known and well-understood framework of two-phaseness with presumed-failure, and use that to trigger compensations. This has the subsidiary advantage of allowing adapation to other (expected-ACID) protocols such as OTS by bridging. In other words, if the resource wants to do isolation, then it can. If it wants to locally commit, and use a compensating local transaction, it can do. There's no difference of model, no special messages. BEA's Technical Issues The tecnical questions that you rightly insist must be addressed are as follows: "1. Inter-business communication MUST be based on asynchronous
I have already addressed this point from one angle. More narrowly, let
me restate. BTP does not base itself on an assumption of synchronicity.
BTP messages are defined, at the highest level, as oneway messages with
very limited assumptions about the underlying carrier. (See my HPTS paper
for a summary, already posted on this list). SMTP would do. BTP says nothing
about the programming
"2. The last version of the document I attempted to review, leaves
According to some people, IBM and Microsoft don't believe transactions
play across the firewall. I'm an old cynic, so I think that means "IBM
and Microsoft have got other fish to fry, but when they're ready, the 'industry'
will discover that transactions play across the firewall". Nobody is talking
about classic ACID transactions. I wish we weren't collectively, in BTP,
making the presentational
What BTP does do is exploit the morphological similarity between "provisionally update this page, logging before-images and locking it against access, then either delete the log and drop the locks, or process the BIs and drop the locks" and "provisionally carry out this operation, logging the counter-operation and the parameter data, then either delete the logs, or run the counter-operation". The difference between classic transactions and the compensation approach is not the shape, the number of messages required in a distributed environment, but the internal contents of "commit/confirm" and "cancel/rollback". > 3. Regardless of the
reasons, we don't have a critical mass of
How would reducing the scope have worked? BEA proposed to reduce BTP from cohesions + atoms + coordination hub, to atoms, minus prepare timeouts. Cohesions is a new feature that allow real-world applications to be constructed with greater reliability, removing work from the application.This approach is vital to any multi-quote case, like the hedge fund trading example in our demo. This feature is oriented to the practical problem of cross-org commerce. It might be a good reason to take up BTP. Prepare timeouts (after ten minutes, this quote will lapse; after a day we will cancel your provisional airline reservations) are a concrete expression of respect for business autonomy. I can't get this from other protocols. Coordination hub is the ability for an exchange or ASP or dominant trading partner to act as a coordination factory. Very helpful for auditing work. These are key, optional features that make BTP well suited to inter-org commerce. They're pretty minimal. There are issues that BTP does not address in 1.0 that are very important for the future, and were consciously excluded, to get something out that would be useful and would start the ball rolling. While BTP does take account of security needs, it doesn't address that integration in any full way. It doesn't deal with dynamic commit, which has a real use in this environment. Etc etc. The API and .NET Finally, a word on .NET and the importance of an API. If we believe that interoperation with .NET is critical then we can either wait for Microsoft, or we can create something that matches Berners-Lee's Test of Independent Invention. A 2PC-like protocol is more likely to jive with TIP 2, or whatever it is that awaits us, than something less "orthodox" in transactional terms. BTP could probably bridge to anything that has a two-phaseness with minimal trouble. Other than that, we can't interoperate, and will never be able to interoperate, unless we use whatever Microsoft come up with. The "complexity" of BTP is the complexity of XA versus the simplicity of TX. One is obvious and pretty intuitive, the other causes brain ache on the first, second, third etc visit. BTP needs its TX, and the JTA proved to be a good approach (no-one could care less how BEA implements JTA, only that the API works). Here they will care whether it is easy for an app programmer to use (that's where simplicity counts) and whether it's interoperable. My guess is that less than ten companies will ever implement commercial versions of BTP or anything like it, and the spec is aimed at those people, while the API is aimed at a much wider audience. Related point: compensations require a new type of programming for most people -- the writing of resources (albeit specific to business contexts or patterns, rather than truly general purpose). That is the hardest part of what we are all talking about here, and I think that there is a case for the new JSR to imbibe the issue of a service-side API to allow compensations and operation sequences to be readily associated. I'm sorry, in Descartes' words, that I didn't have time to write a shorter letter. Apologies also for any duplications of argument -- some of this got dragged in from other quarters. Yours, Alastair
Sanjay Dalal wrote: On behalf of Ed Cobb who is not able to post to BTP mailing list.... |
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