The year was 1995. Although the Internet had been around for many years, only recently had its Hypertext Transfer Protocol (HTTP) and the associated Hypertext Markup Language (HTML) caught the public eye in the form of the World Wide Web. While the general public was falling in love with the Web through web browsers such as Mosaic, Netscape, and Internet Explorer, many companies were struggling to come up with ways to produce the content this new market was demanding.

One such company was Vermeer Technologies. Vermeer came up with a unique, modular approach to web design that it called FrontPage. It included prebuilt functionality for the server — the FrontPage Server Extensions (FPSE) — and modules for the design client (which it called WebBots). Unlike most web design tools, FrontPage included not only a WYSIWYG (what-you-see-is-what-you-get) editor (the FrontPage Editor), but full site management features for the client as well (the FrontPage Explorer). FrontPage 1.0 had only been on the market for a few months when the announcement came that Vermeer had been purchased by Microsoft, and that the FrontPage system was going to form the basis of Microsoft's web design strategy.

As advanced as it was, FrontPage was not immune to problems. In particular, the FrontPage editing client had a tendency to rewrite a page's code to meet its own specifications, which often resulted in nonfunctional scripts — a trait that most developers did not find endearing. Although each subsequent release of FrontPage was better behaved than its predecessor, the damage to its reputation was done. Ultimately, the name FrontPage had to be retired.

The product that was originally to become FrontPage 2007 lived on, however. In fact, it was reformed (and re-formed) into not one, but two, distinct products — SharePoint Designer 2007 and Expression Web 1.0.

Expression Web was designed primarily to satisfy the web designers who not only had no interest in working with SharePoint, but were among the most vocal critics of FrontPage's flaws. Virtually all support for SharePoint and the legacy FrontPage functionality was removed. In their place, Expression Web was given deep support for designing to web standards, ig to web standards, including standards-based ways of doing many of the things FrontPage did with its WebBots.

SharePoint Designer 2007 was effectively a superset of Expression Web 1.0. It gained all the new standards support, as well as retained the ability to work with SharePoint sites and the various FrontPage components.

In the years between the release of SharePoint Designer 2007 and 2010, Expression Web has been updated twice, adding ever more design tools, support for other standards, such as PHP, as well as having deeper integration with the rest of the Expression family. SharePoint Designer's feature set, on the other hand, remained static until the release of SharePoint 2010 (which is thoroughly covered in the rest of this book).

The following table shows the timeline of major milestones from the first release of FrontPage to SharePoint Designer 2010.

Meanwhile, back on the server, the FrontPage Server Extensions (FPSE) were being enhanced until, in the Microsoft Office 2000 releases, a new layer was created over the FPSE called the Office Server Extensions (OSE). The OSE added services for managing discussions and sending email alerts. In addition, file management protocols — including the then-new WebDAV — were added, allowing the Office client applications such as Microsoft Word and Microsoft Excel both to read from and write to websites directly for the first time.

The Years BSP (Before SharePoint)

Many other web server initiatives were taking place at Microsoft during this time frame. Two of them — Microsoft Site Server 3.0 and the Digital Dashboard Resource Kit (DDRK) — warrant special notice as ancestors of SharePoint, as shown in the family tree in Figure A-1.

Microsoft Site Server 3.0 was a massive product with many parts that were not directly related to one another beyond being installed and accessed through a common user interface. Several of these components, however, form conceptual (if not direct code) predecessors to components of Microsoft Office SharePoint Server 2007. Site Server included content management and deployment functionality, allowing the staging and incremental updating of websites. Also, Site Server contained a Knowledge Management framework, which let administrators define property sets that could be applied to items of content. Finally, Site Server introduced Microsoft's first Enterprise-class search engine (Site Server Search).

Figure A.1. Figure A-1

