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) Portable Object Adapter,
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.
Types of Corba Mappings
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.
Full Mapping Hierarchy
The graphic illustrates a class diagram related to CORBA (Common Object Request Broker Architecture), specifically representing the relationships and hierarchy among various classes and interfaces involved in CORBA's client-server interaction model. Here's a detailed breakdown:
Color Key
Green boxes: Represent classes/interfaces from the ORB (Object Request Broker) infrastructure, which is part of the CORBA standard.
Yellow boxes: Represent generated classes or interfaces, typically created by IDL (Interface Definition Language) compilers.
Blue boxes: Represent developer-written implementations.
Key Components
Base CORBA Interfaces
org.omg.CORBA.Object and org.omg.CORBA.portable.ObjectImpl are the fundamental CORBA classes/interfaces provided by the ORB. They act as the base for CORBA objects and their implementation.
Generated Stub and Local Stub
_XStub inherits from org.omg.CORBA.portable.ObjectImpl and is a generated class used on the client side to interact with the CORBA server object.
XLocalStub is another generated class, likely used for local object interactions when the server is in the same process.
Interface X
The X interface extends org.omg.CORBA.Object, indicating that it represents a CORBA object.
It also relies on org.omg.CORBA.portable.InvokeHandler, which helps in delegating method invocations to server-side implementations.
Operations Implementation
XOperations is an interface defining the methods that the CORBA object supports.
XOperationsImpl is the developer-written class providing concrete implementations of these methods.
Server-Side Skeletons
POA_X is a generated class that acts as a skeleton for the server-side implementation. It inherits from org.omg.PortableServer.Servant.
POA_X_tie is another generated class, used for delegation purposes, where a developer-written class (XImpl) can be tied to the POA skeleton.
Developer-Written Implementation
XImpl is the final developer-written class that implements the functionality of the XOperations interface. It may use POA_X_tie to tie the implementation with the CORBA skeleton.
Relationships and Dependencies
Inheritance
Many of the classes/interfaces show inheritance relationships (arrows with empty heads), e.g., _XStub inherits from ObjectImpl.
POA_X inherits from Servant
This class diagram effectively demonstrates how CORBA supports a distributed object model using stubs, skeletons, and developer-provided implementations.
1) ORB 2) Generated 3) Developer written
