Regarding this issue of the "hub", or "message bus", etc. - these are
all just examples of some form of messaging infrastructure. Words like
"hub" or "bus" merely imply a certain type of connection topology
that the messaging infrastructure implements. They make it easier to
talk about these things in concrete terms, but the terms are imprecise
and possibly misleading so we need to be a bit careful using them.
If we try to think about this a bit more formally, what we need to define is merely an "interface" (e.g., in the sense of a modern language such as Java etc.) which provides certain well-defined operations with well-defined semantics. An "implementation" like the PLASTIC hub merely implements this interface. So long as some software implements the interface in a compliant fashion, it doesn't matter how it is implemented. A given implementation may well support additional, completely different interfaces simultaneously, or the semantics may be a superset of what the standard defines.
In addition to a standard interface we need to define at least one wire protocol to be used to talk to the an implementation of the standard messaging interface. If for example this protocol is socket-based, we need to specify in socket terms what the protocol is (e.g., as in Pat's example). If the protocol is partly file-based, then we need to specify that instead. This protocol is largely a separate matter from the formal messaging interface, which could be implemented over multiple wire protocols.
The messaging interface will probably only provide some mechanism for expressing a message, and transmitting or receiving a message. The message _content_ used to talk to specific applications is then another aspect of the standard. For the most part, the message content is probably independent of the specific messaging interface, although certain concepts such as message classes and so forth will probably need to be common.
Finally, when it comes time to use this in a client application, ultimately there is probably going to be some sort of API which client programs actually use. If all we do is specify things to the level of the wire protocol, the applications programmer is still likely to write their own API on top of, e.g., XML/RPC or whatever. One certainly wants to standardize the protocol so that this sort of thing is possible. However, real-world users - for example writing Python apps (or IDL, IRAF, etc.) - will generally not very much mind if someone hands them a ready made module which implements the protocol and provides a nice easy to use API.
I think these are all important elements of the inter-tool messaging facility we are talking about. They all need to be carefully defined, and should not be all muddled together.