It is easy to see that the CORBA Stubs and Skeletons provide the basic structural pieces of a very powerful model. They also make it easier for developers to write CORBA applications, because much of the low-level networking and data transfer functionality is handled invisibly at this level. So let's look a little deeper at this process and ask some important questions about how it all works.

When a client asks the server for a request, it must ask in a manner that the server understands. For example, if the client requests the current temperature, it knows that the server supports a CORBA request called get_current_temperature that accepts a character string identifier and returns a floating point, which is the current temperature. Below are examples of how this call might look in Java and C++.

float get_current_temperature (String id);

float get_current_temperature (const char* id);

The Stub is really the conduit for this information flow. The client asks the Stub for the temperature, and the Stub sends the request on to the server.
The Stub receives the reply and knows how to pull the float return value from the network (this process is called unmarshalling) and passes it back to the client.

The Stub knows how to do its job because the vendor's IDL precompiler builds these capabilities in when the Stub is created. Some of the implementation of this varies from vendor to vendor, but every vendor's functionality must comply with the CORBA specification.

Answer: A IDL, or Interface Definition Language, will be covered in greater detail over the next two Days. For now, it is useful to understand that the value in IDL comes from its abstraction of various language, hardware, and operating system architectures. For example, the IDL long type will automatically be translated to the numeric type appropriate for whatever architecture the application is run on. In addition, because IDL is language-independent, it can be used to define interfaces for objects that are implemented in any language.

In an effort to ensure that client development remains a straight forward process, the Stub makes the following items transparent to the client:

1. Server location
2. Server activation and management
3. Development language
4. Operating system
5. Network protocol

This level of transparency is required by the CORBA specification.