Sometimes I get confused within Novell Identity Manager, as there are many moving parts with multiple bits and pieces to contend with.
If you have not read through David Gersic's excellent series on the basics of how Identity Manager works, then you really should.
David does a great job of taking the typical iManager or Designer view, that you would see when working on an Identity Manager project and walking through it item by item.
The primary difference between the iManager and Designer view, would be that in iManager to 'fishbone' diagram is laid on its side, right to left, left to right, and in Designer it is top to bottom. Personally, Designers approach works much better for me, as I am a smidgen right-left dyslexic, but can remember up and down directions much better. (I find gravity more digestible than right and left, go figure!)
On top of all the policies, and their order or execution, and why they execute, that David explains, there is further complexity in the use of DirXML Script to write any of the rules.
There is lots of content on the topic of using DirXML Script, more than is worth linking too, but the nice thing is that the names of the various tokens are pretty good. For example, the send-email Action you see in Policy Builder seems pretty straightforward (which is really a <do-send-email> token) and really is. Some subtly exists, which the help is actually often pretty good at dispelling.
Thus most of the articles you will see talking about tokens specifically, will focus on the subtle stuff, that does not really make it entirely into the documentation. For example:
These first two, discuss the subtle and important differences between the Attribute, Source Attribute, and Destination Attribute tokens as well of the benefits of using each.
Here are some more generally interesting token articles that can be helpful.
On top of the policy flow, DirXML Script, there is a further lower level concern.
The basic unit in Identity Manager is an object. Probably the lowest level is the Policy object (could be a Style sheet object, or a Mapping table, or a ECMA Script object, but you get the idea).
These objects exist in containers. There is a pair, the Subscriber and Publisher containers, meant to corral the appropriate objects into reasonable locations, to make finding them easier.
With the release of Identity Manager 3.5 and the change in policy linkage, it is possible to store them pretty much anywhere inside the driver set (heck you could probably get it to use an appropriate object anywhere in the tree, but I have never really tried that). This is pretty common in the use of Library objects now, so that one set of rules could be used in multiple drivers.
The Subscriber and Publisher containers exist below the Driver object. At the same level is usually the Schema Map, Filter, and Input/Output transforms.
Drivers reside inside Driver Set objects. The Driver Set object is often made into an eDirectory partition boundary. I happen to strongly disagree with the interface in Designer and iManager that defaults to creating the Driver Set object as a partition if you are not careful. That it should be a partition, I understand the reasoning. That it should be a default, I think is a mistake, because before you partition an eDirectory tree, you should check and be sure that the tree is healthy, time is syncing, servers are communicating, and what not. Otherwise, you are opening your self up to a world of hurt.
Driver Sets are assigned to servers, which are the where the actual Identity Manager binaries are executed.
Now there comes a little bit of complexity.
One server can host only one Driver Set at a time. One Driver Set can be hosted by multiple servers. One Driver Set can contain multiple drivers. Each driver should only run on a single server at a time (though in principle they could run on more than one at once, which probably would create bad end results).
Now was that clear?
The key is: A Driver Set can be assigned to multiple servers. However a single server can only host a single Driver Set.
Even that has a quibble, since one physical server could host multiple virtual machines, each with an eDirectory instance, or on Unix/Linux even host multiple eDirectory instances on a single server instance. Perhaps a better criteria is that a single eDirectory instance can only host a single Driver Set at a time.
Thus many drivers can be in a driver set, on several servers, with any combination of drivers running on any of those servers.
The servers can be any platform that eDirectory and Identity Manager is supported on, such as Windows, Netware (pre 3.6 alas, since Java 1.5 which IDM 3.6 relies on, has not been back ported to Netware), Solaris, Linux, and AIX.