Interstage Service Integrator 解説書

1.1.1 背景

■再利用によるシステム構築

企業の統廃合、事業再編、市場競争の激化といった環境を背景に、企業システムにはより柔軟性が求められています。
システムを構築する時間を短縮し、変化するビジネスニーズに早急に対応するため、以下の考え方が注目されています。

• 既存システムやパッケージを再利用し、組合せによるシステム構築で早期稼働を実現
• 組合せを変更するだけで、業務の変化に迅速に対応

早期稼働、変化に強いシステムは、他社優位性を確保するだけでなく、IT投資の削減にもつながります。

■組合せによるシステム構築の問題点

組み合わせるアプリケーションに以下の問題点があるため、簡単にアプリケーションを組み合わせて構築できないのが現状です。

• あるアプリケーションが変更されれば、別のアプリケーションも変更が必要といったアプリケーション間の“密結合”な関係
• ニーズに応じて開発してきた結果による、複数のアーキテクチャの混在化・複雑化・肥大化

■SOAとサービス

組合せによるシステム構築を実現するのがSOA(Service Oriented Architecture 以降、SOAと略します)の考え方の1つです。
SOAでは、組合せの対象となるアプリケーションを“サービス”と呼びます。サービスは、以下を前提に作成されます。

• 外部から呼び出されることを前提に開発されているアプリケーション
• 別のアプリケーションに依存しない“疎結合”なもの
• 開発言語や動作環境にとらわれないインタフェースをもつ

ユーザは、サービスから提供されるインタフェース仕様に従って呼び出すことで、だれでもサービスを簡単に利用できます。

■ESBとEAIの違い

ESB(Enterprise Service Bus 以降、ESBと略します)は、これらのサービス同士を連携するバスです。
アプリケーション統合は、従来のEAI(Enterprise Application Integration 以降、EAIと略します)でも実現できます。
しかし、EAIが真のアプリケーション統合を実現できない理由に、以下が挙げられます。

• アーキテクチャの“ベンダー依存”

連携のためのプロトコルにベンダー独自の技術を利用したことで、ハブ内では連携できても、他社のEAIとは連携できないなどの問題が発生していました。

ESBも、アプリケーションの統合という点では同一のように見えますが、以下の点が異なります。

• “サービス”と呼ばれるアプリケーションを連携
• “標準技術”で作成されたサービスを連携

SOAでは、サービス同士を標準技術で連携しようとしています。連携するための主な標準技術には、以下があります。

• 通信プロトコル
  • JMS(Java Message Service 以降、JMSと略します)
  • SOAP(Simple Object Access Protocol 以降、SOAPと略します)など
• XMLの使用
  • WSDL(Web Service Description Language 以降、WSDLと略します)でのインタフェース記述
  • XSLTでのデータ変換

ESBは、これら標準ベースの技術を採用した、真のアプリケーション統合を実現するミドルウェア製品です。

[図：“作り変え型”から“成長・発展・継承型”システム構築へ]