DBMS, March 1998
So whatıs it going to be, COM or CORBA? If you are like most application or enterprise architects (or developers), youıve been avoiding making that decision for fear you could lock yourself into a standard that may not succeed. Thus far, itıs been easy to avoid picking sides because most client/server, Web-enabled, and distributed computing applications have been small and simple, with the enabling technology driven by short-term requirements. Those days are quickly coming to an end as the importance of enterprise architecture begins to sink into the minds of many organizations. Itıs about time, donıt you think?
We are finally looking toward complex distributed computing solutions to business problems at the enterprise level. To do this, we need a common application distribution standard, such as CORBA or COM, and the tools and technology not only to create applications but to tie them together as well. In the real world, however, enterprises are islands of loosely coupled information technology standards and solutions, with little coordination and interoperability among the islands. Part of the problem is management and the inability to work together, but the larger issue is interoperability among middleware, tools, and distributed object standards.
Although the issues are complex, the problem of interoperability is certainly one we can solve. For some time now weıve been learning how to link deviant applications together using common middleware or open APIs. We are now extending this concept to the most popular distributed object/middleware standards: COM and CORBA. In other words, we are learning to cross the object standards chasms, making applications work together no matter what church they attend.
The need for a common plumbing layer is clear. Almost all organizations take a "federated" approach to running application-development projects. Each project uses the technology and tools best suited for its short-term goals. Typically, interoperability is at the bottom of the list of priorities for the project leaders.
Distributed objects hold the promise of allowing several applications using the same object interface standards (namely CORBA or COM) to tie to each othersı services. For example, an inventory-control application written using COM exposes its methods to other COM-enabled applications accessible over a network. The same goes for CORBA-compliant application objects. The difference is in the packaging.
CORBA is heterogeneous, where COM is traditionally found on Windows. Several object request broker (ORB) vendors such as Iona Technologies Inc. and Visigenic Software Inc. (recently purchased by Borland International Inc.) sell CORBA-compliant objects for all sorts of applications. COM, in contrast, is built into the infrastructure of the Windows 98 and Windows NT operating systems. (Note that DCOM was distributed COM, or COM with a longer wire; Microsoft now wants DCOM and COM to be known as just plain COM. This business is driving me crazy.)
The CORBA Internet Inter-ORB Protocol (IIOP) allows ORBs from several vendors to work together ı thatıs the idea, anyway. Lately, and with the rise of COM as the distributed object of choice, weıre seeing more products that allow both CORBA and COM objects to work together. Most important, however, a standard known as the COM-CORBA internetworking specification is emerging.
The COM-CORBA internetworking specification comes from the Object Management Group (OMG). It defines a standard mechanism to move requests from COM objects to CORBA objects and back again. The COM-CORBA internetworking specification defines bidirectional mapping, which allows a client to see a CORBA object as a COM object, or vice versa.
The COM-CORBA specification is just a work in process, with the majority of the work broken down into two portions: Part A and Part B. Part A defines the core mechanism to achieve CORBA-COM interoperability, and Part B attempts to address miscellaneous issues such as error handling, network access, and CORBA sequence types. If youıre interested in working with the OMG on the maturation of this specification, the group (www.omg.org) will be happy to have you.
Part A of the specification, at its core, defines three different "views" that are exposed to an object. The first CORBA view allows a COM object to be invoked using a standard CORBA interface. The second view is a COM view that allows a CORBA object to be invoked through a COM interface that provides support for structures and pointers. Finally, the Automation view allows a CORBA object to be invoked through a standard COM Automation interface that supports only simple scalar datatypes.
OK, I know what youıre thinking. If the COM-CORBA specification is a work in process, how can products now available provide COM-CORBA interoperability? Like everything else, vendors have launched products that implement COM-CORBA interoperability in their own special way, not supporting the OMG interoperability standard directly. The idea is that when the specification is final, the COM-CORBA interoperability products will change to support the standard.
Although each product goes off in its own different COM-CORBA linking direction, the products do have some things in common. For instance, most of these interoperability mechanisms generate a "bridge" object thatıs really both a COM and CORBA object. The "bridge" object acts as a proxy between the two object standards talking COM on one half and IIOP on the other. In addition, the COM-CORBA interoperability product provides a wizard that generates a set of COM (Automation) interfaces and the linked CORBA IDL definition.
Several vendors provide COM-CORBA interoperability today. They include Visigenic/Borland, Iona Technologies plc., BEA Systems Inc., Expersoft Corp., and Sun Microsystems. Itıs interesting to note that these are all CORBA-enabled vendors looking to include COM object connections with their offerings. We have not yet seen an interest in CORBA connectivity with traditional COM-enabled tool sets such as Visual Basic and Visual C++. (You can connect to CORBA-compliant ORBs through DLLs, but itıs not pretty.)
Visigenic/Borland sells two CORBA-compliant ORBs: VisiBroker for C++ and VisiBroker for Java. VisiBroker for Java has made the most splashes in the business, not only because of its Java bindings but because it is built into the Netscape Communicator 4.0 Web browser, enabling IIOP communication over the Web. Oracle has also licensed the VisiBroker ORBs for its product offering.
Visigenicıs COM/CORBA connection product is VisiBridge, which comes with the VisiBroker products. VisiBridge allows ActiveX controls and other COM objects to interoperate with CORBA objects.
When using VisiBridge, you get to know the VisiBridge wizard, which lets you build the bridge object to CORBA as either a COM-enabled Automation server or an ActiveX control. When generating an ActiveX control, VisiBridge automatically generates a GUI front end to put a Win32 face on the control.
You do need to know that products such as VisiBridge only give you a start. For more complex distributed applications using COM-CORBA links, youıll need to do a lot of tweaking. For example, some of the changes youıre likely to make include modifications, which address different exceptions and datatypes supported by the CORBA IDL and COM Automation.
Exceptions are processed differently in CORBA and Automation. An example is raising exceptions from the interface that are defined in the IDL. Automation, in contrast, does not support the CORBA definition of exceptions. To get around this problem you can link CORBA exceptions to an Automation client through such tricks as declaring an option argument at the end of each methodıs argument. The argument returns the exception information back to the COM side of the system. When the client passes the argument, the exception information is available from the returning argument pointer. When the exception is not passed, a general system exception may be used.
Of course, the differences donıt stop there. The CORBA IDL can support a structure of attribute name/type parts that creates a complex datatype (known as "structs"). COM Automation does not support structures, thus when translating between the standards, all "structs" declarations have to morph into new and separate objects. If you think that such a process creates a lot of overhead, youıre right.
The binding process of CORBA has to adapt as well when talking to COM. When using the default "blind bind" mechanism in the CORBA world, the object will locate and connect to the fist instance of the interface implementation found on the wire. The VisiBroker product uses Visigenic Smart Agent technology to locate the interface. In contrast, COM does not distinguish between instances of interfaces on the network. Thus, when connecting COM and CORBA objects you need to address the different approaches to finding interfaces. An intelligent mechanism would assure that you find the right interface. Most COM-CORBA bridging products use the CORBA naming services as the mechanism to do just that.
Finally, you have to address the use of COM monikers when looking to make the COM/CORBA link. A moniker is an object instance that assists a client in binding logic with a moniker. It makes sense to protect COM applications from the CORBA binding process by embedding a find-and-bind mechanism inside a moniker.
The process of linking COM to CORBA is complex. The differences in the technology are at the root of the problem. For instance, and in addition to the information Iıve already mentioned, CORBA is a standard, not a technology, and it was designed as an interoperability and integration specification. COM sticks pretty much to a programming model. Whatıs more, while CORBA lets developers access remote methods through a common interface and provides some degree of source-code compatibility, COM is the only standard that provides for the sharing of binary components. This is because COM is largely a Windows-only product. CORBA is looking to address this with JavaBeans, but with the death of OpenDoc it may be too late.
Letıs face facts. Building and implementing an enterprisewide distributed object system is difficult and risky. However, distributed objects are architecturally elegant and make sense for many applications. Moreover, distributed objects, when using the proper architecture, provide good performance, scalability, and ease of maintenance. With the maturation of the CORBA standard to provide better security and transaction services, the features of the ORBs are bound to improve. Whatıs more, Microsoft is adding its own twist to the market by transaction-enabling COM through Microsoft Transaction Server as well as building more COM features into the companyıs already popular tools.
We are moving away from having to deal with the technical details of distributed objects using layers of tools and technology. Today, we are less worried about implementing the mechanics of distributed interfaces, so we can better concentrate on the implementation issues. The appearance of products that not only promise, but deliver, bridges between both CORBA and COM ensure that this trend will continue. We no longer have to worry about interoperability. We no longer have to give up sharing services among applications. We can finally get along with others in our organization who may not see things the way we do.
| Company Information |
|---|
|