Achieving Software Mobility

Introduction

Can we have software move from one machine to another on its own. We certainly can. Mobility of a software on its own opens a whole new door to the way we think of consuming services on servers. To consume a service from another machine, the general or more talked ways are to invoke a web service or to make a RPC/RMI call. But if we can introduce the attribute of mobility in a software, it can travel to another machine and consume a service and either hop to more servers or come back home.

Background

Let's first try to understand a bit about remote method invocation before I move down to object mobility. Remote Method Invocation (RMI) is a common way nowadays via which we can have services or objects residing on remote machines and can call those functions from a local machine.

It’s pretty interesting how it is done. Over here, we will not go into the details of how it is implemented, but simply here is a picture that might help you visualize what is going on.

The coding complexity is not huge but what is happening under the hood is a bit tricky to understand. Again in short, using RMI we can actually call a function of an object which is not residing in the same machine.

Software Mobility

Now, what if instead of our software being able to call a function on the remote object we could have our object itself travel over the network. Sounds interesting, then fasten your seat belt and read on how it is done.

This is a pretty interesting concept called Object or Agent mobility or in more general Terms Software Mobility. We can send in an object over the network which will wake up on another machine and then it can do some specified task, and then come back. Pretty interesting isn't it. Here is a picture to visualize it.

So now what we have here is instead of calling a function of a remote object we are sending our own object to go to another remote machine and do some processing over there and then come back with results. If we can make our objects intelligent and they have mobility then we can do wonders.

The implementation portion is not rocket science at all so here is a bit of idea how it is done. It is two fold:

How to transfer objects from one machine to another

How to receive and send back the object

The first question is simple to answer. We need to learn how to transfer objects via networks. Be careful to serialize the class whose object you will be sending across the network using Serializable attribute. I will let the reader figure out how to transfer an object over the network using a TCP Connection. I will just say it can be done.

For the second question, we should make our server aware of the fact that they will and can receive such objects, so on receiving such an object it will know which function of the object to call to start the object and the object should in turn know which function of the server to call to be able to get back home. As the Sever should have some mechanism to throw back an object, the server will get the home address (home IP) of the object from its data and then throw him back functions. Therefore in short there should be a specified interface an agent should follow so that based on that interface the remote machine can call up some functions of the agent. And also the server should have a defined interface so that the agent can call the remote machines function. For a bit more clarification, here are interfaces that may get you started off.

IMobileAgent

interface IMobileAgent
{
/**
* An AgentServer invokes this method. It is used to tell an agent
* This method should invoke the method start of the object that
* represents the agent.
*
* @param Srv - reference to that server object that received the agent object
*/publicvoid AgentArrived(IAgentServer Srv);
/**
* Print results extracted from different servers
*
*/publicvoid PrintResults();
}

Apart from the implementations of these interfaces, you will need another class or function which will create, initialize the object and throw it to a server and wait to receive the object back, when it is thrown back by the server.

Please note, the server should be listening on a specified port all the time and will receive the objects. On getting an object, it will call the objects' AgentArrived(…) function. When the object decides it wants to go back home, it will call the servers AgentSendBackToHome (…) function. The agent might or can travel to another server instead of going home and that can be achieved by the agent calling the servers AgentMigrate(..) function.

Points of Interest

An example and usage of this object mobility is in distributed search, where we can have multiple agents with different AI in them travelling to different servers and extracting information and then coming back from where they started. All the results of the agents can be deduced to a meaningful search result. For a moment, think wild and I am sure you will come up with a dozen other useful things you can do, since now you know something like this can be done. And on top of it, is it not cool that your software is actually roaming around the network.

I hope this post sheds a bit of light on Object mobility. And now its time to play around with this and make interesting stuff. Have fun!

Looks like you don't know what "marshal by value" is. Because it exists for ages (in numerous languages/platforms) and does exactly what you presented here as an "innovative" idea. Just pass any marsha-by-value object in parameter of a service method, call any method of this object on the server side and get it back in service method's return value. That's it, man.

Thank you for your comment. I am not sure if you read the whole article before jumping into conclusion. I will like to get a few things clear here. No where in the post do I say it is a NEW "INNOVATIVE" idea I have presented. I have claimed besides RMI and webservices this is another way of doing things !

And you are taking about "marshal by value", this is not exactly the same thing as what I presented here. In marshal by value you are sending the object or getting the object back by calling a service method, correct me if I am wrong, you will need to use RMI to do this right ? This is what I said can be avoided and simply your objects can be send via the network where on the other end you will have a server waiting for a object to come. And when it gets an object it will wake it up. The object will perform some functionality in the server side and when it wants to go back, "WHEN IT decided on its own to go back" it can call a function of the server which will throw him back in the network. Plus it can instead of just going back it can travel to more Servers and then finally decide to go back.

Let me give you a scenario and you tell me how you would go about solving using your "Marshal by value". I want to make a Distributed search environment, where my object is assumed to be intelligent and it will roam around server to server until it finds a file. Now can this simply be done using the technique you are talking. I think not as using a service method binds you to "One shot mobility". Your objects goes and come back in the return of the service method. This does not give software mobility as we are perceiving the notion of mobility to be "FREE MOVEMENT AROUND THE NETWORK".

I am not saying this technique does wonders, let me repeat, I say its another way of doing things and its exciting when you can have your objects roaming from one machine to another and another and then come back with a set of results from where it was set off!

Well... you by "object" you mean instance data and class code containing methods to act on this data, then just use any of Grid Computing solutions/platforms. That's exactly what they have been developed for.

This is a very abstract concept and too many issues unanswered i feel.
For one generally the object you want to xfer might have many dependencies which need to be xferred also and what abt the environment in which it will run ?
If these are xferred also or present in the xferred system already I don't see what adv they are providing over 'asynchronous' web services.

As for as the objective of the article is to get one familiar with the basic concept that objects can travel across the network from one machine to another. For the host environment, if one generalizes his own servers the capability to receive objects, that is implementing the interface given then those becomes the host for receiving agents/objects. Now the advantage over web service is that the functionality is performed by some function on the server and some data on the server. So the function on the server will provide you with some fixed algo by which you can process some data on the server. Ok now if you want another algo to be run on top of this data you have on the server you have to add another function on the server. Where as if you are using object mobility then you have the utmost control of what type of algo you want to run on the data on the server side. This is just one of the advantages I see of using this approach. Obviously it has lots of draw backs, one would be sending this objects require more data to travel across the network rather than sending a simple request for a a service.

The notion "State of object" can be realized of what data it is collecting. One way to do this is by simply storing them in a member variable of your class. As the object moves from one machine to another it will automatically have those values as when you are sending the object you are serializing it. Hope this answers your question.