Dr. Dobb's is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.


Channels ▼
RSS

Intergalactic Distributed Objects


Dr. Dobb's Sourcebook January/February 1997: Intergalactic Distributed Objects

Ron, a software engineer with Northern Telecom, specializes in distributed object technology. He can be contacted at resnick@interlog .com or http://www.interlog.com/ ~resnick/ron.html.


Sidebar: CORBA Trading on the WWW

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.

The Universal Front End

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.

The Promise Of Java

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.

What Java Lacks

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:

  • Lack of a client/server method invocation paradigm. Java's clear value is in supporting the deep copying (copy by value) of objects in a network. JavaSoft has introduced the Java Remote Method Invocation (RMI), which allows such client/server interactions. RMI presupposes a homogeneous environment of Java clients and servers, and a synchronous blocked interaction paradigm. Clients and servers, or asynchronous interactions, are out of the scope of RMI.
  • Lack of distribution services. Java is not really a distributed system in its own right, and offers only limited distributed services. For example, while the JVM does have some ability to "sanitize" downloaded bytecodes and thus detect potential Java viruses or Trojan horses, this is a far cry from what is typically meant by a "security" service. Similarly, Java and the WWW are only beginning to introduce concurrency, transaction, or licensing services, all of which are essential in building distributed object applications.
  • Lack of persistence. Once objects are brought to a client site, the more valuable ones will need to be stored. Java has its Serialization interface to allow the streamable storage of individual objects, but does not currently have a compound document storage facility similar to OpenDoc's Bento.
  • Lack of integration of applets in an HTML page. As used in current WWW technology, Java applets are brought to a client browser as embedded references inside of HTML pages, which also dictate their visual positioning on the page. There can be multiple applets referenced through a single HTML page, but there is no enforced "awareness" between these applets. This is in essence the same point made earlier about WWW browsers offering only a hollow (as opposed to solid) Universal Front End.
  • Lack of caching. WWW browsers possess a native time-sense; they have "Back" and "Forward" controls that permit navigation to WWW pages previously visited. This sequencing is enforced at the HTML page level. That is, navigation is allowed back and forth only in integral pages: It is not possible to specify that a "piece" of a given page be blended with a "piece" of some other page.

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.

Beyond Stand-alone Java

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

  • JavaBeans (http://javasoft.com/beans/), an initiative of Sun's JavaSoft. JavaSoft is attempting to equip Java with the RMI, robust distribution services, and (through JavaBeans) a full component framework model. By opening the JavaBeans activities to the development community at large, Sun hopes to keep Java in the public mainstream, and to ensure that the JavaBeans component model can fully interoperate with other existing component models such as OpenDoc and OLE. This is undoubtedly the right strategy. Beans are minimalist components that break with the applet tradition of the past, allowing them to be embedded not just in HTML-based frameworks, but in richer DCFs. JavaBeans is a "good news" announcement, and one that will have significant impact on the component software marketplace. Indeed, JavaBeans is the most promising approach to the "grand unification" of the WWW, Internet, and the DCFs discussed in this article.
  • IBM's Arabica and Blue JavaBeans (http://www.software.ibm.com/clubopendoc/webdev.html) and related initiatives such as their Component Assembly Tool (CAT) and Aglets workbench (http://www.alphaworks.ibm.com/). IBM is a hotbed of activity with regard to Java-based distributed objects, and in the grand Internet tradition of openness, it is making many of these offerings freely available. The encouraging sign is that rather than striking out on its own for API definitions, it is joining with Sun in promoting the Beans specification. The IBM San Francisco Shareable Frameworks project (http:// www.softmall.com.sf/) also looks promising. If anything, looking for information and tools at IBM is a little too much of a good thing -- there is a real smorgasbord and the relationships between the tools are not always clear.
  • Netscape ONE Open Network Environment (http://developer.netscape.com/ library/one/index.html) and Oracle NCA Network Computing Architecture (http:// oracle.com/nca/html/nca_wp.html) also offer compound document-based models that support CORBA IIOP, as well as traditional HTTP-based invocations.

What Does CORBA Have that Java Does Not?

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.

Java and CORBA: Externalization II

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.

Call-by-Value versus Call-by-Reference

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.

Existing Java/CORBA Initiatives

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.

Java and OpenDoc

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:

  • Create an IDL interface for an object.
  • Inherit that IDL from OpenDoc base classes so that it is a bona fide OpenDoc part.
  • Implement the object in Java using the OMG standardized IDL/Java bindings.
  • Install the object (which is simultaneously a CORBA object, a JavaBean, and an OpenDoc part) on the server host.
  • Advertise the object through CORBA Interface Repositories, Naming directories, and the like.

A user of that object, from the Universal Front End (the combined OpenDoc/Web Browser, for instance) can then

  • Visually search through the naming repositories.
  • Retrieve the object reference to the desired server object; bind to the object using CORBA binding.
  • Perform any required authentication, authorization, licensing, or transactional operations.
  • Use CORBA static or dynamic (DII) method invocation or optionally stream the object by value using its Java properties to cause the server object to visually "appear" in the client's Universal Front End. The choice of interaction paradigm (static or dynamic, blocked or asynchronous, by-value or by-reference) can be made as required by the end user with visual controls on the desktop.
  • Once the object is localized in the Universal Front End, it takes on its OpenDoc role, and negotiates for visual screen real estate.

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.

Summary

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


Related Reading


More Insights






Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

 
Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.