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

Page1 Page2 Page3 Page4

　前回に続いて今回も、アプリケーション種別ごとにパターンやベストプラクティス、そして実装テクノロジを重視しながら、アーキテクチャ設計を説明していく。今回は「サービス」「モバイル･アプリケーション」「OBA」「SharePoint業務アプリケーション」について説明する。

■サービス

　サービスは、あるひとまとまりの機能にアクセスするためのインターフェイスである。多くの場合、サービスは分散配置されている。サービスの提供者と利用者はインターフェイス定義に従ってメッセージを交換することで、疎結合が実現される。標準化されたインターフェイス定義やメッセージを採用することで、相互運用性が高まり、異機種混在環境が実現される。

　典型的な例では、サービスはプレゼンテーション層を含まない。その代わり、外部システムとの境界にサービス層を置き、ビジネス層やデータ・アクセス層で扱われるデータと、外部システムと交換するメッセージとの相互変換を行う。

サービスの典型的な構造

　最初に、サービスの設計における一般的な注意点を説明する。

• サービスの粒度が細かすぎるとパフォーマンスが出ないため、ある程度大きな粒度で設計する。粒度の細かな機能を1つのサービスにまとめるときにはファサード・パターンが適用できる
• メッセージに含めるデータは拡張性を持たせる。サービス利用者に影響を与えずに拡張できるとよい
• メッセージに含めるデータには標準的な型を使う。新しい型を作る場合は標準的な型を組み合わせる
• サービス利用者にも、サービスの使われ方にも前提を置かずに設計する
• サービス契約だけに基づいて設計する。サービス契約に基づかない機能を外部に公開しない
• 不正なリクエストが届く可能性を念頭において設計する
• 拡張性や保守性のために、ビジネス上の関心事とインフラ運用上の関心事を分ける
• 再送されたメッセージを判別し、適切に処理する（べき等性を持たせる）
• 順序の入れ替わったメッセージを適切に処理する。順序が入れ替わる可能性がある場合は、メッセージを格納したうえで、正しい順序で処理する

　サービスは、複数の独立したシステムを連携させ、全体として大きなビジネス・プロセスを構成するために利用されることもある。そのようなシステム・アーキテクチャを「サービス指向アーキテクチャ（SOA）」と呼ぶ。SOAを実現する場合は、併せて下記の点にも注意する。

• サービスの粒度はアプリケーション単位とし、やり取りするデータの粒度も大きくする
• インターフェイスと実装を分離する。サービス内部のビジネス・エンティティを外部に公開してはならない
• 明確な境界を持ったサービスを設計する。サービスへのアクセスは必ずサービス・インターフェイスを経由する
• 自律的なサービスとする。どのようなクライアントであっても正しく動作するようにする
• ポリシーに基づいた互換性を実現する。サービスのポリシーを公開し、ポリシーに合致したサービス呼び出しを正しく受け入れる

　サービスのアーキテクチャ・フレームとして、AAG（アプリケーション・アーキテクチャ・ガイド2.0）では下記の事項を取り上げ、検討すべきガイドラインを提示している。ここでは、その中から「メッセージ作成」「メッセージ・エンドポイント」「メッセージ保護」「メッセージ変換」「SOAP」「REST」の6つを説明しよう。

サービスのアーキテクチャ・フレーム

認証

承認

通信

データの一貫性

例外管理

メッセージ作成

メッセージ・エンドポイント

メッセージ保護

メッセージ変換

SOAP

REST

入力値検証

サービス層

ビジネス層

データ・アクセス層

パフォーマンス

セキュリティ

配置

●メッセージ作成

　サービス提供者とサービス利用者の間でデータを交換するとき、データはメッセージという形にラップされていなければならない。ただし、サービスの種類に応じてメッセージの形式は異なる。

注意点：

• 適切なメッセージ種別を選択する。例えば、命令型、ドキュメント交換型、イベント型、要求と応答型など
• 巨大なデータは分割し、連番などを振って送信する
• 日時や時刻に依存するメッセージには情報の有効期限も含める。有効期限の切れたメッセージを受け取った場合は無視する

関連するパターン：

• Command Message（英語）
• Document Message（英語）
• Event Message（英語）
• Request-Reply（英語）
• Message Expiration（英語）

●メッセージ・エンドポイント

　メッセージ・エンドポイントはサービスと通信するためのアクセス・ポイントである。サービス・インターフェイスはメッセージ・エンドポイントも含んでいる。メッセージ・エンドポイントは以下の注意点に従う。

注意点：

