What does stub do on the server side ? And what is a skeleton ?
Th
I'll only address the question of why the stub needs to be on the server side as well as the client side. Th other question has already been answered.
When an exported remote object is passed to a remote object, as either a method argument or a returned value, the following happens. A stub is created on the server machine. Then it is serialized, sent across the net to the client machine, and deserialized there to make an identical copy of the stub. After that, the stub is no longer needed on the client machine.
Here is a typical scenario.
So one use of having a stub on the server side is so that it can be serialized and (a copy of it) sent to other machines, for example as part of binding. In a similar way, when a client does a lookup, the registry serializes a its copy (ss1) and sends it to to client.
A stub for a remote object acts as a client's local representative or proxy for the remote object. The stub hides the serialization of parameters and the network-level communication in order to present a simple invocation mechanism to the caller.
Alternatively, consider a program running on one machine: each method is a branch. When you move the method to a remote machine, you cut off the branch, leaving a stub which contains only communications.
Source
In the remote JVM, each remote object may have a corresponding skeleton. The skeleton is responsible for dispatching the call to the actual remote object implementation.
And a skeleton I regard as a first implementation - something that satisfies the calling convention, performs a partial operation, and completes satisfactorily.
Form Oracle
The key to understanding "stubs" and "skeletons" is to understand the concept of marshalling:
What Is Data Marshalling?
Marshalling (computer science)
How RPC Works
The rmiregistry is just a lookup facility; nothing more. When a server does a bind()
, it "registers" itself with the rmiregistry. When a client does a lookup()
, he checks what's registered on the server. Nothing more, nothing less.
I don't think it makes sense to quibble about terminology like "skeletons". If you prefer, you can call everything a "stub". The point is, both are PROXIES, both do MARSHALLING, one side exists under the client (that the client calls into), and the other side exists on the server (the skeleton calls into the actual server code).
Hopefully, my explanation and example helped in your another link helped (at least a little).
The first thing you need to do is forget about skeletons. They have been obsolete since 1998.
The stub is created by the remote object when it is exported. It is then either bound to the Registry and obtained by the client via a lookup, or else it is returned directly to the client as a result of another remote method.
The client then uses the stub as an implementation of the remote interface concerned, to perform the networking part of RMI, interacting with the server JVM to eventually invoke the same method in the remote object that the client is invoking in the stub.
look at the followed picture:
To be short,stub and skeleton are counterparts in a web service setup. Skeleton belongs to service provider side
and stub belongs to receiver side
. At lower level stub and skeleton communicate with each other.
From client side the business objects communicates with stub objects and stub takes the responsibility form the message and invoke the web service. Once the invoking is done, at service provider side, skeleton is the parallel object for stub and it receives the request message and understands it and passes on the information to service side business objects.
Stub: A stub is a small program routine that substitutes for a longer program, possibly to be loaded later or that is located remotely.
Skeleton A skeleton for a remote object is a server-side entity that dispatches calls to the actual remote object implementation.