(See also: http://usemod.com/cgi-bin/mb.pl?HubAndSpoke -- one that focuses on navigation)

This is a common topology seen with Messaging systems, especially when you have a PublishSubscribe kind of architecture.  You have a single central "drop point" (a hub) that each system sends messages to.  The messages are then forwarded to particular "spokes" along the "wheel".

http://members.aol.com/kgb1001001/hubandspoke.gif

This is basically the MultiCaster idea.  It's also identical in intent to the MediatorPattern. 

There are some decisions you have to make, and some ramifications of choosing a hub and spoke architecture in a messaging system:

(1) Do you multicast (publish) directly from the receiving point?  The simplest hub and spoke system is one where each "spoke" is a subscriber to the hub, which is a publisher.  When you publish to the hub, all of the spokes receive the message.  However, a more flexible approach is to simply publish to the hub and then let the hub decide through some additional logic what to do with the message.  This is closer to the MediatorPattern idea.

(2) Do you perform any translation at the hub?  Often a MessageTranslator is used to take messages pushed to the hub that are not in a CanonicalMessageDataFormat and change them into the canonical format.

--KyleBrown (some naming taken from RichardMonsonHaefel with inspiration from MartinFowler)

Sounds like it could be RhymingSlang. --NickBensema

-----

''This is the idiom that results from using a MessageBus. Indeed, all bus architectures are HubAndSpoke. Sometimes called 'concentrated channel' (network) or 'server orientated' (compute).--RichardHenderson''