line the design and prototype implementation of RMIX, as well as the two ..... some instances of the RMI protocol optimized for fast net- works, like the one used ...
Heterogeneous Access to Service-based Distributed Computing: the RMIX Approach Dawid Kurzyniec, Tomasz Wrzosek, and Vaidy Sunderam Dept. of Math and Computer Science Emory University, Atlanta, GA {dawidk,yrd,vss}@mathcs.emory.edu Abstract Service-based distributed computing as a mode of resource sharing is receiving increased attention, motivated both by enterprise applications and by standardization efforts in the grid community. In this context, significant effort is being devoted to service descriptions and related issues, primarily via Web Services and associated technologies. However, it is also critical to enable access to these services via a variety of heterogeneous transport protocols with dynamic runtime flexibility. The RMIX framework is being developed to facilitate the use of heterogeneous transport protocols for access to distributed services via a wellunderstood and semantically stable language framework, viz. remote method invocation. RMIX permits dynamic negotiation of service-access transport and the selection of the access mechanism that is most appropriate to a given clientservice relationship, while retaining a uniform invocation interface. Interoperability issues, the handling of heterogeneous transports, and preliminary experiences with RMIX are described in this paper.
1
Introduction
Heterogeneous computing has evolved over the last decade or so, and the field has matured considerably. However, heterogeneous computing has received renewed attention lately, especially as a result of the realization that computational grids are, in essence, heterogeneous distributed systems that operate across multiple administrative domains. The initial focus of grid efforts were, naturally, targeted at the most obvious issues in dealing with multiple administrative domains – viz. security (and all its associated aspects) and resource management. In the current phase of evolution, grids have overwhelmingly focused attention on the third, equally if not more important aspect of resource sharing, i.e. interoperability and standards to reconcile the
intrinsic heterogeneity that is present in distributed environments. In particular, there is a strong momentum towards service-based heterogeneous systems, standardized using Web Services [2] or extensions thereof, such as OGSA [4]. Such standards frameworks, based on XML, are used to describe service specifications in a universally understood manner, thereby permitting clients to discover and utilize services across platforms and context domains. One current drawback of this general approach, however, is the rigid coupling between a given service and the transport mechanism that is used to access it. The mechanism described in this paper addresses this issue.
Not surprisingly, and aided by that technology’s considerable maturation, Java-based heterogeneous and grid computing frameworks are receiving special attention as enablers of portability and interoperability. In Java-based distributed systems, there are three commonly used communication protocols for interaction among cooperating entities: JRMP (default RMI), IIOP (RMI-IIOP) and SOAP (JAXRPC). Standard Java RMI [22] is highly Java-specific and not very interoperable; RMI-IIOP [23] provides interoperability through CORBA, and JAX-RPC [20] provides interoperability by leveraging Web Services. In addition, there exist scientific implementations of RMI that focus on performance [10, 12, 8]. However, these solutions are mutually exclusive and do not provide any facilities for mixed usage despite their common basis in the shared RMI paradigm and programming model – one that is very natural and familiar to Java developers. In this project, we attempt to address this situation by providing a flexible framework that permits the dynamic selection of transports as appropriate to a given distributed computing scenario. In a companion paper [9], we describe the language-, programming-, and runtimeoriented aspects of our proposed framework; in this paper, we focus on issues relating to heterogeneity and interoperability with respect to the access protocols.
0-7695-1926-1/03/$17.00 (C) 2003 IEEE
Proceedings of the International Parallel and Distributed Processing Symposium (IPDPS’03)
2
Background
Our work has two main goals. The first is to define a unified, pluggable RMI framework in which access transport is selectable from a variety of protocols (those that already exist as well as those yet-to-be-defined) via a unified API and with common remote method invocation semantics. As illustrated in the Figure 1, such a unification supports interoperable and heterogeneous access to a given service from multiple clients, while simplifying development at the client and server ends. As an example, consider a Web Service accessible via multiple endpoints over various protocols, some offering maximum interoperability (e.g. SOAP) while others being optimized for specific kinds of clients (e.g. Java Remote Method Protocol, JRMP). In fact, the suite of available protocols would not have to be fixed at startup as they could be added in the run time and dynamically discovered by the application. Another benefit brought about by the unified RMI framework is improved reusability of software modules, since they are based on the remote method invocation paradigm but no longer depend on specific transport technologies. For instance, the migration from IIOP to SOAP would be much easier within the boundaries of such framework than otherwise possible; ideally, applications would use new transport protocol seamlessly via the unified API without being modified.
App RMIX RMIX RMIX JRMPX XSOAP
Java
Web Services
RMIX IIOP
CORBA
...
...
SOAP clients
Figure 1. RMIX and Interoperability
Our second goal is to enhance the RMI semantics in order to (1) give service providers more control on how remote endpoints are created, and (2) provide applications with more flexible and configurable communication substrate. In particular, the proposed export extensions include APIs enabling services to selectively export different combinations of service methods by associating endpoints with different subsets of interfaces and controlling
them via invocation interceptors, thereby permitting perclient access policies. Subsequently, in addition to blocking method invocation, the enhanced communication model supports asynchronous and one-way invocation semantics. We believe that such enhancements make RMI a more robust base technology for multi-user, heterogeneous, cooperative, loosely coupled, and geographically distributed systems. The proposed framework has been labeled “RMIX” to imply “RMI eXtended” but also to suggest “RMI MIXture”, thus emphasizing both underlying motivations: to unify various RMI protocols and to upgrade RMI communication semantics. This work is founded on the basis of authors’ experiences with the H2O project [24], that strives to provide a platform for resource sharing among independent, geographically distributed, heterogeneous peers and across administrative domains. The underlying assumption in H2O is that resources are represented by remote objects that provide services via remote method invocation or message passing semantics. However, the H2O model assumes independence and isolation between service providers and service clients, imposing strong interoperability and security requirements. Supporting endpoint customization and multiple transport protocols, RMIX provides H2O with essential abilities that cannot be otherwise fulfilled by the current Java RMI model. Experiences with H2O make us believe that the ideas presented in this paper solve real problems and bring general benefits. The remainder of this paper is organized as follows. Section 3 discusses related work. In Section 4, we briefly outline the design and prototype implementation of RMIX, as well as the two currently implemented transport protocol service providers. Preliminary performance figures, comparing these two providers to the standard Java RMI, are shown in Section 5. Finally, conclusions and future work ideas are outlined in Section 6.
3
Related Work
The RMIX project aims to embrace various RMI protocols within the boundaries of a common framework while at the same time introducing enhancements to the traditional communication model. Related projects usually focus only on selected aspects of the RMI, like communication performance [12, 10, 8], asynchronous invocation [15, 3], or interoperability [16]. Manta [10] is a native Java compiler with very efficient RMI subsystem, facilitating generation of specialized serializers based on a compile-time type information, thus minimizing run-time overhead. However, these features conflict with bytecode compatibility making code using Manta not readily portable. KaRMI [12] is a pure-Java, drop-in replacement for standard Java RMI that provides significant performance improvements especially
0-7695-1926-1/03/$17.00 (C) 2003 IEEE
Proceedings of the International Parallel and Distributed Processing Symposium (IPDPS’03)
in fast networks like Myrinet. KaRMI evolved into JavaParty [5], a very efficient tool for cluster-wide RMI computations. However, KaRMI is not interoperable with standard Java RMI nor does it support dynamic remote class loading, which limits its applicability in loosely-coupled systems. XSOAP [16] is the RMI implementation aiming to achieve interoperability by using SOAP as its transport protocol. XSOAP has been used as a basis for the RMIXXSOAP transport provider module as will be described in Section 4. To our best knowledge, RMIX is the first Java project that unifies different approaches to RMI at the level of the method invocation protocol (rather than just the underlying byte transfer protocol). Outside of the Java domain, similar properties have been independently demonstrated by the .NET Remoting Framework [13]. Pluggable formatters in .NET Remoting correspond to RMIX protocol providers, and channels serve a similar purpose to Java socket factories. Furthermore, the framework features asynchronous and one-way invocations. However, the usefulness of this relatively new technology to the research community and its applicability in heterogeneous applications is affected by restrictive licensing policies and poor support on nonWindows platforms.
4
Design and Prototype Implementation
This section briefly overviews the RMIX design and architecture, describing relations between the framework and protocol provider implementations, and outlining communication features available to application developers.
4.1
Requirements and Features
An early design decision in RMIX was to retain the base model and semantics defined by the Java RMI specification [22]. That is, remote access is realized through client-side stubs of remote objects that implement the same set of remote interfaces (i.e. interfaces that extend java.rmi.Remote and whose methods are declared to throw java.rmi.RemoteException) as their target objects. The Java RMI specification also requires all parameters to be passed by value, except for remote object references that, substituted by stubs, are passed by reference. These canonical properties are shared by most of the alternative RMI solutions as well, even if they do not literally follow other aspects of the RMI specification. Therefore, RMIX promotes these minimal properties to the level of functional requirements that must be satisfied by all protocol provider implementations. On the other hand, different RMI realizations vary significantly with respect to their serialization capabilities, depending on the underlying data encoding used. Recogniz-
ing the fact that some useful RMI/RPC protocols are based on restricted encodings (e.g. XDR [7]), RMIX avoids imposing requirements that would preclude those protocols from being embraced. For that reason, the set of types that must mandatorily be serializable by every protocol provider module is limited to: primitive types, strings, arrays of primitive types, arrays of strings, and final classes with all fields being primitives or strings that additionally have getter and setter methods (conforming to the Java bean design pattern [21]) for all of these fields that are not public. RMIX providers are also required to support serialization of any RMIX remote reference irrespective of which protocol provider created it. The latter feature is essential for runtime protocol switching. In order to support it without introducing explicit inter-provider dependencies, RMIX defines a unified remote reference format, serving as a protocol switching lingua-franca. While reference passing allows distributed applications to exchange remote references between clients and servers, a bootstrap mechanism is needed to establish first contact. RMI provides a simple naming service – the rmiregistry utility. Similarly, the notion of a naming service is used in CORBA environments. Web Services introduce a more sophisticated registration and lookup mechanism in terms of WSDL service descriptors [2], WSInspection [6] documents, UDDI registries [25] and other techniques. RMIX does not obligate transport providers to support any particular type of discovery mechanism (making the choice application-specific), except that for backwards compatibility, compliance with the rmiregistry is provided. RMIX also introduces a few semantical enhancements over standard RMI. One of the most significant is the ability for a remote object to be exported many times with different export parameters thus creating many different endpoints that can offer personalized access to the object (see Figure 2). A common usage scenario would be to publish the information about multiple endpoints within a registry service (e.g. in the form of a WSDL document) leaving clients with the choice of a remote binding. These endpoints may additionally be guarded by invocation interceptors specified by the provider of the remote object during export. In the most common case, interceptors serve as dynamic access control managers, allowing or blocking requested method invocations depending on a runtime policy and the state of a system. In addition to traditional, blocking remote method invocations, RMIX features asynchronous and one-way calls that return to the caller immediately after method parameters has been serialized. This can help improving application performance (by interleaving computation with communication) in geographically distributed applications that tend to have large communication latencies [14]. One-way
0-7695-1926-1/03/$17.00 (C) 2003 IEEE
Proceedings of the International Parallel and Distributed Processing Symposium (IPDPS’03)
Stub
Manager Access
Manage Access, Manage [SOAP]
Stub
Client
Service Access [SOAP]
Stub
Access [JRMPX]
Client
Figure 2. Customizable multiple endpoints
calls do not provide indication of completion, thus they may be implemented very efficiently by certain protocol providers. On the other hand, asynchronous calls do provide indication of completion (and potentially a return value) in the form of a future object or, optionally, a notification on a callback specified by the user. Last but not least, RMIX eliminates the need to generate stub classes. In traditional RMI, this must be done (using the rmic utility) for every remote class. Not only is the process tedious and complicated, but it also has severe disadvantages: it statically binds the user to a particular wire protocol (hardcoded into the generated stub class), and it complicates the deployment of distributed applications [19]. RMIX overcomes these issues by leveraging dynamic proxy classes [18] and featuring dynamic stubs that are silently created as needed at run time. Heterogeneity of access interfaces and transports (to a single service) is enabled by having multiple endpoints to the same remote object, but this introduces an issue when remote stubs are being compared. RMIX resolves this problem using a common identification scheme based on globally unique identifiers. Thus two RMIX stubs (even those created by different providers) pointing to the same remote object are equal in terms of equals and hashCode methods and thus may be used as keys to hash tables. RMIX also unifies the way in which different protocol providers are deployed and managed. It is a requirement for every protocol provider to be bundled in a JAR file with appropriate metadata stored in the manifest. To install a provider just requires the placement of the JAR file in a specific directory; its location controls accessibility (userwide, system-wide, or application-wide). After installation, providers become visible to applications via dynamic discovery.
4.2
JRMPX and XSOAP Providers
Currently two protocol providers are available as the part of the RMIX framework: the JRMPX provider and the
XSOAP provider. The first is a lightweight extension layered on top of the standard Java RMI and thus preserving full Java RMI semantics, namely: complete Java serialization capabilities, dynamic remote class loading, support for class annotation, and distributed garbage collection. The JRMPX transport does not depend on any non-public APIs, so it will remain compatible with future releases of the Java RMI. The second available provider is based on the XSOAP toolkit (formerly SoapRMI [16]) that uses SOAP 1.1 as its wire protocol. To adapt XSOAP to RMIX numerous changes were necessary, but as a result, both JRMPX and XSOAP providers support asynchronous invocation, multiple and customizable object endpoints, unified stub comparison semantics, and other RMIX-specific features.
5
Performance Evaluation
In order to evaluate the costs of supporting heterogeneous, dynamically selectable access to service-based resources, we conducted some basic performance experiments. Our preliminary performance tests consisted of a series of runs of benchmarks adapted from the KaRMI benchmark suite [11]. They include throughput and latency tests and two application benchmarks. The runtime platform consisted of a local network of 11 Sun Blade 1000 workstations running 64-bit Solaris 8, each equipped with two Ultra-Sparc-III 750 MHz CPUs, a 150 MHz system clock, 1GB of RAM, and a Fast Ethernet network adapter. All executable and data files were installed on a shared NFS filesystem. The Java platform used was J2SE 1.4.1 01 for Solaris/SPARC. Simple ping test results are shown in Figure 5. Each test consisted of 10000 method invocations with various arguments: (1) void, (2) null argument, (3) string argument, (4) two long arguments, (5) three long and one string argument, (6) level 0 binary tree and (7) level 3 binary tree of simple objects. As can be seen in the figure, JRMPX has an overhead of the order of 0.5-43% over standard RMI, as a side effect of marshaling/unmarshaling additional objects necessary during JRMP tunneling. However, the overhead is very small for single-arg and no-arg methods. XSOAP’s overhead varies between 1600% and 1800%. However, that is in fact not surprising and consistent with other reports [1]; the textual nature of SOAP messages is well known to incur large overheads as the price for near-total portability. Throughput tests, shown in Figures 3 and 4, involved unidirectional transmission of byte and float arrays, respectively, with increasing array sizes. In both it can be observed that JRMPX is only marginally slower than the RMI, introducing a minimal constant-time overhead with impact on throughput asymptotically approaching zero as the message size increases. It is worth noting the similarities between RMI (and JRMPX) curves across the figures indicating that
0-7695-1926-1/03/$17.00 (C) 2003 IEEE
Proceedings of the International Parallel and Distributed Processing Symposium (IPDPS’03)
2
10
5
5
throughput [MB/s]
throughput [MB/s]
2
10
2
1 5
2 -1
10
2
1 5
2
10
-1
5
5
Sun RMI RMIX, JRMPX RMIX, XSOAP
2 -2
10
2
5
3
10
2
5
10
4
2
5
5
10
2
5
10
6
2
Sun RMI RMIX, JRMPX RMIX, XSOAP
2
10
5
-2 2
5
3
10
2
message size [B]
2
10
4
2
5
5
10
2
5
10
6
2
5
message size [B]
Figure 3. Throughput results; unidirectional transmission of byte arrays
5
5
Figure 4. Throughput results; unidirectional transmission of float arrays
4
Sun RMI RMIX, JRMPX RMIX, XSOAP
Sun RMI RMIX, JRMPX RMIX, XSOAP
10
5 2
10
4
10
3
time [ms]
time [us]
5 5
2
2
10
2 5
3
10
2
5
10 5
2 2 2
10
void
null
String
2 longs 3 longs, String tree(0)
tree(7)
Figure 5. Ping tests with different arguments
encoding of float-point arrays has been improved since earlier RMI releases [12]. In comparison to the other two protocols, SOAP throughput is poorer by a factor of about 10 for byte arrays and about 40 for floating-point arrays. Byte arrays are transmitted in a more efficient manner as a result of a dedicated encoding (base64), whereas the encoding of float arrays requires separate XML elements for every array item, introducing huge overheads in terms of memory usage, processing time and message size. The last part of the performance benchmark concerned application tests (Figure 6). They were performed on 1 server and 8 clients and they solved two different textbook problems: (1) Hamming’s problem that requires many client threads to communicate with the server, and (2) an
1
Hamming
SOR
Figure 6. Application tests; Hamming’s problem and SOR
SOR application where clients communicate with the server to acquire new portions of data to work on. These tests emulate service-based computing such as that encountered in GridRPC or NetSolve, but with RMIX’s enhancement of multiple clients that use different access transports being able to communicate with the server dynamically to select a service transport protocol. The results of these tests show JRMPX overhead of up to 29% in comparison to standard RMI, whereas the corresponding XSOAP overheads approached 1700%. These experiments show that JRMPX may introduce some communication overhead in comparison to the standard RMI. This is a consequence of the underlying design choices: tunneling through standard RMI has the price of
0-7695-1926-1/03/$17.00 (C) 2003 IEEE
Proceedings of the International Parallel and Distributed Processing Symposium (IPDPS’03)
inheriting the overhead of Java object serialization supplemented by additional tunneling-related expenses. JRMPX strives to minimize the overhead with numerous optimizations for the most common cases, as reflected in the figures. For instance, in the important special case of arrays of primitive types JRMPX demonstrates performance levels almost identical to the standard RMI. In many other simple cases, the average communication overhead remains below 10%; however, it may approach 40% in the worst case. It is important to note that due to its performance characteristics, the domain of Java RMI applicability has not yet expanded to scientific applications demanding the highest communication performance possible. Therefore, we believe that JRMPX is a viable general-purpose replacement for the Java RMI in its current domain, as the flexibility and enhancements offered by the RMIX framework may often be worth the price of some extra overhead. However, our future plans include development of a transport provider implementation specifically targeted to achieve superior communication performance, possibly sacrificing some of the serialization semantics of the JRMPX. The poor performance characteristics of SOAP is a wellknown issue [1], intrinsic to its XML ancestry that affects encoding/decoding time and inflates message sizes. However, because in part of that very ancestry, SOAP has become increasingly popular in loosely coupled heterogeneous systems, both in commercial and scientific domains [17, 4, 2]. For that reason, we consider SOAP to be a crucial component of any heterogeneous, multi-protocol framework.
6
Conclusions and Future Work
In this paper, we have described the RMIX framework that provides a consistent RMI programming model over a suite of heterogeneous transport protocols. We show how the programming model is separated from the implementation of the actual protocols that are independently handled by pluggable service providers. We stress that protocols may be added to the system at any time and become immediately available to applications via dynamic, run-time discovery. We show how interoperability between different protocols is achieved, including mandatory support for rmiregistry, well defined comparison semantics between remote stubs backed by different protocol providers, and guarantees of remote stub serializability across all protocols. Additionally, we propose enhancements to the RMI model that enable customization of remote object endpoints and provide asynchronous invocation modes. We argue that the RMIX framework simplifies the development of various kinds of distributed applications, e.g. those that need to accommodate different peers over different protocols, those in which protocol independence is to be achieved, or situa-
tions in which the dynamic protocol negotiation features are desired. We analyze features and performance characteristics of the two supplied transport service providers that use JRMP and SOAP, appropriately, as the wire protocols. We are currently working on several improvements to RMIX. These include the specification of semantic conformance levels to be revealed by transport protocol service providers during dynamic discovery. This enhancement will allow us to further isolate applications from specific transport implementations even if features beyond the lowest common denominator are required. Also, the current version of RMIX does not address the problem of collaboration between independent distributed garbage collectors. For instance, if a JRMPX stub is returned from a SOAP invocation, it is currently the application’s responsibility to keep the target object alive until the stub reaches the receiver and is reconstructed there. We are presently investigating possibilities to address this issue. Finally, we are researching the issues of cancellation in the context of asynchronous RMI. This work is a part of broader initiative that includes design and specification of new protocol bindings to the WSDL language. Currently, the are few WSDL bindings defined, and none of them is appropriate for high performance heterogeneous scientific computing. The envisioned goal is to be able to export a Web or Grid Service on multiple standardized protocols described within a single WSDL document, using RMIX as a server tool to create various endpoints and as a client tool to bind to them. In addition to existing JRMPX and XSOAP service providers, we are planning to develop provider modules (and define WSDL bindings) for such protocols as RPC/XDR, IIOP/CDR, and some instances of the RMI protocol optimized for fast networks, like the one used in KaRMI. At the same time, we hope that such RMIX features as its extensible architecture, simplicity of the transport provider API, and the unified environment it presents will encourage third parties to use the framework and independently supply custom transport protocol service providers.
References [1] K. Chiu, M. Govindaraju, and R. Bramley. Investigating the limits of SOAP performance for scientific computing. In Proceedings of the 11th IEEE International Symposium on High Performance Distributed Computing, pages 246–254, Edinburgh, Scotland, 2002. Available at http: //www.extreme.indiana.edu/˜mgovinda/ research/papers/soap-hpdc2002.pdf. [2] E. Christensen, F. Curbera, G. Meredith, and S. Weerawarana. Web Services Description Language (WSDL) 1.1. http://www.w3.org/TR/wsdl/. [3] K. E. K. Falkner, P. D. Coddington, and M. J. Oudshoorn. Implementing Asynchronous Remote Method Invocation in Java. Technical Report DHPC-072,
0-7695-1926-1/03/$17.00 (C) 2003 IEEE
Proceedings of the International Parallel and Distributed Processing Symposium (IPDPS’03)
[4]
[5] [6]
[7]
[8]
[9]
[10]
[11]
[12]
[13]
[14]
[15]
[16]
1999. Available at http://www.dhpc.adelaide. edu.au/reports/072/abs-072.html. I. Foster, C. Kesselman, J. Nick, and S. Tuecke. The physiology of the Grid: An Open Grid Services Architecture for distributed systems integration, Jan. 2002. Available at http://www.globus.org/research/papers/ ogsa.pdf. B. Haumacher and M. Philippsen. JavaParty. http:// www.ipd.uka.de/JavaParty/. IBM, Microsoft. Web Services Inspection Language (WS-Inspection). http://www-106.ibm.com/ developerworks/webservices/library/ ws-wsilspec.html?dwzone=webservices. Internet Engineering Task Force. ONC Remote Procedure Call. http://www.ietf.org/html.charters/ oncrpc-charter.html. V. Krishnaswamy, D. Walther, S. Bhola, E. Bommaiah, G. Riley, B. Topol, and M. Ahamad. Efficient implementations of Java Remote Method Invocation (RMI). In 4th USENIX Conference on Object-Oriented Technologies and Systems, pages 19–36, 1998. Available at http://citeseer.nj.nec.com/ krishnaswamy98efficient.html. D. Kurzyniec, T. Wrzosek, V. Sunderam, and A. Slominski. RMIX: A multiprotocol RMI framework for Java. In 5th International Workshop on Java for Parallel and Distributed Computing, Nice, France, Apr. 2002. J. Maassen, R. van Nieuwpoort, R. Veldema, H. Bal, T. Kielmann, C. Jacobs, and R. Hofman. Efficient Java RMI for parallel programming. ACM Transactions on Programming Languages and Systems (TOPLAS), 23:747–775, Nov. 2001. Available at http://www.cs.vu.nl/˜rob/ papers/toplas2001.pdf. C. Nester, M. Philippsen, and B. Haumacher. RMI benchmark suite. Available at http://www.ipd.uka.de/ ˜hauma/KaRMI/benchmarks.html. C. Nester, M. Philippsen, and B. Haumacher. A more efficient RMI for Java. In Java Grande, pages 152–159, 1999. Available at http://citeseer.nj.nec.com/ nester99more.html. P. Obermeyer and J. Hawkins. Microsoft .NET Remoting: A technical overview. http://msdn.microsoft. com/library/default.asp?url=/library/ en-us/dndotnet/html/hawkremoting.asp. A. Plaat, H. E. Bal, R. F. Hofman, and T. Kielmann. Sensitivity of parallel applications to large differences in bandwidth and latency in two-layer interconnects. Future Generation Computer Systems, 17(6):769–782, 2001. Available at http://www.cs.vu.nl/˜kielmann/ papers/fgcs00.ps.gz. R. Raje, J. Williams, and M. Boyles. An Asynchronous Remote Method Invocation (ARMI) mechanism for Java. Concurrency: Practice and Experience, 9(11):1207–1211, Nov. 1997. Available at http://www.cs.iupui.edu/ ˜rraje/pub/rmi.ps. A. Slominski, M. Govindaraju, D. Gannon, and R. Bramley. Design of an XML based interoperable RMI system: SoapRMI C++/Java. In Proceedings of Parallel and Distributed Processing Techniques and Applications Conference, Las Vegas, NV, USA, June 2001.
[17]
[18]
[19]
[20] [21]
[22]
[23] [24]
[25]
Available at http://www.extreme.indiana.edu/ soap/rmi/design/. A. Slominski, M. Govindaraju, D. Gannon, and R. Bramley. SoapRMI events: Design and implementation. Technical Report TR549, Department of Computer Science, Indiana University, May 2001. Sun Microsystems. Dynamic proxy classes. http://java.sun.com/j2se/1.3/docs/ guide/reflection/proxy.html. Sun Microsystems. Getting started using RMI. http://java.sun.com/j2se/1.4/docs/ guide/rmi/getstart.doc.html. Sun Microsystems. Java API for XML-based RPC. http: //java.sun.com/xml/jaxrpc/. Sun Microsystems. Java Beans. http://java.sun. com/products/javabeans/docs/beans.101. pdf. Sun Microsystems. Java Remote Method Invocation specification. http://java.sun.com/products/jdk/ 1.2/docs/guide/rmi/spec/rmiTOC.doc.html. Sun Microsystems. Java RMI over IIOP. http://java. sun.com/products/rmi-iiop/. V. Sunderam and D. Kurzyniec. Lightweight self-organizing frameworks for metacomputing. In The 11th International Symposium on High Performance Distributed Computing, pages 113–122, Edinburgh, Scotland, July 2002. Universal Description, Discovery and Integration (UDDI). http://www.uddi.org.
Biographies Dawid Kurzyniec received MS degree in Computer Science from University of Mining and Metallurgy, Krak´ow, Poland in September 2000. Since November 2000, he is working as a research associate in the Department of Computer Science, Emory University. His research interests include distributed systems, security, object oriented design, and dynamic code optimization techniques. Tomasz Wrzosek received MS degree in Computer Science from University of Adam Mickiewicz, Pozna´n, Poland in July 2001. Since May 2002, he is working as a research associate in the Department of Computer Science, Emory University. His research interests include distributed systems and object oriented design. Vaidy Sunderam is a faculty member at Emory University. His research interests are in parallel and distributed processing systems and infrastructures for collaborative computing. His prior and current research efforts have focused on system architectures and implementations for heterogeneous metacomputing, including the Parallel Virtual Machine system and several other frameworks including IceT, CCF, and Harness. Professor Sunderam teaches computer science at the beginning, advanced, and graduate levels, and advises graduate theses in the area of computer systems.
0-7695-1926-1/03/$17.00 (C) 2003 IEEE
Proceedings of the International Parallel and Distributed Processing Symposium (IPDPS’03)
