MessageCentral

Message Central

The primary goal of the Message Central project is to develop technology to enable the widespread use of component-based software, that is, software built by interconnection of software components. We are exploring two elements to reach these goals. The first is a tool called SAGE (Scalable Adapter GEnerator), to simplify the construction of inter-component adapters The second is a programming language called Continuum, to support the creation of reconnectable components.

SAGE

As currently articulated, the development of component-based software depends upon prior agreement on standard interfaces and message sets. Historically, while such agreements have been made, they usually lag far behind the frontier of the application development, with messages and interfaces designed for new functionality containing many accidental differences from similar software developed elsewhere. The Scalable Adapter GEnerator, SAGE, aims to provide tools to simplify the connection of mildly mismatching software by creating message adapters between components.

Earlier Work

SAGE is building on the work of two other efforts that have already developed technology for software composition and message transformation.

The tools developed for Subject Oriented Programming include a compositor that allows developers to specify which elements of several source subjects are to be put together to create a target subject, and performs automatic matching on the basis of several criteria. Although primarily aimed at composing classes that use the same messages, there is much similarity between the problems of matching classes and matching messages.
The Mockingbird project has developed software to simplify the deployment of interoperable distributed components by automatically converting equivalent data interchanged in messages between them.

SAGE and Message Transformation

Software components are connected by the interchange of messages. In some cases, the participants in the message exchange are designed together. In those, and other cases of serendipity, both the sender and the recipient of a message use the same definitions. More often, however, in the case of components that are developed separately and then brought together, the messages, and sequences of messages, will mismatch somewhat in format, content, or protocol. In addition to mismatches in the messages themselves, the industry today enjoys a surfeit of message definition languages and models, from Java Interface Definitions, through OMG's IDL, and including DTDs and MQ System Integrator-based definitions. We need to accept and match messages defined in a variety of definition forms. In order to develop strong tools for finding, matching, and reconciling messages, we need to understand the information needs of these processes. One goal of the Message Central work on SAGE is the production of a software base for producing a variety of message adapters. We will construct tools for automatically finding, matching, and reconciling messages, or assisting with those processes. Examples of message adapters include MQ System Integrator Transformation Nodes, Java Native Call to MQ SYSTEM Integrator Broadcast/Respond. Surfaces, XML->XML message transformers, keys to/from object references transformers and more complex multi-step field transformers.

Novel Technology

Tools for producing message transformation adapters already exist. However, definitions of the transformations, although aided by the tool and interface, are still one-by-one. The map developer specifies the mappings on an element-by-element basis for a single transformation, They are relatively labor intensive. SAGE will use several approaches not employed today to automate this task and reduce the cost of describing transformations between messages that come in related groups:

Contexts	The source and target messages each exist within a nest of contexts, e.g. the Account Management messages used in Interstate Operations by Bank A. The map itself is created within a nest of contexts, like the Message X to Message Y context within the Y3K Services Context. Mappings made in one set of contexts often apply in wider usage, and we will make it possible to exploit that fact.
Descriptive Material	Messages, elements, types, etc. are characterized by formal structure and by less formal natural language text. When developing mappings between message sets, natural language descriptions can provide a basis for matching even when the names of things are different. We will exploit this information.
Fuzzy Identification and Feedback	When using a mapping tool, the tool will generally identify several possible alternatives for matching and transformation choices. The matching process cannot be a “this is the one” process. It needs to accumulate the alternatives, prioritize them, reflect them via the UI, and be prepared to answer “why” an alternative is chosen. We will adopt such an approach and explore the UI issues.

Continuum

Component-structure fragility

Message-oriented programming aims to eliminate the denotation of one of the parameters from the clients' view of method call as the special object to which the "message" is sent, and focus, instead, on the message as a request for service by any server. This permits client code to be reused even when the implementation of a method is moved from one object to another. Consider, for example, a fragment of code written to record the fact that an item was sold to a customer at a store. Assuming that "item, customer, and store" are variables that refer to objects of those types then the sale could be registered by calling the register_sale method of the item being sold. A Java programmer might write:


	"item.register_sale(store, customer)", or perhaps
	"store.register_sale(item, customer)", or perhaps
	"customer.register_sale(item, store)".

This example shows the essence of component-structure fragility. Source code calling for a service is dependent on which of the data involved happen to carry the implementation. This severely limits the use and reuse of software developed by different organizations that made different choices in deciding which objects should carry which function. The use of a message broker makes it possible to have the client code simply read


	"register_sale(item, store, customer)"

and to move the knowledge of which object carries the function into the broker. This makes both the serving objects and their clients much more reusable.

Issues in moving to message-oriented software

Successfully supporting a programming style that eliminated component-structure fragility requires addressing several issues:

What to do instead of interfaces?
What happens to object references?
What about multiple servers?
How do we avoid "message not understood"?

Good support for message-oriented programming will rely upon a broker and a composition system capable of great flexibility, like that provided by MessageCentral.

For further information, please contact Bill Harrison.

[Research home page]

[ IBM home page | Order | Search | ContactIBM | Legal ]