At run time, the access client does not need to reside on a machine that contains IBM WebSphere Business Integration Server Express, nor does it need to reside on the same machine as the development environment. However, for the access client to be able to locate the InterChange Server Express instance it needs at run time, it must be able to locate the Object Request Broker (ORB) server, which keeps track of the locations of different CORBA objects (including InterChange Server Express instances) and communicates this information to ORB clients (such as an access client). To obtain the location of the ORB server, the access client can use the Interoperable Object Reference File that its InterChange Server Express instance generates. When InterChange Server Express starts or reboots, it generates an Interoperable Object Reference file, which has the .ior extension. The access client can use this file to locate the ORB server, and, in turn, to communicate with its InterChange Server Express instance.
Therefore, for the access client to locate its InterChange Server Express instance, you must take the following steps:
Each of these steps is described in more detail in the following sections.
When InterChange Server Express version 3.1.0 or later is booted up, it generates a new .ior file. However, InterChange Server Express dynamically assigns a port number for the ORB server. If the port number changes each time the server boots, the access client cannot depend on the .ior file to locate the ORB Server. Therefore, an access client needs InterChange Server Express to generate a persistent .ior file.
To have InterChange Server Express generate a persistent .ior file, you must edit the InterChange Server Express configuration file (InterchangeSystem.cfg) in an XML editor and add a subsection for CORBA, if one does not already exist. Figure 4 shows the XML code that defines an empty CORBA subsection (one with no configuration parameter defined).
<tns:property> <tns:name>CORBA</tns:name> <tns:isEncrypted>false</tns:isEncrypted> <tns:updateMethod>system restart</tns:updateMethod> <tns:location> <tns:reposController>false</tns:reposController> <tns:reposAgent>false</tns:reposAgent> <tns:localConfig>true</tns:localConfig> </tns:location>
XML definitions of CORBA properties go here
</tns:property>
The CORBA subsection specifies the static port number with the OAport configuration parameter, which has the following syntax:
OAport=portNumber
For example, if the static port number is to be 15000, assign a value of 15000 to its OAport parameter in the CORBA subsection. The following XML fragment would appear within the <tns:property> tag for the CORBA subsection, in the place indicated in Figure 4 with the string "XML definitions of CORBA properties go here":
<tns:property> <tns:name>OAport</tns:name> <tns:value xml:space="preserve">15000</tns:value> <tns:isEncrypted>false</tns:isEncrypted> <tns:updateMethod>system restart</tns:updateMethod> <tns:location> <tns:reposController>false</tns:reposController> <tns:reposAgent>false</tns:reposAgent> <tns:localConfig>true</tns:localConfig> </tns:location> </tns:property>
For more information on the CORBA subsection in the configuration file, see the WebSphere Business Integration Server Express Installation Guide for Linux or for Windows.
For the access client to locate the ORB server at run time, it must be able to locate the .ior file for its InterChange Server Express instance. Locating this file is not a problem if the access client and InterChange Server Express are on the same machine. However, if these two components are not on the same machine, you must take one of the following actions to ensure that the access-client machine can access the .ior file: