In the previous two posts we looked at planning, implementing, and supporting a virtual directory environment in the context of Larry Aucoin's Top 10 Laws Of Virtual Directories. As the final installment of our series discussing his blog articles, we want to consider the topic of internal development. While this obviously includes planning, implementation, and support we see it as a separate and important group because it is orthogonal to all these aspects of a virtual directory infrastructure.

• Law X: A Virtual Directory MUST NOT require custom coding

We think this last law is only partly true. A virtual directory should provide the functionality to resolve most problems without requiring custom code. In our experience, Symlabs Virtual Directory Server deployments are handled using out-of-the-box functionality 99% of the time. The extensive list of included plug-ins that can easily be incorporated out-of-the-box into a configuration is the key to this.

All of our plug-ins are developed in a simple scripting language that allows a client to review the code and understand what it is doing, which means it's also easy customize. And, providing the option to quickly develop custom code puts power in the hands of the customer. It means that solutions can be developed which cater to very specific requirements, and also that the efficiency of solutions can be optimized. But, a 'one-size-fits-all' approach does not work - it results in bloated and inefficient systems that attempt to handle every possible scenario that anyone could think up, but almost always miss one that is unique to your situation.

In our hands-on experience with actual deployments, we have faced and solved many situations where client LDAP applications did not behave well. In most situations, the application behaved in a manner that was fairly unpredictable such that it's unlikely a virtual directory vendor could have anticipated it and coded a solution beforehand. It seems that sometimes there is no way to predict some problems, you simply must find them. You could choose to wait and see if any virtual directory vendor will release a product in the future that deals with your particular issue, or you could take advantage of a virtual directory that allows you (or the vendor) to quickly develop a custom solution that matches your own specific requirements.

By providing the option to develop custom code, problems are resolved quickly and efficiently. There is no need to wait for a vendor to provide a patch or new release. A unique solution can be coded for your requirements without affecting the core of the virtual directory server code, and you can code them yourself if you choose. Our DirectoryScript API is thoroughly documented and includes a very simple Scripting Guide which ensures that you can always take control of your own solution. It's important not to be wholly dependent on a vendor in uncertain economic times - what do you do if a product is locked up and suddenly you don't have access to the all pieces that create functionality you rely on heavily.

Finally, the ability to code your own solution means that you won't exhaust yourself trying to fit a square peg into a round hole. Vendors naturally try to think up the issues that you might want to resolve before you ever get to them, but often the result is that you are forced to solve your particular problem using a tool that isn't designed expressly to fit the specifics of your environment. Most of the time that's not a problem, otherwise we would never even bother to provide any plug-ins at all. But, every so often you find yourself confronted with a situation where the standard plug-ins just don't fit.

So, we think Law X should really read:

• Your Virtual Directory Server should solve most of your problems out-of-the-box, AND
  should also be extensible and capable of modifications to suit your unique requirements

Fernando García Vegas

This continues our examination of the Top 10 Laws Of Virtual Directories that recently appeared on Larry Aucoin's blog. As we discussed them internally and considered how our products stacked up against them, they seemed to fall naturally into three groups. Now let's look at the second grouping - implementation & support issues.

• Law IV: A Virtual Directory SHOULD NOT take long to deploy

This is definitely true. At the end of the day, we're talking about installing some software and creating a configuration that will resolve a given set of problems. As long as the scope of the solution has been clearly defined, we find that Symlabs Virtual Directory Server can be deployed in as little as one hour and normally less than a week.

Most customers like to engage in pretty thorough testing before launching a virtual directory within a production environment, and this often takes time which needs to be accounted for. But, once they see a deployment in action, it is fairly common for customers to become aware of the full potential of the product. With a whole world of new possibilities available, many of them start to change the scope to take advantage of additional features, and this can cause a deployment to drag out.

It is important to be aware that these are not time constraints imposed by the virtual directory product itself, but are the normal outcome when you deploy a new component within your infrastructure and need to be sure that it works the way that you intended.

• Law V: A Virtual Directory SHOULD NOT increase administration costs

Absolutely - almost a corollary of the first law. For our example, Symlabs Virtual Directory Server is very simple to configure and manage from within a friendly GUI environment. In fact, the many improvements that it brings to an environment means that in addition to not needing dedicated people to manage it, you also reduce the cost of managing other infrastructure components as well.

• Law VI: A Virtual Directory MUST NOT have a large footprint

This is also quite true. Symlabs Virtual Directory Server only requires around 4 MB of disk space, so we have this one covered. Our text-based LDIF configuration files require no registry entries and ensure that configuration can easily be moved from one instance to the next as required. Much of the processing functionality that the product can be directed to perform is also text-based, in the form of simple scriptlets that clients can easily modify or customize to work in very particular situations.

