System Configuration

 

Home Purchase Preface Contents Examples Resources Errata Site Guide

 COM and CORBA® Side by Side

Configuration Issues

bulletBuild-Related Batch Files
bulletEnvironment Variable Settings
bulletDCOM Issues
bulletConfiguring DCOM Using dcomcnfg.exe
bulletDCOM Server Issues
bulletDCOM Client Issues
bulletCORBA Issues
bulletOrbix Server Issues
bulletJava IDL Issues
bulletJava Plug-in Issues

 


Build-Related Batch Files

To facilitate the building, cleaning, and running of the example applications, the following batch files are included in the various directories:
 

bullet_clean.bat - This batch file is used to clean up all generated files related to a build.
bullet_make.bat - This batch file is used to build a sample application.
bullet_run.bat - This batch file is used to run a sample application.

 


Environment Variable Settings

Here is what my environment looked like when I built the examples.

C:\>set
COMPUTERNAME=SCARPIA
ComSpec=C:\WINNT4\system32\cmd.exe
HOMEDRIVE=C:
HOMEPATH=\
INCLUDE=c:\vstudio6\vc98\include;c:\vstudio6\vc98\atl\include;
        c:\vstudio6\vc98\mfc\include;C:\Mts\Include
IT_CONFIG_PATH=C:\IONA\Orbix\CFG
LIB=c:\vstudio6\vc98\lib;c:\vstudio6\vc98\mfc\lib;C:\Mts\Lib
LOGONSERVER=\\TOSCA
NUMBER_OF_PROCESSORS=1
OS=Windows_NT
Os2LibPath=C:\WINNT4\system32\os2\dll;
Path=C:\WINNT4\system32;C:\WINNT4;c:\bin;c:\vstudio6\Common\MSDev98\Bin;
     c:\vstudio6\vc98\bin;c:\vstudio6\vb98;C:\Mts;c:\jdk121\bin;
     c:\iona\orbix\bin
PATHEXT=.COM;.EXE;.BAT;.CMD;.VBS;.JS
PROCESSOR_ARCHITECTURE=x86
PROCESSOR_IDENTIFIER=x86 Family 6 Model 6 Stepping 0, GenuineIntel
PROCESSOR_LEVEL=6
PROCESSOR_REVISION=0600
PROMPT=$P$G
SystemDrive=C:
SystemRoot=C:\WINNT4
TEMP=C:\TEMP
TMP=C:\TEMP
USERDOMAIN=HOME
USERNAME=jason
USERPROFILE=C:\WINNT4\Profiles\jason
windir=C:\WINNT4

 


DCOM Issues

A number of issues must be dealt with when trying to use DCOM. To understand DCOM and CORBA, you need to have a network of at least 2 computers.

Configuring DCOM using dcomcnfg.exe

bulletThe first step is to properly configure DCOM. Microsoft provides the dcomcnfg.exe utility to configure DCOM.
 
bulletTo configure DCOM, run dcomcnfg.exe on both your client and server machines.
 
bulletOn the "Default Properties" tab of dcomcnfg:
bulletSet "Enable Distributed COM on this computer" to checked
bulletSet "Default Authentication Level" to "Packet"
bulletSet "Default Impersonation Level"  to "Impersonate"
 
bulletOn the  "Default Security" tab
bulletDefault Access Permissions
   Everyone       Allow Access
bulletDefault Launch Permissions
   Everyone       Allow Launch
 
Although the above security settings may be a little too relaxed for some situations, the above settings should help you to avoid problems that can occur with stricter settings. After you have gotten your DCOM clients and servers to communicate, you can experiment with stricter settings.


DCOM Server Issues

There are very few server issues other than the requirement that the COM server be registered on the server machine. For the local server in Chapter 3, you will want to register the COM server by running "Ch3ComCppServer.exe /RegServer". In addition, the proxy-stub DLL must be registered if a custom interface is used. For type library marshaling, the type library is normally contained in the COM server as a resource.

For the COM servers in the other chapters, I hosted the COM servers under MTS.


DCOM Client Issues

DCOM clients rely on marshaling to communicate with the server. The following table describes the various approaches.
 
Client Approach Typical Clients Marshaling Approach
Custom interface Visual C++ A proxy–stub DLL must be registered on the
client machine (see COM Proxies and Stubs
on page 52).
Custom interface
marked as
[oleautomation]
Visual Basic
Visual J++
Visual C++
Interfaces marked as [oleautomation] can take
advantage of type library marshaling (see COM
Type Library Marshaling on page 53). A type
library that defines the interface must be registered
on the client machine. A proxy–stub DLL
can be used instead if desired.
Dual interface Visual Basic
Visual J++
Visual C++
VBScript (Active
   Server Pages)
Interfaces marked as [dual] can take advantage
of type library marshaling (see COM Type Library
Marshaling on page 53). A type library that
defines the interface must be registered on the
client machine. A proxy–stub DLL can be used
instead if desired.

Nothing is required if clients will be using only
IDispatch since the marshaler for IDispatch is
already installed.

Automation interface
dispinterface
(IDispatch)
Visual Basic
VBScript
Visual Basic
    for Applications
