- jsdl-wg - lists.ogf.org

JSDL Generation Tool Available
by Mark Morgan 08 Feb '09

08 Feb '09

I have just completed a project which Andrew and I thought might be of interest to some of you. We are now supporting an application we call JSDLTool which aids users in creating new JSDL documents for certain types of applications and which can be used to create a series of JSDL files for an application in a parameter sweep scenario. Those keeping up with the mailing list regarding the OGF work on parameter sweeps will notice that our method of dealing with Parameter Sweeps is quite different and this stems largely from the fact that we've been doing parameter sweeps in Genesis II since nearly the beginning of the project's lifetime. As the standards work with parameter sweeps moves forward this tool may be retrofitted to support the new standard as well. In the meantime, this tool produces a batch of jsdl files, one each for each instantiation of the application inside of the parameter space. Any one interested in the application can find information about it as well as links for source code, documentation, and the application itself at http://www.cs.virginia.edu/~vcgr/wiki/index.php/JSDLTool -Mark

4 4

JSDL Teleconference - 28 January 2009 **@1pm UTC**
by Andreas Savva 27 Jan '09

27 Jan '09

Agenda: 1. Agenda bashing & quick status update 2. Parameter sweep public comments discussion (cont.) Confirm consensus on major issues starting with thread http://www.ogf.org/pipermail/jsdl-wg/2009-January/001148.html Other public comments http://www.ogf.org/gf/docs/comment.php?id=282 3. Activity instance document schema ===== Full call-in details ==== Date: 28 January 2009 Time: UTC 1 PM EUROPE: GMT 1 PM / CET 2 PM US: EST 8 AM ASIA: JST 10 PM Duration: 1 hour Dial-in numbers (toll): US: +1 718 3541071 (New York) or +1 408 9616509 (San Jose) UK: +44 207 3655269 (London) Germany: +49 (0)69 50070802 (Frankfurt) Japan: +81 3 3570 8225 (Tokyo) Other countries: http://tinyurl.com/eg48j User guide: http://tinyurl.com/qknrf Teleconference participant PIN: 4371991 Screen share: http://jsdl.glance.net/?key=0128 Note: When you dial in after the initial message in English for the PIN there is another message in Japanese only (sorry) to state your name and press '#' in order to join the call. -- Andreas Savva Fujitsu Laboratories Ltd

1 0

Discussion regarding an implementation of JSDL
by Arnie Miles 23 Jan '09

23 Jan '09

All, I represent the Thebes middleware consortium, which is hosted at Georgetown University. One of the things the Thebes consortium is working on is a job acceptance service that can accept jobs, translate them to DRMAA, and submit them to job schedulers. Our intention is to include the ability to accept SAML assertions to make policy decisions. We currently use an axis web service that takes JSDL and uses DRMAA to submit the job to Sun Grid Engine. It is rudimentary at this point. We're interested in projects that are working in similar arenas, and we're interested in thoughts from the JSDL team about recommendations, suggestions, etc. Thanks, Arnie Miles Middleware Architect Georgetown University

6 9

(Param Sweep) - Stephen Pickles' public comment
by geoff 22 Jan '09

22 Jan '09

