The article intends to highlight some of the drawbacks of using WSS as a platform for internet/extranet based web. The intent of the is not to do a complete feature comparison (although it highlights some of the required ones) but to enumerate some of the challenges and considerations with WSS platform. This should help managers in taking an informed decision.
It looks into WSS as a platform for Internet enabled web sites. Earlier version of Sharepoint, i.e. Sharepoint Portal Services simply lacked this ability because it allowed only for Active directory based authentication making it viable only for intranet environment.
Current version of Sharepoint has 2 variants named Microsoft Office Sharepoint Server (MOSS), which involves licensing cost, and WSS 3.0 which is shipped free with Windows Server R2 or can be downloaded for free.
Please note that WSS itself provides very limited capabilities and is applicable with limited set of requirements.
WSS vs. MOSS - Features
WSS 3.0 and MOSS uses the same Object Model. Application pool can be Created/Extended and can contain number of Site Collections each of which itself can have any number of subsites. Feature based deployment model is extensively used and a feature can be created that address some custom code for different events and then it can be activated to Site collection/Site/Subsite. For Site Definition, by default WSS allows template for blank, blog, wiki sites (you are free to create your own site templates).
WSS 3.0 provides for feature based solution deployment (for webparts, custom actions etc), basic branding support with hooks for customization, document management, search, some set of OOB webparts (like content query webpart, Html editor webpart), ability to hook custom authentication and role providers, and most importantly internet deployment with network load balancing based on Zones and non active directory based authentication. In terms of deployment, it may not have complete set of farm capabilities but it does allow for providing multiple servers for different services like indexing, load balancing etc. You can use either of Enterprise or Express Edition of SQL Server.
MOSS provides for all WSS features plus advanced content management, Enterprise search, Publishing, Site Content and Navigation, Business Data Catalogue, Infopath form Services, Excel Services, advanced Site and Content Localization/Globalization using Concept of Site Variations, User profiles management, lot of out of the box webparts, Single Sign On and many other features.
Is WSS enough for my needs?
What WSS doesn’t provide is a fairly long list but if you want to save heavily on the licensing cost and your requirement are limited then WSS may suffice your needs.
To illustrate this, let us start off with identification by area and side by side check what is provided OOB (or is customizable) and what is not supported.
Based on your intended site structure, you create an application pool containing Site Collections each of which containing any number of subsites. This is same as MOSS; the only difference being additional site templates provided OOB by MOSS. WSS will provide for only few templates like Blank Site, Blog and wiki Sites. MOSS provides Publishing template which you may want to drill to help in making decision.
For site structure you may want to ponder over whether to keep your sites under same site collection or different site collection.
Here we have two things. One is the navigation data source (Navigation Provider) and other is the Control which can display the Navigation Menu (Typically Top Bar Navigation, Side Bar Navigation and Breadcrumb Navigation).
Navigation provider will traverse through the site collection/sites and will create a tree structure for the sites/pages encountered. Each node of the tree contains link to the site/page. This works as an in input to Control which control the rendering of the control which can take care of the security trimming.
If you check out the WSS Central Administrator or any other Site’s web.config file, you will be following Navigation providers
There are a few instances of the portal site map provider that are defined in the MOSS web.config:
PortalSiteMapProvider.CombinedNavSiteMapProvider: attached to the global or top navigation menus
PortalSiteMapProvider.CurrentNavSiteMapProvider: attached to the current, or "Quick Launch" navigation menus
PortalSiteMapProvider.CurrentNavSiteMapProviderNoEncode: attached to the breadcrumb navigation
PortalSiteMapProvider.GlobalNavSiteMapProvider: Get the map for the global navigation
PortalSiteMapProvider.WebSiteMapProvider: enumerates Web sites (SPWebs) in the site collection
One point worth mentioning here is that in WSS, none of the provider provides for pages which you created in the sites. So if you want to show some link to site pages in any of the navigation, you may not be able to do so out of the box. To solve the problem, you can either write your custom navigation provider (if your scenario demands dynamic/frequent addition of Site Pages by the Content administrator and for each addition of page, the link for the page is required to be added to the Menu) or for Static Scenarios you can just manually the nodes in the Navigation tree using Sharepoint Designer. You can even think over creating a feature for extension of Site Navigation nodes.
WSS provide for Quick Launch Webpart which can show Document Libraries, Sites etc but that is more suited for intranet Scenarios. For extranet/Internet scenarios you may want to either use ASP.NET Site Navigation Control or a Sharepoint enhancement to it.
MOSS provides far greater capabilities in terms of Navigation by using Site Navigation and Structure feature and few Navigation webparts. The feature allows complete control over what should be rendered and how it should be rendered. The changes can be published at will using the publishing feature available.
You will certainly miss the site navigation and publishing capabilities of MOSS.
Branding means application of Master page, control over site’s look and feel etc.
MOSS provides publishing feature so Master page in one Site Collection is visible to all sites under it so essentially there is one Master Page from which all sub mater pages can derive and this can be controlled at design time.
WSS does not provide for this because lacking publishing feature, each site has its own Master Page document library and you cannot share the master page across site collections/Sites, at least at design time.
The way to solve this problem is to deploy the master page as a Site Collection feature. The feature can be Activated/Deactivated to site collection/sub sites and it programmatically sets the site’s master page. You will still miss the option to select and preview the master page each time a new page is created.
MOSS provides for feature called site variations which provide for great support for localization. Localization involves both Site Localization and Content Localization. WSS’s localization support is mainly resource files based.
Both in WSS and MOSS you can have your custom role and authentication provider and register it with WSS/MOSS. MOSS by itself provides for User Profile store which you may want to harness. Please refer this excellent whitepaper for understanding User Profile and Management in Sharepoint. http://store.bamboosolutions.com/kb/article.aspx?id=10829
Web parts are stored in Sharepoint Database and be activated/deactivated to a site collection/site as a feature. They are reusable components which can be added to any page.
Following are the options for Web parts:
1. Custom ASP.NET 2.0 Webpart
2. Sharepoint based web part
3. Custom ASCX Control within a web part
Design Considerations for Web part
- Deployment in GAC/Bin folder
- Interconnection between web parts
- Easy Customizability of web part
- Customization of webpart Layout at runtime
- AJAX Type Controls in a webpart
And following is the comparison chart
Create a custom ASP.NET 2.0 Web Part
Create a SharePoint-based Web Part
Custom ASCX Control in a Web part
- For most business needs.
- To distribute your Web Part to sites that run ASP.NET 2.0 or SharePoint sites.
- When you want to reuse one or more Web Parts created for ASP.NET 2.0 sites on SharePoint sites.
- To use data or functionality provided by Windows SharePoint Services 3.0. For example, you are creating a Web Part that works with site or list data.
- When you want to migrate a set of Web Parts using the SharePoint-based Web Part infrastructure to Windows SharePoint Services 3.0.
- To create cross page connections.
- To create connections between Web Parts that is outside of a Web Part zone.
- To work with client-side connections (Web Part Page Services Component).
- To use a data-caching infrastructure that allows caching to the content database.
- Development speed
- Full Programming support and customizable
- Slight Performance difference
- Deployment (Multiple DLLs)
Web parts can be Created/Customized using Windows Sharepoint Designer and Visual Studio.
Product group recommendation is to use ASPX based webparts as far as possible.
Let us take a basic scenario where you have following goals and requirements:
1. You want custom look and feel, Style sheet and Navigation etc
2. Anonymous and as well as authenticated user access
3. Multiple document libraries (may some lists also)
Based on your required site structure, you can create a web application and a site collection under it. Then you can add any number of sub sites under to realize your actual site structure.
Once you have the structure in place, the resulting website will be Windows authentication based. We can extend this website to allow for Network load balancing and anonymous access. Extend the web application to Internet Zone and allow for anonymous access for this site. Both of these sites will point to only one copy of content.
Now we allow for custom authentication by changing the web.config file of the user created website to switch to custom membership provider. Then you can import all your users to the WSS profile database. To configure authorization, you can create specific roles with permissions suited to your needs and then add those profiles to the specific roles. Create various document libraries which you may be interested in.
Now we will address branding aspects, you can create a new master page and for deployment create a feature that deploys your master page. Activate this feature to site collection and all sites can refer to it. For navigation you can create your own webpart which accepts various properties and using Sharepoint object model creates the menu items for you. You may also consider using existing Sharepoint provided Navigation providers and controls.
You can easily add additional features like search etc. Configure search services for your site by defining the search and indexing server. Please note that the page that shows search results used application.master as the master page.
For the content part, now you can create multiple webparts which provides for your business functionality.
While MOSS provides for lot of features and is an excellent platform for portal and Enterprise application integration but it involves huge licensing cost, for basic set of needs WSS platform may suffice.
Hope the information above will help you take an informed decision!!