Newsletter sign-up
View all newsletters

Enterprise Java Newsletter
Stay up to date on the latest tutorials and Java community news posted on JavaWorld

Sponsored Links

Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs

JavaWorld.com

Distributed Object Computing with Joe and NEO

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

By Rawn Shah, JavaWorld.com, 06/01/96

  • Print
  • Feedback
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.

  • Print
  • Feedback

Resources