第 4 章 ‐ Windows SharePoint Services のアーキテクチャ

トピック

コンポーネントの構造
物理的な構成
Windows SharePoint Services が使用する IIS サービス
Windows SharePoint Services による変更点
Web パーツページ
Web パーツのカスタマイズと個人用設定
Web パーツのエクスポート
サイトページ要求の処理
テンプレート
web.config ファイル
まとめ

Windows SharePoint Servicesは、SharePoint製品とテクノロジが動作するための基礎技術です。Windows SharePoint Servicesのアーキテクチャを論理的かつ物理的に理解することによって、製品の構成方法だけでなく、設定による影響の度合いを管理者が理解するのに役立ちます。この章では、Windows SharePoint Servicesのコンポーネントと、コンポーネント間の相互作用について説明します。また、Windows SharePoint Servicesが使用するWindows Server 2003サービスへの影響についても述べます。

SharePoint製品とテクノロジは最初のバージョンから大きく改良されましたが、いくつかの基本的なアーキテクチャは同じです。Windows SharePoint ServicesはSharePoint Team Servicesとほとんど同じ方法でページ要求を処理します。Windows SharePoint ServicesとSharePoint Team Servicesの最も大きな構造上の相違点の1つは、データおよび構成情報の格納方法です。

SharePoint Team Servicesでは、構成情報およびサイトのコンテンツ情報は、ローカルファイルシステム、レジストリ、IISメタベース、およびSQL Serverデータベースに格納されていました。Windows SharePoint Servicesでは、サイトコンテンツ、ドキュメント、製品情報、および構成設定などのすべてのデータがSQL Server 2000またはSQL Server 2000 Desktop Engine（Windows）（WMSDE）に格納されます。

  ヒント
Windows SharePoint Servicesに付属するWMSDEには、2GBの制限がありません。SharePoint Portal Server 2003と共にインストールされる標準のMSDEは、ストレージのサイズが2GBに制限されています。

コンポーネントの構造

Windows SharePoint Servicesでは、すべての情報をデータベースに格納することによって、コンポーネントがフロントエンドコンポーネントとバックエンドコンポーネントに完全に分割されます。Windows SharePoint Servicesのフロントエンドコンポーネントは、個々のサイトをホストし、クライアントの要求を処理するWebサーバーです。フロントエンドWebサーバーはWebサイトのコンテンツまたは構成情報を持たないため、「ステートレス」と呼ばれます。クライアントの要求を完了するために、フロントエンドサーバーはバックエンドデータベースに接続して必要なデータを取得し、Webページを構築してクライアントに送信します。図4-1にフロントエンドWebサーバーとバックエンドデータベースサーバーの関係を示します。

  ヒント
Windows SharePoint Servicesにおけるフロントエンドコンポーネントとバックエンドコンポーネントとの分割は、論理的なものです。物理的には、フロントエンドコンポーネントとバックエンドコンポーネントは、同じサーバーに存在していても、別のサーバーに分かれていてもかまいません。

Windows SharePoint Servicesの新機能

コンポーネントをフロントエンドとバックエンドに分割することにより、Windows SharePoint Servicesは、核となる部分が飛躍的に改良されました。構成の決定に影響する改良点を次に示します。

• バックアップ
  すべてのサイトコンテンツと構成情報を1種類のストレージに統合することで、バックアップ処理が簡略化されます。

• スケーラビリティ
  Windows SharePoint Servicesは、フロントエンドコンポーネントとバックエンドコンポーネントの両方が動作するシングルサーバーの小規模な環境から、複数のフロントエンドWebサーバーおよびバックエンドデータベースサーバーが動作する大規模な環境にまで対応できます。

• 可用性
  あるサーバーに障害が発生した場合でも、他のサーバーが処理を引き継ぐことによって、複数のフロントエンドWebサーバーが同じサイトコンテンツをホストできます。また、バックエンドデータベースは、クラスタ化することによって自動フェールオーバーに対応しています。

• データの統合
  すべての設定およびデータを1つの形式で1つの場所に統合することにより、データを保護します。

• カスタマイズ
  Web開発の基礎知識がある管理者ならば、HTMLエディタを使用して、Windows SharePoint Servicesで利用できる多くのテンプレートやプロパティをカスタマイズできます。なお、詳細にカスタマイズするには、ASP.NET Webページおよびフォームコントロールに関する知識が必要です。また、バックエンドデータベースをカスタマイズするには、SQL Serverのプログラミング知識が必要です。

フロントエンドWebサーバー

