• Web Services とは、ネットワーク (主に World Wide Web) を通して記述、公表、配置、および起動することのできる自己完結型モジュラー・アプリケーションです。
• Web Services は 3 つの役割 (サービスの提供者、サービスの要求者、サービスの仲介者)と3 つの基本的なオペレーション (公開、検索、バインド) を記述します。各ネットワーク・コンポーネントは、これらの役割のいずれか1 つを果たすこともあれば、複数の役割を兼ねることもあります。
• Web Services は 2 つの別個の文書によって記述されます。このうち Well-DefinedService (WDS) 文書は、サービスのオペレーション以外の情報を記述します。たとえば、サービスのカテゴリー、サービスの説明、有効期限日、サービスを提供した会社に関するビジネス情報(会社名、住所、連絡先) などの情報です。また、Network-Accessible ServiceSpecification Language (NASSL) 文書はサービスのオペレーションに関する情報を記述します。たとえばサービス・インターフェース、実装についての詳細、アクセス・プロトコル、接続エンド・ポイントなどの情報です。
• Web Services アーキテクチャーを実装すれば、環境に関する一連の前提条件 (たとえば認証メカニズム、請求手続きなど)を構成して対話を制御および管理することによって、サービス・モデルのセキュリティーや品質を改善することができます。
• Web Services は、従来の静的バインディングではなく、機能依存のルックアップから派生したアプリケーションの中に実行時に動的に組み込むことができます。こうした動的な性質をもつコラボレーションのおかげで、プラットフォームやプログラム言語、それに通信メカニズムからも独立した実装を実現しながら、まったく革新的な製品、プロセス、バリューチェーンを作成することが可能になります。

はじめに

分散コンピューティングに関するこれまでの試み (CORBA、Distributed Smalltalk、JavaRMI) では、システム内のさまざまなコンポーネントの結合の度合いが強すぎて、小さいオーバーヘッドで、どこでも利用可能なインターネットB2B e-business で適用するには効率的ではありませんでした。こうしたアプローチでは、さまざまな組織のビジネス・システム間であまりに多くの合意事項やコンテキストの共有が求められるため、オープンな、小さいオーバーヘッドの B2B e-business 用としては信頼性が欠けていました。

同時に、アプリケーション分野において、固い結び付きの一体構造システムから脱却して、ゆるやかな結び付きで動的にバインドされるコンポーネントからなるシステムを目指す傾向が見られます。こうした原理にのっとって構築されたシステムは、次世代のe-business システムの主流になると思われます。次世代の e-business システムにとって、成功のための最大のかぎは柔軟性だからです。今後のアプリケーションは、実行時に動的に検出され配備される複数サービスによって基本的に構成される(サービスのジャストインタイム統合) と我々は考えます。 各企業が e ポータルや e マーケットプレイスを活用し XML などの新しいテクノロジーを採用することにより既存の IT アプリケーションをますます Web に投入するようになると、サービス(アプリケーション) の統合は、次世代 e-business の革新的技術となるでしょう。

この記事で説明する Web Services の概念は、Web における次世代 e-businessアーキテクチャーがどのようなものになるかについての当チームの見方を反映しています。WebServices アーキテクチャーは、複数サービスをベースとする、動的で、ゆるやかな結び付きのシステムを生成する原理を記述するものであって、特定の実装を記述するものではありません。WebServices アーキテクチャーが記述する役割やオペレーションなどの実装としてどんな技法を選択するかによって、WebServices をインスタンス化する方法はいくつでも考えられます。

Web Services を設計するときには、さまざまな環境要因も考慮に入れなければなりません。たとえば、サービスの仲介者にとってのセキュリティー要件は、展開環境によってさまざまに異なるでしょう。ほとんどのイントラネット展開では最小限のセキュリティー要件しか求められませんが、重要なB2B (企業間) トランザクションが実行されるような環境では、もっと高度なセキュリティーが必要です。1つのアプローチとして、セキュリティーのリスク評価の観点を採用し、その環境のセキュリティー・インフラストラクチャーに応じて、仲介者がさまざまな異なるレベルの情報を提供するように設計する方法があります。(WebServices のセキュリティー考慮事項についての詳細は、「付録」を参照してください。) Web Services ツールキットの今後のリリースでは、これらのセキュリティー考慮事項が部分的または全面的にサポートされる予定です。