The Digital Dashboard Resource Kit (DDRK) was a set of tools to present pieces of content on a special web page called a dashboard. The pieces were called Web Parts and could be sourced a number of ways, from static content to JavaScript to ASP code. The dashboards and Web Parts were stored server-side — either in the file system, a SQL Server database, or an Exchange message store — accessed via standard HTTP and managed through the WebDAV protocol.

Fraternal Twins — It's All in the Name

The first products actually to bear the name SharePoint were released at about the same time as Microsoft Office XP (whose individual components were known as the 2002 Office Products). Two distinct products were named SharePoint: SharePoint Portal Server 2001 (SPS) and SharePoint Team Services (STS). Although some functional overlap existed, they were architecturally very different.

SharePoint Team Services (1.0)

SharePoint Team Services was an enhancement to the Office Server Extensions and was shipped with Microsoft Office XP Professional. Unlike the OSE and the FrontPage Extensions, however, SharePoint Team Services (STS) functioned as a full web-based application in its own right. STS included predesigned web pages, and introduced several key concepts — particularly lists, document libraries, and views. Although still conceptually present in current versions of SharePoint, these objects are very dissimilar in implementation from the way they were in STS. For example, STS used the web server's file system to store all pages and the physical documents for libraries, but kept configuration info, lists, and document metadata in a database. Although some elements are mentioned briefly in this appendix, Appendix B covers the present architecture of SharePoint in detail.

One of the key ways of manipulating these objects in code is called the Collaborative Application Markup Language (CAML). CAML was introduced in STS, has evolved considerably (like the objects it is designed to manipulate), and is still a key part of programming for SharePoint. For example, the query used by the modern Data View (a concept that did not exist in STS) of a SharePoint list or library is generated in CAML, not SQL.

Figure A-2 shows a typical SharePoint Team Services site. FrontPage 2002 was "aware" of all SharePoint Team Services features and could be used to customize and configure STS pages, lists, and libraries.

SharePoint Portal Server 2001

SharePoint Portal Server 2001 made use of the Digital Dashboard technology from the DDRK, and backed it up with many powerful server-side capabilities. Unlike the multiple back-end options provided for the DDRK, SPS exclusively used an updated version of the Exchange message store, which was renamed the Web Storage System. The Web Storage System held dashboard pages and Web Parts, as it did with the DDRK, but in SPS it also stored documents and other content.

SPS also included document library functionality, although it was very different from that provided in STS. SPS document libraries offered workflow and granular control over permissions. SPS also included an updated version of the enterprise search engine from Site Server, allowing SPS to crawl and index information from a wide variety of corporate data sources. Figure A-3 shows a typical SharePoint Portal dashboard.

Figure A.2. Figure A-2

Figure A.3. Figure A-3

Let's Get Together — Casting the (dot) Net

By the year 2003, SharePoint Team Services and SharePoint Portal Server had each secured a following, but a great deal of confusion existed because of the combination of similar names and superficially similar functionality with vast differences in architecture, programming models, and user interface between the two products. There had also been many changes to web programming. Microsoft had introduced the .NET Framework and with it ASP.NET. Web services and the SOAP protocol were starting to make inroads, and XML was becoming the lingua franca of data interchange.

Windows SharePoint Services — A Platform Is Born

For the next wave of SharePoint products, Microsoft attempted to resolve some of the confusion by moving both SharePoint Team Services and SharePoint Portal Server onto the .NET platform. This required a significant amount of rework to both the STS and SPS platforms, as well as going beyond the standard ASP.NET 1.1 ways of doing things. When the dust had settled, a new SharePoint foundation had been created.

This new child contained elements of both parents, as well as several characteristics of its own. In the process, SharePoint Team Services had earned a new name, Windows SharePoint Services (WSS), and a new place in the family tree. WSS would now be considered part of Windows Server, rather than Microsoft Office. As acknowledgment of its STS predecessor, WSS was deemed a 2.0 (version 2) product.

