SharePoint Architecture, part 2, from site to farm

In part one, after misquoting the song “Old McDonald had a farm,” which we shall revisit when we return to the discussion of Microsoft SharePoint farm Shared Services providers, we started describing the SharePoint building blocks using a rendition of “There was an old lady who swallowed a fly.” Starting with items such as documents, folders, lists such as libraries, and finally sites, here is what we have thus far:

“There was an SP server who swallowed a site,

One for the Team, one for a Blog, one for a Wiki, whatever is right.

He swallowed the site to keep the library.

This one for documents, that one for wikis, another for tasks, yet another for KPIs. (pronounced kippees)

He swallowed the library as a holder of the folder.

Quite categorical, with items newer or older,

He swallowed the folder to hold the item.

I dunno why he swallowed that item,

Perhaps he likes ’em.”

The SharePoint site, or SPWeb as it is called in several of the management interfaces, can indeed contain of wealth of items of a plethora of types, organized into folders and libraries. Most deployments of SharePoint have more than one content. In fact, when you count in the management interfaces, it’s pretty safe to say that (nearly) every SharePoint deployment is comprised of several sites.

An SPWeb can be defined as a subsite beneath another site. A collection of sites is called a site collection (SPSite). A site collection always contains at least one site which serves as the root site within the collection.

“There was an SP server who swallowed a site collection,

Root URL, site name, and a good description

He swallowed the site collection to keep the site.”

Each site in a collection shares some common elements and has distinct configuration for others, ….

“There was an SP server who swallowed a web application,

With an IIS site, an AppPool, and a database all its own.

He swallowed the web app to host the site collection.”

Many people want to think of each SharePoint site as having it’s own database or table, however that is not the job of a site, and that is not even the job of a site collection, but lay within the domain of the web application (SPWebApplication). Each web application has its own application pool in IIS, and therefore a distinct IIS site. Furthermore, each SPWebApplication has its own SQL database for its SharePoint content.

Some people become confused by the fact that a SharePoint site is called an SPWeb, yet a site collection is called an SPSite, and it is a web app, SPWebApplication, which is associated with an IIS site. Keep in mind that these terms have evolved over the past ten years or so, and just remember the relationships in this hierarchy if it ever befuddles you.

There is one more level in the hierarchy of the SharePoint foundation before we finally get to the more advanced topic of shared services providers.

“There was an SP server who swallowed a farm.

Configuration, apps, and central admin too,

He swallowed the farm to host a web app or two, maybe a few.”

In reality, a single SharePoint server shouldn’t swallow a farm any more than an old woman should swallow a horse, but one or more servers make up a farm. The web front end, application services, and back-end databases of larger farms are typically spread across several servers for high availability, disaster recovery, performance, and scalability reasons. Although some organizations have more than one farm, a SharePoint farm is the largest building block in the infrastructure of a single SharePoint deployment.

When you’re not just using WSS 3.0 or SharePoint Foundation 2010, but the bigger more powerful MOSS 2007 or the full SP2010 includes another aspect of farms called Shared Services Providers — more on those in the next part.

Here’s a quick review of the foundation SharePoint logical infrastructure.