テクノロジー中心で進めると SOA が本来持つメリットを発揮できない ガートナー ジャパン株式会社 ガートナー リサーチ ソフトウェア グループ アプリケーション統合＆ Web サービス担当 リサーチ デレクター サービス指向アーキテクチャ（SOA）は ソフトウェアアーキテクチャである サービス指向アーキテクチャ（SOA）は、多層型の コンピューティングスタイルであり、複数のアプリケー 飯島 公彦 SOA 対応を謳う製品を販売し始めている。SOA 用に複 数種類のテクノロジーが存在し、SOA 用プラットフォ ームとしても複数種類存在するなど、パッケージアプリ ケーションも SOA 対応のものが出始めており、SOA 対 応プロダクトの数は増える一方である。 ション間で、ロジックやデータを、疎結合型で共有する しかし、SOA は、あくまでも、ソフトウェアのアー のに役立つものとして生み出されてきた、ソフトウェア キテクチャについて論じたものであり、テクノロジーや アーキテクチャである。 製品という実装実体そのものを指すわけではない。 1996 年に、ガートナーがサービス指向アーキテクチ ャ（SOA）という言葉を最初に世に送り出した。その SOA の定義 当時すでに、クライアント・サーバ、インターネット、 バッチ、モバイル、企業間 EDI といった多様なコンピ SOA は「業務として完結する機能」としてのサービ ューティングスタイルが増殖しており、複数のアプリケ スと、サービスを要求し利用するサービスコンシューマ ーションでデータやロジックが冗長的に所有されている で構成されるアプリケーションソフトウェアトポロジー など、複雑性が高まり保守性が悪化していた。この状況 であり、サービスとサービスコンシューマは 1 対 1 の疎 を整理し改善するために、データやロジックを共有する 結合関係を持つ（図１参照）。SOA は、インタフェース 必要性がでてきていたが、モノリシックな従来型のアプ の定義から始まり、インタフェース、インタフェースの リケーショントポロジーでは、データを共有することは 実装およびインタフェースコールのトポロジーを軸に、 困難であり、ロジックを共有することはほぼ不可能であ アプリケーショントポロジー全体を構築する。SOA は、 った。 この問題を解決するために、多層型の設計手法とミド ルウェアを使ってプログラムを構造化する、SOA のア プローチが生まれてきた。最近では、SOA の持つ可能 性の広がりから、さまざまな切り口で語られるようにな ってきている。エンタプライズアーキテクチャ（EA） と SOA の関係についても取り上げられることが多くな り、ビジネスプロセスと SOA の関係についても多く語 られるようになってきている。また、ミドルウェアベン ダーをはじめとする、さまざまなカテゴリのベンダーが、 106 サービス 業務としての論理作業単位であるソフト ウェアコンポーネント。公開され確定した インタフェースを直接的に介して、独立に 設計されたコンテキストから、プログラム アクセスが可能である。 サービスの実装 サービス インタフェース サービスコンシューマ （クライアント） ＳＯＡ １対１の疎結合関係を持つ、サー ビスとサービスコンシューマ（クライ アント）から成るアプリケーションソ フトウェアトポロジーである。 インタフェース インタフェース プロキシ ＳＯＡの設計とは、サービスインタフェースと サービス間の相互作用を設計することである 図 1 SOA −インターフェースアーキテクチャ（出典：ガートナー） 2005 Vol.42 No.2 サービスそのものと、サービスを利用するサービスコン シューマという２つのソフトウェアモジュールの間の関 係を取り扱うものである。サービスは、通常、要求／応 サービス コンシューマ （Ｗｅｂ） サービス インタフェース 顧客情報チェック （新規ＳＯＡアプリケーション） 答型で、インタフェースを経由し、名前を使ってアクセ スされる。サービスコンシューマは、サービスインタフ 顧客履歴チェック ェース・プロキシを組み込んだソフトウェアである。 （コンポジット・アプリケーシ ョン：複数の既存システムやラ ッピングされたサービスで構成 される） SOAは、クライアント／サーバ型のソフトウェアスタ イルに似ている。だが、SOAは、従来のクライアント／ 顧客与信チェック サーバモデルとは異なり、ソフトウェアコンポーネント （外部サービス） 間がインタフェースによって分離された疎結合である点 に重点を置き、また、独立したインタフェースを使用す る。SOAの根本的な狙いは、実行時に、サービスとして のソフトウェアを、その内部の詳細を知ることなく再利 図 2 SOA 適用パターン： コンポジットアプリケーション（出典：ガートナー） 用することであり、次のようなメリットが想定されてい 複数のサービスが組み合わさって業務が完成する。特に、 る。そのため、SOAの狙いを実現するためには、インタ 最近の企業において大きな課題となっているのは、既存 フェースの設計が要となるので、SOAは「インタフェー （レガシー）のソフトウェア資産を最大限に活用（再利 ス指向アーキテクチャ」と言っても過言ではない。 用）し（コストを抑制し）ながら、ビジネス上の付加価 値の高いサービスを新しいビジネスロジックとして追加 【SOA のメリット】 し、新旧のソフトウェア資産を融合させて市場の動きに ・ビジネス・ソフトウェアの開発と配備を段階的に行える 敏感に反応しながら、迅速に実装することが不可欠とな ・複数のユーザーで使用されていたビジネスコンポーネ ってきている。 ントを再利用できる ところが、多くの企業では、現状のソフトウェア資産 ・新規のビジネスプロセスを低コストで組み込める の大半が従来のモノリシック型のアプリケーションが占 ・アプリケーショントポロジーが明瞭（保守が容易） めている。そのままでは、業務として組み合わせるため には多大な労力を必要とするだけでなく、変更管理が極 SOA の適用パターン 1 コンポジットアプリケーションを狙え SOA は、その定義として「業務として完結する機能」 めて煩雑になり、変化の激しいビジネスのニーズに追従 できない。こうしたところに SOA を適用することで、 既存のソフトウェア資産をサービスとして再利用するこ をサービスとして実装することから、業務を実現する 1 とと、付加価値を生み出す新規ビジネスロジックや新規 つの IT アーキテクチャであると言える。しかし、現実 サービスとの柔軟な組み合わせが可能となり、単なる再 の業務は、単一のサービスだけで完成するわけではなく、 利用ではなく、新しいサービスとして生まれ変わる。こ 2005 Vol.42 No.2 107 のようにして組み合わせが行われるスタイルをコンポジ PDA、その他の機器からのアクセスに対応する必要が ットアプリケーションと呼ぶ（図２参照） 。 生じている。このため、従来のアプリケーション構築の ※注意 コンポジットアプリケーションの定義：コンポジ ットアプリケーションとは、コンポーネントパーツが異 なる情報モデルを持つ、組み立てられたアプリケーショ ンである。 考え方では、それぞれのクライアント環境ごとに（同じ 処理機能を持つが、異なる）アプリケーションをいくつ も構築する、ということになり、極めて大きな無駄とな る。これを避けるために、SOA の考え方を適用するの さて、サービスを組み合わせるための容易性は、 である（図３参照）。 SOA により向上するが、異なるサービス間でのさまざ まな違い（特に、データの意味上の違い）を吸収したり、 サービスの実行順序制御については、単に SOA で構築 リアルタイムエンタープライズには、SOA だけでなく、 イベント駆動アーキテクチャ（EDA）が必要である しただけでは標準で実装されるわけではない。このため 企業のビジネス活動は複雑であり、多種多様な業務に に、アプリケーション統合や、サービスオーケストレー より構成されている。その業務機能を実装するサービス ション機能を提供するビジネスプロセスマネジメント としてのアプリケーションは、自然発生的に開始され終 （BPM）テクノロジーが必要となる。こうしたテクノロ 了されるわけではなく、注文受け付けなどのビジネスイ ジーは、100 ％ SOA 環境が構築された場合でも必要にな ベントにより起動される。また、業務によっては、1 つ るだけでなく、非 SOA 環境を SOA 環境に移行させる上 のビジネスイベントが複数のサービスを起動すること でも必要である。 も、あるサービスの実行結果とつきあわせた上で、次の 処理を決定するといった、多対多の処理関係が存在する SOA の適用パターン 2 マルチチャネルアプリケーションを狙え 顧客 （セルフサービス） コンポジットアプリケーションは、単一のサービスコ ンシューマの観点からの SOA によるサービスの再利用 性を考えたものと言える。次の SOA の適用パターンと してガートナーが推奨するのは、マルチチャネルアプリ 顧客サービス マネージャー サービスインタフェース コールセンター オペレーター ケーションである。従来、アプリケーションは、クライ アントに基づいて設計されてきた。ターミナル／エミュ レータであれ、X-Winodow であれ、Visual Basic であ れ、Web ブラウザであれ、アプリケーションにアクセ 顧客サービス アプリケーション リセラー 顧客サービス アプリケーション アカウント マネージャー スするクライアントは、基本的に同一（しかも PC 上） であることを想定して構築されてきていた。しかし、昨 今のクライアント機器の多様化にともない、携帯電話、 108 図 3 SOA 適用パターン： マルチチャネルアプリケーション（出典：ガートナー） 2005 Vol.42 No.2 特性を持つイベント駆動型アーキテクチャ（EDA）が、 SOA とあわせて、現実の業務を構築する上では不可欠 サービスフロー 論理作業単位 リアルタイムエンタープライズ: サービス指向とイベント駆動 である（図４参照）。 現段階では、EDA を実現するテクノロジーは、まだ 開発途上と言ってもよいが、今後、急速に進化すること ・疎結合型 ・対話型 ・閉ループ が想定されており、企業は、今後、SOA と併せて理解 イベントフロー を深めるべき対象として念頭におくことが望ましい。 SOA の取組み上の留意点 ・非結合型 ・通知／サブスクリプション型 ・開ループ SOAに取り組む企業は、業務上の必要性を併せ持つこ 図 4 サービスとイベント： リアルタイムエンタープライズアーキテクチャ（出典：ガートナー） とが不可欠である。コスト削減やテクノロジー優先で 場合がある。こうした処理特性には、SOA の 1 対 1 かつ 揮されない。また、IT環境をすべてSOAで構築する必要 疎結合といえども結合関係のあるアーキテクチャでは実 はない。このため、企業は、SOAの適用が望ましいもの 装が難しく、イベントを取り扱う別のアーキテクチャが と、そうでなくてもよいものの見極めが必要である。 SOAの適用に走ると、SOAの本来持つ潜在的可能性は発 また、多くの企業は、SOA の効果を考える際、短期 必要になる。 １つの注文から一連の複数の業務プロセスを構成する （１年程度）でメリットが出ると期待してはならない。 サービスが同時に起動されるという１対多（場合によっ さらに、SOA は、異なる複数のアプリケーション間で ては、多対多）的な連携処理の場合、呼び出し側はあく のサービスの再利用を指向するものであるため、個々の までサービスを「起動」するだけであり、「処理結果の プロジェクト単位での取組みでは、効果が薄く、EA な 返信」を期待しているわけではない。しかも、こうした どといった全社的取組みと連携することが望ましい。特 関係では、呼び出し側と起動される側は業務プロセス上 に、再利用という観点に注目するならば、再利用をすべ での論理的な依存関係はあっても、システムとしての物 きサービスの抽出を、個別プロジェクトの中で取り組む 理的な依存関係は必要ではなく、SOA がサービス間の ことを避け、大きな範囲で取り組むことで、より効果的 関係が疎結合であるのに対して、EDA では非結合が特 で再利用性の高いサービスを導きだすことが可能にな 徴的である。現に多くの企業において、事業部をまたが る。こうした取組みには、IT 部門だけでは限界があり、 る業務連携はバッチ型で実現されている。これは非結合 ビジネス側の積極的な理解と関与が不可欠なのである。 でのイベント駆動型の処理の単純な例の 1 つである。ア ーキテクチャという観点では、こうしたクライアント／ サーバ型の SOA ではない、イベントを中心とした処理 2005 Vol.42 No.2 109
© Copyright 2024 Paperzz
