Corporate Info | News | Solutions | Products | Partners | Services | Events | Download | How To Buy

2. # 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. Install the Microsoft SDK 3.1 (or later) for Java. 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
Note that if you are zipping files for use, you must include the same resources, without exception. ### 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
2. ## Using the generated classes ### Deployment Once a 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. 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. 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);
      }
    }
2. 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: 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. 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. # Connecting to WebLogic from a COM client ## Setting up your 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: Install the Microsoft SDK 3.1 (or later). Install the weblogic\classes directory on your client and add it to the client's CLASSPATH. 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. 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 Once your classes have been registered, you are ready to continue developing your COM 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
The `javareg` command above does two things: 1) it registers the `weblogic.com.EventProxy` class as an ActiveX Control within the Windows registry assigning it a class identifier (`clsid`), and 2) it creates a type library file. When you run the `javareg` command, a window will appear displaying the alphanumeric `clsid` created for the registration. You should write this identifier down. The `clsid` and type library file are very important, if you plan to distribute your VB application for use on other machines. To run your VB application on another machine, you need to install the weblogic classes on the other machine and export them using command above. You also need to install a copy of the original type library file and register the `weblogic.com.EventProxy` class using the same `clsid` and type library file. An example is included below.
     $ 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
4. # Registering Java Beans for Visual Basic use You can register the Java Beans from a .jar file as COM controls so that they are usable from Visual Basic. This means that you can use Java Beans to build Visual Basic programs, just as if they were a COM component. 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: Install the Microsoft SDK 3.1 (or later). Install the weblogic\classes directory on your client and add it to the client's CLASSPATH. Install the weblogic\lib\weblogicaux.jar on your client and add it to your client's CLASSPATH. 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
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. 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. Compile the Java source code. Install the compiled classes in the CLASSPATH of your WebLogic Server. 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