Donal,
Ali Anjomshoaa wrote:
Fwding bounced mail...
(Alexander, if you're going to be writing much about this, please join the mailing list; it simplifies things greatly.)
Sorry. I've subscribed now.
"Lukichev, Alexander S" <alexander.s.lukichev@intel.com>
Our team is currently develops an application that will use JSDL documents as input to invoke jobs in a distributed system. I'd like to comment if possible some aspects of the latest JSDL schema.
When you say "latest schema", is this pre- or post- the recent work done at the face-to-face meeting? It is my impression that many of these issues you raise were actually addressed there... :^) FYI, you should refer to the document at https://forge.gridforum.org/docman2/ViewCategory.php?group_id=1 22&category_id=868 which I believe is the most recent version of the spec.
Well, I refer this one.
Currently to describe the job to run you can specify: a) executable name b) arguments c) environment variables
This could be not enough configurable because executables can reside at different places on the different systems, arguments can be passed in different ways to close applications on different systems, etc. Thus JSDL contains pretty enough information for locating the suitable server, the located server could fail to run the requested application because of lack of configuration information.
Actually, there is no need to specify the executable name at all. An alternative (that we would encourage people to use where possible) is the "application name", and that provides the necessary abstraction.
That's right.
We also support an extensible set of application "types" which will allow for a much more sophisticated range of behaviour.
The schema limits the possible values to several _types_ of applications like scripts, java classes, sql queries, etc. But how e.g. fortran compilation could be specified? Imagine that you don't know the details about the location of the fortran compiler and the compiler vendor.
We can look at the UNICORE experience and try to configure the particular applications using the following entities:
a) fields (i.e. partucular file names, argument values, e.g. "source=a.c", "size=1234")
I see this as being a different interpretation on the Argument element (which would require using a non-JSDL type for now, though this will make for a powerful thing to do once we've got JSDL 1.0 out of the door.)
OK, so non-JSDL Argument could be a solution.
b) options (i.e. names for common modes of application work; though setting this mode could differ from system to system, e.g. "debug=on" results in passing "-g" to some compilers) c) contexts (modes for application invocations, e.g. "profiliration")
Thess would be probably done with extension elements in the Application element (unless of course they are more like Resources, when they'd go somewhere else). Anyone else want to comment?
d) variations (variations of expected results, e.g. "overwrite" for file operations)
I don't currently see how the current DataStaging element's CreationFlag and DeleteOnTermination sub-elements are insufficient. Please explain further.
Well, file operations can include "copy folder" or "untar file" and can be expressed as applications. So such variations can exist.
It would be nice if some kind of such specification (probably with another entities but with the idea of abstraction of application) is described in the JSDL spec.
I believe it is. Aside from the very standard kinds of execution scheme (like "run this executable") we also have some more sophisticated ideas like mechanisms for invokation of Java programs, running of SQL queries or even invokation of webservices. However, one of the things we still need to do is to fill out the (non-normative?) specification of how these things will be done.
Hope this helps.
Thanks. Alexander
Donal.