Tag Archives: C++

SPML and DSML search filters not so hard

One issue that has been raised in regards to SPML is search filters. SPML allows searches that optionally specify a starting point (in terms of an SPML container), a subset of data to return, and a search filter. In the DSML Profile, the search filter is naturally a DSML filter.

DSML filters can be arbitrarily complex, just like the LDAP filters they model. For instances a DSML filter could be something like “get everyone with the last name of smith”, or in DSML:

<filter xmlns=’urn:oasis:names:tc:DSML:2:0:core’>

<substrings name=’Name’><final>Smith</final></substrings>

</filter>

Or it could be “get everyone with last name smith not located in Orlando”:

<filter xmlns=’urn:oasis:names:tc:DSML:2:0:core’>

<and>

<substrings name=’Name’><final>Smith</final></substrings>

<not>

<substrings name=’Office’>

<final>Orlando</final>

</substrings>

</not>

</and>

</filter>

Now if your back end data is stored in LDAP, then this is pretty easy to handle. Just convert to an LDAP filter and do any attribute name mappings required. If you backend data is SQL, it just slightly more difficult to translate the DSML filter into a SQL query clause.

But what if your back end data store doesn’t support a query mechanism? What if the data is in a flat file, or a NOSQL DB? What if the data is only accessible through an API that doesn’t allow for filtering?

There are several ways to solve that problem, but the easiest is to recursively walk the DSML filter and create a decision tree where each node determines if a given instance passes the part of the filter it knows.  The code for this is pretty simple in .NET and I posted an example here. Note that this example is just a partial implementation of the SPML search request for the purposes of demonstrating this concept. It is not a full featured implementation of SPML.

The basic idea is that an abstract data provider would return a dictionary of the attribute values for each entry in the data. The interface could look like (in C#):

public interface IUnfilteredDataProvider {

List <DSMLData> DoUnfilteredSearch();

}

In this example the sample data provider reads entries from a flat file. On each search request the filter is recursively read and turned into nodes in a decision tree. Each data entry is then passed to the decision tree and if it passes the filter it is appended to the returned results:

List<DSMLData> dataList = this._unfilteredProvider.DoUnfilteredSearch();

DataFilter df = GetDataFilter(searchRequest);

List<PSOType> returnPSOs = new List<PSOType>();

// return only those entries that pass the filter

foreach (DSMLData data in dataList) {

if (df.Pass(data)) {

returnPSOs.Add(data.GetPSO());

}

}

The GetDataFilter method walks the DSML filter and constructs a decision tree (feel free to download the sample and look at the code for more details). No special meaning given to any of the attributes returned by the provider. They are all just treated as DSML attributes. Of course you will note a potential scalability issue with large data sets, but there are several tricks that can be used to minimize that (thoughts for a later post).

Oh, and this approach works great for creating a DSML service as well and the general concept would be just as easy to implement in Java.

So what does all this mean? Supporting filtered searches in an SPML or DSML service is really not that hard, even if your data is stored in a data store that does not support filtering.

Phillips versus flat-head, for real this time

A while back I wrote this post comparing the argument between Virtual Directories and Meta-directories to an argument comparing Phillips and flat-head screw drivers. I forgot about it until I noticed something interesting. Somehow a lot of readers found there way to the post from a thread comparing Java and C#. But another group of readers found arrived by searching for, oddly enough, information about Phillips versus flat-head screws.

Now I have no more interest in getting involved in the Java versus C# language debate than I am in the Virtual Directory versus Meta-directory debate.

But Phillips versus Flat-head screws? Boy have I got some opinions on that.

If you have to work with existing screws your choice has already made for you (just as if you join a project in progress you seldom get to choose between Java and C#). But if you are starting a project from scratch, you not only have to choose between Phillips and Flat-head, there is also Torx (the commercial name for hexlobular internally driven screws), square, hex, Allen (internal hex), one-way-flat-head, spline drive, etc. Just as you might consider more choices than Phillips and flat-head, you might also consider a myriad of programming languages in addition to Java and C#.

But some are clearly superior to others in certain aspects. Flat-head screws have more driving power than Phillips head screws (Phillips head screws are designed to cam-out to prevent over tightening, an intentional design feature). But flat-head screws are much harder to drive by hand due to tool slippage. This is an interesting analogy to  the ease of development of C++ versus both Java and C#.

Allen and hex head screws have even more driving power than flat-head screws and are easier to user, but suffer from the limitation of needing have the exact size tool to fit the specific head size, whereas flat-head screws can accommodate a wide variety of tool sizes. This is similar to how scripting languages are often limited to use in a specific framework.

Wait, am I still talking about screws?

An old favorite gets acquired

Before I was in the Identity Mgt space I developed network management software. I was one of the developers of a very cool SNMP management application generation tool called Taboret. It allowed a user to bring up the MIB for a SNMP agent in a browser and drag and drop MIB elements onto a form to create a custom management application for the device.

The Taboret system was developed in C++ and was supported for Solaris, HP-UX, AIX, and Windows-NT. For the user interface we used a very nice multi-platform GUI library called Ilog Views. I always liked Ilog, a French company. They wrote very nice software libraries.

I just read that Ilog has been acquired by IBM. Good for them.