|Oracle8i Enterprise JavaBeans and CORBA Developer's Guide
This section describes the Oracle8i IIOP services, session IIOP and standard IIOP, and the use of the Oracle8i session for EJB and CORBA applications.
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.
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.
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
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.
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.
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.
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.
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.
The service URL is composed of four pieces:
myPC-1. You can also use
localhost, or the numeric form of the IP address for the host.
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.)
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 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.
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
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.)
Oracle provides a service context class that extends the JNDI
ServiceCtx class defines a number of final public static variables that you can use to define environment properties and other variables. Table shows these.
The public methods in this class that can be used by CORBA and EJB application developers are documented in this section.
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
(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.
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.
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
_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.
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.
The session context methods that a client uses are the following:
login() authenticates the client using the initial context environment properties that were passed in the InitialContext constructor: username, password, and role.
login() authenticates the client using the username, password, and optional database role supplied as parameters.
Looks up and activates a published object having the name