[GRIDRPC-WG] Fwd: OGF applications group page

[Hidemoto Nakada]

Joel and Guy,

thank you for your hard work for OGF34.

we (GridRPC WG) thought that we requested GridRPC group session
on Tuesday by the attached e-mail, but it did not appear in the schedule.

Could you please add it on the schedule? Fortunately,
Tuesday morning, which is convenient for us, seminar room seems
to be available.

thank you in advance.

--
  HIDEMOTO NAKADA, GridRPC Working Group.




---------- Forwarded message ----------
From: Eddy Caron <Eddy.Caron at ens-lyon.fr>
Date: Wed, Jan 25, 2012 at 6:27 AM
Subject: Re: OGF applications group page
To: "Daniel S. Katz" <dsk at ci.uchicago.edu>
Cc: Peter Tröger <peter at troeger.eu>, Andre Merzky <andre at merzky.net>,
Wolfgang Ziegler <wolfgang.ziegler at scai.fraunhofer.de>, Joel Replogle
<replogle at ogf.org>, Hidemoto Nakada <hide-nakada at aist.go.jp>


Dear Daniel and Joel,

The current text of the Grid-RPC is outdated. I will sent a some
upgrade as soon as possible.

About the next session it could be fruitful to give more information.
Is it possible to have a session on Tuesday ?

Text for the next Grid-RPC session :
------------------------------------------------

Join the next Grid-RPC session and come with your data management use case ...

In september 2011, the Open Grid Forum standardized the document "Data
Management API within the GridRPC" [1] which discribes an optional API
that extends the GridRPC standard [2]. Used in a GridRPC middleware,
it provides a minimal set of functions to handle a large set of data
operations among which: movements, replications, migrations, data
prefetch and persistency.

After a few remarks on the GridRPC DM API, we'll present a basic
implementation that we have integrated in two different middleware,
 respectively DIET [3] and NINF [4]. We have conducted several experiments,
showing very high benefits that a Grid user can expect 1) in terms of
resource usage
compared to the current GridRPC context since useless transfers are
avoided; 2) in terms of reducing the completion time of an application
to obtain results the soonest (data can be prefetched and replicated,
hence letting calculus to be submitted really soon in a workflow
analysis in addition to the possible overlap between computations and
communications); 3) in terms of code portability, since we show with
these examples that at last the same GridRPC code can be compiled and
executed within two different GridRPC middleware which implements the
GridRPC data management API; 4) finally we thus obtain middleware
interoperability without any explicit glue as generally done like in
[5]: we show as a proof of concept that resources dispatched across
different administrative domains can be used altogether without the
underlying distributed data management systems having any knowledge of
the workflow and/or computing resources: computational servers of DIET
and NINF transparently collaborate to the same calculus by sharing
GridRPC data!

[1] Y. Caniou, E. Caron, G. Le Mahec and Hidemoto Nakada, "Data
Management API within the GridRPC", June 2011, Open Grid Forum
standard GFD-R-P.186.

[2] H. Nakada, S. Matsuoka, K. Seymour, J.J. Dongarra, C. Lee and
H. Casanova, "A GridRPC Model and API for End-User Applications", June
2007, Open Grid Forum standard GFD-R.052.

[3] E. Caron and F. Desprez, "DIET: A Scalable Toolbox to Build
Network Enabled Servers on the Grid", International Journal of High
Performance Computing Applications, 2006.

[4] Y. Tanaka, H. Nakada, S. Sekiguchi, T. Suzumura and S. Matsuoka,
"Ninf-G: A Reference Implementation of {RPC}-based Programming
Middleware for Grid Computing", Journal of Grid Computing, 2003.

[5] Y. Suzuki, N. Kushida, N. Teshima, K. Nakajima, A. Nishida and
N. Nakajima, "Interoperation between Atomic Energy Grid Infrastructure
(AEGIS) and Other Grids", in High Performance Computing on Vector
Systems 2008, Chap. 3, Roller, S.; Benkert, K.; Galle, M.; Bez, W.;
Kobayashi, H.; Hirayama, T. (Eds.), 2009.

Best Regards,

----------------------------------------------------------------------------------------------

Eddy Caron. Mcf HDR ENS Lyon

ENS Lyon - LIP - Projet GRAAL/Avalon

46 Allee d'Italie, 69364 Lyon Cedex 07, France

E-Mail : Eddy.Caron at ens-lyon.fr

[ Tel : 04.72.72.80.04 ][ Web page : http://graal.ens-lyon.fr/~ecaron ]

------------------------------------------------------------------------------------------------


Le 24 janv. 2012 à 17:52, Daniel S. Katz a écrit :

Hi Peter, Eddy, and Andre,

Can you take a quick look at
http://www.ogf.org/gf/group_info/areasgroups.php?area_id=5 and see
what is out of date and what needs to be changed?

Please email Joel the changes that should be made, and copy Wolfgang and me.

Thanks,
Dan

--
Daniel S. Katz
University of Chicago
(773) 834-7186 (voice)
(773) 834-6818 (fax)
d.katz at ieee.org or dsk at ci.uchicago.edu
http://www.ci.uchicago.edu/~dsk/