ver the last few years, Microsoft has made a significant investment in collaborative technologies. Windows?SharePoint?Services (WSS) and SharePoint Portal Server (SPS) are two flagship products positioned in this space. This article is written in two parts. In this month‘s installment we will introduce the fundamental architecture of SharePoint and discuss the opportunities that SharePoint provides the developer using the Microsoft?.NET Framework. In the second installment, we will discuss programming with the WSS and SPS object models as well as the creation of custom Web Parts for a SharePoint site.
Windows SharePoint Services is an add-on product that is considered an official part of the Windows Server?2003 operating system. WSS supplies a framework for building collaborative Web sites that makes it possible for a company to share information and documents across teams, departments, and large organizations easily and reliably. Any user can access a WSS Web site using a Web browser or through the new collaboration features built into Microsoft Office 2003 products such as Word and Excel.
WSS also provides the infrastructure for generating UIs by including Web Part Pages and Web Parts. Web Part Pages and Web Parts are a powerful aspect of SharePoint because each WSS site provides a browser-based UI that is fully customizable. Web Parts can also be used to track each users‘ personalization information. We will discuss Web Parts in greater detail later in this article.
SharePoint Portal Server 2003 is used to build enterprise-level portal sites that are part of the Microsoft Office 2003 System. It is important to note that SPS is built on top of WSS. SPS complements WSS by adding manageability features that have been designed to assist users in navigating through vast amounts of information and documents. SPS also supplies additional functionality to enhance portal sites using indexing, searching, audience targeting, and single sign-on.
There is a fundamental difference in the roles played by WSS and SPS, as shown in Figure 1. WSS is based on a collaboration theme in the sense that it‘s designed to store and share list-based data and documents. SPS, on the other hand, is based on an aggregation theme. An SPS portal site is useful for aggregating information and documents from many different places. SPS adds value because it provides users with a quick and easy way to find information and documents that are spread out around a private network or scattered throughout the Internet.
In essence, WSS gives you a place to put all your content while SPS provides the means to navigate and search through your content when you need it. These two roles are quite complementary to one another. WSS allows an enterprise-level company to create and maintain tens of thousands of collaborative Web sites, while one or more SPS portal sites allow users to find what they‘re looking for by searching through all this content.
You should understand that SPS depends on WSS to provide many essential services. For example, WSS provides SPS with the capacity to track members and share lists and documents. Furthermore, SPS doesn‘t need to reinvent its own rendering engine for generating the HTML for a portal site‘s user interface. Instead, SPS takes advantage of the WSS Web Part Page and Web Part infrastructure to construct the user interface for an SPS portal site.
Windows SharePoint Services
WSS is free to any individual or company that has purchased the Windows Server 2003 operating system. The WSS installation files can be downloaded using the Windows Update service or from the Microsoft.com SharePoint site.
The WSS framework is built on top of Windows Server 2003, IIS 6.0, and ASP.NET. Figure 2 shows how the fundamental pieces of the WSS framework fit together. Note that before you can successfully install WSS on Windows Server 2003, you must first configure the host computer as an Application Server by enabling IIS 6.0 and ASP.NET 1.1.
Figure 2 WSS Architecture
Learning about WSS is easier once you know a few facts about its history. WSS is part of the second generation of SharePoint products and technologies. The first generation was built on an earlier IIS-based framework named SharePoint Team Services (STS). The STS framework is similar to WSS in that it provides a collaborative framework for sharing list-based data and documents. STS was not, however, built on the .NET Framework or ASP.NET. Instead, it was built using a proprietary ISAPI extension.
Customizing and extending STS Web sites has always been relatively difficult due to limited tool support. Site customization is much easier with WSS and the second generation of SharePoint because of WSS-compatible Web designers such as FrontPage?2003. WSS also offers a much better extensibility model because you can write custom applications and Web Parts for WSS sites and SPS portal sites with Visual Studio?.NET using either C# or Visual Basic?.NET.
STS and the first generation of SharePoint products and technologies have also suffered from scalability problems. An underlying architecture that runs a stateful design on front-end Web servers is responsible. This flaw makes it impossible to scale out STS Web sites using a Web farm environment. When Microsoft engineers started to design WSS and the second generation of SharePoint products and technologies, they made it a primary design goal to fix the scaling problems of STS. Consequently, they designed their architecture to support WSS and SPS deployments with tens of thousands of users and tens of thousands of Web sites.
Figure 3 Web Farm Configuration
The WSS architecture is based on stateless front-end Web servers. It is founded on an integrated storage strategy where all the list-based data and documents associated with a Web site are stored in a SQL Server?database, as shown in Figure 3. A key objective of this integrated storage strategy is that it allows a deployment of WSS Web servers to effectively scale out in a Web farm environment.
Databases
WSS relies on two different kinds of SQL Server databases: configuration databases and content databases. As you might suspect, the configuration database holds deployment-specific configuration information for each physical Web server, IIS virtual server, and WSS Web site. Content databases, on the other hand, hold data associated with WSS Web sites.
WSS requires exactly one configuration database for each deployment of WSS Web servers. A simple deployment can involve a single host computer running both the WSS front-end Web server components and SQL Server with the configuration database and a single content database. A more scalable WSS deployment involves a Web farm scenario with multiple front-end Web servers. A WSS deployment can also involve multiple back-end database servers. For example, in certain deployments scaling advantages can be gained by spreading several content databases across multiple host computers running SQL Server. However, there is only one configuration database for each WSS deployment. The configuration database provides a central repository of information to coordinate all front-end and back-end servers.
Each content database stores the data for one or more WSS Web sites. WSS data that is stored on a site-by-site basis includes lists and documents as well as all information pertaining to site customization and personalization. This integrated storage strategy provides a definite improvement over STS where site-specific data was stored in the file system and in the registry in addition to the database. The fact that everything pertaining to a site is stored within a single SQL Server database makes it significantly easier to back up and restore Web sites under WSS.
If you‘re just getting started with WSS, you can install everything you need on a single computer running Windows Server 2003. Once you have installed Windows Server 2003, configure the computer as an Application Server by enabling IIS 6.0 and ASP.NET 1.1. When you configure IIS and ASP.NET, make sure that you do not install the FrontPage Server Extensions because they are incompatible with WSS. After that you can install WSS by running the installation program STSV2.EXE (see Microsoft Windows SharePoint Services Is Now Available).
For single-machine deployments, WSS doesn‘t require you to use the full-blown version of SQL Server. The WSS installation program can optionally install a special version of MSDE called Windows MSDE (WMSDE). WMSDE is unlike the standard version of MSDE because it doesn‘t limit you to 2GB of storage and 10 database connections. However, WMSDE is more restrictive than MSDE because it only supports table schemas signed by Microsoft. This means you cannot use WMSDE to create your own custom databases and tables.
If you would like to install SPS on a development workstation, the installation process is more complicated. First of all, there are several SPS features that require Active Directory. Therefore, you should install SPS on servers that are part of an Active Directory?domain. Before installing SPS on a host computer running Windows Server 2003, first add that machine to an existing Active Directory domain or configure it to be a domain controller. Once the computer running Windows Server 2003 is in a domain, configure it to be an Application Server by enabling IIS 6.0 and ASP.NET 1.1. With SPS, we also recommend that you install SQL Server instead of relying on WMSDE to store the database for portal sites.
Once you have installed Windows Server 2003 on a computer with IIS 6.0, ASP.NET 1.1, and SQL Server, and added it to an Active Directory domain, you are ready to install SharePoint Portal Server 2003. The first thing the SPS installation program does is install WSS. Next, SPS installs itself on WSS. Finally, the SPS installer displays a wizard that steps you through the creation of the configuration database and the initial portal site.
Note that SPS creates additional databases to track data for SPS services, user profiles, audiences, and security credentials for the single sign-on service. SPS also extends the standard WSS database schemas for the configuration database as well as for content databases that contain portal sites.
Before installing either WSS or SPS in a deployment with SQL Server (as opposed to WMSDE), you might be required to add a SQL login for the Windows account that serves as the identity for the IIS application pools used by SharePoint. By default, WSS and SPS configure IIS application pools to run under the identity of the NT AUTHORITY\NETWORK SERVICE account. If you don‘t like this default setting, you can reconfigure any IIS application pool to use a different Windows account. Whichever Windows account you decide to use, however, you will need to have a SQL login to log on to SQL Server.
Once you have added the SQL login for the appropriate account within SQL Server, you must add the account into the Server Roles of Security Administrators and Database Creators. If you don‘t follow these steps, you will experience errors when installing or configuring either WSS or SPS. That‘s because WSS and SPS by default use IIS application pools that run under the identity of the NT AUTHORITY\NETWORK SERVICE account, which has no permissions to log onto SQL Server. You must configure SQL Server to grant this account the permissions to create databases and configure their security settings.
IIS Web Sites and Virtual Servers
WSS Web site configuration starts at the level of the IIS Web site. A default installation of IIS creates an IIS Web site named "Default Web Site" that is configured to listen for incoming HTTP requests across port 80. You can use the IIS administrative tools to create additional IIS Web sites that listen for incoming HTTP requests on a different port or with a different host header. Figure 4 shows an example of an IIS Web server with two virtual servers that have been configured for user access.
Figure 4 Two Virtual Servers for User Access
Note that the installation of WSS adds its own special IIS Web site named SharePoint Central Administration. WSS uses this IIS Web site to run the SharePoint Central Administration HTML pages. The SharePoint Central Administration Web site is configured to use a random port number during installation.
In SharePoint terminology, an IIS Web site is known as a virtual server. A virtual server must be extended with WSS in order to run WSS Web sites. When you install WSS with the default settings, it automatically extends the virtual server that is listening on port 80. You can extend WSS onto another virtual server by using the SharePoint Central Administration HTML pages or a WSS command-line administration tool named STSADM.EXE.
WSS is unlike ASP.NET in that it doesn‘t configure each Web site using an IIS virtual directory. Instead, WSS tracks all configuration information for WSS Web sites inside the configuration database and content databases. This means that once WSS has extended a virtual server and you start creating WSS Web sites, they will not appear in the IIS metabase. Instead an entry will be created in the configuration database and in the appropriate content database. In reality, IIS doesn‘t know whether a WSS-extended virtual server contains a single WSS Web site or 10,000 WSS Web sites. Because WSS doesn‘t need to configure an IIS virtual directory for each new WSS Web site, you get better scalability and improved maintenance.
When WSS extends itself onto a virtual server, it installs a custom ISAPI filter called the WSS filter (STSFLTR.DLL) which intercepts each request routed to that virtual server and determines whether the request should be handled by WSS or IIS. To make this determination, the WSS filter inspects the URL of the incoming request and consults the configuration database to determine who should process it. Keep in mind that you may have a virtual server in which you plan to run WSS sites as well as other ASP and ASP.NET applications.
When WSS extends itself onto a virtual server, it adds a web.config file to the root directory of the hosting virtual server. This web.config file provides initial configuration settings for WSS and for all ASP.NET code that runs from inside that virtual server. By default, this web.config file contains fairly restrictive security settings. You may be required to modify sections of this web.config file when you want your code to run with elevated permissions or when you want to test or deploy a new custom Web Part.
In SharePoint terminology, a URL space is the set of all possible URLs that target a virtual server. WSS divides the URL space of an extended virtual server into managed paths. Paths that are managed by WSS are considered to be included paths, while those that are not managed by WSS are considered to be excluded paths. When the WSS filter sees an incoming request with a URL that is part of an excluded path, it knows to route the request back to IIS for standard ASP or ASP.NET processing.
What should you do when you want to host a standard ASP.NET application within a virtual server that has been extended with WSS? For example, imagine you want to deploy an ASP.NET Web application at http://AcmeServer/webapp1 so that it‘s available alongside WSS sites in the same virtual directory. At this point you will need to understand how to configure both included and excluded paths. In particular, you need to add an excluded path for the URL space used by the ASP.NET Web application. Figure 5 shows part of the user interface provided by the SharePoint Central Administration HTML pages for defining managed paths.
Take note that Figure 5 shows the virtual server‘s included path as well as its excluded paths. Some included paths such as sites are defined as "wildcard inclusions." The purpose of a wildcard inclusion is make URL parsing more efficient. WSS doesn‘t allow the nesting of excluded paths within the URL space of a wildcard inclusion. Once the WSS filter sees that the first part of the URL for an incoming request matches a wildcard inclusion such as http://AcmeServer/sites, it knows that the request should be directed to WSS for processing.
When the WSS filter determines that the URL of an incoming request is inside an included path, it consults the configuration database to locate the target WSS site. WSS tracks each of its sites in the configuration database using the site‘s URL and an identifying GUID. There is additional information in the configuration database linking each site to a target content database.
Within a WSS deployment, it is often useful to extend more than one virtual server. You might want to do this for flexibility. Each virtual server can be configured using an IIS Application Pool to run its WSS Web sites in an isolated process. IIS also makes it possible to configure the security authentication requirements differently for each virtual server. One virtual server can be configured to require Basic Authentication while a second can be configured to require Integrated Windows Authentication.
In some deployments, every WSS-extended virtual server will have its own separate content database. It‘s also possible to extend a virtual server so that it attaches to the same content database used by another virtual server. This allows a pair of virtual servers to provide two different access points to a common set of WSS sites. This is valuable because the security settings for each virtual server can be configured independently. For example, a virtual server used to provide public-facing Web sites is typically configured to require SSL and Basic Authentication. A second virtual server providing access to users behind a firewall can be configured to require Integrated Windows Authentication.
Site Collections, Sites, and Workspaces
Within a virtual server, WSS sites are partitioned using site collections梐 set of one or more sites that constitutes a unit of ownership. Creating a new site collection requires you to supply a Windows login account and an e-mail address for its owner. WSS tracks information about site collection owners so it can grant them administrative permissions and send them e-mail notifications regarding site collection maintenance issues.
A site collection always includes a top-level site that has the same URL as the site collection itself. When you create a new site collection, the top-level site is then created automatically. In addition to its top-level site, a site collection can optionally contain other secondary sites that are related to the top-level site through parent-child relationships, as is shown in the diagram in Figure 6. Every site must be created within a specific site collection and all the sites in the same site collection are stored in the same content database.
The site collection serves as a unit of backup and restore in WSS. The STSADM.EXE administrative tool provides easy-to-use commands for backing up and restoring a site collection. After backing up a site collection, you can later restore it on the same Web server or on a different one. You will find that WSS makes it a little more difficult to back up and restore individual sites that exist within a site collection below the top-level site. If you are creating a site that you would like to back up and restore independently, you should create the site as a top-level site within a new site collection.
When performing day-to-day maintenance in a large WSS deployment with hundreds of thousands of site collections, it is not necessary to back up site collections individually. Instead, you can perform backups at the level of the content database. Backing-up content databases will be easy for many companies because they can use the same maintenance procedures that they use to back up other SQL Server databases.
Now let‘s take a step back and ask a fundamental question: what is a WSS site? First, a site is a container for storing content. Site contents are primarily stored in the form of lists, document libraries, and child sites. Second, a site is a securable entity whose content is accessible to a configurable set of users. A site can either define its own set of users or it can inherit the users of its parent site. Each site user maps to a Windows account defined within an Active Directory domain or a local Windows security accounts database. A site also contains a configurable set of groups and permissions that define the level of accessibility that various users have on the site‘s lists and document libraries.
Third, a site also happens to be a Web application with its own extensible and fully-customizable user interface. A site owner or Web designer can customize the layout and appearance of a site‘s pages and modify the site‘s navigation structure using either the browser or FrontPage 2003.
Finally, a site is the foundation for using Web Part Page and Web Part technology. Site owners and Web designers can customize Web Part Pages by adding and configuring shared Web Parts. A user can further personalize a Web Part Page by modifying, adding, or removing Web Parts. All the customization and personalization data associated with the Web Parts on a Web Part Page are automatically stored in the content database.
WSS supports several different site templates for "workspaces." Technically speaking, a workspace is really just a standard WSS site. However, the purpose of a workspace is more narrowly defined than other types of WSS sites because it often focuses on a single document or meeting. Furthermore, sites that are workspaces contain predefined lists to provide better integration with Microsoft Office products such as Word, Excel, Access, and Outlook?
Every site is initially created from a site template. A site template is a blueprint that defines an initial set of lists, document libraries, Web Part Pages, and Web Parts that exist within a new site. WSS ships with eight site templates including Team Site, Blank Site, Document Workspace, Basic Meeting Workspace, Blank Meeting Workspace, Decision Meeting Workspace, Social Meeting Workspace, and Multipage Meeting Workspace. When a site is first accessed after being created, WSS prompts the user to select one of the available site templates using the HTML page shown in Figure 7.
Figure 7 Selecting a Site Template
WSS supports the creation and use of custom site templates. You can customize a site to your heart‘s content with FrontPage 2003 and then save the site as a site template. You can save a site as a site template with a few clicks in the browser. Once the custom site template has been created, it is then available for creating new sites within the same site collection. With some additional effort, a custom site template can be exported to other site collections and can also be used to create top-level sites.
SPS Architecture
SPS builds on top of the architectural layer provided by WSS. When you create a new SPS portal site, you are really creating a new physical WSS site collection. However, there are a few noteworthy restrictions about how SPS uses WSS. There can be only one portal site per virtual server. Furthermore, the site collection containing a portal site must always be created at the root URL of the hosting virtual server.
Once you have created a portal site at the root of a virtual server, you can then create additional standard WSS site collections within the same virtual server. If fact, that‘s exactly what SPS does when you execute the Create Site command from a portal site. That is, SPS creates a top-level site within a new site collection. When a portal site user creates a personal site by clicking the "My Site" link, SPS also creates this personal site as a top-level site within a new site collection. This strategy makes it easier to back up and restore shared and personal sites within an SPS deployment.
SPS extends the way in which WSS stores content by introducing areas and listings. Remember that SPS is a product designed around the theme of aggregation. Areas and listings are used by portal site content managers to aggregate content from other places. An area is a container of listings and nested sub-areas. Occasionally, a listing will contain HTML-based text. More often, a listing contains a link to non-portal content such as a document, Web page, or WSS list across the network. The key point is that listings allow SPS to link users to non-portal content such as shared folders, Microsoft Exchange public folders, WSS sites, public Web sites, and Lotus Notes, as shown in Figure 8.
Figure 8 SPS Listings
The areas within a portal site are structured into a parent-child hierarchy. Figure 9 shows the HTML-based interface that SPS provides for working with areas. This user interface makes it relatively simple for portal site content managers to add and delete areas and listings from within the areas hierarchy of a portal site. SPS also makes it simple for anyone to use the browser to relocate an area or listing within the areas hierarchy.
Figure 9 SPS Areas
Areas and listings facilitate aggregation because they make it easy to navigate through content both inside and outside a portal site. Areas and listings are also integrated with the SPS search service. When you run an SPS search within the scope of an area, SPS searches through the content and links of that area‘s listings as well as the content and links of listings within sub-areas nested below.
The SPS search service is complemented by the SPS indexing service. The indexing service is designed to build indices by crawling through the content links provided by areas and listings. The indexing service even knows how to crawl through Word documents and Excel spreadsheets and search for specific keywords. Once the set of indices has been built, the SPS search service is able to perform fast searches that allow users to find the content they need.
Conclusion
This article has provided an in-depth examination of the architecture of SharePoint products and technologies. WSS and SPS are two different products that have been designed to work well together. WSS provides the foundation for creating collaborative Web sites that support customization and personalization. SPS complements WSS by playing the role of a content aggregator. You have also seen that SPS is fully dependent on the underlying infrastructure of WSS. In fact, the more you know about the foundations of WSS, the easier it will be to get the most out of SPS.
In one sense, SharePoint products and technologies reduce the need for custom software development because WSS and SPS provide so much functionality right out of the box. WSS and SPS also provide valuable opportunities to write custom applications and Web Parts. This article has given you a roadmap to get started with SharePoint development. Next time we will continue where we left off and dive into the WSS and SPS object models as well as the development of custom Web Parts.
