Interoperation of Ada and Java
in Distributed Systems Using ADEPT

Anthony Gargaro, Computer Sciences Corporation
Gary Smith, Ronald J. Theriault, Richard A. Volz, and
Raymond Waldrop,Texas A&M University

The Advanced Distributed Engineering and Programming Toolset was originally developed as a tool to build distributed systems using the GNAT Ada compiler. Based on this work, the interoperation of Ada and Java using distributed or remote objects is being explored as a means to capitalize on the complimentary advantages of the two languages to develop a new generation of distributed systems.

 

The Ada community has welcomed the development of Ada 95 [1], with its enhanced object-oriented features and various annexes that extend its capabilities. In this article, we propose the ideas that the Ada community should focus on

     The first suggestion is similar to the concepts on which the Common Object Request Broker Architecture (CORBA) [2] is built. CORBA, however, has not specified the notion of toolsets for configuration. As an indication of the kind of capabilities that are possible and useful, we present a toolset to distribute the execution of Ada programs in accordance with the Distributed Systems Annex (Annex E), and describe work currently underway to extend this toolset to provide interoperability with the Java Remote Method Invocation (RMI) [3].
     The Advanced Distributed Engineering and Programming Toolset (ADEPT)1 has been designed to work with the GNU-NYU Ada Translator (GNAT) Ada compiler and is publicly available via the Internet at http://www.cs.tamu.edu/research/ADEPT. ADEPT provides both iconic-based operations to partition and configure a program and a configuration language in which partitioning and configuring can be expressed. ADEPT automatically generates calling, receiving stubs, and environments (partition main subprograms) to wrap the Ada partitions into a set of interacting programs. ADEPT also provides an automatic start-up capability to load and initiate execution on a network of processors and optional performance monitoring capabilities to collect timing measurements on remote subprogram calls.
     The emerging Java technology coupled with the increasing use of the World Wide Web offers an opportunity to significantly reduce the cost to build open distributed applications. The proliferation of platform-independent Java applets and applications—together with the application program interfaces that provide a seamless integration with existing desktop and workstation environments—will revolutionize the development of many common commercial application domains. On the other hand, for application domains that include requirements for high-integrity code, long-term maintainability, predictable real-time performance, and the incorporation of legacy code, Ada has many advantages. Thus, it is expected that future distributed computing environments may exploit the advantages of both Ada and Java. We briefly describe a concept to achieve interoperability of Ada and Java objects in a distributed system.

An Overview of ADEPT The primary goal of the ADEPT project is to provide an open, easily usable implementation of Annex E. The core ADEPT suite comprises three principal capabilities:

     The PCS is designed to be portable and reusable and is written entirely in Ada. It is connection oriented, rather than datagram oriented, so that reliable message delivery can be assumed. It can support simultaneous use of multiple network protocols and provides support that will permit the dynamic addition of partitions to executing distributed programs. Finally, it multiplexes multiple remote calls between the same two partitions over the same connection to reduce the number of connections that are used.
     The PCT provides a graphical user interface (GUI) to help the application developer partition and configure a distributed program (assign units to partitions and partitions to nodes) and build partitions into executable units. The user interface is like file management in a windows environment. One creates entities for partitions and nodes and assigns units and partitions with familiar drag-and-drop operations. A configuration language and a database supports the underlying operations. The PCT depends on the necessary support from an Ada compiler and linker—such as processing of the categorization pragmas and version attributes specified in Annex E—and creation of the calling and receiving stubs for both statically and dynamically bound remote subprogram calls. The PCT also makes several other facilities available:      An optional timing measurement package is also provided to obtain remote call timing information, i.e., duration of the call, remote processing time, network time, and time required by various parts of the PCS. Space does not permit a detailed description of the use of ADEPT. Only a brief synopsis of its use will be given here. See [4] at http://www.cs.tamu.edu/research/ADEPT for a more complete description.

