GridSFEA has been successfully employed to gridify complex simulation scenarios. With the tools of the framework, the migration of scenarios on heterogeneous grids is made possible. With our approach, user applications can run on heterogeneous grids based on GT4, GT5, gLite, and Unicore. From the user’s point of view, the grid interaction is the same regardless the type of middleware in place. End-users of the grid benefit from high-level operations that hide the complexity of the different grids. Jobs are translated on the fly into other representations; data handling is done using GridFTP. We consider for the next step the investigation of the interoperability of GridSFEA with GridWay for providing flexible migration policies and for interactions with further middleware. This work was partly funded by the EC’ project “Infrastructure for Globus in Europe”, contract nr. 261560/21.06.2010 and the Romanian National Council of Scientific Research, contract nr. RU-RP 10/2009.
Description of the work
The development of grid applications that keep pace with the rapid evolution of the grid middleware is still a challenging task. Moreover, we face today a great effort put in the direction of the interoperability of grids, of the development and adoption of common open standards. In this context, the main objective of the GridSFEA framework is to gridify simulation scenarios stemming from different fields of computational sciences and engineering, following standards, libraries, and best practices available in the grid community. The initial target middleware was the Globus Toolkit 4, currently client-side support for GT5, Unicore, and gLite being available within GridSFEA.
The framework handles simulation scenarios on the grid, from their formulation as grid jobs, submission and monitoring of the status’ execution, attachment to jobs of tasks for post-processing simulation results, to the manipulation of simulation checkpoints and scenario data (intra- or cross-grid transfers, downloads to end-user machines). Thus, high-level operations such as parameter investigations, management of long running simulations, and preview of remote results are made available to framework’s users. Scenarios are annotated; the respective metadata is collected at runtime by application wrappers, and it is registered with the grid services of the framework. These services are WSRF-based (GT4 specific). The client tools of GridSFEA are based on the Eclipse plugin technology. The main challenges we faced were: First, the integration of client-side libraries specific to different middleware proved to be difficult from both the software engineering and the technical perspectives (e.g. conflicting third-party libraries required). Second, the JSDL requests from users/clients are mapped to specifics of the middleware, entailing considerable work, thus only a partial implementation of the JSDL spec is currently supported.
The cross-grid setup employed for this work included the grids RoGrid-NGI (gLite), DEISA (GT4, GT5), and a test grid (GT4). The WSRF-based simulation services of GridSFEA were deployed on the test grid, application wrappers and simulation codes on all sites, the client tools of GridSFEA were installed on an end-user machine located outside these grids. A limitation of our setup is the necessity of having at least one deployment of GT4 in the cross-grid that hosts our grid services. We computed fluid-structure interaction scenarios on the three grids, each job running within one site at the time. Continuation of jobs on other sites was handled by GridSFEA entirely. Thus, our prototype was capable of operating under the strict requirements of production grids the entire framework and simulation tools being present in the user space only (excepting the simulation services). With our work, users can interact with different grids in the same way, with solely knowing a subset of JSDL. In this way, the framework is a concrete example of a tool providing application-level interoperability of grids.
We evaluated community libraries such as jGlobus, GAT, SAGA, DESHL, and CREAM and integrated them to some extent in GridSFEA. By using the Eclipse plugins as enabling technology, the reuse of plugins from and by other tools such as g-Eclipse is fostered. The export of parameter studies of GridSFEA as high-level operations in the WS-VLAM tool brings benefits to further user communities. G-Eclipse is the closest to our approach, but as far as we are aware of, it lacks of operations such as migration of jobs, handling of scenarios, or simulation preview. GridWay is also capable of interacting with different middleware, but it is a middleware component and has a completely different goal, namely metascheduling.
Interoperability of grids is a major concern of the scientific community. Whereas most efforts are focused on finding solutions for middleware interoperability, we propose an approach closer to applications and end users. Our approach is based on extending the client capabilities of the grid simulation framework for engineering applications (GridSFEA), to support middleware such as Globus Toolkit (GT), Unicore, and gLite. For demonstrating the application-level interoperability we present the cross grids computations of scenarios of numerical simulations. The prototype provides high-level end-user operations such as parameter investigations, handling of large jobs, handling of remote simulation data. The tools and the programming interface of the framework act as a mediator between users&applications on one side, and grids on the other side, converting the grid interactions into operations specific to a grid middleware. Experiences are gathered on RoGrid-NGI and on DEISA.