戻る

SOA

SOA という言葉がにわかに注目を浴びています。

SOA の定義

SOAはService Oriented Architectureの略です。日本では、「サービス志向アーキテクチャ」という訳語が当てられています。最大公約的な意味は、「記述言語で定義された粗粒度のサービスを、共通のインタフェースで粗結合する、分散コンピューティング」といったところです。

ここで、粗粒度というのは、業務プロセス的に意味のある、単一の機能やオブジェクトより大きな単位ということです。サービスと呼んでいるのは、ロジックの詳細に依存せずに、入力インタフェースだけを通して利用可能な、それ自体で動作可能な単位ということです。粗結合というのは、実装の詳細に依存しない、インタフェースに対するメッセージを介した結合ということです。この結合には、オンライン同期処理の場合と、非同期処理の両方が含まれます。分散コンピューティングというのは、複数のサービスを組み合わせることで、業務プロセスを組み立てて実現することを指しています。

SOAの実装の詳細はベンダー各社でまちまちです。最も有力な実装は、通信プロトコル/インタフェース定義としてのWebサービスと、ビジネスフロー定義としてのBPEL (Business Process Execution Language)です。ベンダー各社のJ2EEコンテナ製品は、ESB (Enterprise Service Bus)やMOM (Message Oriented Middleware)を独自に実装し、トランザクション管理機能や自己回復などのシステムレベルの機能を追加することで差別化を図っています。

SOA の背景

SOA は EA - Enterprise Architecture などと同様に、かなりレイヤの高い概念なので、ベンダー各社で実現のための実装の乖離が激しくなってきており、各社のマーケティング用語として使われる意味合いが濃厚になってきました。これは、ちょっと前のオートノミックと同様の流れです。

オートノミック(自律)の場合は、IBM がストレージシステムで、自己修復/自己管理を目標として実装した、Eriza というプロジェクトで火がつきました。IBM では、自社の提唱するオートノミックを、ABLE - Agent Building and Learning Environment に基づく MAPE (Monitor, Analyze, Plan, Execute) ループによって実現される、自己構成、自己修復、自己最適化、自己防御の四つの機能で定義し、システムの発展形態を、基礎、管理、予測、適応、自律の五つのレベルに分けて、段階的に向上していくパスを定義し、自社のOSと各ブランドのミドルウェア製品に順次実装しています。しかし、Oracle を初めとするそれ以外のベンダー各社も、各々で程度の差はあっても、オートノミックを定義して自社の製品に実装しつつあります。

オートノミックが本格実装未満の道半ばの中で、次にベンダー各社が注目したのが SOA です。SOA は 1999 年頃まで遡ることができます。その実装は、いまいち盛り上がらない XML ベースの Web サービスを最右翼とします。J2EE 仕様が 1.4 で成熟して、ようやく使い物になり始めたことと、JCP - Java Community Process を本格的に汲んだ EoD - Ease of Development をテーマとする POJO - Plain Old Java Object の J2EE への取り込みや J2EE 1.5 に対する期待に基づいているのではないかと思われます。

SOA の有効範囲

SOAが注目されるようになった理由として、その要素技術の一つであるWebサービスが成熟化してきたことが挙げられます。

Webサービスでは、WSDL (Web Services Description Language)によって記述されたサービスを、UDDI (Universal Description, Discovery and Integration)によるディレクトリ・サービスに登録し、これをSOAP (Simple Object Access Protocol)を使って探索することで、必要なサービスを提供する取引相手をインターネット上で見つけて呼び出します。

インターネット上で動的に取引先を探すという点は、個人向けサービスではいろいろな試みがなされていますが、企業間取引の分野ではなかなか普及していません。しかし、組織内においてシステムが複雑化してくるにつれ、サービスの部品化と粗結合が必要要件に浮上してきました。

該当するケースとしては、IT導入範囲が単純/単一の範囲にとどまらず、複数の業務フローが連携している組織が挙げられます。特に、数年前のダウンサイジングの流行によって部品点数が急増し、オープン化の普及とベストオブブリードでマルチベンダー化し、障害発生率と管理コストが急増しているようなケースでは、複雑さが飛躍的に高まります。

そのような組織内では、メインフレーム、各種UNIX/Linux、Winodwsサーバが、様々なバージョンで混在しています。そこでは、様々なデータベース、無数のアプリケーションが稼動し、各種ストレージ製品、テープ装置、コントロール・ユニットが接続され、様々なトランザクションが入り乱れることになります。これらが必要になる都度1対1に個別のAPIで接続されていると、新規追加/変更時の考慮事項は多岐にわたり、その複雑さのために管理負荷が高まり、やがて実運用に耐えられなくなるでしょう。

このような組織では、システム全体の複雑性を押さえ込み、全体最適化を図る仕組み作りが急務といえます。その、システム側での、一つの解決策がSOAというアーキテクチャであり、SOAを実現する一つの選択肢がWebサービスです。Webサービスは、オープンな標準であり異機種混合環境を想定していることなどから、SOAを実現するための有力な候補の一つとして取り上げられます。但し、WebサービスはSOAの必要条件ではありません。SOAはアーキテクチャとして設計し、複数の技術を比較して要件に合った最適なものを選択することが重要です。例えば、プロトコルとしてRMI/IIOPや、実行基盤としてMOM製品、トランザクション製品などが考えられます。

SOAとして、業務的に意味のある単位のサービスを、内部ロジックの詳細に依存しない再利用可能な単位でモジュール化し、それらを共通のインタフェースで粗結合することによって、次のようなメリットが期待できます。

戻る

Copyright 2004-2005 SUGAI, Manabu. All rights reserved.
SEO [PR] !uO z[y[WJ Cu