
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@univa.com