特集開発現場からの提言（後編）SOAの導入を成功させる現実的な方法とは？有限会社アークウェイ 黒石 高広2005/12/03 |
|
|
|
|
3. メッセージ・バスによるSOAシステムの構築方法
メッセージ・バスを簡単に説明すると
「非同期を前提としたアプリケーション間連携の標準フレームワーク」
である。次の図にメッセージ・バスのイメージ図を示す。
 |
| メッセージ・バスのイメージ図 |
メッセージ・バスでは、アプリケーションは「サービス・エージェント」と呼ばれる論理的なコンポーネントを通じてメッセージの送受信を行う。イメージ図だけ見るとメッセージ・ブローカと同じようにも見えるが、メッセージ・ブローカと違いアプリケーション間に仲介役のサーバは設けないという特徴がある。
別のいい方をすると、メッセージ・バスはサービス・エージェント間のメッセージのやりとりを標準化したフレームワークともいえる。このようにサービス・エージェントを通じてメッセージのやりとりを行う分散管理のアーキテクチャとなっているため、メッセージ・ブローカのように単一障害点が生まれないというメリットもある。
では、このメッセージ・バスはどのように実現できるだろうか？ 以下では、メッセージ・バスに必要な特性と実現方法について解説する。
■標準技術の採用と複数プラットフォームへの対応
企業内のアプリケーションは、複数のプラットフォームが存在するという前提があるため、メッセージ・バスの実現にはOSや開発環境に依存しない標準技術の採用が必要となる。
そこで登場する技術が、.NETやJavaなどの主要プラットフォームでのサポートが進んでいるWebサービスである。Webサービスを利用することで、異なるプラットフォーム間でもメッセージの送受信が容易となる。
 |
| 複数のプラットフォームへの対応策としてのWebサービスの活用 |
| Webサービスを利用することで、異なるプラットフォーム間でもメッセージの送受信が容易となる。 |
また複数のプラットフォームへの対応という意味では、Webサービスを呼び出すためのサービス・エージェントをプラットフォームに応じて提供する必要がある。
.NET用サービス・エージェント、Java用サービス・エージェントのように各プラットフォームに対応するサービス・エージェントを構築し、アプリケーションから利用することで複数のプラットフォーム上から呼び出し可能なメッセージ・バスを構築することができる。
マイクロソフトでの代表的なWebサービス技術にはASP.NET Webサービスがある。単純にメッセージを受け渡すだけのWebサービスであれば、通常のASP.NET Webサービスで問題ない。WebサービスにKerberos認証やメッセージの暗号化などのより高いセキュリティが求められる場合は、Webサービスの拡張技術であるWeb Service Enhancements（WSE）を利用し、WS-Securityなどのより高度なセキュリティ機能を利用できる。
■非同期連携と信頼性の高いメッセージングの実現
非同期連携を実現するためにメッセージ・バスを構築しようとしているので、当然、非同期でWebサービスを利用する仕組みを構築する必要がある。
.NETのWebサービスで用いられるプロキシ・クラスには、Webサービスの呼び出し処理を別スレッド上で行い、呼び出し側のアプリケーションは並列に別の処理を実行できるWebサービスの非同期呼び出し機能がある。しかし、これはあくまでメモリ上の別スレッドで呼び出し処理を行うだけなので、高い信頼性が求められるアプリケーション間連携で使用するには十分でない。
非同期連携と信頼性の高いメッセージングを実現するために、サービス・エージェントの機能として、Webサービスを呼び出す前に一度データベースへメッセージ情報を書き込み、Webサービスの呼び出しに失敗した場合は、自動的にリトライ処理などを行う機能が必要となる。
サービス・エージェントの内部処理の概略を下記図にまとめる。
 |
