|
|
|
|
|
|
| | | |
Deploying your Application
The following sections provide information about the steps that need to be taken before you can run your application:
Deployment Options
When using WebLogic jCOM to access Java objects from a COM client, there are five different deployment scenarios, depending on the implementation used:
In addition, your deployment may be influenced by the use of several WebLogic Servers in
If you chose the appropriate installation for the implementation you are using, all the WebLogic jCOM files required for configuration, deployment and at runtime will already be in the correct location. You may still have to copy additional user-generated files to the correct location.
For more information on deployment when using WebLogic jCOM for accessing COM objects from a Java client, see the WebLogic jCOM Reference Guide.
Deploying your Application
Deploying a DCOM Zero Client Implementation
A DCOM zero client implementation requires zero deployment on the client system. Take note, though, that the WebLogic jCOM bridge is accessed from the client via a hardcoded reference to the server's location (IP and port). This reference is in the client source code. Should the server location change, this objref will have to be regenerated and inserted into the client source in order for the COM client to be able to communicate with the server.
The server installation process (typically a server install) will have installed the WebLogic jCOM components required on the server at runtime:
Once the EJB has been deployed to WebLogic Server and the server has been activated, the compiled bridge can be activated. Any changes made to the server's TCP/IP address and listen port must be reflected in the bridge file itself.
For more on how to generate the objref and activate the bridge, see the Zero Client Installation example in the Programming chapter.
Deploying a DCOM Late Bound Implementation
For a DCOM late bound implementation, the client installation process (typically a client install) will have installed the WebLogic jCOM components required on the client system at runtime:
as well as those required for configuring the client:
Before running the application, the JVM must be registered using regjvm or regjvmcmd. For more on the tools, regjvm and regjvmcmd, see jCOM Tools.
Note: Should the server location change, you will have to re-register the JVM. Before doing this you have to un-register the old entry because the regjvmcmd tool does not overwrite old entries when new entries with identical names are entered. You can un-register the old entry using the command line tool regjvmcmd, or by using the GUI tool regjvm (both can be found in the jCOM\bin directory).
The server installation process (typically a server install) will have installed the WebLogic jCOM bridge files required on the server at runtime:
Once the EJB has been deployed to WebLogic Server and the server has been activated, the compiled bridge can be activated. Any changes made to the server's TCP/IP address and listen port must be reflected in the bridge file itself.
For more on how to register the JVM and activate the bridge see the Late Bound Implementation example in the Programming chapter.
Deploying a DCOM Early Bound Implementation
For a DCOM early bound implementation, the client installation process (typically a client install) will install the WebLogic jCOM tools required on the client system at runtime:
as well as those required for configuring the client:
You must ensure that the type library generated by the java2com tool is on the client system at runtime and that the CLASSPATH environment variable points to the directory in which it is placed. The type library is needed for early binding of the remote object acquired from the WebLogic jCOM bridge. Use the regtlb tool to register the type library on the client. For more about the tools, java2com and regtlb, see jCOM Tools.
Before running the application, the JVM must be registered using regjvm or regjvmcmd. For more on the tools regjvm and regjvmcmd, see jCOM Tools.
Note: Should the server location change, you will have to re-register the JVM. Before doing this you have to un-register the old entry because the regjvmcmd tool does not overwrite old entries when new entries with identical names are entered. You can un-register the old entry using the command line tool regjvmcmd, or by using the GUI tool regjvm (both can be found in the jCOM\bin directory).
The server installation process (typically a server install) will install the WebLogic jCOM bridge files required on the server at runtime:
You must ensure that the wrapper classes generated by the java2com tool are on the server system at runtime and that the CLASSPATH environment variable points to the directory in which they are placed. The wrapper classes enable early bound communications with the Java objects they were created to encapsulate.
Once the EJB has been deployed to WebLogic Server and the server has been activated, the compiled bridge can be activated. Any changes made to the server's TCP/IP address and listen port must be reflected in the bridge file itself.
For more on how to register the type library and the JVM and activate the bridge see the Early Bound Implementation example in the Programming chapter of the WebLogic jCOM User Guide.
Deploying a DCOM Late Bound Encapsulation Implementation
Since late bound encapsulation uses early binding during development and late binding during runtime, deploying a late bound encapsulation implementation is much the same as deploying a late bound implementation. To ensure that late binding is indeed implemented at runtime, you need to be sure that the type library referenced during development is no longer accessible to the client. This will also render the wrappers on the server side inaccessible.
For a late bound encapsulation implementation, the client installation process (typically a client install) will install the WebLogic jCOM tools required on the client system at runtime:
as well as those required for configuring the client:
You must ensure that the type library referenced during development is not visible to the client at runtime, otherwise the implementation will remain early bound.
Before running the application, the JVM must be registered using regjvm or regjvmcmd. For more on the tools, regjvm and regjvmcmd, see jCOM Tools.
Note: Should the server location change, you will have to re-register the JVM. Before doing this you have to un-register the old entry because the regjvmcmd tool does not overwrite old entries when new entries with identical names are entered. You can un-register the old entry using the command line tool regjvmcmd, or by using the GUI tool regjvm (both can be found in the jCOM\bin directory).
The server installation process (typically a server install) will install the WebLogic jCOM bridge files required on the server at runtime:
Once the EJB has been deployed to WebLogic Server and the server has been activated, the compiled bridge can be activated. Any changes made to the server's TCP/IP address and listen port must be reflected in the bridge file itself.
Deploying a Native Mode Implementation
In native mode a COM client accesses a Java object running on the same machine as the client. WebLogic jCOM uses native code to facilitate the interaction. For more on native mode see Native Mode in the Reference Guide.
Server Clustering
If you are using more than one WLS machine in a server cluster, your deployment mechanism will likely be affected. In order to maintain fail-over capabilities, it is recommended that you deploy all WebLogic jCOM files on the client system (similar to native mode deployment above). Placing the WebLogic jCOM bridge on a single WLS machine within your cluster will render your system susceptible to failure; if the bridge machine fails you lose all WebLogic jCOM functionality. Placing the WebLogic jCOM bridge on the client system removes this possibility, allowing your cluster to employ its fail-over capabilities as normal.
|
|
|
|
|
|
Copyright © 2001 BEA Systems, Inc. All rights reserved.
|