システム間連携技術の基礎,,, ,http://itpro.nikkeibp.co.jp/article/lecture/20061215/257067/,, ,,, ,　ほとんどの企業は、好むと好まざるとにかかわらず”分散システム”を選択している。変化に対応しやすく、既存シ,, ,ステムを活用できるからだ。しかし分散システムにすると、システム間を連携する技術は欠かせなくなる。そこで本講,, ,座では、複数の連携技術を取り上げ、その特徴を解説する。,, ,,, システム間連携技術の基礎　Part1 基礎編---ファイル転送，RPC，メッセージ・キューイング，EAIを理解する,,, ,http://itpro.nikkeibp.co.jp/article/lecture/20061215/257077/?ST=selfup,, ,,, ,　アプリケーション間を連携するにはさまざまな技術があり、適材適所に使い分ける必要がある。Part1では「ファイル,, ,転送」「RPC」「メッセージ・キューイング」「EAI」という4種類の技術の特徴を解説する。,, ,,, ,,　4種類のシステム間連携方法にはそれぞれ長所、短所があり、導入時のポイントは異なる（図１、表１）。4種類, ,,の技術は、同期と非同期の技術に分類できる。同期連携はプロシージャ・コールで、非同期連携はファイル転送, ,,とメッセージ・キューイング、EAIになる。, ,,, ,,, ,,, ,,, ,,, ,,, ,,, ,,, ,,, ,,, ,,, ,,, ,,, ,,, ,,, ,,, ,,, ,,, ,,, ,,, ,,, ,,, ,,, ,,, ,,, ,,, ,,, ,,, ,,, ,,, ,,, ,,, ,,, ,,, ,,, ,,, ,,, ,,, ,,, ,,, ,,, ,,, ,,, ,,, ,,, ,,, ,,, ,,, ,,, ,,, ,,, ,,, ,,, ,,, ,,, ,,, ,,, ,,, ,,表１●システム間連携の代表的な４つの手法, ,,, ,,連携技術,,,,,,長所,,,,,,,,,,短所,,,,,,,,,,導入時のポイント ,,ファイル転送,,,,,,大量データをまとめて送信す,,,,,,,,,,バッチ処理となるため、即座に,,,,,,,,,,他システムとの連携頻度を ,,,,,,,,るのに適している,,,,,,,,,,連携した業務には適さない,,,,,,,,,,少なくし、個々のシステムが ,,,独立して運用できるように ,,,設計する ,,プロシージャ・,,,,,,リアルタイムに連携できる。,,,,,,,,,,障害に弱い。一部の障害が,,,,,,,,,,サーバー間の通信ミドル ,,コール（RPC、,,,,,,また、プログラム・モジュール,,,,,,,,,,全体に影響しやすい。プログ,,,,,,,,,,ウェアとして利用し、システム ,,CORBAなど）,,,,,,単位でサーバーを分散配置,,,,,,,,,,ラム開発には高度なスキル,,,,,,,,,,間を密結合するのに適して ,,,,,,,,できるなど、拡張性に優れて,,,,,,,,,,が求められる,,,,,,,,,,いる ,,,,,,,,いる,,,,,,,,,,,,,,,,,,,, ,,メッセージ・,,,,,,即座に連携でき、他システム,,,,,,,,,,大量データの送信はファイル,,,,,,,,,,キューの監視とエラー時の ,,キューイング,,,,,,に与える障害の影響は小さい,,,,,,,,,,転送よりも効率が悪い。また、,,,,,,,,,,リカバリ処理が欠かせない ,,,,,,,,,,,,,,,,,,2フェーズ・コミットが求められ,,,,,,,,,, ,,,,,,,,,,,,,,,,,,るような密な連携には適さな,,,,,,,,,, ,,,,,,,,,,,,,,,,,,い,,,,,,,,,, ,,EAI(Enterprise,,,,,,即座に連携でき、他システム,,,,,,,,,,高価な製品が多い。また、,,,,,,,,,,EAIツールを稼働させるサー ,,Application ,,,,,,に与える障害の影響は小さ,,,,,,,,,,複数システムの連携に利用,,,,,,,,,,バーの可用性には十分注意 ,,Integration),,,,,,い。さらに、メッセージの,,,,,,,,,,するには、データの整理や,,,,,,,,,,する。EAIツールがダウンする ,,ツール,,,,,,振り分け機能があるため、,,,,,,,,,,メッセージ・ヘッダーの設計,,,,,,,,,,と、すべてのシステム間連携 ,,,,,,,,連携対象のシステム数が,,,,,,,,,,が欠かせないため、製品,,,,,,,,,,ができなくなる ,,,,,,,,増えても個々のシステムは,,,,,,,,,,導入時の負担が大きい,,,,,,,,,, ,,,,,,,,複雑になりにくい,,,,,,,,,,,,,,,,,,,, ,,, ,,　ファイル転送とメッセージ・キューイングの違いは、送信に適したデータ・サイズと送信頻度にある。ファイル転送, ,,は、大きなファイルを少ない頻度で送信するのに適している。一方メッセージ・キューイングは、小さいデータを頻, ,,繁に送信するのに適している。ただし、ファイル転送で小さいデータを頻繁に送信できないわけではない。メッセ, ,,ージ・キューイングで大きなデータを送信することももちろんできる。適用範囲は完全に分かれているわけではなく, ,,、かなり重なっている。, ,,, ,,　EAIツールは、前述した3種類の技術の上位に位置する応用製品になる。EAIツールが効果を発揮するのは、連, ,,携するシステム数が増えて運用管理や連携用のプログラム開発が複雑になったときである。以下、図１と表１で, ,,示した4種類の技術を使う上でのポイントや注意点などを順番に解説していこう。, ,,, ,,（１）ファイル転送, ,,, ,,,　システム間連携技術の中で最も導入しやすいのがファイル転送である。使い古された技術であるが、応用範 ,,,囲は広い。ファイル転送には多くの市販製品があるが、多くのOSに付随するFTP(File Transfer Protocol）で実 ,,,現できる。ただ、OS添付のFTPは無償で利用できるが、多くの場合、業務システムで使うにはログの採取や失 ,,,敗時の再送機能などを作りこまなければならない。 ,,, ,,,　ファイル転送は、大量データをまとめて送るのに適している。この後紹介するメッセージ・キューイングよりも、 ,,,大量データの送信速度は概ね速い。また、システム間の密接度が低いため、他システムの影響を受けにくい ,,,。これはシステムがダウンしても、他のシステムに与える影響が小さいことを意味する。送信プログラムをアプ ,,,リケーションとは別に作成する必要があるが、業務アプリケーションそのものに手を加えないため、アプリケー ,,,ションがシンプルになる。 ,,, ,,,　ファイル転送の欠点は、リアルタイム転送できない点である。ファイル転送の送信間隔を短くすればリアルタ ,,,イムに近づくものの、プロシージャ・コールのような同期処理は不可能。メッセージ・キューイングに比べても即 ,,,時性が低い。 ,,, ,,（２）プロシージャ・コール, ,,, ,,,　厳密なリアルタイム処理が必要な場合は、プロシージャ・コールを選ぶことになる。ただこの技術は、システ ,,,ム間を密に結合する場合に限定して使った方が良い。プロシージャ・コールの代表は、米OMGの分散オブ ,,,ジェクトの規格「CORBA（Common Object Request Broker Architecture）」や米Microsoftの「DCOM（Distribued ,,,Common Object Model）」などだ。ソケットなどを使って独自に作りこむことも可能だが、高いプログラム・スキ ,,,ルが要求される。 ,,, ,,,　プロシージャ・コールを利用する場合は、連携するアプリケーションにネットワーク・モジュールを組み込み、 ,,,プログラムの中から他システムのプロシージャを直接呼び出す。ファイル転送のように別途プログラムを用意 ,,,する必要はない。 ,,, ,,,　プロシージャ・コールの特徴は、何といってもリアルタイム性だ。通常の同一プロセス内での関数呼び出しの ,,,ように、システム間をまたがるプロシージャ・コールもプロシージャからの応答があるまで待ち、応答があって ,,,から処理を継続する。同期を保証するのだ。ただ、この特徴はトラブルに弱いという面を併せ持つ。プロシー ,,,ジャ・コールで連携している場合、連携先のシステムがダウンするとただではすまない。一緒にダウンする可 ,,,能性が高い。 ,,, システム間連携技術の基礎　Part1 基礎編---ファイル転送，RPC，メッセージ・キューイング，EAIを理解する （2/2） ,,, ,http://itpro.nikkeibp.co.jp/article/lecture/20061215/257077/?ST=selfup&P=2,, ,,, ,,（３）メッセージ・キューイング, ,,, ,,,　ファイル転送は即時処理に弱い。プロシージャ・コールはトラブルに弱い。メッセージ・キューイングはこの二 ,,,つの欠点を補っており、欠点の少ない技術と言える。 ,,, ,,,　メッセージ・キューイングは、キューに入れたメッセージをやり取りすることで、システム間を連携する。メッセ ,,,ージ・キューイングはファイル転送と同じ非同期型のメカニズムであるが、ファイル転送よりも即時性が高い。 ,,,アプリケーションの内部でメッセージを生成してキューに入れるため、利用者がリターン・キーを押したタイミン ,,,グでサーバーと連携することも可能だ。ファイル転送では、このような連携は難しい。 ,,, ,,,　また、メッセージの送り手は、キューにメッセージを入れるとすぐに次の処理に移る。受けては、キューからメ ,,,ッセージを取り出して処理する。メッセージの送り手と受け手は非同期で処理するため、一方のシステムがダ ,,,ウンしても直接影響を受けない。 ,,, ,,,　メッセージ・キューイングを利用する上での注意点は、エラー処理と運用監視である（図２）。この場合のエラ ,,,ーとは、業務アプリケーションのエラーを指す。図２上のように、メッセージを受け取ったアプリケーションがエラ ,,,ーを起こした場合、送り側のアプリケーションが何らかのリカバリ処理を必要とする場合が多い。プロシージャ・ ,,,コールであれば、連携先アプリケーションのエラーをプロシージャの戻り値などで知ることができる。だが、メッ ,,,セージ・キューイングは非同期のメカニズムであるため、メッセージの送り手が、受け手のエラーを知ることが ,,,できない。 ,,, ,,, ,,, ,,, ,,, ,,, ,,, ,,, ,,, ,,, ,,, ,,, ,,, ,,, ,,, ,,, ,,, ,,, ,,, ,,図２●メッセージ・キューイングを使う際の注意点, ,,,業務プログラムのエラー処理と、キューなどの運用監視に注意が必要である。メッセージを受け取った ,,,業務プログラムがエラーになったときのリカバリ方法を構築しなければならない。また、連携先のマシンや ,,,キューがトラブルを起こした時に、どう対処するかを事前に決めておくことが重要である ,,, ,,,　そのため、エラーが発生したことをメッセージの送り手のアプリケーションに通知する仕組みを作っておかな ,,,ければならない。エラー通知用のメッセージとキューを用意し、エラーを通知する。エラーの発生を知らせるメッ ,,,セージを受け取ったアプリケーションは、必要なリカバリ処理を行う。2フェーズ・コミットなどが求められるアプリ ,,,ケーションでは、リカバリ処理は複雑になってしまう。 ,,, ,,,　2番目の注意点は、運用監視である。メッセージ・キューイングは非同期のメカニズムであるため、連携先でト ,,,ラブルが起きても直接影響せず、キューの転送ができなくなるだけである。しかし、運用監視を怠れば、キュー ,,,がメッセージであふれるなどのトラブルが起きてしまう。連携先システムのサーバーやアプリケーション、キュ ,,,ー、ネットワークなどを監視し、トラブルが起きたときはどのように対処するかをあらかじめ決めておくことが重 ,,,要になる。 ,,, ,,,　メッセージ・キューイングにも欠点はある。ファイル転送に比べて導入は難しいし、バッチ処理を安易にメッセ ,,,ージ・キューイングに変更すると思わぬ落とし穴が待っている。次は、メッセージ・キューイングのトラブル例を ,,,見てみよう。 ,,, ,,,　メッセージ・キューイングは、キューからメッセージを”先入先出し”のルールで取り出し、１メッセージずつ処 ,,,理する。ファイル転送のように複数のデータをまとめて処理するわけではないため、メッセージの順番は重要 ,,,である。メッセージ・キューイングの導入当初、メッセージの順番に起因するトラブルに遭遇するケースがある。 ,,, ,,,　例えばこんな例だ。商品を発注するには当然商品マスターに該当商品がなければならない。にもかかわらず ,,,、新しい商品を発注する時、商品マスターへの追加メッセージを送る前に、発注メッセージを送ってしまった。ま ,,,た、複数の連続したメッセージを送ろうとしたが、一つのキューを複数のプロセスで共有していたため、連続さ ,,,せたいメッセージの間に他のメッセージが混入する例があった。受け手のアプリケーションはメッセージが連続 ,,,していることを想定しているため、エラーになってしまった。このような問題は、複数のキューを使ったり、メッセ ,,,ージの優先順位を付けることで解決できる。 ,,, ,,（４）EAI(Enterprise Application Integration)ツール, ,,, ,,,　連携しなければならないシステムが増えれば増えるほど、運用や開発負担が重くなる。連携先ごとに連携用 ,,,のプログラムを開発したり、キューを設定したりする必要があるからだ。運用スケジューリングは複雑になり、 ,,,連携用プログラムの開発負担は重くなる。そのようなシステム間連携の複雑さを解消するのが「EAIツール」で ,,,ある。 ,,, ,,,　ファイル転送やメッセージ・キューイング製品はシステムとシステムを直接つなぐが、EAIツールはシステムと ,,,EAIツールのサーバー（以下、EAIサーバー）をつなぐ。個々のシステムは連携するシステムが増えてもEAIサ ,,,ーバーとだけつなげばよいため、連携がシンプルになる。EAIツールを使えば、メッセージのヘッダー情報で送 ,,,信先を決めたり、一つのメッセージを複数のシステムに送信できる。 ,,, ,,,　EAIツールを利用するには、EAIツール用にサーバー・マシンを最低１台用意する。EAIツールは、システムと ,,,の接続やデータ変換などを行う「接続アダプタ」、メッセージを蓄える「キュー」、各種設定情報を格納する「レジ ,,,ストリ」などからなる。接続アダプタは、主要な統合業務パッケージやRDBMS製品に対応している。もちろん、 ,,,自社開発した独自システムを連携することも可能だ。ただその場合は、基本的にEAIツールとの連携部分を作 ,,,りこむ必要がある。 ,,, ,,,　ほとんどのEAIツールには、システム間連携をGUIで設定できるツールが付いている。このツールを使えば、 ,,,プログラミングすることなくシステム間連携が設定できる。自社開発のシステムにつなげる場合は接続部分を ,,,開発しなければならないが、それでも、データ・フォーマットの変換部分などをGUIツールで設定できる。GUIツ ,,,ールで開発したプログラムは、EAIツール独自のスクリプト言語やJava言語などに展開される。 ,,, ,,,　EAIツールを選択する際のポイントは五つある（図３）。まず、自社システムで使っている漢字コードやネットワ ,,,ーク・プロトコルに対応しているかどうかだ。パッケージに対応したアダプタがあれば、プログラム開発コストを ,,,下げることができる。３番目はクラスタリング機能の有無。EAIサーバーはシステム間の連携を担当するため、 ,,,EAIサーバーがダウンするとシステム間連携ができなくなる。そのようなトラブルを回避するには、EAIサーバー ,,,をクラスタリング構成で運用してフェール・オーバーを可能にしておく必要がある。 ,,, ,,, ,,, ,,, ,,, ,,, ,,, ,,, ,,, ,,, ,,, ,,, ,,, ,,, ,,,図３●EAIツールの選択のポイント ,,,,自社で使っている漢字コードやパッケージ製品に対応していることは重要。監視機能やクラスタ機能、デー,,,,,,,,,,,,,,,,,,,,,,,, ,,,,タ転送速度などの優劣がポイントになる。,,,,,,,,,,,,,,,,,,,,,,,, ,,, ,,,　４番目は実行性能だ。EAIサーバーのつながるシステム数が増えてくると、やり取りするメッセージの数は多く ,,,なる。単位時間当たりの可能なデータ送信料などを確認しておこう。また、GUIツールで開発したプログラムが ,,,スクリプト言語に展開される場合、処理速度がネックになることがあるので注意が必要だ。そして最後は、運用 ,,,管理機能の優劣である。ログの採取や障害監視などは、EAIツールには不可欠な機能である。 ,,, ,,, システム間連携技術の基礎　Part2 ESB編---SOAのシステム連携基盤EAIがWebサービス取り入れ進化,,, ,http://itpro.nikkeibp.co.jp/article/lecture/20061215/257089/?ST=selfup,, ,,, ,　SOAの考えに基づくシステム連携の基盤として脚光を浴びている。特徴は、機能ごとの分散処理を可能にし、Web,, ,サービスを標準として取り入れたこと。EAIとの違いなどとともに、ESBとは何かを説明しよう。,, ,,, ,,　ESB(Enterprise Service Bus）を一言で表せば、「SOA（Service Oriented Architecture）の実現に必要な、シス, ,,テム同士をつなぐ基盤」である。そのためESBを理解するには、SOAとは何かを押さえておく必要がある。まず, ,,は、SOAについて簡単に説明しよう。, ,,, ,,　SOAでは、企業の各システムが備える機能ごとに、Webサービスなどの標準化したインタフェースを設け、ほか, ,,のシステムやエンドユーザーのWebブラウザおよびクライアント・ソフトから、単純な手続きによってネットワーク経, ,,由で呼び出せるようにする。これを、システムの機能の「サービス化」と呼ぶ。, ,,, ,,　さらに、連携させるシステムのいずれかに、取り扱うデータ項目の追加やネットワーク上の場所などの変更が生, ,,じても、ほかのシステムを修正せずにそのまま連携できるようにする。このような、連携させるシステム同士が互, ,,いの変更の影響をほとんど受けない状態を「疎結合」という。, ,,, ,■システムの機能を自在に組み替え,, ,,, ,,　疎結合されたシステムが持つ機能（これを「サービス」と呼ぶ）は、自在に組み替えて利用することが可能だ。そ, ,,のため、既存システムに必要な機能がそろっていれば、新しい業務のやり方に合わせたシステムを、大幅に改修, ,,することなく素早く実現できる。, ,,, ,,　例えばSOAの考えに基づいたビジネスプロセスの在庫管理ツールを使うと、在庫管理や配送管理のシステムが, ,,備える「在庫引当て」「配送手配」といった機能がそれぞれアイコンとして表示され、それらをつなぎ合わせて設定, ,,をするだけでシステム連携の仕方を組み替えられる。, ,,, ,,　ただしSOAは万能というわけではない。サービス化によってシステム同士を繋ぎやすくする反面、通信や処理性, ,,能のオーバーヘッドが大きくなりやすい。高い性能が必要とされるシステム連携には向かない面がある。SOAが, ,,向くのは、処理性能が多少犠牲になったり性能を高めるためのコストが生じたりしても、ビジネスプロセスの変更, ,,に合わせて簡単に素早くシステム間の連携を組み替えたい、という用途である。, ,,, ,■つなぐために必要な三つの機能,, ,,, ,,　では、SOAの基盤となる「ESB」とはどのようなものか。ESBの機能を挙げると、「ビジネスプロセスを設定してそ, ,,れに合わせてシステムを連携させる」「システム間でやり取りするメッセージが確実に届いたかどうか監視する」「, ,,連携させたシステムの各機能がどれだけ利用されているかを管理する」--といった具合に様々なものがある（図１, ,,）。, ,,, ,,, ,,, ,,, ,,, ,,, ,,, ,,, ,,, ,,, ,,, ,,, ,,, ,,, ,,,現状ではESBの定義には様々なものがある。機能としてみると、「各システムの機能を管理するレジストリ」 ,,,「プロトコルやデータ形式の変換」「メッセージ・ルーティング」という三つが最低限必要な機能であり、これらの ,,,機能を備えるシステム基盤が狭義のESBと言える。広義のESBには、セキュリティやトランザクション管理、記 ,,,述したビジネスプロセスの実行環境など、システム同士をつなぐための諸機能が含まれる ,,, ,,　実はESBの定義は種々あり、それらの機能をどこまで含めるかで意見が分かれる。ただし最低限必要な機能と, ,,して次の三つが挙げられる。, ,,, ,,,・,各システムの情報を管理するレジストリ,,,,,,,,,,,,,,,,,,,,,,,, ,,,・,プロトコルやデータ形式の変換,,,,,,,,,,,,,,,,,,,,,,,, ,,,・,メッセージのルーティング,,,,,,,,,,,,,,,,,,,,,,,, ,,, ,,　ESBの具体的なイメージを持ってもらうため、接続した各システムから見てESBがどのような役割を果たすかを, ,,図２に示した。受注管理、在庫管理、配送管理---といった連携させるシステムは、すべてESBと直に接続する。, ,,必ずESBを通じて、ほかのシステムとメッセージをやり取りする。つまりESBは、連携するシステム間のメッセージ, ,,のやり取りを一手に担う通り道になる。, ,,, ,,, ,,, ,,, ,,, ,,, ,,, ,,, ,,, ,,, ,,, ,,, ,,, ,,, ,,, ,,,ESBは、レジストリ、変換、ルーティングという三つの基本機能を備える。接続された個々のシステムから見る ,,,と、相手のシステムの所在や利用するプロトコル／データ形式を意識することなく、ESBにメッセージを渡すだ ,,,けで連携が可能になる ,,, ,,　ESBに接続された各システム（正確にはシステムの単一の機能もしくはそれらを組み合わせた「サービス」だが, ,,、分かりやすさを優先してここでは「システム」と表す）が別のシステムへのメッセージ送信をESBに依頼する際、, ,,送り先のシステムの物理的な場所まで指定する必要はない。ESBによって、各システムの場所を一元的に管理し, ,,ているからだ。そのための情報の格納庫を「レジストリ」と呼ぶ。, ,,, ,,　ESBはレジストリの情報に基づいて、仲介するメッセージのルーティング処理を実行し、送り先のシステムにメッ, ,,セージを届ける。ルーティングする際、メッセージ中の引数に応じて送り先を変えるといった単純な分岐処理や、, ,,あるシステムにメッセージを送り届けた後で次に別のシステムにも届けるという行程の設定も可能である。メッセ, ,,ージを届けるとき、ESBは送り先のシステムに合わせて、プロトコルとデータ形式を変換する。このときも、レジスト, ,,リの情報を利用する。ESBでは、各システムが利用可能なプロトコルやデータ形式をレジストリで管理している。そ, ,,の情報に基づいて、仲介するメッセージを送り先のシステムが解釈可能な形式に変換する。, ,,, システム間連携技術の基礎　Part2 ESB編---SOAのシステム連携基盤EAIがWebサービス取り入れ進化 （2/3） ,,, ,http://itpro.nikkeibp.co.jp/article/lecture/20061215/257089/?ST=selfup&P=2,, ,,, ,■EAIツールが抱える二つの問題,, ,,, ,,　これら「レジストリ」「変換」「ルーティング」という三つの機能を見ると、「従来のEAI(Enterprise Application , ,,Integration)ツールと何が違うのか」と思うかもしれない。従来のEAIツールも、これら三つの機能を備えているので, ,,、その疑問は最もである。しかし、従来のEAIツールでSOAの考えに基づくシステムを構築すると、以下の二つの, ,,大きな問題に直面する。, ,,, ,,,（１）,,システム同士をつなぐのに必要な大半の機能を、1台のサーバー機で集中処理する仕組みなので、そ,,,,,,,,,,,,,,,,,,,,,,, ,,,,,のサーバー機が性能上のボトルネックになりやすい,,,,,,,,,,,,,,,,,,,,,,, ,,, ,,,（２）,,ツール・ベンダーごとに独自仕様を採用しているので、接続するにはその仕様に合った専用ソフトが必,,,,,,,,,,,,,,,,,,,,,,, ,,,,,要になるほか、他ベンダーのツールとの互換性がない,,,,,,,,,,,,,,,,,,,,,,, ,,, ,,　誤解を恐れずに言えば、ESBはこれらの問題を解決したEAIツールの進化形ととらえることもできる。以下、「処, ,,理性能のボトルネック」と「ベンダーの独自仕様」という二つの問題を、ESBではどのように解決しているのか見て, ,,いこう。, ,,, ,,（１）処理性能のボトルネック---機能別にコンポーネント化、複数サーバーで分散, ,,, ,,,　先に「SOAが向くのは、処理性能は多少犠牲になっても、ビジネスプロセスの変更に合わせて簡単に素早く ,,,システム間の連携を組み替えたい場合」と説明した。これは、処理性能を考慮しなくても良い、という意味では ,,,ない。当然ながら、システムの使い勝手を損ねない一定以上の処理性能を確保する必要がある。ところがES ,,,Bでは、取り扱うメッセージの数が多く変動する可能性がある。処理性能に余裕を持たせたハードウェアを用意 ,,,したとしても、しばらく運用すると使い勝手に影響するほど性能が低下するかもしれない。 ,,, ,,,　予測の難しさは、ESBの接続対象となるシステムが、従来のEAIツールの接続対象システムよりも広範囲で ,,,あることに起因する。ESBではほぼすべての社内システムに加え、取引先や顧客などのシステムも連携対象 ,,,になり得る。接続するシステム数が増えると、システム間のメッセージ数は幾何級数的に増大する。ビジネス ,,,プロセスに合わせて、システム連携のさせ方を素早く組み替えられることも、メッセージ数の変動につながる。 ,,, ,,,　こうした理由からEAIツールを利用したケースより、ESBを利用するケースの方がメッセージ数の変動が大き ,,,い。そのためESBでは、メッセージ数の増大に合わせて、処理性能を柔軟に高められる仕組みが重要である。 ,,, ,,,　従来のEAIツールでは、処理性能を高めるのが簡単ではなかった。従来のEAIツールにおける主流の形態は ,,,、車輪になぞらえて「ハブ＆スポーク」と呼ばれるものである（図３）。連携させる各システムは、スポークの部 ,,,分にあたる。スポークの部分で行うメッセージに関する処理は、プロトコル変換程度である。 ,,, ,,, ,,, ,,, ,,, ,,, ,,, ,,, ,,, ,,, ,,, ,,, ,,, ,,, ,,, ,,, ,,, ,,, ,,, ,,,,EAIツールの中核となるハブは、データ変換やルーティング、レジストリ、記述したビジネスプロセスの実行,,,,,,,,,,,,,,,,,,,,,,,, ,,,,環境といった様々な機能を備えている。これらの機能の大半は、1台のサーバー機で集中して実行する仕,,,,,,,,,,,,,,,,,,,,,,,, ,,,,組みになっていた,,,,,,,,,,,,,,,,,,,,,,,, ,,, ,,,　それ以外のレジストリやデータ変換、ルーティングなどは、「ハブ」にあたるサーバーが一手に処理する。 ,,,従来のEAIツールでは、それらを繋ぐための機能の大半を1台のサーバー（正確には単一のOS上）で集中処 ,,,理する仕組みになっていた。 ,,, ,,,　ESBでは処理が集中するという問題に対し、大きく二つのアプローチをとっている。その一つは、つなぐため ,,,に必要な機能をコンポーネント化することにより、レジストリやデータ変換、ルーティングといった機能ごとにサ ,,,ーバーを分け、分散処理できるようにするというものだ（図４）。ただし単純に、機能ごとに別のサーバーで稼働 ,,,させると処理性能が悪化する。 ,,, ,,, ,,, ,,, ,,, ,,, ,,, ,,, ,,, ,,, ,,, ,,, ,,, ,,, ,,, ,,, ,,, ,,, ,,,,ESBでは、分散処理を実現しやすい仕組みとなっており、典型的なのは、レジストリやデータ変換、,,,,,,,,,,,,,,,,,,,,,,,, ,,,,ルーティングといった機能ごとにコンポーネント化する、というもの。ただし単純に分散処理すると、レジスト,,,,,,,,,,,,,,,,,,,,,,,, ,,,,リへの問い合わせが膨大になるので、レジストリ上のデータをキャッシュとして分散配置できる。なおここで,,,,,,,,,,,,,,,,,,,,,,,, ,,,,は図３と対比させるため明示的にアダプタ（プロトコルを変換するコンポーネント）を描いたが、Webサービス,,,,,,,,,,,,,,,,,,,,,,,, ,,,,のインタフェースを備えるシステムであれば必要ない,,,,,,,,,,,,,,,,,,,,,,,, ,,, ,,,　特にボトルネックとなるのはレジストリへのアクセスである。データ変換やルーティング処理を実行するたび ,,,に、レジストリに情報を問い合わせる必要があるからだ。そのため、データ変換やルーティングを処理するサ ,,,ーバーに、レジストリに格納している情報をキャッシュとして蓄積する仕組みを取り入れている。 ,,, ,,,　もう一つのアプローチは、同じ機能を持つ複数台のサーバーを並べ、処理するメッセージを順番に割り振っ ,,,ていくというもの。ESB自体も負荷分散の機能を備えているが、処理性能を考えて負荷分散装置（ロード・バラ ,,,ンサ）を利用できる。 ,,, システム間連携技術の基礎　Part2 ESB編---SOAのシステム連携基盤EAIがWebサービス取り入れ進化 （3/3） ,,, ,http://itpro.nikkeibp.co.jp/article/lecture/20061215/257089/?ST=selfup&P=3,, ,,, ,,（２）ベンダーの独自仕様---Webサービスを標準採用、専用のアダプタ不要に, ,,, ,,,　「従来のEAIツールにおける大きな問題の一つは、ベンダーごとの独自仕様に基づいてメッセージングをして ,,,いたことにある」。独自仕様では、どのような問題が生じるか（図５）。一つは、接続するシステムごとに、ツール ,,,・ベンダーが提供する比較的高価な「アダプタ」が必要になることだ。アダプタとは、プロトコル形式を変換する ,,,コンポーネントで、システムと接続する部分に利用する。手組のシステムではアダプタを利用して連携部分を ,,,開発する必要があるが、独自仕様であるだけに、その仕様に精通したITエンジニアの絶対数が少ない。 ,,, ,,, ,,, ,,, ,,, ,,, ,,, ,,, ,,, ,,, ,,, ,,, ,,, ,,, ,,, ,,, ,,, ,,, ,,, ,,, ,,,,従来のEAIツールでは、独自のメッセージ形式や特定のプロトコルを用いていたので、EAIツール独自の,,,,,,,,,,,,,,,,,,,,,,,, ,,,,アダプタを利用する必要があった。そのため、異なるベンダーのEAIツールを使っているシステム同士では,,,,,,,,,,,,,,,,,,,,,,,, ,,,,相互接続できないなどの問題が生じていた,,,,,,,,,,,,,,,,,,,,,,,, ,,, ,,,　もう一つは、ベンダー間でEAIツールの互換性がないこと。自社内のシステムを連携させるなら、この点は問 ,,,題ないように思えるかもしれない。しかし近年、関連会社との連結経営を強化するため互いのシステムを連携 ,,,させる企業が増えている。そのときに関連会社が異なるベンダーのEAIツールを使っていると、巨額の費用を ,,,投じて刷新する羽目になる。 ,,, ,,,　また独自仕様であることによって、利用しているEAIツールのベンダーが市場から撤退したり、倒産したりした ,,,場合、サポートを受けられなくなり、別ベンダーのEAIツールに全面的に乗り換えなければならない、というリス ,,,クも生じる。 ,,, ,,,　一方ESBでは、「Webサービス」という標準仕様を導入し、連携させるシステムのインタフェースの互換性を ,,,保っている。システムにWebサービスのインタフェースを備えれば、高価なアダプタを用意したり、新たに開発し ,,,たりする必要はない。Webサービスを取り入れたことのメリットは大きい。連携させるシステムがWebサービス ,,,のインタフェースを備えていれば、どのベンダーのESBにも接続できる（図６）。 ,,, ,,, ,,, ,,, ,,, ,,, ,,, ,,, ,,, ,,, ,,, ,,, ,,, ,,, ,,,,ESBでは、SOAPやWSDL（Web Services Description Language）といったWebサービスの標準仕様を,,,,,,,,,,,,,,,,,,,,,,,, ,,,,取り入れている。これにより、異なるベンダーのESBツールを利用している関連会社などのシステムとも連,,,,,,,,,,,,,,,,,,,,,,,, ,,,,携させやすいといった利点がある。,,,,,,,,,,,,,,,,,,,,,,,, ,,, ,,,　ここで、ESBがインタフェースの標準仕様として採用しているWebサービスとは何かについて、簡単に解説し ,,,ておこう。具体的には、メッセージとしてやり取りするXML(eXtensible　Markup Language）文書の構造や書式を ,,,定めた「SOAP（Simple Object Access Protocol）」と、連携させるシステムの機能（サービス）の呼び出し方法 ,,,や引数などをXML文書で表した「WSDL（Web Services Description Language）」のことである。 ,,, ,,,　ただしSOAPとWSDLの組み合わせだけで、システム連携に必要なESBの機能を全て実現できるわけではな ,,,い。ケースによっては、電子署名や暗号化によってセキュリティを高めたり、確実にメッセージが届いたことを ,,,保証したりする機能も必要になる。これらは、SOAPとWSDLだけでは実現できない。 ,,, ,,,　そうした付加的な機能については、XML関連の標準化団体である「OASIS（Organization for the Advanceme ,,,nt of Structured Information Standards）」やWebの仕様に関する標準化団体「W3C（World Wide Web Consorti ,,,um）」、Webサービスの標準化団体「WS-I（Web Services Interoperability　Organization）」などがそれぞれ、標 ,,,準化を進めている。