• 適切なパターンを選択する。例えば、書籍「エンタープライズ統合パターン」（Enterprise Integration Patterns、洋書、ISBN: 978-0-32120-068-6）で取り上げられているゲートウェイ（Messaging Gateway）、マッパー（Messaging Mapper）、競合する利用者（Competing Consumers）、メッセージ・ディスパッチャ（Message Dispatcher）など
• すべてのメッセージを受け取るのか、特定のメッセージのみ受け取るフィルタを実装するのかを選択する
• べき等性を取り入れる。べき等性を取り入れたエンドポイントは、重複したメッセージを無視し、メッセージがただ一度だけ処理されることを保証する
• 交換可能性を取り入れる。交換可能性を取り入れたエンドポイントは、順序が入れ替わったメッセージを格納し、正しい順序で処理する
• ネットワークが使用できないとか、接続が切れるといった通信の失敗が起きるシナリオに備える。例えばメッセージの到達を保証するような高信頼性メッセージング技術をサポートするなど

関連するパターン：

• Messaging Gateway（英語）
• Messaging Mapper（英語）
• Transactional Client（英語）
• Polling Consumer（英語）
• Event-Driven Consumer（英語）
• Competing Consumers（英語）
• Message Dispatcher（英語）
• Selective Consumer（英語）
• Durable Subscriber（英語）
• Idempotent Receiver（英語）
• Service Activator（英語）

●メッセージ保護

　サービス提供者とサービス利用者の間で重要なデータを送受信する場合、メッセージの保護について検討するべきである。

　トランスポート層で保護することもできるし、メッセージ自体を保護することもできる。後者であれば、メッセージの一部分を暗号化し、デジタル署名を使って改ざんを防止するなども可能である。

注意点：

• メッセージが中継サーバを経由しないのであれば、SSLのようなトランスポート層のセキュリティ機構を検討する
• メッセージが中継サーバを経由する場合にトランスポート層のセキュリティ機構を選択してしまうと、メッセージは各サーバで復号化されて再度暗号化されてしまう。それを防ぐためにはメッセージ自体を保護する
• メッセージに秘匿性の高いデータが含まれる場合は暗号化する
• メッセージやパラメータの改ざんを防ぎたい場合はデジタル署名を使う

関連するパターン：

• Data Confidentiality（英語）
• Data Origin Authentication（英語）
• Exception Shielding（英語）
• Message Protection Patterns（英語）
• フェデレーション

●メッセージ変換

　サービス提供者とサービス利用者の間でメッセージをやり取りする際、メッセージを利用者が理解できる形式に変換しなければならない場合がある。

　例えば、メッセージ・ベースでない利用者がメッセージ・ベースのサービスと通信するような場合だ。こういう場合は、メッセージを利用者が理解できる形式に変換するアダプタを用意する。

注意点：

• 適切なメッセージ変換パターンを選択する。例えば、正規化（Normalizer）パターンは、形式が異なるだけで同じ意味を表すメッセージを統一された形式に変換するのに使われる
• メッセージ形式を定義するメタデータを使用する
• メタデータを格納する外部リポジトリを検討する

関連するパターン：

• Envelope Wrapper（英語）
• Content Enricher（英語）
• Content Filter（英語）
• Claim Check（英語）
• Normalizer（英語）
• Canonical Data Model（英語）

●SOAP

　SOAPはメッセージ・ベースのプロトコルであり、SOAPメッセージはヘッダとボディからなるXMLエンベロープで表現される。ヘッダ部はセキュリティやトランザクションなど、サービスについての付加的な情報を含む。ボディ部はインターフェイス契約に基づいたサービス名や送受信データを含む。SOAPはトランスポート・プロトコルに依存しない仕様だが、ほとんどの場合においてHTTP／HTTPSが用いられている。

　SOAPを用いたWebサービスは、W3CやOASISなどの標準化団体によって標準化されたさまざまなWebサービス技術（まとめて「WS-*」と表記される）と組み合わせることができる。WS-*には、セキュリティやトランザクション、高信頼性メッセージといった技術が含まれる。技術が標準化されているため相互運用性が高く、さまざまなプラットフォームがSOAPを用いたWebサービスに対応している。また、SOAPを用いたWebサービスは、1つのメッセージが複数のシステムを経由して配送されるようなシナリオにも対応することができる。

注意点：

