Distributed Object Computing with Joe and NEO

After reading this article, you'll understand why Joe and NEO are
being accepted by a growing community of developers

You may have just heard about the new product from Sun Microsystems called Joe that interfaces Java programs to a distributed computing environment. Joe came along when NEO, the new enterprise object system, was announced by Sun in March 1996. The projected NEO line of products, including Joe, Solaris NEO, Solstice NEO, and NEO Administration Tools, will not be complete until the end of Summer 1996. With components like Joe and the Java Database Connectivity (JDBC) system, and continued announcements of software support from major vendors, Java is finally starting to shape up for full enterprise computing use.

Joe, primarily a language-level interface to NEO, is essentially Sun's implementation of the Common Object Request Brokerage Architecture (CORBA), as specified by the Object Management Group (OMG). It allows Java programmers to access data and to invoke remote object methods using a common interface.

CORBA

Before we get too intimate with the details of Joe, let's review object technology and how CORBA works. In a few simple words, CORBA allows applications to interact and communicate closely at a higher level of abstraction than just sending packets of data back and forth. The closest similarity to existing systems is the Remote Procedure Call (RPC) system found in Sun Open Network Computing (ONC). Using ONC RPC on Sun workstations and servers, a client application on one side can communicate with a server to perform the remote execution of programs and then deliver the results to the client. Although it has been ported to other systems, ONC RPC primarily works only with Sun machines. CORBA is a step up on the evolutionary ladder: Applications in a heterogeneous computing environment can interact without worries of how the two different machines and operating systems can interface.

How is this different from just TCP-based communications? Sending packets back and forth between a client and a server requires a lot of overhead processing by the application. The developer needs to create a translation of the contents of the packets before they can be processed. RPC is at a higher level, whereby each interaction is a function call with a set of parameters of predefined type.

However, ONC RPC was designed primarily for a homogenous environment like an all-Sun workstation network. DCE attempted to expand the RPC world into truly distributed computing but never quite made it to the top, due to lack of support from vendors. The CORBA specification was initially released in 1991, with a new version 2.0 released in December 1994; it is the current scheme that hopes to solve this problem.

The Object Request Broker (ORB) is a key component of this specification. It acts as the agent between a client application and the data source server application. The ORB can help the client locate and establish communications between the two end-points. Depending upon the implementation, the two end-points might even be communicating with different transport protocols with the ORB acting as a gateway between the two. Each end-point has an interface definition that all ORBs can interact with. This end-point interface is created using the Interface Definition Language (IDL) as specified by CORBA.

Most CORBA implementations in the market support versions 1.1 and 1.2 of the standard; only a handful support some of the more advanced features found in version 2.0. One important component of 2.0 is the Internet Inter-ORB Protocol (IIOP). The IIOP specification allows ORBs from different vendors to communicate on the local network or even across the Internet using the Transmision Control Protocol/Internet Protocol (TCP/IP) as the basis of data transport. It is not surprising to hear that even with a common standard, ORBs are implemented and behave differently; thus the need for IIOP. For example, until the release of an IIOP capable ORB by Sun, Joe can communicate only between applications that conform to the NEO system.

Companies such as Iona Technologies provide ORBs that can interface with other object models such as COM/DCOM that forms the basis of Microsoft's OLE and distributed OLE system. It has not been proven which is the "best" object model by far; most have specific uses. Microsoft's system works very well if you are in a Microsoft environment, of course, which synchronizes with their philosophy. Other models such as DSOM from IBM simply move the focus of execution from the desktop (in COM) to the server, which is also how CORBA works.

NEO

NEO is not an acronym for anything, or so Sun would have us believe. My guess is "Networked Enterprise Objects"; I could be wrong, it could be something "Not Entirely Obvious." In either case, NEO is the release version of Sun's former Distributed Objects Everywhere (DOE) which promises to do just that: Take the computing industry into the world of distributed object computing. With all the hoopla, you should know that Sun is by no means the first to come up with this paradigm. It has existed for quite some time. Smalltalk from Xerox PARC, for example, implemented the same concept well over a decade ago. However, Smalltalk as a language has never caught the popularity of others. NeXT Software has actually had a distributed enterprise object system for several years and would best count as the most mature of commercial distributed object environments. Beset with its own problems, NeXT has not managed to popularize this system widely. Nevertheless, other vendors recognize the importance of this concept, which is why NeXT's OpenStep has been licensed by some of the top vendors, including Sun. NEO can interface directly with OpenStep as naturally as with its own components.

