Location Transparency based distributed communication framework

Location Transparency based distributed communication framework

Let us understand whenever in systems there is a problem of moving objects or dynamic objects, immediately we will have the concept of location transparency and hence there has to be some proxy to enable the same.

If we notice closely, most of the software systems that we use are designed for location transparency. Think about it whenever you access a software application are you bothered about the actual location where the software is installed? I hope we will realize that most of the software systems are designed in such a way to the user it looks as if the software is local to the system although the software can be deployed anywhere in the world or its location can be changed anywhere anytime without the user being aware of it.

Hence location transparency is today an implicit requirement while designing any software application. This is only possible because of the multitude of location transparency based middleware available today for example CORBA, DCOM, RMI, EJBs, WebServices etc.

As we can understand some form of proxy should be responsible for enabling this.

In the next section we will discuss the basic framework of any location transparency based distributed communication framework. Most of the commercially available middleware will follow this architectural model with some variations. Once a person is comfortable with the basic building blocks of this fundamental framework understanding any commercial middleware will be very easy.

In the below mentioned scenario , there are two parts , the client side and the server side.

Whenever an Object (Remote Object) has to be remotely available, we will have to first write the remote interface for the remote object. Remote Interface is basically a set of behaviors or method signatures that has to be remotely available to its users. Usually the Remote Interface can be written in various languages depending on the type of middleware.

Figure- Figure

In CORBA which is a language and a platform independent middleware, the Remote Interface is written using IDL (Interface Definition Language). IDL is a language neutral way of defining any Interface.

In RMI , simple java interfaces are used to write the remote interface.

In EJBs again a simple java interface is used to write the remote interface.

In Web services, the remote interface is described using WSDL (Web Service Definition Langauage) which is again a neutral way of defining behaviors.

In a nutshell , the Remote Interface has to be written for the remote object.

Once the Remote Interface is written, this interface has to be given as an input to a utility tool provided by the framework.

Figure- Figure

This utility tool then generates a set of classes based on the Remote Interface. Among the set of classes generated by this utility tool, there are two very important classes viz the Stub and the Skeleton.

Figure- Figure

Stub – Stub is simply a specialized remote proxy which apart from acting as a remote proxy has the marshaling and the un-marshaling logic.

Marshalling and Un Marshalling – As we know internet is the fundamental communication mechanism which is available today. Any interaction between the object is always done using the internet. We also know that the data travels over the internet in a binary format. So Marshalling is the process of converting the method signatures and its parameters into the binary format so that it can be transmitted over internet while unmarshalling is the process of regenerating the return parameters and other details from the binary format.

Since stub is a remote proxy, it will have the same interface as that of the Remote Interface and second it has a reference variable which points to the location of the actual remote object which has to be transparently hidden.

Skeleton only has the marshalling and unmarshalling logic.

Once the stubs and skeletons have been generated, we need to write the implementation class for the Remote Interface.

Figure- Figure

After all of the above mentioned steps, we need to instantiate an object of the implementation class in the address space of the server process. This is usually one of the steps of the deployment phase.

Figure- Figure

Usually there are three steps to be followed in the deployment phase

  1. The object of the implementation class is instantiated in the address space of the server process.
  2. The reference of this object is provided to the stub
  3. The reference of stub is binded into the naming service wrt a unique name.

In the client address space, whenever the client needs to interact with the remote object, it does a lookup on the Naming Service using the unique key .

Figure- Figure

If there is a matching record for the same, the stub gets downloaded into the client address space.

Figure- Figure

As mentioned earlier, in primitive middlewares the stubs had to be physically transported in to the client address space while in some latest middlewares the Stubs can be loaded dynamically into the Client address space. In any case the stub is supposed to be available in the client address space while the Skeleton is available in the server address space.

Figure- Figure

Now whenever the client invokes a remote method on the remote object, the stub intercepts the call as the stub has the same interface like the remote interface. Also as the stub has the actual address of the hidden object and the marshalling logic, it opens a connection to the memory location, marshals the parameters and the call travels through the transport layer (the internet) and reaches the skeleton. The skeleton which has the unmarshalling logic, unmarshalls the parameters and then the call is dispatched to the actual object in the server address space. At this stage I am just explaining at a very top level, there are a lot of other internal activities and patterns involved which will be explained in detail in the component container architecture model. Once the method of the actual remote object is called , it does the required business processing. Any return data is again passed back to the skeleton which again marshals the same and is transported back to the stub via the transport layer (ie the internet). The stub now unmarshalls the data and then returns the actual return value to the client. To the client it looks like that the remote object is in the same address space while actually it is in a different address space, this is only possible because of the “Stub” which acts as a remote proxy.

This is how any location transparency based middleware will mostly function.

As we know proxy can always be used whenever we want to transparently hide something.. like the way remote proxies are used to transparently hide the location of the target object.

Can we think of any other thing within systems that needs to be transparently hidden?

To help understand the same, let me share with you an example of an “E Greetings Portal” like www.123greetings.com

Hemant Jha
Founder - VPlanSolutions
Researcher, Trainer