How Oracle Identity Manager Uses MDS

Oracle Metadata Services (MDS) is an XML configuration store used by Oracle Identity Manager (OIM), as well as several other Oracle Middleware products. OIM first adopted MDS with the release of 11gR1. Prior to MDS, many Oracle Middleware products used  files on the filesystem as configuration stores, in various formats (XML, Java properties files, etc.). One of the purposes of MDS to create a standard configuration store across the Middleware stack. Not all configuration in OIM lives inside MDS, however: some of it is stored in the OIM schema database tables.

One problem with the old approach, of storing configuration files on the filesystem (e.g. xlconfig.xml in OIM 9.x), is that in a clustered environment there is a risk of inconsistencies in configuration between the nodes, which may have deleterious effects. In OIM 11g, by storing the configuration in the MDS database schema, we eliminate this possibility.

The strength of MDS is in storing XML format configuration files. While it can be used to store binary format files also, OIM does not use it for that purpose. For the connector JARs and plugin JARs in OIM, rather than storing them in MDS, we instead store them as BLOBs inside database tables in the OIM database schema. However, once again, the possibility of cluster inconsistencies which existed in 9.x (where these JARs lived on the filesystem) is eliminated.

MDS is structured like a filesystem – it contains folders/directories (called “packages”) and documents (either XML format or binary).

One of the unique features of MDS is that it supports XML querying. It can quickly search the MDS repository for all documents containing a given XML tag. This then allows configuration to be spread out across multiple packages (reflecting e.g. the module structure of the application). However, while this is very useful, it can become a trap for the unwary – some customers have accidentally uploaded backup files (e.g. EventHandlers.xml.bak) into their MDS repository, thinking that they will be ignored due to the .bak extension. However, OIM uses an MDS XML query to locate event handler definitions, which ignores the file names, hence their backup file gets loaded.

When used with the database schema backend, MDS stores the change history. This feature has existed in MDS since the very beginning of MDS uptake in OIM, with OIM 11gR1 base release. However, until 11gR2, we did not use this functionality in OIM, nor did our tooling or documentation encourage customers to use it (they still could if they were aware of it.) With 11gR2, as we will discuss more shortly, that has changed.

We split up the MDS repositories on a per-application basis – in 11gR1, this means that OIM, SOA and OWSM each get  their own MDS repository. Keeping the configuration of each application separate eases administration, and avoids any potential issues of interference between them. Rather than requiring three separate MDS schemas, MDS supports the partitioning of a single schema into several partitions. So in OIM 11gR1, we use 3 MDS partitions in our MDS schema. (In 11gR2, we add an additional partition to store configuration of the OIM ADF-based UI, as opposed to configuration of the core OIM server.)

OIM 11gR2 brings a number of new features to OIM’s use of MDS. These are not actually new features as far as MDS is concerned – they existed in MDS in OIM 11gR1, and some other Oracle Middleware products were already using them. But OIM 11gR1 did nothing to leverage or exploit these MDS features, while OIM 11gR2 does so.

MDS contains two key features related to version control. The first of these is the notion of labels. A label enables us to assign a memorable name to a version number. For example, suppose I am deploying a new version of some customization that I have developed for OIM, let’s say version 3. I might create a label called “v3-PreDeployment” to mark the state of the configuration immediately prior to the deployment, and another label called “v3-PostDeployment” to mark the state of the system immediately afterwards. If you are familiar with version control systems commonly used for source code – such as CVS, Subversion or Git – an MDS label is essentially the same thing as a tag.

The second feature is the notion of sandboxes. This is equivalent to working copies in version control systems, although it also has some similarities to the notions of changesets or branches. You can create a sandbox to isolate work in progress from the live production configuration. The sandbox is only live for administrative/developer users; once you are satisfied with the sandbox, you can make it live by merging it in to the main configuration. MDS automatically creates pre and post merge labels for you.

The other major area in which OIM 11gR2 takes up more MDS features is in the area of customization. The customization feature in MDS is designed to allow a clear separation between data which is shipped out of the box and data which is customized at a customer site. This helps avoid the common experience where applying a patch or upgrade to out-of-the-box data results in loss of customizations that then need to be reapplied.

The customization feature is particularly used with ADF. We can store a page definition in MDS for some page in OIM, e.g. “Create User”. You can customize the page, but rather than directly modifying the out-of-the-box page definition, you create a customization XML which contains instructions on how to modify the out-of-the-box XML. (Rather than manually creating this customization XML, it is created for you when you use the ADF Composer component.) When ADF asks MDS for the page definition, MDS merges the customization XML with the out-of-the-box page definition. If in a patch or upgrade we change the page definition XML, we replace the base file, but your customization XML is untouched. This greatly reduces the risk of losing customizations during patch/upgrade.

Add Your Comment