システム間連携のアーキテクチャ、4つの基本パターンと正しい適用のポイント：徹底解説！ ITアーキテクトとは何か？（4）（1/2 ページ）

ITアーキテクトの役割を、具体的かつ分かりやすく解説する本連載。今回は一連の業務処理遂行のために、複数のシステムを連携させ機能を組み合わせていく「システム間連携」の処理方式を徹底解説する。

[熊谷宏樹，TIS株式会社]

あらゆる業務プロセスに最適なシステム間連携を設計するためには？

　前回は大量データをスムーズに処理するためのバッチ処理のアーキテクチャ設計を解説しました。今回はシステム間連携のアーキテクチャを紹介します。

　ビジネス上の要求を達成するために、複数のシステムを連携させ機能を組み合わせていくことで業務処理を遂行していくことは少なくありません。このような「システム間連携」の処理方式はさまざまですが、ここでは次の4つの基本パターンに分類します。

1. リソース共有（データベース共有、ディスク共有）
2. アプリケーション連携（RPC、Webサービスなど）
3. ファイル連携
4. メッセージング

　なお、実際のシステムでは、これら基本パターンのいずれか一つで連携させることもあれば、複数のパターンを組み合わせて連携させることもあります。以下では、これらの基本的な連携方式について、その概要と留意すべきポイントについて解説します。

パターン1. リソース共有（データベース共有、ディスク共有）

　連携するシステムが同一のデータベース（以下、DB）にアクセスできるアーキテクチャである場合は、データの整合性が取れた形で、相互に処理結果を連携させることができます。

　当然ながら、各システムにはDBへの物理的なアクセスが行える環境が必要です。DBMSによっては、リモートのDBサーバーにあるテーブルをあたかもローカルのDBサーバー上にあるかのように見せる「データベースリンク」機能を提供しています。これを利用することで、分散DBを共有したシステム間連携を実現することができます。

　「データベースリンク」機能は製品によって名称や仕様に差異があるため、利用に際しては、製品ごとの特徴や制約事項を事前に調査しておきましょう。

DBMS名	機能名
Oracle	データベースリンク
SQLServer	リンクサーバー
DB2	連合データベース
MySQL	FEDERATED
PostgreSQL	dblink／Foreign Data Wrapper (9.1以降)

パターン2. アプリケーション連携（RPC、Webサービスなど）

　システムに外部から呼び出すことのできる「インターフェース」を用意します。連携する側は公開されているインターフェースを利用して、システムが蓄えているデータへのアクセス（CRUD）や、ビジネス機能の呼び出しを行います。この方式は、RPC（Remote Procedure Call）やCORBA（Common Object Request Broker Architecture）などにより実装されます（Webサービスもこの一種と捉えることもできますが、後ほど取り上げます）。

　この方式では連携元と連携先をリアルタイムに同期処理をさせることが特徴です。連携先での処理結果を確実に連携元が受け取り、結果に応じて後続処理を行うことが可能です（CORBAのように、非同期処理をサポートしているものもあります）。同期処理では呼び出し先の処理が長時間に及ぶような場合、呼び出し元も待たされることになるので、「レスポンス要件上問題がないか？」について留意する必要があります。

ポイント

呼び出しに失敗した場合、フレームワークのレイヤーでリトライする必要がないか、処理方式を設計する上で検討しましょう。

Webサービス

　Webサービスは、通信プロトコルにSOAPを用い、XML形式のメッセージを送受信することでアプリケーションが相互に連携する技術です。

　SOAPはHTTPベースであるため、インターネット経由でもメッセージのやり取りが容易に行えることが特徴です。そのため、社内システム間の連携だけでなく、企業間のシステム間連携にもよく利用されます。

　Webサービスの実装フレームワークはJava EE準拠のアプリケーションサーバーや.NET Frameworkなど多くのプラットフォームに含まれており、これらを利用することでWebサービスを比較的容易に開発することができます。

　Webサービスでは、同期処理と非同期処理の両方がサポートされており、サービスによってどちらの方式が適切かを判断する必要があります。連携先の処理が長時間に及ぶような場合、連携元がレスポンス待ちにならないように非同期処理を用いるのが一般的です。非同期処理では処理結果が連携元には通知されないため、連携元が連携先の処理結果を知る必要がある場合は、次のいずれかの方法を用いた仕組みを用意します。

1.コールバック方式：コールバック用Webサービスを連携元に用意し、連携先で処理が終了すると、このコールバック用サービスを利用して処理結果を連携先から連携元に通知します。この方式を採るためには、連携元もWebサービスのサーバー側として機能する必要があります。

図1　Webサービスにおけるコールバック方式

2.ポーリング方式：連携先に、処理を依頼するためのサービスと、処理結果を確認するためのサービスを設けます。初めに処理依頼用サービスを連携元から呼び出し、次に任意のタイミングで、連携元から処理結果確認用サービスを呼び出して結果を取得します。処理結果確認を呼び出したときに、必ずしも処理が終了している保証はないため、結果取得が成功するまで結果確認を繰り返し呼び出す必要があります。

図2　Webサービスにおけるポーリング方式

　大量のデータ転送が伴うような連携にWebサービスを用いる場合、注意が必要です。XMLはデータをタグでマークアップするため、データ量に比例してメッセージサイズが巨大になり、送信時のオーバーヘッドがかかります。このような場合は、例えばデータのURLだけをWebサービスでやりとりし、実際のデータの授受はURLを手掛かりにFTPやHTTPを用いてファイル転送を行うような方式を採用するケースもあります。

REST

　REST (REpresentational State Transfer) は Webにおけるアーキテクチャスタイルの一つであり、URIで識別されたリソースをHTTPのメソッド(GET／POST／PUT／DELETE) を用いて操作する手法です。

　システム間連携では、SOAPをベースとしたWebサービスの代替として、RESTが用いられる場面が増えてきました。厳密なREST の定義にのっとったものでなくとも、HTTPリクエストに対してXML形式のレスポンスを返す場合もRESTと捉えられることが一般的です。また最近ではXML形式ではなく、よりシンプルな表現形式であるJSON（JavaScript Object Notation）形式が使用されるケースも増えています。

　RESTを使った場合、Webブラウザー上でアドレスとしてリソースのURIを指定するとサーバー側のレスポンスをすぐに確認することができます。手法自体がシンプルであるため学習コストが低く、初めて開発する人にとってはSOAPより手軽に始められます。ただし、本番運用においては、サービスの内容を吟味し、実行権限の設定を適切に行うなど、セキュリティ面の考慮も必要となります。

　構造化された複雑なデータを入力として渡したい場合や、受け渡しするデータの型チェックを厳密に行いたいような場合にはRESTは不向きです。このような場合はSOAPを用いるべきでしょう。