Oracle9i CORBA Developer's Guide and Reference
Release 1 (9.0.1)

Part Number A90187-01
Go To Documentation Library
Go To Product List
Book List
Go To Table Of Contents
Go To Index

Master Index


Go to previous page Go to next page

JNDI Connections and
Session IIOP Service

This chapter describes in detail how clients connect to an Oracle9i server session and how they authenticate themselves to the server. The term client, as used in this chapter, includes client applications and applets running on a network PC or a workstation, as well as distributed objects such as EJBs and CORBA server objects that are calling other distributed server objects and, thus, acting as clients to these objects.

To execute CORBA objects, you must first publish these objects in an Oracle9i database instance, using a CORBA CosNaming service. Then, you can retrieve the object reference either through a URL-based Java Naming and Directory Interface (JNDI) to CosNaming or straight to the CosNaming service. JNDI is recommended because it is easy for clients written in Java to locate and activate published objects.

In addition to authentication, this chapter discusses security of access control to objects in the database. A published object in the data server has a set of permissions that determine who can access and modify the object. In addition, classes that are loaded into the data server are loaded into a particular schema, and the person who deploys the classes can control who uses them.

This chapter covers the following topics:

JNDI Connection Basics

The client example in Chapter 2 shows how to connect to Oracle, start a database server session, and activate an object using a single URL specification. This is performed through the following steps:

1. Hashtable env = new Hashtable();
2. env.put(javax.naming.Context.URL_PKG_PREFIXES, "oracle.aurora.jndi");
3. env.put(javax.naming.Context.SECURITY_PRINCIPAL, username);
4. env.put(javax.naming.Context.SECURITY_CREDENTIALS, password);
5. env.put(javax.naming.Context.SECURITY_AUTHENTICATION, 
ServiceCtx.NON_SSL_LOGIN); 6. Context ic = new InitialContext(env); 7. myHello hello = (myHello) ic.lookup("sess_iiop://localhost:2481:ORCL/test/myHello"); 8. System.out.println(hello.helloWorld());

In this example, there are four basic operations:

When a client looks up an object through the JNDI lookup method, the client and server automatically perform the following logic:

When the client invokes a method--such as helloWorld()--on the returned reference, the server activates the object in the server.

The Name Space

The name space in the database looks just like a typical file system. You can examine and manipulate objects in the publishing name space using the session shell tool. See the sess_sh tool in the Oracle9i Java Tools Reference for information about the session shell.

There is a root directory, indicated by a forward slash ('/'). The root directory is built to contain three other directories: bin, etc, and test. The /test directory is where most objects are published for the example programs. You can create new directories under root to hold objects for separate projects; however, you must have access as database user SYS to create new directories under the root.

There is no effective limit to the depth that you can nest directories.


The initial values in the publishing name space are set up when the Oracle9i JVM is installed. 

The /etc directory contains objects that the ORB uses. The objects contained in /etc are:

deployejb    execute    loadjava    login    transactionFactory 

Do not delete objects in the /etc directory.

The entries in the name space are represented by objects that are instances of the following classes:

The javadoc on the product CD documents these classes.

Published names for objects are stored in a database table. Each published object also has a set of associated permissions. Each class or resource file can have a combination (union) of the following permissions:


The holder of read rights can list the class or the attributes of the class, such as its name, its helper class, and its owner.


The holder of write for a context can bind new object names into a context. For an object (a leaf node of the tree), write allows the holder to republish the object under a different name.


You must have execute rights to resolve and activate an object represented by a context or published object name.

You use the chmod command of the session shell tool to view and change object rights.

Execution Rights to Database Objects

In addition to authentication and privacy, Oracle9i supports controlled access to the classes that make up CORBA and EJB objects. Only users or roles that have been granted execute rights to the Java class of an object stored in the database can activate the object and invoke methods on it.

You can control execute rights on Java classes with the following tools:

A client can access the following three built-in server objects without being authenticated:

You can activate these objects using serviceCtx.lookup() without authentication. See the "Logging In and Out of the Oracle9i Session" for an example that access the Login object explicitly.

URL Syntax

Oracle9i provides universal resource locator (URL) syntax to access services and sessions. The URL lets you use JNDI requests to start up services and sessions, and also to access components published in the database instance. An example service URL is shown in Figure4-1.

Figure 4-1 Service URL

Text description of connseca.gif follows
Text description of the illustration connseca.gif

Four components make up the service URL:

  1. The URL prefix followed by a colon and two slashes: sess_iiop:// for a session IIOP request.

  2. The system name (the hostname). For example: myPC-1. You can also use localhost or the numeric form of the IP address for the host.

  3. The listener port number for IIOP services. The default is 2481.

  4. The system identifier (SID)--for example, ORCL--or the service name--for example, mySID.myDomain.

Always use colons to separate the hostname, port, and SID or service name.


