- gridrpc-wg - lists.ogf.org

client code for testing interoperability
by Hidemoto Nakada 13 Jul '06

13 Jul '06

All, Yusuke provided us client source code to test the interoperability. it is now on the forge at the following URL. https://forge.gridforum.org/projects/gridrpc-wg/document/Interoperability_T… He will also upload the revised document soon. We will wait for 2 weeks for comments and will submit it to the committee. regards. -hidemoto

3 13

SAGA Documents published
by Andre Merzky 17 May '06

17 May '06

Hi folx, we proudly announce that we got 2 documents advanced in the GGF document pipeline: - the "SAGA Use Case Document" is now officially publised as GFD.70 (see http://www.ggf.org/gf/docs/?final) - the "SAGA Requierements Document" is now in 30 day public comment period (http://www.ggf.org/gf/docs/?public_comment) Thanks to the authors, and to the folx who gave feedback and input. In particular, thanks again to the use case authors!! For the requirement doc, we would very much appreciate if you would take a couple of minutes and actually comment on it. Preferably you have the time to read it, and criticise it of course. But also if you are already familiar with it, or only have time/interest for parts of it: please comment, and be it only 'agree with publication' or 'is crappy'. https://forge.gridforum.org/forum/forum.php?forum_id=613 Without any comments, the doc will NOT advance (and obviously also not improve)! So please spread the word. Thanks, Andre. PS.: please excuse the cross posting... -- "So much time, so little to do..." -- Garfield

1 0

meeting at GGF 17
by Hidemoto Nakada 15 May '06

15 May '06

All, we will have a meeting on GGF17 in 10th. The primal agenda will be reviewing a interoperability document written by Yusuke from Ninf-G and Keith from GridSolve. This will be the last step to have our specification as the formal recommendation. see you then. -hidemoto

2 2

Fwd (dk@gup.jku.at): REMINDER: AppsAreaWorkshop @ GGF17 [TOMORROW, Thursday, May 11, 09:00 G409]
by Andre Merzky 10 May '06

10 May '06

FYI, Andre. ----- Forwarded message from Dieter Kranzlmueller <dk(a)gup.jku.at> ----- > From: Dieter Kranzlmueller <dk(a)gup.jku.at> > To: Steven Newhouse <s.newhouse(a)omii.ac.uk>, Andre Merzky <merzky(a)cs.vu.nl>, > hide-nakada(a)aist.go.jp, Thilo Kielmann <kielmann(a)cs.vu.nl>, > moore(a)sdsc.edu, aoyagi(a)cc.kyushu-u.ac.jp, csmith(a)platform.com > Subject: REMINDER: AppsAreaWorkshop @ GGF17 [TOMORROW, Thursday, May 11, 09:00 G409] > Date: Wed, 10 May 2006 10:05:47 +0200 > > > Dear Speakers, > > First of all, thanks for agreeing to give a presentation at the > Applications Workshop during GGF17 tomorrow. > > Please find attached some last minute information including the below. > Please help us distribute it to the respective interested parties. > > Looking forward to an interesting workshop, > Dieter > > ---- > > GGF-17 Applications Workshop > (Tokyo, Japan) > > "Bridging the Divide: > Community Application Requirements Driving Standards Development" > > Session 1: "Current Status - Development of Standard APIs" > Chair: Steven Newhouse > > Thursday, May 11, 2006, 09:00-10:30 G409 > > * Welcome, Motivation & Goals (Steven Newhouse) [10 min] > * DRMAA - Distributed Resource Mgnt App API (Andre Merzky) [20 min] > * GridRPC - Grid Remote Procedure Call (Hidemoto Nakada) [20 min] > * SAGA - Simple API for Grid Applications (Thilo Kielmann) [20 min] > * Discussion [20 min] > > Session 2: "Consuming Standards - Current Uses and Future Requirements" > Chair: Dieter Kranzlmüller > > Thursday, May 11, 2006, 11:00-12:30 G409 > > * Summary of Session 1 and Intro to Session 2 (Dieter Kranzlmüller) [10 min] > * Astronomical Grid Community (Reagan Moore) [20 min] > * NAREGI - National Research Grid Initiative (Mutsumi Aoyagi) [20 min] > * Grid Application Integration (Chris Smith) [20 min] > * Discussion [20 min] > > Session Summary: > > This workshop will provide a showcase of standards and community activity > within GGF by bringing together groups in three different areas (Standards > Applications, Community Industry Applications & Community Research > Applications). Through a series of presentations we will show the current > state of the standards activity and critically the current barriers to > pervasive adoption as perceived by the consuming user community. Finally, a > panel session will help to define areas of collaboration and potentially new > areas for standards development. > > Session Description: > > GGF has an active standards and community areas focusing on engagement with > application developers and tool builders in research and industry. For these > separate areas to work effectively we need to build a relationship where the > APIs being developed within the standards area are relevant to the research > and industry consumers, and in turn the application and tool builders are > communicating to the standards area their requirements in terms of stable > defined interfaces. > > With the greater emphasis on GGF's redefined standards and community > functions, and the factorization of the standards area into having an > 'umbrella' research group to drive the coordinated development of a set of > consistent APIs across several working groups, there is a need to establish > the communication links between the standards and community areas for > Applications. > > This workshop, hopefully the first of many, will start to establish the > communication links and provide a showcase as to the current state of the > standards development and the current priorities for application and tool > development in industry and research. In addition, it will provide a general > dissemination mechanism of activity to developers and users (both critical > consumers in terms of achieving pervasive grid adoption) and the wider GGF > community as to activity in the standards and community areas. > > Session Leaders: > Dieter Kranzlmueller, Steven Newhouse, Thilo Kielmann, Craig Lee ----- End forwarded message ----- -- "So much time, so little to do..." -- Garfield

1 0

workshop at GGF17
by Andre Merzky 01 May '06

01 May '06

Hi GridRPC folx, I am not sure if you are aware of this (apart from Craig that is ;-), but the standards application area is organizing a workshop at GGF17: http://www.ggf.org/gf/event_schedule/index.php?id=287&tentative http://www.ggf.org/gf/event_schedule/index.php?id=325&tentative The first session is 'API to APPS', and we intend to present the GGF API efforts (DRMAA, GridRPC, SAGA) to application folx. The second session is 'APPS to API', and is supposed to gather application requirements etc. for future work of the apps area. We would very much appreciate if someone from the GridRPC group could contribute a 20 minute presentation about the current status of the API, its implementation, usage, and outlook for further work. As the target group is the application community, high level information is most appropriate I think (howeverm it is GGF, and technical folx will be present and intersted I think). Would it be possible for the RPC group to come up with a presentation along these lines? Many thanks, Andre & Co. -- "So much time, so little to do..." -- Garfield

2 4

Re: saga update... (iii)
by Andre Merzky 23 Mar '06

23 Mar '06

Ok, lets do the async call, again with an example taken from the NinfG tutorial (pi_client_multi.c, attached with changed indentation). The SAGA version, again in C++, is below: ----------------------------------------------------------- #include <saga.hpp> string func_name = "pi/pi_trial"; string config_file = "file:///client.conf"; int main (int argc, char *argv[]) { if ( argc < 3 ) { std::cout << "\n\t"; std::cout << "USAGE: " << argv[0] << " TIMES HOSTNAME\n"; std::cout << "USAGE: " << argv[0] << " TIMES HOSTNAME1 HOSTANME2...\n\n"; exit (2); } // initialize vars from CL arguments int n = argc - 2; long times = atol (argv[1]) / n; std::vector <std::string> hosts; for ( int i = 0; i < n; i++ ) { hosts[i] = (argv[i+2]); } try { std::vector <long> count; saga::task_container tc; for ( int i = 0; i < n; i++ ) { // create rpc handle saga::rpc handle (hosts[i], func_name, config_file); // perform async call saga::task t = handle.call <saga::async> (i, times, &count[i]); // add task to task container tc.add (t); } // wait tasks (for ever, for all) tc.wait (-1.0, saga::task::All); // Compute and display pi. int sum = 0; for ( i = 0; i < n; i++ ) { sum += count[i]; } std::cout << "PI = " << 4.0 * (sum / ((double) times * n))) << std::endl; } catch ( const saga::exception & e ) { std::cerr << "Found saga error: " << e.what () << std::endl; exit (2); } return (0); } ----------------------------------------------------------- I realised that I forgot the config_file argument to the handle creation in the last (synchroneous) example - it should look like above. That actually _is_ a difference to GridRPC: as the session in SAGA is not RPC specific, it makes no sense to have a RPC specific config file for a session. Hence, the config file would need to be attached to the handle creation. The example code above lives from the task container: that allows to collect multiple asynchroneous calls to be handled together. Best regards, Andre. PS.: as a side note, we do have the above form of RPC included in our saga reference implementation. However, it does not yet forward the calls to a NinfG or GridSolve adaptor. If anyone in this group has interest in connecting the reference implementation to a real GridRPC backend, please let us know :-) -- "So much time, so little to do..." -- Garfield

3 4

Fwd (pbellens@ac.upc.edu): Re: [Fwd: [saga-rg] Re: saga update... (iii)]
by Andre Merzky 22 Mar '06

22 Mar '06

Hi all, I got following forward from Rosa Badia, as an answer to the saga-rpc proposal. Pieter makes some interesting points... Cheers, Andre. ----- Forwarded message from pbellens(a)ac.upc.edu ----- > Date: Mon, 20 Mar 2006 10:47:18 +0100 > From: pbellens(a)ac.upc.edu > To: rosa.m.badia(a)bsc.es > Subject: Re: [Fwd: [saga-rg] Re: saga update... (iii)] > > #include <saga.hpp> > > string func_name = "pi/pi_trial"; > string config_file = "file:///client.conf"; > > int main (int argc, char *argv[]) > { > .. > std::vector <long> count; > saga::task_container tc; > > for ( int i = 0; i < n; i++ ) > { > // create rpc handle > saga::rpc handle (hosts[i], func_name, config_file); > > --> In Ninf-G, one creates an object handle that specifies a host and a module > name, where a module can contain anywhere from 1 to many functions. That comes > in really handy, since you can access a lot of functions with a single object > handle creation call. For the case above, you would need 100 handles to access > 100 functions. Unless you start wrapping those functions, but that s a lot of > work, and pretty ugly. The object handle/Ninf-G case is not part of the > official GRPC standard though, whereas the SAGA handle initialization does > follow the standard. Personally, i prefer Ninf-G's approach here. > > > > // perform async call > saga::task t = handle.call <saga::async> (i, times, &count[i]); > > --> Because the handles are treated different, the GRP call itself differs as > well. I don t see how they pass a callback function, though. In Ninf-G, each > asynchronous GRP call contains a callback function as an argument. > > > > // wait tasks (for ever, for all) > tc.wait (-1.0, saga::task::All); > > --> Here you wait on a function container, in Ninf-G one waits for individual > function calls. Although you can wait for several functions, by using logical > AND or OR functionality. This is an interesting feature of SAGA, although we > don t need it. > > > .. > return (0); > } > ----------------------------------------------------------- > I realised that I forgot the config_file argument to the > handle creation in the last (synchroneous) example - it > should look like above. That actually _is_ a difference to > GridRPC: as the session in SAGA is not RPC specific, it > makes no sense to have a RPC specific config file for a > session. Hence, the config file would need to be attached > to the handle creation. > > --> This makes sense. However, it would make sense to gather all configuration > files into one single file, and use that single file at runtime initialization > time, just as Ninf-G does. > > kind regards, > > pieter -- "So much time, so little to do..." -- Garfield

1 0

CFP: Grid 2006
by Hidemoto Nakada 22 Mar '06

22 Mar '06

All, here is a CFP for Grid2006 that will be held in Barcelona, co-located with the 2006 Cluster Conference. -hidemoto -------------------------------------------------------------------------a GRID 2006 Preliminar Call for Papers ==================================== GRID 2006 the 7th IEEE International Conference on Grid Computing Barcelona, 28-29 September www.grid2006.org The Grid conference series is an anual international meeting that brings together a community of researchers, developers, practitioners, and users involved with Grid technology. The objective of the meeting is to serve as both the premier conference presenting best Grid research and a forum where new concepts can be introduced and explored. The previous events in this series were: Grid 2000, Bangalore, India; Grid 2001, Denver; Grid 2002, Baltimore; Grid 2003, Phoenix; Grid 2004, Pittsburgh; and the sixth event, Grid 2005 in Seattle. All of these events have been successful in attracting high quality papers and a wide international participation. Last year's event attracted about 400 registered participants. >From the second event through the sixth, we have been known as the Grid Workshop affiliated with the Supercomputing SC conference series. For this, our seventh event, we will convene our first meeting as a conference and this year we will be co-located with the 2006 Cluster conference. The proceedings of the first three workshops were published by Springer-Verlag, and the proceedings of the three most recent workshops were published by the IEEE Computer Society Press. We expect this year's proceedings will join those of the last three years in the IEEE Computer Society's Digital Library. Grid 2006 has been labeled CoreGRID event. SCOPE ===== Grid 2006 topics of interest (in no particular order) include, but are not limited to: * Internet-based Computing Models * Applications, including eScience and eBusiness Applications * Distributed and Large-Scale Data Access and Management * Middleware and Toolkits * Monitoring, Management and Organization Tools * Resource Management and Scheduling * Networking * Virtual Instrumentation * Metadata, Ontologies, and Provenance * Creation and Management of Virtual Enterprises and Organizations * Architectures and Fabrics * Information Services * Security Issues * Programming Models, Tools, and Environments * Grid Economy * Autonomic and Utility Computing on Global Grids * Performance Evaluation and Modeling * Cluster and Grid Integration Issues * Scientific, Industrial and Social Implications Technical Papers ================ Grid 2006 invites authors to submit original and unpublished work (also not submitted elsewhere for review) reporting solid and innovative results in any aspect of grid computing and its applications. Papers should not exceed 8 single-spaced pages of text using 10-point size type on 8.5 x 11 inch paper (see IEEE author instructions, a LaTeX style sheet and Word format is available, too). All bibliographical references, tables, and figures must be included in these 8 pages. Submissions that exceed the 8-page limit will not be reviewed. Authors should submit a PDF file that will print on a PostScript printer. Submission implies the willingness of at least one of the authors to register and present the paper. Proceedings: All papers selected for this conference are peer-reviewed and will be published as a separate proceedings. After the event, the papers will also be published in the IEEE Xplore and the CS digital library. For author instructions see http://www.computer.org/cspress/instruct.htm Special Issue: The best 6 to 8 papers from the conference will be selected for journal length extension and their publication in a special issue of the Future Generation Computing Systems (FGCS). Important Dates =============== 1 March 2006 Paper submission site open 7 April 2006 Full paper submission due 14 April 2006 Last date for paper updates before review process 9 June 2006 Acceptance notification 1 July 2006 Camera-ready copy due 28-29 Sept 2006 Conference Conference Organization ======================= General co-Chairs Andrew Grimshaw, University of Virginia, USA Rosa M. Badia, Barcelona Supercomputing Center, Spain Program Chair Dennis Gannon, Indiana University, USA Program Vice Chairs Applications: Satoshi Matsuoka, Tokyo Institute of Technology, Japan Data Management: Beth Plale, Indiana University, USA Networking/Security/Infrastructure: Olle Mulmo, Center for Parallel Computers, KTH Sweeden Scheduling/Resource management: Jarek Nabrzyski, Poznan Supercomputing Center, Poland Tools/Software/Middleware: Ian Taylor, Cardiff University, UK Publicity Chair: Julita Corbalan, Universitat Politecnica de Catalunya, Spain Proceedings Chair: Rajkumar Buyya, University of Melbourne, Australia Finance Chair: Craig Lee, The Aerospace Corporation, USA Local arrangements chair: Toni Cortes, Barcelona Supercomputing Center, Spain Tutorial Chair: Salim Hariri, University of Arizona, USA Steering Committee ================== Chair: Craig Lee, Aerospace Corp., USA Mark Baker, University of Portsmouth, UK Rajkumar Buyya, University of Melbourne, Australia Wolfgang Gentzsch, D-Grid, Germany Daniel S. Katz, JPL/Caltech, USA Manish Parashar, Rutgers University, USA Heinz Stockinger, University of Vienna, Austria

1 0

Re: saga update (ii)
by Andre Merzky 18 Mar '06

18 Mar '06

Hi folx, lets do another, more complete example translation from gridrpc to saga. Todays example is the pi_client_sync.c from the NinfG documentation. The original code (changed formating) is attached as pi_client_sync.c. The SAGA version is included below. I ommited the C version this time, for brevity - please let me know if you would like the direct comparison with C, and I'll try to come up with that. ---------------------------------------------------------- /* This is sample program for Ninf-G, calculate PI on one server */ #include <saga.h> std::string func_name = "pi/pi_trial"; std::string config_file = "client.conf"; int port = 0; int main (int argc, char *argv[]) { if ( argc != 3 ) { std::cerr << "\n\tUSAGE: " << argv[0] << " <times> <hostname>\n\n"; exit (2); } long times = atol (argv[1]); string host = argv[2]; try { /* Initialize Function handle */ saga::rpc handle (host, func_name); /* Synchronous call */ long answer; handle.call (0, times, &answer); /* Compute and display pi. */ std::cout << "PI = " << 4.0 * ((double) answer / times)) << std::endl; } catch ( const saga::exception & e ) { std::cerr << "Catched saga error: " << e.what () << std::endl; exit (2); } return (0); } ---------------------------------------------------------- Don't let yourself be fooled by the shortness of the programm - that is mainly due to C++, not due to saga (although again the session initialization/destroy is done behind the scenes by default). The semantics should be exactly the same as in GridRPC. Well, thats for now, the next example should tackle a async call I guess. Again, I would be more than happy to see more realistic code examples posted by you guys :-) Cheers, Andre. -- "So much time, so little to do..." -- Garfield

