A Practical Comparison of Java Component and Distributed Object Technologies

Reprinted from Object Magazine Jan 98 with permission by SIGS publication

By David Orchard,

The Java language has gained enormous momentum with widespread deployment. A variety of distributed object and component technologies now augment the language itself. This article will take a comparative look at CORBA, RMI, Beans, HTTP, COM, DCOM, DNA and more. Explanations and cookbooks of the technology pieces have been covered in great detail in many publications, so this article concentrates on why component technologies are so interesting, why any technical differences exist, and the similarities and differences in the development, performance and technical aspects of each technology.

Yet Another Paradigm Shift (YAPS)

The convergence of ever-cheaper computing with widespread connectivity through the Internet heralds the age of network-centric computing. Many years ago, Xerox PARC saw Moore’s law leading to three distinct phases of computing. Expensive computing led to the mainframe world, where many users interacted with a single machine. That era was subsumed by the Personal Computer era, when computers on every desktop were connected together by simple Local Area Networks. We are now heading into the final era of computing, where computing power is cheap and globally connected. In this world of network computing, every person will have the use of many CPUs. Readers who use cellular phones, Personal Digital Assistants or Network Computers are living the leading edge of the NC wave.

Figure 1.

The ramifications of the growth of network computing on software development are enormous. Developers must determine how to build software for a world with many microprocessors per person, with all of them connected cheaply. Software development, deployment and maintenance must evolve to deal with the new realities.

Three tier architectures

The first change in software development is the architectural change from client/server to three-tier – also called Network Computing Architecture (NCA). This accounts for all types of clients, from ultra-thin to thick, connected to compute and data servers. The first widely deployed NC architectures appeared in 1995, when web servers added the Common Gateway Interface and database vendors provided Perl APIs. Web clients requested web pages that were constructed by Perl CGI programs retrieving data from databases and handling forms input. Now a generalized understanding of the tiers and communication patterns is emerging.

The web top, a web browser running on any operating system or hardware, dominates the first tier. Indeed, the web top is the client operating system of the future. The web top renders data in the form of HTML pages and it executes behavior in the form of Java, JavaScript or ActiveX/DNA controls. The web top handles all aspects of presentation and has little knowledge of the business rules of an organization.

The message interface connects the client to a business object on a server. The message mechanisms include RPC, HTTP, IIOP, RMI and COM+. The business object is represented as data – HTML pages again – or behavior – the usual suspects of Java, ActiveX/DNA controls - as well as scripting languages such as Perl and JavaScript. The business object implements the presentation and data storage-independent logic of the distributed application.

The business object connects to other business objects by a message mechanism, or saves and retrieves data from a persistent data store. The persistence stores have changed little over the past few years. They are the file system, relational database and object database. The persistence mechanisms are all adding robust and scalable object semantics to business objects. An example of this is the object to relational mapping tools which are becoming generally available.

It is clear that companies and organizations are competing heavily in the architecture space. This is evident by the advances in browsers, Java, web servers, databases, transaction servers and many other pieces. The advances are happening because the new architecture solves many of the difficulties of network computing, that is, the deployment of data and behavior, security, firewall tunneling, performance and scalability. Deployment of documents is as simple as adding an HTML file to a directory and linking users to it. JavaScript, Java and ActiveX nee COM+ behavior is similarly easy to deploy to users. No more need for users or IT staff to manually install applications or documents on PCs. The term "zero-install" means that the user does not have to do any overt action to install software.

The Java and JavaScript sandboxes provide an extremely high level of security for clients. A client can be sure that their machine is safe from tampering. Clients can also be sure where an ActiveX control came from. However, they can’t be sure what the control is or isn’t doing. Another aspect of security is firewalls, which protect most corporate users and Internet sites. Firewalls already have E-mail and HTTP tunneling, and are adding tunneling for other protocols. Interestingly, most message protocols are also layering on or tunneling through HTTP – DCOM nee COM+ and IIOP are notables. Perhaps the universal application protocol will be HTTP. In fact, HTTP 1.1 can be used for much more than simple GETing web pages and Posting forms. I’m a big fan of the simple HTTP protocol, but all developers will benefit from firewalls accepting the standard message protocols.

Perhaps the biggest benefit of NC architectures comes from performance and scalability. Lightweight clients, also known as thin clients, will be widely deployed. By removing the business logic to an object on a server, clients objects can concentrate on presentation logic. The reduction in the processing load, combined with connectivity increases, means that distributed applications can have many more clients than older client/server applications, perhaps an order of magnitude more. Thin clients also means thick servers to deal with the additional computing load from each client, the increase in the number of clients and the proliferation of data. The separation of business logic from data enables compute servers to interact with data severs. The servers can be optimized for computation or for throughput, load-balanced across different machines and made fault-tolerant. This need for thick servers is one reason why companies such as IBM, Oracle and Sun are excited about network computing, and why Microsoft and Intel are moving into enterprise server software.

