最小限の手間でシステム間連携を実現する〜疎結合アーキテクチャの登場：21世紀はじめのWeb技術史（3）

2000年以降のIT技術動向

単一のアーキテクチャと密結合インターフェイス

　企業向けシステムが「その企業だけのために」構築され、外部とのインターフェイスを意識しなくてよかった場合においては、採用するアーキテクチャやインターフェイスは独自仕様のものが採用されていた。特にメインフレームに代表されるクローズド（閉鎖的な）アーキテクチャにおいてはもとより仕様が公開されていない（する必要がない）ため、他システムとのインターフェイスは考慮せずメーカー独自の仕様、単一のアーキテクチャによっていたのである。

　その後オープンシステムの時代を迎えると、他システムとの連携が必要な場面で必要なインターフェイスをとる必要性が出てくる。例えば商品の受発注取引のように、取引先とのデータのやりとりが必然的に起こるようなケースでは、商品データを表すデータ形式や取引データをやりとりするうえでのインターフェイスをあらかじめ取引先と取り決め、その仕様に基づくインターフェイスをシステムに実装することになる。

　このアプリケーション間のインターフェイスは個別に設計・実装され、アプリケーションの内部構造に手を加えるレベルで連携することから「密結合」なアーキテクチャと呼ばれた。この場合取引先が1つであれば想定するインターフェイスは1つで事足りるため、アプリケーション間インターフェイスも個別に実装すれば事足りていたのである。

密結合のイメージ

　多少余談になるが、オープンシステムの時代においてもERPパッケージソフトは独自かつ単一のアーキテクチャで構築され、他システムの連携は（1990年代においては）意識されていなかった。ERPパッケージは企業の資源効率化という観点から統合的なシステムを実現し一大ブームを起こしたが、オープン化時代においても他システムとの連携は意識しないクローズドな思想に基づくシステムである。しかしその後、他システムの連携において必然的に変化を迫られることになり、現在においてはJavaなどのオープンな言語とオープンインターフェイスによるアーキテクチャに取って代わられつつある。

アプリケーション連携のための疎結合〜EAIとWebサービス

　オープンシステムが浸透するにつれ、システムがデータをやりとりする取引先も膨大な数に広がっていく。相手先のシステムごとに個別にインターフェイスを実装することが煩雑になってくると構築コストも高くつくことになり、古いアーキテクチャのシステムを抱える企業にとってはコスト面・業務への影響面に鑑みてそのような投資に踏み切ることが難しくなる。このような事情から、アプリケーションインターフェイスを共通化・標準化する動きが加速していった。

　ちなみに1990年代からアプリケーションインターフェイスを標準化する動きはあった。DCOMやCORBA/IIOPといった分散オブジェクトアーキテクチャがそれである。ただしこれらの標準化技術自体はインターネットが出現する前に策定された独自仕様であり、これらのアーキテクチャ相互でのやりとりを実現するためには、「追加的なインターフェイス記述が必要」「ファイアウォールを通過するために独自の設定が必要」、などのデメリットがあったため、広く普及するには至らなかった。

　アプリケーションインターフェイス共通化の要請に応える形で登場するのが、「密結合」に相対する概念としての「疎結合」アーキテクチャである。すなわち、アプリケーションの内部構造に手を加えることなくシステム間の連携を実現する方法だ。ここではまず、EAI（Enterprise Application Integration）と呼ばれる概念が先駆けとなって出現した。EAIとは異機種のシステム間におけるプロセスやデータ連携やソフトウェア統合を図るためのソフトウェア技術の総称を指し、EAI対応ソフトウェア（EAIツール）は以下のような機能を有する。

　・アダプタ（システム間のインターフェイスを提供する）
　・ルーティング（システム間で受け渡しするデータを仲介する）
　・フォーマット変換（各システムの取り扱うデータ形式の違いを吸収する）
　・ワークフロー（業務に合わせたシステム機能を再編成する）

疎結合（EAI）のイメージ

　これらの組み合わせにより異なるシステム間で連携を図れるため、一度構築したシステムをムダにせず、またアプリケーションインターフェイスを個別に実装するオーバーヘッドを少なくすることができるというメリットが得られた。ただし、EAIツール自体が特定のソフトウェア基盤を前提としていること、アダプタが多くのシステムに対応する必要があることを受けて必然的に高価なツールとなったことなどにより、広く普及には至っていない。

