Frank Sommers
Posts: 2642
Nickname: fsommers
Registered: Jan, 2002
|
|
Re: Thinking out loud, and in public...
|
Posted: Mar 29, 2003 7:36 PM
|
|
>In short: do you think that with the introduction of > faster computers, faster networks and higher bandwiths the > need for mobile code lessens? >
I'd say just the opposite: Faster networks will invite more mobile code. I'd also argue with your notion that mobile code is needed in order to offload computation to a remote entity. That may be one reason to use mobile code, and perhaps the simplest one. But I like to think of mobile code as moving "capability" to some remote entity. It's a sub-specie of mobile data - data that enables the receiver to do something it couldn't do before.
For instance, we did an experimental system aimed at high "survivability." In that system, you have Java objects that are executing, going about their business. But at some point, those objects encounter exceptions. And some of those exceptions may be special, in that they are marked with an interface as "recoverable." When an object encounters such an exception, it doesn't know how to recover from the exception itself. But this recoverable exception object, when instantiated by the Java runtime, goes out on the network and discovers a "solution" to the problem at hand (using Jini, as you may have guessed). That solution comes in the form of code downloaded into the client. That code is then passed some client-side context, and is then able to execute operations on that context that allows the object to recover from the initial failure (or, at least, increases the chances that it could recover).
I don't think that scenario could be built using just mobile data (e.g., XML), because you need to download executable code in the form of those downloadable exception handlers. It's similar to an emergency service: When you call for an ambulance, they don't just hand you an emergency box and leave you with it. They come, and try to use their tools to help you out - i.e., they perform some actions at the scene.
To be very honest, I'm not sure I fully understand the implications of mobile code, even after several years of working with it. In the example I just mentioned, one implication of mobile code is that system doesn't have to be "complete" to start functioning. When you're developing such a system, for instance, you may not code up all those exception handlers up front. You may release the system, and then "inject" handlers into the network (by registering them in lookup services) at some later time. So, you have a running system that is, in some way, incomplete. It also means the exact behaviour of the system is hard (impossible) to predict, i.e., a system's performance model becomes even more probabilistic (and in more complex ways).
But that's just the tip of the iceberg...
|
|