Insider's Eye Webサービスの新実装「Indigo」 サービス指向アーキテクチャをメインストリームに ――　Webサービスで新旧システムの統合化が容易に　―― Greg DeMichillie 2004/07/10 Copyright (C) 2004, Redmond Communications Inc. and Mediaselect Inc.

本記事は、（株）メディアセレクトが発行する月刊誌『Directions on Microsoft日本語版』 2004年7月15日号 p.28の「Webサービスの新実装「Indigo」 サービス指向アーキテクチャをメインストリームに」を、許可を得て転載したものです。同誌に関する詳しい情報は、本記事の最後に掲載しています。

　MicrosoftのWebサービス標準の重要な実装である「Indigo」（コード名）の活用で、同社は特にWebサービスを利用する分野において、サービス指向アーキテクチャ（SOA）が本格的に普及することを期待している。Indigoは共通のWindowsインフラを提供し、新しいWebサービスの構築や既存アプリケーションとの統合化を容易にする技術だ。

　またIndigoは、ASP.NETやCOM+ Enterprise Servicesといった既存のWebサービス環境用の共通インフラとしても機能する。それにより開発者は、選択したプログラミング環境に関係なく、一貫したWebサービス機能を構築することが可能になる。

　今日、多くの組織では、OSやミドルウェア・プラットフォームを超えてアプリケーションやシステムを統合し、コストダウン図る動きが顕著だ。アプリケーションが統合できれば、一方のシステムから他方のシステムへ情報はダイレクトに転送され、効率性と処理速度が向上し、人手によるデータの入力や再入力で発生するエラーは削減される。加えて、重要なビジネス・ロジックを単一のアプリケーションに集中できる場合もあり、冗長性を減らして合理化することが可能だ。

　SOAでは、キー・アプリケーションはすべてWebサービス・フロントエンドを搭載し、標準インターネット・プロトコルをベースにほかのアプリケーションとXML形式のメッセージで通信する。すなわちSOAは、共通の通信環境を可能にするWebサービス標準とプロトコルを利用して、多様なアプリケーションと技術の統合化をシンプルに実現するものだ（下記の「サービス指向アーキテクチャの基本原理」を参照）。

