The publish-subscribe architecture is designed to simplify one-to-many data-distribution requirements. In this model, an application publishes data and subscribes to data. Publishers and subscribers are decoupled from each other too. That is: Publishers simply send data anonymously, they do not need any knowledge of the number or network location of subscribers. Subscribers simply receive data anonymously, they do not need any knowledge of the number or network location of the publisher. An application can be a publisher, subscriber, or both a publisher and a subscriber.

Publish-subscribe supports anonymous, event-driven transfer between many nodes. The developer simply writes the application to send or receive the data.

Publish-subscribe architectures are best-suited to distributed applications with complex data flows. The primary advantages of publish-subscribe to applications developers are: Publish-subscribe applications are modular and scalable. The data flow is easy to manage regardless of the number of publishers and subscribers. The application subscribes to the data by name rather than to a specific publisher or publisher location. It can thus accommodate configuration changes without disrupting the data flow. Redundant publishers and subscribers can be supported, allowing programs to be replicated (e.g. multiple control stations) and moved transparently. Publish-subscribe is much more efficient, especially over client-server, with bandwidth utilization. Publish-subscribe architectures are not good at sporadic request/response traffic, such as file transfers. However, this architecture offers practical advantages for applications with repetitive, time-critical data flows.

Publish-subscribe (PS) data distribution is gaining popularity in many distributed applications, such as financial communications, command and control systems. PS popularity can be attributed to the dramatically reduced system development, deployment and maintenance effort and the performance advantages for applications with one-to-many and many-to-many data flows. Several main features characterize all publish-subscribe architectures: Distinct declaration and delivery. Communications occur in three simple steps: Publisher declares intent to publish a publication. Subscriber declares interest in a publication. Publisher sends a publication issue. The publish-subscribe services are typically made available to applications through middleware that sits on top of the operating system s network interface and presents an application programming interface.

Publish-subscribe is typically implemented through middleware that sits on top of the operating system s network interface. The middleware presents a publishsubscribe API so that applications make just a few simple calls to send and receive publications. The middleware performs the many and complex network functions that physically distribute the data.

The middleware handles three basic programming chores: Maintain the database that maps publishers to subscribers resulting in logical data channels for each publication between publishers and subscribers. Serialize (also called marshal) and deserialize (demarshal) the data on its way to and from the network to reconcile publisher and subscriber platform differences. Deliver the data when it is published.

Publish-subscribe offers some clear advantages for real-time applications: Because it is very efficient in both bandwidth and latency for periodic data exchange, PS offers the best transport for distributing data quickly. Because it provides many-to-many connectivity, PS is ideal for applications in which publishers and subscribers are added and removed dynamically. Real-time applications require more functionality than what is provided by desktop and Internet publish-subscribe semantics. For instance, real-time applications often require: Delivery timing control: Real-time subscribers are concerned with timing; for example, when the data is delivered and how long it remains valid. Reliability control: Reliable delivery conflicts with deterministic timing. Each subscriber typically requires the ability to specify its own reliability characteristics. Request-reply semantics: Complex real-time applications often have one-time requests for actions or data. These do not fit well into the PS semantics. Flexible delivery bandwidth: Typical real-time applications include both real-time and non-realtime subscribers. Each subscriber s bandwidth requirements - even for the same publication - can be different. Fault tolerance: Real-time applications often require hot standby publishers and/or subscribers. Thread priority awareness: Real-time communications often must work without affecting publisher or subscriber threads. Robustness: The communications layer should not introduce any single-node points-of-failure to the application. Efficiency: Real-time systems require efficient data collection and delivery. Only minimal delays should be introduced into the critical data-transfer path.