Share Point Overview

Introduction

In this series of articles I'm going to be looking at Windows SharePoint Services 3.0, which we'll abbreviate to WSS3 from here on. WSS3 is the free version of SharePoint whereas Microsoft Office SharePoint Server 2007 (MOSS) is its big, commercial brother. It is its brother however and is closely related. We're going to focus almost exclusively on WSS3 but will mention MOSS occasionally along the way. MOSS is entirely based on WSS3.0 though it does provide a number of additions. WSS3 is a capable and not insubstantial item of software in itself however.

I am going to assume you know a little (though only a little) about SharePoint technologies in that you have used either WSS3, MOSS or a previous version of SharePoint though perhaps only from an end user's perspective (though an end user can do a fair bit in SharePoint!) It is also assumed later in the series that the reader is a competent ASP.net 2.0 programmer and knows about things like master pages and web parts.

In the first few articles in this series we will largely be introducing and exploring the copious number of features available out of the box with WSS but just a quick early note on the required development environment in case this puts anyone off at this early stage. WSS3 installs on Windows Server only so it is not going to be easy developing for SharePoint unless you have access to such an environment. This means either an accessible server (which may be your main machine) or a virtual machine on your primary development machine if running a client OS, for example via Microsoft’s free Virtual PC product (see Microsoft downloads). We may discuss the pros and cons of each approach nearer the time but here's a brief spec for a development environment: Windows Server 2003 R2 with WSS 3.0, .NET 3.0, SQL Server (2000/2005/Express) and VS 2005. We'll leave that topic for now but will return to development issues for the second half/ two thirds of this article series.

Talking of the future ... what is the plan? See below – these are the subjects we'll be covering approximately. The odd topic may force its way in as we progress.

An introduction to WSS3, in particular the architecture and key concepts in overview

WSS3 Out of the Box – unsurprisingly a look at using some of the out of the box features of WSS3

Security - Authentication and Authorisation

Basic Customisation of WSS3

Site Definitions – sites are a key building block of WSS3 so site definitions are also key

Features – these are components of functionality that can be activated at different levels within WSS3

Web Services – in WSS3 the API is exposed via Web Services

Web Parts – pretty central in development terms

WSS3 Object Model – ditto!

Custom Field Types – in WSS3 you can extend the definitions of field types

Events

Workflow – based on .NET 3.0 WF

Performance

So, in this article we are going to introduce the WSS v3 architecture and key concepts such as sites, site collections, workflow, master pages, web parts and content types.

The main reference for this series of articles is Todd Bleeker’s 'Developers Guide To Windows SharePoint Services3.0', one of the early books available on WSS3 development.

WSS3 Logical and Physical Architecture

The architectural hardware model is designed to be scalable with 3 logical tiers: front end web server(s) (IIS), search server(s) and database server(s) (content and configuration). This logical model can be physically deployed on any number of servers, 1 upwards.

Administration

Application administration is exposed via two main avenues in WSS: via SharePoint Central Administration – a web site in its own right – and via the standard functionality exposed to the admin roles via the SharePoint site. The SharePoint administration model includes support for the following roles:

• Server (farm) admin – the overall management of a server (farm) is achieved via the comprehensive SharePoint Central Administration tool, e.g. email settings, database content servers and backups.
• Site collection admin – sites are divided into hierarchical site collections and these provide an administrative unit. The site collection administrator can set quotas and manage users across all sites in the collection.
• Site admin – the site administrators can create and manage site content elements as well as the security thereof.
• Shared services admin (MOSS only) – MOSS also supports the administration of key MOSS only services).

It is also important to note that the command line tool stsadmin is an essential tool for the more technical SharePoint administrator. More of this tool in later chapters.

Site Collections

