|
Eric Gunnerson: I'll give you my opinion, which may not be the opinion of the CLR guys. First of all, the idea of exchanging code across the network scares the hell out of me from a security standpoint. One of our big focuses is trying to allow people to write stuff that is more secure than what they're writing now. But I guess my big question is, what is the architectural advantage of using mobile code? Maybe I haven't played around with it enough, but I just don't see a lot of need for doing that on the fly. If I want to do that in .NET I can. I can go across the network and fetch some code. I can load the code out of memory, I don't have to write it out to disk first. In other words, the package of a component is an assembly. I could read a byte stream and from that create and load an assembly. So I can do that sort of thing, but why would I want to architecturally?
One of the primary advantages of mobile code is the ability to change the clients interface to the server when you really need to, and not have to introduce a new client. With Java RMI, you might start out with a whole collection of simple stubs that provide remote proxies that client software uses to talk to a 'service'. If you need to optimize caching or provide some other change in protocol, you can convert those 'stubs' to 'smart proxies' which are just more downloaded code (other than the proxy) that can carry an object reference to the new stub, but provide the old interface in addition to a new interface, or changed caching or interaction strategies.
In particular, it is very vital in a mobile network environment to allow a client to try multiple servers. You can either deploy this code as part of the client if you don't have mobile code, or you can deploy it from the server as mobile code so that you can administer the set of alternate servers, change the parameters or change the implementation at will, with all clients getting the changes automatically.
The 'agent' crowd has a whole other set of examples of how mobile code can be used to allow you to do things that are not possible with simple messages.
And still the primary issue with SOAP is that everyone has to write code to convert the SOAP transported data into a set of objects specific to the platform that the data is received in. If you just use Java and the RMI model, you get a Java language object that is ready for use, and this means that as the originator of the object you have more choices of how to transport and represent the internals, and as the receiver, you just know that the object implements a particular interface or is extended from a particular base class.
The Jini lookup server uses interface/class equivalence for finding services. This makes it possible to ask for things based on what they do for you instead of based on where they are, or who created them. The deployers of such Jini services then have the ability to change everything as long as the same interface or class is presented to the users. This makes the system much more flexible, and lets you deploy services in trials more readily, and to change them at will without worrying about how they'll be located. In fact, moving services between machines becomes completely invisible to clients because they are using multicast to find lookup servers and asking for services by implementation instead of by name.
Also, the Jini 2.0 security model allows the LUS to demand proper identification to register services, and allows clients using the lookup server to demand proper identity before using offered services. Thus, you really can secure your systems on a public network by using application level security without having to worry about what the network is letting through...
|