Windows SharePoint ServicesのフロントエンドWebサーバーは、Windows Server 2003のIISによって提供されるWebサービスを使用します。フロントエンドWebサーバーは、クライアントの要求に対応するだけです。バックエンドデータベースに接続し、要求されたサイトページおよびサイトコンテンツの取得に必要な最小限のファイルと設定だけがインストールされます。このため、フロントエンドWebサーバーはステートレスと見なされます。

バックエンドデータベース

SQL ServerとWMSDEのいずれを使用しているかに関係なく、Windows SharePoint Servicesのバックエンドサーバーはバックエンドデータベースを作成します。サイトデータと構成情報を分離するために、2種類のデータベースを使用します。サイトデータを格納するデータベースは「コンテンツデータベース」と呼ばれ、製品情報および設定を格納するデータベースは「構成データベース」と呼ばれます。小規模な環境にコンテンツデータベースを1つ展開することも、大規模な環境に数百または数千ものコンテンツデータベースを展開することもできます。なお、Windows SharePoint Servicesファームにコンテンツデータベースは複数存在することができますが、構成データベースは1つにする必要があります。

構成データベース

Windows SharePoint Services環境には、複数のWebサイトを含む複数のフロントエンドWebサーバーが存在します。Webサイトのコンテンツは、複数のバックエンドコンテンツデータベースの中の1つに格納されます。フロントエンドWebサーバーをステートレスに保つには、特定のサイトのデータがどのコンテンツデータベースに保持されているかを常に管理するための、集中管理データベースが必要です。フロントエンドWebサーバーは、サイトからページ要求を受信すると、まず構成データベースに接続する必要があります。パフォーマンス上の理由から、この情報は次の要求のためにフロントエンドWebサーバーにキャッシュされます。キャッシュされた情報はフロントエンドWebサーバーが使用します。

コンテンツデータベース

コンテンツデータベースは、要求に応じてコンテンツをフロントエンドWebサーバーに提供します。ここにはサイトドキュメント、リストデータ、Webパーツのプロパティ、およびユーザー名や権限など、すべてのサイトコンテンツが格納されます。コンテンツデータベースは、ユーザー数に応じてサーバーでWebサイトをサポートするために必要な数だけ作成できます。

物理的な構成

コンポーネントをフロントエンドとバックエンドに分割することによって、管理者はより柔軟にWindows SharePoint Servicesを構成できるようになりました。Windows SharePoint Servicesにはシングルサーバーからサーバーファームまでのあらゆる構成が用意されており、組織の大小に合わせてその規模を変更できます。

ユーザー数の少ない組織では、Windows SharePoint Servicesのシングルサーバーシステムを使用できます。シングルサーバーシステムでは、フロントエンドコンポーネントとバックエンドコンポーネントが同じ物理サーバーにインストールされます。この構成では、SQL Serverの代わりにWMSDEをバックエンドデータベースとして使用できます。組織のユーザー数が増加し、フロントエンドとバックエンドコンポーネントの物理的な分割が必要になった場合は、WMSDEをSQL Serverに移行できます。それには、IIS、Windows SharePoint Services、およびSQL Serverの管理ツールを使用して、いくつかの手順を実行します。

Windows SharePoint Servicesのサーバーファームでは、同じ構成データベースに接続する同一構成のフロントエンドWebサーバーを複数展開できます。NLB（Network Load Balancing：ネットワーク負荷分散）のような負荷分散ソフトウェアや、負荷分散ハードウェアにより、クライアントの要求が複数のフロントエンドWebサーバーに均等に分散されます。これにより、複数のフロントエンドWebサーバーに負荷が分散されるだけではなく、サーバーが互いにフェールオーバーを提供できるようになります。

Windows SharePoint Services が使用する IIS サービス

Windows SharePoint Servicesは、特定のソフトウェアセットでのみ動作します。フロントエンドサーバーでは、IISとASP.NETがインストールされたWindows Server 2003が動作している必要があります。バックエンドサーバーには別途、SQL ServerまたはWMSDEのインストールが必要です。WMSDEはWindows SharePoint Servicesの一部として含まれています。

Windows SharePoint Servicesは、IISがWebサービス用に提供するいくつかのサービスを使用します。図4-2に、Windows SharePoint Servicesがインストールされる前の、IISがWeb要求を処理する方法のアーキテクチャを示します。

仮想サーバー

IISは、仮想サーバーを使用して、管理、セキュリティ、およびリソースの境界をWebサイトに提供します。IISによって、既定のWebサイトと呼ばれる既定の仮想サーバーが［\Inetpub\wwwroot］フォルダにインストールされます。Windows SharePoint Servicesは、IISによって提供される仮想サーバーを使用して、Webサイトをホストします。