NEO consists of several components: Solaris NEO, the operating system component; WorkShop NEO, the software development environment; and NEO Administration Tools, which consists of converted versions of classic Sun applications such as Solstice Manager (Sun Net Manager, to the old hats). Why would you even want to have new versions of these same packages to support NEO? Couldn't a new version just be added in as a layered product? The clear answer is no; you can certainly access current applications and systems through NEO, but each of these applications acts as a monolithic system through the eyes of the NEO client application. What you need is to create interfaces at the different levels of each product, so that they can be accessed in subsets. That would make a much more efficient system, where you use only the resources you need.

The philosophy of NEO surrounds networked objects and shared applications. It is now possible to convert an application into a networked object using the NEO Workshop tools and adding some code. You don't need to go through often tedious programming in an attempt to solve common network programming problems repeatedly to provide network communications support for your product. Instead, you can rely upon ORBs to handle some of these problems. One bright hope for NEO is in providing a level of version control at the application level, rather than at the programming level. This means that you can use and/or replace currently active components on your network which contribute to the goals of the application. For example, if you have a inventory control system that keeps track of all products kept in a warehouse for delivery, you need applications for monitoring current stock, delivery scheduling, delivery processing, stock aging, etc. If the core of the system surrounds NEO, it is possible to replace just one of these parts with revised applications to support new needs or functionality. If something seems wrong, you can quickly replace the currently active application with the previous version, without disrupting the entire process itself and affecting other parts of the inventory control system.

Joe

To the Internet world and perhaps much of the media, the most interesting component of the NEO system is Joe. With the addition of a few lines of code, you can declare a remote object, locate the object with respect to a NEO name server and then execute any of the methods of the object. There are three steps required to create a proper Joe client application: Compile the IDL interface of the remote object using the IDL-to-Java compiler; develop the Java application that will access this remote object; and compile everything with a Java compiler.

Server applications to the NEO environment can be written in any number of languages that support the CORBA and IDL specifications. This means that your Java code can execute server code written in C++, Smalltalk, and so on. Developing a Joe server is somewhat more complicated, but the process is a similar to developing other CORBA servers.

The bi-directional communications facility is the only way to do proper interaction in a client-server environment. It is well known that HTTP, the default protocol of Web servers is a poor substitute for application intercommunications due to the inefficient mechanisms employed. That is one of the reasons for the existence of Java. The NEO Event Service allows callbacks, an asynchronous notification service that send events back to the requesting client, but does not require the client to constantly poll the server for information.

Other projects

Joe is by no means the first to accomplish this level of distributed computing in Java. Several private projects such as HORB from Hirano Satoshi of the Electrotechnical Laboratory in Japan, and others on the commercial level, such as Black Widow from PostModern Computing Inc., have beaten Sun to the market. These products concentrate on connectivity to CORBA using a specific ORB communicating with others through a General Inter-ORB Protocol (GIOP) or through IIOP. And of course, there are non-Java based implementations of CORBA 2.0: Iona Technologies leads the pack with Orbix 2 on a number of different platforms (and also offers a Java implementation). On April 2, 1996, Hewlett Packard announced HP ORB Plus 2.0, a C++ level implementation.

The future of computing

Most developers claim that object-oriented computing will replace the current stage. Now that mainstream operating systems are being converted into this new format, interoperability is also gaining importance. An analogy is the existence of TCP/IP; without the core protocols like IP, TCP, and UDP, we would never have the Internet. Similarly, without CORBA, ORBs, IIOP, GIOP, et al., we may not have a future in distributed computing.

Conclusion Joe and NEO are two bright lights in the computing industry because they are the fulcrum for acceptance by a growing community of developers. With a common format through Joe, it is possible to communicate with non-Java applications, and soon non-Sun platforms, just as TCP makes it possible for different UNIX, Windows, and other systems to communicate. IIOP and other components of CORBA hold promise as the next evolutionary step in computing. By focusing on the attention paid to Java, we are now feeding a new generation of not only applications programmers, but universally distributed applications programmers.

Rawn Shah is vice president of RTD Systems & Networking Inc., a network consultancy and integrator based in Tuscon, AZ.

Learn more about this topic

Join the discussion
Be the first to comment on this article. Our Commenting Policies