What does stub do on the server side ? And what is a skeleton ?
This is a diagram from wikipedia. I installed stub both on the server machine and the client machine. I understand that stub helps in the networking on the client side but what does stub do on the server side ?
Also in the above figure what does skeleton mean ?
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 and skeleton both hide some complexity.
The stub hides the serialization of parameters and the network-level communication in order to present a simple invocation mechanism to the caller.
The skeleton is responsible for dispatching the call to the actual remote object implementation.
http://docs.oracle.com/javase/7/docs/platform/rmi/spec/rmi-arch2.html
The first thing you need to do is forget about skeletons. They have been obsolete for 13 years.
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.
The key to understanding "stubs" and "skeletons" is to understand the concept of marshalling:
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).
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.
Stub
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
Skeleton
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
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.
- On machine S, an object s is created and exported.
- Part of export is to create a stub for s; call is ss0.
- Machine S calls Naming.bind with s as argument.
- The server side stub ss0 is serialized and sent to the registry's machine R.
- The serialized version of ss0 is used to create a copy of ss0 R; call it ss1.
- The registry on R keeps a pointer to ss1.
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.
来源：https://stackoverflow.com/questions/8586206/what-is-stub-on-the-server-and-what-does-skeleton-mean