アプリケーションプール

「アプリケーションプール」はIIS 6.0の新機能です。各アプリケーションプールは、Webアプリケーションが実行される、分離された一連のワーカープロセスです。各アプリケーションプールは、独自のプロセッサとメモリリソースを使用し、サーバー上の独自の証明書セットが必要です。そのため、アプリケーションプールはセキュリティ境界も提供します。Windows SharePoint Servicesは、IISのアプリケーションプールを使用して、Webサイトにおけるリソースの割り当てを処理します。

認証

IISは「認証」を実行して、Webサービスにアクセスしようとしているユーザーアカウントを検証します。認証は、IISおよびWindows SharePoint Services内の仮想サーバーごとに行われます。Windows SharePoint Servicesでは、IISがフロントエンドWebサーバー上で認証を行います。そのため、認証方式の変更はIISの管理ツールやWindows SharePoint Servicesの管理ツールで行う必要があります。

ASP.NET

IISのインストール時には、セキュリティ上の理由から最小限の構成がインストールされ、提供されている機能の多くはインストールされません。Windows SharePoint Servicesの多くのコンポーネントはASP.NET上で構築されます。このため、Windows SharePoint Servicesをインストールする前に、IISにASP.NET用のアプリケーションサーバーコンポーネントをインストールする必要があります。

Windows SharePoint Services による変更点

アプリケーションプールや認証など、いくつかのIISサービスは変更なしで使用されますが、仮想サーバーや要求処理などのその他のIISサービスは、Windows SharePoint Servicesのアーキテクチャで動作するように変更されます。図4-3にWindows SharePoint Servicesのインストール時に追加および変更されるコンポーネントを示します。

要求ハンドラ

既定では、受信したすべてのHTTP要求は、IISがhttp.sysと呼ばれるカーネルモードドライバを使用して処理します。このファイルは、着信要求を読み取ってルーティングするだけです。Windows SharePoint Servicesは専用のハンドラをインストールします。これは「IHTTPハンドラ」と呼ばれるISAPI（Internet Server Application Program Interface）フィルタです。これにより、処理が次のように変更されます。

• すべてのASP.NETページ要求はIHTTPハンドラによって処理されます。

• ASP.NETコードを含まないHTMLページ要求などの他のすべての要求は、http.sysによって処理されます。

仮想サーバーの拡張

Windows SharePoint Servicesが仮想サーバーを使用するためには、仮想サーバーを拡張する必要があります。これにより、仮想サーバーはサイトコンテンツに対応する適切なコンテンツデータベースを指示する構成データベースに接続できるようになります。簡易インストールを使用して、Windows SharePoint ServicesがWMSDEと共にシングルサーバーにインストールされると、既定のIISの仮想サーバーは自動的に拡張されます。その他の場合は、Windows SharePoint Servicesの管理ツールを使用して各仮想サーバーを手動で拡張する必要があります。

Windows SharePoint Servicesの管理ツールでは、仮想サーバーを拡張することはできますが、作成することはできません。したがって、Windows SharePoint Servicesで仮想サーバーを拡張する前に、まずIISの管理ツールを使用して仮想サーバーを作成する必要があります。仮想サーバーを拡張するには、ローカルコンピュータのAdministratorsグループのメンバとしてログオンするか、Windows SharePoint ServicesとIISの両方の管理者権限を持つユーザーとしてログオンする必要があります。

Windows SharePoint Servicesのアプリケーションプール

Windows SharePoint Servicesで仮想サーバーを拡張するときは、使用するアプリケーションプールも選択します。Windows SharePoint Servicesでは、IISが既定のWebサイトのために使用するアプリケーションプールを使用します。Windows SharePoint Servicesのインストール中に、Windows SharePoint Services管理サイトを含む仮想サーバー用に、1つのアプリケーションプールが追加されます。管理サイト用に作成されるアプリケーションプールは、「CentralAdminAppPool」と呼ばれます。

アプリケーションプールでのリソースの割り当て

Windows SharePoint Servicesでは、アプリケーションプールを共有するよう一連の仮想サーバーを構成することも、各仮想サーバーを別々のアプリケーションプールに配置することもできます。アプリケーションプールを共有するとは、メモリ領域とプロセッサリソースを共有することを意味します。つまり、仮想サーバーの1つが失敗すると、すべての仮想サーバーが失敗します。また、仮想サーバー間で相互にデータへアクセスする可能性もあります。

仮想サーバーごとに別々のアプリケーションプールを設定するには、多くのメモリが必要です。個別のアプリケーションプールが割り当てられる仮想サーバーごとに、約150MBのメモリが必要です。

