Programming WebLogic jCOM
WebLogic jCOM is a software bridge that allows bidirectional access between Java/J2EE objects deployed in WebLogic Server, and Microsoft ActiveX components available within Microsoft Office family of products, Visual Basic and C++ objects, and other Component Object Model/Distributed Component Object Model (COM/DCOM) environments.
In general, BEA Systems believes that Web services are the preferred way to communicate with Microsoft applications. We suggest that customers plan to migrate legacy COM applications to .NET in order to leverage this type of communication. jCOM is provided as a migration path for interim solutions that require Java-to-COM integration. It is suitable for small projects or bridge solutions.
Unlike other Java-to-COM bridges available on the market, jCOM is specifically designed to work with WebLogic Server on the Java side. You cannot use jCOM to make COM objects communicate with any arbitrary Java Virtual Machine (JVM). In addition, jCOM makes direct use of WebLogic Server threads, providing a very robust way to expose services to COM objects.
WebLogic jCOM makes the differences between the object types transparent: to a COM client, WebLogic Server objects appear to be COM objects and to a WebLogic Server application, COM components appear to be Java objects.
WebLogic jCOM provides a runtime component that implements both COM/DCOM over Distributed Computing Environment Remote Procedure Call, and Remote Method Invocation (RMI) over Java Remote Method protocol/Internet Inter-ORB Protocol distributed components infrastructures. This makes the objects on the other side look like native objects for each environment.
WebLogic jCOM also provides automated tools to convert between both types of interfaces: it automatically builds COM/DCOM proxies and RMI stubs necessary for each side to be able to communicate via the above mentioned protocols.
WebLogic jCOM does all the necessary translation between DCOM and RMI technologies, and connects to WebLogic Server as an RMI client. It then communicates requests to Enterprise Java Beans (EJBs) deployed in the WebLogic Server as if the request comes from a regular EJB client.
In a similar manner, when a component deployed in WebLogic Server requests services provided by a DCOM object, the request is translated by the jCOM component from a regular RMI client request issued by the WebLogic Server into DCOM compliant request, and communicated to the DCOM environment to the appropriate object.
Use dcomcnfg to configure DCOM in your machine to ensure that a COM object located in a remote machine is accessible over a distributed environment. For more information about DCOM Configuration, see "Configuring DCOM for Remote Access," which is available at the following URL: http://j-integra.intrinsyc.com/support/com/doc/index.htm
In a zero client installation, no WebLogic jCOM software is needed on the Windows client machine. However, in order to achieve this, you must retrieve an "object reference moniker" from a servlet and place it in the COM client code.
This section provides information to help you make these decisions. For additional information about JCOM, see the COM documentation available at the J-Integra website, at the following URL http://j-integra.intrinsyc.com/support/com/doc/index.htm
The WebLogic Server location is coded into the COM client using an object reference moniker (
objref) moniker string. The
objref moniker is generated by the user and it encodes the IP address and port of the WebLogic Server. You can obtain the moniker string for the COM client code programmatically—or by copying and pasting—from a WebLogic Server servlet. Once the server connection is established, the COM client can link a COM object to an interface in the Java component.
Offers the benefits of the late binding model (see Early Versus Late Binding) and therefore provides the same flexibility in terms of changes made to the Java component.
Requires that the WebLogic Server location and port number be coded into the COM client, which means that if the server location is changed, this reference has to be regenerated and changed in the source code.
Deprives your application of the advantages of early binding. (See Early Versus Late Binding)
Early bound access gives you information about the object you are accessing while you are compiling your program; all objects accessed are evaluated at compile time. This requires that the server application provide a type library and that the client application identify the library for loading onto the client system.
In late bound access, no information about the object being accessed is available at compile time; the objects being accessed are dynamically evaluated at runtime. This means that it is not until you run the program that you find out if the methods and properties you are accessing actually exist.
The DCOM (Distributed Component Object Model) mode uses the Component Object Model (COM) to support communication among objects on different computers. In a WebLogic jCOM application running in DCOM mode, the COM client communicates with WebLogic Server in DCOM protocol.
For both COM-to-WLS and WLS-to-COM applications, because native mode uses native code dynamically loaded libraries (DLLs)—which are compiled and optimized specifically for the local operating system and CPU—using native mode results in better performance.
Moreover, COM-to-WLS applications operating in native mode use WebLogic's T3/Internet InterORB (IIOP) protocols for communication between the COM client and WebLogic Server. This brings the advantages of:
For example, suppose your COM application creates a vector containing 100 data elements whose values are returned by a call to WebLogic Server. In DCOM mode, this would require 100 roundtrip network calls to the server. In native mode, this would require one roundtrip call.
However, for both types of applications, because native libraries have only been created for Windows, implementing native late bound access requires that the WebLogic Server be installed all COM client machines. However, this does not mean you need a distinct WebLogic Server license for each machine running a COM application.
For both COM-to-WLS and WLS-to-COM applications, since native libraries have only been created for Windows, implementing native mode requires that the WebLogic Server be installed on all COM machines.