SLAs essentially are electronic contracts and contain a description of the service to deliver as well as optional business values such as pricing. An important requirement for dynamic SLA provisioning is to prevent illegal modification of agreement offers. Therefore an agreement template may contain a section of creation constraints which can be used by an agreement responder in order to define the structure and possible values of valid agreement offers based on a particular template. Creation constraints therefore provide a way to assert that an agreement offer always matches the agreement responder expectations. Only offers that are valid with respect to its template creation constraints are accepted by the framework.
Creation constraints support the agreement initiator to find out acceptable values for service descriptions. On the other hand, they protect the agreement responder from accepting offers that are created in an illegal way. With the help of creation constraints the input parameters of SLA aware service provisioning systems can be defined very strictly, hence increasing the system stability. Agreement templates that are fully restricted by creation constraints allow agreement initiators to find out exactly which parameters they may specify or change in an agreement offer. Agreement responder in turn can specify agreement templates in a way that each aspect specified in a valid offer is really processed. This helps agreement initiator and responder come to a common understanding of the service that is provided in the context of an SLA.
WS-Agreement specifies so called Offer Items for defining creation constraints in agreement templates. These offer items are subsequently called Offer Item Constraints in order to distinguish between the constraint and the elements in an agreement offer they refer to. An offer item constraint has a name and location element, where name can be used to easily identify this element in an agreement template, and location contains a machine processable expression to select document fragments (or Offer Items) from an agreement offer. These offer items are the elements of an agreement offer that are restricted by the offer item constraint. The location can for example contain an XPath expression. An offer item constraint can refer to zero to n offer items. Each offer item must satisfy the constraint specified in the Item Constraint element. Only if all offer items are valid according to the specified item constraints, the validation of the offer item succeeds. An agreement offer is only compliant to an agreement template when the validation process succeeds for all creation Constraints in the template.
The WS-Agreement specification defines the content of an Item Constraint as a choice between the xs:simpleRestrictionModel group and the xs:typeDefParticle group. Both groups are defined as part of the XML Schema specification.
Value Constraints or simple restriction model of the XML Schema allows defining restrictions on the value spaces of simple types, such as xsd:string, xsd:integer, xsd:boolean etc. The simple restriction model can contain a definition of a simple type and/or a definition of a group of facets. A simple type definition can either be a restriction of an existing simple type, a union of simple types or a list of simple type values.
Structural Constraints model defines how the content of offer items is structured. It uses xs:typeDefParticle group in order to define structural constraints on offer items. They specify which child elements can be part of a certain offer item, the order in which these child elements must occur, the cardinality of each child element, or how child elements are grouped.
Validation of agreement offers is a fundamental functionality of the WSAG4J framework. It implements a well defined and robust offer validation process. For each incoming offer the WSAG4J Engine first looks up the template that was used to create the offer. In the next step it validates the offer items for each offer item constraint. Only if the offer validation succeeded the agreement creation process is started. The WSAG4J framework supports any possible Item Constraints and is capable of handling and validating value and structural constraints. The validation problem is divided in two sub problems:
1. Validation of constraints based on the xs:simpleRestrictionModel group
2. Validation of constraints based on the xs:typeDefParticle group
The WSAG4J Agreement Offer Validator solves these validation problems in a very efficient way. During the validation process the offer validator dynamically creates an XML Schema based on the contents of an Item Constraint. Therefore, the validator first analyzes the content of the item constraint. If the item constraint is a restriction based on the xs:typeDefParticle group, it must contain an all statement, a sequence statement, a choice statement, or a group reference. In this case a validation schema for a complex type restriction is generated. If the Item Constraint does not contain one of the above mentioned elements, a schema for simple type validation is generated. Generating a validation schema based on the content of the Item Constraints is easily possible since the xs:simpleRestrictionModel and xs:typeDefParticle are also used by XML Schema to define simple type definitions and complex type definitions. Therefore, it is in principle possible to create a XML Schema definition for an Item Constraint, the validation problem transforms to the following sub problems:
1. Validation of the correct definition of an Item Constraint
2. Creation of a schema for simple type validation
3. Creation of a schema for complex type validation
4. Validation of the offer items against the creation constraint schemas
The generated constraint validation schema must either contain a simple type definition (xs:simpleRestrictionModel) or a complex type definition (xs:typeDefParticle). The validation of the correct definition of the Item Constraints of a template is done when the templates are loaded. During this process all agreement template documents are validated against the WS-Agreement schema.
In case an offer item constraint is based on the simple restriction model, 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. Moreover, the type must contain a restriction element. The restriction base should match the type of the referenced offer items. The offer validator dynamically determines the schema type of the referenced offer items through used XML parser/processor.
In case of schema generation for structural constraints, the target namespace of the structural constraint validation schema must match the namespace of the type of the referenced offer item. This is due to the fact that this validation schema contains a restriction of the offer item type definition. 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 outcome of the offer item validation assesses if one particular offer item is valid according to its item constraint. The validation of one particular creation constraint is only successful if the validation process for all referenced offer items succeeds. An agreement offer is only valid if the validation of all creation constraint contained in the originating template succeeds. If a valid agreement offer was received, the WSAG4J agreement factory calls the appropriate CreateAgreementAction that was configured for the originating template. The CreateAgreementAction implements the agreement acceptance policy and the service provisioning logic for this specific class of agreements.
For a full guide on how to implement creation constraints go to the Creation Constraints Example.