Multiple Pub/Sub Brokers

by Kris ZypApril 9th, 2008

Pub/sub is a popular architecture for Comet development. Simple applications may only need to deal with a single pub/sub broker (also known as a hub, which can run on a client or a server), which gives a single point for subscribing to topics, publishing messages to topics, and receiving notifications about topics. However, more complex applications may involve multiple pub/sub brokers. This means that rather than having a single domain or namespace for topic names, there may be multiple domains to consider. Multiple brokers may exist when Comet applications connect to multiple pub/sub servers, when both the client and server have a broker, when multiple frames each of have a broker and they can communicate with each other (through FIM or postMessage), or even when different portions of a single client application have their own brokers. Rather than having a single universe of topics, there are different domains that each have their own topics, and these topics may even have the same topic name in a different domain. Brokers may act as proxies to each other, and when these brokers interact with each other, it is important to track both the topic name and the broker to which it belongs. Multiple brokers can be critical for optimum performance and routing of messages. Different modules within a single page may communicate with each other through pub/sub messaging, and routing all such messages through a Comet server would be absurd.

A naive approach would be to try to replicate all topics as is, across all brokers involved. This is ignores all principles of locality, is inefficient, and is terribly unmanageable. It is the pub/sub equivalent of using global variables for programming.

Broker Alias Path Prefixing

The first reasonable technique for broker interaction is to import broker A into broker B where all broker A topics are treated as sub-topics, with path prefix. For example if we have a Utah broker, and it wants to interact with the California broker, it would treat all the topics from the California broker as topics that start with an arbitrary chosen path. In the figure below, all the California topics are prefixed with “/CA”. The Utah broker can now route all subscription requests and publish events for /CA/** to the California broker. The Utah Broker is than acting as a client/subscriber of the California broker, and when it broadcasts messages of interest to the Utah broker, the Utah broker can then translate these broadcasts to its corresponding sub-topics for the Utah broker subscribers. The Utah broker has then incorporated the California topics into its topics, and can act as a proxy for clients that only can access the Utah broker.

two-hub-async.png

This integration has not required any cooperation on the part of the California broker—the integration takes place completely on the Utah broker side. This does not require that the California broker use the /CA prefix for all its topics internally. Mandating that all brokers uniformly use a prefix internally and externally is a fragile attempt at centrally driven scheme. It does not utilize locality and makes adding new brokers very risky.

In order to achieve full transparent proxying, the Utah broker must forward publish and subscription requests. Brokers can generally forward publish requests by globbed subscriptions requests. However, brokers must be capable of routing subscription requests. This is not a traditional functionality of pub/sub brokers. In this case, importing the California topics necessitates informing the Utah broker that it needs to route subscription requests for /CA/** to the California broker (or an intermediary that can deliver the request).

Dojo uses this approach to integrate Bayeux servers/brokers into the central Dojo broker on the client. However, it doesn’t do full proxying: subscriptions and publications are not routed through the central broker, and instead are made directly against the bridge (the cometd handler). By default all Bayeux messages are imported into the /cometd/** topic space in the Dojo broker. A recent patch allows multiple Bayeux servers to be incorporated into the Dojo broker with different names.

Peered Broker Relationship

The integration just described is completely asymmetrical. The California broker has no awareness of the Utah broker. Subscriptions and event publishing can only flow from the Utah broker to the California broker. Event broadcasting can only flow from the California broker to the Utah broker. Of course, peer-to-peer symmetry can be achieved if the California broker simply imports the Utah broker topics in the same manner. Full pub/sub interaction can be performed in both directions between these two brokers. This symmetrical relationship does require both brokers to import each other’s topics.

two-hub-sync.png

URL Paths

Importing foreign topics with path prefixing has a couple of problems. First, the path prefixes encroach on the domain of topics for the integrating broker. That is, if the California topics are imported as /CA/** topics, they may collide with existing topics that already have that namespace. Second, path prefixing creates a tight coupling between the client’s use of topic names and the name selection for importing the foreign topics. In order to subscribe to topics from the California broker with the Utah broker as a proxy, the client must know what the Utah broker will use as a prefix for the California broker (in this case /CA). The client may already know the destination broker, but it also needs to know the routing information. If the prefix for routing changes, the client must be changed as well. If another proxy is added between Utah and California, the prefix may grow longer.

In order to solve this problem, we can treat topics as not only paths, but as URLs. If the California broker is hosted at hub.california.com, the topics may have corresponding URLs where they could be reached, like http://hub.california.com/weather and http://hub.california.com/sports. Now if a module knows that it wants to subscribe to http://hub.california.com/weather, it does not need to know anything about the path to get there. It only needs to know the absolute topic URL. The broker is now responsible for routing the subscriptions and other messages. How this happens, whether it’s through a single proxy or multiple proxies or whether the broker is the final recipient, is all implementation details that the subscribing module does not need to be concerned about. This model is simply based on the model of the web, applied to pub/sub architecture, which has been developed so that resources can be accessed by URLs without knowledge of the routing required to get the resources. Also, plain paths for local topics can still be used (which are analogous to relative URLs). The different syntax for URLs and relative paths precludes collisions.

Path prefixing and URL topics provide two means for integrating multiple pub/sub brokers. Path prefixing minimizes the effort required by brokers and is good solution in small integrations, or when universal location mechanisms are not available. URL topics provide a more robust broker routing mechanism, and can scale more safely and effectively with the addition of new brokers.

Comments are closed.


Copyright 2015 Comet Daily, LLC. All Rights Reserved