Requirements for and Evaluation of RMI Protocols for Scientific Computing
ACM/IEEE SC 2000 Conference (SC'00)
Distributed software component architectures provide a promising approach to the problem of building large scale, scientific Grid applications  . Communication in these component architectures is based on Remote Method Invocation (RMI) protocols that allow one software component to invoke the functionality of another. Examples include Java remote method invocation (Java RMI) and the new Simple Object Access Protocol (SOAP)  . SOAP has the advantage that many programming languages
... component frameworks can support it. This paper describes experiments showing that SOAP by itself is not efficient enough for large scale scientific applications. However, when it is embedded in a multi-protocol RMI framework, SOAP can be effectively used as a universal control protocol, that can be swapped out by faster, more special purpose protocols when large data transfer speeds are needed. Because of this, the underlying communications substrate plays a more critical role than it does for commercial computing. The communication system must be capable of high-performance messaging, efficiently using specialized high-speed networks like Abilene, MREN, or ESNET when possible, using modern research protocols like quality of service and source routing, and handling parallel-to-parallel component communications. Modern communication systems are based on remote method invocation (RMI) protocols that allow an object in one address space to invoke the methods of an object in another address space. The desiderata for an effective RMI system include reliability, robustness, human accessibility, readily usable APIs in modern computer languages, interoperability across languages, platforms, and component frameworks, and integration with the emerging Grid infrastructure  and standards like COM, OMG's Corba Component Model and the DOE Common Component Architecture  specifications. Unfortunately, no single RMI system provides all of those features. The problem of designing a "universal" RMI is difficult. The format of data and the protocol used to exchange it is a determining factor in the degree of interoperability among applications. The lack of a reliable, universally understood data-exchange format has long limited effective communication between heterogenous systems. In recent months, XML  has emerged as a standard for representing data in a platform-independent way. XML is essentially a tree-oriented data representation language that is simple to generate and parse. Also, HTTP has emerged as a simple, universally supported protocol for exchanging data over the Internet. HTTP requests/replies are readily passed through firewalls and handled securely, unlike the notoriously unsafe execution of arbitrary remote procedure calls (RPC) or RMI code. Thus, moving XML data via HTTP is an attractive way for distributed applications to communicate with each other. SOAP does precisely that. By expressing RPCs independent of platforms, it opens the possibility of implementing other architecture-specific protocols in SOAP. In particular, this makes SOAP attractive as an intermediary protocol into which other protocols can be easily translated -one reason why Microsoft has targeted SOAP as an entry mechanism to the COM world  . The same feature that makes SOAP attractive causes a potential performance problem: tagged data is sent as characters. By contrast, Nexus  is designed for high-performance communications and when layered with HPC++  presents to the user a complete RMI system which can interoperate with Java  . However, Nexus has robustness problems and the failure of a global pointer can lead to complete deadlock of the distributed computation. Java RMI tends to be more robust, partly because of Java's exception and error-handling system. Java RMI is, however, a single-language protocol, and scientific computing relies on languages like Fortran90, C/C++, and Matlab as well. This paper addresses the following questions: • What is the raw performance of SOAP when used as a foundation for a RMI system? • How does SOAP performance compare with that of Java RMI and Nexus? • Where are the bottlenecks in SOAP performance? Which are removable through better implementations, and which are inherent in the protocol itself? • Can a dynamic multi-protocol system be designed that achieves the benefits of several runtime systems?