連載 アプリケーション・アーキテクチャ・ガイド2.0解説 第6回 典型的なアプリケーションのパターン（後編） 日本ユニシス　猪股 健太郎 2009/12/15
Page1 Page2 Page3 Page4

■SharePoint業務アプリケーション

　SharePoint業務アプリケーションは、MOSSやWSSを利用して構築する、ロールベースのWebアプリケーション・ポータルである。

　アプリケーションの論理階層構造は、先ほど説明したOBAと同様、プレゼンテーション層、生産性向上支援層、アプリケーション・サービス層の3つからなる。このアプリケーション・パターンでは、プレゼンテーション層がSharePointポータルとなっている。

　SharePointポータルは、IISをWebサーバとして使ったWebアプリケーションとして動作する。ポータルには複数のサイトを作成することができる。

　サイトは複数のページを含み、各ページは複数のWebパーツを含むことができる。最初から用意されているWebパーツを使うだけでなく、アプリケーション独自の機能を提供するカスタムWebパーツを開発してページに組み込むこともできる。

　なお、プレゼンテーション層と生産性向上支援層の機能はMOSSとWSSのどちらでも提供できるが、アプリケーション・サービス層の機能はMOSSだけに含まれている。

SharePoint業務アプリケーションの構造

　SharePoint業務アプリケーションのアーキテクチャ・フレームとして、AAGでは下記のものを取り上げ、検討すべきガイドラインを提示している。ここでは、その中から「ドキュメントとコンテンツのストレージ」「Webパーツ」「ワークフロー」「SharePointオブジェクト・モデル」の4つを説明しよう。

SharePoint業務アプリケーションの アーキテクチャ・フレーム

ドキュメントとコンテンツのストレージ

Webパーツ

ワークフロー

ビジネス・データ・カタログ

SharePointオブジェクト・モデル

InfoPathフォーム・サービス

Excelサービス

配置

●ドキュメントとコンテンツのストレージ

　Office文書はSharePointのドキュメント・ライブラリに格納できる。また、Officeアプリケーションを使うと、複数のストレージに格納されているコンテンツを連結して扱うこともできる。

注意点：

• ドキュメント・ライブラリに文書を格納する場合は、コンテンツ・タイプとして適切なメタデータを設定しておく
• コンテンツ・タイプをどのように管理するかの方針を定めておく。サイト全体で共有することもできるし、特定のリストだけで利用することもできる
• コンテンツ・タイプの継承を活用する。ポータルのルートで定義したコンテンツ・タイプは、子のサイトでも利用できる。また、既存のコンテンツ・タイプを拡張した新しいコンテンツ・タイプを定義することもできる
• ドキュメント情報パネルをカスタマイズし、文書を追跡できるようにしておく
• ユーザーが構成可能な情報や、一時的でない情報は、リストに保存する
• あるリストを何度も表示する場合は、検索結果をDataTable（データテーブル）などにキャッシュしておく
• データベースには、一時的な情報や、トランザクション処理を行う情報を保存する
• SharePointのドキュメント・ライブラリを乱用しない。ドキュメント・ライブラリには、共同作業や適切な管理が必要な文書だけを登録する
• SharePointのドキュメント・ライブラリでソース・コードを管理しない
• リストには2000項目までしか含めることができない。それ以上の項目を扱う場合は独自のUIを作成する
• フィルタを適用したビューではなく、別のフォルダにドキュメントを格納した方が、高速に取得できる

●Webパーツ

　Webパーツを組み合わせることで、プレゼンテーション層を自由に変更できる。アプリケーション独自の機能を実装したカスタムWebパーツを作ることもできるし、SharePointやASP.NETが提供するWebパーツを使うこともできる。

　Webパーツを開発する際は以下の点に注意する。

注意点：

• Webパーツとして実装するのにふさわしい機能を選択する
• Webパーツが利用するデータソースを特定する
• 保守性を高めるため、Webパーツをプレゼンテーション層、ビジネス層、データ・アクセス層の3つの論理階層に分割して設計する
• 再利用性を高めるため、Webパーツは単機能とする
• Webパーツはユーザーが構成したりカスタマイズしたりできるように設計する
• マスター・ページをカスタマイズする時は、マスター・ページにWebパーツ・マネージャを追加しておく
• Webパーツを組み込むページにはWebパーツ・ゾーンを追加しておく
• ユーザーがWebパーツを個別に操作できるように、Webパーツ動詞を利用する
• Webパーツに含まれるコントロールに直接スタイルを設定しない
• Webパーツに共通のプロパティとカスタムWebパーツ独自のプロパティとを区別するために、プロパティをカテゴリ分けしておく
• Webパーツ内で作成したSharePointオブジェクトやアンマネージ・リソースは適切に破棄する

