|
Publish-subscribe model connects Tokyo highways
Publish-subscribe models are well suited for systems with a large number of data consumers that receive subsets or entire data sets from centralized producers. The Object Management Group has standardized the Data Distribution Service (DDS) for Real-Time Systems, with implementations offering an API that can aid designers in creating distributed systems.
Connecting servers, kiosks At the core of the Tokyo Highway Line network is a central information server linked to 100 or so information kiosks along the highway system (see Figure 1 for a typical kiosk). The drivers and passengers stopped in parking area rest stops can get information on traffic conditions, projected arrival times to particular locations, alternate routes, and enforcement points where traffic is being redirected or controlled because of obstructions in the roadways caused by construction or accidents.
The publish-subscribe communication model the highway line network managers chose uses asynchronous message passing between concurrently operating subsystems, connecting a variety of anonymous information producers with many other equally anonymous information consumers. In such a system, when a data producer (central office server) publishes some data on a topic, all the consumers (kiosks and terminals) subscribing to that topic receive it. The data producers and consumers remain anonymous, resulting in a loose coupling of subsystems and a robust service that decouples participants, provides location transparency, and provides flexibility to dynamically add or remove elements. At the center of the Tokyo network is a Windows Server 2000 system backed up by a Solaris 8 system, with terminals based on Windows XP. Most network nodes are similarly diverse, using Cisco 3661, 3640, and 1720 routers for the backbone. The current terminals are served by network connections with a minimum of 256 Kbps bandwidth. However, local conditions – humidity, nearby electrical activity, and other factors – can sporadically reduce the data rate to and from the terminals to about 64 Kbps. Designing to the API DDS does not require that the system designer get involved in the underlying communications protocols. The developer need only tell the system what the bandwidth constraints are, the information needed at each node, which actions must be taken, when to send or receive it, and what is required in response. Instead of a direct, active link to a server in which the client is required to query for updates, the DDS implementation is very information-centric and does not require such active linkages. This allows the Tokyo system developers to simply tell the DDS API what information is needed at which terminal and on which schedule. As a subscription protocol, the system designers can designate the quality of service and delivery profile beforehand rather than negotiating each time a transaction is initiated. As network middleware, the publish-subscribe DDS is independent of underlying software. This helps designers:
Unlike traditional client/server protocols, which operate synchronously and require constant link updates, DDS is asynchronous and anonymous. This allowed the Tokyo system developers to focus on the content to be delivered, leaving DDS to determine when, where, and to which user subset to deliver it. With enough bandwidth, DDS can allow delivery of the same content to all recipients; without proper bandwidth, it allows the developer to determine which terminal needs which subset of information dictated by its location on the highway system. In the DDS implementation the highway system network developers deployed, data is fed to each Web browser-enabled terminal in HTML format, and user requests for information are delivered back to the central server in the same format, with data on general traffic information updated on one or all clients once a minute. Increasing robustness To utilize a robust system relatively immune to such problems with minimum software overhead on the servers, terminals, and routers, the highway system engineers implemented the DDS system as a paired publish-subscribe configuration. This allowed the system engineers to endow their publish-subscribe-based system with some limited two-way communications capabilities. One of the DDS pairs allows the server to deliver information to the terminals, while the other collects information in the form of statistics from the terminals and kiosks.
Implementing a publish-subscribe network gave the design system enough flexibility to compensate for the contingencies that might occur, for example, switching out one server for another during system maintenance or breakdown. Other contingencies they had to plan for included accidents or construction work that might disrupt communications and unanticipated heavy traffic from the terminals by more drivers requesting information, causing congestion on the network or at the server. DDS, in particular, allows some of its attributes to be modified, accommodating a variety of network conditions such as performing a slow declaration to avoid packet flooding at system initialization or when all the terminals must be rebooted. Extending into the future Plans are under consideration to use publish-subscribe more broadly, especially if more physical network links are added to support highway system maintenance and operation. In addition to linking to designated terminals and drivers, the DDS system could work as an efficient vehicle for multicasting information from the central office servers to the field personnel responsible for highway line maintenance. Unlike most network configurations that rely heavily on the underlying hardware or software, this simply does not matter to DDS. If designers opt for a heterogeneous system with servers and terminals based on different types of processors and running multiple OSs, DDS’ publish-subscribe can be adapted. While current connections to the terminals are based on standard Cisco routers over copper cable, Tokyo’s highway system engineers are looking to expand the network with a variety of other network connections: wireless, copper and optical cable, power line, and even telephone wiring. Unlike many standard network protocols’ performance, which depends heavily on available bandwidth, publish-subscribe is much more forgiving and can work with minimum bandwidth.
|
|
||||||||||||||||||||||||||||||||||||||||||||||||
 |
 |
©MMIX Industrial Embedded Systems. An OpenSystems Media publication.
About this Magazine and Website | Contact Us | Industrial Embedded Systems Media Kits