Using WebLogic COM

Introduction

Converting COM objects to RMI-usable objects

Using the WebLogic COM compiler

Setting up your environment

Running the compiler

Syntax

Examples

Using the generated classes

Deployment

Development

Connecting to WebLogic from a COM client

Setting up your client

Writing the code for the client application

Registering interest in WebLogic Events

Registering Java Beans for Visual Basic use

Converting COM objects for server-side use

Related documents

Using WebLogic Events

Using WebLogic RMI

COM Code examples

Introduction

WebLogic, an open, standards-based enterprise application server, provides several means of access for clients in a heterogeneous networked application environment -- including Java clients, VB clients, COM integration on the client and server side, and CORBA invoking directly on EJBs.

Using the Microsoft SDK for Java, it is possible to export Java business objects as COM objects. Enterprise JavaBeans and other Java objects can be automatically wrapped as COM components for easy importation into Visual Basic, Visual C++, Active Server Pages, and any other environment that supports COM. To the Microsoft developer, access to a remote Java component is programmed like any other COM invocation. In this way, the integration barriers between server-side Java and the broad array of client environments can be eliminated.

The reverse mapping works as well. With WebLogic COM, users can wrap their COM business components with Java objects that can be remotely accessed as WebLogic RMI objects within the WebLogic framework. To the Java developer, COM business components are then called like any other remote Java object--except that they must be instantiated within a COM runtime environment, e.g. the Windows operating system.

When using Microsoft SDK for Java, it must to be used to run both the client application and WebLogic Server. The combination of Microsoft SDK for Java running on one side with a Sun Java Virtual Machine (JVM) running on the other side is not supported.

This document details how to set up your environment and use the WebLogic COM compiler to generate RMI-usable objects from your COM objects. Additional instructions describe how these generated objects are then deployed and invoked. This document also contains some general instructions for building non-Java clients capable of invoking RMI-usable objects.

Converting COM objects to RMI-usable objects

To convert COM objects into RMI-usable objects, you need to compile the COM object (typically a .tlb, .olb, .ocx, .dll, or .exe) using the WebLogic COM compiler. The compiler will generate Java wrappers for the COM objects and RMI wrappers for the Java classes. To use the generated class, the implementation class must be deployed as a startup class of your WebLogic Server. Once the COM object is compiled and deployed, it becomes accessible from the network to any client via any of WebLogic's supported protocols.

Using the WebLogic COM compiler

Setting up your environment

Check these setup requirements before you run the WebLogic COM compiler.

1. Install the Microsoft SDK 3.1 (or later) for Java.

2. Add the SDK's bin/ directory to your PATH. Make sure you place the SDK first in your path to prevent inadvertently accessing older versions of Microsoft SDK for Java that you may have installed. For example:

   c:\>set PATH=c:\SDK-Java.310\bin;%PATH%

3. Make sure that you have the weblogicaux.jar file, as well as the weblogic\classes directory in your CLASSPATH. You can check your CLASSPATH as shown here:

   c:\>echo %CLASSPATH%
   c:\weblogic\classes;c:\weblogic\lib\weblogicaux.jar;
   c:\weblogic\license

Running the compiler

Running the compiler will generate Java wrappers for the COM objects and RMI wrappers for the Java classes. The package names of the generated classes will be mapped as follows:

Generated class	Package naming
Java wrappers for the COM object	weblogic.com.COMObj.*
RMI stubs, skeletons, bridges for Java wrappers	weblogic.com.remote.COMObj.*_Stub weblogic.com.remote.COMObj.*_Skel weblogic.com.remote.COMObj.*

In addition, each set of generated remote objects will have a Utilities class that assigns return types for the remote objects. In some cases, you may want to edit the Utilities class.

Select a server-side COM object (typically a .tlb, .olb, .ocx, .dll, or .exe). Determine whether the COM object is multithreaded; you should compile COM objects with the -nothreads flag if the object is not multithreaded. Syntax for the compiler is detailed below.

Syntax

c:\>jview weblogic.comc -d dest options object

-d dest

Direct the destination of the compiler output with the -d option. You should direct your compiler output into weblogic/classes.

options

-help

Displays a list of compiler options.

-verbose

Add this option to display debugging information while running.

-classpath path

Supply a CLASSPATH for the compiler that differs from the CLASSPATH in the command shell or the environment. Example usage might be -classpath %CLASSPATH%;c:\myclasses\classes.zip. For more help, read Setting classpath. If your CLASSPATH is set in your environment or in the shell from which you are executing the compiler command, you do not need this option.