If you specify a dispatcher port instead of a listener port, and you specify a SID, an ObjectNotFound exception is thrown by the server. Because applications that connect directly to dispatcher ports do not scale well, Oracle does not recommend direct connection to dispatchers. 

URL Components and Classes

When you make a connection to Oracle and look up a published object using JNDI, you use a URL that specifies the service (service name, host, port, and SID), as well as the name of a published object to look up and activate. For example, a complete URL could look like:


where sess_iiop://localhost:2481:ORCL specifies the service name, :default indicates the default session (when a session has already been established), /projectAurora/Plans816 specifies a directory path in the namespace, and getPlans is the name of a published object to look up.


Do not specify the session name when no session has been established for that connection. That is, on the first look up there is no session active; therefore, :default as a session name has no meaning. In addition, :default is implied, so you can use a URL without a session name. 

Each component of the URL represents a Java class. For example, the service name is represented by a ServiceCtx class instance, and the session by a SessionCtx instance. See "Using JNDI to Access Bound Objects" and "Session IIOP Service" starting for more information on the service and session names within the URL.

CosNaming Restriction for JNDI Name

The JNDI bound name for the published object must use JNDI syntax rules. The underlying naming service that Oracle9i JNDI uses is CosNaming. Thus, if your name includes a dot (".") in one of the names, the behavior diverges from normal CosNaming rules, as follows:

Normally, in retrieving a CosNaming object, you supply the id and kind as separate entities. The Oracle9i implementation concatenates both id and kind. Thus, to retrieve the object, your application refers to the full name with the dot included as part of the JNDI name, rather than as a separator.

Using JNDI to Access Bound Objects

Clients use JNDI to look up published objects in the Oracle9i namespace. JNDI is an interface supplied by Sun Microsystems that gives the Java application developer a methodology to access name and directory services. This section discusses only those parts of the JNDI API that are needed to look up and activate published objects. To obtain a complete set of documentation for JNDI, see the Web site URL:


It is also possible to access the session namespace without using JNDI. Instead, you can use CosNaming methods. 

As described in "URL Syntax", the JNDI URL required to access any bound name in the Oracle9i namespace requires a compound name consisting of the following two components:

You can utilize the service and session contexts to perform some advanced techniques, such as opening different sessions within a database or enabling several clients to access an object in a single session. These are discussed further in the "Session IIOP Service". However, for simple JNDI lookup invocations, you should use the URL syntax specified in "URL Syntax".

Importing JNDI Support Classes

When you use JNDI in your client or server object implementations, be sure to include the following import statements in each source file:

import javax.naming.Context;    // the JNDI Context interface
import javax.naming.InitialContext;
import oracle.aurora.jndi.sess_iiop.ServiceCtx; // JNDI property constants
import java.util.Hashtable;     // hashtable for the initial context environment

Retrieving the JNDI InitialContext

Context is an interface in the javax.naming package that is used to retrieve the InitialContext. All Oracle9i EJB and CORBA clients use the InitialContext for JNDI lookup(). Before you perform a JNDI lookup(), set the environment variables, such as authentication information into the Context. You can use a hash table or a properties list for the environment. Then, this information is made available to the naming service when the lookup() is performed. The examples in this guide always use a Java Hashtable, as follows:

Hashtable environment = new Hashtable();

Next, set up properties in the hash table. You must always set the Context URL_PKG_PREFIXES property, whether you are on the client or the server. The remaining properties are used for authentication, which are primarily used by clients or by a server authenticating itself as another user.


Context.URL_PKG_PREFIXES holds the name of the environment property for specifying the list of package prefixes to use when loading in URL context factories. The value of the property should be a colon-separated list of package prefixes for the class name of the factory class that will create a URL context factory.

In the current implementation, you must always supply this property in the Context environment, and it must be set to the String "oracle.aurora.jndi".


Context.SECURITY_PRINCIPAL holds the database username.


Context.SECURITY_CREDENTIAL holds the clear-text password. This is the Oracle database password for the SECURITY_PRINCIPAL (the database user). In all of the three authentication methods mentioned in SECURITY_AUTHENTICATION below, the password is encrypted when it is transmitted to the server.


Context.SECURITY_ROLE holds the Oracle9i database role with which the user is connecting. For example, "CLERK" or "MANAGER".


Context.SECURITY_AUTHENTICATION holds the name of the environment property that specifies the type of authentication to use. Values for this property provide for the authentication types supported by Oracle9i. There are four possible values, which are defined in the ServiceCtx class:


If you are using a service name instead of an SID in the URL, set this property to true. Otherwise, the last string in the URL must contain the SID. Given a Hashtable within the variable env, the following designates that the service name is used instead of the SID within the URL:

Hashtable env = new Hashtable();
env.put(Context.URL_PKG_PREFIXES, "oracle.aurora.jndi");
env.put(Context.SECURITY_PRINCIPAL, "scott");
env.put(Context.SECURITY_CREDENTIALS, "tiger");
env.put("USE_SERVICE_NAME", "true");
Context ic = new InitialContext(env);

