As the web continues to evolve, its role as a means of delivering information and entertainment content is expanding to include delivery of interactive services. Examples of these services include stock trading, home shopping, home banking, package delivery, reservation systems, internet search services, and interactive chat services. The common thread that runs among all these applications is that, they require a sequence of interactions between the user and a server (or servers). In the simplest case, all interactions are via HTTP with a web server. More sophisticated applications involve highly interactive client-side processing (such as a fully functional GUI interface), as well as a median for the client to communicate with the server over the Internet. Distributed objects provide a particularly useful mechanism for this client-server communication.
Distributed object architectures are the software frameworks required for building and using client/server applications that use distributed objects. Distributed objects, as defined earlier, are packaged as independent pieces of code and can be accessed by local or remote clients via method invocations. Clients do not need to know where the object resides or what operating systems it executes on. The framework also provides an infrastructure for supporting a large number of servers and applications that can spawn any number of transactions.
A common set of services and capabilities provided by existing distributed object architectures is as follows:
In this section we will talk about three existing Distributed object architectures viz. CORBA, Java, and DCOM, and try to compare and contrast them.
CORBA is a product of an industry consortium of 500 odd companies called the Object Management Group (OMG). It is a set of specifications for providing interoperability and portability to distributed object oriented applications. CORBA-compliant applications can communicate with each other regardless of location, implementation language, underlying operating system and hardware architecture. The next chapter (Chapter 20) covers CORBA in detail, so this section will only give a brief introduction to CORBA.
CORBA is composed of five major components:
CORBA supports static method invocations as well as dynamic method invocations on remote objects through its Dynamic Invocation Interface (DII). CORBA 2.0 also defines a standard for inter-ORB communication, called the Internet Inter-ORB Protocol (IIOP). IIOP is basically TCP/IP with some CORBA-defined message exchanges that serve as a common backbone protocol. Thus, we can see that CORBA provides all the services outlined in the common set of services for a distributed object architecture. For more information on CORBA please refer to the next chapter. Orfali, 1996 is an authoritative reference on CORBA.
In this section we will talk about Java in the context of distributed computing. First of all let's discuss some basic facts about Java. More information on Java can be found in Chapter 21.
Java specifies a "bytecode" representation for compiled Java programs rather than a binary representation. Java bytecode is platform independent and is transportable over a network. It can be interpreted and executed by a "Java Virtual Machine" (JVM) - a run-time executable available on an ever-growing number of platforms. The implication is that behavior, and not just data, can be downloaded to a client and executed locally without any sort of setup or compilation.
The main advantages of Java for distributed computing come from this capability to download behavior. Java enables three fundamental capabilities:
In spite of these capabilities, in terms of a full-fledged distributed object architecture, the current implementation of Java (JDK 1.02) lacks quite a few things which are as follows:
JavaSoft is in the process of developing some new APIs for inclusion in the new release of Java (JDK 1.1) These APIs address the above mentioned shortcomings of Java, make it a more suitable medium for distributed computing, and a better, more robust distributed object architecture. What follows is a short introduction to these new APIs.
JDBC is a standard SQL database access interface. This API provides Java programmers with a uniform interface to a wide range of relational databases, and provides a common base on which higher level tools and interfaces can be built.
The JDBC API defines Java classes to represent database connections, SQL statements, result sets, database metadata, etc. It allows a Java programmer to issue SQL statements and process the results.
The RMI specification is a new API that lets you create objects whose methods can be invoked from a different Java Virtual Machine (JVM). The JVM may be running in the same physical machine or a remote server. Thus, RMI basically provides the capability for calling methods on remote objects.
This API provides a persistence mechanism for Java objects. It supports the encoding of objects and the objects reachable from them into a stream of bytes and the complimentary reconstruction of the object from the stream. It can be used for storing Java objects in a persistent state and reviving them whenever necessary. It can also be used for communication via sockets or RMI.
Java IDL provides a way for transparently connecting Java clients to network servers using the industry standard IDL Interface Definition Language. It allows a Java client to transparently invoke a CORBA object on a remote server. Similarly, it allows a Java server to define objects that can be transparently invoked from CORBA IDL clients.
The Java Core Reflection API provides a small, type-safe and secure API which supports introspection about the classes and objects in the current Java Virtual Machine. If permitted by security policy, the API can be used to construct new class instances and new arrays, to access and modify fields of objects and classes, to invoke methods on objects and classes, and to access and modify elements of arrays.
This API can be used for secure purchasing and financial management on the Web. The Commerce API is part of a larger undertaking called Java Electronic Commerce Framework (JECF), which also includes other components such as Java Wallet and Java Card. Java Wallet defines and implements a client-side framework for credit card, debit card, and electronic cash transactions.
DCOM is Microsoft's standard for distributed computing. It is a third important standard to consider in the world of distributed objects. It is an extension of Microsoft's Component Object Model which forms the foundation for the Windows platform. The beta version of DCOM for Windows 95 was announced recently. It is also called Network OLE, as it supports distributed OLE controls. DCOM is based on Open Software Foundation's DCE-RPC specification for providing distributed services. It forms the basis for the recently announced ActiveX technology.
Let's take a short look at the relative merits and demerits of CORBA and Java.
Architecture neutrality vs. Communication transparency:
Java provides architecture neutrality, while CORBA provides communications
transparency and local/remote transparency. Local and remote invocations
are syntactically and functionally equivalent for CORBA objects. CORBA
also provides platform dependence, but CORBA applications can suffer from
a new type of dependence, namely ORB dependence. Two applications using
two different commercial CORBA ORBs, might have problems in communicating
with each other if the ORB implementations are not compatible with each
other.
Single language vs. Language independence:
Java is a single language, while CORBA was designed to bridge language
differences as well as other system differences. CORBA simplifies mixed
language programming.
Distributed Services:
CORBA defines a much richer set of distributed services than Java does
currently. However the new Java APIs that are being designed for JDK 1.1
take a concrete step towards providing many of these services in Java.
Commercial Availability and Industry Support:
Commercial availability of CORBA-compliant ORBs is limited. Even the ones
that exist are slow and inefficient. Java on the other hand is a complete
implementation and is freely available. CORBA is an industry standard
supported by over 500 companies while Java is a company standard.
Complexity:
CORBA requires too much machinery for simple client/server applications
that are relatively easy to develop in Java.
Java RMI is not CORBA-compliant, but is the "pure Java" solution. Interfaces are defined in Java as opposed to CORBA's language-neutral interface definition language (IDL).
CORBA was designed for a language-independent distributed computing environment where the heterogeneity of the underlying systems is assumed and the objects communicating are written in compiled languages. Java RMI, on the other hand, was designed for a single language environment where the objects are running in a homogeneous environment and where new code can be downloaded at any time.
The language dependence/independence difference shows in the object model each has. The CORBA object model is defined by IDL, which is a different object model than will be found in any object-oriented language. Considerable effort (and complexity) goes into mapping the IDL object model into the object model of the particular programming language. Even in the case of C++, after which IDL was modeled, it is not an easy match.
On the other hand, Java RMI has no separate interface definition language; you just define remote interfaces in Java. This means that there is no translation from one language to another, since you are always in the Java language, using the Java object model.
The heterogeneous/homogeneous environment difference is a little more subtle. In the CORBA world, references are passed around and the code that is associated with that reference has to exist on both sides of the call. Because of this, objects are passed as their declared type (even if they are a more derived type), since it is only code of the declared type that can be guaranteed to exist on the receiving side. For example, suppose class B is derived from class A. If you pass an object of type B in a call that declares that it needs an object of type A, when the reference arrives it will be an A. If it is further passed as an A to something else that inquires if it is a B, the answer will be "no."
Java RMI, on the other hand, always passes an object as it's real type. If the code doesn't exist on the receiving side, that code is simply downloaded. So in the scenario above, when the object of type B is passed to a receiver asking for an A, it is still of type B. When passed along to the third receiver and asked if it is a B, it will reply "yes." If the right code to handle a B isn't around, that code will be loaded (with, of course, all the appropriate security checks).
Another major difference is that Java remote objects are garbage collected, which can't be done with CORBA objects, since CORBA objects are language independent, and therefore have to be consistent with languages that don't support garbage collection. A CORBA remote object, once created, exists until someone gets rid of it; one of the major complications in writing a CORBA server is deciding when it is OK to get rid of the objects. In the JavaRMI case, this is part of the Java garbage collection system, extended by the RMI system.
Another difference is that Java RMI does not have the interface repository of CORBA. It doesn't need it, since the objects are all Java objects and their types, methods, and fields are described by the loadable class files.
Although, Microsoft's DCOM is a relatively new standard, it has the potential to offer a tough fight to CORBA and Java, because of the wide popularity of the Windows desktop and the large number of applications available for it. More information on DCOM can be obtained from Microsoft's DCOM site.
Copyright © 1996 Ashish B. Shah, All Rights Reserved.
Ashish B. Shah
<ashish@csgrad.cs.vt.edu>
Last modified: Tue Oct 29 11:59:59 1996