Publish-Subscribe Style
4.3.1 Overview
In the publish-subscribe style of the C&C viewtype, summarized in Table 4.3, components interact via announced events. Components may subscribe to a set of events. It is the job of the publish-subscribe runtime infrastructure to make sure that each published event is delivered to all subscribers of that event. Thus, the main form of connector in these styles is a kind of event bus. Components place events on the bus by announcing them; the connector then delivers those events to the appropriate components.
The publish-subscribe style is commonly used to decouple producers and consumers of messages. This decoupling therefore supports the modification of these producers and consumers.
| Elements |
|
| Relations | Attachment relation associates components with the publish-subscribe connector. |
| Computational model | A system of independent components that announce events and react to other announced events. |
| Properties | Same as defined by the C&C viewtype but refined as follows: which events are announced by which components and which events are subscribed to by which components, and when components are allowed to subscribe to events. |
| Topology | All components are connected to an event distributor that may be viewed as either a busconnectoror a component. |
4.3.2 Elements, Relations, and Properties
The computational model for the publish-subscribe style is best thought of as a system of largely independent processes or objects that react to events generated by their environment and in turn cause reactions in other components as a side effect of their event announcements. Because the developer of a component in this style cannot know in advance the number of recipients of the component's announced events, the correctness of the component cannot, in general, depend on those recipients. This fundamental property of publish-subscribe systems decouples the components and greatly enhances the ability to modify one part of a system without affecting other parts of it.
The publish-subscribe style can take several forms. In the most common one, often called implicit invocation, the components have procedural interfaces, and a component registers for an event by associating one of its procedures with each subscribed type of event. When an event is announced, the associated procedures of the subscribed components are invoked in an order usually determined by the runtime infrastructure. User interface frameworks, such as Visual Basic, are often driven by implicit invocation: User code is added to the framework by associating user code fragments with predefined events, such as mouse clicks.
In another publish-subscribe form, events are simply routed to the appropriate components. It is the component's job to figure out how to handle the event. Such systems put more of a burden on individual components to manage event streams but also permit a more heterogeneous mix of components than implicit invocation systems do.
4.3.3 What the Publish-Subscribe Style Is For and What It's Not For
The publish-subscribe style is used to send events and messages to an unknown set of recipients. Because the set of recipients is unknown, new recipients can be added without modification to the producers.
4.3.4 Relation to Other Styles
When used to distribute messages, the publish-subscribe style can be regarded as a shared-data blackboard without persistence. When the components have independent threads of control, the publish-subscribe style is a refinement of communicating-processes style.
Implicit invocation is often combined with a peer-to-peer style, in which components may interact either explicitly, using procedure or function invocation, or implicitly, by announcing events. For example, in the distributed object setting, CORBA and EJB provide event announcement capabilities that may be combined with remote procedure calls. In other object-based systems, the same effect is achieved by using the MVC (Model-View-Controller), or Observer pattern.
4.3.5 Examples of the Publish-Subscribe Style
Section 7.6.3 describes a portion of the infrastructure used to support a publish-subscribe system. In the HLA (High Level Architecture) publish-subscribe mechanism (HPSM), the concept of publish is split into two notions: intent and action. Within the HLA, publish means the announcement of an intent to provide data. When it publishes an HLA class, a component announces the intent to provide, at a later time, data values for instances of that class. Conversely, a component can subscribe to an HLA class. The subscription indicates the subscribing component's wish to be notified of new data values of instances of the HLA classes to which the component subscribes.
The action of providing the data is called update in the HPSM. Once it publishes a class, a component may then update instances of that class, whereby the component provides the data values for instances to the HPSM infrastructure. It is the job of the HLA runtime infrastructure (RTI) to ensure that each update is delivered to all subscribers of the relevant class. The update notification is a "pull" event for the subscribing components; a subscribing component must query the HPSM infrastructure for available object instance updates.
The HPSM notions of publish and update are similar to the multiple definitions of the term publish in the newspaper industry. A newspaper publisher announces the intent to provide, or publish, issues of a newspaper. The publisher also provides, or publishes, individual issues of the newspaper. HLA recognizes this duality, teasing the concepts apart and giving them individual names.