10/8/99 - Go Back

This pretty much speaks for itself for now. We've got a lot of thinking to do. It refers to many of the interfaces on Candidate Archtecture 4.


Publishing What A Part Can Do

Currently JavaDoc is the standard for this. With Messages, JavaDoc won't do easily because we no longer have normal methods. What to do? An intriguing possiblity is using a preprocessor before compiling, but this has complexities. Another possiblity is using one public method per Message. The part would receive a Message, check the Message name, and call the method of that name. This would allow JavaDoc per Message. For example:

public void doFileOpened(Message message)

where the Message name was "FileOpened". The method's doc would explain the Message and its properties. A benefit is the public methods are available for direct links to improve performance. A problem is what if the Message name contains periods or characters not allowed in Method names? Another problem is this duplicates what needs to be provided at runtime for Message defintions. Then again, if our Visual Tools are mature, the Part Shop or Inspector can show a part's Messages and their definition easily, and we don't need this done via JavaDoc.

A good way to specify a part's Message definitions in with DK. This can start in part design, and follow the part all the way to the Part Shop and then the systems it's deployed in. To avoid having the same DK in more than one place, something like a DK driven MessageDefRegistry is needed.


The following musing start to deviate from the above diagram.

Part Pin Design

This is a really big decision. What ways should things flow in and out of parts? How many way? The minimum is a single method, inputMessage(Message). This is inadequate because it puts too much complexity in Message and there's no way for the part to output when it needs to. So the real minimum is probably:

interface MessagePinIn {
    // Returns true if handles message, false if not
    public boolean input(Message message);
}
interface MessagePinOut {
    public void setMessageSender(MessageSender sender);
}
interface MessageSender {
    // Returns true if message handled at least once, false if not
    public boolean output(Message message);
}
interface Message {
    (many methods - Has name and tree datatron)
}

Not all parts need both input and output, so these methods are in seperate interfaces. Note this gives us two pins.

A problem is there's no way to tell what Messages a part will input and output at runtime. This prevents inspection and various dynamic behavior. Usually this is no problem, and so it should not be required. Indeed it might be useful in system construction but removed for shipment. The minimum for specifying what inputs and outputs a part supports are:

interface MessagePinInNames {
    public String[] getInputMessageNames();
}
interface MessageSourceNames {
    public String[] getOutputMessageNames();
}

This gives two more pins. Then how do we get a full definition of a Message? We could use the names and a registry to get the definitions. This is the way electronic devices work - you look up what the devices do in a spec. But you have to know the part type to do that. After all, even if we have message names, different parts can react differently to the same message. We have uncovered a missing abstraction.... We could go the interface route, which is message grouping. We need grouping anyhow to determine general part behavior.

But an alternative to this is inputting a message named "AcquireInputMessageNames". The part would return true if it supported this message and would put the Message names in property "Names". Ditto for outputting a message. If group names are desired we could input a message named "AcquireInputMessageGroupNames".

So we can do with just two pins. But which option is best? Probably the minimum number of pins. It uses fewer interfaces and is simpler. It gives a very uniform pin design. This uniformity allows tools to do an cleaner job when for example they animate message flow. It will allow cleaner dynamic part behavior also.

A problem is some messages use static chains and other use dynamic chains. The core parts dynamically manimupate other parts in a manner that makes static message chains unfeasible. But domain parts can do most of their work with static message chains. How do we represent whether a message needs a static chain or not? This could be done in a MessageDefinition datatron with fields like Name, Properties and IsDomain. The property attributes could be Name, Type, IsRequired, IsAcquire, Short Descrption and LongDescription. IsStatic would be true for static chain required, false for not required. This would allow tools to check a system design for correct connections somewhat. We may need more than two types of chains....

What about setting DK? Should we use PinIn? If the rationale behind using the minimum number of pins held for one area, it should hold for this one too. We are throwing the normal use of interfaces out the window here, and using the concept of input output messages instead. We need to stick to this concept and keep it clean and symetrical.

What about the fact that DK may determine what messages a part supports? DK should be set during a parts creation. It should be the first thing done. This would take input messages "IsParamDriven" and if that returned true, "SetParam".

What about determining Message groups supported? Again, use input message "GetInputMessageNames" and "GetOutputMessageNames" is all that's needed. BTW, we can use "Get" instead of "Acquire" because it's shorter. It's still an acquire message.

Our conclusion is only two pins are needed. But this flies in the face of electronics where as the industry matured the number of pins per device increases way beyond the usual 2 or 3 for pimitive devices. Hmmmmmm.... What to do??? How can we determine how to answer this question correctly? Is there a fundamental pattern or principle?

What about core parts????

What about a rule that dynamic calls can be methods, but static calls have to use messages? What about dynamic methods on core parts only, so that dynamic use of domain parts uses messages?


Only Two Pins - Design Ramifications

If all part communication is messages, our work will be very different from normal development.

1. Our models won't show interfaces and methods. They probably need to show message groups and message names.

2. We need elaborate MessageName and MessageGroup registries.

3. Coding itself could be wierd. Messages instead of methods takes more LOC. Some convenience methods such as MessageSender.output(messageName, propertyName, propertyValue) are handy.

4. For optimization parts can expose public methods per Message. These methods can be used by other parts for direct links after acquiring and casting a part. An interface should be used.

5. Messages destroy strong typing. We'll need way to verify that a system design has valid type dependencies. This is not yet designed.

6. We may see an overall slowdown of a factor of 2 or 3. This is large, and would cause lots of time to go towards optimization and the use of direct links. This is a problem.

7. This is all so novel we need some serious prototypes with real systems to see if this is the road to go.

8. There is still a need for interfaces in mobile things, like Messages and Datatrons. What about agents?

9. There is still a need for interfaces in areas where we don't want to introduce Messages. For example a Node needs to check objects when added to see if they implement NodeUser, and if so call setNode(this) on them. This decouples the Node Plugpoint Structure from other partitions. The same may be true for the Cell partition.