Hi all, I took a much closer look at Steve's input on the subject of looping through values ( http://www.ogf.org/gf/docs/comment.php?id=282 ) and, contrary to what I was saying in the teleconf yesterday (which was based on not having given it suitable forethought - big sorry! :( ), before proceding I have the following points relating to Steve's concerns : I'll use this convention throughout : Option (A) : start, step and end values (as per current spec.) Option (B) : start, step and loop count values (Steve's proposal) Point 1 : Following a very small survey on a few local users I received roughly equal preference for each option based on the following principles: Option (A) : Useful when ranges (e.g. physiological ranges) are known, so little or no concern for the number of loops to perform. As per examples ( http://forge.ogf.org/sf/wiki/do/viewPage/projects.jsdl-wg/wiki/ParameterSwe… ) Option (B) : Useful when a specific number of iterations are required, e.g. having 10 values to test. Note: There was some uncertainty, in that a loop count of "n" would generate "n+1" values, i.e, a loop count of 0 will still produce a single loop value! This would require clarification by documentation. Conclusion : We need to ensure that the specification doesn't prevent either of these options for job submission data entry. Point 2 : After reading up about Fortran the best official-looking (i.e. I'm not a Fortran user/expert) explanation I could find is : "3.2 Real & double precision DO variables This was a feature copied from Algol 60 to Fortran 77 at a time when there was a move to relax the strict type rules of Fortran 66. Subsequently it was realized by IFIP that it was a mistake in Algol and the feature did not appear in Algol 68. The problem is that because of the nature of real arithmetic it is not possible, without detailed knowledge of the arithmetic and implementation of a system, to predict the behaviour of a program using this feature. Thus use contradicts the first purpose of the standard, the promotion of portability of programs. Since this deficiency has been known for over twenty years, the feature has been relatively little used in Fortran and programs are readily convertible to use an integer control variable. Fortran should recognize that a mistake was made and the feature should now be deleted from the language." ( http://www.open-std.org/JTC1/SC22/WG5/436 ) Conclusion : Fortran, no doubt as many other programming languages, suffers from non-integer accuracy problems. IMHO though this should be considered a problem solely for implementors to resolve using their own solutions, but it should not however influence the determination of a specification by which grid users want to submit their jobs (i.e. our role). To emphasise the implementation-specific nature Java provides out-of-the-box ability to perform IEEE 754 standard ( http://en.wikipedia.org/wiki/IEEE_754 ), base 10 / decimal arithmetic by use of the BigDecimal class ( http://java.sun.com/j2se/1.5.0/docs/api/java/math/BigDecimal.html ) (note: values of which should be initialised using string representations), which is considerably more accurate than Float or Double classes which use base 2 arithmetic. ( http://www.ddj.com/java/184405721 ) and could meet the accuracy needs of the vast majority of users. In another official-looking document I understand that Fortran has moved towards adopting decimal floating point arithmetic IEEE 754 ( http://grouper.ieee.org/groups/754/email/msg01921.html ) Point 3 : I believe that Option (A) delivers a stronger contract for accuracy by implementations by explicitly specifying three verifiable values, rather than Option (B) which provides just two, i.e. just start and step. Conclusion : Option (A) should take precedence over Option (B) as the former specifies a limit condition (and hence accuracy is explicit) whereas the latter doesn't. Point 4 : We must assume that the user is competent and accurate, although occasionally distracted. Conclusion : It's for implementors to worry about determining suitability of data entered. Overall conclusion: I feel we should stick 100% with the current specification and leave the ability to provide Option (B) input to interface implementations. I'd be very grateful for feedback to this email, particular from Steve Pickles, hence I've Cc'd him. Now that I've managed to document my concerns, and hopefully in a form which is more coherent (and with accessible references) than the views expressed during teleconfs, it'll be easier to see why I remain reluctant to change. Thanks, gef

2 3

First Major g-Eclipse Release Available.
by Nicholas Loulloudes 21 Jan '09

21 Jan '09

1 0

JSDL Teleconference - 14 January 2009 **@1pm UTC**
by Andreas Savva 13 Jan '09

13 Jan '09

I hope tomorrow is convenient for our first call of the year at the regular timeslot of 1pm UTC. With the parameter sweep formally out of public comment we should start wrapping up the various issues reported. Agenda: 1. Agenda bashing & quick status updates (OGF25) 2. Parameter sweep public comments discussion (cont.) 3. Activity instance document schema ===== Full call-in details ==== Date: 14 January 2009 Time: UTC 1 PM EUROPE: GMT 1 PM / CET 2 PM US: EST 8 AM ASIA: JST 10 PM Duration: 1 hour Dial-in numbers (toll): US: +1 718 3541071 (New York) or +1 408 9616509 (San Jose) UK: +44 207 3655269 (London) Germany: +49 (0)69 50070802 (Frankfurt) Japan: +81 3 3570 8225 (Tokyo) Other countries: http://tinyurl.com/eg48j User guide: http://tinyurl.com/qknrf Teleconference participant PIN: 4371991 Screen share: http://jsdl.glance.net/?key=0114 Note: When you dial in after the initial message in English for the PIN there is another message in Japanese only (sorry) to state your name and press '#' in order to join the call. -- Andreas Savva Fujitsu Laboratories Ltd

2 1

New WG in job submission area
by Steven Newhouse 31 Dec '08

31 Dec '08

Apologies for the cross-posting! For those who have been involved in BES, JSDL and the HPCBP work... there is a new activity starting in OGF that intends to build on work in this area... but for new use cases. See below: <quote> The Grid Interoperation Now (GIN) community group is happy to announce its spin-off standardization activity named Production Grid Infrastructure (PGI) working group. Both groups will complement each other and thus GIN proceeds to enable real e-science applications that require resources in more than one production infrastructure demonstrating the technical feasibility of interoperability using open standards wherever possible. In contrast to GIN, PGI will formulate a well-defined set of profiles, and additional specifications if needed, for job and data management that are aligned with a Grid security and information model in order to address the needs of production Grid infrastructures based on the experiences gained in GIN. The resulting Web service interfaces and schemas defined by this working group will be a set of profiles of open standards and specifications such as OGSA-Basic Execution Services (GFD.108), Job Submission Description Language (GFD.136), GridFTP (GFD.20), Storage Resource Manager (GFD.129), and efforts of the GLUE2 (GFD tbc) working group. The additional work bv this group will go beyond the current specifications and extensions to focus on the missing links between these specifications taking reasonable authentication/authorization models into account – all tuned to the use cases found in production Grid infrastructures. The PGI kick-off teleconference providing a ‘PGI 101’ is on Wednesday, 2009-01-07 at 4 p.m. CET (UTC+1). For more details please visit the PGI Website: http://forge.ogf.org/sf/projects/pgi-wg </quote> I assume call details will be circulated nearer the time by the WG chairs. Steven Dr Steven Newhouse EGEE Technical Director http://cern.ch/Steven.Newhouse

1 0

Schedule updates and minutes
by Andreas Savva 19 Dec '08

19 Dec '08

1. The minutes from the last few calls are now online. Apologies for the delay in posting these. Please check them, especially if you think you may have some action assigned to you.... Dec. 10. https://forge.gridforum.org/sf/go/doc15411?nav=1 Nov. 26. https://forge.gridforum.org/sf/go/doc15410?nav=1 Nov. 12 https://forge.gridforum.org/sf/go/doc15409?nav=1 2. The next call is scheduled for 7 January 2009 (Wednesday) at 1pm UTC/GMT. 3. We have requested two sessions for OGF25: - General session - Activity instance session Finally I'd like to thank all group members and teleconference participants in particular for their contribution in 2008. Wishing you happy holidays and happy 2009. -- Andreas Savva Fujitsu Laboratories Ltd

1 0

JSDL Teleconference - 10 December 2008 **@1pm UTC**
by Andreas Savva 09 Dec '08

09 Dec '08

** NOTE 1PM UTC TIMESLOT ** Confirming a call for Wednesday, 10 December, at 1pm UTC. Agenda: 1. Agenda bashing & quick status updates 2. Parameter sweep public comments discussion (cont.) 3. Activity instance document schema (if updated draft) ===== Full call-in details ==== Date: 10 December 2008 Time: UTC 1 PM EUROPE: GMT 1 PM / CET 2 PM US: EST 8 AM ASIA: JST 10 PM Duration: 1 hour Dial-in numbers (toll): US: +1 718 3541071 (New York) or +1 408 9616509 (San Jose) UK: +44 207 3655269 (London) Germany: +49 (0)69 50070802 (Frankfurt) Japan: +81 3 3570 8225 (Tokyo) Other countries: http://tinyurl.com/eg48j User guide: http://tinyurl.com/qknrf Teleconference participant PIN: 4371991 Screen share: http://jsdl.glance.net/?key=1210 Note: When you dial in after the initial message in English for the PIN there is another message in Japanese only (sorry) to state your name and press '#' in order to join the call. -- Andreas Savva Fujitsu Laboratories Ltd

2 1

JSDL extension for SOA-type jobs
by Gorkin, Leonid (IT) 03 Dec '08

03 Dec '08

Hi All, Are there any plans to extend JSDL to support SOA-type jobs? I know this is not a part of the standard right now, and Microsoft added their own extension in Windows HPC 2008. With this extension, JSDL file looks something like <?xml version="1.0" encoding="utf-8" ?> <jsdl:JobDefinition xmlns:jsdl="http://schemas.ggf.org/jsdl/2005/11/jsdl" xmlns:soa="http://schemas.microsoft.com/HPCS2008/hpcbp/soa" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <jsdl:JobDescription> <jsdl:JobIdentification> <jsdl:JobName>SOA Echo</jsdl:JobName> <jsdl:JobProject>HPCBP Project</jsdl:JobProject> </jsdl:JobIdentification> <jsdl:Application> <soa:HPCS2008SOAJob ServiceName="CcpEchoSvc" AllocationShrinkLoadRatioThreshold="75" AllocationGrowLoadRatioThreshold="125" ServiceStatUpdateInterval="30000" ClientConnectionTimeout="30000" ClientIdleTimeout="30000" SessionIdleTimeout="1000"> <soa:JobPriority>Normal</soa:JobPriority> <soa:Project>SOA Test Project</soa:Project> <soa:Runtime>100</soa:Runtime> <soa:ServiceJobName>SOA Test Job</soa:ServiceJobName> <soa:ShareSession>false</soa:ShareSession> </soa:HPCS2008SOAJob> </jsdl:Application> <jsdl:Resources>  </jsdl:Resources> </jsdl:JobDescription> </jsdl:JobDefinition> So if there are plans to support something like this in JSDL/Basic Profile, is there any guidance on when approximately it will be available? I am researching cross-vendor API for various grid providers, and the absence of SOA support is a big issue now. Any information on this is greatly appreciated. Best regards, Leonid -------------------------------------------------------- NOTICE: If received in error, please destroy and notify sender. Sender does not intend to waive confidentiality or privilege. Use of this email is prohibited when received in error.

2 1