Overview of the SharePoint Team Services Architecture

A Web site based on SharePoint Team Services from Microsoft® is built on top of both the Microsoft FrontPage® Server Extensions and a Microsoft SQL Server or Microsoft Data Engine (MSDE) database in what forms a three-tier application. The client tier is the Web browser or Microsoft Office® XP client, the middle tier is the Web server running SharePoint Team Services, and the server tier is the SQL Server database. A SharePoint Team Services list itself amounts to a table that stores data and metadata, an abstraction on top of the database that allows the user to manage tabular data in a Web site environment.

The team Web site uses one database per virtual server, where it stores, retrieves, and updates list data and metadata. This database infrastructure is implemented by using SQL Server or MSDE. When the user modifies a list on a team Web site, the client computer sends the request to the server through either the server extensions Remote Procedure Call (RPC) protocol or HTTP protocol. The RPC is used by the Microsoft FrontPage® client to communicate with the server extensions for publishing or authoring activities on the Web, while the HTTP protocol is used by the browser or FrontPage client to communicate with the server for SharePoint Team Services functionality. When the browser posts URLs in HTTP, the Web server returns HTML files. The HTML files returned to the client are constructed in SharePoint Team Services by using static HTML files, FrontPage metadata files, and data in the SQL Server database.

The following illustration depicts the exchange that takes place between client, server, and database on a team Web site.

Dd588689.DBOverview(en-us,office.11).gif

For more information on lists, or tables, and the database infrastructure, see Overview of the SharePoint Team Services Database.

Dynamic Link Libraries

POST operations are made to one of several Internet Server Application Programming Interface (ISAPI) DLLs. The ISAPI DLL is loaded by Microsoft Internet Information Server (IIS) when the URL of that DLL is specified in a GET, POST, etc. The following table describes the functionality of the server-side DLLs used on a team Web site.

