58bits - Tech

UPDATE: 01/09/2008 - Met some people from Reuters at BarCamp Bangkok over the weekend. They were describing their frustration at having been forced to use SharePoint to build an external community and social networking site for financial analysts. I think I can see why they'd be frustrated with the choice. Although I'm NOT a SharePoint guru - SharePoint appears to me to be to ideally suited to internal corporate intranet activity - offering a really fast way to get a feature rich intranet up and running without any design or development costs. However for a highly customized public (or even private community - but external to the hosting organization) community - there are a  LOT of possible choices - and probably better choices too that will give the site the flexibility it needs in terms of design as well as architecture.

Original post...

Today I decided to go for it, and promote my Windows Server 2008 64 bit test box to a domain controller (using dcpromo). I then created two Hyper-V virtual Windows Server 2008 servers (joined to the domain); the first as a dedicated SQL Server 2005 database server, and the second as a SharePoint server. I've dabbled with WSS a little previously and had all the docs ready. Configuring the Windows Server 2008 domain and the SharePoint server all went surprisingly well.

Windows Server 2008 in particular has a very slick install, role management and feature configuration system - all run via Server Manager. The main and 'real' server has the Active Directory, DNS and Hyper-V roles installed. The two virtual machines have the application server and web server roles installed (the main box is a fairly decent spec Core2Duo with 8GB of RAM).

Configuring WSS correctly takes a little preparation and planning - but for a sandboxed lab installation - it's pretty straightforward. Here's a great five part tutorial on installing SharePoint, and here's a link to a SharePoint deployment book that you can download from Technet.

The first thing you need to know about any WSS deployment is that if you want to use a separate SQL Server 2005 server as your SharePoint configuration and content database - then you MUST install WSS as a server farm - even if you only have a single SharePoint web application server (also the account that it used to connect from the SharePoint server to the database server MUST be a domain account - hence the creation of the server domain first). If you choose a single server installation (as opposed to the server farm installation) then SharePoint will install the Windows Internal Database (SQL Server runtime) and everything will run from a single server without any options (as far as I can tell) to move content to a separate and dedicated database server in the future.

Now that I'm up an running - I'm really curious to take a look at the 'out of the box' features for WSS. WSS is free  - and at first glance I'm impressed with what's there - including content creation, document management, collaboration, calendars, tasks, wikis, and blogs. And this is all before a full Microsoft Office SharePoint Server installation. Here's a link to a comparison of the two. From the docs and feature comparisons you can see that WSS alone offers a lot of intranet and collaboration functionality; ideal for small to medium size organizations that have already made an investment in Windows desktop and server technology.

Although I've not spent a lot of time looking at intranet or content management systems (CMS), I have been following the blogosphere activity around Drupal, Joomla and other 'free' CMS applications. I've also watched the Telligent products mature - like Community Server and Graffiti CMS (Graffiti in particular is a very slick and easy to configure CMS and blogging platform for ASP.Net- perfect for small organizations and individual bloggers). I'll be looking at the Windows SharePoint Services Development Center as well, and if I can find the time - will take a shot at writing an experimental Web Part.

So if it all went so well, then why is the 'Missing SMTP Server' in the title of this post? Well I was 95% there - starting to get that warm and fuzzy feeling you get when a whole bunch of things just work - first time. I then tried to configure the SMTP server for SharePoint's outgoing email messages, and discovered that the SMTP server is no longer under the IIS snap-in - at least not for IIS7. It took a while for me to discover that it's now part of the Features node in Server Manager.