Partitioning and Configuring
As discussed above, the partitioning and configuration of a distributed program are accomplished through the PCT. The user interfaces with the PCT by means of a Motif-based GUI. Ada units, partitions, processing nodes, and host classes2 are represented by icons. The user partitions and configures a distributed program mainly by manipulating the icons that represent the units involved. For example, a remote call interface (RCI) package can be assigned to a partition by "dragging" the icon representing the RCI to the partition icon.
     Icons are displayed in one of three "work windows." There are separate work windows for Ada library-level units, partitions, and nodes. In addition to the three work windows, the PCT includes a main menu bar across the top of the work windows and a text output window across the bottom. Additionally, a command input window may be created below the work windows to issue shell commands. All of the above windows comprise what is known as the ADEPT main window. An image of the main window, together with the different kinds of icons available, is shown in Figure 1.

Figure 1. An image of the ADEPT main window, together with sample icons
Figure 1. An image of the ADEPT main window, together with sample icons.

     The appearance of icons reflect various properties of the entities they represent. For instance, most icons can be either shaded or unshaded. Shaded icons contain other icons, e.g., the Ada units contained in a partition, whereas unshaded icons are "empty." Most icons can be outlined with either thick or thin lines. "Thick" icons generally represent "real" entities, whereas "thin" icons represent virtual entities. "Real" Ada units are those for which a GNAT ".ali" file is visible. "Real" partitions are those for which an executable has been successfully created. "Real" nodes are those that are visible to the underlying operating system. Icons for active partitions may also be either "single" or "stacked." A stacked icon for an active partition represents a partition that may be replicated.3 An active partition icon inside a box indicates that a version inconsistency was discovered when an attempt was made to build the partition executable.
     There are pop-up menus associated with icons, each kind of icon having its own pop-up menu. Pressing the left mouse button with the pointer over an icon will pop up the menu associated with that icon. Pop-up menus can be used for a variety of functions, as appropriate to the particular kind of icon, including

Building Partition Executables
The process of building a partition executable is moderately complicated. Segments of code must be generated, and there is considerable interaction with the compiler, binder, and linker. This has been automated by ADEPT and is invoked from the PCT. The build command is invoked by selecting the appropriate button from the pop-up menu associated with the partition. There is also a build all command that will invoke build on all partitions.
     Extensive use is made of directory structures and search orders in the build process, but this level of detail is omitted in the present discussion. Only the major functions are listed. The following steps are performed when building a partition: Ada and Java Interoperability
ADEPT was initially developed solely for the distribution of Ada programs. We have since studied methods to incorporate seamless Ada/Java interoperability within the ADEPT framework. Our approach provides for the interoperation of Java remote objects and Ada distributed objects as defined in the Java RMI specification [3] and Ada Annex E respectively. Specifically, the approach allows a Java application to call a subprogram within an Ada partition as if the subprogram were specified as a method of a remote object, and, conversely, an Ada partition can call a method within a Java application as if the method were specified as a subprogram of a distributed object. Our initial focus, however, has been on the former capability to support a distributed computing environment comprising Java clients and Ada servers.

Java Exchange Agents
The technical approach for Java/Ada interoperation is embodied in the notion of Java Exchange Agents (JxAs). A JxA provides the capability to transform a remote method call from a Java object (the client) into a corresponding remote call to a subprogram that is executed in an Ada partition (the server). It exploits the similarity in the remote object models provided by RMI and Annex E as explained in [5].
     A JxA is a collection of Java objects that typically execute as a Java application, running on a separate virtual machine from that of the Java client. This virtual machine may be physically located on the client's platform, the server's platform, or on a different platform. There may be more than one JxA available to support a distributed application; however, for the purposes of explaining the technical approach, only a single JxA is considered. The JxA is accessed as a Java server by a Java client using the RMI. The JxA, in turn, accesses an Ada server partition as a client that calls subprograms in the Ada server and uses the same remote communication tier provided by the PCS that supports Annex E for the server partition. Thus, the JxA acts in the role of a server to the Java client and as a client to the Ada server. These two roles are reconciled within the JxA using a registration scheme that allows the remote object called by the Java client to be matched with its corresponding implementation counterpart in the Ada server.
     The JxA utilizes the Java Registry to advertise Ada servers to Java clients. For each Ada distributed object that wishes to advertise that its subprograms may be called by a Java client, a valid remote access value that designates this object and the name of the corresponding distributed object must be made available to the JxA. This action is termed "posting." The actual implementation details of posting, such as any additional data that may be required by the JxA, are omitted to simplify this discussion. Unless a distributed object has been posted to the JxA, its remotely accessible subprograms cannot be called by a Java client.

