September 2005 - saga-rg

SAGA Use Cases
by Andre Merzky 27 Sep '05

27 Sep '05

Hi Group, the SAGA use cases have been made part of the GGF Use Case Repositoyr (prototype). They are now somewhat easier to browse and to access at: http://fs0.das2.cs.vu.nl:9090/twiki-test/bin/view/UseCases This URL might movi into the .ggf.org domain after GGF15. Use case authors: you are welcome to edit the use case meta data at that location (its a wiki). No login is required for now. Cheers, Andre. -- +-----------------------------------------------------------------+ | Andre Merzky | phon: +31 - 20 - 598 - 7759 | | Vrije Universiteit Amsterdam (VU) | fax : +31 - 20 - 598 - 7653 | | Dept. of Computer Science | mail: merzky(a)cs.vu.nl | | De Boelelaan 1083a | www: http://www.merzky.net | | 1081 HV Amsterdam, Netherlands | | +-----------------------------------------------------------------+

1 0

GCE0-05: Portals Workshop - Paper Submission Pages Online
by Mary Thomas 22 Sep '05

22 Sep '05

Please circulate this to any interested groups. GCE 2005: Workshop on Grid Computing Portals Call for Participation -------------------------------------------------------------------------- WORKSHOP UPDATES: **** Paper submission webpage is up and available (see Submissions) ***** http://acel.sdsu.edu/mtgs/gce05/ * Date for workshop has been finalized by SC Committee: Friday, November 18th, 8am - 12pm * Paper submission dates have been extended by 1 week to September 26, 2005. * The Technical Program review committee has been finalized and includes grid portal experts from both the US and Europe (see below). *Important Dates: 26-Sep-05: Extended Abstract Due <---- delayed 08-Oct-05: Acceptance Notification 18-Nov-05: Full Paper Submission Due at time of workshop -------------------------------------------------------------------------- WORKSHOP OVERVIEW: Grid computing portals have emerged to be important components of many large-scale Grid computing projects. Portals provide well-established mechanisms for providing familiar interfaces to secure grid resources, services, applications, tools, and collaboration services for communities of scientists. Furthermore, portals deliver complex grid solutions to users wherever they have access to a web browser running on the Internet without the need to download or install any specialized software or worry about networks and ports, etc. As a result, the science application user is isolated from the complex details and infrastructure needed to operate an application on the grid. The portal development community is currently undergoing a revolution as component-based architectures and services become standardized and widely adopted. Grid middleware is also changing in response to the services oriented architecture (SOA) approach to hosting services. The move towards an SOA grid maps very well to the architecture already employed by portals, further increasing their value within the grid community. This workshop will focus on portal projects that are adopting these new technologies and services. We seek papers from all aspects of portal development including portal architecture design and standards studies, toolkits developed in support of portals, as well as high-level application portals that utilize these technologies. GCE 2005 topics of interest include, but are not limited to: * Project portals including: User Portals,Application Portals, Science Gateway Portals,Education Portals * Portal architecture and design, including: Portlets and portal frameworks (uPortal, Sakai, CHEF, GridSphere, WebSphere, etc); JSP; JSF; Servlets; REST; Cocoon, etc.). * Portal security models and solutions. * Portal languages including Java, Python, Perl, PHP, etc * User interface/usability studies. * Middleware solutions in support of portals including: Web Services; WSRF Services; Grid technologies; Databases; Workflows; WSRP and other standards; Web services in support of Portals. Paper Submission and Publication: Authors are invited to submit an extended abstract paper on original and unpublished work (also not submitted elsewhere for review) reporting significant projects and results in any aspect of grid portals and related technologies. Abstracts/papers should not exceed 6 single-spaced pages of text using 10 point size type on 8.5 x 11 inch paper (see author instructions below). Authors should submit a PDF or PostScript (level 2) file that will print on a PostScript printer. Electronic submission will be done through the workshop website. Emailed copies will be accepted only if electronic submission is not possible. Submission implies the willingness of at least one of the authors to register and present the paper. Proceedings: All papers selected for this workshop will be peer-reviewed and will be published in a special issue of Concurrency and Computation: Practice and Experience (http://www3.interscience.wiley.com/cgi-bin/jhome/77004395) For author instructions see http://www3.interscience.wiley.com/cgi-bin/jabout/5361/ForAuthors.html Organization: Workshop Chair: Mary Thomas (SDSU) mthomas(a)rohan.sdsu.edu Steering/Advisory Committee: Dennis Gannon, Indiana Univ. (gannon(a)cs.indiana.edu Geoffrey Fox, Indiana Univ. (gcf(a)indiana.edu) Jay Boisseau, Univ. of Texas (boisseau(a)tacc.utexas.edu) Rob Allan, Daresbury (r.j.allan(a)dl.ac.uk) Technical Program Chairs: Marlon Pierce (IU) (mpierce(a)cs.indiana.edu) Jason Novotny (IU) (novotny(a)ncmir.ucsd.edu) Technical Program Committee: Alameda, Jay (National Center for Supercomputing Applications) Allen, Rob (Daresbury Labs, UK) Baker, Mark (University of Portsmouth, UK) Carafo, Massimo (University of Lecce, Italy) Fox, Geoffrey (Indiana University) Gannon, Dennis (Indiana University) Haupt, Tomasz (Univ. of Mississippi) Kelley, Ian (Louisiana State University) Kosiedowski, Michal (Poznan Supercomputing and Networking Center) Kuba, Martin (Masaryk University in Brno, CZ) Lin, Abel (University of California at San Diego) Marru, Suresh (Indiana University) Mueller, Kurt (San Diego Supercomputer Center) Novotny, Jason (University of California at San Diego) Parashar, Manish (Rutgers University) Pickles, Stephen (University of Manchester) Pierce, Marlon (Indiana University) Roberto, Barbera (Istituto Nazionale di Fisica Nucleare, IT) Roberts, Eric (Texas Advanced Computing Center) Severance, Charles (University of Michigan) Thomas, Mary (San Diego State University) von Laszewski, Gregor (University of Chicago/Argonne National Labs) Wehrens, Oliver (Albert-Einstein-Institut, Max Planck Institute, Germany) Wilkins-Diehr, Nancy (San Diego Supercomputing Center) We look forward to seeing you at SC in Seattle! Mary Thomas on behalf of the GCE 2005 planning committee -- =============================================================== Mary Thomas Department of Computer Science mthomas(a)rohan.sdsu.edu San Diego State University (619) 594-1694 (office) San Diego, CA 92182-7720 (619) 594-6746 (fax) http://rohan.sdsu.edu/faculty/mthomas Adv. Comp. Env. Lab http://acel.sdsu.edu

