Previous Contents Index Next |
Sun Java System Application Server Standard and Enterprise Edition 7 2004Q2 Update 3 Administration Guide

> ## Chapter 11
> Configuring the Server For Corba/IIOP Clients

> This chapter explains how to configure support for CORBA/IIOP clients, using the RMI/IIOP protocol within the Application Server environment.

> This chapter includes the following topics:

> - About Support for CORBA/IIOP Clients
> - Configuring the ORB

> ##

> About Support for CORBA/IIOP Clients

> The J2EE platform provides indirect support for various types of clients, different hardware platforms, and a multitude of software applications through its interoperabillity requirements. As a J2EE-compliant product, Application Server supports a standard set of protocols and formats that ensure interoperabillity.

> The CORBA (Common Object Request Broker Architecture) model is based on clients requesting services from distributed objects or servers through a well-defined interface, by issuing requests to the objects in the form of remote method requests. A remote method request carries information about an operation that needs to be performed including the object name (called an object reference) of the service provider and the actual parameters, if there are any. CORBA automatically handles a lot of network programming tasks such as object registration, object location, object activation, request de-multiplexing, error-handling, marshalling and operation dispatching.

> The following topics are covered in this section:

> - About Interoperabillity
> - About the ORB
> - About the RMI/IIOP Functionality
> - About the Authentication Process

> ### About Interoperabillity

> Interoperabillity essentially means the ability of an enterprise environment to bring together applications written in various languages. One or more of these existing applications may be running on a personal computer platform, while others may be running on UNIX. In addition, these enterprise environments may also be supporting standalone Java technology based applications that are not directly supported by the J2EE platform.

> J2EE is mandated to provide support for CORBA IIOP (Internet Inter-Orb Protocol) protocol. CORBA defines a model that specifies interoperabillity between distributed objects on a network in a way that is transparent to the user. CORBA achieves this by defining ways for specifying the externally visible characteristics of a distributed object in a way that is implementation-independent.

> ### About the ORB

> Object Request Broker (ORB for short) is the central component of CORBA. The ORB provides the required infrastructure to identify and locate objects, handle connection management, deliver data and request communication.

> One CORBA object never talks directly with another. Instead, the object makes requests through a remote stub to the ORB running on the local machine. The local ORB then passes the request to an ORB on the other machine using Internet Inter-Orb Protocol (IIOP for short). The remote ORB then locates the appropriate object (servant) processes the request and returns the results. IIOP can be used as a Remote Method Invocation (RMI for short) protocol by JAVA applications or objects, using the RMI-IIOP technology.

> The ORB bundled with Sun Java System Application Server provides support for load balancing RMI/IIOP application requests. For information on how to enable load balancing in your client applications, see Chapter 18, "Configuring RMI/IIOP Load Balancing and Failover (Enterprise Edition)."

> ### About the RMI/IIOP Functionality

> CORBA specifies the ORB which allows applications to communicate with each other regardless of location. This interoperabillity is delivered through IIOP, and is typically found in an Intranet setting. Some of the functionalities achieved by RMI over IIOP are as follows:

> - Interoperabillity with objects written in other languages.
> - Ability to propagate transaction and security context.
> - Plug-and-play environment for ORB services.
> - Interoperabillity with EJBs
> - Use of the COSNaming service, an IIOP-based naming service. The EJB interoperabillity protocol requires the use of the COSNaming to look up EJB objects using the Java Naming Directory Interface (JNDI for short) API.

> The JAVA ORB that comes bundled with Application Server supports the following functionalities:

> - Conformance level 0 of CSIv2 (Common Secure Interoperabillity version 2).
> - Fully compliant COSNaming service implements the IDL interfaces and aid the EJB container to publish EJBHome references.
> - IIOP/GIOP Ver 1.2. CORBA specifies the ORB which allows applications to communicate with each other regardless of location. This interoperabillity is delivered through IIOP.