Vision

Well, we’ve talked about the changes happening in the industry. Now we’ll discuss the specific need for components and distributed objects. Most developers have discovered the benefits of object technology, with its three key aspects for software. These aspects are encapsulation of data by behavior, inheritance of implementation and interfaces, and polymorphic behavior. Component technologies are about providing design-time and run-time services for small to large-scale software objects. The services provided cover a wide range of functionality: object method, event and property discovery and invocation, persistence, licensing, drag-and-drop, naming, transaction support, locking and many more. Ideally, developers and users of components will be able to easily create components and wire them together to provide rich functionality. Components have traditionally been desktop or client/server based.

Distributed objects are simply objects that are distributed in space. The distributed object vision sees that components communicating easily across machine boundaries. Components can invoke methods on remote objects almost as easily as a local object method invocation. Distributed objects extend Remote Procedure Calls by allowing invocation of a method on a fine-grained object, rather than a course-grained stateless server. Many distributed object visionaries are predicting that object interfaces will become as ubiquitous as web interfaces.

There is tremendous business opportunity in distributed objects. Applications can use existing services, and even combine the services into richer applications. Imagine using a distributed object to retrieve a set of maps, another object service to filter the maps for points of interest and another object service to combine the maps together into a single feature-augmented map. Vendors can provide a wide variety of services with new business models such as pay-per-use or subscription.

The distributed object vision is an extension of the web vision. Whereas the web provides a user-centered, document-centered, course-grained, stateless worldview, distributed objects provide an application-centered, fine-grained, stateful worldview. Until now, the web has had difficulty in providing machine-readable objects that can be augmented into complex applications.

But the web is undergoing an enormous change due to the new simple yet powerful XML standard. It is my opinion that documents will now equal objects. Objects have data, behavior, and metadata extraction. With Java objects and XML, HTML pages satisfy these constraints and encapsulation. Inheritance is a more difficult quality to add, but server-side construction of pages from other pages can be considered re-use through encapsulation. As well, HTML documents and the web are a large polymorphic system, with every URL overloading the GET or POST method with a different implementation.

Where the web fails with distributed objects is the issue of local or remote transparency. In a distributed object system, the remote object method calls are the same as local object methods.

Figure 3.

A client issues a method invocation that is intercepted by a stub layer. The stub marshals the input object parameters into a transport byte stream. The Object Broker finds the Object Broker that has the remote object registered. The client-side Object Broker then passes the object ID, the method to be called, and the transport bytes to the remote Object Broker. The remote object broker plays hot potato with the information by connecting to the specified object and passing the transport bytes as quickly as possible to a skeleton for the method. The skeleton unmarshals the transport bytes into object parameters, then calls the requested method. After the method is finished, the return parameters are routed in a similar fashion to the client application.

Java

Java was originally intended as a language for developing applications for consumer electronics and embedded systems. I like to call Java "Buzzword-compliant", as it’s lightweight, rich, robust, secure, network-aware and portable. It captured everybody’s imagination, especially Microsoft’s, with its mantra of "Write Once, Run Anywhere". Ironically, while Java is being used heavily for client applications and server-side business objects, the applets are bit players in major web sites. While it hasn’t completely lived up to the expectation of a universal client language and there is considerable pressure being applied by Microsoft, Java is still the developer’s choice of language for applications, both client and server, due to the previously mentioned qualities.

Distributed Object Comparison

While proponents of competing technologies will debate the issue, the reality is that the distributed object technologies are roughly similar, with specific differences dependent upon the aim and legacy of the technology. They all provide a distributed object bus, providing for compile-time and run-time discovery and use of properties, methods and events of remote objects. Tools exist for creating and managing the components. As an example, while the Windows Registry is not a very reliable repository for object interface definitions, it is well known and standard tools are available for accessing it. They all integrate well with Java and have roughly similar performance for similar access types.

Having seen the similarities, there are many differences between the technologies.

Figure 4. Comparison

Let’s take a quick look at some of the points of interest.