-nothreads

Set this flag if the COM object you are compiling is not multithreaded.

-register

Set this flag to register the COM object with Windows. You will customarily set this flag; it doesn't matter if you reregister objects.

-nojactivex

Set this flag to run the compiler without running jactivex. You may choose to run jactivex separately. (The jactivex tool converts COM classes to .java source that you can compile.)

-nobridge

Set this flag to compile without building the RMI-COM bridge. You may choose not to build the bridge if you have already done so previously. (RMI-COM bridges are generated into the package weblogic.com.remote.COMObj.*.)

-nobuild

Set this flag to disable compilation. You may want to run the compiler during debugging without actually outputting any compiled files.

-nostubs

Set this flag to disable generation of stubs and skeletons. (Stubs/skeletons are generated into the package weblogic.com.remote.COMObj.*_Stub and weblogic.com.remote.COMObj.*_Skel.)

object

Full path of the COM object to be compiled.

Examples

c:\>jview weblogic.comc -d \weblogic\classes -nothreads
      -register \winnt\ODA.dll

Using the generated classes

Deployment

You can use any VM that supports the use of WebLogic RMI to access your COM object from a client. Once the COM object is compiled and deployed, it becomes accessible from the network to any client via any of WebLogic's supported protocols, including SSL and HTTP tunneling.

1. Place the .dll that contains the COM object in a directory that is in the PATH of the WebLogic Server process. For example, if you have set a PATH in the Environment tab of the System Properties dialog, in general, files in that PATH will be accessible to WebLogic, whether you start WebLogic from a Shortcut in the Start menu, or from a DOS command window.

2. You will need to add an entry for each implementation class to the weblogic.properties file so that the remote class is instantiated and registered in the WebLogic RMI registry when WebLogic starts up.

   Here is an example. This properties entry registers the implementation class weblogic.com.remote.oda.IConnectionImpl to become available at startup. You use an accompanying property "startupArgs" to bind the object in the registry to the name oda. Note that the property entry name odatest is used only by the properties file to associate the startup class with its startup args. If you do not set a name, the classname will be used instead.

   weblogic.system.startupClass.odatest=\
     weblogic.com.remote.oda.IConnectionImpl
   weblogic.system.startupArgs.odatest=\
     oda

   If you are using out-of-process COM objects, then you should also register a shutdown class that will close all references to these objects to that they may exit.

   weblogic.system.shutdownClass.
   comfinalizer=\
     weblogic.com.COMFinalizer

3. Start the WebLogic Server using Microsoft's JDK for Java.

   c:\> jview weblogic.Server

Development

To invoke on the resulting classes, just import the generated weblogic.com.remote.* package and use the same interfaces you would use for the COM object. Here is an example that invokes on the IConnection object from ODA.dll, which we ran through the compiler to create the generated packages weblogic.com.oda.* and weblogic.com.remote.oda.*.

