Petri net represenation of the grid job A place can be a control place or a data place, i.e. a reference to a resource of type data. The attribute "id" must be unique in this job. The attributes "x" and "y" are the coordinates of the place for graphical representation. The initialMarking of this place. Here you can define an object that serves as initial token Transitions can be control transitions or software transistion, i.e. a reference to a resource of type software. The attribute "id" must be unique in this job. The attributes "x" and "y" are the coordinates of the transition for graphical representation. (x=0..1, y=0..1) The element <condition> is used for defining control transitions. Use java syntax for defining the condition that must be fulfilled for the transition to fire if enabled. The available method calls are be defined by the interface "Conditions" of the JobHandler. If the condition is "true", this control transition will fire. The element <methodCall> is used for defining method calls on the JobHandler. Use java syntax for defining the methodCall. The method call will be invoked when the transition fires. The available method calls are defined by the interface "MethodCalls" of the JobHandler. Typical method calls are "transferExecutable()" or "untarExecutable()". An arc connects a place with a transistion (type="P2T") or a transition with a place (type="T2P"). If an arc connects a data place with a port of a software transition or vice versa, than a data flow between the corresponding data resource and the software resource is induced. A reference to the place with the corresponding id A reference to the transition with the corresponding id. If the transition is a software transition, than the arc may be connected to a specified port of this transition (inputRef or outputRef) A reference to an input port of a software resource. The ids of the input ports are defined by the GResourceDL. A reference to an output port of a software resource. The ids of the output ports are defined by the GResourceDL. types of resources that are supported: software: software component that physically exists e.g. as an executable file (e.g. harlekin.first.fraunhofer.de:/usr/bin/sleep) softwareClass: class of software (e.g. linux) hardware: hardware resource that physically exists and that can be located in the Computing Grid hardwareClass: class of hardware (e.g. x86) data: physically existing data (e.g. a file) dataClass: class of data (e.g. weather data) This must be a unique identifier for this resource in the whole computing grid environment. Recommendation: Use a URI in the form http://HOSTNAME:grdl/TYPE/NAME.xml. HOSTNAME stands for the hostname of the webserver where the resource description can be retreived from. Categorization of resouces: TYPE = sw = software TYPE = sc = softwareClass TYPE = hw = hardware TYPE = hc = harwareClass TYPE = da = data TYPE = dc = dataClass NAME stands for the name of the resource. reference to a resource that is defined somewhere with the same id use this generic parameter to specify entities that have no own tag supported units for element timestamp: msSince1970: Milliseconds since 1.1.1970, 00:00 (as used in Java) iso8601: time format as defined in ISO 8601: YYYY-MM-DDThh:mm:ss.sss (e.g.: 2000-01-01T08:12:00.000+02:00 or 2000-01-12T12:13:14Z) supported types for element value: float: string representation of IEEE-754 floating-point number with single precision (4Byte), e.g. 3.14, 2f, 1e1, .5f, 6., 0, -0, INF, -INF, NaN double: string representation of IEEE-754 floating-point number with double precision (8Byte) int: string representation of integer number (4Byte) boolean: "true" or "false" string: finite character string base64: base64 encoding of binary data (RFC2045) supported operations: eq = "=", gt = ">", ge = ">=", lt = "<", le = "<=" identification contains keywords and a textual description used to identify this resource contains the location of a small picture that can be used for visualization of this resource Here you can define the dependencies between resources. You can define a dependency by referring to other resources using <resourceRef> or by locally defining a new (private) resource using <resource>. supported types of dependencies between resources: depends: this resource depends on the referred resource. conflicts: this resource conflicts with the referred resource. provides: this resources provides the referred resource, i.e. it inherits and extends its properties. suggest: this resource suggests the use of the referred resource. information about the manufacturer of this resource documentation of this resource Information that is provided for performing the authorization (SIT: include more elements here!) This must be a unique identifier for this user Group is user group permitted to read this resource description and to have read access to the corresponding resource? is user group permitted to modify this resource description and to have write access to the corresponding resource? is the user group permitted to execute the corresponding resource? Information that is needed to perform the accounting (SIT: include more elements here!) This is the physical or virtual location of the corresponding object Geographic location defined in latitude/longitude in respect to WGS84 status of this resource. Supported states: <available is="true"> or <available is="false"> more types of states should be added here this element contains information that is needed for the task mapping structure of element taskId: <taskId>longint, longint</taskId> where the first longint is the identifier of the task level and the second longint the identifier of the task within this level hardware specific elements like memory and transmission speed Here, some measurement of the performance of the hardware due to certain metrics should be included (ITWM?) SPEC or Lapack could be possible benchmarks benchmarks can be of type SPEC or lapack (from Laszewski 2002) The transfer rate for communication with or through this hardware resource, sometimes wrongly referred as "bandwidth" (which is measured in Hz). Default unit: bit per s (DIN 44302) This must be a unique identifier for this resource software specific elements that are static and are not to be changed during creation and execution of a grid job input port for resources of type="software" supported types of input ports: stdin: standard input file: local file to be read by the software component. The <location> of <input> can either be defined as child element of <softwareSpecific.static> (i.e. the location and name of the input file is fixed) or as child element of <softwareSpecific.variable> (i.e. the software allows the user to define the location and name of the input file). this identifier must be unique in this resource output port for resources of type="software" supported types of output ports: stdout: standard output stderr: standard error file: local file to be written by the software component. The <location> of <output> can either be defined as child element of <softwareSpecific.static> (i.e. the location and name of the output file is fixed) or as child element of <softwareSpecific.variable> (i.e. the software allows the user to define the location and name of the output file). this identifier must be unique in this resource arguments for the execution of resources of type="software" not supported yet Here the measurement of CPU time needed for this software component on a specified hardware should be included (ITWM?). This information may be used to schedule this software component. types of benchmarks yet not specified (ideas from ITWM?) software specific parameters that are variable and may be changed by the user or some component of the grid architecture (e.g. meta scheduler) after being checked out from the repository use <execution> to define the location where the software compontent should be executed. <execution> may be provided e.g. by the user or by a meta scheduler. not supported yet