BA Concept - Message

6/20/99 - Go Back

The basic collaboration mechanism is a Message.

A BA system is more than a bunch of parts organized into a tree. The parts need to collaborate to get their work done. In normal Object Oriented code this is done with method calls. In the BA it's done by passing Message objects from one part to another. While this is extra trouble at the code level, it has great advantages.

A Message has a name and zero or more properties, just like a Hashtable. The main methods of a Message are:

// Constructor that sets the message name. This serves as the
// unique ID of the message, so that routers and listeners can
// react only to messages of interest.
public Message(String messageName)
// Returns the message name.
public String getName()
// Sets a property 
public void set(String key, Object value)
// Gets a property
public Object get(String key)

This allows a Message to signify a particular event has occured, and carry information of any kind about the event. We could have used the name MessageEvent, but it's used so often we use the shorter name. For further discussion, see the glossary entry for Message.

Practice - (to be continued ***)

Parts implement MessageListener to receive Messages.

Since we are following the event portion of the Bean Spec, we provide an interface for Message event listeners. This must be implemented by parts wanting to receive Messages, which is most parts. The interface methods and brief documentation are:

public interface MessageListener {
    // The part should process the Message according to its
    // inherent design and DK.
    public void processMessage(Message message);
    // Returns the Message names the part is interested in.
    public String[] loadMessageInterests();
}

Typical implementations of processMessage() check the Message name and have a private method for each different Message name. They ignore Message names of no interest. For further discussion, see the glossary entry for MessageListener.

Practice - (to be continued ***)

Parts implement MessageSource to send Messages.

Unlike the Bean Spec, we provide an interface for Message senders. This must be implemented by parts wanting to send Messages. The interface methods and short documentation are:

public interface MessageSource {
    // Adds the listener for the particular named Message.
    public void addMessageListener(String messageName, MessageListener listener);
    // Removes the listener for the named Message.
    public void removeMessageListener(String messageName, MessageListener listener);
    // Returns the router, mainly for tool use such as the Inspector.
    public MessageRouter getMessageRouter();
    // Returns the definitions for the Messages this source might send.
    public Vector getMessageDefs();
}

The first two methods are normal for event sources. The second two support the BA's Visual Tools and advanced part use.

Practice - (to be continued ***)

Parts have no idea where Messages come from or go. (Anonymous Collaboration)

One of the principles of Structured Assembly is Anonymous Collaboration. This says that the less two parts know about each other when collaborating, the better. We accomplish this with Messages and a Mediator to handle Message hookups. The Microkernel is the Mediator. Only it knows where Messages come from or go.

Imagine Parts A and B needing to collaborate. If Part A knew about Part B, the two parts could only be used together, preventing independent reuse. So what we do is have Parts A and B send Messages to each other to collaborate. Thus Messages and the two interfaces above are required to provide the "indirection" that enables maximum loose coupling. The Message subsystem allows independent part reuse, which is a very Good Thing.

Practice - (to be continued ***)