1 0

Re: GGF17 sessions...
by Andre Merzky 15 Mar '06

15 Mar '06

--- please excuse the cross posting --- Hi Group_S_, we scheduled 4 sessions (one 45min, 3 90min) for GGF17 in Tokyo. Given that GGF17 is only 3 days, and that we also plan to hold a application workshop which will be somewhat SAGA centtric, you are save to assume that GGF17 will be pretty busy for us... Below are the details for the scheduled sessions. We are free to shuffle them around, and to change agenda etc. for the next 4 weeks or so (before the program gets printed). So please send us feedback/corrections/suggestions etc. Best regards, Andre + Chairs session 1 - RG - 45 min - administrativa - SAGA overview for the crowd, announce other sessions etc - sync with RPC and CPR, finalize on design teams session 2 - RG - 90 min - plan for real req. document for these design teams - work on SAGA-RPC draft - work on SAGA-CPR draft (if available) - synchronize with (and plan for future) new specs in GGF (GFS, BES, JSDL, ...) (we should READ them before GGF) - if time: start with SAGA-WG issue list session 3 - WG - 90 min - finalize req document, last comments, and submit to editor immediately (if not done before GGF) - update on issue list, close last remaining items session 4 - WG - 90 min - finish issue discussion - check API for remaining open parts - define timeline/responsibilities for finalization - define editors for cook-book - define editors and format for language bindings - update on implementations - discuss bulk optimizations (see DRMAA use case) - discuss parts of API which should be moved into the RG look-&-feel document (object, task, ...) -- "So much time, so little to do..." -- Garfield

1 0