Matt Segvich

COM/CORBA Bridge

The COM/CORBA bridge allows COM components (including DCOM) to seamlessly interact with CORBA applications and vice-versa. COM components are commonly found in applications used in Microsoft applications, especially since the COM specification was developed by Microsoft. Therefore, the advantage to a bridge is that if developers are familiar with Microsoft toolkits, they won’t have to become familiar with CORBA. Likewise, if you have CORBA developers and they have to interface with COM components, they won’t have to learn Microsoft’s products. Thus, time and money are saved in not having to either hire resources or train current developers who are knowledgeable in the new product.

The Object Management Group (OMG) has a specification for COM/CORBA interaction. According to the OMG, there are two options to be compliant with their specification, mapping and interworking.

Mapping consists of COM objects being translated to CORBA objects or vice-versa. It is important to note that this is a one-way communication. You can provide a map to go translate from CORBA to COM and not the other way around and be compliant. The importance in this resides in knowing the limitations of mapping. So while objects can be made available to different distributed computing systems, mapping can not support classes that are composed of other objects. Specifically, they can not have objects as arguments to methods, objects as arguments to interfaces, or objects as properties.

Needless to say this is a severe limitation. So why use maps? If all you’re trying to do is simple translation of objects from one system to another this may meet your needs. Creating maps is typically straight forward. In our case, COM and CORBA are quite similar in concept and though there are exceptions, by and large, the translation of objects between systems is trivial.

The other method of communicating is call interworking. This is much more complex, but it offers many more capabilities than mapping.

Interworking provides two-way communications. For example, if you have a CORBA server and a COM client calls a method from the server passing one of its objects as an argument, the CORBA server can operate on that COM object and return it to the client in its expected COM format. This is quite powerful.

The OMG specification spells out what the requirements for mapping and interworking are, but provides no implementation. Thus, difficult issues, such as asynchronous calls (e.g. event handling) are left up to other parties, typically commercial vendors, as to how to deal with these. For instance, how do you translate calls to Microsoft’s connection points to CORBA’s event services? In many cases, implementers don’t, because you may have met the specification for interworking, but not have support for asynchronous calls. You just need to be aware of these issues. Just because you have two-way communications, doesn’t mean you can do anything you want between the two systems. You may have to develop some of these services yourself or be reliant on a third party.

Parties that provide bridges are Sun’s Active X Packager and Visual Edge’s Object Bridge.

Interesting enough I could not find any reference to bridging from Microsoft. If they do have any documentation, they’ve buried it somewhere on their site. I checked a few of their magazines as well (i.e. MSJ) and couldn’t find anything. It seems they’re just leaving it to the development community and the OMG to figure it out for them. I hope I’m wrong here, but I haven’t been able to see any proof that they’re addressing this.