> Note | Failover and load balancing of remote references of EJB and Name Server objects along the RMI/IIOP path is available in the Enterprise Edition of Sun Java System Application Server. For more information on how to configure RMI/IIOP load balancing, see Chapter 18, "Configuring RMI/IIOP Load Balancing and Failover (Enterprise Edition)."

> ### About the Authentication Process

> Authentication is the process of confirming an identity. In the context of network interactions, authentication is the confident identification of one party by another party. Certificates are one way of supporting authentication.

> The following two kinds of authentication are applicable:

> Server Authentication. Server authentication refers to the confident identification of a server by a client; that is, identification of the organization assumed to be responsible for the server at a particular network address.

> Client Authentication. Client authentication refers to the confident identification of a client by a server; that is, identification of the person assumed to be using the client software.

> Clients can have multiple certificates, much like a person might have several different pieces of identification.

> ##

> Configuring the ORB

> You can configure multiple IIOP-listeners for each instance of Application Server. By default, one IIOP listener is configured. You can configure the IIOP listener properties for your ORB and add additional listeners.

> You can also enable monitoring for the ORB, specify the log level at which messages will be logged, specify thread pool settings, and configure IIOP listener ports and SSL configuration for the IIOP path. In this section, we will discuss how to configure ORB support for an instance of Application Server.

> The following topics are included in this section:

> - To Perform General ORB Configuration
> - To Configure IIOP Listener For the ORB

> ### To Perform General ORB Configuration

> Using the Administration interface, you can enable monitoring, set log levels, and configure pool settings for the thread pool. To perform general ORB configuration, perform the following tasks:

> 1. In the left pane of the Administration interface, expand the Application Server instance for which you want to configure ORB settings.
> 2. Click the ORB tab. The General ORB Configuration page is displayed.
> 3. In the General section of this window, you can enable monitoring, and set log levels for your ORB.
> 1. To enable monitoring for the ORB, mark the Monitoring Enabled checkbox.
> 2. Choose the log level you want, from the Log Level drop-down list. The default log level for the server is typically set to INFO. The default level for the ORB is to use the default for the server. The log level will therefore display Default (INFO), in the drop-down list.

> Log levels are provided to record messages of a range of severity, from FINEST to FATAL. Setting a log level allows you to select what granularity of messages are displayed in the log. A granularity of WARNING will display WARNING, ALERT, SEVERE and FATAL messages. Normally you would need to set the granularity at the server-wide level, but you can use this setting to control the messages displayed from the Application Server ORB.

> 4. In the Thread Pool section of this window, you can specify the pool settings for the request threads used by the ORB.

> Request threads handle user requests for application components. When Application Server receives a request, it assigns the request to a free thread from the thread pool. The thread executes the client’s requests and returns results. For example, if the request needs to use a system resource that is currently busy, the thread waits until that resource is free before allowing the request to use that resource.

> You can specify the minimum and maximum number of threads that are reserved for requests from applications. The thread pool is dynamically adjusted between these two values. The minimum thread-pool size you specify signals the ORB to allocate at least that many threads in reserve for application requests. That number is increased upto the maximum thread-pool size that you specify.

> Increasing the number of threads available to a process allows the process to respond to more application requests simultaneously.

> 1. In the Steady Pool Size field, specify the minimum number of threads in the pool. The pool will also shrink to this number after threads are idle for the period specified in the Idle Timeout (secs) field.
> 2. In the Max Pool Size field, specify the maximum number of threads to which the thread pool can grow.
> 3. In the Idle Timeout (secs) field, specify the timeout for the idle threads in the threadpool to be cleaned up.
> 5. In the Advanced section of this window, you can configure advanced options for your ORB, as follows:
> 1. In the Message Fragment Size field, specify the maximum GIOP 1.2 message size, in order to support fragmentation. The default fragment size is 1024.
> 2. In the Total Connections field, specify the maximum number of incoming remote IIOP connections allowed by the ORB server process.
> 6. Click Save to save your settings. If you want to revert to your previous settings without saving the recent changes, click Revert.