• Language refers to the development language of clients and servers.
• Standard refers to the body that defines the changes to the technology. Javasoft looks to many partners for input into Java, but ultimately Javasoft determines what goes into Java and when. COM+ can be considered closed because the relationship between Microsoft and the ActiveX standards body is unclear, and it appears that Microsoft is not required to implement anything the body specifies.
• COM is generally not considered object-oriented because it is impossible to create a COM object by deriving from another COM object and re-using the implementation and interface. COM objects can re-use implementation by aggregation, but this is distinct from implementation inheritance. For what it’s worth (FWIW), Microsoft engineers have traditionally considered implementation inheritance to be a Bad Thing, as it leaves a derived class subject to the fragile base class problem.
• Interface definition refers to the mechanism for specifying an object’s remote interface. RMI uses the Remote interface, so the specification is in a Java form. CORBA uses the language independent OMG Interface Definition Language. Visigenic’s Caffeine produces OMG IDL from Java Interfaces. Microsoft has two competing and overlapping standards, the older DCE based Interface Definition Language – different from OMG’s of course - and the newer Object Definition Language.
• Unique objects refers to the ability of the object repository to contain a reference to a unique object. COM objects in the Registry are really classes as there is no unique object identifier associated with the object. COM Monikers are used to add object identity. CORBA objects get the nod as truly unique objects because objects have a unique ID; that is, the unique ID is the same across instantiations of the object.
• Ease of development is admittedly highly subjective, but there are distinct differences. RMI is the easiest from a Java perspective as the development steps are few and easy to follow. CORBA development is much simpler with caffeine, but the intricacies of ORBs, pass-by-reference semantics, and many other features can be difficult. COM+ gets a hard grade due to the difficulty in creating and invoking remotable Java objects. A confusing variety of tools with overlapping functionality are required, such as mktyplib, midl, Javatlb, JActiveX, JavaReg, dcomcfg, and manual registry entries. It is possible for Java clients to use remote Java COM+ services without accessing the client registry, but that has been difficult to get running. As well, the JavaReg utility is quite buggy.
• Scalability refers to the numbers of clients and the number of server objects supported, and is necessary for enterprise level deployment. RMI has no way of scaling the number of connections to objects or the instantiation of server objects. MTS provides scalability for COM+ components and has been available for a number of months. The merging of TP monitors and CORBA ORBs is happening, resulting in super-ORBs. Numerous products, in various stages of release, are available for Java clients and Java server objects, including IBM’s Component Broker, Transarc and Iona’s combination of Encina and OrbixWeb, BEA’s Iceberg, Gemstone/J with Visibroker, and many more.

Benchmark

Out of curiosity, I created a simple banking application using a wide variety of communication protocols. Admittedly, it’s very simplistic but the results are interesting. It was run on a single Pentium 133 NT Workstation ThinkPad. The results aren’t true tests of protocol performance because different Java Virtual Machines were used – Netscape Enterprise Server, Microsoft VM, and JDK 1.1.4. The banking application is the trivial case, where an integer amount is deposited into the bank. As mentioned before, the remote COM example was difficult to get working in Java from end to end.

Figure 5. Benchmark

Some notes about the benchmark:

A noticeable result is that connectionless protocols are roughly similar performance, with Servlets being half the speed of connectionless CORBA and RMI. As well, connection-oriented RMI and CORBA have roughly similar figures. Remote COM is expected to be similar. Surprisingly, the local machine COM and CORBA are much slower than direct procedure calls.

Caveats

There are many issues that are not addressed in the benchmark. Scalability of the application is not known. The key issues for scalability are how many connections the server must manage, and the number of objects the server must manage. The connectionless HTTP/Servlet sample probably scales the best because there are no client requirements other than a browser, and the server has no permanent connection object to handle. Imagine an app where a million clients connect during the course of a day, and that will give the reader an idea of what scalability that needs thinking about. Connectionless is very appealing for web style applications, especially ones that have all data made persistent to a back-end, such as JDBC apps.

Another issue is startup performance. RMI, COM+, and CORBA have varying levels of code that must be downloaded and/or installed on the client. A million clients downloading 20K or more of Java code (including ORB, etc.) for a simple deposit during the course of a day will cause the application to have performance of considerably worse than 50 milliseconds for an object call.

Caveat Emptor

So, as always, dear reader, you need to understand your style of application behavior. Do you have many clients running web browsers interacting lightly with a server or do you have a custom application that clients will use for 8 hours a day and which are interacting heavily with a server, etc. All that these benchmarks show is that simple object calls have no order of magnitude of performance difference within the same connection type.

Components

The final comparison is that of components. Not surprisingly, Beans and COM are very similar in many aspects yet different as well. They both have support for events, properties and persistence. Component nesting, a.k.a. Excel documents inside Word, and drag-and-drop between applications have been part of Microsoft Windows for years, first as Object Linking and Embedding (OLE), then ActiveX, now COM+ and DNA. Java added these in the JDK 1.2 release, but these will have been around for considerably less time than DNA and few apps will support them right away. Both have introspection and reflection, which are ways of discovering at design-time and run-time the behavior of the component. Both have a wide variety of tools available, although few tools support JDK 1.2 as it is so new, and Microsoft (to no surprise) owns the market of COM tools.

