Nick Gall's Weblog

Thursday, July 24, 2003

Adaptability = Extensibility + Intermediaries (Federation) + Interoperability? I've been thinking a lot about SOA (Service-Oriented Architecture) these days, and to me, the essence of SOA is interoperability (aka integration). One might say that interoperability is simplly a network-centric way of thinking about modularity—decomposing complex systems into a network of simpler subsystems (modules). When thinking about modular systems, one can focus on the modules and how the designer has factored the overall system to optimize adaptability (minimize coupling and maximize coherence) within the modules (modular adaptability). Or one can focus on perhaps the most important subsystem ("module"?) in the decomposition: the subsystem that enables the interaction among the modules. A great book with keen insights in general systems thinking, Fault Tolerance: Principles and Practices, refers to this interaction-enabling module as the design of the system. So for example, if integrated circuits (ICs) are the "modules," then the circuit board that connects them is the "design." Continuing the analogy, there are many ways to design a circuit board—from soldering onto copper traces to a pluggable breadboard. But note that one can view the design as embedded not only in the circuit board, but also in the connectors embedded in the chips themselves. (Another way of putting this is that the design is embedded in both the connectors among the modules and the interfaces exposed by the modules.) A core issue of adaptability in designing a circuit board is designing one that can not only enable hot swapping of ICs (modular adaptability), but one that can also enable ICs with very different connectors to still interact, e.g., 5-volt ICs interoperating with 12-volt ICs, or electrical ICs interoperating with optical ICs. This is what SOA is all about. As the electrical to optical example shows, however, to achieve interoperability between such different connection types requires a design that abstracts away all physical details and enables interoperability purely in terms of abstract (i.e. informational) identifiers, formats, and protocols (IFaPs). When a physical component has been abstracted to such a degree, it is appropriate to think of it as a service (aka process, abstract state machine) instead of an object (thing, physical machine). Of course, to achieve this level of abstraction (e.g., spanning optical and electrical designs) requires that the abstract design be based on intermediaries between the concrete designs. Such an abstract circuit board design would be a federated design. Now a data communications network, like a circuit board, is a design that connects a set of modules to form a system. (Actually, both the data network and the circuit boards are both "networks" in the general sense of the term. Perhaps design == ([is equivalent to] network [connectors, intermediaries, and interfaces].) As with optical and electrical circuit boards, different networks have different physical characteristics. (There are in fact optical and electrical networks.) Thus, the core issue of adaptability in the network context is interoperating across two different types of networks so that modules on each network can be composed or combined to form a single system. This of course entails abstracting away from network specific IFaPs to abstract IFaPs that can be bound to any concrete IFaPs. (SCSI in fact does this across the optical [fibre channel] and electric [buses] networks that make up a SAN.) The Internet did this, didn't it? So aren't we done? Well, yes, but there is no easy way to evolve the Internet IFaPs themselves. We've been waiting for a decade to evolve from IPv4 to IPv6. So in designing a network abstraction to overlay the Internet, we should not repeat the same mistake. We must design it to enable the generation of a wide variety of abstract IFaPs; hence the need for extensible formats (SOAP envelope) and extensible Message Exchange Patterns (protocols). (I'm not sure whether URIs are extensible enough identifiers. I have to look into XRN further.) So… The adaptability of a design can be broken down into two distinct types of adaptability. First, the degree to which the design enables the modules to evolve/adapt internally, e.g., to enable one module to be replaced by a functional equivalent with superior performance/quality/price. Second, the degree to which the design itself can evolve/adapt. I think HTTP and REST make the same mistake as IPv4. Although REST enables the evolution of the resources (modules) it interconnects, the REST IFaPs are not themselves designed to evolve to the same degree as the SOAP IFaPs. 7:48:25 AM

Getting Back in the Groove. Ouch! Eleven days without a post. What can I say. I couldn't post from Las Vegas, where I was attending CA World (7/13-7/17). The dial up from the hotel room was too slow (21K), and the LAN at CA World screwed up Radio--don't ask me why. After that, I just got "busy." But now I'm ready to get back into the discipline of daily postings. 4:58:27 AM

Sunday, July 13, 2003

I'm a Bright. Just read Daniel Dennett's editorial in the New York Times describing the Bright movement and I went to the website to be counted. From the website: A Bright is a person who has a naturalistic worldview A Bright's worldview is free of supernatural and mystical elements. The ethics and actions of a Bright are based on a naturalistic worldview. 6:44:48 PM

The Lever of Riches: Technological Creativity and Economic Progress. Is a good book by Joel Mokyr, which I found through a reference to it in David Landes magisterial "The Wealth and Poverty of Nations." Both books have lots of concrete examples of the evolution of technology and its economic impact. It is chock full of great quotes: [The dynamic forces of technology and the conservative forces of ceremony and ritual] oppose each other in dialectical fashion, and what is required for technological creativity is the right blend of accumulated knowledge of past generations and the ability to shed the stifling burden of past institutions. pg 190 6:28:48 PM

Saturday, July 12, 2003

Absolute Truth. A nice pragmatic (Rortian) definition from Douglas Purdy of Microsoft: From the Wise Man's Dictionary: Absolute Truth == What I currently believe based on my finite mental capability operating on somewhat shoty data. 7:24:56 AM

Friday, July 11, 2003

Tight vs. Loose Coupling. In searching for discussions of the relationship between AOP (Aspect-Oriented Programming) and SOAP envelope processing (so far nothing), I ran across a good chart comparing tight and loose coupling. It raised a number of aspects that I have not yet focused on, e.g., references, ontology, and schema. Much food for thought in my thinking on designing for change. For example, what is the relationship between interoperability and adaptability? 7:36:38 AM

Thursday, July 10, 2003

All your base are belong to us. Blew the whole morning surfing blogs, but came up with a real gem: "All your base are belong to us." Sometimes I feel like I'm way behind the curve. But I'm catching up. "All your base" is a perfect example of the organic creation of content enabled by the Web. Truly inspiring. I can't even begin to describe how important such examples are. 7:27:29 AM

Wednesday, July 09, 2003

Are "interface" and "catalyst" the same thing? Something got me thinking about catalysts again, and it struck me that the definition of catalyst and the definition of interface are deeply intertwined if not identical. An interface is a point of interaction between two or more distinct things (systems, processes, substances, chemicals, particles, etc.). A catalyst is such a point of interaction (i.e., reaction) that is not changed or consumed by the interaction. It is not an input (reactant) or output (product) of the interaction. It is the "fixed point" in the interaction. Note that discussions of catalysts and catalysis speak of "providing a lower energy pathway between the reactants and the products." (See catalysis. Emphasis mine.) Metaphors such as pathways, channels, transports, mediums, abound in talk of both catalysts and interfaces. The interesting insight from this generalization of catalyst/interface is that one can think of the quality of an interface in terms of how much it lowers the energy pathway (i.e., lowers the activation energy) between provider and consumer. Thus, an interesting avenue to pursue is to compare the concepts of loose coupling and accelerating interaction. Another interesting avenue to pursue is to see if the catalysis metaphor can shed light on the notion of binding an interface to its implementation. 7:57:17 AM

Tuesday, July 08, 2003

Is an "End-to-End" Internet the only "true" Internet? Interesting post by Lawrence Lessig, a Stanford Law professor who focuses on IP issues. He cites Saltzer, Clark and Reed's "End-To-End Arguments In System Design"as his definition of the "Internet." Given my beliefs about how Web services breaks down the end-to-end vs in-the-net dichotomy, I'll respond when I have more time. 5:33:30 AM

Sunday, July 06, 2003

Towards a Science of Modularity. Applied X is about the interface of Theory X and Medium Y. Applied physics, applied math, applied comp sci. Often such applied disciplines are looked down upon by their respective pure theory disciplines. But it is in the application of theory that the action takes place. What is needed, though, is a general theory of "application." What is common to all types of applied theory? One thing that is clear is that the people applying the theory have to be dual experts: expert in the theory being applied and expert in the medium to which it is being applied. Of course, such a medium has its own theory, so such people must be experts in two theories. This leads to the concern that a jack of two trades is not a master of either. But there is a third expertise involved in such cases: expertise in the theory of application itself, of interfaces generally. The various bodies of theories are simply a modularization of knowledge. Thus, like all modular systems, the modular framework that separates the disciplines and interfaces them, is subject to the same "laws of modularity." It is such "laws of modularity" that I hope to "discover" (uncover/reveal) and describe as a "Science of Modularity." (SoM) Or perhaps "Liminal Science."  Google both of these terms. It is such an SoM that Herbert Simon was pursuing in "Sciences of the Artificial." (SotA) SoM is a generalization of SotA, in that it studies both natural and artificial forms of modularity and modular evolution. SoM is really also the underlying unity among the various "General Systems Theories" out there. They focus mostly on the boxes, SoM focuses on the lines connecting the boxes. 8:14:44 AM

Thursday, July 03, 2003

New SOAP Reinvents Distributed Computing via Aspect-Oriented Messaging. Recently, the W3C ratified SOAP v1.2 as a Recommendation, which gives SOAP the status of an official Web standard for the first time. SOAP has come a long way since late 1999, when META predicted its ubiquity and recommended it as a "quick and dirty" approach to low-end B2B integration. SOAP v1.2 makes abundantly clear that SOAP is intended to be far more than a primitive XML-RPC mechanism. SOAP provides the foundation for a completely new style of distributed computing based on a lightweight, extensible, distributed protocol for exchanging and processing structured information via user-extensible message exchange patterns (MEPs), user-extensible message (header) processing models, and user-extensible bindings to exchange (e.g., HTTP, SMTP) and execution (e.g., J2EE, .Net) technologies.  SOAP v1.2 makes two fundamental revisions to SOAP v1.1 to make it even quicker, but also a lot cleaner and more broadly applicable. First, v1.2 is based on the W3C XML Infoset standard, which effectively supercedes XML 1.0 as the language for defining XML-based standards. Because SOAP is defined in terms of the Infoset's abstract data set, it is free to use diverse serializations besides the verbose XML 1.0 angle-bracket (</XML>) representation, including compact binary representations. This change effectively eliminates any limitations on the use of SOAP due to bandwidth concerns. Second, v1.2 provides a much simpler and more powerful aspect-oriented mechanism for extending the SOAP processing model. New aspect-oriented features can be added to SOAP by defining additional SOAP headers and how to process them. Such features can range from transport-level features such as security and reliable messaging to business-level features such as spending-policy enforcement to personalization and differentiated service. Bottom Line: Users who consider SOAP to be just a low-level RPC mechanism should review SOAP v1.2 to understand its potentially profound architectural implications for distributed computing. 5:54:18 AM

Tuesday, July 01, 2003

(Historical) Analysis-Driven Innovation. An interesting question is the degree to which sustaining and disruptive innovation are based on or driven by analysis of data regarding the system to be improved. Certainly, one must have some idea of the limitations of the current system in order to improve it, thus data collection and analysis seem central to at least sustaining innovation. This is an interesting interpretation of George Santayana's famous dictum: "Those who cannot remember the past are condemned to repeat it." Put another way: "Those who do not collect and analyze information about the past behavior of a system cannot improve it." But this begs the question of how evolution improves a system apparently without such analysis. Certainly, random mutation, which entails no analysis, can "improve" one member of a species. But is the diffusion of such an improvement dependent on some process akin to historical analysis. Something to ponder. 5:07:13 PM