上に戻る

新しいアーキテクチャーのアプローチ

従来のシステム・アーキテクチャーでは、システム内のさまざまなコンポーネントをどちらかというと「固くて砕けやすい」方法で結び付けてきました。Web指向のシステムを含む膨大な数の IT システムが、互いに固い結び付きのアプリケーションやサブシステムによって構成されるという特徴があります。IBMCICS トランザクション、データベース、レポートなどは、データ構造 (データベース・レコード、フラット・ファイル)を使用して固い結び付きで構築されています。

このような一体構造のシステムは、変化に対してもろいものです。サブシステムのいずれか1 つの出力が変更されただけで、しばしばシステム全体に障害が発生します。1つのサブシステムの実装を新しいものに切り替えると、古い実装に静的にバインドされていた(そして古い実装の副次作用に意図せずに影響されていた) コラボレーションに障害が起こります。こうした状況は、技術力と人海戦術によってある程度乗り切ることができます。しかしビジネス取り引きの規模、需要、数量、速度が増すにしたがって、このアーキテクチャーのもろさはますます顕著になります。これらの要因の1 つでも飛躍的に上昇した場合には、システムのもろさはもはや危機的なレベルに達します。Webサイトが利用できない (または応答がない)、新しい製品やサービスを流通させるためにはスピードが不十分、新たなビジネス機会に迅速に移行できない、競争相手の脅威にさらされる、といった事態を招きかねません。IT組織の設計者たちは、固い結び付きに足を取られてこうした変化に対応できません。Webのダイナミックな世界では、こうしたもろいアーキテクチャーは受け入れられないのです。

アプリケーション設計の現在のモデルに代えて、変化への対応性に富むシステムを可能にする、もっと柔軟なアーキテクチャーを開発しなければなりません。

上に戻る

Web Services

Just-in-Time (ジャストインタイム) 統合

Web Services アーキテクチャーは、次世代の e-business アーキテクチャーの背景となる諸原理を記述し、システムの考え方としてオブジェクト指向システムからサービス統合型システムへの移行を促します。WebServices システムは、コンポーネントの結合解除および動的バインドを有効な形で促進します。システム内の各コンポーネントは振る舞いをカプセル化し、ネットワーク上で共同作業する他のコンポーネントに向けてメッセージ機能API を公表します。この意味で、システムを構成するコンポーネントはすべてサービスなのです。コラボレーションを動的にバインドするためにサービスを検出するアプリケーションによって、複数のサービスが配備されます。WebServices はサービス指向の新しいアーキテクチャー・アプローチを反映しています。その基礎となっているのは、ネットワーク内で利用できるサービスを検出し調和させることによって、複数アプリケーションをバインドすること、(つまりアプリケーションのジャストインタイム統合) の概念です。

Web Services のアプローチの場合、アプリケーション設計とは、特定の機能を実行するためのネットワーク・サービス機能を記述する行為であり、複数コラボレーターの調和を記述する行為です。実行時において、アプリケーション実行とは、コラボレーター要件を検出機構への入力として変換し、適切なサービスを提供できるコラボレーターを見付けて、そのコラボレーターのサービスを呼び出すためにコラボレーターへのメッセージ送信を調整することを指します。こうした新しいアプリケーションは、検出およびコラボレーションを行う複数サービスからなる集合体を形成するため、それらのアプリケーション自体がサービスになります。

Web Services とは何か

Web Services とは、ネットワーク (主に Web) を通して記述、公表、配置、および起動することのできる自己完結型モジュラー・アプリケーションです。

