How SPML 2.0 Concepts Are Mapped to Waveset
SPML 2.0 uses its own terminology to discuss the objects that are managed by a provisioning system.
Note –
See the OASIS SPML 2.0 specifications at http://www.openspml.org/.
The following sections describe how SPML 2.0 concepts are mapped into Waveset:
Understanding Targets
A target is a logical end point in the server. Every target is named and declares the schema of the objects that it manages. Targets also declare which capabilities (a set of requests) are supported. See Understanding PSOs for more information.
Currently, Waveset supports only one target. You cannot declare multiple targets. You can name this target anything you want, but the data objects’ format must conform to the DSML profile.
A supported target is the one target defined in the spml2.xml file (Configuration:SPML2 object). For example, in ListTargetsRequest Examples, ListTargetResponse returns one target, spml2-DSML-Target.
Understanding PSOs
As mentioned in the previous section, targets manage Provisioning Service Objects (PSOs). A PSO is somewhat analogous to a view in Waveset, but without behavior. Consequently, you can think of a PSO as the data portion of an Waveset view, a User view in particular.
Note –
Waveset only manages Users and requires you to define a user extended attribute called spml2ObjectClass.
For Waveset’s purposes, a PSO is a collection of attributes that are mapped (using a form) to and from a User view. Each object specifies an objectclass attribute that is used to map the object to an objectclass definition in the schema defined for the target.
The objectclass attribute is used to find the following:
-
A repoType that is provided to support additional targets later
-
A form that maps the attributes to and from the Waveset view
Understanding PSOIdentifiers
SPML includes an object ID that is called a PSOIdentifier (PsoID).
OASIS SPML 2.0 specifications recommend that PsoIDs be opaque to a requestor (client). Consequently, Waveset uses repository IDs (repoIDs) as PsoIDs when adding PSOs to the system.
A repoID is distinct and it is not meant for presentation to a user. When displaying a PSO to a user, the requestor should use the equivalent of the waveset.accountid or whatever attributes are used in the Identity template to present the object’s ID.
When identifying the PSO (as in a ModifyRequest), the requestor should use the repoID and not the waveset.accountId. Although the requestor can use the waveset.accountId as a PsoID, doing so is not recommended and it might change in a future release. Requestors should try to keep the PsoID opaque.
PSOs use an objectclass attribute to specify the object type. If this attribute is not present when a request is made, Waveset allows you to specify and use a “default” object class, such as SPMLUser. Internally, the objectclass value is maintained as an spml2ObjectClass attribute for users. For Waveset this attribute must be a user extended attribute. You might not see an spml2ObjectClass attribute for users that existed before you enabled SPML 2.0.
Understanding Open Content and OperationalAttributes
SPML makes heavy use of xsd:any elements in the .xsds file to provide what the specification refers to as Open Content. In SPML, Open Content means that most elements can contain elements of any type. Waveset uses this idea to provide OperationalNVPs (NameValuePairs) and OperationalAttributes that control processing. OperationalNVPs appear as elements in the XML, while OperationalAttributes appear as attributes. See the OpenSPML 2.0 Toolkit at http://www.openspml.org for more information.
You can use one NVP in all requests except ListTargetsRequests, and in all responses. Waveset stores a sessionToken in an OperationalNVPs called session that allows the system to cache sessions on behalf of the user and improves efficiency. For more information about OperationalNVPs and OperationalAttributes, see Supported SPML 2.0 Capabilities.
- © 2010, Oracle Corporation and/or its affiliates