CORBA

1. Introduction

1.1 Java and CORBA

• a pure object-oriented language: vs. COBOL or C;  advantages over C++ (including exceptions, threads, and the standard library);  straightforward mapping from IDL
• portability and platform-independence (without recompiling): the standard library includes CORBA base classes, the JDK includes an ORB
• web integration: servlets (using threads and library functionality) and JSP vs CGI,  applets as thin clients (rather than HTML "null" clients) or CORBA clients (standard access to distributed services)
• component models: Enterprise Java Beans (EJB) is a subset of the CORBA Component Model and uses IIOP so it can interact with CORBA (development roles, design patterns: stateless/ful session beans and entity beans, configurable infrastructure service, etc.)

• implementation-independent interfaces: IDL, software development process, maintenance
• access to applications and objects written in other languages: IDL-language mappings
• location transparency, server configuration and activation (via POA)
• automatic stub and skeleton generation: networking, sockets, marshalling
• access to CORBA services and facilities: naming, trading, notification, transactions, persistence, security, etc.
  

• both have implementation-independent interfaces, location transparency, activation, automatic stub (and skeleton) generation
• RMI is simpler to use, but has fewer services for large-scale apps (e.g., no scalability and life-cycle configurability via POA, no Transaction Service)
• they can now interact: RMI can use IIOP, CORBA 3 can pass objects by value, there is a remote interface to IDL compiler

1.2 The Object Managment Group (OMG)

1.3 The Object Management Architecture (OMA)

1.3.1 The Core Object Model

1.3.2 The Reference Model

• The Object Request Broker (ORB) is a message bus among distributed objects that provides access to common services (directory services, metadata, security, etc.) and location transparency (it insulates the application from specifics of operating systems, platforms, network protocols, etc).
• Object Services provide fundamental, system-level functionality needed by large-scale distributed applications (list of CORBAservices: p 32).
• Common Facilities provide user-oriented application functionality that is not domain-specific, e.g. the Internationalization and TIme Facilities, the Data Interchange Facility, and the Printing Facility
  
• Domain Interfaces define domain-specific facilities, e.g. there are OMG SIGs for business, telecommunications, internet, health care, and manufacturing (p 21-23).  Several requests for information (RFI) and requests for proposals (RFP) are in progress in various Domain task forces.
•  Application Interfaces define the functionality of individual applications.

1.4 The CORBA object model

1.5 The CORBA architecture

2. The OMG Interface Definition Language (IDL)

2.1 Introduction

2.2 Lexical analysis

2.3 Modules and interfaces

2.4 Non-object types and constants

2.5 Operations and attributes

2.6 Valuetypes

• Class instances cannot be passed or returned by value
• Null values cannot be passed for constructed types, sequences, or string parameters or return values

   module Tree {
      typedef sequence<string> StringList;
      valuetype BinaryTree {
         private string name;
         private BinaryTree left;
         private BinaryTree right;
         factory init(in string name);
         StringList pre_order();
         StringList post_order();
         boolean equals(in BinaryTree tree);
         // ... other operations ...
      };
   };

3. CORBA in Java

3.1 A basic CORBA program

• the operations interface IntfOperations and the signature interface Intf which extends IntfOperations (p 147)
• an IntfHolder class with a public field value to use for out parameters
• an IntfHelper class that defines class operations associated with the type (primarily narrow)
• a _IntfStub class for the client stub
• an IntfPOA abstract skeleton class for the server implementation to extend, and an optional IntfPOATie for the server implementation to delegate to via the tie mechanism

• import org.omg.CORBA.*
  
• call ORB.init to initialize the ORB and get a reference to the ORB pseudo-object (p 148: the second argument is a properties file with ORB properties)
• obtain object references (p 148-149: get a stringified interoperable object reference from the command line, "narrow" it to convert it to the correct type, and check for null;  alternatively, obtain the naming service via orb.resolve_initial_references and resolve the object name)
• invoke the operation (p 149, p 161 with out parameters and holders)
• all CORBA System Exceptions are descendants of SystemException, which is unchecked, but a robust application will catch and handle them rather than exiting (p 149)
• call orb.shutdown(true) (where true indicates that the call should block until all pending requests and POA operations have completed) and orb.destroy() before terminating

• by convention, the servant class that implements the IDL interface Intf is named IntfImpl
• either extend the generated POA skeleton class or delegate via the tie mechanism (discussed below)
• define the constructors, variables, and methods (p 155-156, p 164 with out parameters)

• initialize the ORB and create a servant
• obtain a POA (orb.resolve_initial_references provides access to the root POA, the interface repository, and CORBAservices)
• activate the servant to enter it in the POA's Active Object Map: use poa.servant_to_reference (p 157) or poa.activate_object (which returns a byte[] object ID that can be converted to a reference with poa.id_to_reference )
  
