ホーム ライブラリ ラーニング ダウンロード サポート コミュニティ
サインイン | United States - English | |
このトピックはまだ評価されていません - このトピックを評価する

Windows SharePoint Services のアーキテクチャの概要

Microsoft Windows SharePoint Services Product Team
Les Smith
Microsoft Corporation

October 2004
日本語版最終更新日 2004 年 11 月 29 日

適用対象:
   Microsoft Windows SharePoint Services
   Microsoft Office SharePoint Portal Server 2003

要約: Microsoft Windows SharePoint Services に実装されているアーキテクチャについて見ていき、ユーザーがページ要求を発行したときのサーバーの動作と SharePoint Services の応答について説明します。また、Windows SharePoint Services のアンマネージ コードとマネージ コードの役割の違い、および Windows SharePoint Services データベース スキーマについて説明します。この記事には英語のページへのリンクも含まれています。

目次

システムの概要
Web サーバーのトポロジ
IIS および ISAPI フィルタを使用した要求の処理方法
Web パーツのインフラストラクチャ
Windows SharePoint Services のアンマネージ コード
構成データベースのコンテンツ
まとめ

システムの概要

Microsoft Windows SharePoint Services の展開では、次の 3 つのサーバー コンポーネントが有効です。

  • 1 つ以上のフロントエンド Web サーバー
  • 1 つの構成データベース
  • 1 つ以上のコンテンツ データベース サーバー

これら 3 つのコンポーネントは、1 台のコンピュータにインストールすることもできますが、サーバー ファーム内の複数のコンピュータに分散してインストールすることもできます。状態に関するすべての情報は、Microsoft SQL Server のコンテンツと構成データベースを通じて管理されます。

Dd583133.odc_wssarchitecture_fig1(ja-jp,office.11).gif

図 1. Windows SharePoint Services の展開の概要

Web サーバー

Windows SharePoint Services を実行しているサーバー ファームでは、Web サーバーは状態のない複製です。要求は負荷分散を通じていずれかの Web サーバーにルーティングされ、各サイトはいずれかの Web サーバーにより処理されます。Web サーバーは、バックエンド データベースに接続してデータを取得し、Web ページを構築してそれをクライアントに返します。Web サーバーがサーバー ファーム内で停止すると、要求は別の Web サーバーにルーティングされます。Web サーバーを追加すると、展開のキャパシティを増強することができます。Web サーバーには、ドキュメントやその他のエンド ユーザー データは格納されません。すべての Web サーバーのコンテンツと構成設定は、データベース サーバーに格納されます。

コンテンツ データベース サーバー

バックエンド コンテンツ データベースには、サイト ドキュメントやドキュメント ライブラリ内のファイル、リスト データ、Web パーツのプロパティ、およびユーザー名や権限など、すべてのサイト コンテンツが格納されます。Web サーバーとは異なり、各コンテンツ データベース サーバーは同一ではありません。特定サイトのすべてのデータは、1 台のコンピュータの 1 つのコンテンツ データベースにのみ存在します。SQL Server は、データベース サーバーが停止した場合にサービスが中断されないように、バックアップによるフェールオーバー保護機能を備えています。

構成データベース

構成データベースは、要求を適切なデータベースに振り分けたり、バックエンド データベースの負荷を分散して、展開に関するすべての管理を行います。フロントエンド Web サーバーが特定サイトのページ要求を受信すると、構成データベースをチェックして、サイトのデータが保管されているコンテンツ データベースを確認します。構成データベースは、Web サーバーと同じコンピュータまたは Microsoft SQL Server を実行しているリモート コンピュータ上で実行することができます。

Web サーバーのトポロジ

Windows SharePoint Services の展開における Web サーバーのトポロジ (論理的レイアウト) は、コンテキストにより異なります。Windows SharePoint Services を展開する場合、ユーザーは既定で Microsoft インターネット インフォメーション サービス (IIS) 内に 2 つの仮想サーバー (Web サイト) を作成します。管理仮想サーバーとして使用する Web サイトを作成し、ポート 80 で既存の IIS Web サイトを拡張してエンド ユーザーまたはランタイム仮想サーバーを作成します。

Dd583133.odc_wssarchitecture_fig2(ja-jp,office.11).gif

