This section provides an example on how to define creation constraints as described in the section Creation Constraints.
The agreement template used in the following example can be found as under sample template.
This template has one service description term called "SampleServiceDescription" as shown below which defines the name/version of the application that can be executed on some target compute resource.
<wsag:Terms>
<wsag:All>
<wsag:OneOrMore>
<wsag:All>
<wsag:ExactlyOne>
<wsag:ServiceDescriptionTerm wsag:Name="SampleServiceDescription" wsag:ServiceName="Sample_Application_Service">
<jsdl:JobDefinition xmlns:jsdl="http://schemas.ggf.org/jsdl/2005/11/jsdl">
<jsdl:JobDescription>
<jsdl:Application>
<jsdl:ApplicationName>Sample_Job_1</jsdl:ApplicationName>
<jsdl:ApplicationVersion>1.0</jsdl:ApplicationVersion>
<jsdl:Description>Sample Job 1</jsdl:Description>
</jsdl:Application>
</jsdl:JobDescription>
</jsdl:JobDefinition>
</wsag:ServiceDescriptionTerm>
</wsag:ExactlyOne>
</wsag:All>
</wsag:OneOrMore>
</wsag:All>
</wsag:Terms>
The first item constraint Structural_Offer_Constraint (shown below) restricts the structure of the overall agreement and describes exactly how valid service descriptions in an agreement offer must look like. This is done by defining the structure and valid values for a offer item in the sample template.
<wsag:Item wsag:Name="Structural_Offer_Constraint">
<wsag:Location>declare namespace wsag='http://schemas.ggf.org/graap/2007/03/ws-agreement';$this/wsag:AgreementOffer</wsag:Location>
<wsag:ItemConstraint>
...
<xs:element name="Terms">
<xs:complexType>
<xs:complexContent>
<xs:restriction base="wsag:TermTreeType" xmlns:ws="http://schemas.ggf.org/graap/2007/03/ws-agreement">
...
<xs:element name="All">
...
<xs:restriction base="wsag:ServiceDescriptionTermType">
<xs:sequence>
<xs:element ref="jsdl:JobDefinition" xmlns:jsdl="http://schemas.ggf.org/jsdl/2005/11/jsdl" />
</xs:sequence>
... ... ... ...
</wsag:ItemConstraint>
</wsag:Item>
The above Item Constraint restricts the terms element of an agreement offer. The agreement terms must contain one All statement. The All statement must include one OneOrMore statement that must include one All statement. This last All statement must include one ExactlyOne statement. Moreover, the ExactlyOne statement must include one service description term for the service the agreement initiator has selected for execution. The Item Constraint also ensures that the service description term contains a JSDL job definition document.
The second item constraint Structural_Application_Contraint in our sample template uses Job Submission Description Language. JSDL defines most of the elements in its data structures as optional. In general the job definition contains a job description, which in turn contains elements such as application, data staging, resources, or job identification. It illustrates how the structure of a JSDL job definition can be restricted and ensures that the job description must contain only an application section.
<wsag:Item wsag:Name="Structural_Application_Contraint">
...
<xs:restriction base="jsdl:JobDescription_Type">
<xs:sequence>
<xs:element name="Application">
...
<xs:restriction base="jsdl:Application_Type">
...
<xs:element ref="jsdl:ApplicationName" minOccurs="1" maxOccurs="1" />
<xs:element ref="jsdl:ApplicationVersion" minOccurs="1" maxOccurs="1" />
<xs:element ref="jsdl:Description" minOccurs="0" maxOccurs="1" />
...
</xs:restriction>
... ... ...
</wsag:Item>
A third item constraint "SimpleType_Application_Constraint" is a simple restriction on application name and version, and shows that ApplicationName can be enumerated as list and ApplicationVersion must contain an integer value from 1 to 10.
<wsag:Item wsag:Name="SimpleType_Application_Constraint">
...
<xs:element name="ApplicationName">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:enumeration value="Sample_Job_1" />
<xs:enumeration value="Sample_Job_2" />
</xs:restriction>
</xs:simpleType>
</xs:element>
<xs:element name="ApplicationVersion">
<xs:simpleType>
<xs:restriction base="xs:int">
<xs:minInclusive value="1" />
<xs:maxInclusive value="10" />
</xs:restriction>
</xs:simpleType>
</xs:element>
...
</wsag:Item>
In case an offer item constraint is based on the simple restriction model (see creation constraints), the agreement offer validator creates a new validation schema with a simple type definition. This schema is then used to validate the referenced offer items. The target namespace of the schema can be domain specific. The top level simple type for the validation is generated. This type definition must specify a name as SimpleApplicationConstraintType, must contain a restriction element, and the restriction base should match the type of the referenced offer items.
In case of schema generation for structural constraints (see creation constraints), the target namespace of the structural constraint validation schema must match the namespace of the type of the referenced offer item. Moreover, the elementFormDefault value of the validation schema must match the corresponding value of the offer item type definition. This means if the type of the offer item is specified to be fully qualified, then the elementFormDefault property of the generated schema must also be set to qualified. In the next step, the schema definition of the offer item type is included into the validation schema. Now the constraint validation type is generated. The validation type has a complex content that restricts the offer item type. The restriction base of the SampleStructuralApplicationContraintType must be set accordingly. In our example the restriction base is the jsdl:JobDefinition_Type.
Since the agreement offer validator can only detect validation errors during runtime, it is appropriate to define schemas for item constraints validation during development time. It reduces the overhead of starting or stopping the engine after every XML validation error. The simple application constraint schema is defined to valide the SimpleType_Application_Contraint item constraint, the structural application constraint schema is used to to validate the Structural_Application_Contraint offer item, and the structural offer constraint schema is defined to validate the Structural_Offer_Constraint offer item. It is quite straightforward to validate the resulting schema in almost every IDE. For example in Eclipse a right click on a schema file brings a drop down menu and the listed menu item "validate" will validate the XML file.
A valid job description has exactly the same structure as the one provided in a service description term of the template. An agreement offer is only valid if the validation of all creation constraints contained in the originating template succeeds. Have a look on the sample offer that is based on the sample template.
<jsdl:JobDefinition
xsi:type="jsdl:SampleStructuralApplicationContraintType"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:jsdl="http://schemas.ggf.org/jsdl/2005/11/jsdl"
xsi:schemaLocation="http://schemas.ggf.org/jsdl/2005/11/jsdl schema-Structural_Application_Contraint.xsd">
<jsdl:JobDescription>
<jsdl:Application>
<jsdl:ApplicationName>Sample_Job_1</jsdl:ApplicationName>
<jsdl:ApplicationVersion>1.0</jsdl:ApplicationVersion>
<jsdl:Description>Sample Job 1</jsdl:Description>
</jsdl:Application>
</jsdl:JobDescription>
</jsdl:JobDefinition>