Global XML Web Services Architecture（GXA）は、2001年10月のMicrosoft PDC 2001にてマイクロソフトの次世代XML Web サービスのアーキテクチャとして発表されたものです。当初はマイクロソフト単独のアクティビティと見えましたが、次第にパートナー企業を巻き込んだイニシアティブの様相を呈しつつあります。しかしながら、企業のWeb サービスの採用も増えつつある現在、非常に重要な技術ロードマップでもある反面、全体像が見えにくいため.NETのような実装技術との切り分けがつかない方も多いかと思います。本稿ではGXAの技術的背景やSOAPの「モジュール」性との関係を交えながら全体像を明らかにしたいと思います。
GXAにおいても「相互運用性」を保証するための共通フレームワーク作りを端緒としています。その当時日本ではほとんど注目されてはいなかったかも知れませんが、2001年4月にW3CがWeb サービスに関するワークショップを開催していました。その中にマイクロソフトとIBMの共同発表として「Web Services Framework」（http://www.w3.org/2001/03/WSWS-popa/paper51）というペーパーがありますが、そこではXML、SOAP、WSDL、UDDIに加えていくつかのビルディングブロックの必要性が説かれています。Webサービスのフレームワークとは、特定のプラットフォームやアプリケーションに依存しない、ワイアレベルのファシリティを提供するものです。何故そのようなものを必要としているか、というとWeb サービスが持っている自律性、分散性という環境において相互運用性を実現するために、それぞれのコンポーネントがどのように協調すべきかを規定しながら、特定の実装技術に束縛されない共通フレームワークを提供することを目的としていたわけです。
GXAはWeb Services Frameworkのコンセプトを発展させて、SOAPをベースとしたビルディングブロック群から構成されたアーキテクチャとして定義されています。SOAPメッセージはヘッダ部とボディ部に分離可能ですが、一般的にヘッダ部をSOAPプロセッサが、ボディ部をアプリケーションが処理する形になっています。GXAでは、SOAPヘッダ部に１つ以上のメッセージングサービス構成情報が追加可能という、SOAPのモジュール性を利用することでアプリケーション（Webサービス）の保守性や再利用性を高めるだけでなく、将来の拡張性や既存技術の置き換えなどにも柔軟に対応できるよう設計されています。 GXAの設計原則は以下の４つに集約されます。
言わばGXAはWeb サービスのためのプロトコルフレームワークです。ただし、ソフトウェア製品ではなく仕様群という位置づけですので、GXA対応のプラットフォームやミドルウェア、ツールなどの開発を促進する必要があります。
図１にあるように、全てのビルディングブロックはSOAPを基盤としたモジュール構造になっています。それぞれのモジュールは現在大きく分けて４種類に分けることができます。
では、GXAのモジュール群のうち、現在公開中のモジュールであるWS-Routing、WS-Referral、WS-Securityの３つの仕様を掘り下げて行きましょう。
WS-RoutingはSOAPメッセージの非同期ルーティングメカニズムを提供するもので、メッセージの発信者から仲介者を経由して受信者へ至るステートレスなメッセージパスを定義します。WS-Routingにおける仲介者は、他のWS-Routing送信者のためにWS-Routingメッセージの処理と転送を行うことができます。例えば、送信者に代わって付加価値サービスを提供する、管理またはポリシーの代行をするなどのメカニズムが実現可能となります。WS-Routingのメッセージパスは基本的に1方向となっていますが、オプションとして逆方向も可能なので、要求/応答、ピアツーピア、受信確認やフォールトの返信など様々なメッセージパターンがカバー可能です。トランスポートに関してはTCPやUDPなど既存のプロトコルを選択でき、新しいトランスポートの定義は含まれてはいません。
定義の方法ですが、図2のように送信者Aが仲介者B、Cを経由して受信者Dにメッセージを送信する場合は、以下のようなメッセージパスを定義します。
| <SOAP-ENV:Envelope |
| xmlns:SOAP-ENV="http://www.w3.org/2001/06/soap-envelope"> |
| <SOAP-ENV:Header> |
| <wsrp:path xmlns:wsrp="http://schemas.xmlsoap.org/rp/"> |
| <wsrp:action>http://www.im.org/chat</wsrp:action> |
| <wsrp:to>soap://D.com/some/endpoint</wsrp:to> |
| <wsrp:fwd> |
| <wsrp:via>soap://B.com</wsrp:via> |
| <wsrp:via>soap://C.com</wsrp:via> |
| </wsrp:fwd> |
| <wsrp:from>soap://A.com/some/endpoint</wsrp:from> |
| <wsrp:id>uuid:84b9f5d0-33fb-4a81-b02b-5b760641c1d6</wsrp:id> |
| </wsrp:path> |
| </SOAP-ENV:Header> |
| <SOAP-ENV:Body> |
| ... |
| </SOAP-ENV:Body> |
| </SOAP-ENV:Envelope> |
| “path”ヘッダ以下の要素は次のような意味です。 | |
| "from" | ：メッセージの発信者 (A)。 |
| "to" | ：最終的な受信者 (D)。 |
| "fwd" | ：順方向のメッセージ パスを含んでいます。 |
| "rev" | ：逆方向のメッセージ パスを含んでいます。 |
WS-Referralは、メッセージパス内にいるSOAPノード（ルーター）が利用するルーティング情報を動的に構成するためのプロトコルで、WS-Routingから見ると「メタ」データを提供するものです（そうは言ってもWS-Routing専用を前提としているわけではなく、別のルーティング仕様と合わせて利用できることも念頭に置いています）。「Referral」という言葉を辞書で引くと「委託」とか「参照」などの意味を表しますが、WS-ReferralではSOAPノードが処理責任の一部もしくは全体を他のSOAPノードに委譲することできます。これにより、SOAPルーターがファイアウォールや他の仲介者に関する情報を取得する、グローバルにユニークでないURIによって識別されるリソースを発見する、またURI空間の負荷分散やアウトソーシングといったより大規模なスケーラビリティをWeb サービスにもたらすことなどが可能になります。WS-Referral仕様では具体的に以下のものを定義しています。
WS-Referral文は、WS-Referral仕様の核心部分であり、主に“for”、“if”、“go”、“desc”、“refId”の５つの要素から構成されています。例えばこれらの要素を使用し、「SOAP アクター "soap://example.org/some.doc" か、"soap://example.org/topics/icebergs" で始まる SOAP アクターにマッチするすべての SOAP アクター名について、この委譲が過去 12 時間 (43,200,000 ミリ秒) 以内のものであれば、"soap://example.com/mirror" を通過する。」という構成情報は、以下のように定義します。
| <r:ref xmlns:r="http://schemas.xmlsoap.org/ws/2001/10/referral"> |
| <r:for> |
| <r:exact>soap://example.org/some.doc</r:exact> |
| <r:prefix>soap://example.org/topics/icebergs</r:prefix> |
| </r:for> |
| <r:if> |
| <r:ttl>43200000</r:ttl> |
| </r:if> |
| <r:go> |
| <r:via>soap://example.com/mirror</r:via> |
| </r:go> |
| <r:refId>uuid:09233523-345b-4351-b623-5dsf35sgs5d6</r:refId> |
| <r:desc> |
| <r:refAddr>http://example.com/references/2001/10/1234.xml</r:refAddr> |
| </r:desc> |
| </r:ref> |
もちろん、このルーティング構成情報は発行した後も委譲先へのメッセージ転送を含めて変更が可能です。その他にもWS-Referral文の識別管理、明示的/暗黙的な委譲の発行やクエリ、WS-Referral文のキャッシングなどのメカニズムも検討されています。ある意味WS-ReferralはWS-Referral文をストアする、複数のSOAPノードにまたがる仮想的な分散データベースとも言えます。
ご存知の方も多いと思われますが、WS-Securityはマイクロソフト、IBM、ベリサインの３社共同という形で発表されたWeb サービスのセキュリティ仕様です。Webサービスのビジネス利用という観点からは間違いなく最重要技術です。とは言え現状のWebサービスにセキュリティサポートがないわけではありません。SSLを始めとしたトランスポートレベルのセキュアなメッセージ交換は現在でも利用されていますが、主に端点間（point-to-point）でのことであり仲介者を含めたルーティング情報が動的に構成されるようになると、メッセージレベルのセキュリティ標準の重要性が高まってきます。それがWS-Secirity（と派生モジュール群）が提供するものです。WS-Securityの主なゴールは以下のようなものです。
また、図3のようにWS-Securityではいくつかの派生仕様を検討中で、これらの組み合わせでより複雑なシナリオにも対応できるよう更にモジュール化されています。
すなわち現在のWS-Securityは確立されたセッション、セキュリティコンテキスト、及び（または）ポリシーの合意を前提とした、メッセージレベルのセキュリティを提供する単一のメッセージセキュリティ言語を記述することを中心にしています。
XML Web サービスにおけるSOAPメッセージの保護、という観点からは次の 2 種類の脅威を考慮する必要があります。
これらの脅威に対処すべく、WS-Securityの”Security”要素内は、大きく分けて認証のためのセキュリティトークン、完全性（integrity）を証明するための署名、機密性（confidentiality）を保持するための暗号化（encryption）の３つで構成されます。
セキュリティトークンは申告のコレクションであり、名前、ID、キー、グループ、特権、権限などから成ります。仕様では、ユーザー名とパスワードの組や、バイナリエンコード形式のX.509証明書やKerberosチケットなどを挙げています。
メッセージの完全性は、セキュリティトークンとXML署名を組み合わせて利用することで、メッセージが改ざんされずに転送されることを保証します。完全性メカニズムは、複数のアクターによって行われる可能性のある複数の署名をサポートし、追加の署名形式をサポートするために拡張ができるよう設計されています。
メッセージの機密性は、セキュリティトークンとXML暗号化を組み合わせて利用することで、 SOAPメッセージの機密の部分を保持します。暗号化メカニズムは複数のアクターによる追加の暗号化処理と操作をサポートするように設計されています。
その他にまだ仕様としては発表されてはいませんが、ロードマップとして見えているものとしては以下の２つがあります。
このようにGXAは高度化するビジネス要求に俊敏に応えるWebサービスを構築する、標準ベースのプロトコルフレームワークを提供するものです。また、GXAは高度にモジュール化されているため、Webサービスのシステム要件に応じたモジュールの選択、置き換え、拡張などに対して柔軟です。マイクロソフトは業界の主要パートナーとの協力の下、これらの仕様やWebサービスの更なるスケーラビリティや可用性、セキュリティなどを向上させるその他の仕様群を標準化してゆきます。なお2002年４月末の時点で時期はまだ発表されていませんが、マイクロソフトの最初のGXA実装としてGXA Toolkitを開発中であり、.NET FrameworkからGXAの各ビルディングブロックを利用したWebサービスを構築できるようになります。