7 Dec 2016

SharePoint Development - MOSS 2007

This post is the second in a series looking at how SharePoint development has changed over the years, and how it is likely to change in the future. In this post, we will look the SharePoint 2007 release.

Series Outline:

 

MOSS 2007

The 2007 release (actually released in 2006) attempted to build on SharePoint 2003, and to integrate it more closely with the Microsoft Office suite. This version fixed many of the shortcomings of the 2003 product but also vastly expanded the platform’s core functionality. A major focus was placed on improving document and records management, alongside web content and portals. This version had a fully functional and integrated content management system, a result of the feedback on Content Management in the 2003 release. This gave rise to the infamous pie diagram for the SharePoint 2007 release:

Image showing pie chart of the MOSS 2007 Features

End users were given the option to navigate the platform to create team sites and manage workflows. As a result, SharePoint moved to become a more collaborative platform, and started to resemble the product we know today.

As in 2003, the product came in 2 different versions:

  • Windows SharePoint Services v3 (WSS 3.0), a basic free version for Window Server.
  • Microsoft Office SharePoint Services (MOSS 2007), the premium version built on top of WSS, with the new MOSS designation indicating the greater level of integration with the Office suite. This version was bundled with the Office 2007 suite and added enterprise search and people search, document repositories, additional Web parts, workflow, and content syndication. MOSS targeted organizations storing more than 500,000 documents (large enterprise customers).

The new features included with MOSS 2007 were:

  • Business Data Catalog
  • InfoPath Form Services
  • Excel Services
  • Content types
  • Use of SharePoint Designer to develop portals (replacing FrontPage)
  • Rights Management
  • Shared Service providers
  • Updated security model
  • Improved administration (now create and configure IIS web sites via Central Admin)
  • Improved authoring and site management experience
  • Updated MySite UI
  • Introduced minor versioning and document check out/in in document libraries for editing

 

Developing for SharePoint 2007

WSS 3.0 was built on top of ASP.NET 2.0 and IIS 6.0. Unlike WSS 2.0, requests to WSS 3.0 were routed through the ASP.NET runtime before reaching the WSS layer. This allowed the use of AJAX with SharePoint web parts and pages in WSS 3.0, as well as wrapping custom ASP.NET user controls (.ascx files) in web parts for deployment. Additionally, it allowed the use of  ASP.NET authentication (Forms Based Authentication). As portal sites no longer had to be created at the root of the IIS web site, hundreds of portal sites could be hosted inside a single IIS web site (in current SharePoint terminology, at the web application level).

SharePoint 2007 Stack Architecture (taken from http://dotnetslackers.com/articles/net/MOSS-2007-Architecture-and-Requests.aspx)

The stacked architecture was meant to encourage existing ASP.NET developers to start developing for SharePoint, as it meant that their existing skills and tools could be re-used for SharePoint development. However, developers new to the SharePoint platform still struggled to cope with SharePoint’s particular development methodology (such as features) and gotchas.

As a result of these fundamental architectural changes in the SharePoint architecture, upgrading from 2003 to 2007 was a painful  and laborious process. Additionally, updating custom site definitions (.stp files) when upgrading to 2007 was to be avoided - something that would be repeated in the next release as well. The use of custom site templates for application development, although available since the 2003 release, was heavily promoted in MOSS 2007 by Microsoft. This gave developers a means of creating custom templates for creating new sites in SharePoint with specific site or web features automatically activated. This led to a lot of messing around with GUIDs for features in onet.xml files, and using the Visual Studio Extensions for Windows SharePoint Services (VSeWSS) to package and deploy the custom templates.  In general, you could add custom site definitions easily enough, but it was very difficult to edit or delete an existing site definition.

Additionally, in MOSS 2007, an existing site could be saved as a site template (.stp file) for new sites. It is a package containing a set of differences and changes from a base site definition. It wasn’t as performant as the site definitions, as it was stored in the content database, while the site definition files were cached on IIS on the web front end servers. Site templates also weren’t as portable as site definitions, as to move them between farms, the farms had to be at the same version and patch level. This was because the site templates were dependent on the original base site definitions they were created from.

In WSS 3.0, features and farm (full trust) solutions were introduced. A feature is simply an XML definition for a component deployed to the SharePoint farm, with a specified scope (Farm, Web Application, Site and Web). Features were introduced in WSS 3.0 to address the failings in WSS 2.0 with regard to defining functionality used across multiple sites. Feature Receivers and Feature Stapling were also introduced, allowing modification of features on activation, and allowing features to be automatically enabled on specific site templates. Features were deployed in the new Windows SharePoint Services Solution Package (WSP) files that replaced the .cab file format used previously, and were deployed either using the SharePoint UI, or more commonly using the STSADM.exe tool (and a plethora of .bat files).  Again, I seem to recall a lot of messing around with DDF files to package and deploy web parts correctly.

In addition to all this, developers could now use:

  • Content Types: metadata used to describe the attributes and actions applied to a particular category of information, and used  to develop a logical information architecture. Content types are in practice the schema definition of a site or list, and allow us to encapsulate a data schema and make it independent of a location on a SharePoint site.
  • Integrated workflow and out of the box workflow templates
  • InfoPath Forms Services and Excel Services to integrate with existing business processes
  • Business Data Catalog
  • Integration with SQL Server Reporting Services

With the release of MOSS 2007, there was major growth in the use of SharePoint, particularly across the enterprise. In 2008, Microsoft reported more than 100 million SharePoint users across over 17,000 client organisations, and total SharePoint sales of more than $1 billion. The product and associated tools had matured enough to be a realistic platform for internet and intranet usage in large organisations. As a developer, it was better than the 2003 release to work with (a very low bar), but it was still an extremely frustrating product. The tooling in Visual Studio 2007, whilst improved since Visual Studio 2003, was still clunky and slow. Developers instead looked at third party tools to help with packaging and deploying solutions, such as:

There are probably many other tools that I can’t recall – feel free to call out any in the comments below.

SharePoint Online (BPOS)

In October 2007, the Business Productivity Online Suite (BPOS) was released. This was Microsoft's first attempt at establishing a SaaS offering. BPOS included SharePoint Online, Exchange Online, Office Communications Online and Live Meeting. The SharePoint Online offering was based on the SharePoint 2007 release. Depending on the subscription chosen, this would be either a Dedicated (single tenant) or a Standard (multi-tenant) instance.

While the BPOS offering was successful, Microsoft encountered a number of issues running high performance multi-tenanted instances of SharePoint Online using MOSS 2007, and this experience fed directly into the development of SharePoint 2010.

Next week, I’ll look at the release of SharePoint 2010 and how the developer story changed significantly.

No comments:

Post a Comment

Note: only a member of this blog may post a comment.