Frank Sommers
Posts: 2642
Nickname: fsommers
Registered: Jan, 2002
|
|
Re: Running Jini1.2 how t get rid of the stubs??????????
|
Posted: Feb 25, 2002 4:53 PM
|
|
Jini, per se, doesn't need stubs. Stubs are something you need for remote method invocation. Not only RMI, but many other RPC technologies also rely on the use of stubs. In essence, a "stub" is a little piece of code that "stands in" the place of a remote object and, typically, simply forwards method invocations to, and return values from, the remote object.
There are RPC mechanisms not dependent on stubs -- for instance, you can use IP multicast messages, etc, Jini allows any of these RPC mechanisms to be used. Jini even allows you to use no RPC mechanism at all, and to use instead straight TCP sockets, HTTP, or even implement a service so that it doesn't make any network connections from the client.
That said, whatever piece of code represents the service on the client side, that code must be available at the client, i.e., that code somehow must moves to the client. Jini specifies that "RMI semantics" be used for mobile code. In the simplest terms, that means that when you ship an object, you annotate a codebase URL to the serialized form of that object. If you use straight Java object serialization (you can use any mechanism to do that, btw), serialization "marshalls" the object's instance representation to an output stream, and then marks the classes those objects belong to with something called a ClassInfo. If the client doesn't have the class represented by these ClassInfo markers, it must download it from somewhere on the network, and that's when the "RMI semantics" of code mobility come into play.
So, if you write the URL(s) where a client can download the classes from at the end of the marshalled stream, the client can create class loaders corresponding to those URLs, and load the classes from there. The client's programmer doesn't have to be aware of those chunks going down the wire (but he does need allow code to come into the client from the network, and hence install an RMISecurityManager).
In summary, stubs are for remote procedure calls, not for Jini. Now, the current implementation of the Jini specs by Sun actually uses RMI underneath, so it does rely on remote stubs (but that's mostly hidden from you). It's mobile code that requires that a client somehow can download code from the network -- whether that code is needed for deserializing stub objects or any other type of object the server provices.
Hope this helps.
Frank
|
|
Previous Topic