管理

Windows SharePoint Servicesの管理Webサイトには、「既定のIIS」アプリケーションプールの管理のためのWebページがあります。新規または既存の仮想サーバーに新しいアプリケーションプールを作成して割り当てる場合には、Windows SharePoint Servicesの管理ツールを使用できます。ただし、他の管理作業を実行するにはIISの管理ツールを使用する必要があります。

アプリケーション「プール」とアプリケーションプール「ID」は異なるものです。アプリケーションプールIDは、アプリケーションプールのセキュリティコンテキストとして使用されるユーザーアカウントです。アプリケーションプールIDとして指定されたアカウントは、フロントエンドWebサーバーがバックエンドデータベースに接続するために使用されます。Windows SharePoint Servicesのインストール時に作成されたアプリケーションプールには、インストール中にアプリケーションプールIDが割り当てられます。

既定では、セットアップの最後に構成データベースの管理アカウントとして設定したアカウントが、CentralAdminAppPoolのアプリケーションプールIDに指定されます。このアカウントは、CentralAdminAppPoolアプリケーションプールのパスワードが期限切れになるか、再設定された場合にのみ変更する必要があります。

IISの既定のWebサイトのアプリケーションプールIDは、拡張されている場合、Windows SharePoint Servicesで設定されます。ほとんどの場合、このアカウントはドメインアカウントです。ただし、SQL Serverを使用するシングルサーバー構成でインストールする場合は、このアカウントをローカルアカウントにすることができます。またこのアカウントは、構成データベース上のSQL Serverのdb_ownerデータベースロールのメンバである必要があります。

Web パーツページ

Windows SharePoint ServicesのWebパーツページは、さまざまな情報を取得して、1つの場所に統合するように設計されています。Windows SharePoint ServicesにおいてWebパーツページを構成する要素（Webパーツ）は、ページの処理方法や表示方法に影響します。WebパーツはWebパーツページで「Webパーツ領域」と呼ばれる領域にグループ化されます。これらの各コンポーネントは、Windows SharePoint Servicesサイトにおけるページの動作について重要な役割を担っています。

物理的には、Webパーツページは、FrontPage 2003などのWindows SharePoint Servicesで動作するHTMLエディタで変更できる、ASP.NETファイル（.aspx）です。Windows SharePoint Servicesには、Webパーツページの作成に使用できる8つのテンプレートが付属しています。これらの各テンプレートには、Webパーツを追加できるWebパーツ領域の異なるセットが含まれています。

Webパーツ

WebパーツはASP.NETサーバーコントロールから派生していますが、標準のASP.NETコントロールよりも簡単にカスタマイズできるように設計されています。Webパーツではコントロールのコードとプロパティが分離されているため、ユーザーはコードに触れることなくプロパティを操作できます。Webパーツのコードは、ASP.NET DLLであるアセンブリファイルに存在し、プロパティはサイトのコンテンツデータベースに読み込まれます。

Webパーツがインストールされると、多くの場合、「アセンブリファイル」はサイトをホストしている仮想サーバーの［bin］フォルダに格納されます。このフォルダがIISの既定のWebサイト上にある場合、パスは［Inetpub\wwwroot\bin］です。その他のアセンブリファイルの格納場所として、グローバルアセンブリキャッシュ（Global Assembly Cache：GAC）も利用できます。これは、既定では、［%SystemRoot%\assembly］フォルダになります。

［bin］フォルダに格納されているファイルは、部分的にしか信頼されません。つまり、これらのファイルはコンテンツデータベースにデータを自動的に保存したり、Webパーツオブジェクトモデルを使用したりすることはできません。WebパーツアセンブリファイルをGACに保存すると、これらの制限はありません。また、WebパーツはフロントエンドWebサーバーのすべての仮想サーバーで利用できるようになります。

いくつかのWebパーツには、Webパーツを正しく表示するために必要な、「リソースファイル」と呼ばれる別のファイルも含まれています。インクルードされるすべてのリソースファイルは、サイトサーバー上にローカルに格納されます。Webパーツの目的により、リソースファイルはイメージファイルから言語ファイルまで多岐にわたっています。リソースファイルは［\Inetpub\wwwroot\wpresources］フォルダに置かれますが、Webパーツアセンブリファイルだけは［bin］フォルダに置かれます。アセンブリファイルがGACにある場合、リソースファイルは［\Program Files \Common Files\Microsoft Shared\web server extensions\wpresources］フォルダに置く必要があります。URLアドレスが指定可能なファイルはリソースファイルと見なされ、該当の［wpresources］フォルダに置かれます。