1 0

Details for call 22/9/05
by Tom Goodale 22 Sep '05

22 Sep '05

Hi, Sorry for the late notice. Today's details are: Date: Thu 22 September 2005 Time: 1700 Central European Summer Time 1600 British Summer Time 1000 Central Summer Time 0800 Pacific Summer Time Number: 0844 888 8888 (UK) 01805 004 102 (Germany) +44 870 088 5706 (Others) Code: 808044 Cheers, Tom

1 0

SAGA GGF15 schedule (fwd)
by Shantenu Jha 21 Sep '05

21 Sep '05

---------- Forwarded message ---------- Date: Wed, 21 Sep 2005 18:43:51 +0200 From: Andre Merzky <merzky(a)cs.vu.nl> Hi all, the session schedule for GGF15 is out, and can be viewed at: http://www.ggf.org/gf/group_schedule/ The SAGA sessions are: Monday 14:00 (Stuart): The session will present the SAGA API Draft, and discuss the mapping of the current API draft to the SAGA Use Cases. The session will also host a presentation from the GridCPR group, and a discussion to coordinate our work with that group. - Administrativa, GGF agenda bashing ( 5 min) - presentation of SAGA API (15 min) - mapping 3 Use Cases to API (50 min) - GridCPR presentation/discussion (20 min) Wednesday 11:00 (Franklin): The session will host a low level discussion of the current SAGA API draft. The draft is supposed to advance to submission status soon. This discussion will be continued in our Thursday session. The session will also host a discussion of higher level issues, such as the handling of future API extensions, and language bindings. - agenda bashing ( 5 min) - API discussion (60 min) - General discussion (25 min) Thursday 14:00 (St. James): The group will work on the current draft of the Requirement Document. The session will also continue low level discussion on the SAGA API draft spec. - agenda bashing ( 5 min) - requirement doc discussion (25 min) - continued API disc ussion (60 min) Cheers, Andre. -- +-----------------------------------------------------------------+ | Andre Merzky | phon: +31 - 20 - 598 - 7759 | | Vrije Universiteit Amsterdam (VU) | fax : +31 - 20 - 598 - 7653 | | Dept. of Computer Science | mail: merzky(a)cs.vu.nl | | De Boelelaan 1083a | www: http://www.merzky.net | | 1081 HV Amsterdam, Netherlands | | +-----------------------------------------------------------------+

1 0

Fwd (kielmann@cs.vu.nl): Fwd (craig@rush.aero.org): Re: [saga-rg] deep copy / shallow copy
by Thilo Kielmann 19 Sep '05

19 Sep '05

