LighthouseContext in Service Provider

This section describes how the LighthouseContext is used differently within Service Provider.

Object Locks

Service Provider does not support object locks.

Do not use the following methods, which are defined in the ObjectSource interface:

• lockobject

• unlockobject

• getLock

• breakLock

Persistent Object Queries

If you are writing a generic repository browsing application, you will need perform searches to discover the objects in the repository. There are two styles of searches, a listing search (listObjects), and a fetching search (getObjects). A listing search retrieves the name and a few attributes of the object, but does not bring the entire object into memory. A fetching search loads the entire object into memory.

You should always use listing searches when querying IDMXUser objects, because there can be a large number of users in the directory.

The listObjects, getObjects, and deleteObjects methods recognize an options map argument, in which search criteria and other options may be specified. When building an options map, it is recommend that you use a set of constant string objects. The following table lists the valid query option names and their corresponding constant object.

Service Provider enforces a maximum number of results that a query can return. This maximum is specified by the maxRows option.

User Objects

Since Service Provider users are also persistent objects, you can create and modify them in the same way as configuration objects. While this is the fastest way to create users in the directory, it is important to understand that the provisioning of resource accounts does not happen when you use the persistent object methods. If you want to perform provisioning you must use the IDMX User View and the view methods.

The IDMXUser class is a subclass of Composite, which provides a generic model to represent an object with a collection of attributes, assignments to resources, and links to the associated objects on those resources. The structure of the IDMXUser class is similar to the Oracle Waveset WSUser class, but the field and method names are slightly different, because the model is intended for use with entities other than user accounts.

The following table shows the correspondence of some of the major classes and field names in the two products.

When you set the attributes of an IDMXUser, it is important to know how these attributes are being mapped to attributes in the directory. This mapping is defined by a Resource definition in the repository, which is named Service Provider End-User Directory in the examples.

This resource is available in Oracle Waveset by default. The resource has a schema map set up to work with the Service Provider example end user pages.

The full DN of this user will be built according to the identity template defined in the resource. If you want to assign a DN whose structure differs from that in the identity template, call the setIdentity method to specify the full DN.

Any attribute that you set on an IDMXUser that is not defined in the directory schema map will be stored as an extended attribute. Extended attributes are stored in the XML blob with the other object metadata, they are not directly accessible in the directory.

When you no longer need a persistent object, it may be deleted to reclaim space and reduce clutter in searches. Service Provider does not perform reference checks before deleting an object. This means that it is possible to delete a Resource object, for example, while that object is still being referenced by a Role object.