Webパーツ領域

Webパーツ領域は、WebデザイナがWebパーツを編成したり動作を制御したりできる、Webパーツページ上のコンテナです。Webパーツ領域は、Webパーツが標準的なASP.NETサーバーコントロールとは異なる動作を行えるようにするシステムの一部です。Webパーツ領域内にWebパーツを配置することにより、WebパーツはWindows SharePoint Servicesのアーキテクチャを利用できます。Webパーツ領域外に配置すると利用できません。

静的Webパーツ

通常、Webパーツ領域には1つまたは2つのWebパーツが含まれます。ただし、必ずしもWebパーツをWebパーツ領域内に配置する必要はありません。Webパーツ領域外に配置されたWebパーツは、標準のWebコントロールと同じように扱われ、動作するため、「静的Webパーツ」と呼ばれます。静的Webパーツとそのプロパティは、Webパーツページ（.aspx）ファイルに格納されます。このためユーザーは、静的Webパーツとやり取りしたり、ブラウザ内で変更したりすることができません。

動的Webパーツ

Webパーツ領域内にあるWebパーツは「動的Webパーツ」と呼ばれます。これは、標準のWebコントロールや静的Webパーツと違い、ユーザーが動的Webパーツのプロパティを変更できるためです。Webパーツは、Webパーツ領域によってコンテンツデータベースに接続されることで、Windows SharePoint Servicesに参加できます。動的Webパーツのプロパティはコンテンツデータベースに保存されるため、ユーザーはプロパティにアクセスして操作できます。

Web パーツのカスタマイズと個人用設定

Windows SharePoint Servicesで使用されるWebパーツのビューは、共有ビューと個人用ビューの2種類があります。共有ビューはすべてのユーザーが見ることができるビューです。一方、個人用ビューは、ユーザーがビューを個人用に切り替えるとそのユーザーに対してのみ表示されるビューです。個人用ビューでは、ユーザーはWebパーツのプロパティを必要なだけ変更して、自分専用の設定を行うことができます。Webパーツのアーキテクチャにより、ユーザーが加えた変更は保存され、Windows SharePoint Servicesはそれぞれの個人用Webパーツのバージョンを常に把握できます。

カスタマイズと個人用設定

個人用設定（パーソナライズ）は、Webパーツの個人用ビューを作成することを指します。一方、カスタマイズは、すべてのユーザーが見ることのできる共有ビューに影響するWebパーツを変更することを指します。ページの共有ビューを変更するには、ページをデザインする権限が必要です。既定では、Windows SharePoint Servicesのページは共有ビューで表示されます。ユーザーがそのページの個人用ビューに切り替えて変更を加え、そのページを表示すると、個人用ビューが既定のページになります。WebPartPage DefaultviewPersonalというMETAタグが.aspxコードに含まれている場合、Webパーツページは個人用ビューを既定にするように設計されている可能性があります。

個人用設定

ページの個人用ビューに切り替えると、個人用設定は、サイトページのWebパーツの表示でプロパティを調整するのと同じくらい簡単になります。ページにWebパーツを追加することも簡単になります。追加したWebパーツは、設定したユーザーに対してのみ表示されます。動的Webパーツのプロパティは、Windows SharePoint Servicesのコンテンツデータベースに格納されます。プロパティに変更を加えると、この変更は個人用のWebパーツとして格納されます。共有ビューから変更されたプロパティのみ、データベースに別個に格納されます。Webパーツがそのユーザー用にレンダリングされるとき、Windows SharePoint Servicesによって違いが調整され、個人用ビュー用のプロパティが適用されます。

個人用設定の制御

Webパーツ領域を使用して、Webパーツのプロパティの変更を制御できます。Webパーツ領域のプロパティを操作することにより、Webデザイナは領域に含まれているWebパーツへの変更を禁止することができます。共有ビューのカスタマイズを許可して、個人用ビューの個人用設定を許可しないという設定も可能です。Webパーツ領域のプロパティは、ブラウザから変更することはできません。変更するには、Windows SharePoint Services上で動作するHTMLエディタを使用します。

Webパーツのプロパティを変更しても、アセンブリファイル内のコードは変更されません。Webパーツのすべてのバージョンで、同じアセンブリファイルが参照および使用されます。

Web パーツのエクスポート

Webパーツは、ユーザー間で簡単に共有できるように設計されています。ユーザーは個人用ビューまたは共有ビューのWebパーツをエクスポートできます。このとき、実際にWebパーツ全体がエクスポートされるわけではなく、Webパーツのプロパティだけがエクスポートされます。