• サービスをスケールアウトさせたい場合は、セッション情報をサーバ上に持たせず、ステートレスに設計する
• SOAPヘッダはオプション扱いである。必須情報はSOAPボディに含める
• エラーを通知する際はSOAP Faultを使う
• SOAP FaultはSOAPボディの唯一の子要素にしなければならない
• SOAPヘッダを処理する際のエラーもSOAP Faultとして返す
• 必ず処理されなければならないSOAPヘッダ要素は、mustUnderstand属性をtrueまたは1にする
• WS-*標準を検証し、活用する。これらの標準には、メッセージ・ベースのアーキテクチャによくある問題を扱うための、一貫したルールと方法が示されている

関連するパターン：

• サービス・コントラクト
• データ・コントラクト
• エラー・コントラクト

●REST

　REST（REpresentational State Transfer）とは、リソース（＝システムが管理する情報のひとまとまり）と、それに対応付けられたURIを重視するアーキテクチャ・スタイルである。リソースをURIで特定し、そのリソースの現在の状態を表現する情報（Representational State）をサーバとクライアントの間で転送（Transfer）するので、RESTという名前がついている。

　RESTは、WebおよびHTTPを本来の設計思想に基づいて利用しようとするアーキテクチャ・スタイルだといわれることもある。HTML文書やそれに付随するコンテンツを対象にするだけでなく、より抽象化した「リソース」を扱う仕組みとしてURLとHTTPを活用しようとするためである。

　RESTの詳細は本記事の範囲を超えるため割愛する。詳しく知りたい方は、書籍「RESTful Webサービス」 （オライリー・ジャパン、ISBN 978-4-87311-353-1）や、山本陽平氏のブログ記事「REST入門」を参照してほしい。

　RESTを用いたWebサービスとSOAPを用いたWebサービスを比較した場合のRESTの利点の1つは、サービス利用者がSOAPやWSDLやWS-*といった複雑な仕様に対応する必要がなく、単にHTTPクライアントであればよいことだ。

　SOAPを用いたWebサービスでは、サービスごとにインターフェイス契約が異なり、WSDLが異なる。サービス利用者はWSDLごとにプロキシを用意しないといけない。C#やVisual Basicであればプロキシ・クラスをツールで生成することができるが、コード自体は必要である。

　ところが、RESTの場合のインターフェイス契約は「HTTPに従うこと」だけである。どのようなサービスであろうと、リソースのURLさえ分かっていればサービスを利用できる。このような性質は特にJavaScriptからWebサービスを利用するのに都合がよいため、AJAXを採用したシステムではSOAPよりもRESTが好まれる。

注意点：

• RESTサービスに対応するリソースを決定するときには状態遷移図を活用する
• リソースを一意に特定する方法を設計する。なるべく、リソースに意味のある名前を付けるのがよい
• リソースを表現する際、複数のフォーマットに対応するかどうかを決定する。Atom、JSON、単なるXMLなどがよく用いられる。例えば、「http://www.example.org/example.atom」はAtom形式を、「http://www.example.org/example.json」はJSON形式を表すようにするなど
• リソースに対する操作をクエリ文字列で表現しない。例えば、「http://example.org/?action=insert」などとしてはいけない。リソースに対する操作は標準的なHTTPメソッド（GET／POST／PUT／DELETEなど）で表現する
• POSTメソッドを乱用しない。PUTやDELETEメソッドを活用することを検討する
• HTTPを活用し、すでに整備されたWebのインフラを使う。キャッシュや認証やETagなどといった機構を使うことができる
• GETリクエストは安全に処理する。すなわち、リソースが更新されない限り、同じリクエストには同じ結果を返す。また、PUTやDELETEリクエストに対して、べき等性を持たせる

■

　サービスのまとめとして、サービスの構築に利用できる実装テクノロジを表にまとめる。

テクノロジ	利用シナリオ
ASP.NET Webサービス	シンプルなWebサービスを構築する場合
Windows Communication Foundation （WCF）	さまざまな機能を活用したサービスを構築する場合や、相互運用性の高いWebサービスを構築する場合
Web Service Extensions（WSE）	ASP.NET Webサービスにおいて、メッセージ・ベース・セキュリティやバイナリ・データ転送を取り入れたい場合
SOAP／HTTP	WCFにおいて、さまざまなクライアントとの相互運用性が必要な場合
バイナリ・フォーマット／TCP	WCFにおいて、サーバとクライアントがイントラネット内にあり、Windows認証やトランスポート・セキュリティを取り入れたい場合
バイナリ・フォーマット／名前付きパイプ	WCFにおいて、サーバとクライアントが同じマシンに置かれる場合
サービスの構築に利用できる実装テクノロジ

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

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

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