Web Services アーキテクチャーは、オブジェクト指向によって分析や設計を行う方法、および、コンポーネントの組み合わせによってe-business ソリューションのアーキテクチャー、設計、実装、配置を行う方法を、論理的により一層発展させたものです。これまでのアプローチはいずれも、大規模システムの複雑さに対処できることが実証されてきました。WebServices では、一部のオブジェクト指向システムと同様に、カプセル化、メッセージ送信、動的バインド、サービスの記述と照会などの基本概念を採用しています。さらに、WebServises の基礎となるのは、すべてのものがサービスであり、ネットワーク上の他のサービスが利用できるAPI を公表し、実装の詳細をカプセル化するという概念です。

上に戻る

Web Servises のコンポーネント

サービス指向環境では、以下のような活動が必要です。

1. Web Servises を作成し、そのインターフェースと呼び出し方式を定義する必要があります。
2. Web Servises を、1 つまたは複数のイントラネット・リポジトリーまたはインターネット・リポジトリーに公表して、潜在的なユーザーがこれを検出できるようにする必要があります。
3. Web Servises を配置して、潜在的なユーザーがこれを呼び出すことができるようにする必要があります。
4. Web Servises が呼び出されて、何らかのサービスを提供する必要があります。
5. Web Servises が利用できなくなった場合、または不要になった場合には、公表を取り止める必要があるかもしれません。

そこで、Web Servises アーキテクチャーでは公表、検出、およびバインドの 3つの基本的なオペレーションが必要になります。サービスの提供者は、サービスの仲介者に向けてサービスを公表 します。サービスの要求者は、サービスの仲介者を利用して必要なサービスを検出し、それを自らにバインド します。このような概念が、下の図に示されています。

Web Servises アーキテクチャーにとって、サービスを記述するメカニズムが 1つの重要な要素となります。このアーキテクチャーのための完全な記述方法は、2つの別個の文書、つまり Network Accessible Service Specification Language(NASSL) 文書、および Well-Defined Service (WDS) 文書の中に含まれています。NASSLは、ネットワーク・ベースのサービス用の、XML に基づく Interface DefinitionLanguage (IDL) です。NASSL はたとえばサービス・インターフェース、実装についての詳細、アクセス・プロトコル、接続エンド・ポイントなど、WebServises のオペレーションに関する情報を記述します。WDS 文書は、たとえばサービスのカテゴリー、サービスの説明、有効期限日、サービスを提供した会社に関するビジネス情報(会社名、住所、連絡先) など、サービスのオペレーション以外の情報を記述します。WDS文書とそれに対応する NASSL 文書とは、互いに補完的です。この 2 つの文書を一緒に使用してサービスの完全な記述を指定することにより、サービスの要求者はサービスを検出して呼び出すことができます。

Web Servises アーキテクチャーでは、構成やネゴシエーションが可能な環境に関する一連の前提条件のセットを使って、すべてのコラボレーション(共同作業) を制御することができます。環境の前提条件とは、サービス呼び出しの前に作動可能になっている必要のある、機能とは無関係のコンポーネントまたはインフラストラクチャー・メカニズムです。たとえば、特定の通信メカニズム(HTTPS や IBM MQSeries) の使用、サード・パーティーによる特定の監査サービスや請求手続きサービスの使用などがあります。(それ自体、サービスとして実装されることの多い)これらのコンポーネントは、必要なサービスが実際に呼び出される前に配置されなければなりません。

各サービスは、そのサービスが指定する環境のあらゆる前提条件に適合する限り、多数の実装をサポートすることができます。たとえば、サービスによっては、通信層の選択、請求手続きサービスの選択、その他のオプションが可能な場合があります。サービスの要求者は、環境の前提条件を満たすためにどんな実装を使用するかについて、ネゴシエーションつまり選択することができます。WebServises アーキテクチャーにおいて、両方のコラボレーターが求めるような、セキュリティーに優れ、信頼性のある、安定したコラボレーションが実現するかどうかは、環境前提条件にかかっています。

上に戻る

Web Servises の利点

Web Servises アーキテクチャーを使用すると、次のような利点があります。