A site collection is a hierarchy of WSS web sites (aka workspaces/ webs/ sites – we'll try and settle on the latter). They share elements such as a templates, workflows, site columns, master pages and content types (more of which later but the reader should be aware of most of these concepts already). Sites within a site collection can share content and navigational elements.

The default permissions and permissions groups for a site collection are:

• Full control: as says
• Design: can edit lists, document libraries, and pages in the site
• Contribute: can view pages and edit list items/ documents
• Read: can view pages, list items/ documents

On installation and by default a single site collection /web application is created. Further site collections may be created from the SharePoint Central Administration site (subsequently CA assuming I remember). The CA is accessible directly on the server under admin tools or via the CA URL. The required option is Application Management – Create or Extend web application – Create new Web Application. By default:

• NLTM authentication will be used
• anonymous access will not be permitted

It is also recommended that

• a new IIS application pool should be used
• the database name should be linked to that of the site collection (so you can easily work out which database corresponds to which site collection)

You may need to recycle the application pool before you use the new site collection as configuration information is cached and may need to be forced to reset. The easiest/ best way to do this is to right click on the application pool in IIS and select recycle.

Web sites and Workspaces

A (web) site is a collection of zero or more lists and libraries and the pages that manage them. Security may be inherited or unique among the various webs within a site collection, definable by the site admin. Sites can have their own content types and site columns. More of which shortly.

Workspaces are just sites really. They are, however, predisposed due to the nature of their included lists and libraries to specific business activities. Types of workspace include the document workspace and a variety of meeting workspaces. Document workspaces can be created from a document library (see next section) in WSS or from Office client software.

Microsoft Office SharePoint Designer 2007 (subsequently SPD) can be used to edit sites and their sub-objects simply by pointing SPD at the URL of the web site, as one would have done with Frontpage, which is no coincidence as SPD is the evolution of Frontpage. Note that a WSS3 site uses a shared template page on the file system in a site template definition. Customising a page, through SPD for example, forces it to stop using this template page and for the new ‘template’ to be stored in the content database. In WSS2 this was referred to as 'unghosting' a page and is a terminology that is likely to continue. Note that a) SPD provides a warning when this is about to happen and b) SPD allows the process to be reversed.

Lists and Libraries

Sites in SharePoint are comprised of lists and their close bedfellow, libraries. A list is a place to store data. A (document) library is a special type of list modelled more on the concept of file systems folders for storing documents. Lists rely on the concept of columns (aka fields or attributes) – an item of information about the type of list, e.g. name of a document. In turn views rely on columns – specific views of the list data based on criteria applied against the columns.

Enhancements in WSS3

• Site columns provide a way to create a column that will be used by several different content types and/or lists. They offer a way to enforce consistency and reusability of columns across a site or list.
• A content type is a collection of settings that can be applied to a particular category of content. So multiple types of content can be managed from a single list or library. For example, documents and presentations could be stored in the same document library but have different columns, templates, workflows and behaviours associated with them.
• List improvements – several capabilities that previously only existed for libraries have been extended to lists, and vice versa.
• Events – fire before and after an action has occurred and can be coded against
• Folder creation and versioning is also now supported for lists
• Security enhancements – permissions are now specifiable down to the list item level and the UI has been improved in terms of better context sensitive security menu options
• RSS feeds are available for every list and document library created
• Workflow – Windows Workflow Foundation (WF) provides a programming framework and tools for developing and executing a wide variety of workflow-based applications. WSS3 provides the infrastructure to manage workflow execution, allow workflows to exist for long periods of time, create and respond to workflow tasks and track the history of workflow and the objects it affects (lists and library items). Thus WSS3 workflow allows the creation, management and tracking of a series of actions based on a business process in WSS3. For example, a task could be generated for the Quality Manager to approve any new document uploaded to the quality system document library. The actions that occur in a workflow can be initiated automatically by WSS3 or can be manually initiated by the user. As you might expect workflows are available to lists and libraries. While multiple workflows may be made available for a single list item, only one instance of a workflow can run on an item at any one time. Workflows can be created for a specific list using the SPD wizard. More advanced and centralised workflows can be created using VS.net.

Galleries

WSS2 introduced the concept of the gallery for site templates, list templates and web parts. Once added to a site collection gallery an item was available for use throughout the site collection. This has changed a little in WSS3. Instead of there being a single gallery for a site collection each site has a gallery. With each site items may be shared between a parent and its children; items such as columns, content types and workflows. The full list of gallery types is now:

• Master pages
  With the fact that WSS3 is built on ASP.net 2.0 come master pages which help preserve presentational consistency via the sharing of interface elements across all pages of an application. Developers can then also focus on the content unique to each page. A web form (ASP.net 2.0 page) associated with a master page is referred to as a template page. Controls inside a template page map to placeholders IDs in the master page. The .NET runtime matches on these IDs generating the final page.
• Site content types
  Quite often common categories of content apply to multiple sites. In WSS2 different types required separate document libraries as each document library could only have a single document template specified and one set of columns for metadata. In WSS3 multiple types of content can be associated with a single document library. The basic elements of content type are: title, document template, metadata (site columns) workflow and policies. By default content types are not enabled on a document library. This can be changed via the advanced properties of a document library.
