Re: [business-transaction] FW: Principles of Design

[Alastair Green <alastair.green@choreology.com>]

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

-----Original Message-----
From: Sanjay Dalal [mailto:sanjay@bea.com]
Sent: Thursday, September 06, 2001 7:26 PM
To: home
Subject: Principles of Design
 

 

Tim Berners-Lee

Date: 1998, last change: $Date: 2001/01/08 19:23:50 $
Status: personal view only. Editing status: first draft.

Principles of Design

Again and again we fall back on the folklore of the principles of good design. Sometimes I need a URI for them so this is started as collection of them. I have written about some in many places. Principles such as simplicity and modularity are the stuff of software engineering; decentralization and tolerance are the life and breath of Internet. Brian Carpenter has ennumerated some principles of design of the Net [carpenter]. The third pair of ideas I have found commonly useful for the Web. I mentioned them in a keynote at WWW7 and the note on Evolvability.

This is largely "motherhood and apple pie" but it still needs a home.

Simplicity

"Keep it simple, stupid!"

Simplicity is easily to quote but often ignored in strange ways. Perhaps this is because it is the eye of the beholder.

A language which uses fewer basic elements to achieve the same power is simpler.

Sometimes simplicity is confused with 'easy to understand". For example, a two-line solution which uses recursion is a pretty simple, even though some people might find it easier to work though a 10-line solution which avoids recursion.

In XML, "Processing Instructions", those things which start with "<?" are not simple. They look simple, just an extra sort of thing in the language, but the complicate what was a very clean design of elements and attributes, and a complication in the underlying syntax is has great effect. All specifications which refer to XML processing will have to figure out what to do about processing instructions as well as elements.

Modular Design

When you design a system, or a langauge, then if the features can be broken into relatively loosely bound groups of relatively closely bound features, then that division is a good thing to be made a part of the design. This is just good engineering. It means that when you want to change the system, you can with luck in the future change only one part, which will only require you to understand (and test) that part. This will allow other people to independently change other parts at the same time. This is just classic good software design and books have been written about it. The corollary, the TOII is less frequently met.

Modular design hinges on the simplicity and abstract nature of the interface definition between the modules. A design in which the insides of each module need to know all about each other is not a modular design but an arbitrary partitioning of the bits.

Tolerance

"Be liberal in what you require but conservative in what you do"

This is the expression of a principle which applies pretty well in life, (it is a typical UU tenet), and is commonly employed in design across the Internet.

Write HTML 4.0-strict. Accept HTML-4.0-Transitional (a superset of strict).

This principle can be contentious. When browsers are lax about what they expect, the system works better but also it encourages laxness on the part of web page writers. The principle of tolerance does not blunt the need for a perfectly clear protocol specification which draws a precise distinction between a conformance and non-conformance. The principle of tolerance is no excuse for a product which contravenes a standard.

Decentralization

This is a principle of the design of distributed systems, including societies. It points out that any single common point which is invoved in any operation tesnds to limit the way the system scales, and produce a simgle point of complete failure.

Centralization in social systems can apply to concepts, too. For example, if we make a knowledge representation system which requires anyone who uses the concept of "automobile" to use the term "http://www.kr.org/stds/industry/automobile" then we restrict the set of uses of the system to those for whom this particular formulation of what an automobile is works. The Semantic Web must avoid such conceptual bottlenecks just as the Internet avoids such network bottlnecks.

Test of Independent Invention

If someone else had already invented your system, would theirs work with yours?

Does this system have to be the only one of its kind? This simple thought test is described in more detail in "Evolution" in these Design Issues. It is modularity inside-out: designing a system not to be modular in itself, but to be a part of an as-yet unspecified larger system. A critical property here is atht they system tries to do one thing well, and leaves otehr things to other modules. It also has to avoid conceptual or other centralization, as no two modules can claim the need to be the unique center of a larger system.

Principle of Least Power

In chosing computer languages, there are classes of program which range from the plainly descriptive (such as Dubmin Core metdata, or the content of most databases, or HTML) though logical languages of limited power (such as access control lists, or conneg content negotiation) which include limited propositional logic, though declarative languages which verge on the Turing Complete (PDF) through those which are in fact Turing Complete though one is led not to use them that way (XSLT, SQL) to those which are unashamedly procedural (Java, C).

The choice of language is a common design choice. The low power end of the scale is typically simpler to design, implement and use, but the high power end of the scale has all the attraction of being an open-ended hook into which anything can be placed: a door to uses bounded only by the imagination of the programmer.

Computer Science in the 1960s to 80s spent a lot of effort making languages which were as poweful as possible. Nowadays we have to appreciate the reasons for picking not the most powerful solution but the least powerful. The reason for this is that the less powerful the language, the more you can do with the data stoerd in that langauge. If you write it in a simple delcarative from, anyone can write a program to analyse it in many ways. The Semantic Web is an attempt, largely, to map large quantities of existing data onto a common langauge so that the data can be analysed in ways never dreamed of by its creators. If, for example, a web page with weather data has RDF describing that data, a user can retrieve it as a table, perhaps average it, plot it, deduce things from it in combination with other information. At the other end of the scale is the weather information portrayed by the cunning Java applet. While this might allow a very cool user interface, it cannot be analysed at all. The search engine finding the page will have no idea of what the data is or what it is about. This the only way to find out what a Java applet means is to set it running in front of a person.

I hope that is a good enough explanation of this principle. There are millions of examples of the choice. I chose HTML not to be a programming language because I wanted different programs to do different things with it: present it differently, extract tables of contents, index it, and so on.

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