• 必要な共通理解を最小限に抑えることによって、相互運用性が高まる

  サービスの提供者と要求者の間で最低限必要とされる共通理解は、XML ベースのインターフェース定義言語(NASSL)、XML ベースのサービス記述 (WDS)、およびコラボレーションやネゴシエーションのプロトコルのみです。相互運用性の実現にどうしても必要な部分を最小限に抑えることによって、共同作業するWeb Servises は本当の意味でプラットフォームや言語から独立して実行することができます。必須部分を最小限に抑えることによって、さまざまに異なる多数のインフラストラクチャーに基づくWeb Servises の実装が可能になります。

• ジャストインタイム統合が可能になる

  Web Servises でのコラボレーションは、実行時に動的にバインドされます。サービスの要求者は必要なサービスの機能を記述し、サービス仲介者のインフラストラクチャーを利用して、ふさわしいサービスを見付けます。必要な機能をもつサービスが見付かると、そのサービスのNASSL 文書からの情報を使ってそれがバインドされます。

  動的なサービス検出と呼び出し (公表、検出、バインド)、およびメッセージ指向のコラボレーションによって、一連のアプリケーションがゆるやかな結び付きで統合され、新しいアプリケーションやサービスのジャストインタイム統合が可能になります。こうして、自己構成型で、適応性に富み、個々の障害点のより少ない堅牢なシステムが実現します。

• カプセル化によって複雑さが軽減される

  Web Servises のすべてのコンポーネントはサービスです。重要なのはサービスを実装する方法ではなく、サービスの振る舞いのタイプです。サービスによってカプセル化される振る舞いを記述するメカニズムは、WDS文書です。

  カプセル化は次のような重要な役割を果たします

  • 複雑さの軽減。システムの複雑さが軽減され、アプリケーション設計者は、呼び出そうとしているサービスの実装の詳細について心配する必要がありません。
  • 柔軟性と拡張容易性。同じタイプのサービスのさまざまな実装、つまり複数の同等サービスを、実行時に置き換えることができます。
  • 拡張性。同じサービス記述の新しいサービスを提供することによって、振る舞いがカプセル化されて拡張されます。

• レガシー・アプリケーションの相互運用が可能になる

  レガシー・アプリケーションを NASSL 文書および WDS 文書でラップ してサービスとして公表する方法で、WebServises アーキテクチャーはそのようなアプリケーション間の相互運用を簡単に実現します。さらに、セキュリティー、ミドルウェア、通信などを扱うテクノロジーをラップして、それらのテクノロジーをWeb Servises の環境前提条件として利用することもできます。LDAP などのディレクトリー・テクノロジーをラップして、サービス仲介者にすることもできます。

  サービスが下位レベルのシステム (たとえば通信層) をラップすることによって、アプリケーション・プログラマーは低レベルのプログラムを行わなくてもよくなります。こうしたサービスのおかげで、バーチャル企業は、さまざまな異種システムを必要に応じて(http ベースの通信で) 結合したり、ある 1 つの方法で管理された仕組みに参加することができ、他の通信メカニズム(たとえば MQSeries) がより高度な機能を提供することができるようになります。

  このような例に、企業合併があります。合併後の企業は、さまざまな異種 IT システムやビジネス・プロセスを統合する必要があります。サービス指向のアーキテクチャーを利用すれば、こうしたシステムを非常にスムーズに統合することができるでしょう。別の例として、普及しつつあるコンピューターを旅行産業と組み合わせることもできます。メインフレームに大きく依存する旅行アプリケーションをラッパーによってサービスとして公表し、サービス指向環境でさまざまなデバイスから利用できるようになります。既存の環境を阻害することなく、新しいサービスを作成して動的に公表し、検出されるようにすることができます。

上に戻る

要約

Web Servises は、e-business の次の発展段階です。Web Servises の出発点となった考え方は、すべてのものがサービスであり、ネットワーク上でメッセージ機能を利用して動的に検出および調整できるということです。

Web Servises アーキテクチャーでは、各コンポーネントがサービスであると見なします。そのようなサービスは振る舞いをカプセル化し、APIを介してネットワーク上で振る舞いが呼び出されるようにします。これは、オブジェクト指向の論理(カプセル化、メッセージ機能、動的バインド、反映) を e-business の分野に発展させたものです。