(ODA.dll allows you to directly access an Oracle7 database via the Oracle Call Interface (OCI). It is available from http://www.download.com; search on "ODA".)

import weblogic.com.Variant;
import weblogic.com.remote.oda.*;
import weblogic.rmi.*;

public class ODATest {

  public static void main(String[] args) throws Exception  {
    String url = args.length == 0 ? "t3://localhost:7001" : args[0];
    String name = "oda";

    IConnection conn = (IConnection) Naming.lookup(url + "/" + name);

    conn.Open("alpha", "scott", "tiger");
    IRecordSet rs = conn.getRecordset();
    rs.Execute("SELECT * FROM EMP");

    rs.Fetch();
    int numcols = rs.getCount();
    for(int col = 0; col < numcols; col++) {
      IField f = rs.getItem(new Variant(col));
      System.out.println(f.getName() + ": " + f.getValue());
    }
    conn.Close();

    System.exit(0);
  }
}

You can also use a DLL that references COM objects with WebLogic COM. Note that if your DLL references COM objects that are not present in the DLL, WebLogic COM will not know what type to cast return values to. The Utilities class (located with the generated objects) tries to determine what type of object your are returning and cast it to the appropriate type.

There are two potential solutions to this problem:

1. Add the methods and implementation to the DLL in which COM objects are defined. For example, in the cases shown above, you might add the _MyDataActiveX methods and implementation to the DLL in which BusObj, etc. COM objects are defined.

2. Edit the Utilities class to return the proper type. For example:

     if(o instance of weblogic.com.dserver._MyDataActiveX)
      return new
        weblogic.com.remote.dserver._MyDataActiveXImpl(
            (weblogic.com.dserver._MyDataActiveX) o);

   or, as in this example of an object with a BusObj interface:

     if(o instanceof weblogic.com.dllname.BusObj)
      return new
        weblogic.com.remote.dllname.BusObjImpl(
            (weblogic.com.dllname.BusObj) o);

   You can also cut-and-paste from the Utilities class generated from the other DLLs. In a future release, you will be able to place all the related DLLs on a single command line so that WebLogic COM can handle dependencies.

Connecting to WebLogic from a COM client

You can write a client application in Visual Basic (or any other environment that supports COM) that uses Java objects installed in the WebLogic Server, for example Enterprise JavaBeans (EJBeans) and RMI (Remote Method Invocation) objects. Being able to access Java server-side objects from your Visual Basic clients makes it easy to integrate very complex and sophisticated business logic with client-building GUI tools that many Windows developers are already familiar with.

To use this feature of WebLogic COM, you must have several sets of Java classes available on your client:

1. Install the Microsoft SDK 3.1 (or later).
2. Install the weblogic\classes directory on your client and add it to the client's CLASSPATH.
3. Install the weblogic\lib\weblogicaux.jar on your client and add it to your client's CLASSPATH.

Next, compile the classes you want to use with your client. For example, if you plan to invoke the EJB examples shipped with the WebLogic release, you will need to compile the EJB examples. There are Windows bat/cmd files shipped in the examples/ejb directory that help you compile these files. If you are compiling your own classes outside a directory that you have already added to your CLASSPATH, you will need to add those classes to your trusted classpath in the next step.

You will need to register the WebLogic classes as trusted classes. Here is an example that works if you have installed the WebLogic classes on your C drive:

 $ jview weblogic.com.Export
  c:\weblogic\classes;c:\weblogic\lib\weblogicaux.jar

If you are compiling other classes that your client will use in another directory, you must add that directory to the export process as well (in beta 4, all the classes must be exported at the same time). Here is an example. Note that this is a single command that should be typed on one command line. We have divided the lines here to make it readable.

 $ jview weblogic.com.Export
  c:\weblogic\classes;c:\weblogic\lib\weblogicaux.jar;c:\myclasses

Finally, you will need to run WebLogic Server using the Microsoft SDK for Java. COM clients are not support when running WebLogic Server under a Sun JVM.

Writing the code for the client application

Here is a Visual Basic code example of how to connect to a WebLogic Server and create a handle to an EJB object "TraderHome" through a JNDI initial context. (If you use this example, be sure to compile and export the necessary classes, as described above.) The VB objects that we instantiate and use in this example provide access to the following:

• The WebLogic object provides a handle to the WebLogic client-side code.
• With the WebLogic object, you can connect to a WebLogic Server that acts as a JNDI naming provider.
• The call to getInitialContext() returns an InitialContext with which you can "look up" (get access to, or more literally, get an object reference to) any service object in the JNDI naming tree hosted by WebLogic. A service object might be an Enterprise JavaBean or an RMI object.
• You can invoke any of the methods of the object.

In this example, we call the Create() method on the EJBean home, which returns an EJBean instance, trader.

  Dim server As Object
  Dim brok As Object
  Dim ic As Object
  Dim trader As Object

  Set server = GetObject("java:weblogic.com.Server")
  Set ic = server.getInitialContext("t3://beale:7001")
  Set brok = ic.lookup("statelessSession.TraderHome")
  Set trader = brok.Create()

From here, you operate on the trader bean just as you would any other EJBean. (For more on WebLogic EJB, read BEA WebLogic Server Enterprise JavaBeans.)

When you have finished your WebLogic operations, it is good programming practice to call close() on the context (in this example ic) to clean up server-side resources.

Finally, compile your VB client. Start the WebLogic Server on the server host, and test your client application.

Registering interest in WebLogic Events

You can have your clients (for example, VB or PowerBuilder clients) register an interest in WebLogic Events. For more information on what you can do with events, read the Developers Guide, Using WebLogic Events.

To use WebLogic's Events service from your COM clients, you must register the COM EventProxy as a COM object. Here is an example; it includes the steps necessary to export the WebLogic classes for use with VB, which you must do before the EventProxy class is available for registering.

 $ jview weblogic.com.Export
   c:\weblogic\classes;c:\weblogic\lib\weblogicaux.jar
 $ javareg /control /codebase:c:\weblogic\classes
   /class:weblogic.com.EventProxy
   /register /typelib:c:\weblogic\lib\EventProxy.tlb

 $ javareg /control /codebase:c:\weblogic\classes
   /class:weblogic.com.EventProxy /register 
   /typelib:c:\weblogic\lib\EventProxy.tlb /clsid:{45B24280-1EB0-
   11D3-B6DB-0000861F705F} /nomktyplib

There are two important options in the command above. First, the clsid option specifies the class identifier to be registered with the class. Secondly, the nomktyplib option tells the utility that it should not create a new type library. Instead, it registers the existing type library specified in the argument of the /typelib option. See the Microsoft SDK for Java documentation for more information on the javareg utility.

Once you have registered the COM EventPoxy as an ActiveX Control, you need to add an EventProxy component to the VB form. Select the Components command from the Project menu in Visual Basic. Select the weblogic.com.EventProxy checkbox and hit OK. An EventPoxy component will now appear on the component pallet. Drag an EventProxy component onto the VB from. Here is some sample code from a VB client:

Private i As Integer
Private ic As Object

Private Sub EventProxy1_tengahEventOccurred(ByVal Parameter0 As Object)
  i = i + 1
  Label1.Caption = "WEBLOGIC.TIME Events: " & i
  Label2.Caption = Parameter0.topic
  Set paramSet = Parameter0.paramSet
  Label3.Caption = paramSet.toString
End Sub

Private Sub Form_Load()
  Set server = GetObject("java:weblogic.com.Server")
  Set ic = server.getInitialContext("t3://localhost:7001")
  Set t3Services = ic.lookup("weblogic.services")
  Set events = t3Services.events
  Set eventTopic = events.getEventTopic("WEBLOGIC.TIME")
  Set er = eventTopic.register(EventProxy1.getEvaluate(
         "weblogic.event.evaluators.EvaluateTrue"),
	 EventProxy1.getAction)
End Sub

Registering Java Beans for Visual Basic use

You will need to have the SDK installed, and then you will export the WebLogic classes to your SDK classpath and run the Register program against the .jar file that contains the Beans. Here are detailed instructions:

1. Install the Microsoft SDK 3.1 (or later).
2. Install the weblogic\classes directory on your client and add it to the client's CLASSPATH.
3. Install the weblogic\lib\weblogicaux.jar on your client and add it to your client's CLASSPATH.
4. Register the WebLogic classes as trusted classes. Here is an example that works if you have installed the WebLogic classes on your C drive:

    $ jview weblogic.com.Export
     c:\weblogic\classes;c:\weblogic\lib\weblogicaux.jar

5. Run the weblogic.com.Register program against a .jar file that contains GUI beans you want to use in VB. Here is an example:

    $ jview weblogic.com.Register MyBeans.jar

6. Start Visual Basic.

Converting COM objects for server-side use

If you want to use COM objects from Java servlets -- that is, server-side use of a COM object, rather than client-side use -- you can do so with the Microsoft SDK 3.1 (or later) and the Microsoft JVM. This feature allows you to integrate legacy COM-based application business logic into the full power of the WebLogic framework -- a quick way to make limited-scale applications Internet- or intranet-ready.

1. Use the jactivex.exe tool to convert your COM classes to Java source code. There is more information on the jactivex.exe tool at Microsoft's website.

2. Compile the Java source code.

3. Install the compiled classes in the CLASSPATH of your WebLogic Server.

4. Write a client-side browser servlet that uses the compiled classes.

   Note: You cannot use the servlet classpath for servlets that access COM objects. The Microsoft JVM has special security restrictions that only allow you to load your servlet classes from the system CLASSPATH, since they use COM classes.

   This also restricts direct use of JHTML or JSP based servlets with COM, since they are not loaded from the system CLASSPATH. However, you can use their stand-alone compilers respectively to generate a static servlet class, which you can register as a regular HTTP servlet. For more details, see the Developers Guides for JHTML and JSP.

Copyright © 2000 BEA Systems, Inc. All rights reserved.
Required browser: Netscape 4.0 or higher, or Microsoft Internet Explorer 4.0 or higher.
Last updated 12/23/1999