The Configuration: SPML object contains definitions for the SPML schemas that you want to expose, and information about how those SPML schemas are mapped into Waveset views. This information is represented by using a GenericObject that is stored as an extension of the configuration object.
The following attributes are defined in GenericObject: schemas and classes:
Schemas. A list of strings, where each string contains the escaped XML for one SPML <schema> element. Because the SPML elements are not defined in the waveset.dtd, you cannot directly include them in an Waveset XML document. Instead, you must include them as escaped text.
Classes. A list of objects containing information about the supported SPML classes and how those classes are mapped into views. Define one object from this list for each class defined by the SPML schemas on the schemas list.
Initially, the distinction between the two lists might be confusing. The information in the schemas list defines what Waveset returns in response to an SPML SchemaRequest message. The client uses this information to decide which attributes can be included in other messages such as AddRequest. Waveset does not care about the contents of the schemas list. This list is simply returned verbatim to the client.
You are not required to define SPML schemas. Waveset works without schemas. If you do not define an SPML schema, Waveset returns an empty response after receiving a schema request message. Without a schema, clients must rely on pre-existing knowledge about the supported classes and attributes.
Best Practice:
Writing SPML schemas is considered a best practice, because it enables you to use general purpose tools (such as the OpenSPML Browser) to build requests.
The following example shows the default SPML configuration. The text of the SPML schema definitions have been omitted for brevity.
<Configuration name='SPML' authType='SPML'> <Extension> <Object> <Attribute name='classes'> <List> <Object name='person'> <Attribute name='type' value='User'/> <Attribute name='form' value='SPMLPerson'/> <Attribute name='default' value='true'/> <Attribute name='identifier' value='uid'/> </Object> <!-- Class 'user' defines no form so we'll default to a builtin simplified schema. I don't really like this but SimpleRpc currently depends on it. --> <Object name='user'> <Attribute name='type' value='User'/> <Attribute name='identifier' value='waveset.accountId'/> </Object> <!-- Class 'userview' defines the form "view" which causes the view to pass through unmodified--> <Object name='userview'> <Attribute name='type' value='User'/> <Attribute name='form' value='view'/> <Attribute name='identifier' value='waveset.accountId'/> <Attribute name='multiValuedAttributes'> <List> <String>waveset.resources</String> <String>waveset.roles</String> <String>waveset.applications</String> </List> </Attribute> </Object> <Object name='role'> <Attribute name='type' value='Role'/> <Attribute name='form' value='SPMLRole'/> <Attribute name='default' value='true'/> <Attribute name='identifier' value='name'/> <!-- attribute ...for now? --> </Object> </Configuration>
Two classes are defined in this example:
The standard person class
An Waveset extension named request
The following attributes are supported in a class definition:
name – Identifies the class name. The name value can correspond to an <ObjectClassDefinition> element in an SPML schema, although this value is not required. You can use this name as the value for the objectclass attribute in an AddRequest or a SearchRequest.
type – Defines the Waveset view type used to manage instances of this class. Generally, this attribute is User, but it can be any repository type that is accessible through a view. For information about views, see Oracle Waveset 8.1.1 Deployment Reference.
form – Identifies the name of a configuration object containing a form. This attribute contains the rules for transforming between the external attributes defined by the class and the internal view attributes.
default – Specify true to indicate that this attribute is the default class for this type only. For more than one SPML class implemented on the same type, you must designate one class as the default.
identifier – Each class typically defines one attribute as the object identity. The identifier attribute in the class definition specifies which attribute represents the identity. Where possible, use the identifier attribute value as the name of the corresponding repository object you create to represent the instance.
filter – When evaluating an SPML search request for a class, you typically include all repository objects associated with that class in that search. This approach is fine for User objects, but some classes might be implemented by using generic types such as TaskDefinition or Configuration, not all of which are considered instances of the SPML class.
To prevent unwanted objects from being included in the search, you can specify the filter attribute. The value is expected to be an <AttributeCondition> element or a <List> of <AttributeCondition> elements. Because custom classes are typically created for the User type, using a filter is uncommon. The default configuration uses filters to expose a subset of the TaskInstance objects that are known to have been created to handle asynchronous SPML requests.
The schemas attribute contains a list of strings that contain the escaped XML for an SPML <schema> element. If you examine the spml.xml file, note that the schema elements are surrounded by a CDATA-marked section. Using CDATA-marked sections is convenient for escaping long strings of XML. When Waveset normalizes the spml.xml file, the CDATA-marked sections are converted into strings containing < and > character entities.
The default SPML configuration includes two schemas:
A standard schema that is being defined by the SPML working group.
A custom schema that is defined by Waveset. Do not customize these schemas.
The Waveset schema contains a class definition for request and various extended requests for common account management operations.