Web Servises における基本的な役割には、サービス提供者、サービス要求者、およびサービス仲介者があります。これらの役割は、公表、検出、バインドの3 つのオペレーションを行います。オペレーションは環境の前提条件によって調整され、セキュリティー、ワークフロー、トランザクション、請求手続き、サービス品質、サービス・レベルの合意などの要素が導入されます。サービス記述言語のメカニズムは、WebServises の基本的運用にとって重要です。Web Servises の完全な記述方法は、2つの別個の文書、つまり Network-Accessible Service Specification Language(NASSL) 文書、および Well-Defined Service (WDS) 文書の中に含まれています。

Web Servises アーキテクチャーの利点には、次のようなものがあります。

• 必要とされる共通理解の幅を最小限に抑えることによって、相互運用性を高める
• ジャストインタイム統合を可能にする
• カプセル化によって複雑さを軽減する
• レガシー・アプリケーションの相互運用を可能にする

上に戻る

付録: セキュリティーおよび信頼性の問題

Web Servises アーキテクチャーのセキュリティーについて論じるとき、オープンかつ動的なWeb 環境でサービスを検出して実行する新しいモデルを受け入れるためには、セキュリティー というものに対する私たちの従来の理解を変える必要があるでしょう。サービス指向アーキテクチャーにおけるセキュリティーの目標は、異なる役割の間で信頼性のある対話を行えるようにすることです。セキュリティーを攻撃からの保護と定義するならば、WebServises アーキテクチャーは予想される一連の攻撃を識別して、Web Servisesの対話を攻撃から守る方法を提案します。信頼性に関して言えば、2 つの主体がリスクを理解したとき、つまり、可能性のある攻撃および自分たちの受る被害について把握し、ビジネス取り引きを行ううえでどんな対策や安全策を講じるかについて合意に達したとき、信頼性が確立されたと見なすことができます。

攻撃を察知して対応策を講じるうえで難しいのが、新たな攻撃が次々と登場するいたちごっこの状況、つまり、何らかの対応策を考え出しても、それに対する新たな攻撃が編み出されるという循環です。しかだって、予測に基づいた対応策を取る必要があるかもしれません。私たちが設計するシステムにセキュリティーを導入しようとするとき、可能性のある、ありとあらゆる攻撃形態や対応策が実際に登場するのを待つわけにはいきません。WebServises アーキテクチャーでセキュリティーを実現しようとするとき、既存の攻撃やそれに対する対策案をどのように把握して文書化するかがまず課題となります。WebServises アーキテクチャーは、現状の背後にある考え方をつかんで、さまざまなレベルのセキュリティー機構を柔軟に実装し、既存のミドルウェアと新しいセキュリティー機構との統合における制御点を維持しようとします。セキュリティー対策の進歩は新しい経済の発展にとって重要です。しかし経験が実証するところによると、ある実装が成功するためには、設計や運用が簡単で、広く普及し、コスト効率的でなければならなりません。さもなくば、人々はそれを使わないでしょう。どう高く評価しても、非効率的な実装としか言えません。

攻撃対象となりうる、対応策を講じる必要のある分野には、次のようなものがあることがわかっています。

• 仲介者、要求者、提供者の間で実行時に共有される情報のセキュリティー
• 実行時に展開されるネットワークのセキュリティー
• 設計時の、プログラミング・モデル (API、スケルトン、スタブなど) のセキュリティー

設計時のアプリケーション・セキュリティー・モデルの問題に加えて、アプリケーション開発環境自体の別の種類のセキュリティー問題が存在します。これは、実行時コンポーネントと設計時コンポーネントとの間にセキュリティー上の不調和を生み出します。また、この他の要件として、WebServises は単純で、オープンな標準の上に成り立ち、拡張可能でなければなりません。これら3 つの要件は、何か新しいものが開発されるときにセキュリティー上の目標として常に掲げられます。既存のセキュリティー・プログラミング・モデルおよびメカニズムを新しい設計の中に取り入れるのは困難です。