Webパーツがインストールされると、プロパティは.dwpという拡張子の記述ファイルに格納されます。ユーザーは、Webパーツをエクスポートすることで新しいバージョンの記述ファイルを作成します。［Webパーツ］メニューの［エクスポート］が選択されると、コンテンツデータベースからプロパティの現在の状態が読み取られ、記述ファイルに保存されます。

Webパーツをインポートするユーザーは、アセンブリファイルや補助ファイルではなく、実際には記述ファイルだけをインポートします。.dwpファイルをインポートすると、新しいWebパーツが作成され、.dwpファイルで指定されたプロパティが新しいWebパーツに適用されます。その後、Windows SharePoint Servicesが設定をデータベースに保存します。その設定は、次にユーザーがページを参照するときのために保持されます。記述ファイルが読み取られ、カスタマイズされたプロパティが個人用ビューとしてデータベースに格納されます。ただし、WebパーツをインポートするフロントエンドWebサーバーのローカルにアセンブリファイルが存在しない場合、インポートは失敗します。

記述ファイル

「記述ファイル」は、自由に編集したり要素を追加したりすることができます。記述ファイルに加えられたすべての変更は、個人用設定のためにWebパーツの既定のプロパティを上書きします。異なる種類のWebパーツの記述ファイルには、その種類のWebパーツだけに適用されるそれぞれの要素を格納できます。記述ファイルに必須の要素は、<Assembly> 要素と <Typename> 要素だけです。ただし、Webパーツがインポートされた後にWebパーツの既定の名前と説明を表示するには、<Title> 要素と <Description> 要素を加える必要があります。次にイメージWebパーツの記述ファイルの例を示します。

<?xml version="1.0” encoding="utf-8”?>
<WebPart xmlns:xsd="http://www.w3.org/2001/XMLSchema"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  <Title>Image Web Part</Title>
  <FrameType>Default</FrameType>
  <Description>Use to display pictures and photos.</Description>
  <IsIncluded>true</IsIncluded>
  <ZoneID>LeftColumn</ZoneID>
  <PartOrder>1</PartOrder>
  <FrameState>Normal</FrameState>
  <Height />
  <Width />
  <AllowRemove>true</AllowRemove>
  <AllowZoneChange>true</AllowZoneChange>
  <AllowMinimize>true</AllowMinimize>
  <IsVisible>true</IsVisible>
  <DetailLink />
  <HelpLink />
  <Dir>Default</Dir>
  <PartImageSmall />
  <MissingAssembly />
  <PartImageLarge>/_layouts/images/msimagel.gif</PartImageLarge>
  <IsIncludedFilter />
  <Assembly>Microsoft.SharePoint, Version=11.0.0.0, Culture=neutral, 
     PublicKeyToken=71e9bce111e9429c</Assembly>
  <TypeName>
    Microsoft.SharePoint.WebPartPages.ImageWebPart
</TypeName>
</WebPart>

記述ファイルのタグには、Webパーツ要素を使用します。要素に値がなければ、既定値が適用されます。<Assembly> 要素には、Webパーツのアセンブリファイルの名前が含まれます。ローカルのフロントエンドWebサーバーにアセンブリファイルが存在しない場合、Webパーツは読み込まれません。

サイトページ要求の処理

ユーザーがWindows SharePoint Servicesサイトに接続しようとすると、その要求に対していくつかの特定の処理が実行された後、要求元のクライアントのブラウザにページが表示されます。図4-4に、要求がクライアントに返される前に、要求に対して実行される処理を示します。Windows SharePoint Servicesは、静的HTMLページ、ダイレクトモードでレンダリングされる.aspxページ、セーフモードでレンダリングされる.aspxページの3種類のうちいずれかの方法でページ要求を処理します。

ページ要求のルーティング

Windows SharePoint Servicesでは、いくつかのコンポーネントが追加されていますが、IISのアーキテクチャも使用して処理が行われます。IISのページ要求を処理するコンポーネントであるhttp.sysは、Windows SharePoint Servicesでも最初に要求を処理するコンポーネントです。Windows SharePoint Servicesがインストールされても、http.sysは変更されません。また、http.sysがIISに対して実行するのと同じ機能が、Windows SharePoint Servicesに対しても実行されます。http.sysは着信HTTP要求をリッスンし、フロントエンドWebサーバー上の適切な仮想サーバーのURLを解決し、要求元のユーザーを認証します。