Figure 2. Technical approach overview
Figure 2. Technical approach overview.

     Figure 2 depicts an overview of this approach. In this figure the Java client and Ada server agree to use N1 as the name by which the client may use a distributed object D1 created by the server. The Ada server posts the name N1 and a remote access value designating a distributed object D1 to the JxA. The JxA, in turn, dynamically creates a Java Exchange Stub (JxStub), R1, to be the actual intermediary between a Java client and the Ada object, and registers this JxStub with the Java Registry under the name N1. The client may then request a remote object that corresponds to N1. When the client is returned to the remote object reference of the JxStub object R1, it may then make a remote call using R1; this results in building a data stream and making the remote call to D1.
     The posting action to the JxA serves three purposes:

     This class implements a call compatible with the PCS that supports the Ada Annex E implementation. Supporting this latter capability is the Java Exchange PCS (JxPCS) that underlies the JxA.
     Our approach depends upon having Java classes (JxStubs), corresponding to each Ada object type, which can be dynamically created by the JxA as needed. That is, for each Ada distributed object designated by an RACW type, a Java remote interface must be created. It is through this interface that the Java client calls the subprograms of the distributed object as remote methods once a remote object has been obtained from the Java Registry. In addition to this interface, a JxStub (which implements the above interface) must be created. A translator may create them automatically from the specifications of the Ada type from which the distributed object is created.
     The rudimentary approach described above to reconcile the correspondence between a remote object and a distributed object requires that the posted and registered names be the same. Thus, the Java clients and Ada servers must establish a consistent naming convention called "static naming." Generally, one would like to be able to dynamically create objects on the Ada servers and allow Java clients to obtain references to them without having to establish a static-naming convention among the objects.
     The dynamic association can be achieved by inserting an additional level of indirection between the Ada servers and the JxA, as illustrated in Figure 3. We introduce an Ada Object Resource Manager (ORM) for each server object type, with which all of the Ada distributed objects register (in general, there may be more than one). The ORM posts itself to the JxA. The ORM has a static name, and thus the JxA can register it with the Java Registry. It is thus possible for a Java client to obtain a reference to a JxStub for the ORM and to make a remote call to the ORM. In this case, the ORM returns a RACW value for a distributed object, which has registered itself with the ORM. The JxStub for the ORM, upon receiving the RACW value, creates another JxStub for the actual Ada server object. The Java reference to this latter JxStub is returned to the client. The client may then use this remote reference indirectly via the JxStub to access the Ada distributed object.

Figure 3. Handling of dynamically created objects.
Figure 3. Handling of dynamically created objects.

     Effectively, this approach is remarkably similar to the former but places the responsibility to manage dynamic objects where it belongs: with the application developer.

Conclusions
The previous two sections have shown the kind of simple, graphical interface that can be built for the construction of distributed Ada programs and an approach to build distributed, interoperable Ada and Java programs. Although the work is not yet complete, enough has been done to suggest that the ideas are highly viable and will have considerable utility when complete.
     The generalization of these ideas is to create similar tools to enable users to readily construct distributed "programs" composed of components written in a variety of languages. To be effective, the tools must be easy to use and focus on the developer's view of the system being built, not on the implementation details. Then, Ada components can be made available and readily used without the need for the system builders to make a commitment to switch to Ada. This would provide a much easier way for them to "get their feet wet" and learn firsthand of the advantages of Ada.

About the Authors
Anthony Gargaro is a lead scientist in the Engineering Center of Computer Sciences Corporation Integrated Systems Division responsible for developing distributed systems technology. He served as an Ada 9X distinguished reviewer and as a consultant to the Ada 9X Mapping Revision Team. He has received awards from the Department of Defense and the Association for Computing Machinery for contributions to the Ada initiative.