　疎結合の実装形態として次に出現したのが「Webサービス」だ。WebサービスはWWW（World Wide Web）関連技術を用いてソフトウェアをインターネット越しに使えるようにする一連のソフトウェア技術基盤の総称であり、多くはXML（eXtensible Markup Language、拡張マークアップ言語）をベースにしている。Webサービス同士を連携させるアプローチが今後のソフトウェア開発の主流になるものと予見されている。Webサービスの登場で、異機種間のシステム連携に当たるコスト面・技術面の障壁が取り除かれていった。

ビジネスニーズに合わせた疎結合〜WebサービスからSOAへ

　EAIやWebサービスは技術要素の観点での「疎結合」を実現する手段であった。これらをさらに拡張・統合し、ビジネス要件に基づく疎結合の実現とレガシーシステムを生かしつつ新システムとの統合を図るアーキテクチャが「SOA」（Service-Oriented Architecture、サービス指向アーキテクチャ）である。SOAとは、ビジネス上の機能に相当するソフトウェアを1つのサービスとし、そのサービスをネットワーク上で連携するシステム構築のアプローチで、2004年ごろから提唱された。以下の概念の多くはWebサービスの構成要素である（WebサービスとSOAを同一視する見解もあるが、ここではビジネスの要請に対応した別の概念とする）。

　SOAで用いられている主要な技術要素は以下のとおりである。

　■ WSDL（Web Services Description Language）：XMLをベースとしてWebサービスのありか・利用しているフォーマット・通信プロトコルなどをWebサービスのインターフェイスとして記述する

　■ UDDI（Universal Description, Discovery, and Integration）：XMLをベースとして、Webサービスを検索するシステムの総称。企業側でWebサービスに関する各種情報（名称および機能、提供対象、技術仕様など）を「UDDIレジストリ」（「Webサービスの電話帳」のようなもの）にあらかじめ登録・公開しておくことで、必要なサービスを必要な場面で自由に利用することができる

　■ SOAP（Simple Object Access Protocol）：他のシステムにあるデータやサービスを呼び出すためのメッセージングプロトコル。XML文書にSOAPエンベロープと呼ばれる付帯情報を追加し、HTTPプロトコル上においてやりとりが行われる。サービスの利用者および提供者の双方がSOAPに対応していれば、異なるコンピュータシステムの間でデータのやりとりを共通化することができる

疎結合（Webサービス／SOA）のイメージ

　それまでの疎結合の考え方がソフトウェア部品を単位としていたのに対し、SOAでは「ビジネス機能」を基本単位としてとらえており、業務の連携や統合というニーズに対応する粒度に合わせられたのが大きな特徴である。すなわちSOAとは「Webサービスをベースとして、ビジネスニーズに合わせて考案されたアーキテクチャ」と位置付けることができる。これらを用いることにより、サービスをネットワーク上で連携させることで素早くシステムを構築し、かつレガシーシステムを再構築することを回避しつつシステム間連携を図ることができるソリューション（解決方法）として注目を集めている。

今後の展望〜 コーディングはなくなるか？

　以上、密結合から疎結合（EAI→Webサービス→SOA）という流れを俯瞰（ふかん）してきた。この流れにより、異機種のシステムを連携させるための技術的な基盤は整備されつつある。これらの技術を用いることで、企業はレガシーシステムを維持しつつビジネスニーズを達成することができるため、ビジネスシステムにおけるコーディングの作業が激減する（特に全面再構築のニーズが下がる）と考える見解がある。

　確かに、システム間の連携という局面ではコーディングする量が減るかもしれないが、システムを使うのはあくまで人間であり、ビジネスニーズによってシステムの振る舞いや位置付けが変化し続けることを踏まえるならば、企業システムが完全自動化されるような時代が訪れるのは当分先になろう。

　ただし、「新しいコードはなるべく書かず、動いているシステムに極力手を加えないでシステム間連携を実現する」というアプローチが普及していくことは予想できる。システム機能を新しく実装することは新たにバグの可能性を埋め込むことと表裏一体であり、安定的な運用を求められる企業向けシステムにおいては信頼性・可用性の確保は急務の課題だからである。

　SOA製品についても現段階ではまだ大規模な普及期に至っていない。企業向けシステムのマーケティング用語にとどまらず、実績と信頼を伴ったビジネス課題を解決するツールとしてのSOA市場での勝負はむしろこれからが本番を迎えることになろう。