The object reference used by the client in the previous lesson functions as if it is a reference to the remote CORBA object. In fact, the reference is really a reference to a stub. Thus, understanding the structure of the stub classes will deepen your understanding of how CORBA clients really work.

A stub looks like the remote object it serves as the proxy for because the stub implements the signature interface for the remote object. As subclasses of org.omg.CORBA.portable.ObjectImpl (which implements org.omg.CORBA.Object, the CORBA equivalent of Java's root java.lang.Object class), stubs inherit basic CORBA object functionality. The core part of a stub's code is an implementation of the corresponding interface that performs the marshalling and unmarshalling of invocations to the server. Local stubs are subclasses of regular stubs, which provide an optimization for calls to objects within the same VM.

package weather;

public class _WeatherServiceStub
 extends org.omg.CORBA.portable.ObjectImpl
 implements weather.WeatherService
{
 private String[] ids = 
   {"IDL:weather/WeatherService:1.0"};
 public String[] _ids()
 {
  return ids;
 }
 public java.lang.String getReport
   (java.lang.String city)
 {
  //  ... Marshalling/unmarshalling code to send over
  //request and parameter, get the result, 
    and return it.
 }
}

It is worth understanding what the stub does, but, unlike the skeleton, it is generally not used directly by you, the developer.
In the next lesson, you will learn how stubs are actually instantiated by helper classes when clients narrow object references.