• activate the POA manager to enable dispatching requests to servants
• export the object reference by printing a stringified IOR for clients to use (or write it to a file);  alternatively, bind the object reference in a naming service
• call orb.run to wait for requests
• handle exceptions
• call orb.destroy() before terminating (run blocks until the ORB is shut down by another thread)

3.2 The IDL to Java mapping

3.2.1 Identifiers, basic types, type aliases, and constants

3.2.2 Holder and helper classes

3.2.3 Constructed and sequence types

• class constants for the enumeration values and for their corresponding int values
• a protected constructor
• a method value to obtain the int
• a class method from_int that returns the enumeration value corresponding to the argument int

• public fields for each member
• a no-argument constructor and a constructor that takes values for each member

• private fields for the discriminator and the contained value
• a no-argument constructor
• an accessor for the discriminator
• accessors and modfiers for each possible value

• a public field for each member
• a no-argument constructor that sets the message to the exception's repository ID
• a constructor that takes values for each member
• a constructor that takes values for each member and a string message

3.2.4 Modules

3.2.5 Valuetypes

3.2.6 Generated interfaces and classes

3.2.7 The tie mechanism

3.2.8 Portability interfaces

3.2.9 The Java to IDL mapping

4. The ORB Run-Time System

4.1 Pseudo-IDL and local interfaces

• A local interface may inherit from other local or unconstrained interfaces, but an unconstrained interface may not inherit from a local interface.  A valuetype may support a local interface.
• A local interface is a "local type", as is any non-interface type declaration constructed using a local interface or other local type.  For example, a struct, union, or exception with a member that is a local interface is also itself a local type.  A local type may be used as a parameter, attribute, return type, or exception declaration of a local interface or a valuetype.  A local type may not appear as a parameter, attribute, return type, or exception declaration of an unconstrained interface or as a state member of a valuetype.

4.2 The Object interface

4.3 The ORB interface

• ORB initialization
• obtaining initial references (e.g., to services)
• converting object references to strings and back
• starting and stoping the ORB, and emulating concurrency
• creating anys, type codes, and other pseudo-objects used with DII
• sending multiple DII messages, and accessing the result of a deferred synchronous invocation
• managing value factories
• creating policy objects

4.4 The Portable Object Adapter (POA)

4.4.1 Motivation and overview

• Allow programmers to construct object implementations that are portable between different ORB products
•  Provide support for objects with persistent identities. More precisely, the POA is designed to allow programmers to build object implementations that can provide consistent service for objects whose lifetimes (from the perspective of a client holding a reference for such an object) span multiple server lifetimes
• Provide support for transparent activation of objects
• Allow a single servant to support multiple object identities simultaneously
• Allow multiple distinct instances of the POA to exist in a server
• Provide support for transient objects with minimal programming effort and overhead
• Provide support for implicit activation of servants with POA-allocated Object IDs
• Allow object implementations to be maximally responsible for an object’s behavior.  Specifically, an implementation can control an object’s behavior by establishing the datum that defines an object’s identity, determining the relationship between the object’s identity and the object’s state, managing the storage and retrieval of the object’s state, providing the code that will be executed in response to requests, and determining whether or not the object exists at any point in time.
• Avoid requiring the ORB to maintain persistent state describing individual objects, their identities, where their state is stored, whether certain identity values have been previously used or not, whether an object has ceased to exist or not, and so on
• Provide an extensible mechanism for associating policy information with objects implemented in the POA
• Allow programmers to construct object implementations that inherit from static skeleton classes generated by OMG IDL compilers or from a DSI implementation

• create and manage object references
• map an object reference that a client uses as a request target to a servant that performs the request when the ORB processes the request

• child POAs (if any)
  
• a "POA manager" that determines its "processing state"
  
• if its Servant Retention Policy is RETAIN, an "Active Object Map" that maps object IDs to servants (possibly many-to-one)
• if its Request Processing Policy is USE_DEFAULT_SERVANT , a "default servant"
• if its Request Processing Policy is USE_SERVANT_MANAGER , a "servant manager"
• an optional "adapter activator" to create child POAs

4.4.2 Policies

• whether CORBA objects are persistent (the Lifespan Policy)
• how object IDs are generated, and whether a servant can handle requests from multiple object IDs (the ID Assignment Policy and the ID Uniqueness Policy)
• how the POA locates a servant to execute a request (the Servant Retention Policy, the Request Processing Policy, and the Implicit Activation Policy)
• the concurrency model used to execute requests (the Thread Policy)