The default is false.

The URL given within the lookup should contain a service name, instead of an SID. The following URL contains the service name orasun12:

myHello hello =

    (myHello) ic.lookup("sess_iiop://localhost:2481:orasun12/test/myHello");

The JNDI InitialContext Methods

InitialContext is a class in the javax.naming package that implements the Context interface. All naming operations are relative to a context. The initial context implements the Context interface and provides the starting point for resolution of names.


You construct a new initial context using the constructor:

public InitialContext(Hashtable environment)

It requires a Hashtable for the input parameter that contains the environment information described in "Retrieving the JNDI InitialContext" above. The following code fragment sets up an environment for a typical client and creates a new initial context:

Hashtable env = new Hashtable();
env.put(Context.URL_PKG_PREFIXES, "oracle.aurora.jndi");
env.put(Context.SECURITY_PRINCIPAL, "scott");
env.put(Context.SECURITY_CREDENTIALS, "tiger");
Context ic = new InitialContext(env);


This is the most common initial context class method that the CORBA or EJB application developer will use:

public Object lookup(String URL)

You use lookup() to retrieve an object instance or to create a new service context.

See "Session Management Scenarios" for examples of how to use the JNDI lookup method within an EJB or CORBA application.

Session IIOP Service

All client/server network communications route requests over an accepted protocol between both entities. Most network communications to the Oracle9i database are routed over the two-task common (TTC) layer. This is the service that processes incoming Oracle Net requests for database SQL services. However, with the addition of Java into the database, Oracle9i requires that clients communicate with the server over an IIOP transport that recognizes database sessions. This is accomplished through the session IIOP service.

The session IIOP service is used for facilitating requests for IIOP applications, which includes CORBA and EJB applications. The following sections describe how to manage your applications within one or more database sessions:

Session IIOP Service Overview

As discussed in the Oracle9i Java Developer's Guide, since the EJB is loaded into the database, your client application must start up the EJB within the context of a database session. Because beans are activated within a session, each client cannot see bean instances active in another session unless given a handle to that session. However, you can activate objects either within the existing session or another session.

The session IIOP service session component tag--TAG_SESSION_IIOP-- exists inside the IIOP profile--SessionIIOP. The value for this Oracle session IIOP component tag is 0x4f524100 and contains information that uniquely identifies the session in which the object was activated. The client ORB runtime uses this information to send requests to objects in a particular session.

Although the Oracle9i session IIOP service provides an enhancement of the standard IIOP protocol--it includes session ID information--it does not differ from standard IIOP in its on-the-wire data transfer protocol.

Client Requirements

Clients must have an ORB implementation that supports session IIOP to be able to access objects in different sessions simultaneously, from within the same program, and to be able to disconnect from and reconnect to the same session. The version of the Visigenic ORB that ships with Oracle9i has been extended to support session IIOP.

Session Routing

When a client makes an IIOP connection to the database, Oracle9i determines if a new session should be started to handle the request, or if the request should be routed to an existing session. If the client initializes a new request for a connection (using the InitialContext.lookup() method) and no session is active for that connection, a new session is automatically started. If a session has already been activated for the client, the session identifier is encoded into the object key of the object. This information enables the session IIOP service to route the request to the correct session. In addition, a client can use this session identifier to access multiple sessions. See "Session Management Scenarios" for more information.

Oracle9i JVM Tools

When using the Oracle9i JVM tools, especially when developing EJB and CORBA applications, it is important to distinguish the two network service protocol types: TTC and IIOP.

Figure 4-2 TTC and IIOP Services

Text description of sess.gif follows
Text description of the illustration sess.gif

Figure4-2 shows which tools and requests use TTC and which use IIOP database ports. The default port number for TTC is 1521, and the default for IIOP is 2481.

Session Management

In simple cases, a client (or a server object acting as a client) starts a new server session implicitly when it performs the lookup for a server object. Oracle9i also gives you the ability to control session start-up explicitly. Two Oracle-specific classes give you control over the session IIOP service connection and over the sessions within the database:

Service Context Class

The service context class controls the session IIOP service connection to the database. Given a URL to that database, you can create a service context. You can open one or more named sessions within the database off of this service context. This Oracle-specific class extends the JNDI Context class.


The ServiceCtx class defines a number of final public static variables that you can use to define environment properties and other variables. Table 4-1 shows these.

Table 4-1 ServiceCtx Public Variables  
String Name  Value 

















Integer Name  Integer Constructor 


new Integer(2) 


new Integer(1) 


The public methods in this class that CORBA and EJB application developers can use are as follows:

public Context createSubcontext(String name)

This method takes a Java String as the parameter and returns a JNDI Context object representing a session in the database. The method creates a new named session. The parameter is the name of the session to be created, which must start with a colon (:).

