FRAMINGHAM (05-24-95) - ~For most network users, the Common Object Request Broker Architecture (CORBA) 2.0 -- the Object Management Group's (OMG) new interoperability standard for ORBs -- provided a startling revelation. Many users had believed the original version of CORBA made it possible for objects of all descriptions to interact across networks. Surprise: Until CORBA 2.0, each ORB was an "island of objects" that couldn't interoperate with other islands very easily, if at all.
But while CORBA 2.0 solves the problem of interoperability between CORBA systems, there are many other object systems in use today that do not support CORBA. The leading example is Microsoft Corp.'s OLE 2.0. There is no standard -- de facto or otherwise -- for interoperability between OLE 2.0 and CORBA 2.0.
Adding to the interoperability challenge are the many other object systems in use. These include the four major Smalltalk language environments, each of which is slightly different; the many different versions of C++; development tools such as Powersoft Corp.'s PowerBuilder, Forte Software Inc.'s Forte and Dynasty Technologies Inc.'s Dynasty Development Environment; and Lotus Development Corp.'s Lotus Notes, with its object model for document-sharing applications.
Within any one of these object systems, interoperability is possible. For example, the odds are quite good that two objects built using ParcPlace Systems Inc.'s Smalltalk environment will be able to interact. The same cannot be said for an object built using ParcPlace's Smalltalk and one built using any of the other Smalltalk versions. Even though two object systems may share common genetic material, so to speak, interoperability between them is still difficult to achieve.
Interoperability between completely different object systems is that much more difficult. Developers report major headaches in trying to bridge the Component Object Model or Notes and CORBA; Smalltalk and C++; and so on.
Many organizations already have at least two or three incompatible object systems installed and running today -- even if they don't realize it. As more users and vendors put object technology to work, new object systems will continue to appear.
Sun Microsystems Inc., an OMG founder and a strong CORBA backer, is an example of a company using multiple object systems despite a seeming commitment to a single object system -- CORBA. Sun will soon ship a new version of its Solaris operating environment that includes a CORBA- compliant ORB and associated tools. At the same time, Sun's internal MIS organization is building a new architecture that uses custom middleware to support data and application integration. The internal group is not using CORBA; it has created its own object system.
Sun is also working on Hot Java, a product that promises to turn the Internet into a giant distributed object computing environment. Hot Java is based on still another object system derived from C++.
This scenario is becoming increasingly common. Just as different groups within organizations decide to install Apple Computer Inc.'s Macintosh OS or IBM's OS/2 Warp instead of Microsoft's Windows, users will also bring in multiple object systems. The result will be islands of objects -- pockets of users of particular object systems, each of which exists largely in isolation.
Integrating these islands of objects will be the top systems integration issue facing users for the rest of this decade. Yet so far, there has been little discussion of object interoperability. In general, users and vendors seem to be sitting back and waiting for the OMG to solve the problem for them. Unfortunately, this is not likely to happen. The OMG is doing important groundwork by producing interoperability standards such as CORBA 2.0. But CORBA 2.0 is an enabler of solutions, not a solution in its own right.
The situation is analogous to the islands of automation problem of the 1980s. At that time, users needed to integrate data stored in incompatible system architectures. The cost of integration was so high that users demanded architectures to make integration easier and less costly. In the late '80s, IBM expended an enormous amount of money and energy building a set of interfaces, called Systems Application Architecture (SAA), just to rationalize its own incompatible computer architectures.
Object interoperability will be a bit different. Note that the emphasis is on interoperability as opposed to integration. Interoperability recognizes that multiple object systems are inevitable, and the best approach is to design bridges between these systems.
It is naive to expect that all users and vendors will adopt a single object system, such as CORBA or OLE. The best way to balance the freedom of choice users want, with the interoperability that organizations need, is to design software that can transform and interconnect objects from different systems. We are just beginning to see this type of software from vendors such as Forte Software, Iona Technologies, Ltd., Teknekron Software Systems Inc. and Visual Edge Software, Ltd.
During the era of systems integration that SAA exemplifies, the driving user need was to integrate data. Now, in the age of distributed objects, users need to integrate functions as well as data. Most users of distributed object technology hope to be able to mix and match software assets across their enterprises to speed up application development, make information systems more accurate and relevant, and keep maintenance costs in line. These goals won't be truly attainable until the object interoperability problem is solved.
(Rymer is editor in chief of the Distributed Computing Monitor, a monthly report published by Patricia Seybold Group Inc. of Boston. He can be reached at (617) 742-5200 or via the Internet at jrymer@psgroup.com.)
[Copyright 1995 Network World (US), International Data Group Inc. All rights reserved.]