Figure 6. Component comparison

The biggest difference between the two, IMHO, is the security model. Java provides a way of ensuring that an application or applet does not harm the machine it is running on, as well as a code-signing mechanism to open up the machine to the applet or application. Microsoft only provides a code-signing mechanism, which ensures that a person within a company certified by a certificate authority has authored the control. It does nothing to ensure the code does what it should or shouldn’t do. And the mechanisms to revoke a granted certificate are slow, and potentially dysfunctional across international boundaries.

I believe this will lead to "Internet Ghettoes". That is, there will be good places on the net that you will trust the code from, such as Disney, Microsoft, IBM, etc. Then there will be bad places on the net that you will not trust the code from, even if it’s signed, say "Dave’s house of control horrors". The security issue is a much more important issue than Microsoft has given credit to. It reeks of small-scale client/server development; not what we need for a world of millions of connected clients. While products advertising that it protects you from hostile Java applets are absurd, the COM control protection and certification are definitely going to be valuable.

While Java is fully object-oriented, COM has not been. But COM+ will address many of the limitations that object oriented developers have faced with COM. COM+ adds many features to COM, by "embracing and extending Java": single-level implementation inheritance, virtual methods, import and package concepts via COM+ namespaces, heap allocation of variables, automatic garbage collection, naming conventions for properties and events, constructors/destructors, interfaces with static members, an object repository separate from the windows registry, and more. In fact, COM+ implementations look eerily similar to Java.

Microsoft has made a concerted effort to bring COM+ fully into the object world. Time will tell how COM+ will be deployed as COM+ is in pre-alpha state as this article heads to the presses. If Microsoft and Javasoft follow through, most of Java Beans and COM+ will be the same.

Reality check

We’ve done a comparison of the state of Java component and distributed object technologies, so it makes sense to now talk about what is missing from Java and components. The first issue is the lack of a consistent client platform. With Microsoft balking at support RMI and CORBA in their client, developers are forced to write controls to install the requisite classes in clients. And the Java implementation of client-side COM+ is not available yet. Java is still missing the run anywhere aspect so client Java code must be debugged for every client platform.

Server-side Java is much clearer, as developers can control the server. I believe that server-side Java is where most of the development effort will occur, not on the client. However, robust, high-performance, high-scalability Java VMs are still missing. In fact, Java’s built-in 32-bit memory addressing is a critical problem for Server development. The Java VM is potentially the biggest development in Operating System technology in the past decades. Operating Systems are all about giving a process an individual memory space to operate in, preventing pointer access from one program interfering with another. With no pointers, Java has done away with the need for heavyweight processes. We needed TP monitors to deal with process re-use in an OS, so Java VMs need the equivalent. Perhaps the Java VM is the "killer-app" for object servers. Finally, tools to develop server-side Java, such as integrating HTML/XML presentation templates with Java Beans business objects that use JDBC for persistence, are far away.

Recommendations

I’m not going to make any sweeping recommendations, such as "Use CORBA instead of COM/COM+ because X". It’s clear that the choice of distributed object protocols should be driven by the middleware support and client capabilities, not by the protocol itself. Client support for HTML, ORBs, COM+ and Java should be balanced by the need for transaction services, database connectivity, legacy system connectivity, HTML generation, scalability, performance and reliability.

HTML is fabulous for many needs of today’s 3-tier architectures, especially document display and forms input. The use of client-side Java 1.1, CORBA and COM completely depends upon client support. Server-side Java is completely different. Servlets, JDBC, Beans, JITS, and native compilers make Java ideal for creating business objects and connecting to other back-end systems. ORBs and COM are close to being suitable for enterprise deployment, with both standards adding high-performance, scalability and extensive object services support.

Conclusions

Component specifications and distributed object protocols are of increasing interest due to the changes taking place in the computing and communications fields. The changes have caused a new architecture to emerge. The 3-tier architecture separates presentation, business and data logic into separate layers. This enables high numbers of clients, integration with legacy systems and databases, and quick adoption of new technology. Components are built as Java Beans, COM controls, or HTML pages. They communicate using the HTTP, IIOP, RMI or COM protocols with servers. Server components can also be built up from other server components and connected together. With component and communications middleware becoming stable and standardized, other middleware services and tools for objects are becoming available – object servers, transactional objects, object-relational mapping tools, and connection managers to name a few.

The future of objects is now, with HTML, Java and COM leading the way. Application developers should be building applications from components and distributing via 3-tier architectures, allowing developers time to concentrate on the business logic. The early adoption phase is over, and organizations are now rising the adoption curve to ubiquitous development and deployment of objects.

All opinions and statements of facts are the opinions of David Orchard and do not represent IBM Corp.