The return result should be cast to a SessionCtx object.

This method can throw the exception: javax.naming.NamingException.

public Context createSubcontext(Name name)

Each of the methods that takes a String parameter has a corresponding method that takes a Name parameter. The functionality is the same.

public static org.omg.CORBA.ORB init(String username,
                                     String password,
                                     String role,
                                     boolean ssl,
                                     java.util.Properties props)

This method retrieves access to the ORB that is created when you perform a look up. Set the ssl parameter to true for SSL authentication. Clients that do not use JNDI to access server objects should use this method.

See the sharedsession example in Appendix A of the Oracle9i CORBA Developer's Guide and Reference for a usage example.

public Object lookup(String string)

The lookup method looks up a published object in the database instance associated with the service context, and either returns an activated instance of the object, or throws javax.naming.NamingException.

Session Context Class

The session context class controls named database sessions that are created off of a service context. Once the session has been created, you can activate CORBA or EJB objects within the session, using the named session context object. Session contexts represent sessions and contain methods that enable you to perform session operations, such as authenticating the client to the session or activating objects. This class extends the JNDI Context class.


Creating a subcontext within the session context affects the object type returned on the final JNDI lookup. See "Lookup of Objects Off of JNDI Context" for more information. 


The session context methods that a client uses are the following:

public synchronized boolean login()

The login method authenticates the client, using the initial context environment properties passed in the InitialContext constructor: username, password, and role.

public synchronized boolean login(String username,
String password,
String role)

The login method authenticates the client, using the username, password, and optional database role supplied as parameters.

public Object activate(String name)

The activate method looks up and activates a published object with the given name.

Session Management Scenarios

The following sections describe the five different scenarios for managing database sessions:

Client Accessing a Single Session

In general, when you look up a published object from a client with a URL, hostname, and port, the object is activated in a new session. For example, a client would perform the following:

Hashtable env = new Hashtable();
env.put(Context.URL_PKG_PREFIXES, "oracle.aurora.jndi");
env.put(Context.SECURITY_PRINCIPAL, "scott");
env.put(Context.SECURITY_CREDENTIALS, "tiger");
Context ic = new InitialContext(env);
SomeObject myObj =
   (SomeObject) ic.lookup("sess_iiop://localhost:5521:ORCL/test/myObj");

Activating an object in a new session from a server object is identical to starting a session from an application client. If you invoke the lookup method within the server object, the second object instance is activated in a separate session from the originating session.

Ending a Session

Normally, a session terminates when the client terminates. However, if you want to explicitly terminate a session, you can do one of the following:

Terminate A Session From The Server-Side Using The Endsession Method

The server can control session termination by executing the following method:


Terminate A Session From The Client-side Using The Logout Object

If the client wishes to exit the session, it can execute the logout method of the LogoutServer object, which is pre-published as "/etc/logout". Only the session owner is allowed to logout. Any other owner receives a NO_PERMISSION exception.

The LogoutServer object is analogous to the LoginServer object, which is pre-published as "/etc/login". You can use the LoginServer object to retrieve the Login object, which is used to authenticate to the server. This is an alternative method to using the Login object within the JNDI lookup.

The following example shows how a client can authenticate using the LoginServer object and can exit the session through the LogoutServer object.

import oracle.aurora.AuroraServices.LoginServer;
import oracle.aurora.AuroraServices.LogoutServer;
// To log in using the LoginServer object
LoginServer loginServer = (LoginServer)ic.lookup(serviceURL + "/etc/login");
Login login = new Login(loginServer);
System.out.println("Logging in ..");
login.authenticate(user, password, null);
//To logout using the LogoutServer
LogoutServer logout = (LogoutServer)ic.lookup(serviceURL + "/etc/logout");
Client Starting a Named Session

You can explicitly create multiple sessions on the database instance through the JNDI methods provided in the ServiceCtx and SessionCtx classes.

The following lookup method contains a URL that defines the IIOP service URL of "sess_iiop://localhost:5521:ORCL" and a default session context.

SomeObject myObj =
   (SomeObject) ic.lookup("sess_iiop://localhost:5521:ORCL/test/myHello");

In this simple case, the JNDI initial context lookup method implicitly starts a session and authenticates the client. This session becomes the default session, which is identified by the name ":default". All sessions are named. However, in the default case, the client does not need to know the name of the session, because all requests go to this single session. Unless specified, all additional objects will be activated in the default session. Even if you create a new JNDI initial context and look up the same or a new object, the object is instantiated in the same session as the first object.