Anthony Gargaro
Computer Sciences Corporation
304 West Route 38
Moorestown, NJ 08057-0902
Voice: 609-234-1100
Fax: 609-722-6762
E-mail: agargaro@isd.csc.com

Gary Smith is pursuing a doctorate in computer science from Texas A&M University, where he is an assistant lecturer. His interests include real-time and distributed computing and a general interest in programming language design. He has recently been involved in several distributed Ada projects.

Gary Smith
Room 330B, H. R. Bright Building
Texas A&M University
College Station, TX 77843-3112
Voice: 409-845-4456
Fax: 409-847-8578
E-mail: garys@cs.tamu.edu

Ronald J. Theriault has a bachelor's degree in physics from the University of Michigan. For several years, he developed software to analyze and display satellite data in support of upper atmospheric research. Prior to his current position as a research specialist and senior systems programmer at Texas A&M University since 1988, he was a systems programmer with the Robotics Research Laboratory at the University of Michigan. He has worked on UNIX systems administration and distributed Ada research projects for over a decade. He has been integral to the development of three generations of distributed Ada systems. Theriault is co-author of a series of papers that deal with distributed execution of Ada programs.

Ronald J. Theriault
Room 221A, H. R. Bright Building
Texas A&M University
College Station, TX 77843-3112
Voice: 409-845-1865
Fax: 409- 847-8578
E-mail: ron@cs.tamu.edu

Richard Volz is a Royce E. Wisebaker professor of engineering and department head of the computer science department at Texas A&M University. Prior to his current position, he was director of the Robotics Research Laboratory and a professor of electrical engineering and computer science at the University of Michigan. He has served on the Air Force Scientific Advisory Board, the Ada Board, the Aerospace Safety Advisory Panel—a Congressional oversight committee on NASA (continuing)—and the NASA Space Station Advisory Panel. He received the Decoration for Exceptional Civilian Service from the U.S. Air Force and the NASA Special Service Award. He is also an Institute of Electrical and Electronics Engineers fellow.

Richard A. Volz
Room 305B, H. R. Bright Building
Texas A&M University
College Station, TX 77843-3112
Voice: 409-845-8873
Fax: 409-862-4813
E-mail: volz@cs.tamu.edu

Raymond Waldrop has a bachelor's degree in mathematics and physics from Harding University and a master's degree in computer science from Texas A&M University. He is currently pursuing a doctorate in computer science at Texas A&M. His research interests include distributed computing and programming languages, with a focus on distributed Ada.

Raymond Waldrop
Room 205, H. R. Bright Building
Texas A&M University
College Station, TX 77843-3112
Voice: 409-862-2084
Fax: 409-847-8578
E-mail: rwaldrop@cs.tamu.edu

References

  1. Ada 9{X} Mapping/Revision Team, "ISO/IEC 8652:1995(E) Ada Reference Manual - Language and Standard Libraries, Version 6.0," Intermetrics, Inc., 733 Concord Ave., Cambridge, MA 02138, Dec. 21, 1994.
  2. Object Management Group - "The Common Object Request Broker: Architecture and Specification, Revision 2.0," July 1995.
  3. Sun Microsystems, Inc., "Java Remote Method Invocation Specification, Revision 1.0," 1996.
  4. Gargaro, A., G. Smith, R. Theriault, R. Volz, and R. Waldrop, "ADEPT - Ada 95 Distributed Execution and Partitioning Toolset for GNAT," Technical Report, April 1996.
  5. Gargaro, A., G. Smith, R. Theriault, R. Volz, and R. Waldrop, "Toward Interoperation of Ada and Java Using ADEPT," Technical Report, Dec. 20, 1996.
Notes
  1. ADEPT: Advanced Distributed Engineering and Programming Toolset—service mark of the Texas Engineering Experiment Station. This work was sponsored by the Computer Sciences Corporation.
  2. A host class is a set of processing nodes. Assignment of replicable partitions (see next endnote) to a host class results in replication of the partition a specified number of times.
  3. Active partitions that contain no RCI packages are said to be replicable and may be replicated on an arbitrary number of hosts.