Distributed Technology

Distributed objects technology

This technology virtually hides the network from the designer and programmer. A distributed object is an object which is resident on one computer and for which methods can be invoked associated with code resident on other computers. A good distributed objects technology should totally hide the underlying communication details from the programmer, for example when a programmer wants to invoke the method  to an object called  on a server, then the programmer should produce the code

in the same form as if the object was contained in the computer in which the code is resident. There should be no references to ports, sockets and server sockets.

The vast majority of distributed objects schemes involve the generation of 'under the bonnet’ code which carries out the actual processes of sending messages to objects and transmitting the data associated with such messages.

Two distributed objects technologies are CORBA, which is a multi-language technology, and RMI, which is a Java-based technology.

Distributed objects technology works by intercepting calls to distributed objects and executing system code which carries out the process of locating objects and sending data and execution instructions. All this is carried out ‘under the bonnet’ with the programmer not being forced to include communication code. The architecture of a distributed objects system is shown in Figure 2. Here, a number of objects spread around a collection of computers communicate by invoking methods, all data transfer being carried out by means of arguments to the method calls which correspond to the messages.

Figure 2 A distributed objects architecture

The main advantage of using a distributed objects scheme lies in the fact that it has a 100 per cent fit with object-oriented technology: that classes identified during the analysis and design phases can be immediately implemented in terms of classes in some programming language, deposited on some remote computer which forms a component of a distributed system and reused without any modification.

The main disadvantage with distributed objects currently being experienced by developers is that their performance, certainly compared with message passing technologies, is inferior.

The mechanisms for developing distributed objects are straightforward and involve either processing source code or an intermediate language.

Many of you will already be familiar with event processing if you have developed visual interfaces with the later versions of Java. Developing such an interface consists of a number of steps:

• A visual object such as a button is placed in a container such as an applet or a  object.
• An object such as a container implements a listener interface.
• Methods in the interface which the container implements will react to events such as a button being clicked or a pull-down menu being activated and an item selected. The code for these methods is provided within the container class.
• Finally, code is placed either in the constructor for the container or in the  method for an applet, which registers the container as a listener to certain events such as a button being clicked.

This model of processing is based on code being written which responds to events such as a button being clicked, a window being closed and text being deleted from a text box.

The same model of processing is used in bus architectures. An example of such an architecture is shown in Figure 3. Here a bus connects a number of listener objects to a transmitter object which sends data along the bus. When data appears on the bus each listener object is executed to read and process the data.

In order to listen to data which is being transferred across a bus the listener objects have to be registered with the bus in the same way that event handlers need to be registered when developing visual interfaces.

An object bus is very much like a radio transmitter in that listeners to a radio station tune into a channel and receive data (sound) transmitted by the radio transmitter. In the bus architecture listener objects tune into a channel (subscribe) and receive objects which are dispatched along the bus.

Figure 3 The object bus architecture. In this figure only one channel is shown, there may be many more.

The model here is somewhat different to that of the distributed object model. In that model, objects communicate with other objects via method calls; invariably the client initiates the processing with the server being a passive entity until it receives some request for a service. This is an example of pull technology where clients pull data from servers. The object bus model is an example of push technology where the server is pushing data out to the clients which, when they receive it, carry out some processing action.

The object bus architecture is particularly well suited to applications where realtime events are being generated and have to be processed by a dynamically changing collection of listener objects. Typical applications include:

• The delivery of stock market data to financial subscribers on a real-time basis.
• Teleconferencing applications where messages from conference participants have to be broadcast in real-time to other participants.
• Distributed multimedia applications such as video on demand where large chunks of data have to be delivered to subscribers on a real-time basis.
• Conversational applications such as chat rooms where a number of participants communicate with each other in real-time.

Architectures

4.2.1 Hub and spoke architectures

There are two main types of bus architectures. These are hub and spoke architectures and multicast bus architectures. Figure 4 shows a typical hub and spoke architecture.

Figure 4 A hub and spoke architecture

It consists of a central hub object which carries out the transmission of data to listener objects. Each listener responds to the event of objects being dispatched to the hub object from a transmitter object which produces the objects to be broadcast. In such an architecture there might be one hub object per channel or a single master object serving all the channels.

This type of architecture is one of the easiest to implement since it can be developed using base technologies such as RMI or  and  objects. It also has the advantage that since all objects pass through the hub object, accounting and management functions can be centralised on this object. The main disadvantage of this approach, as compared with the multicast bus architecture approach, is that it can generate large amounts of traffic. There is also a reliability problem in that when the server containing the hub malfunctions the whole system goes down.

Multicast bus architectures

This form of technology, like the hub and spoke approach, allows the broadcasting of messages to a number of receivers. Some of the implementations of bus architectures are rooted in multicasting, a technique which allows data to be broadcast to a number of clients. However, some, like the industrial example iBus detailed later in this course, are a sort of software implementation of an Ethernet, where objects are sent down a bus and only processed by any receiver that requires the object; if it isn't required it is passed on to the next receiver.

Figure 5 The multicast bus architecture

Multicasting

Multicasting can be thought of as a primitive form of broadcasting of packets. It is carried out using Unreliable Datagram packets (UDP) that are broadcast out on a multicast IP address. Because it is based on UDP, multicasting will suffer from loss of packets when a network is congested. In Java multicasting is based on the  class which is an extension of the  class.

The architecture of a simple multicast bus architecture is shown in Figure 5. It consists of a transmitter object which sends objects along a multicast bus; attached to the bus are a number of listener objects which are activated when the event corresponding to the dispatch of the object occurs.