サービス指向アーキテクチャの基本原理 　サービス指向アーキテクチャ（SOA）では、すべてのキー・アプリケーションがWebサービス・フロントエンドを搭載し、標準インターネット・プロトコルをベースにほかのアプリケーションとXMLメッセージでやりとりする。 　 SOAの目的は、これまでIBMやMicrosoft、そのほかのベンダが努力してきたにもかかわらず、結局、捕らえどころのなさだけが証明されたアプリケーションの統合化だ。アプリケーション統合の最終目標は、システム間におけるデータ転送プロセスの自動化によるビジネス・トランザクションの時間とエラーの削減であり、ビジネス・ロジック（在庫管理などのルール）を単一のアプリケーションに組み込み、ほかのアプリケーションからアクセスできるようにして、ITの効率性を改善することだ。 　こうしたニーズに対応するため、ベンダ各社はさまざまな分散オブジェクト技術を投入してきた。例えば、MicrosoftのDistributed Component Object Model（DCOM）、あるいはIBMやIonaが共同開発したCommon Object Request Broker Architecture（CORBA）などだ。 　 DCOMやCORBAはどちらも、アプリケーション・コンポーネントの統合に用いた技術はアプリケーションの統合化にも利用できるという仮説からスタートしている。これらの技術によって、アプリケーション内のコンポーネントがほかのアプリケーション内のコンポーネントを起動できるようになった。しかし、ある問題がSOAの重要な教義として浮上したとき、それに対応することができなかった。それは境界問題だ。 　アプリケーションの境界にはいくつかの形状がある。 論理的境界：ユーザーの認証で2つのアプリケーションが相互に相手方を信頼しているか否か、あるいは同じOSを共有しているか否かなど。 物理的境界：2つのアプリケーションを接続するネットワークの信頼性や遅延など。 　DCOMやCORBAは、こうした境界を開発者から見えなくすることを目指した。それによって当初は問題を単純化できたが、予期せぬ結果を引き起こしたのはコードだった。完全に制御された環境では非常にうまく機能したものの、異なるOS上で実行されるアプリケーションを統合しようとしたとき、あるいはアプリケーションどうしを接続するネットワークが急に速度低下したり、信頼性を失ったりすると、コードは正常に機能しなかった。 　対照的に、SOAはアプリケーション境界を考慮したいくつかの重要な原則に基づいている。 アプリケーション境界を意識したSOAの原則 ●コードの共有ではなく、メッセージングとスキーマで統合 　SOAでは、アプリケーションが利用するOS、ミドルウェア・プラットフォーム、オブジェクト技術に関して、いかなる仮定も持たない。その代わりに、サービスは共有するデータや、あらかじめ決められたパターンの交換メッセージに対して、共通のフォーマット、スキーマを定義する。 　例えば、製造業者と部品供給業者は、発注を定義するスキーマと発注の開始、確認に用いるメッセージ・パターンで合意する必要がある。発注開始のメッセージを受け取った供給業者は、そのリクエストを自社のERPシステムや請求システムのフォーマットに自由に変換できる。 　概念的には一般の電子データ交換（EDI）システムと似ているが、SOA（特にWebサービス）の狙いは、これまで高価で時間のかかったタスクを、XMLメッセージ・シンタックスやインターネット・プロトコル群を用いて、技術的にシンプルで、より自動化かつ標準化されたものにすることだ。 ●サービスは自立的 　自立的なサービスとは、独立的に作成、構築されるだけでなく、外部のシステムに依存せずに機能を実行し、自己完結的な機能を提供するものだ。 　例えば、請求サービスは注文された品が倉庫から出荷されたとき、顧客に正しく請求書が発送されるように出荷サービスと連携しているが、いずれのシステムも他方のリクエストを作成するために自分の作業を中断することはない。 　こうしたレベルの独立性は、サービスどうしが疎結合で、通信は非同期であることを示している。さらに自立的なサービスは、健全なレベルで相互に懐疑的だ。例えば、請求サービスはクライアントが外部のエンティティによって認証済みであっても、請求リクエストを処理する前に、必ず独自に認証チェックを行う。 ●ポリシー・ベースの互換性 　サービスは、IndigoやVisual Studioなどのツールのフレームワークに対応してサービス接続プロセスを自動化するために、それぞれの要求項目に関する十分な情報を公開する必要がある。 　例えば、クライアントに自己証明やデータ暗号化のためにX.509認証の添付を求めるサービスは、概要説明の一部として、その情報を公開しなければならない。そうすれば開発ツールやフレームワークは、ランタイムにそれらの情報を読み込み、自動的に適切な認証を添付したり、メッセージを暗号化することができる。 　こうしたポリシー・ベースの互換性では、状況が変化した場合でも、サービスやクライアントのコードを書き換えることなく、要求項目を変更することが可能だ。

なぜIndigoが重要なのか？

　IndigoはAPIとOSサービスのセットでSOAをサポートし、開発者がWindows上でWebサービスを活用したり、構築するときに必要となる基本機能を提供する。例えば、XMLメッセージを送受信するためのAPIや、メッセージのセキュリティを確保するためのAPI、あるいは信頼性のない転送プロトコル上で確実にメッセージをやりとりするためのAPIなどだ。

　SOAが開発された最大の理由は、相互運用性の実現にある。そのためIndigoは、いわゆるWS-＊標準と呼ばれるWebサービス・メッセージングの新しい業界標準を実装している（下記の「WS-＊が標準を定義する」を参照）。

