Oracle8i Enterprise JavaBeans Developer's Guide and Reference Release 3 (8.1.7) Part Number A83725-01 |
|
Figure 3-3 shows the interaction between the listener and the dispatchers, and also illustrates how an Oracle8i ORB session is activated.
The incoming request is examined by the shared server services to see if the request is for an existing session. If so, the request is forwarded to the indicated session. If not, the service creates a new database session for the request 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 reads the incoming IIOP messages, authenticates the client, finds and activates the corresponding server-side objects, and sends IIOP messages as needed to reply to the connected client. Subsequent messages from the client are directed to the existing session.
When you configure a listener, you need to configure separate ports as listening endpoints for both Net8 and IIOP connections. Similarly, if you want any endpoint to use the secure socket layer (SSL), you will also need a separate endpoint for an SSL-enabled IIOP endpoint. See "Using the Secure Socket Layer" for more information about connecting using IIOP and SSL.
The administrator for your database configures an MTS server with a dispatcher that is GIOP enabled. In addition, the administrator configures a listener that this dispatcher registers with upon database startup.
When the database does start up, all dispatchers register with all listeners configured within the same database initialization file. However, when an IIOP client invokes a request, the listener will only redirect the request to a GIOP dispatcher or hand off to a generic dispatcher.
These are discussed fully in the following sections:
The listener recognizes the IIOP protocol and redirects the request to a registered GIOP dispatcher.
The listener redirects if a GIOP dispatcher is configured. If no GIOP dispatcher is configured, the listener can hand off the request to a generic dispatcher. See "Hand Off to Generic Dispatcher" for more information.
If there is no GIOP dispatcher statically configured, but there is a generic dispatcher configured, the listener can hand off the request to this dispatcher. The only restrictions are that the listener and dispatcher must exist on the same node in order for the hand off to occur and that the listener must be either statically or dynamically configured to receive an IIOP request.
For hand off to occur, the listener forfeits the socket to the dispatcher. Thus, this can only occur within a single node.
Figure 3-5 shows the dispatcher and listener combination in a hand off environment.
The listener must be configured to receive IIOP requests. You can either statically configure the listener through the Net8 configuration, or you can dynamically configure the listener through a dynamic registration tool,
Note:
regep
. See "Dynamic Listener Endpoint Registration" for more information.
The client communicates directly with the dispatcher from this point on. The client is never made aware that the socket was handed off.
As discussed in "Hand Off to Generic Dispatcher", a listener will hand off the socket to an existing generic dispatcher. In order for a hand off to occur for an IIOP incoming request, the listener must have an IIOP endpoint registered. You can register any listening endpoint through either of the following:
regep
The dynamic registration tool, regep
, adds any type of listening endpoint to your listener. This includes an IIOP listening endpoint. The following describes how to use the dynamic registration tool for an IIOP listening endpoint.
The restrictions for this scenario are as follows:
The advantage for dynamically registering a listener endpoint is that you do not need to restart your database for this listener to be IIOP enabled. The listening endpoint is active immediately.
For full details on the regep
tool, see the Oracle8i Java Tools Reference Guide.
The following line dynamically registers a listener on the SUNDB
host on endpoint port number 2241. This tool logs on to the SUNDB
host.
regep -pres oracle.aurora.server.SGiopServer -host sundb -port 2241
If you want your client to go to a dispatcher directly, bypassing the listener, you direct your client to the dispatcher's port number. Do one of the following to discover the dispatcher's port number:
lsnrctl
service
.
If you choose to configure the port number, the following shows the syntax:
mts_dispatchers="(address=(protocol=tcp | tcps)
(host=<server_host>)(port=<port>))
(presentation=oracle.aurora.server.SGiopServer)"
The attributes are described below:
The client supplies the port number on its URL, as follows:
session_iiop://<hostname>/:<portnumber>
Notice that the URL excludes a SID or service name. The dispatcher does not need the SID instance or service name because it is a directed request.
Oracle8i also supports the use of authentication data such as certificates and private keys required for use by SSL in combination with GIOP. To configure your transport to be SSL-enabled with GIOP, do the following:
The following sections detail how to accomplish these three steps.
You must edit the database initialization file to add an SSL-enabled dispatcher. Uncomment the MTS_DISPATCHERS parameter in the database initialization file that defines the TCPS port. During installation, the Database Configuration Assistant always includes a commented out line for SSL TCP/IP. This line is as follows:
mts_dispatchers="(protocol=tcps)(presentation=oracle.aurora.server.SGiopServer)"
Modify the listener to accept SSL requests on port 2482.
This brings you to the listening port panel, as shown in Figure 3-6.
These steps will add wallet and SSL configuration information into both the listener and database configuration files. The SSL wallet location must be specified in both the listener and database configuration files. Both entities must locate the wallet for certificate handshake capabilities.
listener.ora
file: ssl_client_authentication=false ssl_version=undetermined
The default is for the database to authenticate the client. If you want the listener to authenticate the client, change the ssl_client_authentication
parameter to true.
sqlnet.ora
file: ssl_client_authentication=true ssl_version=0 sqlnet.crypto_seed=<seed_info
>
If you did not request client authentication, the ssl_client_authentication
parameter will be false. The default value is for client authentication to be true. In addition, you can specify a specific SSL version number, such as 3.0, in the ssl_version
parameter. The ssl_version
value of 0 means that the version is undetermined and will be agreed upon during handshake.
listener.ora
and database's sqlnet.ora
files, the wallet location is specified:oss.source.my_wallet=(source= (method=file) (method_data= (directory=wallet_location)))
The Oracle Advanced Security Administrator's Guide describes how to set up the SSL wallet with the appropriate certificates.
This brings you to the listener location panel, as shown in Figure 3-2.
This places the following in the listener.ora
file: it modifies the listener to specify TCPS --instead of TCP--as the protocol with port number 2482. The following shows an example of an SSL-enabled listener on the sales-server
host.
listener= (description_list= (description= (address=(protocol=tcps)(host=sales-server)(port=2482)))) (protocol_stack= (presentation=giop) (session=raw)))
|
Copyright © 1996-2000, Oracle Corporation. All Rights Reserved. |
|