The core engine required to run a Symlabs Virtual Directory Server instance is coded in portable C and compiled to run on a variety of operating systems, thus avoiding the requirement for additional software to be installed on your system. This also means that our product is highly efficient and offers tremendous performance with less impact on your CPU.

• Law VII: A Virtual Directory MUST NOT be difficult to support

Another one we completely agree. In our case, Symlabs Virtual Directory Server uses the same code base for Windows 2000, 2003, and 2008, plus Linux, Solaris Sparc, and Solaris x86 as well. This is is one of the benefits of writing code in portable C. Our products can be run on the platform of your choice and, because the code is the same, we have no problem providing support regardless of the environment you run them on.

Furthermore, many of the features built into the product, such as the ability to easily import and export configurations, scriptlets, and log files, make it possible for our support staff to quickly evaluate problems in your configuration instance and resolve them efficiently - without any need for you to get your hands dirty.

• Law IX: A Virtual Directory MUST NOT introduce too many proprietary elements

This goes hand-in-hand with Law VII. If your solution is cobbled together using too many proprietary elements it will quickly become unsupportable. This is why we like to code from the ground up. Symlabs Virtual Directory Server does not introduce any proprietary data store, caching, or ports, and where we have introduced external libraries, we have tried to keep to open source implementations (such as the OpenSSL libraries). This ensures that if there is a problem that needs urgent resolution, we are not dependent on an external vendor to resolve it. Symlabs is a strong supporter of standards, believes in helping to ensure that they are followed, and has staff actively contributing to the definition of specifications that provide the framework for open standards.

Fernando García Vegas

Recently Larry Aucoin, a co-founder of Optimal IdM, posted an excellent two-part article entitled Top 10 Laws Of Virtual Directories on his blog. Larry's points are well thought out and make a lot of sense, and prompted much discussion within our team. As a result, we've come up with a few thoughts of our own about each law, particularly with regard to Symlabs Virtual Directory Server and LDAP Proxy, and (not to be out-done) are kicking off a three part series here to share them.

Actually, it's a three part format not for any competitive reason, but because our discussion generated a lot of ideas, and also we'll review Larry's laws in groups that correspond to activities rather than in numerical order. So, let's start by looking at ones that involve planning a virtual directory infrastructure.

• Law I: A Virtual Directory MUST REDUCE complexity

This is pretty much a no-brainer. When things are done well, they tend to be simple. Virtual directories are usually implemented in response to some complex infrastructure problem, and their goal is to help remove the complexity. If this isn't happening, you're doing something wrong.

• Law II: A Virtual Directory MUST NOT create more issues than it solves

We wholeheartedly agree. In fact, Symlabs Virtual Directory Server and LDAP Proxy are designed around the idea of minimal interaction. This means the virtual directory should only have an impact on those requests and responses that require modification. Any other traffic should be left completely untouched. Our products provide enough granularity to specify exactly what to change, so that only traffic related to this modification will be affected. Working only on the elements that need modification ensures that you are working to resolve your target problem, not introducing a range of new problems to your environment. After all, if its not broken, don't try to fix it.

• Law III: A Virtual Directory SHOULD NOT be asked to solve ALL identity related issues

There is no 'one size fits all' solution. As Larry points out, federation servers, synchronization engines and virtual directory servers are tools that can be used to solve specific types of identity issues, just like provisioning systems, workflow managers, etc. We offer separate federation product for clients with diverse requirements because we're aware that different tools serve different purposes.

It's worth adding here that, while a virtual directory server shouldn't be asked to solve all identity-related issues, you also shouldn't have to pay for a whole set of features that you don't require. This is the reasoning the led us to offer Symlabs LDAP Proxy at a lower price point - so that clients who only need to resolve LDAP-related issues can avoid having to pay for added capabilities they don't need.

• Law VIII: A Virtual Directory MUST be a VALUE ADD

Nobody should disagree with this statement. After all, who would intentionally buy a product that subtracts value? Both Symlabs LDAP Proxy and Virtual Directory Server offer a massive range of additional functionality that enhances any LDAP infrastructure, even extending it so that it is capable of integrating with alternate systems. They provide the ability to add unique business logic to your data through a large set of plug-ins that can be arranged in a processing pipeline which will deliver any result you want. All of the plug-ins are developed in a simple scripting language and can be modified to fit your particular requirements, so their limits are boundless. You can make use of this functionality out-of-the-box, or invent your own. This is the best possible value that you can add, the ability to be in control.

Fernando García Vegas