Purtillo and Atlee,"Module Reuse by Interface Adaptation," Software-Practice and Experience , Vol.21 No. 6, June 1991, pages 539-556.
Alfke, "Learning to Love SOM," MacTech, Vol. 11 No. 1, January 1995, pages 12-16.
HERMES - A Heterogeneous Reasoning and Mediator System - a system for semantically integrating different and possibly heterogeneous information sources and reasoning systems.
CIKM-94 Intelligent Information Agents Workshop - Papers and URLs related to intelligent software agents, the more futuristic family of mediators.
Agents and Mediators: SHADE and the Stanford Logic Group - A site which links to two initiatives workking on agents and mediators.
The first paper, Sullivan-Notkin's "Reconciling Environment Integration and Component Independence", is a good overview of an architecture built around mediators. It's one of those good old compare and contrast architectures papers, with a pretty good general description of mediators.
Sullivan-Notkin presents an approach that integrates environments by increasing the independence of the constituent components. It presents architectures of a simple Vertex-Edges Graph object, in each of four methods: Encapsulation, Hardwired, Event-Driven, and Mediated Event-Driven. The latter proves the most flexible and efficient to expand and maintain.
The paper then abstracts the mediator-event approach, and discusses the insights the authors' work has given them into related topics.
I chose the second paper, Purtillo-Atlee's "Module Reuse by Interface Adaptation", for two reasons. First, it builds a case for software reuse by interface adaptation, whereby a layer of glue is applied between code segments whose parameters don't match. Second, it describes a simple Module Interconnection Language (MIL), Nimble, by which this glue layer is created.
I could not find a single concise paper that describes SOM and the Interface Description Language that provides mediating glue between SOM classes. Instead, Alfke's article "Learning to love SOM" provides a developer's perspective on what SOM is, what it does and doesn't provide, and what is required to use it.
This article by a member of the OpenDoc team at Apple describes his early misgivings about the choice of SOM as the underlying object-oriented substrate of OpenDoc and future Macintosh Toolbox versions. It describes why SOM is needed, how building a SOM-based system is different than building one in a traditional programming language, and the steps in building a SOM object.
A Mediator arbitrates the needs and capabilities of two parties. In software, a mediator acts as a go-between for two or more software agents.
It's a broad definition, and in the literature mediation run the gamut from database queries to code wrappers to component technology to communities of semi-autonomous concierges in cyberspace, exchanging tasks and data for the benefit of its client software.
Because reusing trusted code is often the fastest, safest way to reuse data, this technique is popular. In many ways, UNIX is a direct outgrowth of this philosophy. It is not surprising, then, that it has begun to be formalized into an architectural philosophy.
It's a different type of software reuse than we talk about in object-oriented or structured programming discussions. It looms large in the pie-in-the-sky futures discussion, from the computerized butler on the ATT commercials to the impending component systems OLE and OpenDoc.
My thesis today is a fast introduction to a particular category of mediators and how they relate to a pet topic of mine, Component Integration Labs' OpenDoc technology, specifically the System Object Model (SOM) that underlies it.
>From There:
Sullivan-Notkin was the most popular piece of the day, being the paper with the most content, although it was agreed the results were obvious in hindsight.
I noted that the structure of the paper was clearly that of straw men created to knock down in favor of the author's conclusions.
Appelbe noted that a project recently completed was in architecture the same as the mediators alternative presented in the paper. It was then asked if it was obvious, why was it not the first design?
Abowd noted that he had not seen before the notion of events mechanisms in mediators. It became clear that there were two different notions in the room as to what constitutes a mediator.
The first is mediator as coordinator, a controlling mechanism making sure all of the components worked together and were kept up to date.
The second is mediator as translator, providing an interface between two components.
A few nits were picked including some questions about UNIX belonging in the section devoted to related work. Also, it was agreed by all that papers are easier to read if they are put together in the right order.
As the historian of record, let me take advantage of the last word. In retrospect, the choice of this paper was a flawed one. I wanted to focus on the role of mediators as a façade hiding the inner works of the component behind it. I did not notice that the mediators in this paper were generally of the mediator as controller. It did, however, serve well as an introduction to mediators. Obviously.
During the discussion of Purtillo-Atlee, we didn't discuss Nimble much. Most discussion on this paper revolved around the advantages claimed for code reused in this manner. My contention is that partitioning the code into modules that can be developed and tested independently is a holy grail to a production development environment. LeBlanc and others pointed out that testing, and especially boundary conditions, will still complicate the testing procedure.
I conceded that the same testing problems that exist for systems developed with existing techniques. In fact, other papers I've read express additional testing concerns brought up by the black box nature of mediators. The consensus is trust, but verify; mediators must provide a way for users to test them.
Also a concern is the testing of the mediating interface itself. Is it trivial, is it impossible, is it like testing any other code. This was not really resolved, as a heated discussion broke out over what the vertex iterator was for in the previous paper.
A major miscalculation on my part, Alfke's article did not sufficiently explain SOM to those not familiar with it.
Before he left, Appelbe offered that SOM is not exactly easy or automatic to work with. In particular, he mentioned that interfaces that do change
Clayton wondered why SOM implemented metaclasses, in his view not a very useful concept. No answer was agreed upon, although it was speculated that IBM may have used the term as a conceptual abstraction, and not in the object-oriented sense. This, upon further investigation, appears to not be the case, so IBM's motivation is still a mystery.
A point was made about SOM and other CORBA-compliant binary class implementations that the object trees for SOM-based systems tend to be rather shallow, due to the performance hits caused by multiple passages through the interface layer.