Dr. Dobb's Sourcebook January/February 1997
To date, the two key technologies that have promised a component approach to software distribution are Microsoft's OLE and the hybrid of OMG (http://www.omg.org/) CORBA and CI Labs' OpenDoc. Eventually, software components of all varieties will coexist. OpenDoc (see http://software.ibm .com/clubopendoc/ and http://opendoc .apple.com/) was, from its inception, designed to support the notion of "component inclusivity," with Componentglue to make OLE objects behave as first-class components in an OpenDoc compound document, and vice versa. The Essential Distributed Objects Survival Guide, by Robert Orfali, Dan Harkey, and J. Edwards (John Wiley & Sons, 1996), provides an excellent discussion of these technologies and the relationships between them.
In this article, I'll build on the Orfali thesis of "intergalactic components" based upon Distributed Component Frameworks (DCFs). I'll then extend it to account for the proliferation of the World Wide Web and Java. The point of all of this is that the Web and the world of distributed components are merging, and the best capabilities of both domains can be used to enhance each other in the superposition of the two.
For starters, let's look at a key concept introduced by both the Web and DCFs, namely the "Universal Front End." This concept involves the emergence of a single point of contact for users of computing systems. It takes the notion of standardized GUI to the extreme, suggesting that all computing is done in the space of a single GUI framework, manipulated by a single consistent set of controls -- the Universal Front End.
The DCFs tackle the notion of a Universal Front End explicitly by introducing a document-centric, as opposed to application-centric, view of a desktop. Microsoft OLE and OpenDoc offer compound document frameworks in which one continuous stream of content can be placed inside a single container (the document), and each form of content has associated controls used to modify the content in place, with uniform user interfaces.
In contrast, the Web offers its own Universal Front End -- the web browser. It would not be out of place to suggest that many desktops in the world today, when started for a session of computing, have a Netscape Navigator or Internet Explorer client brought up first. Furthermore, we expect more of our information to come through a web browser and more of our work to be done on the surface of a browser. In short, the world has discovered its Universal Front End of choice, and has embraced it passionately.
Hence, for DCFs to achieve their quest of being the desktop Universal Front End, they must quickly come to grips with the fact that it already exists, and that they will have to merge with the browsers.
Why should the browsers welcome these suitors? Precisely because of the painstaking attention to detail they offer. While Navigator is certainly a Universal Front End in that it can connect a user to American Airlines one moment and CNN the next, only the controls and menu items around the perimeter of the browser remain invariant between these sessions. The content downloaded from the servers (displayed in the center of the browser window) has no enforced commonality. Most significantly, the controls embedded in these downloaded content pages -- the hyperlinks, dialogs, and pushbuttons contained in American Airlines' and CNN's HTML pages, as well as the back-end CGI processing of these controls -- have no consistency requirements. Thus, browsers offer only a hollow Universal Front End -- the center is still up for grabs.
This is where DCFs in general -- and OpenDoc in particular -- truly shine. OpenDoc parts all have an enforced consistency of appearance, behavior, and controls gained through object inheritance. When these parts are dropped together in a container, a new "application" is created from the dynamic collaboration of all of them. This "application" is solid, though, where the web page was hollow. All the controls everywhere in the compound document -- along the periphery and in the center -- subscribe to the common OpenDoc model.
In response to these issues, Apple has developed a tool named "CyberDog" -- a suite of OpenDoc parts each performing an Internet task: e-mail and News clients, HTML parsers, image viewers, and the like (see http://www.cyberdog.apple.com/). These parts can be placed in an OpenDoc container with the result being a fully functional WWW browser.
There is a race against time for the DCF proponents to act. For, not only is the CORBA/OpenDoc coalition battling its long-standing foe OLE, but a new contender, Java, has entered the ring, and has brought with it the "mother of all distributed systems" -- the Internet.
So much has been said and written about "The Promise of Java" in recent months that one cringes to say any more. And yet, Java is unleashing a tidal wave that simply must be taken into account. The ability to download behavior from a server to a client enables three fundamental capabilities.
First, it allows clients to dynamically gain an intelligence they did not originally have. This intelligence can be added to any preexisting behavior the client already had, without cumbersome recompilation or installation procedures. Obtaining it is as simple as clicking a piece of HTML hypertext.
Second, it greatly simplifies software upgrade issues in large distributed systems.
Finally, Java simplifies the burden of software component developers who wish to provide their components on heterogeneous platforms. Rather than cross-compiling and testing their binary components on Windows, OS/2, Macintosh, and UNIX, developers can write their code in Java, compile it to bytecode, and test it once in a Java Virtual Machine (JVM) environment on their OS of choice.
Although clearly powerful, stand-alone Java is lacking in several respects. Fundamentally, Java is a programming language and bytecode specification. It is not an application architecture, distribution model, or component framework. Stand-alone Java is insufficient for building enterprise systems. Some of the shortcomings in stand-alone Java are:
Of these shortcomings, the first two deal with the distribution aspects of Java while the latter three deal with the framework and compound document aspects. This observation is of central importance in this article: that the integration of Java into a usable component software model requires work both at the ORB level as well as at the framework level.
Proponents of stand-alone Java are well-aware that it is insufficient for a full distributed object framework. There are a number of initiatives to address most of the aforementioned issues, such as
Earlier, we noted that stand-alone Java has weaknesses in its client/server model and distribution services. These are precisely the areas where the CORBA specification has excelled.
CORBA offers comprehensive support for remote invocations. It achieves this through its Interface Description Language (IDL), and its static and dynamic invocation mechanisms. With respect to distribution services, the CORBAServices suite offers the most complete set of services ever assembled in one distributed computing specification. CORBAServices include naming, events, trading, security, externalization, licensing, concurrency, transactions, persistence, time, and more. (For more information, see the accompanying text box entitled "CORBA Trading on the WWW.")
CORBA offers the world its IDL, its well thought-out approaches to static, dynamic, synchronous, and asynchronous interfaces, and a rich and comprehensive set of CORBAServices. All of these contributions are the result of several years of dedicated effort by the best practitioners in the industry in each subject matter. Language and compilation experts considered the syntax of IDL and issues of language bindings. Distributed computing experts considered the network implications of how the static and dynamic interfaces could best be designed. And domain experts in areas such as databases, transaction systems, and security applied their talents to each of the CORBAServices.
It is ironic that a comprehensive architecture with such broad industry backing and such a clearly superior technological basis still faces significant ambivalence in the industry. The WWW and Java are all the rage, while CORBA seems to remain, in the popular psyche at least, relatively unknown.
CORBA offers one CORBAService, the Externalization service, that is of particular interest here. The CORBA Externalization service supports the streaming of an object from one physical location to another. However, CORBA Externalization permits the "roaming" only of an object's state, not its behavior. To permit roaming behavior across different network, hardware, and operating-system environments would require an efficient interpretive system, such as Java. Hence, CORBA Externalization supports roaming objects only when a class' methods are already implemented in the native execution environment of the destination host. This implies that only hosts that have been statically precompiled with a class' methods are candidates for being the destination of an externalized object.
While the Externalization service is undoubtedly useful in its current form, extending it to support the streaming of an object's behavior as well as state certainly would be of great benefit. This leads to a key recommendation of this article: The OMG should extend the existing Externalization service to support streamable behavioral objects. There is an OMG Request for Protocol (RFP) asking for a "By Value" transfer service that may be suitable for this purpose. Submissions to this RFP would augment the existing IDL interfaces of the Externalization service to support streaming of object behavior to and from a stream. An obvious submission to the By Value RFP would be the Java language, Java bytecodes, and the JVM interpreter as a reference implementation that meets the needs of the By Value RFP. Let's call such a submission, assuming its acceptance, "Externalization II."
With Externalization II (based on Java) in place, the strongest aspects of Java and CORBA would be merged. The CORBA architecture provides a full distributed environment, including remote method invocation facilities, services, and implementation language independence. However, it does not have any mechanism for streaming object behavior. In contrast, Java is not really a distributed environment, but it does offer the streamable object behavior that CORBA lacks. Thus, rather than build an entire distributed environment around Java, it would appear far more sensible to "inject" Java into the Externalization service of CORBA, letting it serve its natural function in an existing and powerful distributed architecture.
CORBA and Java provide flexibility similar to the "call-by-value" and "call-by-reference" styles in programming languages. Call-by-reference is typically far more efficient, since it requires minimal physical copying of data onto the calling stack, and copies only pointers to heap storage. However, call-by-value has its place as well: There are cases where the called function (or object) has no access to referenced values, or where it wishes to modify a local copy of the value without affecting the original value. Virtually all programming languages, object oriented and otherwise, have recognized the need to support both. Most modern languages default to copy-by-reference for performance and efficiency reasons, but still have support for call-by-value. Object-oriented languages have another reason for preferring copy-by-reference, since it supports the data encapsulation principles of objects more naturally.
When distributing objects over a network, the same fundamental principles apply, and are even heightened. Access by reference to an object (that is, remote method invocation) is inevitably more efficient and better supports that object's encapsulation. Even as we move to an era of high-speed networks, it will still usually be preferable to ask a remote object to perform a calculation on itself and return a result. However, there will always be cases where the "by value" streaming of an object will be needed, and indeed may be more efficient (for example, when the object is used repetitively by the client, so the cost of transporting it once can be amortized over the more efficient subsequent local method calls). Note that there is nothing fundamentally new being stated here: The choices between "thin client/fat server" and "fat client/thin server," and between database-stored procedures versus database client code involve the same tradeoffs.
The advantage of the CORBA/Java strategy suggested in the Externalization II service is that it does not enforce a compile-time static choice for "fat" versus "thin." Rather, it lets developers create distributed objects and lets the users of those objects decide dynamically whether to cache them locally or access them remotely. Indeed, these users can alter their strategy at will. They can begin by invoking the object remotely through CORBA remote invocations, and at any time, decide that it is worthwhile to stream the object locally. This decision would presumably be based on the performance consideration of paying a one-time download charge, made up for by subsequent faster local access. Furthermore, it could be made by an end user without requiring programming ability, merely by selecting a "localize object" visual control.
ORB vendors have been working on CORBA/Java gateway implementations. There are several of these, such as Iona's OrbixWeb (http://www.iona.com/Orbix/ OrbixWeb/), Visigenics VisiBroker for Java (http://www.visigenics.com/), and Sun's JOE. These all appear to employ a "two-phase" integration, in which a Java-enabled web browser is used to download a Java applet from a server host. Once localized, the Java applet begins executing in the space of the browser's JVM. Unlike ordinary applets, however, the applet contains a "miniature ORB" within it. Thus, using such a gateway is a two-phase process. First, you download the Java applet from the Web using standard HTTP streaming. You then let the localized applet act as an ORB client and invoke methods on remote CORBA servers.
Since this two-phase approach seems to be the prevalent one in the industry, I'll contrast it directly with the aforementioned Externalization II approach. Unlike Externalization II, the two-phase approach does not attempt to unify Java and CORBA: Rather, it advocates a gateway approach. This does not yield the same benefits, since the Java side of the gateway now cannot benefit from the CORBA services (for example, the Java applet is still downloaded using HTTP). Hence, clients cannot find their applets using CORBA naming or trading. And, once found, the clients and their server applets do not benefit from CORBA security, licensing, and so on. Meanwhile, by leaving the CORBA side of the gateway without the benefit of Java's streamable behavior, CORBA objects lose all the dynamic benefits of streamable behavior. Hence, it is to the mutual benefit of both camps (Java and CORBA) to merge, and take advantage of each other's strengths.
Finally, it will always appear unnatural to an end user to have to work with the two-phase approach, in which phase I uses one infrastructure (HTTP and Java) and phase II uses another (CORBA). Users will insist on a simplification into one common infrastructure, especially a common infrastructure more powerful than the sum of its parts, such as that proposed in the Externalization II service.
We have noted that Java's deficiencies as a complete distributed infrastructure fall into two basic camps, namely the lower-level distribution aspects and the higher-level visual-framework aspects. The Externalization II proposal discussed how to combine Java with CORBA to best overcome the first set of issues. We now consider how to combine Java's strengths with OpenDoc in order to deal with the latter set.
In fact, I've already discussed the importance of creating a single Universal Front End for users, and the fact that the Java-enabled web browsers are well on their way to taking their place in popular usage for this task. However, since they only provide a hollow standardization (only their perimeter controls are invariant), they require help from the DCFs to complete the task in the center of the browser. It is possible to build such a DCF from the raw materials of HTML and a scripting language such as JavaScript (as is being done in Netscape ONE). But this approach doesn't take advantage of the inherent abilities of objects and frameworks, such as extensibility through subclassing and dynamic semantic messaging. More promising then, is JavaBeans' approach, in which individual beans on a desktop are full objects in their own right with an event-based messaging model.
I'll now suggest going one step further, by basing the high-level component integration upon Externalization II. Externalization II, in effect, would be JavaBeans first-class CORBA objects with IDL interfaces. Of course they are very powerful CORBA objects, since they support the behavior streaming capability of Java. But fundamentally, to an external user, an object implemented in Java that advertises an IDL interface is indistinguishable from any other CORBA object. Also, OpenDoc parts are really CORBA objects as well (again, with special properties like support for scripting and automation).
So, a developer can:
A user of that object, from the Universal Front End (the combined OpenDoc/Web Browser, for instance) can then
You can only surmise that IBM, in putting forth Arabica and Blue JavaBeans, has exactly this kind of tight integration between CORBA, Java, and OpenDoc in mind. Arabica can achieve a complete desktop synthesis made possible when CORBA objects, OpenDoc parts, and JavaBeans are literally one and the same thing, merely exhibiting different aspects of their behavior in differing conditions (not unlike a wave/particle duality for physical "objects").
This model now allows for a fully solid, yet network-distributed Universal Front End, in which the best aspects of CORBA, Java, and OpenDoc are fully leveraged. It does, however, require the adoption of a "By Value" service based on Java, such as the Externalization II model recommended in this article.
The vision that is promised by the technologies I've discussed here is the same "intergalactic distributed objects" vision proposed in Orfali et al., but updated to account for the "intergalactic network" that already exists -- the WWW and Internet.
DDJ