The only way to activate objects within another session is to create a named session. You can create other sessions in place of or in addition to the default session by creating session contexts off of the service context. Because each session is a named session, you can activate objects in different sessions within the database.

  1. Instantiate a new hashtable for the environment properties to be passed to the server.

        Hashtable env = new Hashtable();
        env.put(Context.URL_PKG_PREFIXES, "oracle.aurora.jndi");


    Only the URL_PKG_PREFIXES Context variable is filled in--the other information will be provided in the login.authenticate() method parameters. 

  2. Create a new JNDI Context.

    Context ic = new InitialContext(env);
  3. Use the JNDI lookup method on the initial context, passing in the service URL, to establish a service context. This example uses a service URL with the service prefix of hostname, listener port, and SID.


    Provide only the service URL of hostname, listener port, and database SID. If you provide the JNDI name of the desired object, a default session will be created for you. 

    ServiceCtx service =
            (ServiceCtx) ic.lookup("sess_iiop://localhost:2481:ORCL");
  4. Create a session by invoking the createSubcontext method on the service context object. Provide the name for the session as a parameter to the createSubcontext method. A new session is created within the database.

    SessionCtx session = (SessionCtx) service.createSubcontext(":session1");


    You must name a new session when you create it. The session name must start with a colon (:) and cannot contain a slash (/), but is not otherwise restricted. 

  5. Authenticate the client program to the database by invoking the login method on the session context object.

    session.login("scott", "tiger", null);    // role is null
  6. Activate the object, identified by its bound JNDI name, in the named session.

    Hello hello = (Hello)session.activate (objectName);
        System.out.println (hello.helloWorld ());

Example 4-1 Activating Objects in Named Sessions

The following example creates two named sessions of the name :session1 and :session2. Each one retrieves the Hello object separately. The client invokes both Hello objects in each named session.

Hashtable env = new Hashtable ();
env.put (Context.URL_PKG_PREFIXES, "oracle.aurora.jndi");
Context ic = new InitialContext (env);

// Get a SessionCtx that represents a database instance
ServiceCtx service = (ServiceCtx) ic.lookup ("sess_iiop://localhost:2481:ORCL");

// Create and authenticate a first session in the instance.  
SessionCtx session1 = (SessionCtx) service.createSubcontext (":session1");

// Authenticate
session1.login("scott", "tiger", null);

// Create and authenticate a second session in the instance.  
SessionCtx session2 = (SessionCtx) service.createSubcontext (":session2");

// Authenticate using a login object (not required, just shown for example).
LoginServer login_server2 = (LoginServer)session2.activate ("/etc/login");
Login login2 = new Login (login_server2);
login2.authenticate ("scott", "tiger", null);

// Activate one Hello object in each session
Hello hello1 = (Hello)session1.activate (objectName);
Hello hello2 = (Hello)session2.activate (objectName);

// Verify that the objects are indeed different
System.out.println (hello1.helloWorld ());
System.out.println (hello2.helloWorld ());
Two Clients Accessing the Same Session

When the client invokes the JNDI lookup method, Oracle9i creates a session. If you want a second client to access the instantiated object in this session, you must do the following:

  1. The first client saves both the object instance handle and a Login object reference.

  2. The second client retrieves the handle and Login object reference and uses them to access the object instance.

Example 4-2 Two Clients Accessing a Single Instance

  1. The first client authenticates itself to the database by providing a username and password through the authenticate method on a Login object.

  2. The session is created and the object is instantiated through the lookup method that is given the URL.

  3. Both the LoginServer object and the server object instance handle are saved to a file for the second client to retrieve.

    // Login to the 9i server
    LoginServer lserver = (LoginServer)ic.lookup (serviceURL + "/etc/login");
    new Login (lserver).authenticate (username, password, null);
    // Activate a Hello in the 9i server
    // This creates a first session in the server
    Hello hello = (Hello)ic.lookup (serviceURL + objectName);
    hello.setMessage ("As created by Client1");
    System.out.println ("Client1: " + hello.helloWorld ());
    // save Login object into a file, loginFile, for Client2 to read
    com.visigenic.vbroker.orb.ORB orb = oracle.aurora.jndi.orb_dep.Orb.init();
    String log = orb.object_to_string (lserver);
    OutputStream os = new FileOutputStream (loginFile);
    os.write (log.getBytes ());
    os.close ();
    // save object instance handle into a file, helloFile,
    // for Client2 to read String obj_hndl = orb.object_to_string (hello); OutputStream os = new FileOutputStream (helloFile); os.write (obj_hndl.getBytes ()); os.close ();

The second client accesses the Hello object instance in the active session by doing the following:

  1. Retrieves the object handle and the Login object. This example uses implementation-defined methods of readHandle and readLogin to retrieve these objects from storage.

  2. Authenticates to the database session with the same Login object as the first client through the authenticate method. You can recreate the Login object from the LoginServer object through the Login constructor.

    FileInputStream finstream = new FileInputStream (hellofile);
    ObjectInputStream istream = new ObjectInputStream (finstream);
    Hello hello = (Hello) orb.string_to_object(istream.readObject());
    finstream.close ();
    // Authenticate with the login Object
    LoginServer lserver = (LoginServer) readLogin(loginFile);
    //Set the VisiBroker bind options to specify that the
    //login is to not try recursively, which means that if it
    //fails on the first try, return with the error immediately.
    //See VisiBroker manuals for more information.
    lserver._bind_options (new BindOptions (false, false));
    Login login = new Login (lserver);
    login.authenticate (username, password, null);
