[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [business-transaction] FW: Principles of Design
Pal,
I like it a lot. I think that this sentence captures a problem that has afflicted recent discussions: "Sometimes simplicity is confused with 'easy to understand' ". It's useful to take these points and see how they map to BTP. We can't be mechanical about it -- Berners-Lee is writing in a context, but there's a lot of applicability. Simplicity Any recoverable, distributed two-phase coordination protocol with failure recovery has an uncompressable core of functionality. That core is the Superior-Inferior relationship for atoms, in BTP terms. It isn't trivial, it isn't obvious in all of its subtleties, and it is tolerably hard to understand to the level required to carry out a good, production-capable implementation. It's also 60-80% of what the current spec is about, depending on your view, and how much ancillary material (security, workflow etc) we include. We had all better get over the fact that this is hard stuff. For me simplicity means reduction to essentials, decomposing and laying bare the elements and communications that are needed to effect requirements. The original BEA proposal has a hidden two-phase protocol within it (a resign prior to termination is the cancel message, and perhaps this can be carried by an application response fault as well). My last document showed the other mappings. It makes implementation design choices such as "one coordination object per address space", "always use interposition". For a product these are fine choices. They simplify the implementer's job for a target market. For an interop standard these are bad choices. The true, skeletal structure of the protocol is obscured and muddied by implementation considerations. Other target markets are made harder or precluded. Such an approach is the opposite of "simple". It is simply proprietary. BTP has factored out and made explicit the essential messages and contracts required for Superior/Inferior relationships. By doing so it has done what a good standard does: provided a level playing field for implementation competition. It favours no incumbent vendor. Modularity Our conformance picture really maps perfectly to this whole section. We say: here's a clump of functionality. It talks, using "simple and abstract interfaces", to other clumps of functionality. Within those clumps there can be levels of capability. We end up with the highly modular, interface-defined breakdown: Initiator/Factory Terminator/Decider [simpler term for persistent terminator, the thing that logs the outcome] Superior/Inferior What does a factory create? Coordinators, Composers, Sub-Coordinators and Sub-composers. The first two are Deciders. The closeness of the relations between the Factory and the Decider capability, the overlap of classes within them, if you like, makes it seem reasonable to group them together to create (as proposed previously): Initiator/Terminator <--> Factory/Decider, and Superior <---> Inferior. Whichever final division we come up with in terms of interop profiles (I've suggested two above, with a preference) we clearly have islands of functionality properly separated by clear interfaces (message sets). As our problem domain is creating shared state transitions we cannot avoid specifying overarching contracts that bind the actions of the parties across our interfaces. That is not a violation of modularity, but is intrinsic to the system we are defining. Decentralization I can't see what the relevance of this is to our work. I certainly don't think we colonize the global namespace, to take it literally. Tolerance There's another related document on evolvability (ugly term) which discusses the limits of free extension. I think our extension qualifiers get it about right. We don't try to guess all uses, we know the standard has to be integrated with higher-level protocols for particularly trading communities, that vendors have to be able to play with extensions for e.g. security and that some of those extensions may cycle back into the base standard when proven. So we've provided a properly-scoped sandpit for type of experimentation, without harming the base structure. The concept of a binding pro-forma, with the initial bindings only to SOAP, is another example. We haven't tried to define the use of everything, but we haven't blocked the road to the future either, and we're allowing the market to draw the plans. Test of Independent Innovation Could we interwork with our moral equivalent of the Multi-Media Mesh, designed by someone else? Yep, that's what open-topped coordination and the choice of the classic two-phase structure produce. Interworking, legacy integration, domain bridging, edge flexibity, investment protection, ability to live in other people's stacks. Is there other intelligent life on earth? Yes, like the four or five predecessor groups who did all the hard work that we're borrowing and moulding (CCR, OSI/TP, X/Open DTP, OTS, TIP). Yes, like the people in Microsoft who may come up with some cognate attempt that we'll have to interwork with or bridge too (maybe). Principle of Least Power "When expressing something, use the least powerful language you can". Our "language" is pretty simple, and tailored to the specific job. We declare messages by writing descriptions of their content in English. We formalize this for the XML encoding by using (simple) schemas, and reillustrate the messages by giving example documents. We declare shared state transitions by writing two-sided state tables. At another level, we are writing a language containing the verbs required for our two key interoperable relationships. Punkt. I want to add something to this list of issues and principles in standards design. It's the "Dave Turner from Microsoft Said It Most Recently" principle: A Good Standard Leaves Room for Implementer Variation Standards are compromises to enable industries to function to fulfill human needs despite the fact that the competing companies all "want" to be monopolies. Good standards tell you what to do to allow communication, not how to do it. HP and BEA have different architectures in their different products. BTP let's them compete, and interoperate, without ripping up their well-understood architectures. Alastair Pal Takacsi-Nagy wrote: I found this old opus from Tim Berners-Lee. We should consider this wrt. BTP... |
begin:vcard n:Green;Alastair J. 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 adr:;;13 Austin Friars;London;;EC2N 2JX;England version:2.1 email;internet:alastair.green@choreology.com title:Managing Director fn:Alastair J. Green end:vcard
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC