Windows SharePoint Services v3's Features - Aspect-Oriented Administration?

If you're not familiar with Aspect-Oriented Programming (AOP), its basically a mechanic that allows you to inject code in strategic locations even after the destination code has been written. This is different than creating a pluggable architecture that deliberate holes in it that are meant to be filled by additional code later. The reason for this difference is that in AOP, the original author of the code may have absolutely no knowledge whatsoever that it will be extended later using AOP. In a pluggable architecture, the code author creates discrete extensibility points and typically provides a sandbox API in which the code plug-ins can function. As an example, AIM is nothing more than a messaging plug-in for the popular IM client Trillian. The Trillian code exposes certain aspects of its object model to the messaging plug-ins and the extensibility point is well defined.

On the other hand, AOP extends at a much lower level by injecting code in various places. You might use AOP to log the execution of every method in a given namespace to a text file. Typically, if you want to log method execution, your code has to be aware of that and you have to manually add calls to a logging mechanism every time you write a method. With AOP, you can take methods that have no logic for logging and add a logging aspect to those methods, either at the beginning of the method or at the end or both. In typical AOP implementations, you create an aspect, which is basically a block of code, and then you define a mask that indicates to the AOP compiler (or runtime, depending on implementation) which code needs to be aspected with the code you wrote. In this case you might say that all public non-static methods need to call RecordLogStart() at the beginning of the method and RecordLogFiniah() at the end of the method.

Features are a new feature (yes, I know the recursive nature of that naming is annoying...but its all I can come up with) of SharePoint 2007. Basically, SharePoint has exposed a bunch of extensibility points that allow you to "light up" new functionality. These extensibility points are fixed and well-defined, so the flexibility is less than a true AOP implementation. However, what you can do with those extensibility points is completely up to you and limited only by your imagination and your coding ability. If you want to have a site that contains a List that supports IT support requests then you can simply create a feature that contains the schema and code necessary to accomplish that and install the feature in the farm. After that, any site that wants that functionality can simply turn it on. In previous versions of SharePoint, you would have to create a custom site template in XML that contained the list and the schema definition. If another site type wanted to have the IT request functionality, they would have to go through the tedious process of copying the XML code from one site template and pasting it into another.

With features you can just package up the re-usable functionality into a single directory, deploy it to the 12\Template\Features directory, install the feature using stsadm and then turn it on wherever you feel its appropriate. Not only does this allow you to add features (aspects) to your sites in a live, dynamic fashion, but it allows the same set of code to be re-used among sites that don't share the same template. This is incredibly huge and I think at the moment that next to the Business Data Catalog, Features and Solutions (cab packages containing feature definitions) are probably the most underrated pieces of functionality available in SharePoint 2007.

As a programmer, Features and Solutions appeal to virtually all of my senses in a way very similar to the way AOP appeals to me. They reduce the amount of code I need to write. They reduce the complexity of the code that I need to write. They allow me to re-use the same code more than once in any number of locations, regardless of the site template of the site activating the feature. I can deploy Features in a single cab file representing a custom Solution, allowing me to create a Solution once and then deploy it to the entire farm automatically without having to manually run an MSI on each web front end server!!

For some hard-core examples of Features and programming with Features and Solutions, you'll have to wait until my book comes out ;) I need to keep some stuff secret before the book comes out, otherwise the book won't sell any copies and I won't be able to use my royalties to buy that Nintendo Wii I'm waiting for :)

tags: sharepoint  moss  wss  features  aop  

links: digg this    del.icio.us    technorati    reddit