> ### To Configure IIOP Listener For the ORB

> Each new instance of Application Server comes with a default ORB configuration, which includes a pre-configured IIOP listener. The IIOP listener is a listen socket that listens on a specified port and accepts incoming connections from CORBA based client application You can configure any number of IIOP listeners for a single instance of Application Server.

> To create a new IIOP listener or to configure IIOP listener properties, perform the following tasks:

> 1. In the left pane of the Administration interface, expand the Application Server instance for which you want configure ORB properties.
> 2. Click ORB, and open the IIOP Listener tab under it. You will see a list of all the IIOP Listeners that have been configured for that specific instance of Application Server.
> 3. To create a new IIOP Listener, click New (if you are editing an existing IIOP listener, just open the listener and perform tasks listed in the following steps). When you click New, or when you open an existing IIOP listener, you will see the Creating a New IIOP Listener page.

> 4. You can configure general parameters for your IIOP listener, as follows:
> 1. In the Id text field, provide a name to identify the listener. You can use any identifier, such as ORB_Listener1, ORB_Listener2, etc.
> 2. In the Address text field, type the address of the machine on which you have installed Application Server. You can either specify the machine address in the machinename.domainname format, as indicated in the given example, or you can provide the IP address of the machine.
> 3. In the Port text field, type a unique port number for the new IIOP Listener. The default IIOP listener comes with a default port number. You can change this port number. However, before changing the port number, please ensure that the new port number that you specify is not being used by any other existing software application or process.
> 4. To enable the listener, mark the Listener Enabled checkbox.
> 5. In the SSL/TLS Settings section on this page, you can set security for the IIOP listener. Check the appropriate boxes associated with the Secure Sockets Layer (SSL) and Transport Layer Security (TLS), including all the ciphers. You can select either SSL2 or SSL3/TLS sockets.You can configure the SSL/TLS settings for your listener, as follows:
> 1. In the Certificate Nickname field, provide the nickname of the certificate that the server presents to the client during SSL handshake. You must have previously installed a certificate to see its nickname in this list.
> 2. Mark the SSL2 Enabled field, to enable SSL2 security option for the listener path.
> 3. Select the SSL2 ciphers that you want to use for the SSL2 security. Mark the checkboxes against the required ciphers. Unless you have a compelling reason for not using a specific cipher suite, you should allow them all.
> 4. Mark the SSL3 Enabled field, to enable SSL3 security option for the listener path.
> 5. Mark the TLS Enabled field, to enable TLS. TLS must also be enabled on the browser seeking access to your server. Check both TLS and SSL3 for Netscape Navigator 6.0.
> 6. Mark the TLS Rollback Enabled field. In order to enable TLS Rollback, you need to enable TLS first. Also ensure that SSL3 and SSL2 are disabled, when you enable this option. Use the TLS Rollback option for Microsoft Internet Explorer 5.0 and 5.5.
> 7. Select the SSL3/TLS ciphers that you want to use for SSL3 and TLS. Select these only if you have enabled SSL3 or TLS. Unless you have a compelling reason for not using a specific cipher suite, you should allow them all.
> 8. Mark the Client Authentication Enabled checkbox to indicate whether the ORB listener port for SSL IIOP connections with client authentication is enabled or not. Client authentication is the process of authenticating client certificates by cryptographically verifying the certificate signature and the certificate chain leading to the CA on the trust CA list.
> 6. Click OK to save the IIOP listener settings.

> Note | When you install Application Server, an IIOP listener is created for the default server instance. The default port number for the default IIOP listener port is 3700. Please note that each IIOP listener must bear a different port number. Also note that the machine address that you provide in the Address text field must be the address of the machine on which Application Server is installed. For more information about SSL settings for the listener path, and other details of security for Application Server, see the Sun Java System Application Server Administration Guide to Security.

> Previous Contents Index Next

> Copyright 2005 Sun Microsystems, Inc. All rights reserved.