技術動向――SOAに連なる分散アーキテクチャの発展経緯：サービス指向アーキテクチャ 第2部（2/2 ページ）

[Open Enterprise Magazine]

　従来の個々の業務システムを完結した全体と見る見方からは、新しいシステムは複数システムを連携させ、統合したものと見えるが、根本的な考え方としては、やはり独立して完結したシステムを構築するという手法のままだといえるだろう。こうした発想で多数のシステムを統合していくと、システム間の連携をその都度個別対応で作り込んでいく、という結果になる。新たに連携を実現する必要のあるシステム間で連携のために必要なデータ形式やデータ交換のためのメカニズムを摺り合わせ、個別に実装していくわけだ。こうした手法は、既存のシステムに対する変更を最小限に留め、必要最小限の追加投資で連携を実現できる可能性がある。しかし、連携を必要とするシステムの数が少なければよいが、システムの数が増えてくると、接続が増えるにつれて作業量が爆発的に増加するという問題がある。そこで、次に試みられたのがハブ＆スポーク・モデルによる相互接続である。ハブとは車軸のことであり、スポークは、車輪と車軸を繋ぐ放射状の支持構造である。自転車の車輪を思い浮かべて頂ければ、イメージが沸くだろう。

　ハブ＆スポーク・モデルでは、中央に相互連携とデータ交換のための専用サーバを設置し、各システムはこのサーバとのみ接続する、という形になる。システム間の連携は、このサーバが中継して実現するのである。この場合、システムを接続する際に新たに開発する必要があるのは中継サーバと接続するためのメカニズムだけで、連携相手となるシステムに個別に対応する必要はなくなる。そのため、接続すべきシステムが増加しても、開発負担は最小限で済む。新たに接続することになったシステムと中継サーバの間の接続さえ実現すれば、既存のシステムには何ら手を加える必要はない。

　ハブ＆スポーク・モデルに基づくシステム連携は、EAI（Enterprise Application Integration）として実装され、中継サーバはEAIツールとして販売されている。システム間の連携では、データの形式を変換したり、通信の開始／終了を制御したりといったさまざまな追加機能が必要になり、従来の個別接続のアプローチでは、接続するシステム間で毎回こうした機能を作り込んでいたが、EAIでは、こうした変換や調整の機能をEAIツールにまとめて組み込んでしまう。

図2■ハブ＆スポーク・モデルによる相互接続の簡素化。システムごとに専用のインタフェースを使って相互接続するのは、数が少ないうちはいいが、システム数が増えると接続も膨大な量になる。ハブ＆スポーク・モデルでは、接続数を大幅に削減できる

　EAIによって、分散したシステムを相互に接続する基礎はできあがったのだが、長期的な発展を考えると、インタフェースが安定した標準的なものであることが求められる。つまり、各システムとEAIツールとの接続が、EAIツール独自のインタフェースで実装されると、EAIツールに囲い込まれ、変更が難しくなるという問題が生じるのである。

　そこで、まずデータ自体をXMLで標準化することで個別のデータ変換プロセスを実装する必要を排除する方向に進んだ。続いて、インタフェースにも標準が確立された。それが、Webサービスということになる。XMLによるデータ表現とWebサービス・インタフェースによる相互通信を前提とすれば、実は接続自体はハブ＆スポーク・モデルに拘る必要はなくなる。要は、すべてのシステムが相互接続のための標準インタフェースを備えており、それを使って接続できるのであれば、システム数が増えることによる負担の大半が排除できることになる。こうして、Webサービスに基づく相互接続によって分散したシステムを統合する動きが強まり、それがSOAへの注目を高めることになった。

Webサービスの拡張

　Webサービスは、XMLによるデータ表現と、SOAP（Simple Object AcessProtocol）に基づく通信を基本としたプログラム・モジュールの相互連携のメカニズムである。そもそもの発想は、インターネット上で提供されている多数のサービスを統合／連携させて付加価値を生み、新たなサービスを作り出すことにある。しかし、一足飛びにインターネット上でのサービス連携に進むのはやはり無理があり、現実には企業内でのシステム連携や、イントラネットを介した企業グループ内での特定システム間の連携に使われ始めたというレベルに留まっている。

図3■Webサービス技術の概要

　当初はWebサービスの仕組みさえあれば、どのようなサービスの連携でも実現できるかのような語られ方もしたが、実際にはそのようなことはなく、連携させるサービスごとにさまざまな合意事項が必要である。そのため、各種業界団体を舞台に、Webサービスのための周辺規格とでもいうべきものが次々と標準化されつつある。ごく単純に言えば、Webサービスで交換されるデータはXML形式になるので、業界ごと、あるいはサービスごとに、XMLデータのためのスキーマを統一し、利用しやすいデータとなるように、あらかじめ準備を整えておくという作業が次々と進んでいるのだと表現してもよいかもしれない。また、通信プロトコルとして使われるSOAPはごく単純なメッセージ交換の機能だけを実装してあるため、企業間でのサービス呼び出しに必要となるセキュリティや認証、確実性を保証するための問い合わせ／確認など、さまざまな追加機能を付け加える必要がある。技術的には、XML＋SOAPという基本的な要素を使えばXMLデータの交換は可能になるわけだが、ビジネスの現場で使うためには、より高度な機能も揃っていないと安心して使えるものにはならないということでもある。Webサービスは、現実には比較的低レベルのインタフェースであり、「サービスの連携」という高度な機能を実現するためには、不足している要素が多い。不足を補うための追加仕様の標準化では、OASIS（Organization for the Advancement of Structured Information Standards）などの業界団体が重要な役割を果たしている。OASISは、eビジネスの標準を開発／推進する非営利の業界団体である。ここでは、ビジネス利用のためのXMLの標準規格であるebXMLや、セキュリティのための標準規格SAML（Security Assertion Markup Language）といった各種の規格制定に精力的に取り組んでいる。また、もう1つの重要な業界団体としてWS-IもWebサービスを現実的なビジネスの現場での要求に対応させるための活動を活発に行なっている。WS-I（WebServices Interoperability Organization）は、Webサービスの互換性を確保するための活動を中核として、標準プロファイル（Basic Profile）の策定を行なっている。

Webサービスの追加仕様

記事の続きは、以下のPDFで読むことができます。

---

本特集は、ソキウス・ジャパン発刊の月刊誌「Open Enterprise Magazine」の掲載特集を一部抜粋で掲載したものです。次の画像リンク先のPDFで記事の続きを読むことができます。同特集は、2004年12月号に掲載されたものです。

サイズ　360Kバイト