| 非同期連携と信頼性の高いメッセージング |
この図のように、サービス・エージェントが呼び出されると、一度メッセージをデータベースへ永続化し、別プロセスから非同期でデータベースからメッセージを読み取り、Webサービスへ送信する。
メッセージの送信に失敗した場合は、データベースへ送信ステータスを書き込み、一定時間後にメッセージをリトライ送信するようにする。このようにサービス・エージェントを構築することで、非同期での信頼性の高いメッセージングを実現できる。
信頼性の高いメッセージングを実現するために、ここではデータベースをベースにした非同期連携の方法を提案したが、マイクロソフト技術に詳しい方は、非同期連携と聞くとMicrosoft Message Queuing（MSMQ）やSQL Server 2005 Service Brokerを思い浮かべるかもしれない。メッセージ・バスは複数プラットフォームへの対応が前提となるため、非同期での信頼性の高いメッセージングにどの技術を利用するかは、複数プラットフォームへの対応や開発の容易さなどから慎重に判断していただきたい。
■粒度の大きなWebサービスの必要性
メッセージ・バスで利用するWebサービスは、粒度の大きいWebサービスとしてインターフェイスを設計する必要がある。
これは、メッセージ・バスがあらゆる種類のメッセージを通す必要があるため、特定のメッセージ・スキーマに依存したインターフェイスでWebサービスを設計すると、メッセージの種類の数だけWebサービスを用意する必要が生じるからである。
 |
| 粒度の大きなWebサービスと粒度の小さなWebサービス |
| メッセージ・バスで利用するWebサービスは、粒度の大きいWebサービスとしてインターフェイスを設計する必要がある。 |
粒度の大きなWebサービスは、XSD（XMLスキーマ定義言語：XML Schema Definition Language）の<any>要素を利用してインターフェイスを定義することで実現できる。
粒度の小さなWebサービスでは、単純に引数リストで定義されたWebサービスであるため、メッセージの種類ごとにWebサービスを用意する必要があるといった問題や、Webサービスのインターフェイスに変更が発生した場合、呼び出し側のプロキシ・クラスも更新する必要が生じるといった問題がある。
ただし粒度の大きなWebサービスを利用する場合、Webサービスのインターフェイスのレベルでメッセージ・スキーマの検証を行うことができなくなるため、Webサービスを呼び出すサービス・エージェントやWebサービスの内部で、メッセージのスキーマ検証を行うためのスキーマ管理の機能やメッセージ・スキーマの違いを吸収するためのスキーマ変換の機能が必要となる。
 |
 |
| INDEX | ||
| [特集] | ||
| 開発現場からの提言（前編） | ||
| サービス指向アーキテクチャ（SOA）の実際 | ||
| 1．なぜいまSOAが求められているのか？ | ||
| 2．「SOA＝Webサービス」だけではうまくいかない | ||
| 開発現場からの提言（後編） | ||
| SOAの導入を成功させる現実的な方法とは？ | ||
| 1．アプリケーション間連携の現状（AS-IS）とあるべき姿（TO-BE） | ||
 |
2．メッセージ・バスによるSOAシステムの構築方法 | |
| 3．メッセージ・バスだけでは難しい問題 | ||
 |
||
- 第2回 簡潔なコーディングのために （2017/7/26）
ラムダ式で記述できるメンバの増加、throw式、out変数、タプルなど、C# 7には以前よりもコードを簡潔に記述できるような機能が導入されている - 第1回 Visual Studio Codeデバッグの基礎知識 （2017/7/21）
Node.jsプログラムをデバッグしながら、Visual Studio Codeに統合されているデバッグ機能の基本の「キ」をマスターしよう - 第1回 明瞭なコーディングのために （2017/7/19）
C# 7で追加された新機能の中から、「数値リテラル構文の改善」と「ローカル関数」を紹介する。これらは分かりやすいコードを記述するのに使える - Presentation Translator （2017/7/18）
Presentation TranslatorはPowerPoint用のアドイン。プレゼンテーション時の字幕の付加や、多言語での質疑応答、スライドの翻訳を行える
 |
|
|
|
|
