Introduction
When I first looked at the Sharepoint Server 2003, I thought it was a Web application with very attractive CSS and DHTML. But when I start working on it, I realized the scope of this massive product. The WSS and SharePoint Portal Server 2003 are no doubt much more than web application that install in 20 minutes with a database(s) . In Order to really unleash their power and for utilizing their features to full extend, one must know what happens under the hood. This article examines the essential points that every developer or technical consultant adhere 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 looking into the architecture we must had to look into IIS6.0 Work Process Model and 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 Share Point Sever 2003 is tightly coupled with them.
Examining the Role Of IIS 6.0
IIS 6.0 (Internet Information Server 6.0) is the latest version of IIS Web Server from the Microsoft, which at the time of writing this article runs only on Windows Server 2003 . The prime reason of this is that its has been redesign and rewritten from the scratch and tightly integrated with the operating system ifself. Take a look at figure 1.0.
As you can see from figure 1.0 the IIS lies on top of HTTP protocol stack namely HTTP.sys , the important thing to note is that HTTP.sys is the Part of OS network subsystem so its main advantage of running in kernel mode as that of device drivers , the obvious advantage of this is of getting facility of kernel mode caching and queuing. Actually simply putting the HTTP protocol stack servers the following key tasks
- Listen queries and queuing them to correct IIS Virtual Server. (This will then pick up by correct IIS worker process .
- Text Bases logging
- Ensure SSL Encryption/Decryption work correctly.
Now let's move forward and look 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 as 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 same old low, medium and high options II5.0 used . Well the good news is that the Share Point Product and Technologies not uses this processing mode in-fact their inside components can't be used with this model so I am not going to put much more light on this other than in this section. By the way, this also is the default model for IIS 6.0!.
IIS Worker Process Isolation Mode
This is new processing model built natively for leveraging II6.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 users request is satisfied by 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 that these application pools bring, first II6.0 allows multiple application pools to be created and hence you are free to chose for your application not only to the Virtual Server Level but also for Virtual Directory Level.
The application pool(s) are allocated their own worker process namely (W3wp.exe) this helps in efficiently restart the web application running in the application pool by simply recycling the worker process . Actually there is also an advantage that worker process can be recycled without producing any application downtime this is possible because an application pool can be an aggregation for more than one worker process , and due to this a new worker process will take on the job right from the point where 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) in occur and this can be minor or major depends upon the nature of Application .
So To sum it all , and complete out examination of IIS6.0 lets take a user query/request to IIS 6.0 and sees how the things mentioned in above section tackle them this will give a through understanding of exactly what's happen under the hood. So to start with see figure 1.1.
- The users made a request .
- The HTTP.sys (the kernel mode HTTP protocol Stack) intercept the request .The HTTP.sys queues the request for correct IIS 6.0 Virtual Server so that application pools worker process can pick them up.
- The Worker Process take the request and pass it to the ISAP I filter(s) (well ISAPI filters are essentially the dll's that are registered for IIS Events and done something rational when that event(s) happen by executing code ) , with respect to the priority they got.
- Next To ISAPI Filters we got ISAPI Extensions , which are registered on the basis of file extensions . The most common application pages ASP, ASP.NET served by IIS are processed by ISAPI extensions. After ISAPI extension process 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, we need to understand SharePoint Server 2003 architecture. Let's take a look at another core pillar that we must feel comfortable with before we delve into SharePoint server 2003 Architecture and that's its ASP.NET. The next section is devoted to it
Examining the Role Of ASP.NET
The ASP.Net is a framework that dynamically created the pages that run on the server. What we are interested in is to examining how ASP.NET work with IIS6.0 and how they intermingled to provide a powerful basis for WSS / SharePoint Portal Server 2003 Architecture.
Let's start with the ASP.NET application fully utilizes the II6.0 and its worker process isolation mode to the full extend.
The role of ASP.NET come into play when ISAPI extension called aspnet_isapi.dll which is in fact registered for file extensions i-e aspx , asmx and ashx.. see figure 1.2 
The figure 1.2 shows the ASP.NET architecture in IIS6.0 Worker Process Isolation Mode. Actually if we analyze the structure of ASP.NET processing engine is remarkably similar to IIS and this is done in order to give a developer ease for working with same mind set . As ASP.NET engine sits within IIS 6.0 its provides some similar functionality like of ISAPI Filter/Handlers and you can all do it in pure managed code. The figure 1.3 shows the ASP.NET rendering sequence, and its evident form it that ASP.NET Modules are functionality similar to ISAPI filers which can listen to ASP.NET events (which are you can say on Global level) , they can modify the information which then send to ASP.NET Handler which are like ISAPI extensions which are registered to handle certain file extensions.
This all sum's up into a remarkable and wonderful aggregation of IIS6.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 Architecture of SharePoint Products and Technologies (WSS and SharePoint Server 2003).The most simple and straight forward 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 II6.0 Worker Process Isolation Mode and ASP.NET. Take a moment and look at figure 1.4
The figure might be a bit complex because when WSS extend the Virtual Server its also had to couple up a scenario when some one wants to host a ASP.NET web application on this same very virtual server . So for facilitate the dual –path execution model the WSS provides a list which contain both the path that WSS will server and also those who will be server by ASP.NET these are knows as path inclusions and exclusions respectively . I will put more light on this a bit later in this section but first examine the role other main components.
In figure 1.4 if you notice you will see a ISAPI DLL extension on the top (just below Front Page RPC , DAV ) the reason for this extension is to support the different protocol support that are not meant to handle by ASP.NET of any other components . In fact to your interest there is a dll namely OWSSVR .DLL that performs a plethora of work by providing bulk of rendering and CAML support. In fact if you ever want to build a solution on top of WSS/SharePoint Server 2003 you had to dig it a lot because it takes a request and rewrite URL or pack 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 want to see its desired behavior you had to intercept the request before this WSS filter
Moving forward , the other components are pretty much in place as you might had 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
- The first is the HTTP Protocol stack (HTTP.Sys) which we already see in the previous sections done the same stuff.
- The SharePoint ISAPI Filter (STSFLTR.dll) examines the request and verify that requested path with that enlisted in "Managed Path List " list. If the requested path is not found in exclusion list the request is forwarded to SharePoint Page Handler other wise send to ASP.NET page Handler.
- Note The path for /_vti_bin/ directory is hard coded in exclusion list, the reason for this is that it contains the ISAPI extensions used by the SharePoint to provide FrontPage RPC and DAV Protocol.
- Next we had SharePoint Handler which actually severs couple of purpose, firstly its act a smart page handler for the Web Part pages (which Microsoft Label as Smart Pages and they are secure because in order for the server controls present on them , to successfully render they must be enlisted as Safe inside Web.Config File of the WSS extended Virtual Server ) saying this keep in mind that web part them self's are merely custom controls with some added tuning. The SharePoint Handler actually doesn't do the actual plumbing instead it internally calls the default page handler for doing the hard work.
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 /_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.
Note : All the administrative pages are run in Direct mode and /_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 much restrictive mode compared to direct , here the pages have active scripting disabled and only the server side control 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 information fetched from the database before passing them to ASP.NET from execution.
- Finally the response either ASP.NET page or static content is send to end user that made the request.
Now as we had enough knowledge about where WSS stands with other components namely II6.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, Windows Services. These all play very vital role in WSS / SharePoint Portal Sever Architecture hence to completely understood the architecture their examination is also essential
Examining SharePoint Product and Technologies Architecture
Examining 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, the some of the components related to IIS 6.0 and ASP.NET we already seen and some of them we going to examine in this section so that we get the concrete understanding of WSS architecture.
See the figure 1.6, it reveals two important facts, first is that there is much more to WSS than only IIS6.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 configuration as well as content in the databases. This way WSS very cleanly distinguish and separate presentation from data . When WSS installed it creates a configuration database that stores the meta data , physical configuration 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 support multiple content databases for a single extended virtual server this way if there is huge load on the single content data base you can split the database into multiple.
The WSS also had some Windows Services to perform certain functionality.
The SharePoint Timer Service (see figure 1.6) is essentially a Windows Service that takes accounts of executing timely events, these are the actions that occur at predefined amount of time).
Alerts are the feature that is used to notify user about certain event , lets say that 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 look 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 same index based search as Microsoft Search.
Lets see the SharePoint Server Architecture as it leverages and existing WSS components and add some of its own
Examining SharePoint Portal Server 2003 Architecture
See figure 1.7 for SharePoint Server 2003 Architecture, which indeed build 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, which hide the WSS Site Structure under the cover , but again the point to note is that the a lot of work is done by WSS .Although there are certain restrictions as how WSS is used by SharePoint Server 2003 for example there can be only one Portal Site One Virtual Server. Further more the site collection containing a Portal Site must always be created at the root URL of the hosting Virtual Server.
As we see in WSS we got SharePoint Timer Service, the SharePoint add services of itself to the architecture .As the Items on the SharePoint Areas had bit more cardinality for Alerts than those in WSS so SharePoint come up with its own Alert Service. One example where this is required is when you set alert for certain item 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 users NT credentials to legacy applications -authentication schemes.
The Portal Sever Administration Service also a new addition, as the components had increased as well as services its quite important to create a certain central and standard Administration that can synchronizes 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 SPS indexing service, actually this is same MSSearch core that is shared by number of other Microsoft products, including SQL Server. The Indexing service crawls through the content in the SharePoint content database and set up the indices once they are build 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. Share Point Portal Server 2003 also extends the standard WSS database schemas for the configuration database as well as for content databases that contain portals.
Note:
By default WSS and SPS configure IIS application pools under the identity of AUTHORITY\NETWORK SERVICE account, this account has no permissions to log on SQL Server, so you must configure SQL Server to rant permissions to create databases and configure their security settings.
Difference in Roles of WSS and SharePoint Server 2003
There is a fundamental difference b/w WSS and SharePoint Server 2003 WSS is based on collaboration theme that in the sense its 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 its provides users with quick and easy way to find information and documents that are spread out around a private or scattered thorough out the Internet. So to sum it up WSS gives you a place to put all your content while SharePoint Server provided efficient means to navigate and search through your content when you need it.
Conclusion
In this article we see the underlying block for WSS and SharePoint Portal Server 2003, we start by taking a look into II6.0 Working Process model then counter the ASP.NET and its role with IIS6.0. We finally visited the WSS and SharePoint Portal Server Architecture and examine the key components that they are composed of. In the end we see the major difference in the Roles of WSS and SharePoint Portal Server 2003.