要求は、http.sysで処理された後、Windows SharePoint ServicesによってインストールされたISAPIフィルタに渡されます。このISAPIフィルタ（STSFLTR.DLL）は、他のすべてのページ要求を正しいハンドラまたはインフラストラクチャに渡すことを目的としています。STSFLTR.DLLは、すべての静的HTMLページをIIS ISAPI拡張に渡します。.aspxページは、ASP.NETのインフラストラクチャかIHTTPハンドラのいずれかに直接渡されます。またSTSFLTR.DLLは、インクルードとエクスクルードも処理します。

.aspxページのレンダリング

Windows SharePoint Servicesのインストール中に、それぞれのリソースの種類とハンドラの種類の関連付けが定義されます。このマッピングセットは、この章で後述するweb.configファイルの <httpHandlers> セクションで定義されます。このセクションで定義されるハンドラの1つがIHTTPハンドラで、すべての.aspx要求を処理するために登録されています。IHTTPハンドラは、ASP.NETページをASP.NETに直接渡すダイレクトモードか、セーフモードで実行します。

ダイレクトモード

通常、ASP.NETページが実行されると、ページが読み取られ、Webサーバーに保存されるDLLファイルにコンパイルされます。コンパイルされたDLLは、毎回ページを解析する必要がないため、.aspxページより高速に実行されます。Windows SharePoint Servicesでは、このようにASP.NETページが処理されることを「ダイレクトモード」と呼んでいます。フロントエンドWebサーバーの_layoutsディレクトリにあるASP.NETページだけが、ダイレクトモードで実行されます。_layoutsディレクトリには、［ドキュメントとリスト］、［ページの作成］、［サイトの設定］ページなど、Windows SharePoint Servicesによって使用される固定のアプリケーションページが含まれます。このディレクトリはWebサイトの外にあると見なされます。Webパーツページに含まれる他のすべてのASP.NETページは、セーフモードで実行されます。

セーフモード

Webサイト内にあると見なされるASP.NETページは、セーフモードで実行されます。セーフモードでは、.aspxページのコードをDLLファイルにコンパイルすることは許されません。また、安全なコントロールのリストに含まれている、ページ上のコントロールだけが実行されます。安全なコントロールのリストはweb.configファイルに含まれます。すべてのWebパーツページはセーフモードで実行されます。

テンプレート

Windows SharePoint Servicesには、サイトやサイトページの作成に使用できるテンプレートが付属しています。サイト全体、またはWebパーツページ、会議ワークスペース、リスト、領域、クォータなどのサイトのさまざまな部分にテンプレートを適用できます。既定では、テンプレートは、フロントエンドWebサーバーのローカルファイルシステムの［\Program Files\Common Files\Microsoft Shared\ web server extensions\60\TEMPLETE］フォルダに格納されています。テンプレートを使用すると、データベース領域を節約できるだけでなく、Windows SharePoint Servicesのパフォーマンスも向上します。

データベース領域の節約

サイトのコンテンツデータベースには、サイト内で作成された各ページのレコードが格納されるドキュメントテーブルが含まれます。Windows SharePoint Servicesがサポート可能なサイト数やページ数を考慮すると、このテーブルのレコード数はかなりの量になる可能性があります。たとえレコード数が多くても、Windows SharePoint Servicesでは、既定で、テーブル内の各レコードを比較的空けておくことで、全体的なテーブルのサイズを小さく保ちます。テンプレートを使用してページを作成すると、コンテンツデータベース内のそのページ用のレコードには、ページの作成に使用されるテンプレートの位置だけが含まれます。ページのカスタマイズデータはレコードに含まれません。

各サイトページのカスタマイズは、レンダリング処理中にのみ行われます。レンダリング処理中は、ナビゲーションコントロールがページのURLを見て、サイトの名前を探します。コントロールは、サイト名を使用して、コンテンツデータベース内のカスタマイズ情報を探し、見つかったカスタマイズ情報で変更を加えてからページを表示します。同じテンプレートを基にしたページは同一になります。ただし、レンダリング処理中にカスタマイズされるため、この処理はユーザーに認識されません。

パフォーマンスの向上

テンプレートを使用すると、ASP.NETページはデザインどおりに実行されます。通常、ASP.NETページはフロントWebサーバー上で読み込まれ、DLLファイルに保存されます。そのページに対する以降の要求は、フロントWebサーバーのローカルファイルシステムからDLLファイルを実行して処理されます。Windows SharePoint Servicesでは、この処理はダイレクトモードと呼ばれます。テンプレートに基づいたサイトページは、ダイレクトモードで実行されます。DLLを作成する必要があるのは、ページのサイトのバージョンごとではなく、各テンプレートに対してだけです。ページのサイトのバージョンごとにメモリにDLLを読み込むのは現実的ではありません。

カスタマイズの影響

