システム連携の歴史を振り返る：SOAへ至る道

　前回紹介したとおり、メッセージという概念はオブジェクトを連携させるために非常に重要な役割を果たしている。そこでシステム間連携を実現するためのSOA史を見ていくことで、メッセージが果たしている役割の変化について理解していこうと思う。

　その昔、システムを連携させるためにはデータをテープに書き込み、物理的に搬送していた（さらに昔はパンチカードだったらしいが、残念ながら筆者は見たことがない）。

　たとえば注文情報を取引先に届けようと思うと、物理的に搬送する回数をできるだけ減らす必要がある。そこで日中にたまったデータを日次のバッチによってソーティングし、取引先ごとにテープに書きだして送っていた。この時点では、システム同士は疎結合で、テープが届くまで各システムは独立して動いていた。

図1

　やがてオンライン化が進みだすと、クライアントとサーバという概念が出現する。それまでのコンピューターは一部のスタッフだけがデータ入力に使うものと考えられてきた。ところがコンピューターが多くの業務をこなすようになると会社にいる大半の人がコンピューターを使うようになる。とはいえデータそのものは会社として共有しておかなくてはいけない。

　そこで各自に配られて入力を受け付けるコンピューターをクライアントと呼び、クライアントからのリクエストを受け付けて処理を実行し、データを共有するコンピューターをサーバと呼ぶようになった。このクライアントとサーバ間の通信は緊密なリアルタイムの処理が求められた。そのためにトランザクション処理と呼ばれるデータの一貫性管理を行う仕組みが発達することになる。

図2

　一方でシステムの乱立も進んだ。全社で共有システムではなく、部門や事業部といった単位でもシステムが利用されるようになった。こうしたシステムが個別に閉じた世界であるだけなら良いが、相互にデータをやり取りする必要が出てくる。ここもオンラインで処理が行われることになる。

　ただし、システム間はクライアント・サーバ間よりも疎に保たれなくはならない。サーバがダウンしていればクライアントが使えないのは仕方がないにせよ、他システムがダウンしているからといって自システムまで停止するのは問題がある。

　ここでもバッチ型のファイル転送処理は有効であった。テープがオンラインになっただけで、ここの基本的な考え方は変わらなかったのである。

図3

　しかし、各システムの関連度が高くなってくると、より細かい単位でのオンライン連携が求められてくる。そこでMOM（Message Oriented Middleware：メッセージ指向ミドルウェア）が登場する。MOMは送り手のシステムからの要求を受け付けると、一度のその情報をキューにため込み、受け手のシステムが受け取るまで情報を保持する。送り手のシステムからするとMOMにメッセージを投げ込めば処理は終了する。このため非同期にシステム間を連携することができたのだ。

図4

　ここまででメッセージをやり取りするためのパターンは、ほぼ確立されている。整理してみよう。

　テープ搬送では、送り手はメッセージをテープに書き出せば終わりである。その後、テープがどうなろうが知ったことではない。個々のシステムの独立性は非常に高い。

　オンラインのクライアント・サーバシステムでは送り手がメッセージを送信し受け手がその結果を返し終わるまでの間、送り手と受け手は互いにロックされる。このタイプがもっとも緊密な関係になる。

　オンラインのファイル転送は送り手が届け終わるまで、送り手と受け手は互いにロックされている。受け手がいなければ送り手はメッセージを送ることができないが、送り終われば解放される。あとは受け手型の処理が行われるだけだ。

　MOMは送り手と受け手に直接的な関係がない。送り手はメッセージをミドルウェアに渡せば解放される。一方で、受け手はミドルウェアから通知を受ける形でデータを受け取る。お互いがロックされることはない。

　この関係の強さをまとめると表1のようになる。

表1

　では、SOAの出現によってメッセージの考え方はどのように変化したのだろうか。次のページで見ていこう。