25

What does stub do on the server side ? And what is a skeleton ?

from wikipedia

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 ?

Matjaz Muhic
  • 5,328
  • 2
  • 16
  • 34
program-o-steve
  • 2,630
  • 15
  • 48
  • 67

7 Answers7

24

look at the followed picture:

skeleton

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.

Community
  • 1
  • 1
aMooly
  • 551
  • 5
  • 13
8

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

http://www-itec.uni-klu.ac.at/~harald/ds2001/rmi/rmi.html

Matjaz Muhic
  • 5,328
  • 2
  • 16
  • 34
  • Is it that stub on the server machine is known as skeleton ? The same stub that is on the client machine ? – program-o-steve Dec 21 '11 at 08:04
  • 1
    Skeleton is just a stub on the server side. I think. It's been a long time since I used RMI in college... :) – Matjaz Muhic Dec 21 '11 at 08:22
  • how it is different from the stub on the client machine ? – program-o-steve Dec 21 '11 at 08:27
  • 4
    The difference is exactly what I described in my answer: Stub is responsible for marshalling (converting) the calls to java objects to a network-level "calls" and the skeleton does the same but in reverse order. It unmarshalls (converts back) the network-level "calls" to the java class calls. – Matjaz Muhic Dec 21 '11 at 08:41
  • 1
    when i kept the same .class files on the server and the client how do they act different ? Can you please explain – program-o-steve Dec 21 '11 at 08:52
  • >The skeleton is responsible for dispatching the call to the actual remote object implementation. Is this true, the skeleton is serverside, the stub is client-side. That way skeleton is meant to receive the client-side call (convert serialized object to real object) – Raja Nagendra Kumar Jul 23 '20 at 06:30
7

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.

user207421
  • 305,947
  • 44
  • 307
  • 483
6

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).

J.Hpour
  • 971
  • 11
  • 20
paulsm4
  • 114,292
  • 17
  • 138
  • 190
3

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

enter image description here

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

Community
  • 1
  • 1
Premraj
  • 72,055
  • 26
  • 237
  • 180
3

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.

Shabbir
  • 273
  • 4
  • 7
1

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 server machine.

Here is a typical scenario.

  • On the server machine S, an object s is created and exported.
    • Part of exporting is to create a stub for s; call it ss0.
  • Machine S executes 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 reference 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 its copy (ss1) and sends it to to client.

Theodore Norvell
  • 15,366
  • 6
  • 31
  • 45
  • The stub is created once when the remote object is exported, not every time it is used as a parameter or return value. Your bullet points are therefore also out of order. 'After that, the stub is no longer needed in the client machine' is also incorrect, and your use of 'server' and 'client' is merely confusing when you are also talking about both parameters and return values. – user207421 Jan 06 '17 at 02:53
  • The registry doesn't keep a pointer to anything. It keeps the stub. You mentioned `ss1` before defining it, but all this talk of `ss0/1/2` is pointless. They are all copies of the same stub, as is 'the serialized version of `ss0`'. There is no need to talk about the 'server-side stub' and the copies as being different things. They are all just 'the stub'. – user207421 Jun 29 '17 at 00:03
  • ss2 was a typo. Fixed. Thanks. If you don't like the word "pointer", then "reference". The stubs in different VMs are different objects. They may represent the same thing, but they are different objects. The OP wanted to know why there is a stub object on the server's VM. This is what I am explaining. The two answers currently with the most upvotes (aMooly and Matjaz) don't address this part of the question. – Theodore Norvell Jun 29 '17 at 01:10