n keep a lid on network traffic, even when there's lots of data and many subscribers, by using message routers and multicast transmission to distribute information.
I examined
three leading
P&S solutions: Open Horizon's Ambrosia, Talarian's SmartSockets, and Tibco's TIB/Rendezvous. These products typically become an integral part of a large organization's computing infrastructure, using many different platforms, networks, and architectures, as well as different applications.
Choosing a tool is more than a matter of finding one that helps you build what you want. Most middleware tasks can be handled by most P&S solutions, but some just work better and are easier to implement than others for a particular application. Architecture, program
ming API, level of delivery reliability, and availability of security features, including authentication and encryption, all differentiate these products.
P&S products can solve scalability issues, but different products scale in different dimensions, depending on their architecture and design. The right publish/subscribe solution for your application depends on whether you need to add subscribers, the volume of data to be published, and the size and topology of your transport network.
Ultimately, the best approach to buying any type of middleware is to run your own tests with your own applications. I invited leading P&S middleware vendors to install their latest products in BYTE's lab and supply test programs, but it became clear that P&S performance depends on too many variables to allow meaningful comparisons. Platform, message size, data type, timing, batching (i.e., the number of messages sent by the publisher at one time), system configuration, available RAM, network bandwidth, t
he number of publishers and subscribers, and middleware architecture all affect performance and make comparisons difficult. As noted earlier, the ultimate criterion is how well a product works for your own specific application.
I checked the products' baseline functionality, which includes ability to publish and subscribe data, support for security and authentication, quality of service, fault tolerance, and the current de facto and de jure standards. These standards affect the products' ability to interface with the most popular and important protocols, programming languages, OSes, and platforms.
Infrastructure Architecture
Traditional client/server programming employs a request/reply model, while P&S (see "Publish or Perish," September 1997 BYTE) enables a producer to publish data and permits consumers to subscribe to it. A broker transmits these data events to its subscribers, eliminating one obstacle to scalability: the need for data consumers to periodically poll for new data. Wh
en new data comes in, the middleware delivers it to all the subscribed data consumers (and to them only).
Tibco
uses a peer-to-peer multicast on a bus architecture for TIB/Rendezvous: All peers publish or subscribe to messages directly. Any peer can publish data by sending it to a subject at a multicast address, and any system can receive it by subscribing to the subject's multicast address. Each participating system runs a Rendezvous daemon that sends and receives messages on the network. Rendezvous routing daemons can route messages to subscribers on remote LANs. These daemons act as message brokers because they forward messages to their destinations, publishing messages to and accepting messages from the bus for Rendezvous-enabled applications.
In contrast,
Ambrosia
employs a peer-to-peer/broker unicast approach. Using a hub-and-spoke architecture, Ambrosia-enabled applications subscribe and publish by opening a TCP connection with an Ambrosia Message
Broker process that has the ability to track who's subscribing and who's publishing.
The distinctions between architectures are critical to performance and scalability -- which are determined more by the nature of the application than by the P&S middleware being used. For example, using multicast to deliver messages means that local network traffic will be flat no matter how many subscribers there are: An event is published only once to get it out to all subscribers on the network. TIB/Rendezvous uses this model; one IS manager whose company uses this product reported that the network load flattened out after the addition of as few as two to four subscribers.
In a hub-and-spoke architecture, each message passes through a broker or a server. Here you must add message routers as you add subscribers. Therefore, if one message router is just enough to handle 30 subscribers on a LAN, doubling your subscriber base means adding another message router. To complicate matters, there's nothing stopping
you from deploying
SmartSockets
, for example, with multicasting enabled to save bandwidth -- or from deploying TIB/Rendezvous using unicast transmissions, with each peer pointed to a routing daemon, to simulate a hub-and-spoke architecture.
Consider an application linking a large number of publishers, each publishing to fewer subscribers, all deployed across a WAN. Implement with a bus architecture like TIB/Rendezvous's, and you will need to have at least one routing daemon at each geographic location to forward messages. Hub-and-spoke architectures also work well for applications requiring explicit involvement of the application with message routing.
Message routers can retain a cache of old messages of variable sizes, so subscribers who miss anything due to system failure can catch up on missed messages. TIBrequires each peer be running (or have access to) a Rendezvous daemon to listen for multicast content; message-routing products, like SmartSockets and Ambrosia, rely on
their enabled application client software to handle subscriptions.
Open Horizon Ambrosia 2.1
Open Horizon positions Ambrosia as a P&S solution for the Internet. Since Ambrosia is one of the first products to be certified 100 percent Pure Java, Ambrosia peers require only a Java 1.1 virtual machine (VM) and a TCP/IP stack; the broker software runs on Windows NT4.0 or Solaris. Ambrosia's hub-and-spoke architecture might seem ideal for widely distributed systems, but version 2.1 doesn't support interbroker communications. Instead, it funnels all messaging through a single broker (version 3.0, expected soon, will support interbroker routing).
The Ambrosia message broker routes messages from publisher to subscriber, acting as an intermediary for messages and enforcing delivery reliability (see the sidebar "Managing Performance/Reliability Trade-Offs") and security (it supports encryption). If a subscriber requests guaranteed delivery, the message broker makes sure the message is delivered.
The broker handles all authorization tasks, including determining whether a peer is allowed to subscribe, publish, or request guaranteed delivery of events.
Unlike TIB/Rendezvous, which delegates all programmatic policy to the application itself, Ambrosia requires the developer to use the message broker to create program policies, such as who can publish and who can subscribe. The Admin console lets you manage access policies for individuals or groups and monitor messages by subject.
Ambrosia builds on Java's security interfaces for user authentication, authorization of users for particular operations, DES encryption, and integrity checking via a secure digest. Expected at the start of this year is support for triple-DES encryption and public-key authentication.
Talarian SmartSockets 4.0
With its 14 pounds of documentation, SmartSockets scored tops in volume of support materials, including tutorials with step-by-step instructions and sample code. SmartSockets' hub-and-spoke archit
ecture supports true message routing between message brokers for wider scalability across WANs. RTserver, SmartSockets' message broker, routes messages directly to subscribers or to intermediate message routers. Multicast transmission is available as well, for reducing traffic on a LAN.
Even so, Talarian describes the architecture as a "logical bus," which means peers publish messages into the logical bus and other peers subscribe by tapping into that bus. SmartSockets is very much a message-routing product, using OSPF (Open Shortest Path First) routing to efficiently route messages from publishers to subscribers.
SmartSockets rates high on reliability, supporting hot failover between message routers, as well as other types of load balancing. The package supports DES encryption but lacks public-key support.
Tibco TIB/Rendezvous 4.1
Tibco's TIB/Rendezvous event-driven middleware employs a bus architecture: Everything is published directly to the bus. Relying heavily on multicast, Re
ndezvous-enabled applications scale incredibly well when implemented appropriately. The publisher publishes one message, which can be subscribed to by processes running on any or all systems on the network. Adding subscribers impacts network traffic only minimally, since subscribing is a matter of the subscriber's publishing a message announcing its subscription.
Intranets, extranets, and the Internet complicate matters. Extending the TIB bus to WANs requires the routing of messages. The Rendezvous routing daemon, rvrd, forwards messages subscribed to by other routing daemons on behalf of systems on other networks. TIB/Rendezvous routers use subject-based routing to minimize internetwork traffic: Only messages subscribed from outside a site are forwarded.
Creating a channel to publish data with Rendezvous is easy, but integrating existing applications can be more complicated. Reliance on a daemon means that all Rendezvous-enabled applications can share access to the P&S bus.
Cost and Su
itability
Overall, the suitability of any of these products to your application depends on what that application is and how you want to deploy it. After deployment, these products make publishing data simple, but building the application can be trickier.
Cost considerations are also important. Although the raw cost of the software license is important, with per-seat costs for a fully functional TIB/Rendezvous peer starting at $600, the expense of developing and deploying your application must also be considered. Expect to devote considerable effort to designing your event namespace and the interfaces between legacy applications and whichever P&S architecture you choose.
Product Information
Ambrosia 2.1 developer's license.................starts at $5950
Deployment systems..............................start at $14,950
Open Horizon, Inc.
South San Francisco, CA
Phone: 650-869-2200
Fax: 650-869-2201
Internet: http://www.openhorizon.com
Publish and Subscribe Meets the Internet
