Terminology used in ILM
Before we begin and following Craig’s lead, I’d like to be clear on ILM’s terminology. The reason for this is we use overloaded terminology when discussing ILM concepts that have important connotations in other contexts. Depending on your background, these connotations either feel “wrong” or “right.”
Attributes
An attribute is the smallest unit of information ILM can store. An attribute has a simple data type (string, integer, Boolean, reference, etc.) and a value. We refer to attributes by name like “First Name” or “Employee ID.” For people with LDAP or AD backgrounds, think of these as directory attributes. For people with XML backgrounds, think of these as simple child XML elements.
An attribute can be single-valued or multi-valued. This distinction is profoundly important. A single-valued attribute is one simple data type. A multi-valued attribute is a collection of homogenous simple data types. I like to think of multi-valued attributes as arrays. We use single-valued attributes to store a person’s display name or email address, whereas we use multi-valued attributes to store a group’s members. Each simple value in the multi-valued group membership attribute represents a member.
Objects
An object is a collection of attributes. We refer to objects by their name like “Person” or “Group.” For people with LDAP or AD backgrounds, think of these as directory objects. For people with XML backgrounds, think of these as parent XML elements with child XML elements representing attributes.
Attribute Bindings
An attribute binding maps an attribute to an object. These bindings create the collection of attributes, describe the validation rules, and define whether the attribute is required. Because of decoupling attributes from objects, it is possible to define one attribute and use it for multiple objects. This becomes very useful for reused data like “email address” which has the same data type, validation rule, and attribute name regardless on which object the email is stored. To be clear, validation can exist on each the attribute definition and the attribute binding. A valid value must satisfy both validations.
Think of a customer who has Person, Group, and Customer objects in ILM. It is reasonable to expect each object to have an email address. Attribute bindings enable an ILM admin to define the email attribute and set the validation rule (e.g. an email address must include an ampersand) exactly once. exactly once.
Then the ILM admin creates 3 attribute bindings to map the email attribute to each the Person, Group, and Customer objects. If the admin wishes to refine the validation to restrict email addresses to only “.com”, the admin must update only one validation rule on the attribute. However, if the admin wishes to restrict email addresses to only “@contoso.com” for Person objects, the admin must update only one attribute binding. Using attribute bindings with separate validation rules makes ILM objects and attributes more maintainable.
Anecdote: One customer came across an issue importing HR data into ILM “2” RC. The customer had mapped attribute “Employee Type” to an attribute from a connected system. This connected system used abbreviations, say “F” and “V”, to describe whether the person was full-time or vendor. The out-of-box behavior of ILM “2” RC is to have two validation rules for Employee Type: one on the attribute and another on the attribute binding. These validation rules restrict the value of employee type to “Intern”, “Contractor”, and “Full-Time.” Since “F” and “V” are not included in this validation, the customer could not use those abbreviations out-of-the-box. The customer noted this and made a change only to the attribute validation, omitting the corresponding change to the attribute binding validation.
When the sync engine tried to flow in data from the connected the system, the customer unexpectedly got errors. The root of the problem was -- as we hinted above – that we forgot to modify the attribute binding validation as well. Be warned: attribute bindings and attributes work very well together, yet you must be mindful of the validations on each.
Object Instances
An object instance is a living object in the system. While attributes, objects, and bindings all define the structure and type of data ILM may store, an object instance stores the actual data. We refer to object instances by ObjectId (a unique identifier). An object instance much match the schema defined by the objects, attributes, and attribute bindings. We say that the Object Instance validates against the schema provided all attribute values contain the correct simple data types and satisfy both validation rules.
Schema
A schema in ILM is the sum total of attributes, objects, and attribute bindings. It represents the comprehensive view of what an ILM object instance should look like. I tend to think of this as XML Schema since we represent ILM objects as XML elements over the wire and can represent our validation rules as XML Schema restrictions.
XML Element
An XML element is how we will refer to elements in an XML document. For example, in <Person/>, “Person” is an XML element. We prefix the word “XML” to signify that element in this context comes from the XML specification. If we fail to prefix “XML”, we most likely mean elements returned in an enumeration call or even objects in ILM. We will strive to be precise.
XML Attribute
An XML attribute is how we will refer to attributes in an XML document. For example, in <Person attrib=”Value”/>, “attrib” is an XML Attribute. We prefix the word “XML” to signify that the attribute comes from the XML specification. If we fail to prefix “XML”, we most certainly mean an attribute in ILM.
ILM Service
This is the ILM component that exposes web services. Please note that ILM has multiple services: the Certificate Lifecycle Manager service, the Synchronization Engine service (previously called MIIS), and the new ILM Service. The .NET namespace of the ILM Service is Microsoft.ResourceManagement to signify that ILM and its web services are capable of managing arbitrary enterprise resources (persons, customers, computers, etc.). You may see later in our blog posts references to ResourceManagement or a ResourceManagementClient, which is our programmatic view of the ILM Service.