サイトページがカスタマイズされると、テンプレートやテンプレートに基づくサイトページのアーキテクチャにより向上していたパフォーマンスが失われます。サイトページのコードが編集されて保存されると、サイトページの読み込みにテンプレートを使用できなくなります。

このような状態が発生すると、Windows SharePoint Servicesは、サイトのコンテンツデータベースのドキュメントテーブルにあるサイトページのレコードを変更します。ページ全体のコピーを使って、サイトページのレコード内のテンプレートの位置が置き換えられます。また、ダイレクトモードで実行できるのはテンプレートだけなので、この時点からページはセーフモードで実行されます。

web.config ファイル

web.configファイルはXMLベースのテキストファイルで、ASP.NETサービスの構成情報が含まれます。Windows SharePoint Servicesには複数のweb.configファイルがあります。次にそれぞれの格納場所と説明を示します。

• ［\Inetpub\wwwroot］フォルダ
  この場所にあるweb.configファイルは、サーバー上のすべての仮想サーバーの構成設定を定義します。仮想サーバーが拡張されると作成されます。

• ［\Inetpub\wwwroot\wpresources］フォルダ
  この場所にあるweb.configファイルは、Webパーツの構成設定を定義します。仮想サーバーが拡張されると作成されます。

• ［\Program Files\Common Files\Microsoft Shared\web server rxtensions\wpresources］フォルダ
  この場所にあるweb.configファイルの目的は、このフォルダ内に置かれたファイルの場所の制限です。このフォルダには、GACにあるアセンブリファイル用のWebパーツのリソースファイルが格納されます。

• ［\Program Files\Common Files\Microsoft Shared\web server extensions\60\CONFIG］フォルダ
  この場所にあるweb.configファイルは、他の.configファイルと共に、他の仮想サーバーを拡張するための構成設定を定義します。

• ［\Program Files\Common Files\Microsoft Shared\web server extensions\60\ISAPI］フォルダ
  この場所にあるweb.configファイルは、_vti_binディレクトリの構成設定を定義します。このフォルダには、Windows SharePoint Servicesが使用するWebサービスが格納されます。

• ［\Program Files\Common Files\Microsoft Shared\web server extensions\60\TEMPLATE\LAYOUTS］フォルダ
  この場所にあるweb.configファイルは、_layoutsディレクトリの構成設定を定義します。_layoutsディレクトリには、ダイレクトモードで実行される信頼されたアプリケーションページが格納されます。_layoutsディレクトリに格納されているコンテンツは、フロントエンドWebサーバーのすべての仮想サーバーで利用できます。

• ［\Program Files\Common Files\Microsoft Shared\web server extensions\60\TEMPLATE\ADMIN\＜ロケールID＞］フォルダ
  この場所にあるweb.configファイルは、SharePointのサーバー管理のサイトを含む仮想サーバーで使用されるページの構成設定を定義します。

仮想サーバーがWindows SharePoint Servicesによって拡張されると、［\60\CONFIG］フォルダに、仮想サーバーのweb.configファイルを作成するために一緒に使用される.configファイルと.xmlファイルが格納されます。web.configファイルを［\60\CONFIG］フォルダから仮想サーバーのルートフォルダにコピーする前に、Windows SharePoint Servicesは、［\60\CONFIG］フォルダ内でwebconfig.*.xmlという形式の名前を持つ.xmlファイルを検索します。そして、そのファイルの内容とweb.configファイルを結合してから、仮想サーバーのルートパスにweb.configファイルを書き込みます。.xmlファイルで定義されているアクションは、仮想サーバーの構成設定に適用されます。.xmlファイルとweb.configファイルを結合する主な利点は、Windows SharePoint Servicesのアップグレードやweb.configファイルの上書きを行っても、カスタマイズ情報が失われないことです。

まとめ

Windows SharePoint Servicesでは、SharePoint Team Servicesから大幅な改良が行われています。アーキテクチャの主な変更点の1つは、すべてのデータと製品情報のデータベースへの統合です。この結果、フロントエンドコンポーネントとバックエンドコンポーネントは完全に分割され、Windows SharePoint Servicesの展開規模に柔軟性が与えられました。

Windows SharePoint Servicesのサイトアーキテクチャは、独自のインフラストラクチャを使用してサービスを追加する一方で、基礎となるテクノロジに依存しています。Windows SharePoint Servicesが使用し、ベースとなるサービスは、IIS、ASP.NET、およびWindows Server 2003によって提供されます。Windows SharePoint Servicesが提供するインフラストラクチャにより、クライアントの要求が処理され、クライアントが表示するページをレンダリングします。