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
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
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 :
3.1.23 UUID
See section 3.1.3, “Authorization, PAC, and UUID” on page 53 for more
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
70 DCE Replacement Strategies
The developer must rewrite the DCE applications to run in the new
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
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
enterprise beans

Get DCE Replacement Strategies now with the O’Reilly learning platform.

O’Reilly members experience live online training, plus books, videos, and digital content from nearly 200 publishers.