MOSS WSS Components Architecture in a single diagram

I stumbled upon this image in one of the msdn forms. This image grabbed my attention at once because in single image it encompassed all the components for Windows SharePoint Services(WSS), MS Office SharePoint Server 2007(MOSS) and the various dependent components and add-on servers. Keep this handy to answer any quick question by your friend or a business user.


I found this MOSS logical architecture diagram from msdn available in visio and XPS format.

Below is the JPEG format of the same:

MOSS Logical Architecture


SharePoint & Windows Workflow Foundation – (Sequential, State Machine Workflows, InfoPath Forms)

Below are the plethora of links to learn Workflows and its integration with SharePoint using InfoPath forms and or ASPX pages. You will find here some nice resources for State Machine Workflows in particular.

If you are new to workflow development then as a 1st step towards it, learn sequential workflows. Either read my former blog post or go for this step by step sequential workflow example. – this is a quick 9 min video: I recommend this to be your 1st step towards learning state machine workflows. For a detailed video of the same example check out the MS webcast by Pravin Indurkar. The Order Processing Application code is available for download in the below Microsoft Workflow Samples link. – Windows Workflow Foundation Samples – 7 part series – links/recommended books – More links … – Blog

The below 4-part series is a good and The Best example or sample available related to Workflows and SharePoint:

Windows Workflow Foundation – Excellent Use Case:

Add Custom ASPX Pages or ASP .Net Pages in SharePoint

The Problem: Let’s say we have an ASP .Net Web Application with many web forms, user controls, business layer, and data access layer. It works fine as a web application. What we are looking for integrating the files within this web application into the SharePoint site and totally get rid of the web application. This has couple of advantages:

  1. Business users and end users need not go to a separate web application (URL). Users can see all those pages within SharePoint site.
  2. Once the integration is done, we have the SharePoint site’s security and access rules i.e. Authentication and Authorization is in place without any additional work.
  3. Simple development experience as compared to developing with web parts.

In a nutshell this option allows us to build an ASP.Net application outside of SharePoint, build it, test it & then add it to SharePoint. Now, the problem is what are the ways to deploy the ASP .Net application pages into SharePoint and which one is should we go with. After doing some research and work I found that there are many ways in which we can do this. Below is a brief discussion of the sam.


  1. The SharePoint designer approach: This approach can be used if there are few aspx pages with little functionality.
  2. Using web parts. This can be used in conjunction with SharePoint designer. But once again, developing many web parts is not feasible and also raises performance issues.
  3. _Layouts folder approach: This is the simplest of all. Just deploy the web application pages under the _layouts folder of SharePoint and the pages can be accessed from any SharePoint site. Cons: The pages don’t inherit the security and access rules from SharePoint. The pages can be accessed from any site existing on that server farm. Master Page integration is not possible. MSDN Article explains with a sample.
  4. User controls using Smart Part: In this approach, the developer can develop web parts using the third party Smart Part control. In this way the developer can have the drag – drop functionality as he/she can develop it as a user control and drop it in the smart part. This method is similar to web parts but the developer has the privilege of drag-drop functionality but it still carries the negatives mentioned for the web parts approach.
  5. Using features and WSP package: Following some steps as recommended by Andrew Connell (MOSS MVP). Here is the blog. I believe this is the standard approach users are using in the SharePoint developer community.
  6. Using VSeWSS (Visual Studio extensions for WSS): This is yet another and latest solution. Microsoft recently released the VSeWSS 1.1 RTM. Using this, we can deploy all the asp .net pages into SharePoint by setting up a new project in Visual Studio. VSeWSS creates a solution package using features. Setup the project and hit ‘Deploy’ and it is done.

Below are the blog links I referred to:

More Links: Some are related to SharePoint 2003.

Yet another nice contribution by Andrew Connell :