• Site columns
  List centric columns are suitable for situations where specific properties need to be associated with list elements but are not suitable for (all) other lists. This is a situation which often arises. In WSS2 to include a unique column for a list or library it had to be created for that list. The required title, data type, validation rules and constraints would be manually specified for each list. This was a) time consuming and b) error prone when columns were needed by multiple lists. Site columns in WSS3 address this. Site columns created at the top level site can be utilised with other sites in the site collection hierarchy.
• Site templates
  A site template consists of lists, libraries, web part and content and allows users to store and share information targeted to supporting a business process. On installation site templates are based on site definitions that are stored in the '12 Hive': program files\common files\Microsoft Shared\web server extensions\12. We won’t go through the whole list but provided templates include the standard default team site, blog, various meeting workspaces as well as, interestingly, SharePoint central administration itself. You can also create your own.
• List templates
  Are collections of files, metadata columns, views and web parts. Out of the box SharePoint categorizes the 15 list templates available as libraries, communications, tracking and custom lists. After the required columns, views and any other customisation have been specified a list can be saved as a list template from list settings – general settings. To make a site collection's list templates available to another site collection you can save the custom list template to the file system from the source site collection's List Template gallery and then upload it to another site collections gallery.
• Web parts
  Web parts provide a modular and reusable functionality to a WSS3 application. In WSS3 they are based on ASP.net 2.0. This makes life much easier than previously for the WSS developer. Several web parts come with WSS3, e.g. content editor, image, etc. Custom web parts can also be created and installed to support the specific needs of an organisation. Much more of this later in this series.
• Workflows
  There is often a need to provide support for multi stage processes where actions are taken based on previous activities being completed. WSS3 greatly enhances capabilities in this area over previous versions providing a rules based workflow engine based on .NET 3.0’s Windows Workflow Foundation (WF). In MOSS several workflow templates are available out of the box. However, in WSS3 they must be created either via SPD or via VS.net using the Designer for Windows Workflow Foundation. SPD provides 'designers' or 'information workers' with the ability to create declarative rules-based workflows for specific lists and libraries through a wizard. By the very nature of wizards the workflows created are limited. For more complex workflows VS.net Designer for WF is available.

The first three are available to all sites but the others only to the root site of the site collection.

MOSS Additions

Just for comparison and information as MOSS is not the technology under primary discussion, MOSS Standard Edition includes the following:

• Documents and records management – MOSS provides a records repository site template, auditing capabilities, out of the box workflow templates, and document converters to control how enterprise content is managed through its lifecycle
• Enterprise search – while a full text search engine exists within WSS3, in MOSS this is extended to allow indexing of non-SharePoint content sources such as web pages, file shares, exchange folders as well as custom application content.
• Single sign on – capabilities have been extended.
• User profiles and audiences – the detail of personalisation is extended and support for ASP.net 2.0 membership and personalisation facilities also extends the facilities available. The Business Data Catalog (see below) also has potential impact in this area allowing import from LDAP directory sources.
• Web content management and publishing – MOSS replaces Microsoft Content Management Server 2002 (MCMS) and hence replaces much of the functionality this product offered via allowing users to populate templated web pages.

The Enterprise edition further provides

• Business data catalog – provides the ability to interact with enterprise backend applications.
• InfoPath forms server – a tool for business data collection and forms based collaboration providing users with the ability to publish InfoPath 2007 forms so they can then be completed in a browser.
• Excel server – allows users to create, modify and share spreadsheets online via the MOSS interface.

For all these extras you pay a great deal more. See http://office.microsoft.com/en-us/sharepointserver/FX102176831033.aspx. The great thing is that with WSS3 you can do quite a lot for 'free'.

Summary

This first article in the series on WSS3 introduced the product, presenting a high level look at many of the key elements of WSS3 including site collections and their constituent elements as well and hopefully started to give you an idea of what is achievable using WSS3 'out of the box'. Before we start looking at customising and extending what is supplied, both programmatically and by other means, we'll continue in the next article to look at some of the features we’ve introduced in more detail. One of the key requirements for a WSS/ MOSS architect is understanding how functionality can be delivered 'out of the box' and as a consequence when bespoke development work is required instead. This way lays optimum bang for your buck.

References

Developers guide to WSS3.0
Todd Bleeker
Charles River Media

http://dotnetaddict.dotnetdevelopersjournal.com/moss_vs_wss.htm

http://www.dotnetjohn.com/articles.aspx?articleid=234