サービスや代行モデルに対するアクセス制御に関して何らかの決定を行う必要があり、その決定内容をアプリケーション内で実現する必要があります。そのためのツールはアプリケーション開発環境の中に存在し、WebServises アーキテクチャーには含まれませんが、広い意味で B2B 環境に含まれることになるでしょう。ツール化によってアクセス制御のロジックをアプリケーションに追加することで、設計時の問題の一部に対処できるかもしれません。しかし、従来のすべての状況に対処するのは不可能でしょう。アクセス制御の決定のためにサービス要求者が提供しなければならないあらゆる情報をサービス提供者と要求者の間でやり取りするとき、サービス提供者が前提条件セクションを使用することを、当チームは推奨します。

仲介者を設計するとき、次のようなアクセス制御モデルが可能です。

無節操な仲介者 - 要求者や公表者の認証検査をまったく行わない仲介者です。仲介者はデータ・リポジトリー内の情報への公衆アクセスを提供し、データが正しいかどうかについて何らの保証もしません。このタイプの実装に対する攻撃には、サービス要求者または提供者が偽名を使うこと、許可されないデータ改ざん、情報の開示、サービス妨害(サービス拒否攻撃)、およびアクションの否認があります。

認証された仲介者 - 要求者と公表者の両方を認証する仲介者です。仲介者は、情報にアクセスしようとしているのが誰かに関して、あらかじめ得た情報に従って決定を下すことができ、自らの保管する情報に対するアクセス制御を実施することができます。このタイプの実装に対する攻撃には、サービス要求者または提供者が偽名を使うこと、許可されないデータ改ざん、情報の開示、サービス妨害(サービス拒否攻撃)、およびアクションの否認があります。通常、このタイプの仲介者は、サービス要求をHTTPS プロトコルで呼び出し、SSL を使ってエンティティー認証を行うための要件を実装します。また、メッセージ交換の一部として定義されたXML 文書の署名を有効にするために、XMLDSIG 用のパーサー・サポートを組み込むこともあります。

完全な権限を与えられた仲介者 - 許可パラダイムを実装し、各データ項目のアクセス情報を保管します。このタイプの仲介者は各項目の所有権を確定し、許可された主体のみがデータを変更できるという要件を実施します。また、特定の情報に対して要求者の特定のサブセットのみがアクセスできるようにする、よりきめの細かい許可エンジンを実装することもあります。このタイプの実装に対する攻撃には、サービス要求者または提供者が偽名を使うこと、許可されないデータ改ざん、情報の開示、サービス妨害(サービス拒否攻撃)、およびアクションの否認があります。通常、このタイプの仲介者はHTTPS を介してサービスを提供し、SSL を使ってエンティティーを認証し、メッセージ交換の一部として定義されたXML 文書の署名を有効にするために XMLDSIG 用のパーサー・サポートを実装します。またTivoli/Dascom のようなミドルウェア・インフラストラクチャーや AZN API を使って、企業内のアクセス制御決定を実施します。

参考文献

• Web Servises についての詳細は、The Associated Press、The New York Times (無料の登録が必要)、およびThe San Jose Mercury News のニュース項目>でご覧いただけます。
  
  
  
  
• Web Servises のツールキットWeb Services Toolkit Version 1.2 には、次のような機能があります。
  • IBM WebSphere Application Server バージョン 3.5 のサポート
  • Linux のサポート
  • Apache Xerces 1.1.3 および SOAP 2.0 への移行
  • 資料の改善
  更新されたこのバージョンには、次のような機能もあります。
  • Web Services Description Language (WSDL) のサポート
  • Universal Discovery Description & Integration (UDDI) API のサブセット
  • Advertisement and Discovery of Services (ADS) のサポート
  • 新しい Web Servises 作成ツール
  
  
  
  
  

著者について

この記事を評価する

コメント

上に戻る

目次

• はじめに
• 新しいアーキテクチャーのアプローチ
• Web Services
• Web Servises のコンポーネント
• Web Servises の利点
• 要約
• 付録: セキュリティーおよび信頼性の問題
• 参考文献
• 著者について
• コメント