Now that we’ve covered the terminology, we show how ILM uses its own web services. We hope by illustrating ILM’s own dependence and commitment to web services, you will agree the web service interface is an important piece of the product to understand.
There are three supported ways to create, read, update, and delete object instances in ILM:
Because numbers 2 and 3 use the web services “under the hood,” we will focus on web services initially in this blog. For background, let’s talk about how the other two supported ways use web services.
The ILM Portal actually is a “smart” web service client that provides a great web experience for accomplishing identity-management tasks like you’ve read in the brochure. The portal uses only the public web service interface that you and everyone may program against. This decision was by design: we wanted any 3rd party to be able to create a “better” portal experience to suit their needs. It is possible to recreate our portal using only knowledge of ILM’s web services and ASP.NET. Every operation in the portal gets translated into a straight-forward series of web service calls. For example, “Join Group” is simply a WS-Transfer Put request on the group’s members attribute (we’ll go into more detail later and even show examples). Feel free to turn on WCF message tracing in the ILM Service to reverse-engineer the portal calls. There is no “secret sauce” in the ILM portal.
The ILM Synchronization Engine should really be thought of just another component of ILM. However, for those of you with MIIS backgrounds, you will correctly recognize that the sync engine is distinct from the ILM Service. The default connection between the ILM Service and the sync engine comes from the ILM Management Agent (ILM MA). The ILM MA makes web service calls when flowing data with the ILM Service. For example, if an authoritative HR system creates a new person, the ILM MA will make a web service WS-Transfer Create Request to make a new Person instance in ILM. Again, please turn on WCF message tracing in the ILM Service to watch ILM MA web service calls.
From these short descriptions, we hope that it is clear how ILM’s web services play a key role in most ILM scenarios. Even if you don’t plan to write code for our web services, we hope you take time to learn them from our upcoming posts in order to diagnose issues better. Finally, I’d like to make the point that the crutch of diagnosing all issues is System.Diagnostics tracing in the .NET framework. I recommend using both WCF’s trace sources and ILM “2” RC’s trace source “Microsoft.ResourceManagement”. Please be advised we may change this trace source name for RTM and it is not supported.