Nothing is required since the marshaler for
IDispatch is already installed.

The above table (Table 8-3, page 237) was excerpted from COM and CORBA® Side by Side: Architectures, Strategies, and Implementations by Jason Pritchard. Copyright © 1999. Reprinted by permission. All rights reserved.

In addition, you will need to install Mike Nelson's DCOM Bridge utility to use DCOM from Visual J++ COM clients and Visual Basic 4.0/5.0 COM clients. Note that Visual Basic 6.0 allows a server name to be specified when calling CreateObject().

If you need to install a type library on a client machine, which will probably be the most common scenario, the simplest approach is to use Mike Nelson's Regtlb utility.

Finally, you will need to place the prog ID in the registry if you place a VB or VJ++ client application on a remote client machine. I have included files named "progid.reg" in the source code zip file for this purpose.

 


CORBA Issues

CORBA issues will vary greatly from one vendor to the next.

Orbix Server Issues

The Orbix daemon can be used to enforce security and to provide automatic activation of Orbix servers. These features complicate the use of IIOP from non-Orbix CORBA ORBS such as Java IDL and VisiBroker for Java. For this reason, the Orbix servers used in the examples were written to not rely on the Orbix daemon.

Here is an excerpt of the main() function from one of the Orbix server implementations.

int main()
{
    // *********************************************************
    // Uncomment the following if we want to rely on
    // the Orbix daemon. Since we're relying on pure
    // IIOP and IOR strings, we don't need this.
    //
    // CORBA::Orbix.setServerName(SRV_NAME);
    // *********************************************************

    // Create the factory implementation object.
    Ch3::CheckingAccountFactory_var factory =
        new CheckingAccountFactoryImpl;

    // Get the IOR for the factory.
    char* factoryIOR;

    try
    {
        // This call is not CORBA compliant.
        factoryIOR = factory->_object_to_string
                              (CORBA::IT_INTEROPERABLE_OR_KIND);
    }
    catch(CORBA::SystemException& sysEx)
    {
        cerr <<"Unexpected system exception " << endl;
        cerr << &sysEx ;
    }

    // Write the IOR to a file.
    ofstream strm("ior.txt");

    if ( !strm )
    {
        cout << "server: Unable to create IOR file - " << endl;
        return 1;
    }

    cout << "Writing IOR ("
         << factoryIOR
         << ") to ior.txt ..."
         << endl << endl << flush;

    strm << factoryIOR;
    strm.flush();
    strm.close();

    CORBA::string_free(factoryIOR);

    try
    {
        // *****************************************************
        // Uncomment the following if we want to rely on
        // the Orbix daemon. Since we're relying on pure
        // IIOP and IOR strings, we don't need this.
        //
        // CORBA::Orbix.impl_is_ready
        //      ((char*)SRV_NAME, CORBA::Orbix.INFINITE_TIMEOUT);
        // *****************************************************

        // Comment out the following if using impl_is_ready().
        CORBA::Orbix.processEvents(CORBA::Orbix.INFINITE_TIMEOUT);
    }
    catch (CORBA::SystemException &sysEx )
    {
        cerr << "Unexpected system exception"
             << &sysEx
             << endl;
        return 1;
    }

    // impl_is_ready() returns only when Orbix times-out
    // an idle server (or an error occurs).
    cout << "server exiting" << endl;

    return 0;
}
The main downside of the above approach is that the Orbix server must be started manually. This is true for all of the Orbix server applications used in the examples.


Java IDL Issues

The Java IDL CORBA ORB is included as part of Sun's Java(TM) 2 SDK, Standard Edition, v1.2.1.

To create Java IDL servers and clients, you also need to obtain the IDL to Java compiler from Sun.

For my development purposes, I have a version of Java IDL (javaidl.jar) that works with Microsoft's JVM. To be honest, I'm not sure where I got it and I'd probably be violating redistribution laws if I placed it on this site. If you have a JDK 1.1 version of the Java IDL classes, you can probably do the same thing (the JDK 1.2 classes won't work). For commercial purposes, you'll certainly want to go with a commercial ORB that works with both JDK 1.2 and Microsoft's JVM. Once you have a .jar file with the appropriate classes, you'll want to create a registry entry like this.

REGEDIT4

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Java VM]
"Classpath"="C:\\WINNT4\\java\\classes;.;c:\\WINNT4\\java\\javaidl.jar;
             c:\\jre12\\lib\\rt.jar"
Microsoft's JVM uses this registry entry to find Java class files. I have successfully compiled Java IDL and Swing programs using Microsoft's Java compiler. Running such programs is a different story. While my Java IDL classes run fine in the Microsoft JVM, the swing classes from the JRE 1.2 distribution do not work.


Java Plug-in Issues

The Java Plug-in gets installed as part of Sun's Java run-time environment. It can also be obtained separately and redistributed. See this page for more details.

 

Home ] Up ] Purchase ] Preface ] Contents ] Resources ] Errata ] Site Guide ]

Send mail to jpritchard@pobox.com with questions or comments about this web site.
Last modified: August 12, 2003