> From: Craig Lee <craig(a)rush.aero.org> > Subject: Re: [saga-rg] deep copy / shallow copy > > But, one could argue that when programming in a given language, > the copy/assignment operator will be used for both SAGA and non-SAGA > objects. > That is to say, the programmer should be/will be aware of the > copy/assignment semantics throughout the program. Nicely put, Craig! That's what I tried to say... > I agree that differing copy/assignment semantics could cause problems > for a programmer, but I don't see how a SAGA binding could dictate > copy/assignment > semantics that are different from a language's "native" semantics. > Besides being difficult or impossible to implement, this means that > different objects within a single program could have different > copy/assignment > behavior, depending on whether they were SAGA or non-SAGA objects. > This, too, could cause problems. > > I think this should be left as a language binding issue. Nonetheless, > the SAGA API doc could have a prominent "Advice to Practitioners" > section that identifies and discusses these binding pitfalls. Sounds right to me. Thilo -- Thilo Kielmann http://www.cs.vu.nl/~kielmann/

2 1

deep copy / shallow copy
by Andre Merzky 11 Sep '05

11 Sep '05

Hi all, during a discussion with Hartmut today, we stumbled over the question of copy behavious for the SAGA objects. Consider following code: ---------------------------------------------------------------------- 0 saga::job_description jd_1; 1 2 jd_1.set_attribute ("SAGA_Host", "host_1"); 3 4 cout << jd_1.get_attribute ("SAGA_Host")) << endl; 5 6 7 saga::job_description jd_2 = jd_1; 8 9 cout << jd_2.get_attribute ("SAGA_Host")) << endl; 10 11 jd_2.set_attribute ("SAGA_Host", "host_2"); 12 13 cout << jd_1.get_attribute ("SAGA_Hoset")) << endl; 13 cout << jd_2.get_attribute ("SAGA_Hoset")) << endl; ---------------------------------------------------------------------- What would that print? If the copy in line 4 is a deep copy, it would print: host_1 // jd_1 orig host_1 // jd_2 as copy from jd_1 host_1 // jd_1 orig still host_2 // jd_2 newly set if it is a shallow copy, it would be: host_1 // jd_1 orig <not defined> // jd_2 not defined yet host_1 // jd_1 orig still host_2 // jd_2 newly set if SAGA objects are only handled as references, it would be: host_1 // jd_1 orig host_1 // jd_2 as reference to jd_1 host_2 // jd_1 newly set (via jd_1 ref) host_2 // jd_2 just the same as jd_1 As the SAGA implementation should obviously show the same behaviour (either one for now), the spec needs to define that obviously. We think, that a default shallow copy is the most useful one. If for some objects a deep copy makes sense, a clone() method could be defined, which has the explicit semantics of a deep copy. If a reference is needed for some object, the native language can usually be used to obtain such one. So, if shallow copy as default, all three of the above cases seem easily implementable if needed. If there are no opinions against that, I'll add the respective note to the spec. Many thanks, Andre. -- +-----------------------------------------------------------------+ | Andre Merzky | phon: +31 - 20 - 598 - 7759 | | Vrije Universiteit Amsterdam (VU) | fax : +31 - 20 - 598 - 7653 | | Dept. of Computer Science | mail: merzky(a)cs.vu.nl | | De Boelelaan 1083a | www: http://www.merzky.net | | 1081 HV Amsterdam, Netherlands | | +-----------------------------------------------------------------+

4 7

Details for call 08/09/2005
by Tom Goodale 08 Sep '05

08 Sep '05

Hi, Sorry for not sending this earlier. Today's details are Date: Thu 25 August 2005 Time: 1700 Central European Summer Time 1600 British Summer Time 1000 Central Summer Time 0800 Pacific Summer Time Number: 0844 888 8888 (UK) 01805 004 102 (Germany) +44 870 088 5706 (Others) Code: 808044 Cheers, Tom

2 1

Use Case Mapping...
by Andre Merzky 08 Sep '05

08 Sep '05