• Lifespan Policy: TRANSIENT
• ID Uniqueness Policy: UNIQUE_ID
• ID Assignment Policy: SYSTEM_ID
• Servant Retention Policy: RETAIN
• Request Processing Policy: USE_ACTIVE_OBJECT_MAP_ONLY
• Implicit Activation Policy: IMPLICIT_ACTIVATION
• Thread Policy: ORB_CTRL_MODEL

4.4.3 Object references

• the interface type of the reference
  
• the host and port that created the reference
• the full path name of the POA that created the reference
• the object ID, a sequence of octets which uniquely identifies that CORBA object
• optional information for services, e.g. security and transaction information
  

• POA::activate_object and POA::activate_object_with_id enter the argument servant in the Active Object Map, and the first returns the ORB-generated object ID.  These operations require the RETAIN policy.  The exception ServantAlreadyActive is signaled if the servant is already mapped and the POA has the UNIQUE_ID policy.  The object reference is then obtained with POA::servant_to_reference or POA::id_to_reference .
• POA::create_reference and POA::create_reference_with_id create a reference of the type given by the argument RepositoryId but do not associate it with a servant.  The first operation requires the SYSTEM_ID policy and the second takes an object ID (p 235).  The reference may then be exported, and a servant will be selected when a client invokes a request, e.g. the default servant or a servant returned by the servant manager.
• POA::servant_to_reference can be called without activating the servant first if the POA has the RETAIN and IMPLICIT_ACTIVATION policies (p 236, 237).  It enters the argument servant in the Active Object Map with a POA-generated ID and creates and returns an object reference.
• The Java language mapping adds a method _this(orb) to each skeleton class which returns a reference to the CORBA object that the servant incarnates (like servant_to_reference ).  If the POA returned by the servant's _default_POA method (the root POA if it has not been overridden) uses the IMPLICIT_ACTIVATION policy, _this can be used to activate the servant in that POA and create a reference (p 441).  However, this technique has the drawback that the POA used is not apparent.

4.4.4 Default servants

• implementing a stateless service, e.g. a calculator or time-of-day service
• responding to requests for instances of a particular class by loading the corresponding object from a database, performing the operation, and then storing the object (p 447-449)
• implementing a wrapper for system utilities, external hardware, or a non-object-oriented legacy system
• implementing a single DSI servant for several CORBA object types

4.4.5 Servant managers

   local interface ServantActivator : ServantManager {
      Servant incarnate(in ObjectId oid, in POA adapter) raises (ForwardRequest);
      void etherialize(in ObjectId oid, in POA adapter, in Servant serv,
         in boolean cleanup_in_progress, in boolean remaining_activations);
   };

   import org.omg.PortableServer.*;
   public class XXXActivatorImpl extends ServantActivatorPOA {
      private int maxAOMSize;
      // a FIFO queue of activated object IDs
      private LinkedList idQueue = new LinkedList();

      public XXXActivatorImpl(int maxAOMSize) {
         this.maxAOMSize = maxAOMSize;
      }

      public Servant incarnate(byte[] oid, POA poa) throws ForwardRequest {
         if (idQueue.size() == maxAOMSize) {
            byte[] deactivateID = (byte[]) idQueue.removeFirst();
            try {
               poa.deactivate_object(deactivateID);
            }
            catch (org.omg.PortableServer.POAPackage.ObjectNotActive objNotActive) {
               // should not happen: the object is activated
            }
            catch (org.omg.PortableServer.POAPackage.WrongPolicy wrongPolicy) {
               // should not happen: we set the POA policies
            }
         }
         idQueue.addLast(oid);
         // e.g., use the oid to get initial field values from the database
         return new XXXImpl(oid, poa);
      }

      public void etherealize(byte[] oid, POA poa, Servant servant,
            boolean cleanup_in_progress, boolean remaining_activations) {
         // ID deleted from queue by incarnate
      }
   }

   local interface ServantLocator : ServantManager {
      Servant preinvoke(in ObjectId oid, in POA adapter, in CORBA::Identifier operation,
         out Cookie the_cookie) raises (ForwardRequest);
      void postinvoke(in ObjectId oid, in POA adapter, in CORBA::Identifier operation,
         in Cookie the_cookie, in Servant the_servant);
   };

4.4.6 The POA manager

4.4.7 Adapter activators

4.4.8 The interface Current

4.5 DSI/DII

4.6 Interceptors

5. CORBA Services

5.1 The Naming Service

5.1.1 Overview

5.1.2 The interface NamingContext and related types

   NameComponent[] name = new NameComponent[]{
      new NameComponent("uic", "school"), new NameComponent("cs", "dept"), NameComponent("ai", lab")};