WS-＊仕様が標準を定義する 　Indigoは、Webサービスに関連するいくつかのプロトコルと仕様を実装している。それらの仕様のほとんどは、MicrosoftがBEAやIBM、VeriSignなどのキー・パートナー数社と共同で開発したものだ。 　WS-Securityなどは、Web Service Interoperability Organization（WS-I）やOrganization for the Advancement of Structured Information Systems（OASIS）に承認されている。そのほか、承認待ちの仕様や現在開発中のものもある。 　こうした仕様の名称は、主に“WS-”を接頭語として用いているため、全体を総称して“WS-＊”と呼ばれる。また“WS-star”、あるいは“WS-splat”と発音されることもある（主な仕様のリストは、Directions on Microsoft 日本語版 2003年11月号「Webサービス仕様開発がわずかに前進」を参照）。 　WS-＊仕様はすべて2つの基本仕様の上に構築されている。XMLとSimple Object Access Protocol（SOAP）だ。XMLもSOAPもWebを利用したアプリケーション統合の基盤を提供するが、出来上がったシステムはベースとなるインターネット以上の信頼性は望めない。またページを正しくロードするためには、ユーザーがブラウザを定期的に再起動しなければならない。もしリクエストが数百万ドル単位の発注だとすれば、こうした“リフレッシュ”など到底受け入れることはできない。 　具体的にいえば、IT組織には次のような必要不可欠なビジネス要求がある。 アクセスの認証とデータの暗号化を含むセキュリティ 不安定な接続でも保証されるメッセージ配信 複数のデータベースにまたがる連携トランザクション能力 　ITシステムを開発する場合、ほとんどの組織はIBMのWebSphere MQ（旧MQ Series）やMicrosoft Message Queuing（MSMQ）、あるいはTibcoのEnterprise Message Serviceなどを利用して、こうした内部システムの問題を解決する。しかし、これらの技術は通常、相互運用することができず、またインターネット経由で利用することを前提に設計されていない。 　Microsoftや同社のパートナーは、そうしたビジネス要求をインターネット上でサポートする共通のプロトコル・セットを定義すれば、今日の困難で時間のかかるタスク、すなわち組織内部で、あるいはインターネット接続したパートナー間において、異なるプラットフォーム上で実行される新旧アプリケーションを統合化することを簡単に実現できるようになると期待している。

　Indigoはまた、これまでMicrosoftが取り組んできたいくつかの分散コンピューティング技術、例えばASP.NETのWebサービス機能（ASP.NETのデフォルトの拡張子から“ASMX”と呼ばれる）や.NET Remoting、COM+Enterprise Servicesなどを統一するものとなる。

　こうした技術は、いずれも異なるWebサービス標準をサポートし、それぞれの機能へのアクセス方法が異なる。例えば、開発者にとって最もシンプルなプログラミング・モデルはASP.NETのWebサービス・サポートだ。Visual Studioでサポートされているこのモデルであれば、開発者はWebサービスとして起動できるコードを簡単に記述できる（XMLやSOAPリクエストを開発者が慣れ親しんだ形式に自動変換する）。

　しかし、ASP.NETは暗号化をHTTPSに依存し、Webサービス標準のWS-Securityをサポートしていない。これは多くの組織にとって不都合だ。なぜなら、HTTPSは送信側から受信側へのメッセージ全体を暗号化するため、コンテンツの内容に応じて負荷分散するために異なる場所へ転送することができない。

　Microsoftでは、既存のシステムをIndigo上に再配置することで、それらの機能セットを統一し、開発者がどのようなプログラミング・スタイルを選択しようと、共通の完成されたWebサービス標準にアクセスできるようになることを期待している。（Indigoが異なるサービス・プログラミング・モデルをサポートする仕組みについては、下記の「Indigoのプログラミング・モデルとホスト」を参照。）

