MOCCA - Towards a Distributed CCA Framework for Metacomputing Maciej Malawski∗† , Dawid Kurzyniec∗ , Vaidy Sunderam∗ ∗ Emory
University, Atlanta, USA Email: {dawidk,vss}@mathcs.emory.edu † Institute of Computer Science AGH, Krak o ´ w, Poland Email:
[email protected]
Abstract— We describe the design and implementation of MOCCA, a distributed CCA framework implemented using the H2O metacomputing system. Motivated by the quest for appropriate metasystem programming models for large scale scientific applications, MOCCA combines the advantages of component orientation with the flexible and reconfigurable H2O middleware layer. By exploiting unique capabilities in H2O, including client-provider separation, a secure hosting environment, and negotiable transport protocols, enhancements to both functionality and performance could be attained. The design and implementation of MOCCA highlights the natural match between CCA components and H2O pluglets, both in structure and invocation methodology. An outline of how native CCA modules can be supported in the MOCCA framework describes the potential for future deployment of legacy codes on metacomputing systems. We also report on preliminary experiences with test applications and sample performance measurements that favorably compare MOCCA to alternative component frameworks for tightly- and loosely-coupled metacomputing systems.
I. I NTRODUCTION The important and challenging research area of modern distributed computing requires – on the one hand – a software platform, that would allow aggregation of distributed resources and management of distributed applications, and – on the other hand – programming models, which would facilitate writing distributed applications by offering useful abstractions and tools. Among such software platforms are Grid toolkits, such as the Globus Toolkit [1], Unicore [2], Legion [3] and H2O [4]. The range of programming models includes message passing, remote procedure calls, distributed objects, service-oriented architectures, tuple spaces and component models. Since no single programming model fits all application scenarios, the need for research in this direction is still important. In this paper, we describe the design and development of a framework adapting the Common Component Architecture [5] model to the H2O platform. The CCA is a carefully designed component model that was primarily targeted for large scale scientific applications in integrated environments, such as HPC clusters. Due to its simplicity and well-defined interfaces, it can also be adapted to distributed and loosely coupled environments. Therefore, there exist CCA frameworks, where components are located in a single process or within the same cluster. On the other hand, we have frameworks with all components distributed and communicating by some RPC mechanism (e.g. SOAP).
However, in the case of metacomputing environments, we often have, at the same time, two or more levels of coupling between computing resources. In CCA terms, this means that we may have (at the same time) components running on a single machine, other components running on different nodes of the same cluster, others still in the same LAN or campus, and, finally, ones that are distributed over the Internet to various remote locations. To the best of our knowledge, no existing CCA framework can efficiently handle such a metacomputing scenario. We believe that the H2O platform can provide a solution to this problem, and that, additionally, exploiting the advantages of H2O will enable building a flexible and convenient CCA framework for metacomputing. Moreover, we observe that the CCA can serve as a convenient programming model for H2O. This paper is organized as follows. In Sec. II we provide an overview of the CCA model and frameworks, and briefly introduce the details of the H2O platform. In Sec. III we specify the goals and expected benefits of MOCCA. Sec. IV presents the details of design and implementation in the specific context of H2O, while support for multilingual components is discussed in Sec. V. Experience with applications and initial performance results are given in Sec. VI; Sec. VII contains a summary and outlines future work. II. BACKGROUND In this section we introduce the CCA model, comparing it to other programming models for metacomputing systems. Subsequently, we present the H2O framework, focusing on features that can be exploited when building a CCA framework. A. CCA as a programming model and its implementations There is no single programming model or paradigm for metacomputing systems. Some models, such as message passing, can be adapted from parallel computing. Other models are based on remote procedure calls (RPC, RMI) or distributed objects (CORBA). Service-oriented models, like Web services and WSRF [6], are adopted from commercial standards, for constructing applications from relatively loosely coupled parts. Tuple space models, like JavaSpaces or HLA [7], propose a shared space for exchanging data between application elements. Finally, there are efforts to adapt the component-based
programming model to metacomputing systems. We are going to focus on CCA as a specific example. The underpinning of component-based systems is composition of applications from software units with specified interfaces and dependencies. The components can be deployed independently and can be composed by a third party [8]. Component-based systems have gained popularity in industry, leading to standards such as EJB [9], CCM [10] (CORBA) and DCOM [11]. Scientific community also expressed their interest in using component models. There are examples of adapting CORBA for scientific applications [12] or building component frameworks based on other principles, such as active objects [13]. The Common Component Architecture (CCA) [5] aims to adapt the component model for high performance scientific computations.
Fig. 1.
CCA model of components
In CCA, interfaces that a component offers are called provides ports (see Fig. 1). Dependencies on other components are expressed by a declaration of uses ports. Each component implements a mandatory interface for obtaining a reference to the framework service, which in turn can be used to register ports that the component uses and provides. The process of composing applications in the CCA model has the following form: First, the components need to be created (instantiated) and the uses ports of component instances need to be connected to provides ports. The (virtual) container where component instances are created is often called the arena. The arena, along with components and their interconnections, can be visualized by a GUI tool. In addition, the CCA specification defines a set of standard ports e.g. the Builder port, which is a standard interface to create and connect components. It is worth noting, that the CCA allows components to be dynamically connected and disconnected at runtime. The CCA was, from the very beginning, designed to support scientific applications. Therefore, components may be parallel in nature. Component interfaces (ports) are described using SIDL (Scientific Interface Definition Language) [14], which is different from other IDLs in that it supports such datatypes as complex numbers and multidimensional arrays, which are important from the scientific applications’ point of view. The CCA does not specify if the components are to be local or distributed, thus enabling both local and distributed frameworks. One very important aspect of the component-based software model is separation of the interface definition from actual implementation of the component itself. This allows writing components in multiple programming languages and connecting multilingual components at run time in one application.
This problem is addressed in CCA by relying on the Babel [14] toolkit, which is a SIDL parser and code generator. It is coupled with a runtime library enabling the generation of bidirectional bindings and facilitating interoperability between C, C++, Fortran 77, Fortran 90, Python and Java. As the CCA specification matures, many implementations of the CCA standard, called frameworks, are being developed by the scientific community. Each of these frameworks tries to address some of the aspects of the component model. CCAFFEINE [15] is a framework based on Babel and supporting parallel components based on MPI. It has a scripting language to compose applications, as well as a GUI control tool. The components in CCAFFEINE are created within the same process, thus the inter-component communication is implemented as a local method call. XCAT [16] is a Javabased distributed framework, where components use the SOAP protocol to communicate and it aims at providing WSRF [6] compatibility. XCAT can use ssh or Globus to instantiate remote components, making it better suited for distributed environments than for high performance applications. XCAT uses Jython [17] as a scripting language to assemble applications from components. DCA [18] is a parallel framework based on MPI and its main focus is on the M xN problem, i.e. connecting components consisting of M parallel processes to components containing N ones. LegionCCA [19] is an ongoing project with the aim to create a distributed CCA framework for a Legion metacomputing system; no details are available yet. Scirun2 [20] is a project related to CCA that includes a problem solving environment with a GUI and is designed to support multiple component models. From this survey we conclude that none of the aforementioned CCA frameworks provides the efficiency and flexibility needed for metacomputing environments. Since the CCA itself as a model is well suited for metacomputing, we believe that combining it with H2O can result in a framework addressing these issues. B. Overview of the H2O platform H2O is a resource sharing platform, which aims to provide an alternative to Globus-based Grid systems. The main features of H2O are schematically presented in Fig. 2. In H2O, resource providers only need to install an H2O kernel, which serves as a basic container for deploying components, called pluglets. Remarkably important in the H2O model is the separation of the role of container providers (resource owners) from the role of software deployers. This means that a provider can offer a raw resource (CPU, storage) by setting up an H2O kernel with a specified security policy, and other parties (called deployers) can install software by deploying their pluglets into kernels. This deployment process is fully dynamic and thus convenient for the client, who is provided with a simple Java API to deploy the required software. Subsequently, the system can be accessed by users, who can utilize the deployed pluglets. The roles of providers, deployers and users can overlap; possibilities are limited only by security policies imposed by the resource owners. It is worth noting that the H2O kernel
security mechanisms prevent multiple users from interfering with one another.
Fig. 2.
Overview of H2O platform
H2O is written in Java and relies on RMIX, an efficient and extensible multiprotocol communication library, based on RMI. It offers RMI API while allowing protocol negotiation and selection of multiple underlying protocols (e.g. JRMP, SOAP, RPC). RMIX can be used equally well for LAN connections, demanding efficiency, and in widely-distributed environments, focusing on interoperability. Nevertheless, H2O does not mandate the use of RMI as a programming model and Java as a programming language. These features, and additional ones, such as remote file staging, are used as basic building blocks to enable higher-level programming models. Currently implemented models include PVM, MPI [21] and OGSA Web services [22]. There is also ongoing work to integrate H2O with the JXTA [23] peer-to-peer framework. III. O BJECTIVES AND APPROACH The aim of our work is to design and implement a CCAbased framework for the H2O platform. The framework should fulfill the following goals: • Provide easy mechanisms for creation of components on distributed shared resources; • Provide efficient communication mechanisms; • Allow flexible configuration of components and various application scenarios; • Support native components, i.e. components written in non-Java programming languages and compiled for specific architectures. As outlined before, the H2O platform possesses several features that can become strong benefits for the distributed CCA framework. Here we enumerate these features: • H2O enables dynamic installation of software components on shared resources by deploying pluglets in H2O kernels. Such a mechanism will allow easy and dynamic creation of CCA component instances on distributed sites. • H2O uses RMIX as an efficient communication layer. Since the CCA ports communicate in an RPC style, RMIX is well suited to connecting remote ports. When the components are running on the same machine, it
is possible to exploit this locality instead of using the network for communication. • H2O allows multiple usage scenarios and component configurations, which can be directly exploited in the CCA framework: H2O enables separating the resource provider from the deployer of the component, by facilitating deployment of component code on shared resources. Although many users may deploy their components in one H2O kernel, they do not interfere with one another owing to the H2O security mechanisms. Thus, users can create their own distributed arenas on overlapping sets of resources in a secure way and exploiting the locality where possible. Also, H2O allows to separate roles of component deployer and the user. For instance, third party reseller may deploy stateless component as a persistent service, allowing users to connect to its ports and communicate with it. Placement of deployed components may be controlled by the user, or it may be left to automatic load balancing tools. • If required, it will be possible enable compatibility with Web services (as it is the case with XCAT) by reusing mechanisms of the Web service pluglet [22]. All these features imply that the H2O platform, through its component foundations and orientation on metacomputing, has sufficient capabilities to provide the foundation for a powerful and efficient CCA-based metacomputing framework. IV. D ESIGN AND PROTOTYPE IMPLEMENTATION OF MOCCA Below, we present the design choices for our CCA framework, resulting from the requirements and from specific H2O features. Firstly, it was decided to have one-to-one mapping between a CCA component and an H2O pluglet. This design choice makes the deployment of a component in the framework as easy as the deployment of a pluglet. Moreover, we can take advantage of the fact that in H2O each pluglet operates in a secure execution environment. This is achieved by the H2O kernel that uses separate Java class loaders for different pluglets, and adapts Java security mechanisms to define and enforce protection boundaries. Thus, placing each CCA component instance in a separate pluglet enables secure operation of many such instances on a shared resource. Even multiple different versions of the same component can run at the same time. The challenge related to enclosing components in pluglets is that it makes exploiting the locality more difficult. Method calls between components in the same kernel are, by default, executed as remote calls. However, RMIX allows applications to switch to a local binding (utilizing shared address space), subject to access control policies. Since such approach compromises component isolation, the choice of strategy is left up to the application composer. The second issue is the remote communication mechanism. It would be convenient to design CCA Port interfaces as RMIX remote Java interfaces (java.rmi.Remote). However, the Java bindings to SIDL interfaces defined in Babel impose
Fig. 3.
Deploying components as H2O pluglets
a specific inheritance hierarchy. Thus, it is not possible to straightforwardly turn them into RMI-compliant remote interfaces. Our solution to this problem relies on introduction of an intermediate layer which translates invocations of CCAbased interfaces to RMI remote interfaces. At the client-side (uses port), this layer is represented by a dynamic proxy. The server-side (provides port) exposes a remote interface of the MOCCA Pluglet, which includes the invoke() method. This method delegates to a call of the CCA-compliant provides port implementation, thus making the intermediate layer fully transparent to both component developers and users. In the case of a distributed CCA framework, it is necessary to decide how the CCA BuilderService port is designed. The Builder is a main interface that the framework exposes to the user and it allows creating component instances, connecting them and querying their state. In MOCCA we have decided to create a hierarchical builder system. MoccaBuilder is a pluglet which can create new components and manage them within the kernel it is deployed in (see Fig. 3). In order to create components in many different kernels, it is necessary to deploy Builders in each kernel first. To minimize the distributed state, information about connections is kept in components that use ports provided by other components. Clients can build their own distributed component arenas by using several Builder pluglets deployed in different H2O kernels. Due to H2O kernel security mechanisms, many different users can deploy their own Builders to the same kernel at the same time and create their own component arenas, without interfering with one another, as shown in Fig. 4. Overlapping arenas can also be created, e.g. when collaboration between different groups working on the same project is required. To facilitate usage of the system by individual users, who need to quickly compose applications consisting of some components and instantiate them on kernels which they have access to, we introduced an additional builder service. MainBuilder constitutes an entry point for the client, providing a simple API to deploy new Builder pluglets and the standard builder
API to compose CCA applications. MainBuilder forwards creation and connection requests to the appropriate builders (see Fig. 4). It is possible to give the user full control over the placement of newly created components. Alternatively, MainBuilder may support pluggable load balancers which would automate component placement based on some optimization criteria. This issue, however, is out of the scope of our current work. One design issue, which has been resolved in an almost automatic way, involved the nature of ComponentID, which is used by the CCA framework as a unique identifier of the component. We have decided to use the H2O pluglet URI for this purpose. This URI can be passed from one kernel to another and, given this URI, the client (e.g. the component initiating the interaction) can invoke a remote method on the pluglet (e.g. a method of a provided port). By exploiting the hierarchical composition of H2O pluglet URIs, we can easily decompose them into a kernel part, a builder part and a component part (e.g. http://my.kernel/mybuilder/mycomponent facilitating management of framework components. In order to use the framework, it is necessary to have clear and convenient user interfaces allowing the building of applications by deploying components and connecting their ports. The first interface to our framework is the MainBuilder Java interface, which implements the CCA Builder service port. Framework-specific information, such as the location of H2O kernels where the component is to be deployed, is passed in the properties, making this interface fully CCA-compliant. In addition to the Java interface, we offer a Jython scripting interface, similar to that found in XCAT. Jython [17] is a Javabased implementation of the Python language and it allows interacting with Java objects nearly in the same way as with regular Python objects. Consequently, our MainBuilder API is also accessible from a Python script. Such scripts have the obvious advantage of being interpreted, which means they don’t have to be recompiled following each modification. Moreover, it is possible to use the interpreter to interactively communicate with the framework, which makes development and prototyping of component applications very convenient. No GUI tool has been developed yet, but as the BuilderService is a standardized port in CCA, we are planning to adapt a GUI from the CCAFFEINE framework, once the need arises. V. S UPPORT FOR NATIVE COMPONENTS We believe that support for native components is crucial for any metacomputing platform. Generations of programmers have produced millions of lines of legacy code written in Fortran or C. Today, these languages and many others are still used, for convenience, performance, compatibility or other reasons. It is well recognized that multi-language interoperability is difficult in the general case, and would require manual or semi-automatic generation of wrappers or adapters. However, for a specific programming model, with specific constraints and with well-defined APIs, this goal is easier to achieve. One example is MPI, where, on the one hand, Java wrappers exist, and, on the other, it has been possible
Fig. 4.
Multiple users can use the same resources
to adapt the C- or Fortran-based FT-MPI library for the H2O platform. H2O is used to spawn distributed MPI applications on multiple shared resources. Similarly, the CCA model with constraints imposed by SIDL and with standard mechanisms of connecting component ports makes language interoperability possible. The natural solution for the CCA framework is to use the capabilities that Babel offers. This basically involves writing a component implementation in any supported language (C, C++, Fortran 77 or 90, Java, Python) in conformance with the SIDL interface definition. Subsequently, the component may be shipped as a dynamically-loaded .so library file accompanied by its SIDL interface definition, and the framework should be able to load it and connect it to other components. To achieve interoperability, Babel defines its internal object representation (IOR) which is a structure of function pointers written in C. Each language binding creates a stub and skeleton code (automatically generated from SIDL), to allow interaction of the specific language program with the IOR. In the case of Java, the Java Native Interface (JNI) is used. The Babel runtime library is responsible for assigning all function pointers from the IOR to appropriate implementations of methods in a given language binding. Babel makes this work in the case of a single process, however the issue is more complex in a distributed framework, which requires remote invocations of port methods. In order to insert remote communication between the uses and provides ports of CCA components, it is necessary to add remote invocation capabilities to Babel objects. In case of H2O, where transport is based on the RMIX, the key layer is the Java binding offered by Babel. Currently, we are considering two approaches. The first one involves dynamic and transparent creation of a Java binding for an existing native component at run time, given its code (as a dynamically loaded library) and the SIDL description. This would be the most elegant solution, but it would also require generating some executable native code at run time, which may be dependent on specific platforms and compilers. The second approach is not as transparent, since it requires one step of static preprocessing before a component can be used in the framework. This step
makes use of Babel to generate Java bindings to a given SIDL interface, and then generates additional wrapping code translating CCA port invocations to remote RMIX calls on the user side, and vice versa on the provider side. The generated wrappers, after compilation, are ready to be shipped together with the component implementation code and deployed in the framework. The H2O already supports staging of files when deploying pluglets, so this mechanism can be used for loading native libraries into H2O kernels. We are currently weighting the advantages of both approaches. We expect to provide more details on this issue in the final version of our paper. VI. T EST APPLICATIONS AND PERFORMANCE OF THE PROTOTYPE
Our current implementation, which we call MOCCA Light, supports only Java-based components. It is compliant with the CCA specification at the level comparable to the XCAT. Most of the CCA specification has been implemented, with only some auxiliary interfaces (such as port properties) still left pending. We performed initial tests that aimed at accomplishing two objectives: first, to check how convenient it is to use the framework, and second, to measure the performance of the remote port invocations using the RMIX transport. A. Application Flow Composer as a Java example Since there aren’t many CCA components written in Java, except some of the examples from XCAT, we have decided to use an Automatic Flow Composer (AFC) [24] as a test example, taking into account our previous experiences with that application. AFC is a system that was initially designed and developed for the XCAT framework. Its goal was to automatically compose the description of an application workflow. This description is an XML document which contains the definitions of components, their ports and connections between them. It is supplied to a tool (the workflow engine) that automatically creates component instances with appropriate connections and executes the resulting application within the framework. The AFC is able to automatically generate
complete workflow description(s) given some initial and final constraints on the components involved plus access to a registry containing the list of available component descriptions. Current research of the authors of AFC is focused on exploiting the semantic description of components for more accurate matchmaking, and supporting workflows built from services.
Fig. 5.
Flow composition example.
Following this short introduction to AFC, we will now describe our experience with porting and executing it on MOCCA. The AFC consists of five components connected together, as seen in Fig. 5. The initial component, called Optimizer, selects the best workflow descriptions of those generated by the Composer component. The Optimizer uses two additional monitoring components, one for evaluating the performance of remote sites where components may be instantiated, and another for estimating the quality of their Internet connections. In this test, performance data was not relevant, so the evaluator components produced their answers basing on artificial pre-generated data. We have concluded that the migration of AFC from XCAT to MOCCA was an easy task. This is because both frameworks are CCA-compliant, with only minor departures which required only slight code modification. Setting up an application on remote sites in the case of XCAT requires either ssh interactive access (with public key authentication) or the Globus GRAM. In the case of MOCCA, it suffices to have access to the H2O kernel. The deployment of component code is then fully automated – the user only needs to specify the location of the JAR component file. The performance of AFC in both frameworks was similar, due to the fact that the test application is not communication-intensive, and also the data which is sent between the components consists of XML documents containing component and workflow descriptions. Thus, no advantage was observed in choosing RMIX over XSOAP. B. Communication-intensive application To measure the performance of the invocations of methods on CCA ports in MOCCA, we conducted a test on a very simplified communication-intensive application, modeling real
scientific computation. The application consisted of two components: a model of a computation engine (such as FFT), performing calculations on an array of double numbers and returning the modified array as a result, and a client component utilizing the engine. We tested two configurations of components, for differing network connections. The first testbed consisted of two machines, a workstation in Atlanta, USA, and a node of a cluster located in Krakow, Poland, so that the communication utilized regular transatlantic Internet links. The second testbed was built of two 2.6GHz Pentium4 PCs connected by a Gigabit Ethernet LAN. On both testbeds, we measured the roundtrip time for different packet sizes. Fig. 6 and Fig. 7 show the results obtained in both networks by MOCCA and XCAT frameworks. In the former figure, the results for small packet sizes are presented in the form of the roundtrip time. In this experiment, the network latency turns out to be a major bottleneck. Nevertheless, XCAT introduces a significant additional overhead, attributable to the size of SOAP headers, outweighing the payload, as well as time needed to open the connection. In MOCCA, this overhead was much smaller owing to more efficient protocols used by RMIX. The latter two plots illustrate throughput achieved for large data packets. On the wide area connection, where the network bandwidth is a bottleneck, MOCCA performs about 30% faster than XCAT due to more compact data encoding (binary versus Base64). In the case of the Gigabit LAN, we observed CPU saturation, indicating that the problem became computation-bound. MOCCA was able to exploit approximately 25% of the theoretically-available bandwidth, which we consider a promising result. XCAT performed very poorly, utilizing only about 1.7% of the available bandwidth The plots also show the standard deviation which was computed on the basis of 10 runs of the same test. In the case of the transatlantic network, the uncertainty was caused by the multiplicity of users sharing the connection; the results, however, were reproducible at different times of the day. In the case of the Gigabit Ethernet, we observed significant variations of throughput for certain message sizes. We have been able to attribute these artifacts to the asynchronous Java garbage collection, interfering with our measurements. The results shown in the figure were obtained with SUN J2SDK 1.4 running in server mode and with incremental garbage collection turned on. Having understood most of the factors leading to the overhead and variance, we conclude from our tests that the performance of RMIX-based MOCCA is promising not only for widely-distributed, but also for more tightly coupled applications. VII. S UMMARY AND FUTURE WORK In this paper, we presented MOCCA, a CCA framework based on H2O metacomputing platform. We described the advantages of H2O and how they can be exploited in building the CCA framework. The benefits include the flexibility of deployment and usage of components on shared resources, the various multi-user scenarios and the efficient performance
1.2
0.02 MOCCA XCAT
0.016
Round trip time (sec)
Round trip time (sec)
1
MOCCA XCAT
0.018
0.8 0.6 0.4
0.014 0.012 0.01 0.008 0.006 0.004
0.2
0.002 0 0.01
0.1
1
0 0.01
10
0.1
Packet size (kBytes)
(a) Transatlantic Internet connection Fig. 6.
Roundtrip time measured for invocations between components.
35 MOCCA XCAT
MOCCA XCAT
30
0.16
Throughput (MBytes/sec)
Throughput (MBytes/sec)
10
(b) Gigabit Ethernet connection
0.2 0.18
0.14 0.12 0.1 0.08 0.06 0.04
25 20 15 10 5
0.02 0
1
Packet size (kBytes)
1
10
100
1000
10000
Packet size (kBytes)
(a) Transatlantic Internet connection Fig. 7.
0
1
10
100
1000
10000
Packet size (kBytes)
(b) Gigabit Ethernet connection
Throughput measured for invocations between components.
resulting from RMIX in both wide area and fast local networks. Support for native components, which we are currently addressing, was outlined as well. A significant part of the implementation is already complete and initial results are promising in terms of flexibility, performance and user convenience. Future work includes dynamic reconnection of components at runtime and automatic optimization of the resource selection process, to make component applications more adaptive and fault-tolerant. Additionally, there is a broad area of research in the field of workflow model programming, and we hope it will become possible to use MOCCA as a workflow platform. The dynamic nature of CCA and H2O coupled together can be of high importance and value for higher level problem solving environments.
ACKNOWLEDGMENTS The authors would like to thank Marian Bubak for his advice, Tomasz Gubała for consultations, and Piotr Nowakowski for his comments. This work was partially supported by U.S. DoE Grant DE-FG02-02ER25537, NSF grant ACI-0220183, and by Emerson Center for Scientific Computation in Atlanta. R EFERENCES [1] (2004) The Globus Alliance Website. [Online]. Available: http: //www.globus.org/ [2] (2004) Unicore Forum. [Online]. Available: http://www.unicore.org/ [3] A. Natrajan, A. Nguyen-Tuong, H. Humphrey, M. Herrick, B. P. Clarke, and A. S. Grimshaw, “The Legion Grid Portal,” Concurrency and Computation: Practice and Experience, vol. 14, no. 13–15, pp. 1365– 1394, Nov./Dec. 2002. [4] D. Kurzyniec, T. Wrzosek, D. Drzewiecki, and V. S. Sunderam, “Towards Self-Organizing Distributed Computing Frameworks: The H2O Approach,” Parallel Processing Letters, vol. 13, no. 2, pp. 273–290, 2003.
[5] (2004) The Common Component Architecture Forum. [Online]. Available: http://www.cca-forum.org/ [6] (2004) The WS-Resource Framework. [Online]. Available: http: //www.globus.org/wsrf [7] (2004) IEEE Standard for Modeling and Simulation (M&S) High Level Architecture (HLA). [Online]. Available: http://standards.ieee. org/catalog/olis/compsim.html [8] C. Szyperski, Component Software: Beyond Object-Oriented Programming. Addison-Wesley, 1999. [9] Enterprise JavaBeans technology. [Online]. Available: http://java.sun. com/products/ejb/ [10] (2002) CORBA Component Model, v3.0. Object Management Group, Inc. [Online]. Available: http://www.omg.org/technology/documents/ formal/components.htm [11] (2004) COM: Component Object Model Technologies. Microsoft Corporation. [Online]. Available: http://www.microsoft.com/com/default.mspx [12] S. Lacour, C. Perez, and T. Priol, “Deploying CORBA components on a computational grid: General principles and early experiments using the Globus toolkit,” in Component Deployment: Second International Working Conference, CD 2004, Edinburgh, UK, May 20-21, 2004. Proceedings, ser. LNCS, W. Emmerich and A. L. Wolf, Eds., vol. 3083. Springer-Verlag, 2004, pp. 35 – 49. [13] F. Baude, D. Caromel, and M. Morel, “From distributed objects to hierarchical grid components,” in International Symposium on Distributed Objects and Applications (DOA), Catania, Sicily, Italy, 3-7 November, ser. LNCS, vol. 2888. Springer-Verlag, 2003, pp. 1226 – 1242. [14] S. R. Kohn, G. Kumfert, J. F. Painterand, and C. J. Ribbens, “Divorcing Language Dependencies from a Scientific Software Library,” in Proceedings of the Tenth SIAM Conference on Parallel Processing for Scientific Computing. Portsmouth, Virginia, USA: SIAM, Mar. 2001. [15] B. A. Allan, R. C. Armstrong, A. P. Wolfe, J. Ray, D. E. Bernholdt, and J. A. Kohl, “The CCA core specification in a distributed memory SPMD framework,” Concurrency Computat., vol. 14, pp. 1–23, 2002. [16] S. Krishnan and D. Gannon, “XCAT3: A Framework for CCA Components as OGSA Services,” in Proc. International Workshop on High-Level Parallel Programming Models and Supportive Environments (HIPS 2004), Santa Fe, New Mexico, USA, Apr. 2004, pp. 90–97. [17] (2004) The Jython Website. [Online]. Available: http://www.jython.org/ [18] F. Bertrand and R. Bramley, “DCA: A Distributed CCA Framework Based on MPI,” in Proc. International Workshop on High-Level Parallel Programming Models and Supportive Environments (HIPS 2004), Santa Fe, New Mexico, USA, Apr. 2004, pp. 80–89. [19] H. B. M. Govindaraju and M. J. Lewis, “Design of Distributed Component Frameworks for Computational Grids,” in Proceedings of the International Conference on Communications in Computing (CIC), June 2004, pp. 160–166. [20] K. Zhang, K. Damevski, V. Venkatachalapathy, and S. G. Parker, “SCIRun2: A CCA Framework for High Performance Computing,” in Proc. International Workshop on High-Level Parallel Programming Models and Supportive Environments (HIPS 2004), Santa Fe, New Mexico, USA, Apr. 2004, pp. 72–79. [21] P. Hwang, D. Kurzyniec, and V. Sunderam, “Heterogeneous parallel computing across multidomain clusters,” in Proceedings of 11th European PVM/MPI Users’ Group Meeting, Budapest, Hungary September 19-22, 2004, ser. LNCS. Springer-Verlag, 2004. [22] G. Stuer, V. S. Sunderam, and J. Broeckhove, “Towards OGSA Compatibility in Alternative Metacomputing Frameworks,” in Computational Science - ICCS 2004. 4th International Conference, Krako´ w, Poland, June 2004, Part I, ser. LNCS, M. Bubak, G. D. van Albada, P. M. A. Sloot, and J. J. Dongarra, Eds., vol. 3036. Springer Verlag, 2004, pp. 51–58. [23] (2004) The JXTA Project. [Online]. Available: http://www.jxta.org/ [24] M. Bubak, K. G´orka, T. Gubała, M. Malawski, and K. Zaja¸c, “Component-based system for grid application workflow composition,” in Proceedings of Recent Advances in Parallel Virtual Machin and Message Passing Interface, 10-th European PVM/MPI User’s Group Meeeting, Venice, Italy, Sep.29-Oct.2 2003, J. Dongara, D. Laforenza, and S. Orlando, Eds., 2003, pp. 611–618.