In-Session Activation

If the server object wants to look up and activate a new published object in the same session in which it is running, the server object can execute the following:

Context ic = new InitialContext( );
SomeObject myObj = (SomeObject) ic.lookup("/test/Hello");

Notice that there are no environment settings for authentication information in the environment or a session URL in the lookup. The authentication already succeeded in order to log into the session. Plus, the object exists on the local machine. So, any other object activation within the session can proceed without specifying authentication information or a target sess_iiop URL address.

All object parameters designated within in-session object methods use pass-by-reference semantics, instead of pass-by-value semantics. The following example contains a single input object parameter of myParmObj into the foo method for the previously retrieved in-session object, myObj.;

With pass-by-reference, the reference to the input object parameter is directly passed to the destination server object. Any changes to the contents of the myParmObj on the client or the server are reflected to the other party--as both parties reference the same object. Alternatively, if it were pass-by-value, a copy of the myParmObj object would be passed. In this case, any changes to the party's copy of myParmObj would be visible only with the party that made the changes.


In-session activation as demonstrated in this section is valid for both IIOP and non-IIOP clients. 

In-Session Activation in Prior Releases

In releases previous to Release 8.1.7, in-session activation was performed with the thisServer/:thisSession notation in place of the hostname:port:SID in the URL. This notation is still valid, but only for IIOP clients.

For example, to look up and activate an object in the same session, do the following:

Hashtable env = new Hashtable();
env.put(Context.URL_PKG_PREFIXES, "oracle.aurora.jndi");
Context ic = new InitialContext(env);
SomeObject myObj =
   (SomeObject) ic.lookup("sess_iiop://thisServer/:thisSession/test/Hello");

In this case, myObj is activated in the same session in which the invoking object is running. Note that there is no need to supply login authentication information, because the client (a server object, in this case) is already authenticated to Oracle9i.

Realize that objects are not authenticated--instead, clients must be authenticated to a session. However, when a separate session is to be started, then some form of authentication must be done--either login or SSL credential authentication.


You can use the thisServer notation only on the server side--that is, from server objects. You cannot use it in a client program. 

Lookup of Objects Off of JNDI Context

In the Sun Microsystems JNDI, if you bind a name of "/test/myObject", you can retrieve an object from a Context when executing the following:

Context ctx = ic.lookup("/test");
MyObject myobj = ctx.lookup("myObject");

The returned object is activated and ready for you to perform method invocations off of it.

In Oracle9i, trying to retrieve an object from a Context results in an inactive object being returned. Instead, you must do the following:

  1. Retrieve a SessionCtx, instead of a Context. You can retrieve the SessionCtx from a ServiceCtx, in one of the two following ways:

    • Retrieve the ServiceCtx first and the SessionCtx from the ServiceCtx, as follows:

      ServiceCtx service =
              (ServiceCtx) ic.lookup("sess_iiop://localhost:2481:ORCL");
      //Retrieve the ServiceCtx subcontext
      SessionCtx sess = (SessionCtx) service.lookup("/test");
    • Retrieve the ServiceCtx and SessionCtx in the same lookup, as follows:

      SessionCtx sess =
              (SessionCtx) ic.lookup("sess_iiop://localhost:2481:ORCL/test");
  2. Execute the Oracle-specific SessionCtx.activate method for each object in the session that you want to retrieve. This method activates the object in the session and returns the object reference. You cannot just perform a lookup of the object, as it will return an inactive object. Instead, execute the activate method, as follows:

    MyObject myObj = (MyObject) sessCtx.activate("myObject");
    // Verify that the objects are indeed different
    System.out.println (myObj.printMe ());

The Oracle9i JNDI implementation provides two implementations of the Context object:

In performing a lookup, you must lookup both the ServiceCtx for identifying the database and the SessionCtx for retrieving the actual JNDI bound object. Normally, you supply the URLs for both objects within the JNDI URL given to the lookup method. However, you can also retrieve each individually as demonstrated above.

Setting Session Timeout

A session--with its state--normally exits when the last connection terminates. However, there are situations where you may want a session and its state to idle for a specified amount of time after the last connection terminates, such as the following:

The timeout clock starts when the last connection to the session terminates. If another connection to the session starts within the timed window, the timeout clock is reset. If not, the session exits.

You can set the session idle timeout either from the client or from within a server object:

Set the Session Timeout from the Client

