Distributed Objects and Models of Distribution
The distributed objects paradigm is one of the most commonly used models of distribution in distributed computing today, mainly because it integrates well with most object-oriented programming languages. We explore the four major types of distributed object paradigms and look at some other distributed computing models.
The distributed computing paradigm is one in which separate components are located on distant computers and communicate with each other using a number of varying messaging methodologies.
The core idea behind distributed computing is that the network of separate components is seen as a single computer by an end user or developer – the underlying complexity behind the distributed components are abstracted by an interface or middleware solution.
There are four key paradigms of interest when looking at distributed computing:
- Message passing
- Distributed Objects
- Event-based architectures
- Server processes
Message Passing Paradigm
The idea behind the message passing paradigm is that remote objects communicate with one another via the passing of messages. Messages can be sent in two ways; asynchronously or synchronously. Asynchronous messages are those in which the sender doesn’t care if the message has been received – it doesn’t stop or halt its processing to wait for a response.
In contrast, synchronous messaging is that in which the sender actually stops to wait for a response from the receiver before continuing with any further processing.
The message passing paradigm is the lowest level of the distribution models – by this I mean it has the lowest level of abstraction from the underlying mechanisms behind its functionality. It’s commonly used as the underlying mechanism in more complex distributed object schemes, but there are a number of very well-known protocols that rely primarily on the message passing paradigm.
The most popular and important is these is HTTP itself. HTTP, the Hypertext Transfer Protocol, is the foundation for the World Wide Web as we know it and is based on the message passing paradigm. It involves a client (for example a Web browser) sending a request message to a Web server, who in turn sends a response message.
Messages sent through the HTTP protocol must have headers, which contain message codes indicating the type of request or response. Types of HTTP request header methods include GET, POST, PUT, HEAD and DELETE, and some HTTP response codes that you may be familiar with are 200 OK, 301 Moved Permanently, 400 Bad Request, 404 Not Found, and 505 HTTP Version Not Supported.
The message passing paradigm is used when:
- Communication needs are relatively simple
- High performance is required
- Rapid implementation is required
- No existing protocols are available – a new protocol has to be created
Distributed Objects Paradigm
In contrast to the message passing paradigm, the distributed objects paradigm views a distributed system as being comprised of a series of interacting objects. In this paradigm, objects on separate machines invoke methods on objects on remote machines. The underlying technology which intercepts calls to distributed objects, locates the targeted remote objects and physically sends data and instructions to the remote objects is hidden from view from the designer or developer.
The major advantage of the distributed objects paradigm is that it fits perfectly with the object oriented paradigm of nearly all modern software development environments and languages; seeing entities as objects corresponds exactly with programming languages such as Java and C# in which data are defined through classes and instantiated as objects.
Another important advantage of this paradigm is that it provides a high level of abstraction for underlying transport mechanisms such as sockets and transport-level protocols – the average programmer using a technology like RMI or CORBA usually would never have to even be aware of details at the socket level, and can instead focus on programming business logic.
There are four main technologies in use that provide a distributed objects paradigm. They are, in no particular order:
- CORBA – Common Object Request Broker Architecture
The CORBA standard, defined by the Object Management Group (OMG), is a widely used distributed object paradigm that allows separate pieces of software written in different languages and located on different systems to call methods on each other, hiding the underlying complexity behind these calls.
CORBA provides an interface definition language, or IDL, which is a specification language used to describe a software component’s interface in a language-independent way. Each distributed object uses IDL to specify its interface to the outside world. IDL is a key tool in hiding the implementation of each object’s methods – using a language-neutral tool like IDL means that objects can change their implementation without affecting any outside users of the module.
IDL works by allowing distributed objects to specify an interface for their methods so that CORBA can create ‘code stubs’ – similar to header files in C++, a code stub simply describes the method definition and parameters without having any detail of the implementation.
Clients are given these ‘code stubs’, which are essentially function prototypes, by the CORBA architecture, and when they need to call the remote method they call the local code stub instead which is then responsible for packaging the information.
Once a method has been called using a local code stub, CORBA’s Object Request Broker is the mechanism responsible for actually locating the server with the method’s full implementation on behalf of the client. It locates the server, ensures the server is ready to receive the request, unmarshals the method parameters from the client-side code stub and transports the return data (if any) to the calling client.
- RMI – Remote Method Invocation
Another important and widely-used distributed object paradigm is Remote Method Invocation, or RMI. RMI is used in Java to facilitate object method calls between Java Virtual Machines (JVMs) located on separate computers.
RMI works on essentially the same principles as CORBA, in that objects located on remote systems call one another’s methods, but with slightly a different implementation.
A server can register its remote objects with RMI’s simple naming facility, the RMI registry. The RMI registry is basically a place for servers to register its objects and services and for clients to query available objects and services. The below diagram displays the typical connection flow that occurs when a client uses Remote Method Invocation.
Once a client obtains a reference to one or more remote objects on a server and invokes methods on them, the specific details of communication between the remote objects are handled by the RMI and are not necessary for the developer or user to know. Indeed, to the programmer, the remote communication looks just like any other regular Java method invocation.
- DCOM – Distributed Component Object Model
The Distributed Component Object Model is a Microsoft-designed distributed object paradigm in which, similar to the other paradigms, software components can communicate across networked computers. It worked in a similar fashion to CORBA, facilitating marshalling and unmarshalling of method arguments and return values between objects, however this paradigm has been deprecated by Microsoft in favour of .NET Remoting, a part of their .NET Framework.
- XML Web Services
Web services are a method of communication between computers or devices over the Web – the W3C defines a web service as ‘a software system designed to support interoperable machine-to-machine interaction over a network. It has an interface described in a machine-processable format (specifically WSDL).
Other systems interact with the Web service in a manner prescribed by its description using SOAP messages, typically conveyed using HTTP with an XMLserialization in conjunction with other Web-related standards.’
So you can see that the underlying transport mechanism for Web Services is a message-passing paradigm (through HTTP), and it uses SOAP – Simple Object Access Protocol – as the protocol for describing the basic message framework.
Event Based Architectures
Event based architectures are based on a broadcasting concept, similar to event-driven programming in languages such as Java.
For example, in a typical Java program a contain object would ‘listen’ for events for specific interface objects such as a button click, and define methods in response to those events.
Event driven architecture typically consists of event emitters (or transmitters) and event consumers (or receivers). Receivers have the responsibility to response to events as soon as one is detected, and the reaction may or may not be completely provided by the receiver itself. For example, the receiver might only have the responsibility to filter, transform and forward the event to another component or it might provide a self-contained reaction to the event.
There are two main types of event-based architecture – bus and hub and spoke.
In a bus style of event-based architecture, listener objects listen for and receive objects along an ‘object bus’. This style is an example of pushpushes data to clients which they then process. Push technology is the opposite of pull technologies such as the Web client-server model, in which a client pulls information from the server.
Push based methodologies are ideal for a system that handles rapidly changing events, such a system that runs in real time and has a constantly changing environment. The below diagram shows a typical example of a bus style event-based architecture.
- Hub and Spoke
In a hub-and-spoke architecture, a transmitter object sends data to a central hub, such as a middleware solution, which then transmits data to any number of listener objects.
The below diagram shows a typical example of a hub-and-spoke style:
There are a couple of important server processes that are influential distributed computing paradigms. These are traditional ‘client-server’ processing and ‘peer-to-peer’ processing.
In the standard client-server model, by far the most used distributed computing model today, a number of clients send messages to machines acting as servers. Each server can, in turn, invoke a response or send a message to another server, or process information before returning a response to the original client request. The below diagram summarises the typical client/server model.
There are a number of variations to the typical client/server model, such as the use of multiple servers and caches to increase performance and resilience, the use of mobile code and mobile agents, and using low-cost computers for clients (thin client vs fat client).
For example, a single service – such as Google’s search engine, could be provided by multiple (sometimes even thousands) of servers instead of just one, to reduce and balance server load.
Another commonly used variation on the client server model is the use of a Web proxy server, in which clients communicate with servers through an intermediary, the proxy server, as in the below diagram:
You may have also heard of Java Applets – pieces of code used on the Web that are downloaded from a server and then run on a client machine. The client interacts directly with the applet instead of communicating with the server, until more information is requested. This is another variation to the client/server process.
The opposite process to this is the thin client variation, in which application code and processes are run entirely on the server, and the client is only given the task of displaying information to the user – in other words, the client only handles the presentation layer. Thin clients are used when user responsiveness and speed is very important to the application and network latency is low.