InfoCenter Home >
6: Administer applications >
6.6: Tools and resources quick reference >
6.6.32: Administering name service support (overview)

6.6.32: Administering name service support (overview)

Domain Name Service (DNS) support

The application server can act as a Domain Name Service (DNS) client. In some cases, DNS access is required. For applications using enterprise beans, a name service is also provided.

WebSphere Application Server clients and DNS resolution

By default, a WebSphere administrative server or application server uses the IP address of the local host on which it is running in its object references. Thus, clients of these servers do not usually need to have DNS enabled in order to access these object references, nor do they need to be on the same network as the server.

However, in cases where DNS is disabled on the client machine, additional steps must be performed for certain clients as follows:

  • If the product edition you are using provides a Java-based administrative console (WebSphere Administrative Console), it must be run with the -primaryNode option:
    -primaryNode <name of administrative server to which to connect>
  • If the product edition you are using supports clients that rely on the workload management features of WebSphere Application Server, the clients must be run with the system property com.ibm.ejs.wlm.BootstrapNode:
    -Dcom.ibm.ejs.wlm.BootstrapNode=<name of administrative server to which to connect>

By default, the administrative server name is the short name of the host on which it is running. As shown above, use an argument to specify the administrative server host name, which is required because the clients do name service lookups for names that are qualified by the administrative server name. Usually, if DNS is enabled, they can derive the administrative server name by doing a DNS reverse translation; however, if DNS is disabled, then they have to be explicitly provided with the administrative server name.

In some situations, it might be necessary to override the default value for the host information in the object references generated by WebSphere administrative or application servers. To do this, set the system property com.ibm.CORBA.LocalHost as follows:

-Dcom.ibm.CORBA.LocalHost=<value>
where <value> can be a host name (long or short) or an IP address. Set this property on a per server basis.

Some possible reasons for overriding this value are as follows:

  • The host machine has multiple IP addresses.

    Given the default behavior, either address could be selected, possibly arbitrarily. The LocalHost property should be set to specify a single IP address to be used in all object references.

  • You want to place the host name, rather than the IP address, in the object references.

    This might be necessary for situations in which external clients exist outside a firewall, and these clients cannot access the internal network directly. In this case, the host name can be translated to a gateway machine, which can then translate and forward to the internal network using the real IP address.

Java Remote Method Invocation (RMI) support

Applications can invoke RMI servers, but should not be RMI servers

WebSphere Application Server supports servlets that invoke Remote Method Invocation (RMI) servers, but the servlets are not permitted to be RMI servers themselves. They can be RMI clients. The same applies to enterprise beans. If this guideline is violated, a java.rmi.RMISecurityException will result.

Do not set security managers in RMI clients

Correct use of the Java RMI services requires that a security manager (for example, class java.rmi.RMISecurityManager) be set within the RMI server. Typically, a security manager will not be set in the RMI client program.

As such, a servet acting as an RMI client should not set a security manager. The same applies to enterprise beans acting as RMI clients. Setting a security manager within a servlet (that is acting as an RMI client) is not only incorrect usage of RMI, but will cause problems for the server. The security manager will be global to the server and will affect server operations.

If one of your applications currently sets a security manager when it should not be doing so, stop the application server containing the application, remove the statements that set the security manager, and start the application server again.

Go to previous article: Setting the ORB timeout value Go to next article: Administering environment entries (overview)

 

 
Go to previous article: Setting the ORB timeout value Go to next article: Administering environment entries (overview)