Mapping Clients  «Prev  Next»
Lesson 3 Skeleton and stub Java classes
Objective Describe the stub and skeleton Java classes and interfaces that the IDL compiler will generate from an IDL interface.

Skeleton and Stub Java Classes

Earlier in the course, you learned about the basic mapping for interfaces. In this lesson, we will discuss the full mapping for interfaces, focusing on the production of stubs and skeletons; we will explore each aspect of the full mapping in greater depth in subsequent lessons.
The mapping for stubs and skeletons we will cover in this module is based on the POA, discussed in depth later in this course. This is the mapping supported by JacORB. An earlier mapping that is still used in many current CORBA implementations that do not yet support the POA is based on the older BOA.

Mapping for signature and operations interfaces

For an IDL interface X, two key Java interfaces are generated: the signature interface, also X, and the operations interface, XOperations. The operations interface specifies all the methods that implementing classes must provide to support the IDL interface. It is used in the server-side mapping. The signature interface, which extends the operations interface, is used as the type in all Java method signatures generated from those IDL operations that used the IDL interface.

Mapping for stubs

There are two types of stubs in the POA-based mapping: local and remote. Local stubs simply provide a way to optimize performance for clients and servers running in the same virtual machine (VM). Remote stubs are the same as previous CORBA stubs; they are local proxies for remote server objects. For an IDL interface X, the IDL compiler can generate a remote stub class called _XStub and a local stub class called _XLocalStub.

Mapping for skeletons

The server-side mapping for skeletons produces two classes, corresponding to different ways to approach the server-side implementation. A CORBA server developer must hook up actual implementation classes to the communications plumbing that is provided in the skeletons and ORB. There are two ways to do this: inheritance and delegation. For IDL interface X, the IDL compiler generates a POA_X class skeleton that the developer can subclass in order to write the implementation. In this way, an implementation class is hooked into the plumbing by simply inheriting it. Alternatively, the generated POA_X_tie class can delegate to an implementing class.
The names of the tie classes may vary from ORB to ORB. We will be using the JacORB names in this course.

Corba Mapping Hierarchy

View the Corba Mapping Hierarchy below to see the full mapping hierarchy.
Database diagram of the pet store schema
  1. Vendor code
  2. Generated code: signature interface
  3. Generated code: operations interface
  4. Generated code: stub class
  5. Generated code: local stub class
  6. Generated code: skeleton class
  7. Generated code: skeleton TIE class
  8. Developer code: implementation object-delegation approach
  9. Developer code: implementation object-inheritance approach

In the next lesson, you will learn about the Java operations interface generated for an IDL interface.