DCE Replacement Strategies

Chapter 3. Replacement strategies 69

Changes in reentrant C library function

There are syntactical differences in the DCE libc_r and AIX libc_r routines.

However, the basic functionality of the routines is the same and just needs to be

mapped.

3.1.22 Time

There is no recommended C/C++ strategy for replacing direct dependencies to

the DCE time service. It is assumed that applications do not depend directly on

this service.

Many applications indirectly depend on using a time service to synchronize the

time on each system containing a DCE security authentication server, as this

server is time-sensitive. For applications that currently use the DCE time service

to handle this indirect dependency, the recommended replacement is to use a

platform-specific implementation of the Network Time Protocol (NTP). AIX

includes an

xntpd

daemon, which is an AIX implementation of NTP.

Implementations of NTP are available on other platforms and some of these

implementations are freely available. For information about NTP, refer :

http://www.ntp.org/index.html

3.1.23 UUID

See section 3.1.3, “Authorization, PAC, and UUID” on page 53 for more

information.

3.2 Replacement strategy for Java applications

This section recommends a Java strategy for replacing direct dependencies to

DCE services. The strategy is to use IBM WebSphere Application Server and

IBM Directory Server. IBM WebSphere Application Server is the IBM

implementation of the J2EE technology. (See section 2.3, “Technologies for Java

applications” on page 34 for more information.) The IBM Directory Server is the

IBM implementation of the LDAP technology. (See 2.2.6, “LDAP” on page 28 for

more information.)

To implement this strategy:

 The architect must determine a new J2EE component architecture for the

DCE applications.

 The administrator must revise the application environment for the new

architecture.

70 DCE Replacement Strategies

 The developer must rewrite the DCE applications to run in the new

environment.

3.2.1 Determining a new architecture

The architect must determine a new J2EE component architecture to which each

DCE application will be rewritten. The following presents two examples of J2EE

component architectures. For complete information about J2EE component

architectures, refer to the J2EE and IBM WebSphere Application Server

documentation.

Example 1: Java client applications and enterprise beans

This example maps to a DCE application consisting of application clients,

application servers, and back-end application servers, with all communications

being performed using the DCE RPC protocol.

In this example, the DCE RPC clients are rewritten to be Java client applications,

the DCE RPC servers are rewritten to be enterprise beans, and the back-end

DCE RPC servers are rewritten to be back-end enterprise beans.

Figure 3-1 illustrates this example:

Figure 3-1 Java client and back-end enterprise beans

The Java client application or the client enterprise bean finds the desired method

using the Java Naming and Directory Interface (JNDI) and invokes the desired

method using Java Remote Method Invocation (RMI). If the enterprise bean

containing the desired method is located on a remote node, the client serializes,

marshals, and transmits the method invocation using CORBA IIOP and, if

necessary, secures the IIOP transmission using CORBA CSIv2.

The administrator can configure CSIv2 so that client identity information is

passed to the target enterprise bean using client basic authentication (client

passes its user identity and password), client certificate authentication (client

passes its public certificate using an SSL transport), delegation, or identity

assertion. If CSIv2 is configured to use an SSL transport, SSL passes the public

certificate of the target enterprise bean to the client and protects the privacy and

integrity of all transmitted data.

Java client

applications

Enterprise

beans

Back-end

enterprise beans