Dice.cyfronet.pl

Eryk Ciepiela1, Joanna Kocot1, Tomasz Gubala1,3 Maciej Malawski1, Marek 1 Academic Computer Center CYFRONET, ul. Nawojki 11, 30-950 Krak´ow, Poland 2 Institute of Computer Science, AGH, al. Mickiewicza 30, 30-059, Krak´ow, Poland 3 Informatics Institute, University of Amsterdam, Kruislaan 403, 1098 SJ GridSpace Engine is the central operational unit of the ViroLab VirtualLaboratory. This specific runtime environment enables access to com-putational and data resources by coordinating execution of experimentswritten in the Ruby programming language extended with virtual lab-oratory capabilities. Experiments harness published and semanticallydescribed services which constitute a GridSpace. The GridSpace Engineis a reliable service acting as an entry point to the Virtual Laboratory,its execution capabilities and a facade for specialized services such asData Access Service. Moreover, owing to the provided dedicated li-braries, the GridSpace Engine supports interactive execution and run-time monitoring of experiments. Furthermore, the GridSpace Engineis capable of retrieving experiment source not only from file systemsbut also from multiple Application Repositories accessed by dedicatedadapters. Currently, our repository is based on the Subversion sourcecode management and version control system. The GridSpace Engineis also responsible for storing obtained experimental results in the Lab-oratory Data Base.
Keywords: e-Science, virtual laboratory, grid resources coordination,experiment repository.
Nowadays, virtual laboratories attract attention of scientists needing compu- tational power and specialized software in order to process and analyze existinghuge data sets, particularly in the field of bioinformatics. Moreover, such lab-oratories may successfully support specialists from a vast range of domains inmaking decision [1]. The aim of ViroLab [6] Virtual Laboratory [4, 5] is to pro-vide high-quality environment dedicated to create, develop, manage, and runin-silico experiments in the domain of virology.
The role of GridSpace Engine within Virtual Laboratory is to provide exper- iment execution capabilities, so it can be considered an experiment executionengine or experiment enactment engine. The idea behind the GridSpace engineis to separate the wide range of client tools assisting experiment planning [8]from the engine that actually enacts the experiments. Even more significant is that this distinction enables the GridSpace Engine to be a shared, reliableand efficient service independent of end-user machines, and as such dedicated toperform time-consuming experiments making use of grid resources. Such an ap-proach delivers the experiment execution engine as a facility for dispersed groupsof (possibly mobile) users who employ computationally intensive experiments intheir research. For them, the GridSpace Engine constitutes a remote and stableentry point to the ViroLab Virtual Laboratory.
Existing virtual laboratory solutions differ in the means of expressing exper- iments which in turn determines the way the experiment is enacted.
Projects like Kepler [10], myGrid Taverna [11] or Triana [12] use workflows to model experiments e.g. through Modeling Markup Language (MoML) usedin Kepler. Therefore, their enactment engines are provided with declarativedescription which has to be done without explicitly specifying how to do this,and such a description is often assembled using graphical tools. An alternativeapproach, also undertaken in the ViroLab Virtual Laboratory, is to use scriptsin order to express experiments in a more imperative manner. In this approachevaluation of experiments is performed by script interpreters such as Matlab inthe case of Geodise [13] project.
The other major issue is how to run such an execution engine on grid re- sources. Since GridSpace Engine is required to support interactive experiments,data streaming and monitoring of running experiments a suitable middlewaretechnology has to be employed. Globus Toolkit [14] enables stateful WSRFservices, as well as job management services, but the drawbacks are the largeoverhead of the whole toolkit and limited support for interactivity. Componentframeworks such as MOCCA [15] can also be used for dynamic deployment ofexperiment on Grid resources.
Structure and functionality of GridSpace Engine The goal of the GridSpace Engine is to combine capabilities of accessing computational and data resources, of interacting with experiment executor, andof evaluation of a “glue code” of experiment script. The experiment code, here-inafter called experiment plan, is entirely written in Ruby [16], and the capa-bilities offered by Virtual Laboratory are provided through specialized librarieswritten in this language. In this approach, the whole functionality and utilitiesof Virtual Laboratory are exposed to experiment developer and used from thelevel of experiment plan.
Since the GridSpace Engine uses the JRuby [17] implementation, pure Ruby code can access the Java programming language classes and vice versa. There-fore, some Virtual Laboratory-specific libraries are developed in Java, and can beseamlessly called form within the Ruby wrapping library. This brings into action Fig. 1: GridSpace Engine placed in an environment of ViroLab Virtual Labora-tory.
a vast range of Java-based libraries and utilities which can be easily incorporatedin the execution engine.
The most essential libraries incorporated in the GridSpace Engine are re- sponsible for access to grid resources. The Grid Operation Invoker (GOI) [2, 3]provides a library to invoke grid operations from Ruby code. Data Access Client(DAC), in turn, is a Ruby client for accessing Data Access Service [7] that inte-grates all data sources available in the Virtual Laboratory.
Besides these two, a user data input library is provided to enable experiments to interactively request the input from the user, which is especially desired in thecase of decision support experiments. Furthermore, dealing with the outcomeof experiments demands some means of streaming output of experiments and alibrary for sending results back to the user, with rendering modules on the clientside.
The GridSpace Engine, including the JRuby interpreter, is accessed via API and can be called from any Java application. In particular, considering theVirtual Laboratory, it is used by specialized tools such as the Experiment Plan-ning Environment [8] dedicated for experiments developers, and the ExperimentManagement Interface [8], which allowing experiment launching via the ViroLabPortal. Aside of these robust and complex tools, the GridSpace Engine comesalong with a simple client in a the form of command line tool.
To keep the GridSpace Engine operable in the environment of Virtual Lab- oratory, and also to keep it generic there are a number of ways of providing theexperiment plan to the engine. First of all, there is a way of programmaticallypassing the experiment plan via an API. However, to facilitate retrieving exper-iment plans from Experiment Repository a dedicated module called GridSpace Fig. 2: A common scenario of using GridSpace Engine to execute experiementplans stored in the Experiment Repository.
Engine Application Repository Client is introduced. It enables plugging of clientsfor different implementations of Experiment Repositories.
GridSpace Engine placement within the Virtual Laboratory including special- ized tools, laboratory resources and Experiment Repository is shown in Fig. 1.
A significant part of the functionality of the GridSpace Engine is to manage the session of the experiment execution. In this aspect, the engine preservesthe scope of the user context (including security credentials) enabling SingleSign On (SSO) access to grid objects, as well as experiment execution contextindispensable e.g. for the monitoring and provenance events correlation. The in-teractions between building blocks of the Virtual Laboratory which are involvedin a common usage scenario of experiment execution are depicted in Fig. 2.
The GridSpace Engine is also intended to carry out on-line monitoring of experiment course including invocation of grid operations, access to data, currentstatus of experiment plan execution, logging messages etc. These data are tobe provided both to client tools requesting and tracing execution and to themonitoring infrastructure. Thereafter, historical information can be used tofurther optimize execution through choosing the most efficient grid objects bythe GridSpace Application Optimizer (GrAppO) [9].
The current status of work (as of the end of September 2007) covers the first stable version of the GridSpace Engine implementation embeddable in aJava Virtual Machine of a client tool. Moreover, a command line tool is pro-vided allowing users to evaluate experiments locally on their own machines. This version of the engine was successfully integrated with Experiment Planning En-vironment and with a prototype of ViroLab Portal. Furthermore, GridSpaceEngine already cooperates with SVN-based [18] implementation of ExperimentRepository owing to a dedicated Application Repository Client adapter.
The GOI and DAC libraries are developed externally and independently, and have been also integrated with the engine. The libraries for handling user datainput and result management are on the very early stages of their developmentroadmaps with only simple prototypes existing for feasibility studies. Monitoringfeatures are not supported yet.
GridSpace Engine considered as an experiment enactment service combines capabilities of Virtual Laboratory building blocks such as Grid Operation In-voker, Data Access Client, Experiment Repository and a number of dedicatedlibraries. The concept, design and prototype were verified by several fully func-tional applications that make use of computational resources, data resources anduser data input library. The experiments include a Genotype to drug rankingapplication, supporting decision making by medical doctors who choose the mostsuitable drug to apply in HIV treatment.
The next step in the scope of this work will be to develop GridSpace En- gine server remotely accessible through a interoperable protocol developed forclients written in diverse technologies. Future plans also include enrichment ofGridSpace Engine with robust libraries for user data input and experiment re-sult management. It is planned as well to enable online monitoring of runningexperiments along with integration with monitoring infrastructure of the VirtualLaboratory.
Acknowledgements. This work was supported by the EU Virolab project IST-027446 with related Polish grant SPUB-M and the Foundation for Polish Sci-ence.
1. Peter M.A. Sloot, Ilkay Altintas, Marian Bubak, Charles A. Boucher: From Molecule to Man: Decision Support in Individualized E-Health IEEE ComputerSociety,vol 39, no.11, pp. 40-46, Nov., 2006 2. Tomasz Bartynski, Marian Bubak, Tomasz Gubala, Maciej Malawski: Universal Grid Client: Grid Operation Invoker Proceedings of International Conference ofParallel Processing and Applied Mathematics (PPAM’07), Gdansk, September2007, LNCS (to appear) 3. Tomasz Bartynski, Maciej Malawski, Marian Bubak: Invocation of Grid Opera- tions in the ViroLab Virtual Laboratory In Proceedings of Cracow Grid Workshop2007, this volume. 4. ViroLab Virtual Laboratory, http://virolab.cyfronet.pl 5. Tomasz Gubala, Bartosz Balis, Maciej Malawski, Marek Kasztelnik, Piotr Nowakowski, Matthias Assel, Daniel Harezlak, Tomasz Bartynski, Joanna Ko-cot, Eryk Ciepiela, Dariusz Krol, Jakub Wach, Michal Pelczar, Wlodzimierz Fu-nika, Marian Bubak: ViroLab Virtual Laboratory In Proceedings of Cracow GridWorkshop 2007, this volume. 6. ViroLab - EU IST STREP Project 027446, http://www.virolab.org7. Matthias Assel, Bettina Krammer, and Aenne Loehden: Data Access and Vir- tualization within ViroLab In Proceedings of Cracow Grid Workshop 2007, thisvolume. 8. Wlodzimierz Funika, Daniel Harezlak, Dariusz Krol, Piotr Pegiel and Marian Bubak: User Interfaces of the Virolab Virtual Laboratory In Proceedings of Cra-cow Grid Workshop 2007, this volume. 9. Maciej Malawski, Joanna Kocot, Eryk Ciepiela, Marian Bubak: Optimization of Application Execution in the ViroLab Virtual Laboratory In Proceedings ofCracow Grid Workshop 2007, this volume. 10. Ilkay Altintas, Efrat Jaeger, Kai Lin, Bertram Ludaescher, and Ashraf Memon.
A web service composition and deployment framework for scientific workflows.
ICWS, 0:814, 2004.
11. R. Stevens et.al. Exploring williams-beuren syndrome using mygrid. Bioinfor- matics, 1(20):303–310, 2004.
12. Ian Taylor, Matthew Shields, Ian Wang, and Andrew Harrison: Visual grid work- flow in Triana. Journal of Grid Computing, 3(3-4):153-169, September 2005.
13. Geodise project homepage http://www.geodise.org14. The Globus Toolkit homepage, http://www.globus.org/toolkit/15. M. Malawski, D. Kurzyniec, and V. Sunderam: MOCCA - towards a distributed CCA framework for metacomputing In Proceedings of 19th IEEE InternationalParallel and Distributed Processing Symposium (IPDPS’05) - Joint Workshop onHigh-Performance Grid Computing and High-Level Parallel Programming Mod-els - HIPS-HPGC, April 4-8, 2005, Denver, Colorado, USA, page 174a. IEEEComputer Society Press, 2005. 16. Ruby programming language home page http://www.ruby-lang.org/17. JRuby 18. Subversion version control system home page http://subversion.tigris.org/

Source: http://dice.cyfronet.pl/publications/filters/source/papers/gspacecgw07.pdf