When I first looked at SharePoint Server 2003, it seemed to me like a web application with very attractive CSS and DHTML. It’s only later when I started development in WSS/Share Point Server 2003 then I realized the scope of this massive product. The WSS and SharePoint Portal Server 2003 are no doubt much more than web applications that install in 20 minutes with a database(s). In order to really unleash their power and for utilizing their features to the full extend, one must know what happens inside. This article examines the essential points that every developer or technical consultant adheres at times mainly regarding the request processing and architecture of WSS and Share Point Portal Server 2003, and answers them with acute amplification.
Well to be very honest, in order to thoroughly understand the whole process of request and response and to look into the architecture, we must take a look at the IIS 6.0 Work Process Model and the role of ASP.NET, and how they handle the request and return the request. The prime reason for this is that the WSS and hence SharePoint Sever 2003 are tightly coupled with them.
Examining the Role Of IIS 6.0
IIS 6.0 (Internet Information Server 6.0) is essentially the latest Web Server from Microsoft which at the time of writing runs only on Windows Server 2003. The prime reason of this is that it's has been redesigned and rewritten from the core. Moreover it's very firmly integrated with the operating system, take a look at figure 1.0.
As you can see, in figure 1.0, the IIS lies on top of the HTTP protocol stack namely HTTP.sys. The important thing to note is that HTTP.sys is the part of the OS network subsystem so it has the advantage of being run in kernel mode as that of device drivers. The obvious advantage of this is of getting the facility of kernel mode caching and queuing. Simply putting, the HTTP protocol stack serves the following key tasks:
- Listen to queries and queuing them to the correct IIS Virtual Server. (This will then be picked up by the correct IIS worker process.)
- Text based logging.
- Ensures SSL Encryption/Decryption work correctly.
Now let’s move forward and into the request processing modes that IIS provides, they are also known as application isolation modes.
IIS 5.0 Isolation Mode
This is purely for backward compatibility, for those who are migrating or upgrading from Windows 2000 to Windows 2003. In this case we have the processing model that is of IIS 5.0 with the same old low, medium and high options IIS 5.0 used. Well, the good news is that the SharePoint Product and technologies do not use this processing mode. In-fact their inside components can’t be used with this model. So I won’t put too much light on this in this section. By the way this is the default model for IIS 6.0!
IIS Worker Process Isolation Mode
This is the new processing model built natively for leveraging the IIS 6.0 architecture. In this mode all web applications including ISAPI filters and Extensions are run inside what’s known as application pools. Well for those of you who don’t know about application pools, their sole purpose is to provide process isolation for the code executed when the user's request is satisfied by the web application. If you take a took at figure 1.0 you will get the exact meaning of what they are. Actually there is much more to it than these application pools bring. First, IIS 6.0 allows multiple application pools to be created and hence you are free to chose for your application not only the Virtual Server Level but also the Virtual Directory Level.
The application pool(s) are allocated their own worker process namely the W3wp.exe. This helps in efficiently restarting the web application running in the application pool by simply recycling the worker process. Actually there is also an advantage that worker processes can be recycled without producing any application downtime. This is possible because an application pool can be an aggregation of more than one worker process, and due to this a new worker process will take on the job right from the point where the previous one left before its termination.
Well there is one point that you must know and that’s the cost of memory overhead that application pool(s) cause and this can be minor or major depending upon the nature of the application.
So to sum it all, and to complete our examination of IIS 6.0, let's take a user query/request to IIS 6.0 and see how the things mentioned in the above section tackle them. This will give a through understanding of exactly what’s happening under the hood. So to start with, see figure 1.1.
- The user makes a request.
- The HTTP.sys (the kernel mode HTTP protocol stack) intercepts the request. The HTTP.sys queues the request for the correct IIS 6.0 Virtual Server so that the application pool's worker process can pick them up.
- The Worker Process takes the request and passes it to the ISAPI filter(s) (well, ISAPI filters are essentially the DLLs that are registered for IIS Events and do something rational when event(s) happen by executing code), with respect to the priority that they have got.
- Next to ISAPI filters, we have got ISAPI extensions, which are registered on the basis of file extensions. The most common application pages ASP and ASP.NET that are served by IIS are processed by ISAPI extensions. After the ISAPI extension processes the request, the response is passed back to the ISAPI filter(s) and then to the HTTP.sys protocol stack and all the way to the user that made request.
Now as we are equipped with the IIS 6.0 essentials that we require to understand the SharePoint Server 2003 architecture, let's take a look at another core pillar that we must feel comfortable with before we delve into the SharePoint Server 2003 architecture, and that’s ASP.NET. The next section is devoted to it.
Examining the Role of ASP.NET
The ASP.NET is a framework that dynamically creates the pages that run on the server side. Well what we are interested in is to examine how ASP.NET works with IIS 6.0 and how they intermingle to provide a powerful basis for the WSS / SharePoint Portal Server 2003 architecture.
Well to start with, the ASP.NET applications fully utilize IIS 6.0 and its worker process isolation mode to the full extend.
The role of ASP.NET comes into play when the ISAPI extension aspnet_isapi.dll, which is in fact registered for file extensions aspx, asmx and ashx, is called. See figure 1.2.
The figure 1.2 shows the ASP.NET architecture in the IIS 6.0 Worker Process Isolation Mode. Actually if we analyze the structure of the ASP.NET processing engine, it is remarkably similar to IIS and this is done in order to give the developer the ease for working with the same mind set. As the ASP.NET engine sits within IIS 6.0, it provides a similar functionality like that of ISAPI Filter/Handlers and you can do it all in pure managed code. The figure 1.3 shows the ASP.NET rendering sequence, and it's evident from it that ASP.NET modules are functionally similar to ISAPI filers which can listen to ASP.NET events (which are you can say on a Global level). They can modify the information which then is sent to the ASP.NET handler which are like ISAPI extensions which are registered to handle certain file extensions.
This all sums up into a remarkable and wonderful aggregation of IIS 6.0 and ASP.NET.
The IIS6.0, ASP.NET and SharePoint Products and Technologies
As we all know, WSS runs only on Windows 2003 Server, well the question is why? The question is of prime importance once you want to know the basis of the architecture of SharePoint Products and Technologies (WSS and SharePoint Server 2003). The most simple and straightforward answer to this question is that this is the only way to consume the components provided by Windows Server 2003 to the fullest and this includes IIS 6.0 Worker Process Isolation Mode and ASP.NET. Take a moment and look at the figure 1.4.
The figure might be a bit complex because when WSS extends the Virtual Server it also has to couple up with a scenario when some one wants to host a ASP.NET web application on this same very virtual server. So for facilitating the dual–path execution model the WSS provides a list which contains both the WSS server path and also the ASP.NET server path. These are knows as path inclusions and exclusions respectively. I will put more light on this a bit later in this section but first let us examine the role of the other main components.
In figure 1.4 if you notice you will see an ISAPI DLL extension on the top (just below Front Page RPC, DAV). The reason for this extension is to support the different protocols that are not meant to be handled by ASP.NET or any other components. In fact to your interest there is a DLL named OWSSVR.DLL that performs a plethora of work by providing the bulk of rendering and CAML support. In fact if you ever want to build a solution on top of WSS/SharePoint Server 2003, you have to dig it a lot because it takes a request and rewrites the URL or packs the request inside the DLL by encapsulating it into the header tag.
Anyways the crux of the matter is that this OWSSVR.DLL is of prime importance for you if you are willing to write a custom filter at some point, and to see its desired behavior you have to intercept the request before this WSS filter.
Moving forward, the other components are pretty much in place as you might have expected. To amplify these let us go through a typical request flow form the user to the WSS/ SharePoint Server 2003 application and see how the user gets the final response. To start with see the figure 1.5.
Now the question that comes to mind is why to do all this stuff in this crude way. Well, the reason is very simple: as WSS divides the execution of pages into two modes with Direct or Safe mode.
The distinction is essential as this is done due to the base architecture of WSS. In the Direct mode the pages are compiled and thus enjoys the compiled code execution performance enhancements. Well, all the contents in the /_layouts/ directory are executed in the Direct mode. So if you are looking to develop pages which you want to run in Direct mode, put them under this directory.
All the administrative pages are run in Direct mode and the /_layout/ directory maps to the drive letter: \Program Files\Common Files\Microsoft Shared\web server extensions\60\TEMPLATE\LAYOUTS directory.
- On the contrary the ASP.NET pages executed in Safe mode are compiled on the fly, this is a much restrictive mode compared to Direct. Here the pages have active scripting disabled and only the server side controls that are marked as safe are executed. All the Web Parts are server side controls hence they are rendered under Safe mode. The SharePoint Handler also plays a vital role as it builds ASP.NET pages based on the information fetched from the database before passing them to ASP.NET for execution.
- Finally the response, either the ASP.NET page or the static content, is sent to the end user that made the request.
Now as we have enough knowledge about where WSS stands with other components namely IIS 6.0 and ASP.NET, we will now see the architecture of WSS and SharePoint Portal Server 2003. We will see that they have other components like database, and Windows services. These all play a very vital role in the WSS / SharePoint Portal Sever Architecture, hence to completely understand the architecture their examination is also essential.
Examining SharePoint Products and Technologies Architecture
Examining the WSS Architecture
The WSS is the base for SharePoint Server 2003. In fact the existence of WSS is inevitable for SharePoint Server Portal Server 2003. In this section we will drill down the WSS architecture, and see some of the components related to IIS 6.0 and ASP.NET. We've already seen some of them that we are going to examine in this section so that we get the concrete understanding of the WSS architecture.
See the figure 1.6, it reveals two important facts. First is that there is much more to WSS than only IIS 6.0, and secondly the underlying databases. This is why we can never say that WSS is a normal web application. As you can see in figure 1.6, the WSS uses Microsoft SQL Server 2000 to store all the information. Actually it stores all the configuration as well as the content in the databases. This way WSS very cleanly distinguishes and separates the presentation from the data. When WSS is installed it creates a configuration database that stores the meta data, physical configurations and information about every single virtual server that has been extended. And for every extended virtual server, WSS creates a Content Database that apparently stores the actual data in the content database. This elevates the scalability option as WSS supports multiple content databases for a single extended virtual server. This way if there is huge load on the single content database you can split the database into multiple.
The WSS also has some Windows services to perform certain functionality.
The SharePoint Timer Service (see figure 1.6) is essentially a Windows service that takes account of executing timely events, these are the actions that occur in a predefined amount of time.
Alerts is the feature that is used to notify the user about a certain event. Let's say that the user wants to be alert every time certain documents are uploaded in the document library. Actually alerts are very configurable hence quite flexible to use. The alerts are generated with the help of SharePoint Timer Service which looks for changes after every five minutes (this time is configurable) for immediate notifications that need to be send.
The search functionality is quite out of the box and requires very little configuration to get results. Actually the search is the same index based search as Microsoft Search.
Let's see the SharePoint Server Architecture as it leverages, and the existing WSS components.
Examining SharePoint Portal Server 2003 Architecture
See figure 1.7 for the SharePoint Server 2003 Architecture, which indeed builds on top of WSS.
The SharePoint Server 2003 utilizes the same WSS Presentation and Collaboration Layer and extends them by installing some templates for presentation and database for storage. As Share Point Portal Server 2003 gives hierarchy in terms of areas, it hides the WSS Site Structure under the cover, but again the point to note is that there is a lot of work done by WSS. There are certain restrictions as how WSS is used by SharePoint Server 2003, for example there can be only one Portal Site for one Virtual Server. Furthermore the site collection containing a Portal Site must always be created at the root URL of the hosting Virtual Server.
As we saw, in WSS, we have got the SharePoint Timer Service, and the SharePoint adds services of itself to the architecture. As the items on the SharePoint Areas had bit more cardinality for Alerts than those in WSS, SharePoint came up with its own Alert Service. One example where this is required is when you set alert for certain items in the SharePoint Area or for the search results.
Another important Enterprise level addition is of Single Sign On. The Single Sign On allows Web Parts to map user's NT credentials to legacy applications –authentication schemes.
The Portal Sever Administration Service also has a new addition. As the components have increased as well as services, it's quite important to create a certain central and standard administration that can synchronize the components and maintain some uniform settings that are desired. The Portal Administration Service is also taking care of other services with respect to the configuration information.
The SharePoint Search Service is complemented by the SPS indexing service. Actually this is the same as MS Search core that is shared by a number of other Microsoft products, including the SQL Server. The indexing service crawls through the content in the SharePoint content database and sets up the indices. Once they are built the search can perform very efficiently and fast.
The SharePoint Server 2003 creates additional databases to track data for SPS Services, user profiles, audiences, and security credentials for single Sign-on Service. The SharePoint Portal Server 2003 also extends the standard WSS database schemas for the configuration database as well as for content databases that contain portals.
By default WSS and SPS configure IIS application pools under the identity of the AUTHORITY\NETWORK SERVICE account. This account has no permissions to log on to SQL Server, so you must configure SQL Server to rant permissions to create databases and configure their security settings.
Difference in the Roles of WSS and SharePoint Server 2003
There is a fundamental difference between WSS and SharePoint Server 2003. WSS is based on the collaboration theme in the sense that it's designed to store and share data list based data and documents. SharePoint Server on the other end is based on an aggregation theme. The SharePoint Server site is useful for aggregating information and documents from many different places. SharePoint Server adds value because it provides users with a quick and easy way to find information and documents that are spread out around a private area or scattered thorough out the Internet. So to sum it up WSS gives you a place to put all your content while SharePoint Server provides an efficient means to navigate and search through your content when you need it.
In this article we saw the underlying blocks for WSS and SharePoint Portal Server 2003. We started by taking a look at the IIS 6.0 Working Process model, then looked at ASP.NET and its role with IIS 6.0. We finally visited the WSS and SharePoint Portal Server Architecture and examined the key components that they are composed of. In the end we saw the major differences in the roles of WSS and SharePoint Portal Server 2003. If you have any questions regarding this article feel free to email me at firstname.lastname@example.org.