図 2. IIS 内にある既定の管理およびエンド ユーザー仮想サーバー

"管理" 仮想サーバーは 1 台のコンピュータに 1 つだけ保持できます。このサーバーは、すべてのフロントエンド Web サーバーを構成して、新しい仮想サーバーを拡張するのに使用します。

Windows SharePoint Services の展開では、1 つ以上の仮想サーバーを実装することができます。仮想サーバーは 2 通りの方法で構成できます。既定の構成を行うと、IIS 内の仮想サーバーでドメイン名が解決されます。この構成では、各サーバーごとに 1 つのドメイン名を持つ複数の仮想サーバーを作成できます。もう 1 つの構成方法はスケーラブル ホスト ヘッダー モードと呼ばれます。このモードでは、IIS 内で使用されるホスト ヘッダー モードの機能が拡張されます。このモードを使用すると、ホスト ヘッダーまたはドメイン名を使用してサイトを解決し、単一仮想サーバーで複数のドメイン名のホスティングが可能になります。

エンド ユーザー仮想サーバーのスケール エンティティはサイト コレクションで、これは最上位のサイトまたはルートの Web (たとえば、http://VServer/[sites/]SiteCollection など) および任意の数のサブサイト (たとえば、http://VServer/[sites/]SiteCollection/Subsite) で構成されます。最上位のサイトには、Web パーツ、リスト テンプレート、サイト テンプレート ギャラリーなどが含められ、最上位のサイトがサイト コレクション内にあるすべてのサイトの管理を行います。仮想サーバーはサイト コレクションによりパーティション化され、特定の URL の名前空間が異なるセグメントに分割され、各サイト コレクションには独自の名前空間 (たとえば、http://VServer/[sites/]YourSiteCollection や http://VServer/[sites/]MySiteCollection など) が与えられます。Windows SharePoint Services は、コンテンツ データベース全体のサイト コレクションの負荷を分散できますが、各サイトは常に親のサイト コレクションと同じデータベース内に存在します。

サイト コレクションは IIS Web サイトや IIS 仮想ディレクトリと同等ではないため、IIS がサイト コレクションを認識することはありません。

SharePoint Portal Server 2003 に関する注意点: Microsoft Office SharePoint Portal Server 2003 を展開する場合、機能が強化された Windows SharePoint Services サイト コレクションがポータル サイトとなります。各仮想サーバーごとに 1 つのポータル サイトがありますが、追加の標準 Windows SharePoint Services サイト コレクションは、仮想サーバー上で作成することができます。

IIS および ISAPI フィルタを使用した要求の処理方法

ベースの HTTP 要求を処理するのは IIS ですが、マネージ パスまたはデータのインクルードやエクスクルードを実行するように IIS の動作を変更する ISAPI フィルタ (STSFLTR.DLL) を実装するのは Windows SharePoint Services です。ISAPI フィルタは、要求を Windows SharePoint Services ISAPI 拡張にリダイレクトするか、ASPX ページ (.aspx) と Web サービス URL (.asmx) をフィルタを通じて SharePoint ASP.NET ハンドラに渡します。

Dd583133.odc_wssarchitecture_fig3(ja-jp,office.11).gif

図 3. ASP.NET または ISAPI 拡張にルーティングされた HTTP 要求

SharePoint Portal Server 2003 に関する注意点: SharePoint Portal Server を展開する場合、SQL Server にサービスとプロファイル データベースが同時に作成され、ASP.NET の下に ADO.NET レイヤが実装されます。

IIS の役割

IIS は、HTTP.SYS ドライバを使用して IIS Web サイトまたは SharePoint 仮想サーバーに指定されたポートをリッスンして、HTTP 要求を適切なアプリケーションにルーティングし、受信 IP パケットを処理します。既定では HTTP 要求にはポート 80 、HTTPS 要求にはポート 443 が使用されます。IIS は、要求の送信先となる仮想サーバーのドメイン名、ポート、および IP アドレスを使用して要求を解決します。IIS Web サイトは展開に関する管理、セキュリティ、リソースの境界を提供しますが、Windows SharePoint Services コードは仮想サーバーのレベルから下位方向に実行され、サイト アクティビティを処理します。

IIS は、各仮想サーバーごとにすべてのユーザー認証 (匿名、統合 Windows 認証、または基本) を行い、匿名要求の有効化を管理します。IIS の匿名アクセスが無効になると、仮想サーバー全体に対して無効になるため、匿名要求が Windows SharePoint Services に届くことはありません。ただし、認証されていない要求を受け取るには、Windows SharePoint Services を構成する必要があります。認証されていない要求を受け取るように IIS で構成されていても、認証されていない要求を受け取るように Windows SharePoint Services で構成されていない場合、要求は拒否されます。

IIS を使用したユーザー認証処理に加え、Windows SharePoint Services では IIS 6 の新しいアプリケーション プール機能を使用して、仮想サーバーを別のアプリケーション プールで実行することができます。各アプリケーション プールは、独自のプロセッサとメモリ リソースを持ち、Web アプリケーションで実行される分離された一連のワーカー プロセスを提供します。Windows SharePoint Services は、アプリケーション プールを使用してリソースを割り当てます。これには次の長所があります。

  • プロセスの認証: Windows SharePoint Services は、SQL Server 認証を使用するように構成されていない限り、アプリケーション プールの認証を使用して SQL Server に接続します。
  • プロセスの分離: 同じコンピュータで複数の仮想サーバーを稼動させることができます。サーバーがそれぞれ別のアカウントで実行される場合、共通の構成データベースを共有することにはなりますが、各データベースは完全に個別に保存されます。アプリケーション プールはセキュリティの境界を提供します。各アプリケーション プールには、サーバー上で独自の資格情報が必要となります。
  • アプリケーションの再利用: 以前のバージョンの IIS では、プロセスの実行に時間がかかり、サーバーにとってリソースのリークが大きな脅威となっていました。現在のバージョンの IIS では、プロセスが再利用されるため、リソースのリークによるサーバーへの影響はなくなりました。

Windows SharePoint Services による IIS への変更点

Windows SharePoint Services は、IIS アプリケーション プールと認証に変更を加えずに使用しますが、Windows SharePoint Services アーキテクチャに統合するための仮想サーバーまたは要求処理などのその他の IIS サービスには変更を加えて使用します。Windows SharePoint Services が単一のコンピュータにインストールされる場合、Windows SharePoint Services は既定の IIS アプリケーション プール DefaultAppPool を既定のエンド ユーザー仮想サーバーと共に使用するための独自のアプリケーション プール STSAppPool1 で置き換え、管理仮想サーバー用の追加のアプリケーション プール STSAdminAppPool を作成します。サーバー ファームのコンテキストでは、管理者が両方のプールを作成して名前を付けます。

SharePoint Portal Server 2003 に関する注意点: SharePoint Portal Server に既定で作成される管理アプリケーション プールの名前は、CentralAdminAppPool です。

マイクロソフトの SharePoint Team Services とは異なり、Windows SharePoint Services は仮想サーバー レベルの下にある IIS のメタベース内に構成データを記録しません。すべてのサイトとサイト コレクション情報は、IIS から独立して SharePoint 構成データベースに格納されます。これにより、サーバー ファーム構成の管理が簡単になります。

ISAPI フィルタを使用してパス要求を処理する

ISAPI フィルタ (STSFLTR.DLL) は、認証の前に要求された URL を調べて、管理者により制御されているインクルード パスおよびエクスクルード パスのリストに基づき、要求を Windows SharePoint Services マネージ パスに宛てられたものかどうかを判断します。ISAPI フィルタは、次のロジックに従って要求をルーティングします。

  • マネージ パスでない場合、パススルーを許可します。
  • マネージ パスで、_layouts or _vti_bin などの仮想ディレクトリに存在する場合、URL をサーバーのルートにある _layouts or _vti_bin に書き換えます。
  • マネージ パスだが _layouts に存在せず、.aspx または .asmx ファイルに対する要求である場合、パススルーを許可します。この場合、要求は ASP.NET ISAPI 拡張で処理されてから、Windows SharePoint Services のマネージ ハンドラで処理されます。
  • マネージ パスでなく、_layouts に存在せず、.aspx ファイルでも .asmx ファイルでもない場合、Windows SharePoint Services の ISAPI 拡張を書き換えます。

SharePoint ISAPI 拡張への要求は、静的 HTML ページのコンテキスト、FrontPage Server Extensions リモート プロシージャ コールのプロトコルなどのレガシ プロトコル、および新しい DAV プロトコルや静的ページ GET (たとえば、.htm や .doc ファイルの取得) のコンテキストで発生します。

マネージ パスの主な機能は、Windows SharePoint Services で管理する URL 名前空間を定義することにありますが、セルフサービス サイトの作成中に使用されるパスの定義も主な機能の 1 つです。これにより、管理者はサイトを作成する場所を制御できます (たとえば、サイト作成の場所を指定のディレクトリに限定したり、http://Server/UserSites/ などの URL を含めるように指定できます)。

パスにはインクルードとエクスクルードのいずれかを指定できます。エクスクルードを使用すると、特定の URL 名前空間が拡張サイトに関連付けられないように指定できるので、Windows SharePoint Services が要求をインターセプトするのを防ぐことができます。Windows SharePoint Services は、エクスクルード パスに送られた要求を無視します。一方、インクルードを使用すると、SharePoint 展開で使用される URL 名前空間をいくつかのサイト コレクションにパーティション化する方法を指定できます。インクルードには、次の 2 つがあります。

  • "明示的インクルード" はサーバーのルート自体が SharePoint サイトであることを意味し、Windows SharePoint Services が管理する Web サイトを指定します。
  • "ワイルドカード インクルード" は、Windows SharePoint Services が管理する特定ディレクトリの下にあるサイト コレクション全体を指定します。
注: SharePoint Portal Server 2001 をアップグレードして Web ストア ドキュメント管理を使用する場合、SharePoint Portal Server はエクスクルードを使用して、ポータル ルート サイトの仮想ディレクトリ パスの下などの Web ストア システムに URL を公開します。SharePoint Portal Server は、既定で 2 つのワイルドカード インクルード (1 つはチーム サイト向け、もう 1 つは個人サイト向け) を実装し、パーティション化スキーム ("/teams" や "/sites" など) を使用して最上位のサイト フォルダとサブサイト コレクションが混同されるのを防ぎます。

ASP.NET ハンドラおよびページ レンダリング

Windows SharePoint Services の ASP.NET ハンドラは、ページの実行時に使用する ASP.NET モード ("ダイレクト" モードまたは "セーフ" モード) を決定するフィルタの役割を果たします。

仮想 /_layouts ディレクトリに存在する "アプリケーション" ページ と呼ばれるページは、ダイレクト モードで実行されます。つまり、Windows SharePoint Services ではこれらのページをインターセプトしませんが、ASP.NET では正常に実行することができます。アプリケーション ページには、新しいリストの作成や表示の編集などに使用するネイティブ SharePoint ページが含まれます。/_layouts ディレクトリのコンテンツは Web サイトの外にあると見なされ、要求に応じて直接 IIS からページが提供されます。このディレクトリにあるカスタム ASP.NET ページ内では、任意のコードを使用できます。

ホームページ、リストやアイテムを表示するページ、Web パーツ ページなどの Web サイト内にある ASP.NET ページは "ユーザー" ページと呼ばれ、セーフ モードで実行されます。つまり、管理者がコントロールをセーフに指定した場合に限り、Windows SharePoint Services 上で Web フォーム コントロールを実行できます。これらのページは、ユーザー インターフェイスや Microsoft Office FrontPage 2003 などを使用してカスタマイズすることができますが、ランタイムにブラウザでテキストとしてしかレンダリングされないユーザー ページに任意のコードを追加することはできません。ダイレクト モードとは異なり、セーフ モードでは ASP.NET ページは DLL にコンパイルされません。特定の仮想サーバーの Web サイトで実行できるセーフ コントロールのリストは、サーバーの Web 構成ファイルを編集することにより変更できます。

注: ASP.NET アプリケーションを Windows SharePoint Services と共存させ、SharePoint ISAPI フィルタの干渉を受けずに同じサーバーで実行させるには、アプリケーションの URL を除外する必要があります。また、アプリケーションの Web 構成ファイルを変更して、SharePoint ASP.NET ハンドラを削除する必要があります。アプリケーションのコードは除外されている URL で実行されるので、Windows SharePoint Services アセンブリを参照することはできません。詳細については、「Microsoft SharePoint Products and Technologies 2003 Software Development Kit (SDK)」の「Working with web.config Files」を参照してください。

Web パーツのインフラストラクチャ

Web パーツのインフラストラクチャにより、Windows SharePoint Services をセーフ モードで処理できるので、ページ URL、現在のユーザー ID、データベースに格納されたその他の情報に基づいて、Web パーツを ASP.NET ページへ追加できます。

Dd583133.odc_wssarchitecture_fig4(ja-jp,office.11).gif

図 4. Web パーツ ページのゾーンへのデータ挿入

Web パーツ ページをブラウザで開くと、Windows SharePoint Services がページ URL とユーザー ID を使用して SQL Server からページに指定された Web パーツのリストを返し、ASP.NET ページ オブジェクトを作成します。これによりページの Web パーツ ゾーンに、指定した Web パーツのデータが挿入されます。たとえば、SharePoint サイトのホームページには、既定でお知らせ、イベント、リンク リストの要約ビューを表示する Web パーツと、ロゴを表示するイメージ Web パーツの 2 つの Web パーツ ゾーンが含まれます。ただし、管理者がページの個人用の設定を許可し、ユーザーがページをカスタマイズできる場合、Windows SharePoint Services はユーザーごとに異なる Web パーツを表示します。

Windows SharePoint Services のアンマネージ コード

サイトで動作する Windows SharePoint Services とリストで使用されるロジックのほとんどは、主に以前の SharePoint Team Services で使用されるダイナミック リンク ライブラリ (DLL) を通じて提供され、アンマネージ コード内に存在します。Windows SharePoint Services の Web パーツとその他の ASP.NET オブジェクトや ISAPI 拡張は、実際はアンマネージ コードの上に位置するシン レイヤです。Web パーツと Web サービスは、新しい SharePoint オブジェクト モデルの上に作成され、オブジェクト モデルはアンマネージ コードを呼び込むラッパーの役割を果たします。

アンマネージ コードは、Microsoft Office FrontPage 2003 Server Extensions、DAV プロトコル、ビューのレンダリング、静的ドキュメント GET、およびすべてのデータベース入出力をサポートします。プリンシパル DLL である owssvr.dll は、リストの処理に使用されるほとんどのロジックを提供します。これにはデータの定義とテキストの処理に使われる独自の XML 言語 (Collaborative Application Markup Language (CAML)) を解釈するロジックなどが含まれます。

各フロントエンド Web サーバーには、CAML スキーマ ファイルを含むセットアップ ディレクトリ (Local_Drive:\Program Files\Common Files\Microsoft Shared\web server extensions\60\) 内にサイトとリスト定義が含まれます。スキーマ ファイルは、新しいサイトのインスタンスやリストの作成方法、およびリスト データの表示方法などを決定します。サイトとリストの定義については、「テンプレートと定義の紹介」を参照してください。

SharePoint Portal Server 2003 に関する注意点: SharePoint Portal Server は、ADO.NET を通じてマネージ コードへのアクセスを追加でデータベースに実装します。

ビューのレンダリング

CAML は、Web パーツでのリスト ビューのレンダリング方法を定義します。各 Windows SharePoint Services リストは、\web server extensions\60\TEMPLATE\Language_ID\Site_Definition\LISTS ディレクトリに独自の SCHEMA.XML ファイルを持ち、HTML ページがブラウザで表示されたときのリストの表示方法を定義します。以前のバージョンでは、SharePoint Team Services のリスト ビューはブラウザの CAML アイランド ("ows" プリフィックスにより示される) の拡張を通じて伝えられましたが、Windows SharePoint Services では、 次の図に示すように、Web パーツを通じて CAML ビューが表示されます。

Dd583133.odc_wssarchitecture_fig5(ja-jp,office.11).gif

図 5. Windows SharePoint Services の Web パーツによるリスト ビューのレンダリング

CAML SCHEMA.XML ファイルには、既定のリスト ビューの定義と各アイテムの処理に使用されるフォームの定義が含まれます。CAML は、クライアントのブラウザに必要な HTML とスクリプトを構築するのに使用されます。これには、ビューのヘッダーで使用されるスクリプト、ツールバー、列のヘッダー、ビューの本文で使用されるフィールド名やフィールド値、およびビューのフッターで使用されるページ ナビゲーションやリストのプロパティが含まれます。CAML は Windows SharePoint Services のコンテキストで使用して、Web パーツのビューで必要とされるマークアップ、スクリプト、またはテキスト (HTML、XML、WML、ECMAScript (Microsoft JScript または JavaScript) など) をブラウザに送り出すことができます。CAML は、カレンダー コントロールのリスト ビューで使用されるスクリプトなどの複雑な領域を構築するのに使用します。

注: データ ビュー Web パーツは、SharePoint リストまたはリスト ビューから XML を構築し、XSLT (Extensible Stylesheet Language Transformation) を使用してリスト ビューのユーザー インターフェイスをレンダリングできるので、標準的なアプローチでハイエンドのカスタマイズができます。Windows SharePoint Services は XML 形式でデータを提供し、FrontPage が代替 Web パーツを実装してデータのビューをレンダリングします。

SCHEMA.XML に加え、Windows SharePoint Services では次の CAML スキーマ ファイルが使用されます。

  • WEBTEMP.XML: チーム サイトやドキュメント ワークスペース テンプレート、または特定の会議ワークスペース テンプレートの Windows SharePoint Services に含まれる既定の定義など、展開で使用する複数のサイトを定義できます。このファイルを編集すると、サーバー ファーム内のすべてのサイトに影響を与えます。
  • ONET.XML: 新しいサイトに含めるリストとページを定義します。
  • FLDTYPES.XML: Windows SharePoint Services およびその HTML レンダリングに使用する各フィールド型の SQL の実装を定義します。
  • BASE.XML: データベースに存在するリスト、ドキュメント、ユーザー情報に関するテーブルなどのグローバル リストのスキーマを定義します。
  • DOCICONS.XML: 各ファイルの種類を表すアイコンを定義して、ファイルの種類とアプリケーションを関連付けます。

サイトとリストの定義については、「テンプレートと定義の紹介」および「Customizing SharePoint Sites and Portals: Part 1」を参照してください。.

カスタマイズ ページ

セーフ モードを使用すると、サーバーにコードを置かずにサイトをカスタマイズできるだけでなく、サイトに作成するオブジェクト数とデータベースに保管するデータ量を削減できるので、スケーラビリティが向上します。

以前の SharePoint Team Services では、サーバーに多数のサイトを作成した場合、AllItems.htm ファイルやアイテム フォームなど、各リストの各ユーザー ページの数だけコピーを作成する必要がありました。Windows SharePoint Services では、ユーザー ページがカスタマイズされていない限り、セットアップ ディレクトリの CAML SCHEMA ファイルにページ定義がすべて含められ、定義がフロントエンド Web サーバーにキャッシュされます。定義をキャッシュすると、サイトやリストを作成するたびに Windows SharePoint Services がユーザー ページのコピーを作成する必要がなくなります。これらのページは、ブラウザでは実際のページのように見えますが、CAML スキーマ ファイルからコンテンツを派生させて表示させた仮想ページです。定義をキャッシュすると、カスタマイズされていないページをサイト全体で再利用したり、不要なデータ ストレージやページに必要なメモリのフットプリントを削減して、スケーラビリティを最大限に高めることができます。Windows SharePoint Services はデータベースのクエリを実行して、要求されたページがカスタマイズされているかどうかを判断します。カスタマイズされていない場合、データベースにファイルのすべてのコンテンツは含まれず、カスタマイズされていないページが含まれるセットアップ ディレクトリのフォルダへのパスのみがクエリに返されます。カスタマイズされていない Web パーツ ページに関しては、SQL Server は Web パーツ ゾーン内に表示される Web パーツのリストのみを返します。

サイトの default.aspx が要求されると、Windows SharePoint Services は最初にページのソースがカスタマイズされているかどうかを確認します。カスタマイズされている場合、ドキュメント テーブルのコンテンツ列に null は含まれません。カスタマイズされていない場合、バイナリ形式のページ コンテンツが含まれます。定義は、セットアップ ディレクトリからではなく、データベースから取り出されます。ページをカスタマイズした後に、元のページ定義に戻すことはできません。同様に、AllItems.aspx ページのリスト ビューがカスタマイズされている場合、変更されたビューはデータベースの Web パーツ テーブルの tp_View 列に格納され、リスト ビューの定義がセットアップ ディレクトリから取り出されることはありません。

構成データベースのコンテンツ

Windows SharePoint Services のインストールには、展開を管理する 1 つの構成データベースが必要です。このデータベースの構成設定は、管理仮想サーバーを通じてのみ変更が可能で、設定はエンド ユーザー仮想サーバーでは読み取り専用になっています。

構成データベースには、次の一般的な種類のデータが保存されます。

  • グローバル設定: ファーム内にあるWeb サーバーやデータベース サーバーなどのサーバー ファームに関する情報。
  • 仮想サーバー: 特定の仮想サーバーに使用する SMTP サーバーやサイトの既定設定など、展開に使用する各仮想サーバーに関する情報。
  • サイト マップ: 特定のサイトのデータがどのコンテンツ データベースに含まれるかなどの情報。Windows SharePoint Services が要求された URL を受け取ると、このデータベースの設定によってサイトのデータが含まれるコンテンツ データベースが確認されます。

図 6. は、コンテンツ データベース ルックアップ使用時のサイト マップの処理方法を示しています。

Dd583133.odc_wssarchitecture_fig6(ja-jp,office.11).gif

図 6. 仮想サーバーの相対 URL に基づくコンテンツ データベース ルックアップ

要求は、http://MyServer/sites/mysite/Lists/AllItems.ASPX のサーバーに送信されます。URL の相対部分、sites/mysite は、要求のサイト コレクションを指定します。サーバー上で作成されたサイト コレクションのワイルドカード組み込みは、既定で sites により提供されるので、sites/mysite はサイト コレクションを指定する仮想サーバー相対フラグメントです。URL の相対部分でコンピュータ名が除外されるので、同じアドレスまたは異なる複数のアドレスを持つ 2 つの仮想サーバーで同じコンテンツの処理が可能となり、サイト データにエクストラネット用サイトとイントラネット用サイトの両方のデータを持つことができます。

前の例では、構成データベースが STS_01 というデータベースの ITG_STS_1 というデータベース サーバーに存在するサイトのデータを指定しています。この情報が構成データベースから収集されると、Web サーバーのセッション cookie にデータベース ID (図6 の 101) が キャッシュされて、次の要求で正しいデータベースに接続するのに使用されます。Windows SharePoint Services は、最後にユーザーがサイトを訪れてからサイトが移動していないことを前提に、オプティミスティック キャッシュ スキームを使用します。キャッシュされた URL が間違っている、またはなくなっている場合は、Windows SharePoint Services が構成データベースをチェックしてサイトが移動されたかどうかを確認し、自動修正アルゴリズムによりシステムの調整が行なわれます。

SharePoint Portal Server 2003 に関する注意点: SQL Server をインストールすると、SharePoint Portal Server が独自のテーブルを構成データベースに追加して、このデータベースを使用してファーム内のサーバーのアクティビティ (検索やインデックス作成、シングル サインオンを使用中のユーザーなど) の追跡を行ないます。また SharePoint Portal Server は、代替アクセスのマッピングやエクストラネットのマッピングを追加して、複数の代替ストアの集計を実行します。

コンテンツ データベース スキーマ

Windows SharePoint Services は、SQL Server データベースにすべてのエンド ユーザー データを格納します。これには次の長所があります。

  • リスト データ、ドキュメント、およびメタデータが正規化されたテーブルに保存される。
  • ドキュメントおよびドキュメント メタデータのトランザクションを更新できる。
  • ドキュメントおよびドキュメント メタデータのバックアップに一貫性がある。
  • 記憶域レイヤをプログラムできる。
  • デッドロックを検出および解決できる。

以前の SharePoint Team Services は各サイトに 1 つのデータベースおよび各リストに 1 つのテーブルを実装していますが、Windows SharePoint Services はスケーラビリティを強化するため、サーバーごとに決まったデータベース スキーマおよび決まった数のデータベースを使用します。少ない数のデータベースにすべてのリスト データを格納する、またリスト スキーマのマッピングを物理テーブルに格納するのは論理的に理にかなっています。また、ストアド プロジージャを使用することにより SQL Server との往復回数も最小限で済み、入出力ロジックをデータ ストレージに近接させることができます。

Dd583133.odc_wssarchitecture_fig7(ja-jp,office.11).gif

図 7. コンテンツ データベースのコア スキーマ

サイト テーブルには、データベース内で表されている各サイト コレクションに適用される設定が含まれており、これは各サイト コレクション内で作成されたすべてのサブサイトに適用される既定の設定です。テーブルは、各サイト コレクションの各最上位のサイト、およびポータル サイトのコンテキストにおけるルート サイトと "個人用サイト" を表します。Web テーブルには、サイト コレクション内の各サイトに適用される設定が含まれます。

ドキュメント テーブルには、データベースによって表されるサイト コレクションのサイト全体のすべてのドキュメントが格納されます。これには、ドキュメント ライブラリのドキュメント、添付ファイル、および各リストのノード、またページがカスタマイズされている場合には default.aspx と各リストのユーザー ページなどが含まれます。ページがカスタマイズされていない場合は、ドキュメント テーブルのコンテンツ列に null が含まれます。初めてサイトが作成されたときは、ページがまだカスタマイズされていないため、すべてのサイト ページに対してテーブルのコンテンツ列に null が含まれます。ページ定義は、フロントエンド Web サーバーに物理的に存在するスキーマ ファイルから取り出されます。

リスト テーブル (またはリスト テーブルのリスト) には、データベース内のすべてのサイトの各リストに対する行が含まれます。このテーブルには各リストの設定が含まれ、サイトに含まれるリストまたはドキュメント ライブラリ、および各リストによりインスタンス化されるスキーマを指定します。ユーザー データ テーブルには、サイト内のユーザーが作成したアイテムのすべてのリスト データが含まれます。各行には各アイテムのデータが含まれます。

リンク テーブルには、リンクを再計算するリンク修正に使用されるリンクが含まれ、リンク管理が大幅に簡略化されました。以前のバージョンでは、各ドキュメントの背後のファイル システム内でシャドウ ファイルを作成する必要があり、ドキュメントからのリンクとドキュメントをポイントするリンクのすべてが含まれていました。

Web パーツ テーブルには、サイト内で使用されるすべての Web パーツとリスト ビューに関する情報が含まれます。以前使われていたユーザー ページの CAML ビューが Web パーツに置き換わったように、前のバージョンのビュー テーブルは Web パーツ テーブルに置き換わりました。tp_View 列には、カスタマイズされていないビューの null を除く変更されたビューの CAML が含まれます。 Web パーツの個人用の設定情報は、個人用の設定テーブルで管理されます。

SharePoint Portal Server 2003 に関する注意点: SharePoint Portal Server コンテンツ データベースは Windows SharePoint Services データベースのスーパーセットで、テーブルやストアド プロシージャが追加されています。SharePoint Portal Server はテーブル内で外部キー リレーションシップを使い、Windows SharePoint Services のデータベース スキーマを変えることなく 2 つのデータベースを追加します。プロファイル データベースには、Web パーツとコンテンツの対象となる個人のプロファイルやユーザーの定義などが保存されます。またサービス データベースでは、検索やインデックス作成だけでなく、Web 購読と Web 購読の結果をサポートしています。

まとめ

Windows SharePoint Services アーキテクチャは、以前のバージョンである SharePoint Team Services のアーキテクチャに修正を加え、課題となっていたスケーラビリティとパフォーマンスの向上を実現しました。Windows SharePoint Services は .NET Framework を独自の機能に統合して、Web 開発プラットフォームとしての拡張性と多様性を図りました。さらに、データベース スキーマを大幅に変更したことにより、SQL Server 機能を活用しやすくなりました。Windows SharePoint Services のデータベースの変更により、SharePoint Team Services に比べて、SharePoint アーキテクチャにおいて IIS が果たす役割が縮小されました。このアーキテクチャを理解すると、Windows SharePoint Services プラットフォーム上でどのようにカスタム アプリケーションを開発すべきかを判断するのに役立ちます。


この情報は役に立ちましたか。
(残り 1500 文字)