One step forward, two steps back. As soon as IT professionals are sure that a novel tool is ready to make their lives simpler, they devise a new and complex problem that their new tool might be barely able to solve.
Call it resource allocation, call it geek machismo: Whatever you call it, the phenomenon rides again with the advent of distributed objects.
The notion of an application as a bundle of communicating objects, rather than a program "engine" processing a stream of independent data, is still somewhat new to enterprise application developers. Adding further complexity are distributed objects, which communicate across local and dispersed networks. Making things even more confusing is the tension between Microsoft Corp.'s DCOM (Distributed Component Object Model), a partial but working implementation of the idea, and the Object Management Group's CORBA (Common Object Request Broker Architecture), a multivendor specification with varying implementations.
Ten years ago, objects of any kind were a fringe technology, beloved of Smalltalk hackers with their hideously expensive workstations. But hardware got cheaper more quickly than coders got smarter, and objects have become the cost-effective approach to hiding the complexity of new development platforms. Using languages such as C++ or Object Pascal--or even Object COBOL--developers can now wrap anything from a graphical interface component to an abstract system service in a package that matches applications' needs.
Rather than having independent functions call each other, programmers can now think in terms of objects sending each other messages--and checking those messages against internal validation rules. From here, it's not a giant leap to get from messages that travel within a single computer to messages that travel across a physical network connection.
Although this is a small step in principle, it's a large one in terms of the details that have to be resolved. The essence of object techniques is that those details should themselves be encapsulated in an object-oriented model, generally termed an Object Request Broker, or ORB.
An ORB maintains a repository of interfaces that can be used to request data from objects on one or more machines. The ORB need not possess any knowledge of how that data is represented within those objects: It merely knows what requests an object can satisfy. When an incoming request matches the format of a known interface, the ORB dispatches the appropriate message to the corresponding object.
CORBA Version 2.0, a multivendor interoperability guideline for ORBs, has evolved more slowly than impatient buyers would prefer. CORBA's competition--Microsoft's DCOM--has gotten a late start, but has moved more rapidly to provide a streamlined solution.
Microsoft has no secret ingredient: It's just that more than 600 companies participate in the CORBA process, complying (with varying success) with generic specifications but differing in implementation details. Microsoft, by contrast, need not negotiate with anyone and can offer software developers finely grained consistency between desktop and enterprise operating environments.
At this time, DCOM still has notable gaps. For example, remote administration is difficult due to lack of a robust network-based directory service. CORBA, however, has many more smaller details left to the imagination, and, at this time, many CORBA players are seeking differentiation through separate APIs, relying on higher-level bridging technologies to get from one vendor's system to another in a CORBA-compliant way. Thus, buyers are faced with grave uncertainty as to the ability of "CORBA-compliant" applications to exchange business data items without additional layers of middleware.
Microsoft has released extensive code and sample development tools at recent events such as last month's Professional Developers Conference. Based on these indicators, buyers are likely to feel that Microsoft's time frame for filling the obvious gaps in DCOM is going to be quicker than the OMG members' completion of a far larger number of tiny but crucial details.
CORBA has substantial momentum and strong core technology, and it will be the standard for bridging legacy platforms to each other and to the desktop. It will also require extensive corporate IT training and support investments (as well as generating a lucrative market in consulting and services) to make it work.
DCOM will be the standard on desktop and department-size systems and will be the focal point of interoperability efforts. It will also be the primary target of ISVs.
Neither can safely be ignored.
Advanced Technologies Analyst Peter Coffee can be reached at peter_coffee@zd.com.