|
|
Managing Remote Client Applications (BEA WebLogic Enterprise Systems)
This chapter explains how to configure connections from remote client applications to CORBA objects via the standard Internet Inter-ORB Protocol (IIOP). This chapter is specific to BEA WebLogic Enterprise servers.
This topic includes the following sections:
Terms and Definitions
Note: In BEA WebLogic Enterprise 4.0, servers could only make invocations on other servers inside the BEA WebLogic Enterprise domain. In BEA WebLogic Enterprise 4.2, the servers can make invocations on any server, inside or outside a BEA WebLogic Enterprise domain.
Note: In BEA WebLogic Enterprise 4.0, a native client could not make invocations on objects outside the BEA WebLogic Enterprise domain.
Note: In BEA WebLogic Enterprise 4.0 and 4.1, a client could not act as a server.
Note: The server role of the native joint client/server is considerably less robust than that of an server. It has none of the BEA WebLogic Enterprise administrative and infrastructure components, such as tmadmin, FactoryFinder, and ISL/ISH (hence none of BEA WebLogic Enterprise's scalability and reliability attributes), it does not use the BEA WebLogic Enterprise TP Framework, and it requires more direct interaction between the client and the ORB.
Note: In BEA WebLogic Enterprise 4.0, a remote client could not act as a server.
Note: A joint client/server is different from a server that acts as a client as part of its server role. Once the server completes processing of an invocation, it returns to dormancy. A joint client/server is always in the active mode, executing code not related to a server role; the server role temporarily interrupts the active client role, but the client role is always resumed.
Note: The server role of the remote joint client/server is considerably less robust than that of a server. Neither the client nor the server has any of the BEA WebLogic Enterprise administrative and infrastructure components, such as tmadmin, FactoryFinder, and ISL/ISH (hence, none of BEA WebLogic Enterprise's scalability and reliability attributes).
Note: In BEA WebLogic Enterprise 4.0 and 4.1, callback objects existed but were not named as such; they could have implementations only in the BEA WebLogic Enterprise domain; that is, they could be located only in a server (as a CORBA object).
Remote Client Overview
In this chapter, the term remote client means BEA WebLogic Enterprise client applications that you deployed on systems that do not have the full BEA WebLogic Enterprise server software installed. This means that no administration or application servers are running there and that no Bulletin Board is present. All communication between the client and the application takes place over the network. The types of clients are:
A client process can be running UNIX or Microsoft Windows. The CORBA and ActiveX clients have access to the CORBA ORB interface. RMI clients have access to Enterprise JavaBeans (EJBs). Jolt and Tuxedo /WS clients have access to Tuxedo services. The networking behind the calls is transparent to the user. The client process registers with the system and has the same status as a native client. The client can do the following:
Note: A client process communicates with the native domain through the ISH.
Illustration of an Application with Remote Clients
Figure 12-1 shows an example of an application with remote clients connected. Any request by a remote client to access the CORBA server application is sent over the network to the ISH. This process sends the request to the appropriate server and sends the reply back to the remote client.
Figure 12-1 Bank Application with Remote Clients
How the Remote Client Connects to an Application
The client connects to the ISL process in the IIOP Listener/Handler using a known network address. This is initiated when the client calls the Bootstrap object constructor. The ISL process uses a function that is specific to the operating system to pass the connection directly to the selected ISH process. To the client application, there is only one connection. The client application does not know, or need to know, that it is now connected to the ISH process.
Setting Environment Variables
For CORBA C++ clients, environment variables can be used to pass information to the system, as follows:
Note: The network address that is specified by programmers in the Bootstrap constructor or in TOBJADDR must exactly match the network address in the server application's UBBCONFIG file. The format of the address as well as the capitalization must match. If the addresses do not match, the call to the Bootstrap constructor will fail with a seemingly unrelated error message:
ERROR: Unofficial connection from client at
<tcp/ip address>/<port-number>:
For example, if the network address is specified as //TRIXIE:3500 in the ISL command line option string (in the server application's UBBCONFIG file), specifying either //192.12.4.6:3500 or //trixie:3500 in the Bootstrap constructor or in TOBJADDR will cause the connection attempt to fail.
On UNIX systems, use the uname -n command on the host system to determine the capitalization used. On Windows NT systems, see the host system's Network control panel to determine the capitalization used. Or use the environment variable COMPUTERNAME. For example:
echo %COMPUTERNAME%
Setting the Maximum Number of Remote Clients
To join remote clients to an application, you must specify the MAXWSCLIENTS parameter in the MACHINES section of the UBBCONFIG file.
MAXWSCLIENTS tells the BEA WebLogic Enterprise system at boot time how many accesser slots to reserve exclusively for remote clients. For native clients, each accesser slot requires one semaphore. However, the ISH process (executing on the native platform on behalf of remote clients) multiplexes remote client accessers through a single accesser slot and, therefore, requires only one semaphore. This points out an additional benefit of the remote extension. By putting more clients out on remote systems and taking them off the native platform, an application reduces its IPC resource requirements.
MAXWSCLIENTS takes its specified number of accesser slots from the total set in MAXACCESSERS. This is important to remember when specifying MAXWSCLIENTS; enough slots must remain to accommodate native clients as well as servers. Do not specify a value for MAXWSCLIENTS greater than MAXACCESSERS. The following table describes the MAXWSCLIENTS parameter.
Parameter |
Description |
---|---|
MAXWSCLIENTS |
Specifies the maximum number of remote clients that may connect to a machine. The default is 0. If a value is not specified, remote clients may not connect to the machine being described. The syntax is MAXWSCLIENTS=number. |
Configuring a Listener for a Remote Client
Remote clients access your application through the services of an ISL process and one or more ISH processes. The ISL is specified in one entry as a server supplied by the BEA WebLogic Enterprise system. The ISL can support multiple remote clients and acts as the single point of contact for all the remote clients connected to your application at the network address specified on the ISL command line. The listener schedules work for one or more remote handler processes. An ISH process acts as a surrogate within the administrative domain of your application for remote clients on remote systems. The ISH uses a multiplexing scheme to support multiple remote clients concurrently.
To join remote clients to an application, you must list the ISL processes in the SERVERS section of the UBBCONFIG file. The processes follow the same syntax for listing any server.
Format of the CLOPT Parameter
You use the following ISL command-line options (CLOPT) to pass information to the ISL process for remote clients. The format of the CLOPT parameter is as follows:
ISL SRVGRP="identifier"
SRVID="number"
CLOPT="[ -A ] [ servopts options ] -- -n netaddr
[ -C {detect|warn|none} ]
[ -d device ]
[ -K {client|handler|both|none} ]
[ -m minh ]
[ -M maxh ]
[ -T client-timeout]
[ -x mpx-factor ]
[ -H external-netaddr"
For a detailed description of the command-line options (CLOPT), see the ISL command in the Command, System Processes, and MIB Reference.
Modifying the UBBCONFIG File to Support Remote Clients
Listing 12-1 shows a sample UBBCONFIG file to support remote clients, as follows:
Listing 12-1 Sample UBBCONFIG File Configuration
*MACHINES
SITE1
...
MAXWSCLIENTS=150
...
SITE2
...
MAXWSCLIENTS=0
...
*SERVERS
...
ISL SRVGRP="BANKB1" SRVID=500 RESTART=Y
CLOPT="-A -- -n //TRIXIE:2500 -d /dev/tcp
-m 5 -M 30 -x 5"
...
Configuring Outbound IIOP for Remote Joint Client/Servers
Support for outbound IIOP provides native clients and servers acting as native clients the ability to invoke on a remote object reference outside of the BEA WebLogic Enterprise domain. This means that calls can be invoked on remote clients that have registered for callbacks, and objects in remote servers can be accessed.
Administrators are the only users who interact directly with the outbound IIOP support components. Administrators are responsible for booting the ISLs with the correct startup parameters to enable outbound IIOP to objects not located in a connected client. Administrators may need to adjust the number of ISLs they boot and the various startup parameters to obtain the best configuration for their installation's specific workload characteristics. They have the option of booting the ISLs with the default parameters.
Note: In this release, outbound IIOP is not supported for transactions or security.
Functional Description
Outbound IIOP support is required to support client callbacks. In version 4.0 and version 4.1 releases of the BEA WebLogic Enterprise software, the ISL/ISH was an inbound half-gateway. Outbound IIOP support adds the outbound half-gateway to the ISL/ISH (see Figure 12-2).
There are three types of outbound IIOP connections available, depending on the version of GIOP supported by the native server and the remote joint client/server application:
Note: GIOP 1.2 is supported only by BEA WebLogic Enterprise 4.2 and later C++ clients, servers, and joint client/servers and WebLogic Enterprise 5.0 and later Java servers. GIOP 1.2 is not supported by BEA WebLogic Enterprise 4.0 or 4.1 clients and joint client/servers. The Java clients and joint client/servers only support GIOP 1.0. The BEA WebLogic Enterprise 4.0 and 4.1 C++ clients and servers only support GIOP 1.0 and 1.1.
Bidirectional and dual-paired connection outbound IIOP provides outbound IIOP to object references located in joint client/servers connected to an ISH. Asymmetric outbound IIOP provides outbound IIOP to object references not located in a joint client/server connected to an ISH, and also allows BEA WebLogic Enterprise clients to invoke on any object reference, not only object references located in clients currently connected to an ISH.
Each type of outbound IIOP is described in more detail in the following sections.
Figure 12-2 Joint Client/Server IIOP Connections Supported
With bidirectional outbound IIOP, the following operations are executed (see Figure 12-3):
Figure 12-3 Bidirectional Connection
Asymmetric Outbound IIOP
With asymmetric outbound IIOP, the following operations are executed (see Figure 12-4):
Figure 12-4 Asymmetric Outbound IIOP
Dual-paired Connection Outbound IIOP
With dual-paired connection outbound IIOP, the following operations are executed (see Figure 12-5):
Figure 12-5 Dual-paired Connections Outbound IIOP
How the Routing Code Finds an ISL
The steps to finding an ISL are as follows:
Note: Normal BEA Tuxedo routing is used to find an ISL.
Note: Some invokes may be made to ISLs on nonlocal machines.
Using the ISL Command to Configure Outbound IIOP Support
Outbound IIOP support is used when a native C++ or Java client, or a server acting as a native client, invokes on an object reference that is a remote object reference. The routing code recognizes that the object reference is from a nonBEA WebLogic Enterprise ORB or from a remote BEA WebLogic Enterprise joint client/server.
Types of Object References
There are two kinds of remote object references:
Both are detected by the routing code and sent to the outbound IIOP support for handling.
User Interface
The user interface to outbound IIOP support is the command-line interface for booting the ISL process(es).
Command-line options to configure the outbound IIOP processing were added to the ISL command in a previous release of the BEA WebLogic Enterprise software. These options enable support for asymmetric IIOP to object references not located in clients connected to an ISH.
Additional command-line options were added in the WebLogic Enterprise 5.1 release for SSL and Secure Connection Pools. Listing 12-2 shows the ISL command syntax and highlights the new options.
Listing 12-2 ISL Command-line Options
ISL SRVGRP="identifier"
SRVID="number"
CLOPT="[ -A ] [ servopts options ] -- -n netaddr
[ -C {detect|warn|none} ]
[ -d device ]
[ -K {client|handler|both|none} ]
[ -m minh ]
[ -M maxh ]
[ -T Client-timeout]
[ -x mpx-factor ]
[-H external-netaddr]
#Options for outbound IIOP
[-O]
[-o outbound-max-connections]
[-s Server-timeout]
[-u out-mpx-users] "
#NEW options for SSL
[a]
[-R renegotiation-interval]
[-S secure-port]
[-v {detect | warn | none}]
[-z [0|40|56|128]]
[-Z [0|40|56|128]]
#NEW options for Secure connection Pools
[-E principal_nane]"
For a detailed description of the CLOPT command-line options, see the ISL command in the Command, System Processes, and MIB Reference.
|
Copyright © 2000 BEA Systems, Inc. All rights reserved.
|