Hi all, below are some notes for mapping the current SAGA API spec to one of the use cases, i.e. the GridLab use case for application migration. I attach the use case for reference as well. Cheers, Andre. +-----------------------------------------------------------------+ The SAGA API allows to migrate any job it can handle with the job class, using the migrate method. That provides an easy solution for the GridLab migration use case if supported by the implementation/middleware/backend: -------------------------------------------------------------- #include <saga.hpp> #include <vector> #include <string> using namespace std; int main () { saga::job_server js; saga::job j = js.run_job ("remote.host.net", "my_app"); job_definition jd = j.get_job_definition (); vector <string> hosts; vector <string> files; hosts.push_back (string ("near.host.net")); files.push_back (string ("http://remote.host.net/file > http://near.host.net/file")); jd.set_vector_attribute ("SAGA_HostList", hosts); jd.set_vector_attribute ("SAGA_FileTransfer", files); j.migrate (jd); cout << "Heureka!" << endl; return (0); } -------------------------------------------------------------- (Question: does the SAGA migrate call move checkpoint files automatically, or do they need to be specified in the new job description as above?) However, for the complete use case to be implemented on application level, a number of steps cannot be implemented in SAGA. The call sequence would be: In the application instance which performs the migration on the other job: - trigger migration for the remote job - discover new resource + move checkpoint data to new resource + schedule application on new resource + continue computation (and discontinue old job) In the application instance which gets migrated - get tirggered from checkpointing = perform application level checkpointing - report checkpoint file location(s) Items marked with + are possible to implement in SAGA, items marked with - aren't. The item marked with '=' is (currently) not related to SAGA. For the complete implementation of the use case, SAGA misses: 1) means to communicate with the remote application instance 2) means to discover new resources Notes: 1) means of communcation are actually given, but not per se usable for this use case. E.g. streams are a definite overkill for signalling checkpointing requests. Signals (as in job.signal (int signal)) would work, but only if the remote job uses signal handling as a checkpoint trigger. That also might be difficultato use if the job is running in a wrapper script, or in a virtual machine etc - that might not be transparent to SAGA, and would require direct communications. Also, the signalling method misses feedback about success of the operation, and cannot return information such as the location of checkpoint files. 2) the current SAGA API covers job submission to specific hosts, or lets the middleware choose a suitable host for submission. However, the brokering result is not exposed on API level, as would be neccessary for this specific use case, and possibly for other dynamically active Grid applications. One way to implement that is to provide a direct interface to Grid information systems, and on that way expose information about available resources. That would actually be more flexible, as is e.g. also allows the discovery of specific services, but would also require additional semantic knowledge on application lelvel. +-----------------------------------------------------------------+ -- +-----------------------------------------------------------------+ | Andre Merzky | phon: +31 - 20 - 598 - 7759 | | Vrije Universiteit Amsterdam (VU) | fax : +31 - 20 - 598 - 7653 | | Dept. of Computer Science | mail: merzky(a)cs.vu.nl | | De Boelelaan 1083a | www: http://www.merzky.net | | 1081 HV Amsterdam, Netherlands | | +-----------------------------------------------------------------+

1 0

multiple inheritance...
by Andre Merzky 02 Sep '05

02 Sep '05

Hi all, as we started to define the strawman in a OO way, we decided to use only simple OO features, and in particular no polumorphosm and multiple inheritance. The strawman right now respects that. However, as we now ponder over additional interfaces, such as permissions, we get into trouble: the file class would for example implement both the attribute and the permission interface, and hence would be inheriting multiple bases. In terms of implementation this can be avoided I think, although not beautifully. Hence the question, if that limitation is neccessary/wanted/needed on specification level. Plymorphism on the other hand can _not_ easily be avoided on implementation level once it is written down in the spec, and hence should not enter it. So, my opinion is to allow multiple interfaces on classes in the spec, bat take care that an implementation can be done w/o the need for multiple inheritance. Any other opinions? :-) If not, I would adjust the respective part in the intro. Cheers, Andre. -- +-----------------------------------------------------------------+ | Andre Merzky | phon: +31 - 20 - 598 - 7759 | | Vrije Universiteit Amsterdam (VU) | fax : +31 - 20 - 598 - 7653 | | Dept. of Computer Science | mail: merzky(a)cs.vu.nl | | De Boelelaan 1083a | www: http://www.merzky.net | | 1081 HV Amsterdam, Netherlands | | +-----------------------------------------------------------------+

3 2

permissions...
by Andre Merzky 02 Sep '05

02 Sep '05

Hi all, you see, its SAGA day in Amsterdam :-P The permission issue has been discussed a number of times during the phone calls and on the list, and it was a TODO item for me to draft an interface. Well, here is the first shot at it, without much details. before I go much further, feedback would be, as usual, welcome. Note that this interface might be in fact too simple, as it requires additional calls in the name space interface to allow stuff like: dir = directory (url); dir.set_permissions (U_READ, "file.secret.txt"); Right now the interface would only allow: dir d = directory (url); file f = d.open ("file.secret.txt"); f.set_permissions (U_READ); f.close (); and it seems in fact awkward to open a file just to set/get permissions. So, the real question I guess is: should it be an interafce at all, or shouldn't we just include it into the name space? Are (unix file like) permission of use elsewhere? Cheers, Andre. -- +-----------------------------------------------------------------+ | Andre Merzky | phon: +31 - 20 - 598 - 7759 | | Vrije Universiteit Amsterdam (VU) | fax : +31 - 20 - 598 - 7653 | | Dept. of Computer Science | mail: merzky(a)cs.vu.nl | | De Boelelaan 1083a | www: http://www.merzky.net | | 1081 HV Amsterdam, Netherlands | | +-----------------------------------------------------------------+

1 0