自動化されたビジネスプロセスをサポートし、オペレーションの可視性を高めることはできるでしょうか？
コストを抑えながら永続的にアプリケーションを接続することはできるでしょうか？
これまでのITへの投資を活用するにはどうすればよいのでしょうか？
ITの柔軟性を向上させ、変化するビジネス要件に適合させることはできるでしょうか？

ITは、長い間これらの課題に直面してきました。これまでアプリケーションとシステムは、あまりの融通の利かなさに悩まされてきました。一度作成されたものを変更することが非常に難しいのです。このような柔軟性の欠如は、スタンドアロンアプリケーションにとっては問題というレベルですが、大規模なビジネスシステムとなると悲惨な事態に発展することも珍しくありません。

しかし今日では、サービス指向アーキテクチャ（SOA）が幅広い相互運用性を達成する機会とともに、ビジネス要件にテクノロジを常に適合させるための柔軟性を提供します。SOAは、特に現在のIT環境の範囲と複雑さを考慮すると、非常に重要な役割を果たすのです。

SOAは、以下のようなメリットを提供します :

• 幅広いアプリケーションの接続性と相互運用性

• ITを容易にビジネスニーズに適合させる。SOAでは、アプリケーションとシステムはモジュールセット、つまり柔軟に組み合わせて自動ビジネスプロセスを作成するための再利用可能なビジネスコンポーネントとして表現されます。

• 既存のアプリケーションとデータの再利用性を強化し、カスタムソフトウェア開発の必要性を最低限に抑える。

• 統合コストの削減

• ベンダによる囲い込みを減らし、移行費用を抑える。

SOAは、GUI、クライアント/サーバ、オブジェクト指向コンピューティングへの移行と同様に、ITにおける非常に重要な転換期です。業界のベテランにとって、サービス指向アーキテクチャの基盤となっている概念は新しいものではありません。今日のSOAは、過去20年間で進化を遂げてきた強力なテクノロジアプローチの集大成と言えます。

W3C Webサービスアーキテクチャワーキンググループは、SOAを「一般に次のような性質を特徴とする分散システムアーキテクチャの形態の1つ」として定義しています :

• 論理ビュー : サービスは、役割によって定義された実際のプログラム、データベース、ビジネスプロセスなどの抽象的な論理ビューであり、通常はビジネスレベルのオペレーションを実行する。

• メッセージ指向 : サービスは、プロバイダエージェントとリクエスタエージェント間で交換されるメッセージの形で形式的に定義されおり、エージェント自体の所有物ではない。

• 記述指向 : サービスは、マシンが処理可能なメタデータで記述される。

• 粒度：サービスは、比較的大きく複雑なメッセージを伴う少数のオペレーションを使用する傾向にある。

• ネットワーク指向 : 絶対的な要件ではないが、サービスはネットワークを介して使用される傾向にある。

• プラットフォームに中立 : メッセージは、インタフェースが提供する、プラットフォームに中立的な標準化されたフォーマットで送信される。

Webサービスは、ルックアップおよび通信サービスを表現する今日最も幅広く普及した重要な標準です。Webサービスは、統一されたサービスモデルと記述（WSDL（Web Services Description Language））、共通のサービスレジストリ（UDDI（Universal Description, Discovery, and Integration））、サービス呼び出し（SOAP（Simple Object Access Protocol））の標準を提供します。

SOA : サービスを結合するためのモデル

SOAは、アプリケーションが機能を公開するためのインタフェースを提供するだけでなく、サービスを結合するアーキテクチャを考慮しなければなりません。Webサービスは、クライアント/サーバモデルとイベント主導型モデルの2つの主要なサービスモデルで定義されます。クライアント/サーバ（RPC形式）サービスは、サーバによって公開されているAPIにクライアントアプリケーションを緊密に結合します。この場合のコントラクトはAPIで、通常インタラクションは同期的に行われます。イベント主導型モデルでは、サービスは受信するメッセージに対応し、応答としてメッセージを発信します。ここでのコントラクトはメッセージで、通常インタラクションは非同期で行われます。

イベント主導型モデルは数々のメリットを提供し、SOAのモデルとしてはクライアントサーバモデルよりも優れています。まず、イベント主導型モデルは疎結合されているため、アプリケーション間の依存性が最小限に抑えられ、優れた柔軟性を得ることができます。細粒度アプリケーションインタフェースの変更に伴う多くの変更に対処するよりも、フィールドが追加された新しいバージョンのメッセージに対応するほうがはるかに簡単です。細粒度インタフェースを変更する場合、単純な変更でもアプリケーション呼び出しの連鎖全体が壊れてしまう可能性があります。一方、メッセージを使用する場合、対話するアプリケーションの独立性を確保することができます。

サービスが成功するには、サービスがサービス作成者以外のユーザにも容易に理解できるものでなければなりません。通常、イベント主導型インタフェースモデルでは、インタフェースはアプリケーションのオブジェクトアーキテクチャのリテラル表現ではなく、自己記述型のXMLビジネスドキュメントです。サービス消費者にとって、自己記述型のドキュメントを理解し処理することは、多数の細粒度オブジェクト、メソッド、その意味を解読するよりもはるかに簡単です。

また、非同期メッセージングはイベントストリームの並行処理を大幅に効率化し、複雑なシステムで特定のサービスが一時的に利用できなくなった場合に回復力を提供します。イベント主導型のインタラクションでは、結果の生成からサービス呼び出しが切り離されます。アプリケーションは、RPCモデルのように他のアプリケーションからの応答を待機するのではなく、イベントが発生したときに対応します。メッセージングベースのイベント主導型アーキテクチャは、メッセージングインフラが提供する回復性の恩恵も得られるため、アプリケーションはシステムおよびネットワーク障害から分離されます。

SOAインフラストラクチャ

アプリケーションとアプリケーション開発プラットフォームによるWebサービスのサポートが当然となった今、焦点はWebサービスの統合の問題に向けられています。サービス間の関係はどう捉えるべきでしょうか？企業内に散在するWebサービスをどのように接続すればいいのでしょうか？サービス間のインタラクションはどのように調整すればいいのでしょうか？サービスの管理、監視はどうすればいいのでしょうか？このような問題に対処するために、サービス自体を提供するアプリケーションプラットフォームよりも優れたSOAインフラの必要性が指摘されています。

エンタープライズSOAの目的は、柔軟で堅牢なインフラを構築し、任意のアプリケーションをいつでも簡単に接続して問題を解決できるようにすることです。SOAは、ビジネスプロセスの変更に応じてサービス間の論理フローの変更に対応するだけでなく、サービスの動的な追加と再構成を即座に実行できなければなりません。

サービス指向のこれらの目標達成を支援するために、SOAインフラは以下をサポートする必要があります :

• 柔軟性 : 企業は、コーディングでなく設定を通じてプロセスやアプリケーション間の関係を変更できなければなりません。

• 異種混在環境 : 一貫したサービスモデルを提供しながら、既存のアプリケーションとサービス化された新しいアプリケーションの橋渡しをする必要があります。

• 分散配備 : サービスは、組織全体に、または組織の境界を越えて配備されます。

• 管理 : インフラは、その内部に配備されたサービスだけでなく、インフラ自体も管理、監視できなければなりません。

これらの要件を直接サポートするのが、エンタープライズクラスの機能を提供するSOAインフラであるエンタープライズ・サービス・バス（ESB）です。ESBは、幅広い統合プロジェクトタイプをサポートできるように設計されています。またアーキテクチャのベストプラクティスを実装し、さらに強化しているため、個別のプロジェクトに最適なことはもちろん、グローバルに拡張することができます。