Connections and Security

Services and Sessions

This section describes the Oracle8i IIOP services, session IIOP and standard IIOP, and the use of the Oracle8i session for EJB and CORBA applications.

About the Session IIOP Protocol

Standard CORBA does not support the concept of sessions, but the session concept is fundamental to the Oracle8i database and the JServer ORB. In a "standard" CORBA server and ORB, the server and ORB are always running, and when an object is activated it is registered with the ORB, and is available while the server is running. In Oracle8i JServer, objects are activated on demand from a client, in a database session. Each session has its own "virtual" Java VM, and the ORB is activated to run in that VM. The Oracle8i Java Developer's Guide explains why this activation model is efficient in terms of memory usage, and why it scales well.

Because objects are activated in a session, the ORB and the database need a means to be able to distinguish objects within the same server process based on the sessions in which they are activated.

In standard IIOP, a connection is identified by its host and port number. The host and port number is also encoded into object references (IORs). However with session IIOP, a client can connect to multiple sessions within a service, not just to multiple services.

The fundamental point is that the session IIOP service provides a way for applications and server objects to distinguish among sessions as well as services.

This service introduces a new component tag, SessionIIOP, inside the IIOP profile (TAG_INTERNET_IOP--the OMG component tag for Oracle session IIOP is 0x4f524100). The session IIOP component tag has information that uniquely identifies the session in which the object was activated. This information is used by the client ORB runtime to send requests to the right objects in the right session.

While the Oracle8i session IIOP service provides an enhancement of the standard IIOP protocol, in the sense that it includes session ID information, it does not differ at all 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 Oracle8i has been extended to support this, and discussions are underway to have this supported by other ORB vendors as well.

Session Routing

When a client makes an IIOP connection to the database, the server code must decide 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 is doing a new request for a connection (using the InitialContext.lookup() method), and no session is active for that connection, then a new session is automatically started.

For session routing to work, standard IIOP is sufficient. Session IIOP is needed only if the same client requires access to objects residing in multiple sessions. With session IIOP the server is able to decide, on the basis of the object being activated, whether to activate a new session or rout to an existing session, depending on the absence or presence of a session ID component tag inside the IIOP profile.

Configuration for IIOP

To access oracle servers, client programs do not really need to do anything special. It is only necessary to have a listener configured to accept IIOP requests, and be able to redirect the requests to a dispatcher port that accepts session IIOP. See the Oracle8i Net8 Administrator's Guide for information about configuring the INITSID.ORA file for the IIOP protocols.

A session is a specific connection of a client to a service. For example, when a tool such as SQL*Plus makes a connection through Net8 to a listener TTC port, Oracle8i establishes a new database session to handle the connection and provide SQL support. Similarly, when an incoming IIOP request from a CORBA or EJB client program is handled, a new session is also established by Oracle8i.

In the case of a session IIOP request the new session that is established has, independent Java VM, complete with the session's own ORB. The memory footprint for a new Java VM session with an ORB is quite low, being only about 150 kB.

See "Session Management" for information about activating services and sessions using JNDI. See "Services and Sessions" for a discussion of why Oracle supports the session IIOP service.

Database Listeners and Dispatchers

When the listener receives a request for an IIOP connection from a client, it assigns an IIOP dispatcher to the client request, and sends an IIOP reply to ask the client to reconnect to the dispatcher. Figure 4-2 shows the interaction between the listener and the dispatchers, and also illustrates how an Oracle8i ORB session is activated.

Figure 4-2 Listener/Dispatcher Interaction

When a shared server services a new IIOP connection, it first creates a new database session for it and activates the ORB in the session. This session is very similar to the database sessions created for incoming Net8 connections. In the session the ORB takes care of reading the incoming IIOP messages, authenticating the client, finding and activating the corresponding server-side objects, and sending IIOP messages as needed to reply to the client that connected.

Further IIOP messages from the same client are routed directly to the existing session and handled similarly by the ORB.

When you configure a listener to accept both Net8 and IIOP connections, there is no need to distinguish between session IIOP and "standard" IIOP. The listener handles both on the same port. However, you do need a separate port for secure socket layer (SSL) connections. See "Using the Secure Socket Layer" for more information about connecting using IIOP and SSL.

URL Syntax

Oracle8i 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 Figure 4-3.

Figure 4-3 Service URL

The service URL is composed of four pieces:

The service name followed by a colon and two slashes: sess_iiop:// for a session IIOP request.
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.
The listener port number for IIOP services. The default is 2481.
The system identifier or SID, for example: ORCL.

Colons are always used to separate the hostname, port, and SID.

If you specify a dispatcher port instead of a listener port, and you specify a SID, an ObjectNotFound exception is thrown by the server. (If you specify a dispatcher port, you cannot specify a SID. Since 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:

sess_iiop://localhost:2481:ORCL/:default/projectAurora/Plans816/getPlans

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.

Note:
You do not specify the session name when no session has been established for that connection. That is, on the first lookup there is no session active, hence :default as a session name has no meaning.

Each component of the URL represents a Java class. For example, the service name is represented by a ServiceCtx class instance, the session by a SessionCtx instance. (See the ORB JavaDoc on the distribution CD for detailed documentation of these classes. The most relevant methods and variables are also described below.)

The Service Context Class

Oracle provides a service context class that extends the JNDI Context class.

Variables

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

ServiceCtx Public Variables

String Name	Value
DEFAULT_SESSION	":default"
NON_SSL_CREDENTIAL	"Credential"
NON_SSL_LOGIN	"Login"
SSL_CREDENTIAL	"SecureCredential"
SSL_LOGIN	"SecureLogin"
SSL_30	"30"
SSL_20	"20"
SSL_30_WITH_20_HELLO	"30_WITH_20_HELLO"
THIS_SERVER	":thisServer"
THIS_SESSION	":thisSession"
Integer Name	Integer Constructor
SESS_IIOP	new Integer(2)
IIOP	new Integer(1)

Methods

The public methods in this class that can be used by CORBA and EJB application developers are documented in this section.

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.

Throws
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)

Gets access to the ORB created when you do a look up. Set the ssl parameter true for SSL authentication. This method should be used by clients that do not use JNDI to access server objects.

See "sharedsession" for a usage example.

public synchronized SessionCtx login()

login() authenticates the caller using the properties in the initial context environment, and then activates a new session and returns the session context. The returned object is narrowed to the appropriate type.

Throws javax.naming.NamingException.

public Object lookup(String string)

lookup() 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.

public Object _lookup(String string)

_lookup() looks up a published object in the database instance associated with the service context, and either returns the object, or throws javax.naming.NamingException. Unlike with lookup(), the object is not activated.

The Session Context Class

Oracle provides a session context class, SessionCtx, that extends the JNDI Context class. Session contexts represent sessions, and contain methods that let you perform session operations such as authenticating the client to the session or activating objects.

Methods

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

public synchronized boolean login()

login() authenticates the client using the initial context environment properties that were passed in the InitialContext constructor: username, password, and role.

public synchronized boolean login(String username,

                                 String password,

                                String role)

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


public Object activate(String name)

Looks up and activates a published object having the name name.