Name	Description
admin.dll	The ISAPI extension that implements administrative operations such as creating and deleting subwebs, and managing users through the FrontPage permissions dialog box. Path: http://www.server.com/subweb/_vti_bin/_vti_adm/admin.dll
author.dll	The ISAPI extension that implements authoring operations, such as uploading files, applying themes, renaming and deleting documents, and so forth. Path: http://www.server.com/subweb/_vti_bin/_vti_aut/author.dll
fpadmdll.dll	The ISAPI extension that implements the Administration pages, including the display of those pages and the execution of administrative operations from the browser. Path: http://www.server.com/subweb/_vti_bin/_vti_adm/fpadmdll.dll
owssvr.dll	The ISAPI extension that implements SharePoint Team Services functionality, such as list creation, deletion, and authoring, as well as the HTML page-rendering system. It is used directly from the browser (for example, creating a list by making an HTTP POST to `http://www.server.com/subweb/_vti_bin/owssvr.dll?Cmd=NewList)` and it is used programmatically through a client API when FrontPage interacts with the functionality of a team Web site. Path: http://www.server.com/subweb/_vti_bin/owssvr.dll
shtml.dll	The SmartHTML interpreter that is used to perform the FrontPage Server Extensions browse-time functionality, such as saving the results of HTML form submissions to a document in the user's team Web site. It doubles as the DLL that implements operations that can be performed by browsers against team Web sites on the server, such as determining what site a particular document lies within or the server extensions version. Path: http://www.server.com/subweb/_vti_bin/shtml.dll/_vti_rpc

For information on POSTS and RPC protocol, see Overview of the RPC Protocol.

Creating a SharePoint Team Services List

For basic operations of a list in SharePoint Team Services, the server uses:

core schema files and a list schema file to define field and view schemas for storing or displaying data.
static HTML site pages (such as AllItems.htm DispForm.htm, EditForm.htm, and NewForm.htm for each list) to provide a frame for rendering or submitting content.
database tables to store the list's data and metadata, including the field and view schemas defined by the schema files.

The core schema files apply globally to lists on the server, while each list schema file (SCHEMA.XML) applies only to a specific list type. Both kinds of schema file use Collaborative Application Markup Language (CAML) for transmitting field and view definitions to and from the database. Based on user input through the site pages, the CAML in the schema files is used to generate the field and view schemas (also CAML) that are stored for each list in the database.

When creating or modifying a list, the user makes selections in an HTML document that the server creates upon a site page by means of the database schemas. When the site page is opened in a browser, FrontPage components on the page expand on the server to draw in the stored view definition and data from the database to render the document. A list's site page thus serves as a place of transit for passing list data and schema definitions to and from the database, and CAML provides a vehicle for transmitting and emitting the data. For more information on CAML, see the CAML Schema Reference.

The following illustration presents a high-level view of the exchanges that occur between the file system and the database when a list is created.

Dd588689.Overview(en-us,office.11).gif

The core schema and list schema files are used during site provisioning and modification. The core schemas define global lists, base list types, field types, and list or document templates. Each list schema file defines the fields, views, and forms required for the given list, and depends on global definitions provided by the core schemas. Together, the core and list schemas define the unique properties of a list, specifying how its data and metadata are stored in the database, and how the list is rendered in the browser.

As an example of team Web site list processes, the creation of a new announcements list involves the following actions by the server:

The browser posts a request to owssvr.dll on the server to create the list, specifying the title and description of the list. The POST specifies the key value pair, Cmd=NewList, along with such parameters as ServerTemplate, which specifies a number identifying which list template to instantiate (for example, 104 indicates the Announcements list).
The server opens ONET.XML in the /Program Files/Common Files/Microsoft Shared/web server extensions/50/Templates/1033/xml folder and looks for the list template corresponding to the number specified in step 1. When it finds the template, it knows the location in the Layouts folder where the files for that template are stored. For example, a template definition in ONET.XML might look like the following:
```
<ListTemplate Name="announce" DisplayName="Announcements" Type="104" 
  BaseType="0" Default="TRUE"OnQuickLaunch="FALSE" SecurityBits="111" 
  Description="An announcement list makes it easy for team members to post 
  news and information for the rest of the team to see." 
  Image="_layouts/images/itann.gif"/>
```
This definition tells the server that the corresponding list template is stored in the Announce directory of the /Program Files/.../web server extensions folder.
The server opens a second file in the /Program Files/.../web server extensions area, in this case SCHEMA.XML of the Announce folder. This file includes the set of fields that constitute the list, which is combined with a set of universal built-in fields defined in ONET.XML (such as for ID number, author, editor, and last modified) to construct a CREATE TABLE statement that is responsible for creating the actual database table.
A directory is created for the new list in the /wwwroot/Lists folder, and the HTML site pages are copied from the setup area (/Program Files/Common Files/Microsoft Shared/web server extensions/50/1033/Templates/Layouts folder) to the new directory. The folder metadata for the directory (in the .fp_folder_info file of the /_vti_cnf subfolder) is initialized with the internal name of the list, the type of list, and the display name of the list.
The server creates a record in the List of Lists table for the new list, filling in all the columns based on the information specified in the NewList request and the instructions in SCHEMA.XML. The tp_RootFolder column contains the URL ID of the directory created in step 4, and the tp_Fields column contains field definitions that are drawn from both ONET.XML and SCHEMA.XML. The field definitions include display patterns that define computed fields, such as the title links for items displayed in AllItems.htm. (The LinkTitle field type, a field defined in ONET.XML, surrounds the values from a table's Title field with <A> tags to produce title links.)
In SCHEMA.XML, the server locates the Views and Forms sections and copies each view and form definition into the tp_View column of the Views table. Rows are created for each of the list's HTML site pages (AllItems.htm, DispForm.htm, EditForm.htm, and NewForm.htm), and the View column contains the schemas for rendering each of these pages. (The site pages contain FrontPage components that expand in the browser to pull in these view schemas from the database.)

The following illustration summarizes the process of creating a new list.

Dd588689.overview2(en-us,office.11).gif

Rendering

Rendering refers to the process of producing an HTML document to display in the browser. Since SharePoint Team Services is implemented as an ISAPI extension, the most common way of rendering is to browse to a page through owssvr.dll. For example, posting the following URL command, http://STSServer1/_vti_bin/owssvr.dll?Using=Lists/Announcements/AllItems.htm opens the Announcements list.

Once a command is posted, Microsoft Internet Information Server (IIS) starts up the SharePoint Team Services request, passing the URL to owssvr.dll. When the site page is opened, FrontPage components on the page (for example, ListView, ListForm, or ListProperty) are expanded and draw in the list's data and view definition from the database. Client-side JavaScript on the page executes and hides this internal URL that is sent to the server, displaying instead the Web URL of the site page, for example, http://STSServer1/Lists/Announcements/AllItems.htm. In addition, the script writes a <FRAMESET> tag in the document stream that causes the current page to be re-loaded, using owssvr.dll to process the page instead of loading the raw HTML page in the browser. The file owssvr.dll reads in the contents of the page and starts looking for CAML regions, those that begin with <ows:, in order to render the page.

Rendering, however, can also be initiated internally within the code. For example, the View element causes the server to look up the schema for the view that has been specified by its Name attribute, and then to render that CAML as a part of the overall rendering process. The following example renders the Announcements list:

<ows:XML>
  <SetList>Announcements</SetList>
  <SetVar Scope="Request" Name="ViewEmpty"></SetVar>
  <View Name="{86A4A751-27A8-4c21-99EA-241148C9AF2F}"/>
</ows:XML>

The unique view ID identifies which list view the server should expand from the database. In addition to defining the HTML layout of the toolbar and paged row sets for when the number of rows exceeds a certain limit, the server renders the following view from the View column of the Views database table:

<ViewHeader>
  <HTML><![CDATA[<TABLE ID="]]></HTML>
  <WebQueryInfo/>
  <HTML><![CDATA[" width="100%" border=0 rules=rows><TR ALIGN=TOP><FORM>]]></HTML>
  <Fields>
    <HTML><![CDATA[<TH class="ms-vh">]]></HTML>
    <Field/>
    <HTML><![CDATA[</TH>]]></HTML>
  </Fields>
  <HTML><![CDATA[</FORM></TR>]]></HTML>
</ViewHeader>
<ViewBody>
  <HTML><![CDATA[<TR>]]></HTML>
  <Fields>
    <HTML><![CDATA[<TD class="ms-vb">]]></HTML>
    <Field/>
    <HTML><![CDATA[</TD>]]></HTML>
  </Fields>
  <HTML><![CDATA[</TR>]]></HTML>
</ViewBody>
<ViewFooter>
  <HTML><![CDATA[</TABLE>]]></HTML>
</ViewFooter>
.
.
.
<ViewFields>
  <FieldRef Name="LinkTitle"/>
  <FieldRef Name="Modified"/>
</ViewFields>
<Query>
  <OrderBy>
    <FieldRef Name="Modified" Ascending="FALSE"/>
  </OrderBy>
</Query>

The query engine on the server translates the View definition into a SQL query for selecting list data to display.

For more information on rendering, see Page Rendering Elements and Field Rendering Elements in the CAML Schema Reference. For specific information on the View element, see the View element topic.

Script and Team Web Site Lists

Both JavaScript and Microsoft Visual Basic® Scripting Edition (VBScript) are used to perform various functions on a team Web site. Script is used on the HTML site pages, in several .js files in the /web server extensions/50/isapi folder, and it is also embedded within CAML schemas that define fields or views, although conversely CAML can itself be embedded within script. In addition, like CAML, script is often assigned to the S-XML attribute in FrontPage components.

In all cases, keep in mind that script always executes on the client, while any CAML you add executes on the server. This means that when you customize a team Web site by adding both script and CAML to an .htm page, the CAML executes on the server and is rendered on the client before the script is executed on the client. You may need to combine approaches described in this reference: for example, script to formulate commands based on user selection, CAML to define the view for displaying the list data, and URL protocol for posting the commands to the server. For an example of this approach, see Customizing Web Views in File Dialog Boxes. For examples of how to make server-wide or site-specific customizations using CAML on HTML pages and in the core schemas, see How to Use CAML. For information on the URL protocol, see Using the URL Protocol.

Note FrontPage components cannot be included within script because they cannot be extended within the script.

FrontPage Components and Lists

FrontPage components are often used in the site pages (List folders) and in the application pages (_layouts folder) to provide a client-side editing experience in FrontPage. They are the basic way of adding components to pages in a team Web site, including SharePoint Team Services components such as list views, list forms, and list properties (like the title of a list or its description). The components expand on the server when the page is browsed to, which pulls the schema definitions into the .htm page.

A typical FrontPage component used on a team Web page might look like the following from NewForm.htm for the Announcements list:

<!--webbot bot="ListForm" S-List="Announcements" S-Mode="NEW" 
preview="&lt;em&gt;[ListForm]&lt;/em&gt;"startspan --><ows:XML>
<SetList PreserveContext="TRUE">Announcements</SetList>
<SetVar Name="DisplayMode" Scope="Request">NEW</SetVar>
<ListForm Type="NewForm"/></ows:XML><!--webbot bot="ListForm" 
i-checksum="58236" endspan -->

This component expands on the server to create the New Item form used for adding items to the Announcements list. The component is identified as the ListForm component for NEW mode belonging to the list, which specifies that the New form view be pulled from the Views table and inserted into the display of NewForm.htm. The component also contains encoded preview text for the FrontPage client. When the page containing this component is browsed to, the component expands into a view table that lays out the entire form.

The following table lists some of the components that have been implemented to support FrontPage editing of SharePoint team Web site lists:

Name	Description
ListField	Specifies a particular field within the database. The s-Field attribute specifies the data type of the field.
ListForm	Specifies a form for a list (such as new item, edit item, or display item). The parameters specify the name of the list and the type of form. When the component expands, it sets the current list, sets the display mode to be appropriate for the kind of form, and then requests a rendering of the form through the <ListForm> tag.
ListProperty	Specifies a particular property of a list (for example, its title or description). This component expands to a <SetList> and a <ListProperty> tag, which are then interpreted by owssvr.dll at browse time, just like the other list components. Most list properties correspond directly to the values of columns in the Lists table for the list in question, although there are some computed properties, for example a property that returns the number of items in the list.
ListView	Specifies a view of a list. The parameters for this component are the name of the list and the view in question. When the component expands, it emits CAML (contained within <ows:...> tags) that sets the current list to that specified in the component's S-List parameter, then asks for a rendering of the view specified in the component's S-View parameter. When a view is edited in FrontPage, an extra attribute is added to the ListView component, S-XML, which contains the new CAML description of the view. When the page is saved to the server, the ListView component class on the server notices the S-XML attribute, updates the Views table (or creates a new entry if the view is new) and removes the S-XML attribute.
ListViewSel	Defines a view selector for a particular list. The HTML that is used in the view selector is specified by a bot attribute.
ProjectProperty	Specifies a property of the current site, typically a column from the Projects table. This component expands into the <ProjectProperty> tag.

At browse time, these tags are recognized by the XML parser, and the corresponding rendering functions are performed. The FrontPage editor recognizes these components, just as it recognizes the other traditional server extensions components, and provides a user interface for editing.

FrontPage components often serve as a useful indicator of where you should insert code blocks when you customize a page using CAML, within FrontPage or other editing environments. For example, in Layout Customization view of FrontPage, the following ListField component in Default.htm can be replaced with CAML to define a custom links view for the home page.

<!--webbot bot="ListField" s-Field="URL" s-Title="URL" s-Context="viewbody" b-ShowTitle="FALSE" -->

The following CAML sample, when substituted for the above component, defines a view in which the targets of the links open in a separate window:

<ows:SetVar Name="FieldName">URL</ows:SetVar>
<ows:ForEach Select="/FIELDS/Field" MatchVar="FieldName">
  <HTML><![CDATA[<a target="_blank" href="]]></HTML>
  <Column/>
  <HTML><![CDATA[">]]></HTML>
  <Column2 HTMLEncode="TRUE"/>
  <HTML><![CDATA[</a>]]></HTML>
</ows:ForEach>

To make such replacements, be sure to pick the right component. Default.htm contains another component named ListField, whose s-Context attribute is set to viewheader.

For more information on FrontPage components, see the FrontPage Software Development Kit.