History


Previous experiences

The need for sending messages to whoever or whatever is interested in receiving the data is not new. Consider the situation where one person buys some shares of company XYZ for $100. Ideally, all traders interested in that same stock would want to see the new price immediately on their screens. Another implemenation is the control room of some sort of chemical plant where more than one operator monitors computer screens describing the goings on in the plant. If valve ABC opens, all screens monitoring that valve would need to be updated simultaneously.

Enter the publish/subscribe paradigm.

One or more subscribers register themselves as interested parties for a subject (price of stock XYZ or valve ABC, ...) Later, whenever a piece of information is published on that subject (stock price, valve position, ...) all subscribers will receive that same piece of information.

The publisher does not need to know how many subscribers are interested in the information or what their network addresses are. Also, the subscribers don't need to know what the addresses of publishers are. All that is required is that both publisher and subscribers aggree upon the subjects being used.

A number of commercial packages already implement such functionality (and much more), so the idea is most certainly not new.

In the past I already implemented this sort of functionality within one single Java VM, using static variables. However, that approach has the serious drawback that messaging occurs only within one single virtual machine (actually, within one namespace inside a virtual machine)

New requirements

Recently I wanted to develop a sort of emulator software. A very important aspect of that software is that it should be possible to monitor the system externally, even on other systems, and that commands can be sent to it, also from other systems.

The static variables approach in Java simply does not offer this kind of flexibility, so I started a network based implementation using multicast communication.

Why not use one of the Sun java tools?

First, it is just more fun to write your own tools ;-)

Second, even if Sun does provide a similar package now, they did not when I last looked on their site (could be due to my poor searching capabilities ;-)) The only related package I discovered there was limited to message exchange within one single Java Virtual Machine.

Third, it looks as if OttoBus will be going multilingual (programming language, that is) and I do not believe Sun will provide much non-java support in java.

It is to be expected for the simulator soft mentioned above, that quite some interaction between a java implementation and a bunch of perl scripts will be used (at least by me)


OttoBus home

Last Update: 10 September 2001