[jsdl-wg] rough draft of job example for WS-Agreement
Karl Czajkowski
karlcz at univa.com
Tue Aug 2 09:02:47 CDT 2005
This is something I am working on for the WS-Agreement specification.
As I mentioned on the call, I am interested in comments in case the
scenario is confusing to people. The purpose is to illustrate
WS-Agreement mechanisms w/ something more concrete.
Please note, "template" in the following text is related to a
WS-Agreement advertisement mechanism and has little to do w/ the
notion of a JSDL document being a job template. WS-Agreement
templates are a meta-model for describing a range of agreement offer
documents that may be acceptable to a given party.
I haven't built up all the schema-validating template/offer wrapping
yet, to focus on some JSDL-based content to illustrate the constraints
etc.
karl
The job submission scenario mentioned in Section (ref intro to spec)
involves an Agreement that describes a single job, where the initiator
of the Agreement is the one submitting the job. The templates for
such a scenario will show the job description term language that is
supported by the job hosting service and MAY also indicate default
values or constraints on what values are supported for jobs executed
by that service.
The following example template shows the use of a prototype JSDL
document as a service term and specifies some default values in the
prototype. Specifically, it shows:
-- The use of the optional jsdl-posix:POSIXApplication sub-language
-- Default 1 MiB file size limit
-- Default 0 byte core dump size limit
-- Default 64 open file descriptors limit
-- Default "LINUX" operating system
-- Default "x86" CPU type
-- Default 1.6 GHz CPU speed
-- Default 2 CPUs per node
-- Default 100 Mb/s network connectivity for nodes
-- Default 1 node per job
And the creation constraints indicate limited values for some
options. Specifically, they constrain:
-- Maximum 500 MiB file size limit
-- Maximum 500 MiB core dump size limit
-- Maximum 1024 open file descriptors limit
-- Choice of "LINUX" or "FreeBSD" operating systems
-- Choice of "x86", "x86_32", or "x86_64" CPU types
-- Choice of 10, 100, or 1000 Mb/s network connectivity for nodes
-- Choice of 1, 2, or 4 CPUs per node
-- Maximum of 128 nodes per job
No complex constraints are given to show how fields are inter-related,
so the consumer of the template does not know if there are limited
numbers of nodes with particular OS, CPU, network, or SMP types.
These namespaces have to get cooked into the XML examples still:
jsdl="http://schemas.ggf.org/jsdl/2005/06/jsdl"
jsdl-posix="http://schemas.ggf.org/jsdl/2005/06/jsdl-posix"
...
<wsag:ServiceDescriptionTerm
wsag:Name="Job JSDL" wsag:ServiceName="Job">
<jsdl:JobDefinition>
<JobDescription>
<Application>
<jsdl-posix:POSIXApplication>
<FileSizeLimit>1048576</FileSizeLimit>
<CoreDumpLimit>0</CoreDumpLimit>
<OpenDescriptorsLimit>64</OpenDescriptorsLimit>
</jsdl-posix:POSIXApplication>
</Application>
<Resources ...>
<OperatingSystem>
<OperatingSystemType>
<OperatingSystemName>LINUX</OperatingSystemName>
</OperatingSystemType>
</OperatingSystem>
<CPUArchitecture>
<CPUArchitectureName>x86</CPUArchitectureName>
</CPUArchitecture>
<IndividualCPUSpeed>
<Exact>1600000</Exact>
</IndividualCPUSpeed>
<IndividualCPUCount>
<Exact>2.0</Exact>
</IndividualCPUCount>
<IndividualNetworkBandwidth>
<Exact>100000000</Exact>
</IndividualNetworkBandwidth>
<TotalResourceCount>
<Exact>1</Exact>
</TotalResourceCount>
</Resources>
</JobDescription>
<jsdl:JobDefinition>
</wsag:ServiceDescriptionTerm>
...
<wsag:Item>
<Location>//jsdl-posix:FileSizeLimit</Location>
<xsd:restriction base="xsd:positiveInteger">
<xsd:maxInclusive value="524288000"/>
</xsd:restriction>
</wsag:Item>
<wsag:Item>
<Location>//jsdl-posix:CoreDumpLimit</Location>
<xsd:restriction base="xsd:positiveInteger">
<xsd:maxInclusive value="524288000"/>
</xsd:restriction>
</wsag:Item>
<wsag:Item>
<Location>//jsdl-posix:OpenDescriptorsLimit</Location>
<xsd:restriction base="xsd:positiveInteger">
<xsd:maxInclusive value="1024"/>
</xsd:restriction>
</wsag:Item>
<xsd:restriction base="jsdl:ProcessorArchitectureEnumeration">
<enumeration value="x86_32"/>
<enumeration value="x86_64"/>
<enumeration value="x86"/>
</xsd:restriction>
</wsag:Item>
<wsag:Item>
<Location>//jsdl:OperatingSystem/jsdl:OperatingSystemType/jsdl:OperatingSystemName</Location>
<restriction base="jsdl:OperatingSystemTypeEnumeration">
<enumeration value="LINUX"/>
<enumeration value="FreeBSD"/>
</restriction>
</wsag:Item>
(base="jsdl:RangeValue_Type" for complex type of the next fields)
<wsag:Item>
<wsag:Location>//jsdl:IndividualNetworkBandwidth</wsag:Location>
<xsd:sequence>
<xsd:element name="Exact" minOccurs="1" maxOccurs="unbounded">
<xsd:simpleType>
<xsd:restriction base="xsd:double">
<xsd:enumeration value="1000000000"/>
<xsd:enumeration value="100000000"/>
<xsd:enumeration value="10000000"/>
</xsd:restriction>
</xsd:simpleType>
</xsd:element>
</xsd:sequence>
</wsag:Item>
Given the preceding template example, a submitting client might
generate an offer such as in the following example. This offer
overrides some of the default values while observing the creation
constraints, and also includes additional JSDL language elements which
are supported by the schema of the top-level term document even though
they are not present in the template's prototype document, nor are
they constrained in any way according to the schema.
Specifically, this offer:
-- Provides an executable program file name
-- Provides an argument list to the program
-- Provides input/output/error file redirections
-- Provides a working directory name for the job
-- Selects a 16 MiB file size limit
-- Keeps the default 0 byte core dump size limit
-- Selects the maximum 1024 open file descriptors limit
-- Selects the "LINUX" operating system
-- Selects the "x86_32" CPU type
-- Keeps the default (fixed??) 1.6 GHz CPU speed
-- Sets optional CPU time limits to schedule the job
to run for at least 15 minutes but no more than one hour
of CPU time per CPU
-- Selects dual-CPU SMP nodes
-- Selects 100/1000 Mb/s network speeds (the scheduler can choose which)
-- Selects 4 nodes for the job
The Agreement responder can validate that this offer meets the
criteria for the template and also can check whether the job hosting
service has sufficient resources to handle this job, before deciding
whether to accept or reject the agreement offer. If accepted, the
resulting Agreement resource MUST have the same terms as in the offer,
so we do not provide an additional agreement document example.
An offer:
...
<jsdl:JobDefinition id="xsd:ID"?>
<jsdl:JobDescription>
<jsdl:Application>
<jsdl-posix:POSIXApplication name="xsd:NCName"?>
<Executable>/home/user1/test/program</Executable>
<Argument>-benchmark</Argument>
<Argument>-output</Argument>
<Argument>-</Argument>
<Input>input</Input>
<Output>output</Output>
<Error>error</Error>
<WorkingDirectory>/home/user1/test/1</WorkingDirectory>
<FileSizeLimit>16777216</FileSizeLimit>
<CoreDumpLimit>0</CoreDumpLimit>
<OpenDescriptorsLimit>1024</OpenDescriptorsLimit>
</jsdl-posix:POSIXApplication>
</jdsl:Application>
<Resources ...>
<OperatingSystem>
<OperatingSystemType>
<OperatingSystemName>LINUX</OperatingSystemName>
</OperatingSystemType>
</OperatingSystem>
<CPUArchitecture>
<CPUArchitectureName>x86_32</CPUArchitectureName>
</CPUArchitecture>
<IndividualCPUSpeed>
<jsdl:Exact>1600000</jsdl:Exact>
</IndividualCPUSpeed>
<IndividualCPUTime>
<jsdl:Range>
<jsdl:LowerBound>900</jsdl:LowerBound>
<jsdl:UpperBound>3600</jsdl:UpperBound>
</jsdl:Range>
</IndividualCPUTime>
<IndividualCPUCount>
<jsdl:Exact>2.0</jsdl:Exact>
</IndividualCPUCount>
<IndividualNetworkBandwidth>
<jsdl:Exact>1000000000</jsdl:Exact>
<jsdl:Exact>100000000</jsdl:Exact>
</IndividualNetworkBandwidth>
<TotalResourceCount>
<jsdl:Exact>4</jsdl:Exact>
</TotalResourceCount>
</Resources>
</jsdl:JobDescription>
<jsdl:JobDefinition>
----- End forwarded message -----
--
Karl Czajkowski
karlcz at univa.com
More information about the jsdl-wg
mailing list