You can set the idle timeout on the client through the pre-published utility object--oracle.aurora.AuroraServices.Timeout. This object is pre-published under "/etc/timeout". Use the setTimeout method from this object.

  1. Retrieve the Timeout object through a JNDI lookup of "/etc/timeout"

  2. Set the timeout with the setTimeout method giving the number of seconds for session idle.

    Timeout timeout = (Timeout)ic.lookup(serviceURL + "/etc/timeout");
    System.out.println("Setting a timeout of 20 seconds ");

Set the Session Timeout from a Server Object

A server object can control the session timeout by using the object, which contains the sessionTimeout() method. This method takes one parameter: the session timeout value in seconds. For example:

int timeoutValue = 30;
// set the timeout to 30 seconds;
// set the timeout to a very long time;


When you use the sessionTimeout() method, you must add $(ORACLE_HOME)/javavm/lib/ to your CLASSPATH. 

Retrieving the Oracle9i Version Number

You can retrieve the version of Oracle9i that is installed in the database through the pre-published oracle.aurora.AuroraServices.Version object, which is published as "/etc/version" in the JNDI namespace. The Version object contains the getVersion method, which returns a string that contains the version, such as "8.1.7". You can retrieve the Version object by providing "/etc/version" within the JNDI lookup. The following example retrieves the version number:

Version version = (Version)ic.lookup(serviceURL + "/etc/version");
System.out.println("The server version is : " + version.getVersion());

Activating In-Session CORBA Objects From Non-IIOP Presentations

Non-IIOP server requests, such as HTTP or DCOM, can activate a CORBA object within the same session.

  • HTTP

An HTTP client interacts with the Oracle9i webserver and executes a JSP or servlet, which can activate the CORBA object within the same session that it is running in.

  • DCOM

A DCOM client uses a DCOM bridge to access Oracle9i. While within the Oracle9i session, the DCOM bridge session can activate the CORBA object within the same session that it is running in.

If the non-IIOP server object wants to look up and activate a new published object in the same session in which it is running, the server object can execute the following:

Context ic = new InitialContext( );
SomeObject myObj = (SomeObject) ic.lookup("/test/Hello");


Once you retrieve the IIOP object reference through this method, you cannot pass this object to a remote client or server.  

Notice that there are no environment settings for authentication information in the environment or a URL specified in the lookup. The authentication already succeeded in order to log into the session. Plus, the object exists on the local machine. So, any other object activation within the session can proceed without specifying authentication information or a target URL address.

Accessing CORBA Objects Without JNDI

It is possible for clients to access server objects without using the JNDI classes shown in the other sections of this chapter. These clients can connect to an Oracle server by using CosNaming methods.

Retrieving the NameService Initial Reference

In order to use the CORBA ORB methods, you must first retrieve the naming service object. Oracle9i prepublishes a NameService object that you can retrieve through the ORB resolve_initial_references method.

In CORBA, there are two methods to retrieve the NameService initial reference: using ORBInitRef or ORBDefaultInitRef. At this time, we have provided only the ORBDefaultInitRef methodology.

You must provide a service URL to the ORBDefaultInitRef of the form of host, port, and SID. Or you can provide the service URL with host, port, service name. In addition, you can specify some optional properties, such as:

Example 4-3 Retrieving a Server Object Using CosNaming

The following example demonstrates how to retrieve the NameService object. From this object, the login is executed and the server object is retrieved.

import java.lang.Exception;

import org.omg.CORBA.Object;
import org.omg.CORBA.SystemException;
import org.omg.CosNaming.NameComponent;

import oracle.aurora.client.Login;
import oracle.aurora.AuroraServices.LoginServer;
import oracle.aurora.AuroraServices.LoginServerHelper;
import oracle.aurora.AuroraServices.PublishedObject;
import oracle.aurora.AuroraServices.PublishingContext;
import oracle.aurora.AuroraServices.PublishedObjectHelper;
import oracle.aurora.AuroraServices.PublishingContextHelper;

import Bank.Account;
import Bank.AccountManager;
import Bank.AccountManagerHelper;

