SharePoint - Windows SharePoint Services (WSS) Overview and Architecture

Intend
Off lately I have started working on technologies based on C# and ASP.NET. Initially I used to concentrate on scalability and performance optimization in C#. Now I have started looking into SharePoint technology. While I was searching for the materials on SharePoint there were a lot of materials which describes the functionality part but I was not able to find any single document that helped someone new to C# and ASP.NET in understanding SharePoint. In this article I am trying to cover the basics of SharePoint so as to enable someone new with these technologies all of the content which I am putting down over here are collected from various sites given inline and in Reference sections so all courtesy to them.

  • Overview of ASP.NET Applications
  • SharePoint Technology Stack
  • Windows SharePoint Services v2 vs v3
  • Windows SharePoint Services Architecture


Overview of ASP.NET Application
All most all of us are aware about server side scripting languages where the processing of the code takes place in the server and final HTML output is send back to the client for browser rendering. Similarly MS has a technology which is similar to that which is ASP.NET. ASP.NET has a very rich set of controls and features that enables us to write scalable and extensible web applications. So before we proceed to I would like to touch upon how ASP.NET is being handled by MS web server named Internet Information Server (IIS).



Within IIS we have a mapping list for extensions which map *.aspx to a particular DLL name which will be processing the request for resources of type *.aspx (eg: http://code.grep.in/sample.aspx). Now whenever a request is received by server it redirects the request to corresponding DLLs which are called Internet Server API (ISAPI) extensions. Now similarly they have ISAPI filters, ISAPI extensions are end points where they process the most part of the request. ISAPI filters can be cascaded in the sense we can have multiple ISAPI filters through which the request can go. There are specific hook point where we can plug-in these ISAPI filters. So for processing *.aspx request we have extensions which does all the ASP.NET file parsing and response building. ASP.NET also has something like ISAPI filters and ISAPI extensions and they are HTTP Modules and HTTP Handlers respectively.

SharePoint Technology Stack
Figure 2 shows the technology stack related to SharePoint. Light blue components are the basic foundation on which SharePoint is built upon. What SharePoint returns back by consuming those fundamental services are colored dark blue and dark red.We don’t have to understand all of it you will be able to co-relate few of them by the end of this article.



There are rich set of feature supplied by Core Workspace Services which can be referred to as Windows SharePoint Services (WSS, the blocks in dark blue) and the Applications/Portals can be referred to as MOSS (Microsoft Office SharePoint Server, the blocks in dark red).MOSS is built on top of WSS technology so it extends the WSS features and provides much more new features and tighter integration with Microsoft Office Applications like Word, Excel etc.

Windows SharePoint Services V2 vs V3
Before we jumpstart into architecture let me tell you few of the interesting design changes. In v2 WSS used to have a ISAPI filter which sits in IIS and which sees the Inclusion and Exclusion list to figure out if it is a ASP.NET Page or WSS requestas shown in Figure 3. Once that is done WSS Extension used an unmanaged code to interact with ASP.NET.So the integration was tighter with IIS rather than ASP.NET and they had problems with WSS code getting ran before ASP.NET context gets initialized. Another problem was that WSS had implemented its own ASP.NET parser for handling the ASP.NET pages residing in databases as there was not mechanism to do so in ASP.NET 1.1. This particular WSS ASP.NET parser lacked lot many features supported by classic ASP.NET parser. There was always non-sync with parser features with this implementation.



In order to avoid all the issues and conflicts they redesigned WSS on using ASP.NET. Now WSS it completely written using ASP.NET and now they have HTTPModules and HTTPHandlers to serve the request. ASP.NET 2.0 provided a mechanism to fetch pages from databases using HTTPModules which is called Virtual Path Provider; clients can extend the Virtual Path Provider to implement their own ways to fetch ASP.NET pages. WSS has one called SPVirtualPathProvider within SPRequestModule which does the processing for database persistent ASP.NET pages.

Windows SharePoint Services Architecture
From the technology stack diagram we know the features provided by WSS. Figure 4 shows the internal components and a sample flow of request.Wildcard mapping (*) enables the request to be routed to ASP.NET extension; another way to look at WSS is serving all types of resource like *.doc, *.ppt, *.aspx.




Within ASP.NET runtime they create a worker request for the same incoming request and we have a application factory which manages all the applications like SharePoint application (SPHttpApplication). The entire application specific configuration like external DB connector details all resides in web.config which get reread on modification enabling us to do only the fly changes without affecting older application instances. Older application instances will be still alive if it is in use but destroyed once it has processed all the assigned requests. With ASP.NET we can have multiple modules as show like Auth Modules, Session Modules, SPRequestModule etc. SPRequestModule is one which fetches the URL residing in databases.We can see various HttpHandlers like SPHttpHandler, ASP.NET Page handler, ASP.NET Web service handler etc. SPHttpHandler is the HttpHandler responsible for WSS related handling.



WSS is a kind of operating system for a web – a network built on the HTTP and HTML protocols. We have Administrative Object Models to mine the data within WSS in an organized object model hierarchy.Given below is the general WSS architecture that we can think off.
From the diagram itself it is evident that WSS is an user-friendly system of content creation, storage and management. WSS has various databases associated with it like
  • Configuration DB
    • Metadata
    • Configuration settings
    • Information about every single IIS Web site that has been SharePoint-extended in the Web farm
    • A Web farm can have only single configuration DB and multiple content DB
  • Content DB
    • Actual site content
    • User Information
  • Admin DB
    • Central Administrator tool


References
With this I guess I have provided some basic overview about what WSS is.

Upcoming articles which I plan are based on:
  • MOSS Architecture
  • User profile management in WSS and MOSS
  • Overview of Administrative Object Model

Labels: , ,

About this entry

You’re currently reading “SharePoint - Windows SharePoint Services (WSS) Overview and Architecture,” an entry on ANOOB BACKER Technical Blog

Published:
7:20 pm
by -