Indigoのプログラミング・モデルとホスト 　Indigoはミドルウェアとして機能し、プログラミング・モデルやコードをホストする実際の環境を超えて、WS-SecurityやWS-ReliableMessagingといった主要なWebサービス標準を実装した共通のWindowsインフラストラクチャを提供する。 Indigoのプログラミング・モデルとホスト 　図上部は、開発者のコードを示している。このコードはIndigoを直接ターゲットにしているか、いずれIndigo対応に書き換えられるMicrosoftの現行プログラミング・モデル（.NET Remote Objects、ASP.NETの“ASMX”、COM+ Enterprise Services）を用いている。 　図下部は、サービスが実行されるさまざまな環境だ。ASP.NETアプリケーション、伝統的なWindows NTスタイルのサービス、独自のEXEファイルやDLL、あるいはLonghornに対応予定のAvalonユーザー・インターフェイス・ライブラリを搭載したアプリケーションなどがある。

Indigoを待ちながら

　Indigoは2003年10月、Professional Developers Conference（PDC）で“Longhorn”の一部として発表された。Longhorn計画にはIndigoのパフォーマンスやスループットを向上させる機能が含まれるが、IndigoはWindows XPやWindows Server 2003でも動作する。Indigoが成功するためには、バックワードの互換性が欠かせない。というのも、IT組織の多くはデスクトップやサーバをアップグレードせずに、Webサービス・アーキテクチャを導入したいと考えているからだ。

　Indigo開発チームによると、Indigoのベータ版のリリースは2004年秋から始まる。MicrosoftはIndigoの配布方法について、まだ明らかにしていない。Indigo開発チームの主任プログラム・マネージャ、Steve Swartz氏は最近、Webキャストで次のように述べている。「何かの製品に連動して出荷の時期を決めるのではなく、出荷の準備ができた時点で、タイミングが合う製品が何になるかを見極め、それに合わせてIndigoを出荷することになる。Indigoとともに出荷される製品は、Whidbeyかもしれないし、OSのFeature Pack、またはLonghornになるかもしれない」

■Indigoをアプリケーションに適用するには

　PDCで配布されたIndigoは非常に早期のバージョンで、最終リリースまでに大幅な変更が加えられる可能性があると、Microsoftは開発者たちに説明している。従ってPDCバージョンはアプリケーションへの組み込みには適さないが、開発者がIndigoアーキテクチャを学習したり、アプリケーションをどのように設計するか研究するための素材としては役立つだろう。

　将来的にIndigoをアプリケーションに利用しようと考える開発者には、現時点で次の2つのオプションがある。

●ASP.NET
　開発者はASP.NETのWebサービス機能を利用することができる。ASP.NETは拡張WS-＊仕様をサポートしていないが、MSMQやBizTalkなどの技術を組み合わせて、現在でもWS-＊機能の一部をサポートするシステムを構築可能だ。またASP.NETは開発者のコードとWebサービスの実装を切り離す仕組みになっているので、将来の移行も容易だ。

●Web Services Enhancement Toolkit
　ASP.NETに代替するものとしては、Web Services Enhancement（WSE）Toolkitがある。Indigoチームが作成したライブラリで、新しいWS-＊仕様の発表に合わせて頻繁にアップデートされる。そのためMicrosoftでは、バージョン間の互換性について、ソース・コードに関しても相互運用性に関してもノー・クレーム対応としている。ただしMicrosoftは、Indigoのリリース・バージョンとその直前のWSEのバージョンの間では相互運用性が確保されるとしている。

　WSEの詳細については、Directions on Microsoft 日本語版 2003年11月号の「Webサービス仕様開発がわずかに前進」を参照。

Directions on Microsoft日本語版 本記事は、（株）メディアセレクトが発行するマイクロソフト技術戦略情報誌「Directions on Microsoft日本語版」から、同社の許可を得て内容を転載したものです。『Directions on Microsoft 日本語版』は、同社のWebサイトより定期購読の申し込みができます。

　

Insider's Eye

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）