public class Client {
  public static void main(String args[]) throws Exception {
    // Parse the args
    if (args.length < 4 || args.length > 5 ) {
      System.out.println ("usage: Client host port username password <sid>");
    String host = args[0];
    String port = args[1];
    String username = args[2];
    String password = args[3];
    String sid = null;
    if(args.length == 5)
      sid  = args[4];

    // Declarations for an account and manager
    Account account = null;
    AccountManager manager = null;
    PublishingContext rootCtx = null;

    // access the Oracle9i Names Service
    try {
      // Initialize the ORB
      // The service URL for the server is provided in a string
      // that is prefixed with 'iioploc://' and includes either
      // host, port, sid or, if the USE_SERVICE_NAME is set to true,
      // host, port, service_name. This example uses host, port, sid
      // and sets it in the ORBDefaultInitRef.
      String initref;
      initref = (sid == null) ? "iioploc://" + host + ":" + port :
	"iioploc://" + host + ":" + port + ":" + sid;
      System.setProperty("ORBDefaultInitRef", initref);

       * Alternatively, you can set the host, port, sid or service in the 
       * following individual properties. If set, these properties
       * take precedence over the URL set within the ORBDefaultInitRef property
      System.setProperty("ORBBootHost", host);
      System.setProperty("ORBBootPort", port);
      if (sid != null)
         //set the SID. alternatively, if the USE_SERVICE_NAME property is
      //true, this should contain the service name instead of the sid.
	System.setProperty("ORACLE_SID", sid);

       * Some of the other properties that you can set
       * include the backwards compatibility flag, the service name
       * indicator, the SSL protocol definition, and the transport type.
       System.setProperty("ORBNameServiceBackCompat", "false");
       System.setProperty("USE_SERVICE_NAME", "true");
       System.setProperty("ORBUseSSL", "true");
       //transport type can be either sess_iiop or iiop
       System.setProperty("TRANSPORT_TYPE", "sess_iiop");

       //initialize the ORB
       com.visigenic.vbroker.orb.ORB orb = 
oracle.aurora.jndi.orb_dep.Orb.init(); // Get the Name service Object reference with the
// resolve_initial_references method rootCtx = PublishingContextHelper.narrow(orb.resolve_initial_references( "NameService")); //After retrieving the NameService initial reference, you must perform // the login, as follows: // Get the pre-published login object reference PublishedObject loginPubObj = null; LoginServer serv = null; NameComponent[] nameComponent = new NameComponent[2]; nameComponent[0] = new NameComponent ("etc", ""); nameComponent[1] = new NameComponent ("login", ""); // Lookup this object in the Name service Object loginCorbaObj = rootCtx.resolve (nameComponent); // Make sure it is a published object loginPubObj = PublishedObjectHelper.narrow (loginCorbaObj); // create and activate this object (non-standard call) loginCorbaObj = loginPubObj.activate_no_helper (); serv = LoginServerHelper.narrow (loginCorbaObj); // Create a client login proxy object and authenticate to the DB Login login = new Login (serv); login.authenticate (username, password, null); // Now create and get the bank object reference PublishedObject bankPubObj = null; nameComponent[0] = new NameComponent ("test", ""); nameComponent[1] = new NameComponent ("bank", ""); // Lookup this object in the name service Object bankCorbaObj = rootCtx.resolve (nameComponent); // Make sure it is a published object bankPubObj = PublishedObjectHelper.narrow (bankCorbaObj); // create and activate this object (non-standard call) bankCorbaObj = bankPubObj.activate_no_helper (); manager = AccountManagerHelper.narrow (bankCorbaObj); account = ("Jack.B.Quick"); float balance = account.balance (); System.out.println ("The balance in Jack.B.Quick's account is $" + balance); } catch (SystemException e) { System.out.println ("Caught System Exception: " + e); e.printStackTrace (); } catch (Exception e) { System.out.println ("Caught Unknown Exception: " + e); e.printStackTrace (); } } }

See "Ending a Session" for more information on the LoginServer, Login, and LogoutServer objects.

Retrieving Initial References from ORBDefaultInitRef

CORBA 2.3 Interoperable Name Service supports both the ORBInitRef and ORBDefaultInitRef methodologies for creating and retrieving initial references. At this time, Oracle9i only supports an IIOP URL scheme within the ORBDefaultInitRef, as shown in "Retrieving the NameService Initial Reference". You can only provide either a host, port, SID or host, port, service name combination--prefixed by "iioploc://"--to the ORBDefaultInitRef for locating the initial reference. Within this location, the service must have been activated. Any service activated within the specified location can be retrieved using the resolve_initial_references method with its object key, which is defined at the time of activation.

For example, if you set the ORBDefaultInitRef to the following server URL:


Then, initialize the ORB and retrieve your service, as follows:

//initialize the ORB
com.visigenic.vbroker.orb.ORB orb = oracle.aurora.jndi.orb_dep.Orb.init();

// Get the myService service Object reference with resolve_initial_references 
rootCtx = PublishingContextHelper.narrow(orb.resolve_initial_references(

The object key that is used to retrieve the service is "myService". The object with this key is returned with the resolve_initial_references method.

The following are the Oracle9i services that are activated during startup: NameService, BootService, AuroraSSLCurrent, and AuroraSSLCertificateManager.

If you want Oracle9i to initiate any services for you during startup, supply a string with a comma-separated list of services to be installed when the ORB is initialized in the UserORBServices property. Each service must be a fully-qualified package name and name of the class that extends the ORBServiceInit class. You must extend this class in order for your service to be installed by Oracle9i.

Go to previous page Go to next page
Copyright © 1996-2001, Oracle Corporation.

All Rights Reserved.
Go To Documentation Library
Go To Product List
Book List
Go To Table Of Contents
Go To Index

Master Index