From SharePoint Portal Server 2001, Windows SharePoint Services inherited the concept (but not the implementation) of Web Parts as easily configurable modules to display content of various types on pages (now called Web Part Pages rather than dashboards). From SharePoint Team Services, WSS gained easily customizable lists, libraries, and views. Most of these elements, as well as library documents and other site-specific files, were now served from a re-architected content database.

Web Part Pages were a special case. Templates for Web Part Pages, and site definitions for the core website types, were housed on the file system. When one of these elements was instantiated, a placeholder, or ghosted item, was placed in the content database. The ghosted item contained a pointer to the original file and the instance information needed to make the item unique. These pages could be customized, however, by an editing tool such as FrontPage 2003, and in the process, a full instance of the customized file was stored in the database. That was called unghosting the file, and it could result in performance degradation, as well as complications when broader-scale changes needed to be made to all pages in a site.

Finally, the new platform introduced the capability to spread its functions across multiple servers and to serve the same content from multiple web front ends. This farm system was critical to improving SharePoint's scalability and resilience.

Opening a New Portal

SharePoint Portal Server 2003 was built upon the WSS foundation, and therefore contained all the WSS functionality. However, many features that were carried forward from SPS 2001 but not included in WSS were implemented through custom code in SPS 2003. In particular, portal sites and areas used a different page model and site hierarchy than standard WSS sites. Also, because the WSS document storage framework did not implement certain features that were present in SPS 2001 document libraries (such as item-level permissions and workflows), an option was provided to use a special backward-compatible document library, which continued using the Web Storage System instead of the new content database structure. Figure A-4 shows a typical page from a WSS or SPS 2003 site.

Figure A.4. Figure A-4

For the 2007 Microsoft Office System, Windows SharePoint Services was again significantly enhanced over its predecessor. WSS 3.0 was built on the ASP.NET 2.0 framework, which itself was enhanced with several concepts taken from SharePoint — specifically, ASP.NET 2.0 includes support for a Web Part framework. WSS 3.0 also made use of the Windows Workflow Foundation and ASP.NET 2.0 authentication models. In addition, many weaknesses of WSS 2.0 are addressed in WSS 3.0, including the following:

SharePoint Portal Server 2003 was replaced with Microsoft Office SharePoint Server 2007 (MOSS). As the name implies, MOSS was far more than a portal product. Enterprise Content and Records Management, enhanced social networking through My Sites, and the latest version of Microsoft's Enterprise Search technology were just the starting point.

A new level of MOSS functionality became available through the Enterprise Features. Although these Features were installed on all MOSS servers, they needed to be enabled with a special code, and could only be "legally" accessed by users who have an Enterprise Client Access License (CAL). Enterprise CALs are an extra-cost option. They permit access to server-side Excel Services, an InfoPath Forms engine, business reporting functions such as KPIs, and easy integration with third-party systems through the Business Data Catalog (BDC). Figure A-5 shows a default MOSS home page.

Figure A.5. Figure A-5

For the 2010 edition of SharePoint Products and Technologies, Microsoft has taken a more evolutionary approach. It again changed the product names, with SharePoint Foundation 2010 replacing WSS while once again becoming independent of Windows, and MOSS evolving simply into SharePoint Server 2010.

Much of the underlying structure is very similar to that of WSS 3.0 and MOSS (and is described in detail in Appendix B). Nevertheless, many new features have been added and a fairly significant change has been made to the underlying design elements of SharePoint master pages themselves. Although these elements are quite different under the skin, Figure A-6 shows that the core functionality of SharePoint remains.

Figure A.6. Figure A-6

Notice the distinct family resemblance in all the screenshots shown in this appendix. The number one request of people implementing SharePoint has historically been, "Can you make it look less like SharePoint?" As you have learned throughout this book, with your mastery of Microsoft SharePoint Designer 2010, the answer is a resounding "Yes!" However, you should also have learned how not to make these changes blindly, so as to retain all the goodness the SharePoint Foundation provides.