org.omg.PortableServer

In Java, Portable Object Adaptor (POA)-based Dynamic Skeleton Interface (DSI) servants inherit from the standard DynamicImplementation class, which inherits from the Servant class. The native Servant type is defined by the PortableServer module for the POA. In Java, the Servant type is mapped to the Java org.omg.PortableServer.Servant class. It serves as the base class for all POA servant implementations and provides a number of methods that may be invoked by the application programmer, as well as methods which are invoked by the POA itself and may be overridden by the user to control aspects of servant behavior.

Package Specification

For a precise list of supported sections of official OMG specifications with which the Java[tm] Platform, Standard Edition 6 complies, see Official Specifications for CORBA support in Java[tm] SE 6.

POA-related Interfaces

The PortableServer module defines the following POA-related interfaces:

• POA
• POAManager
• ServantManager
• ServantActivator
• ServantLocator
• AdapterActivator
• ThreadPolicy
• LifespanPolicy
• IdUniquenessPolicy
• IdAssignmentPolicy
• ImplicitActivationPolicy
• ServantRetentionPolicy
• RequestProcessingPolicy
• Current

In addition, the POA defines the Servant native type.

Operations classes

Each of the interfaces listed above has an associated Operations interface. The Operations interface is generated by the idlj compiler and contains the method signatures for methods defined in its associated interface. The Operations interface can be accessed by both the client and the server, while its associated interface can only be called by the client.

Value Classes

• IdAssignmentPolicyValue
• IdUniquenessPolicyValue
• ImplicitActivationPolicyValue
• LifespanPolicyValue
• RequestProcessingPolicyValue
• ServantRetentionPolicyValue
• ThreadPolicyValue

Helper Classes

Helper classes, which are generated for all user-defined types in an OMG IDL interface, supply static methods needed to manipulate those types. There is only one method in a helper class that an application programmer uses: the narrow method. Only Java interfaces mapped from IDL interfaces will have a helper class that includes a narrow method, so in the PortableServer package, only the following classes have a narrow method:

• ForwardRequestHelper
• ServantActivatorHelper
• ServantLocatorHelper

POA Classes

POA classes are used to implement the ServantActivator or ServantLocator.

Exceptions

The ForwardRequest exception indicates to the ORB that it is responsible for delivering the current request and subsequent ForwardRequest requests to the object denoted in the forward_reference member of the exception.

Interfaces Implemented by the Application Programmer

Most of what PortableServer does is transparent to the user. The result is that programmers will use only a few of the interfaces mentioned above. The remaining interfaces will be provided by the ORB implementation. The interfaces of interest to application programmers are the following:

• AdapterActivator

  Adapter activators are associated with POAs. An adapter activator supplies a POA with the ability to create child POAs on demand, as a side-effect of receiving a request that names the child POA (or one of its children), or when find_POA is called with an activate parameter value of TRUE. An application server that creates all its needed POAs at the beginning of execution does not need to use or provide an adapter activator; it is necessary only for the case in which POAs need to be created during request processing.

• ServantLocator

  When the POA has the NON_RETAIN policy, it uses servant managers that are ServantLocators.

• ServantActivator

  When the POA has the RETAIN policy, it uses servant managers that are ServantActivators.

Package org.omg.PortableServer.ServantLocatorPackage

This package supplies a CookieHolder class for passing the Cookie type as an out parameter. The CookieHolder class follows exactly the same pattern as the other holder classes for basic types.

Related Documentation

For an overview of Java IDL, please see:

import javax.naming.InitialContext;
import javax.naming.Context;
import javax.rmi.PortableRemoteObject ;
import com.sun.corba.se.impl.poa.POAORB;
import org.omg.PortableServer.*;
import java.util.*;
import org.omg.CORBA.*;
import javax.rmi.CORBA.Stub;
import javax.rmi.CORBA.Util;



public class HelloServer {
    public HelloServer(String[] args) {
        try {
            Properties p = System.getProperties();
         //   p.put("org.omg.CORBA.ORBClass", "com.sun.corba.ee.internal.POA.POAORB");
            ORB orb = ORB.init( args, p );

            POA rootPOA = (POA)orb.resolve_initial_references("RootPOA");

            Policy[] tpolicy = new Policy[3];
            tpolicy[0] = rootPOA.create_lifespan_policy(
                LifespanPolicyValue.TRANSIENT );
            tpolicy[1] = rootPOA.create_request_processing_policy(
                RequestProcessingPolicyValue.USE_ACTIVE_OBJECT_MAP_ONLY );
            tpolicy[2] = rootPOA.create_servant_retention_policy(
                ServantRetentionPolicyValue.RETAIN);
            POA tpoa = rootPOA.create_POA("MyTransientPOA", null, tpolicy);


            String  ObjectId = "MyObjectId";
            byte[] oid = ObjectId.getBytes();

            org.omg.CORBA.Object obj = tpoa.create_reference_with_id(oid,
                new _HelloImpl_Tie()._all_interfaces(tpoa, oid)[0]);
            HelloInterface helloRef = (HelloInterface)PortableRemoteObject.narrow(
                obj, HelloInterface.class );

            Context initialNamingContext = new InitialContext();
            initialNamingContext.rebind("HelloService", helloRef);
            System.out.println("Hello Server: Ready...");
            orb.run();
         } catch (Exception e) {
            System.out.println("Trouble: " + e);
            e.printStackTrace();
         } 
     }


     public static void main(String args[]) {
         new HelloServer( args );
     }
}