●ワークフロー

　SharePointには、ドキュメント・ライブラリと組み合わせられるシンプルなワークフローが付属している。SharePointデザイナやVisual Studioを使うことで、カスタム・ワークフローを作成することもできる。

注意点：

• どのビジネス・プロセスが自動化されているのかを確認しておく
• 既存のワークフローを電子化する前に、そのワークフローが正しく、かつ適切に文書化されていることを確認しておく
• 業務要件を満たす適切なワークフロー技術を選択する
• 業務要件が単純であれば、組み込みのワークフローを選択する
• 組み込みのワークフローで業務要件を満たせないのであれば、SharePointデザイナを使用する
• 業務要件が非常に複雑だったり、既存業務システムとの連携が必要だったりする場合は、Visual Studioでカスタム・ワークフローを開発する
• Visual Studioでカスタム・ワークフローを開発する場合は、開発者でなくても使えるように、SharePointデザイナに登録できるようにする
• カスタム・ワークフローのデバッグ時には、ログ出力レベルを「Verbose」にする
• カスタム・ワークフローのデバッグを容易にするため、実行状況を外部から計測できるようにしておく
• ワークフロー・アセンブリのバージョンを適切に管理し、アセンブリのバージョンを上げる場合はGUIDも変更する
• ワークフローを入れ替える前に、既存ワークフローへの影響を確認しておく
• 利用者が作成したワークフローの履歴やタスク・リストは独立して管理する
• 保守性を高めるため、ワークフローはコンテンツ・タイプと対応付ける
• リストのアイテムに対して、同じワークフローは1つしか動作させられないことに注意する
• ワークフローはリストに対して開始させるものではなく、リストのアイテムに対して開始させるものであることに注意する

関連するパターン：

• シーケンシャル・ワークフロー
• ステートマシン・ワークフロー
• Human Workflow（英語）

●SharePointオブジェクト・モデル

　SharePointは、プロセスの自動化に対応したオブジェクト・モデルを公開している。それを使うことで、文書のバージョン管理をカスタマイズしたり、チェックイン・ポリシーをカスタマイズしたりすることもできる。

注意点：

• アンマネージ・リソースを解放するため、SharePointオブジェクトを使い終わったらDisposeメソッドを呼び出して正しく破棄する
• 例外ハンドラで適切にSharePointオブジェクトを破棄する
• SharePointオブジェクトをキャッシュする場合は、スレッドの同期およびスレッドセーフを心がける
• SharePointオブジェクトのデータをキャッシュする場合は、DataTable（データテーブル）を利用する
• 権限を昇格させるときには、権限昇格後に生成されたSharePointオブジェクトだけが、昇格した権限を利用するように注意する

■

　最後に、SharePoint業務アプリケーションの構築に利用できる実装テクノロジを表にまとめる。

テクノロジ	利用シナリオ
Windows Workflow（WF）	カスタム・ワークフローを取り入れたアプリケーションを構築する場合
Microsoft BizTalk Server	ワークフローにおいて、複雑なシステム連携や、信頼性の高いメッセージングが必要となる場合
マイクロソフトESBガイダンス	マイクロソフト以外の製品で構築されたシステムと連携してEDIを実現したい場合や、エンタープライズ・サービス・バス（ESB）パターンを実現したい場合
Microsoft Office SharePoint Server（MOSS）	アプリケーションのビジネス層が単一のSharePointサイトにからしか利用されず、ほかのサイトの情報にアクセスする必要がない場合
System.Web.UI.WebControls.WebParts.WebPartクラス	カスタムWebパーツを開発する場合で、SharePoint 2003との互換性が不要な場合
Microsoft.SharePoint.WebPartPages.WebPartクラス	カスタムWebパーツを開発する場合で、SharePoint 2003との互換性が必要な場合
SharePoint業務アプリケーションの構築に利用できる実装テクノロジ

■

　以上で、本連載が開始した2009年3月時点におけるAAGの内容を一通り紹介し終わった。

　しかし、前回の連載の冒頭でお伝えしたように、AAGは3月時点の内容からさらに加筆され、2009年10月にMSDNに正式公開された。よって次回は、正式公開されたAAGの概要や、本連載記事からの変更点、そして新規に追加されたクラウド・サービスの設計について紹介することで、連載の最終回とさせていただきたい。

INDEX
	連載：アプリケーション・アーキテクチャ・ガイド2.0解説
	第6回 典型的なアプリケーションのパターン（後編）
	1．サービス
	2．モバイル･アプリケーション
	3．OBA
	4．SharePoint業務アプリケーション

「アプリケーション・アーキテクチャ・ガイド2.0解説」

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）