Select the Features node - and then Add Features (in right hand panel) and you'll see an option for SMTP Server. When selected you're also prompted to install the Remote Server Administration Tools and something called the Feature Administration Tools beneath which you see listed the SMTP Server Tools. I said ok to all of that... but could I find a snap-in or configuration option for the SMPT Server Tools anywhere? Well nope - not even after an hour of Googling and searching the docs for the SMTP Server Tools. Amazingly - the SMTP server re-appears under the IIS6 snap-in (as long as you've installed the IIS6 compatibility components) however after being prompted to look for the something called Feature Administration Tools and SMTP Server Tools - I figured I could be forgiven for looking just about everywhere BUT the original IIS6 snap-in. Argh...

Ok - well pain over - I'm still looking for a way to configure a local SMTP server with a smart host entry that also requires server credentials - since neither the WSS SMTP outgoing email server options, or the SMTP server (under IIS6) offer a way to relay mail to a server that requires authentication for outbound mail. I'd like to be able to use the SMTP servers at my external Webhosting service (WH4L) but they both require authentication for SMTP outbound email. Ah well - not a big deal compared to the rest - but it would be a nice way to finish things off.

SMTP server hiccups aside...WSS looks pretty darn good and it'll be fun experimenting with additional sites and features on my test installation.

I learn something new nearly every time I write code - whether in a small project or large.

I recently updated my online gallery component at http://www.58bits.com/otherblog/photos/home.aspx. One of my TODO: items was a rewrite of a VCR style pager I've used previously. What I wanted was a style like the one shown in the screen shot... similar to that used on many sites. I also wanted user friendly(ish), hackable URLs, with each URL truly representing a resource; resources that may have more than one representation. For example, what you see visually as a user visiting the site - is a page with either thumbnails or a preview on it. However if you're an RSS reader, or a slide-show plug-in, you'll be given an RSS/XML representation of the same resource.

So what did I inadvertently create by moving to the new pager style? A  RESTFul pager. By asking for pages using the HTTP GET verb (as opposed to my old VCR pager that relied on forms and POST - ok a bad move I know) - I now have URLs that look like this...

http://www.58bits.com/otherblog/photos/5cgg96ab3e6g/thumbnails/2/2x3/view.aspx

And I now have a good separation from the server implementation, and the client's perception of a resource via a cool URL, and one that won't change.

As an aside, I can also now do something intelligent with caching, telling the client whether the resource has been updated or not via ETags, last modified dates and HTTP 304 response codes, saving a ton of bandwidth while at the same time ensure that changes propagate.

I'm a newbie to REST as an architectural style and am currently reading a lot on the topic - but what I've found from my initial exploration is that if you've been programming the Web for a little while, you've been close to REST by default. Embracing the style to include other verbs (other than the ubiquitous GET) is not such a big step, and I'm looking forward to experimenting further.

Here's a link to an author that's produced a great presentation on RESTFul Web Services

A colleague just sent me a link to the MIX07 presentation of ASP.Net Dynamic Data Controls. I'd actually seen this demo before - but something about taking a quick second look made me want to blog about it.

Is it just me, or are there other people out there that kind of wince when they see these sort of presentations? (ignoring the obvious 'prop and holding' behavior of Mahesh Prakriya and his bottle of water).

The tools are definitely cool and I can see how these controls would be useful for knocking together a quick admin UI, or proof of concept app.  But the thing that kind of depresses me when I watch a video like this (with more powerful controls that let you build apps more quickly!) is the thought that there are 'developers' out there that will use this stuff and call themselves programmers - without knowing a whole lot about software development (principles - like searching, sorting, comparing, or how to build applications that are secure, transactional, and scale).

I sometimes wonder if we're headed back the good ol'days of VB6 where whole departments grew up without really knowing much about software development at all.

MS has an evangelical team, but frankly I'd like to see less proselytizing of how technology is going to make our software development lives so much better - and more holistic presentations that combine neat tools like this - with careful qualifiers that put the tools into the wider context of software design, quality and production issues.

I wrote earlier about my experiences using the Application Block Software Factory to create a new Application Block and Provider - it started well - and creating my first provider went fine.

Putting things into production was a slightly different matter.

Again the docs are thin - and it took a brief email exchange between myself, Tom Hollander and Fernando Simonazzi of Clarius Consulting to solve one problem I came unstuck with (no doubt attributed mainly to my first crack at ObjectBuilder and ABSF).

The problem I ran into relates to the ProviderData classes that are created by the ABSF. ProviderData classes are created for each of your providers and contain the configuration information required for your provider (read from the .config file). ABSF will also create another class in the source file for your ProviderData class - an Assembler class - ProviderAssembler. ProviderAssembler implements Object Builder's IAssembler interface and is responsible for handing back an instance of your provider, along with feeding any strongly typed settings to the constructor of your provider as required.

In broad terms - there are two ways to build classes from your application block using ObjectBuilder: IAssembler or using ObjectBuilder's generic CustomProviderAssembler method.

It's not immediately obvious that there are two provider creation strategies here or that there can be issues if you mix the two.

One is strongly typed - using your own Provider Assembler class. In this case any attributes you declare in your settings file....

<add name="Provider1" type="MyProvider, ProviderProject.Providers" databaseName="Test" specialProperty="Test" />

(databaseName and specialProperty) will be referred to in your ProviderData class as properties like the following...(just the databaseName attribute here)

private const string DATABASE_NAME = "databaseName";
[ConfigurationProperty(DATABASE_NAME)]
public string DatabaseName
{
    get { return (string)this[DATABASE_NAME]; }
    set { this[DATABASE_NAME] = value; }
}

During the call to your assembler's Assemble method - you can pass the values of these convenient and strongly typed properties into your provider's constructor.

However here's were I came unstuck.

For each of your ProviderData classes - there is also a BaseProviderData class - and at first glance this seems like correct place to place any provider properties that may be common to all your providers - with one very important exception.

The ABSF also creates a CustomProviderData class - which ALSO derives from the BaseProviderData.

CustomProviderData doesn't implement properties for configuration - it simply reads all the attributes in your settings and places them into a property bag (a name value pair collection) which will get passed into the constructor of your implemented CustomProvider. You then retrieve the settings from the NVC as you need them in your provider (casting into the required types for each attribute).

So...

<add name="Provider2" type="MyCustomProvider, ProviderProject.Providers" databaseName="Test" setting1="Test" setting2="Test" />

In this case setting1, and setting2 will appear in the NVC when received by MyCustomProvider's constructor - BUT - if the databaseName property was defined in the BaseProviderData class - it will NOT be included in the NVC. The NVC is built for 'unknown' attributes only and in the pattern of assembly provided in the ABSF - databaseName is now a 'known' configuration property (known by the BaseProviderData class) and so won't be included.

So - if you are considering offering the client the option to create their own custom providers (as opposed to pre-defined strongly typed providers in the block) - be very careful about placing common property settings in the BaseProviderData class - because if a custom provider needs an attribute of the same name - it will never see it since it won't be included in the NVC of settings during construction.

NOTE - see Part Two of this article here...

I've recently been working on a component for a client that requires several implementations of a base class and interface including internal class dependencies.

I'd also been lurking over a couple of blog entries on the topic of Inversion of Control Containers and the Dependency Injection pattern and trying to work out the best strategy for configuring the base provider class as well as the dependencies, and so for the first time I was thinking - hmmm.. a case for DI and a pluggable architecture.

I'm by no means an 'Alpha Geek' where DI, IoC and pluggable frameworks go, however I've been using EntLib and various providers in .Net for a while now and my curiosity was peeked when Enterprise Library 3.0 shipped with its very own Application Block Software Factory.

A brilliant blog writer by the name of Jeremy D. Miller has posted a series on DI and IoC - such as The Dependency Injection Pattern – What is it and why do I care? and Thoughts on Building Pluggable Frameworks.  I'd been looking at StructureMap and Castle Windsor as possible starting points.

I've also been following the evolution of the Guidance Automation Toolkit and the Guidance Automation Extensions. There's some cool stuff going on here with the software factories released so far.

So... while StrctureMap looks like an excellent choice (although I should stress I'm really not qualified at this stage to compare the two) - I decided to try it the Microsoft way first using GAX and the Application Block Software Factory ... and here are the results - a Foo Application Block sample app (Zip). 

There aren't any QuickStart sample apps for an Application Block using the software factory (at least not yet) and the docs supplied are clear but very brief and so a little digging was required. Tom Hollander has posted three video tutorials on getting started with this software factory - Enterprise Library: The Videos. The first two demonstrate the creation of providers for existing application blocks. The third one takes you through the creation of a custom application block. As an aside - the Configuration namespace in .Net 2.0 is large and daunting at first - but there's some powerful stuff in there. It helps a lot if you're familiar with the most common classes in the configuration namespace, ideally having created at least one configuration section using the ConfigurationSection base class.

I also wanted a simple App.config ready to go with my new block and configuration settings including custom settings for a provider. While Tom's video demonstrates this - the screen width was too narrow to see some of the settings he'd used including the most important reference to the section handler type.

After watching the videos and trying it out - a couple of hours later I'd got the hang of it and can now produce a custom application block, base provider and configuration classes in about five minutes; not a bad return.

The only dependencies in the new custom block are the Microsoft.Practices.EnterpriseLibrary.Common and Microsoft.Practices.ObjectBuilder namespaces - so if you're already using Entlib - these shouldn't worry you - and if you're nervous about getting into bed with GAX and GAT too soon - then with one custom application block in the bag - you can use this as a template for other projects without GAX. Creating new providers within the project is very straightforward.

One mistake I made that caused me to get hung-up for a few minutes - was a typo in the type declaration in the App.config settings file for my first concrete provider (CoolFooProvider) - if you make this mistake you'll get the following exception at runtime - "The [Assembler] attribute is not set in the configuration object type Foo.Configuration.FooProviderData." (for your base provider data class). Since this is the base type for concrete provider data class it's not decorated with the [Assembler] attribute; it's never meant to be 'assembled'. The application block couldn't find my concrete implementation (because of the config typo) and so fell back to trying to assemble the base class. Check your config file carefully if you see this message.

I also didn't like the default name of the ApplicationBlockSettings class that was created by the software factory - but this is a simple search and replace in files from VS - in this case renaming ApplicationBlockSettings to FooSettings. This is important though since this is the class that handles the section - and the one that you'll need to reference in your App.config section definition.

And very lastly - I prefer my section definition names to be camel cased (and so do the authors of the main EntLib blocks) and so a quick change to...

"public const string SectionName = "foo"" in FooSettings was in order.

My objective in the exercise was to see how quickly I could create configurable providers for the base and interface definitions for the component - including the correct settings for App.config since I did not want to depend on the designer for configuration setting creation. Like most things - it's quick and easy once you know how. Here's the link again to a working demo of a custom application block - Foo application block (Zip).

The next step in the project will be to create two new provider bases and interfaces for the nested dependencies (this is the main design goal of the block - otherwise I'd be using a simple FactoryClass to create the component). The constructor for the parent provider will simply call ProviderFactory for the nested providers based on one of the string settings in the parent provider, and of course the App.config will contain another list of possible provider entries for the child providers. If you've made it to your first custom Application Block then this next step is a breeze.

If I were more knowledgeable about StructureMap and the Castle Windows Container - I'd make some comparison comments - but I'm not (yet) so I wont. I've read enough so far to know that I'm in good shape for the first step in the process which is a good object configuration and creation strategy.

Containers are next....