Insider's Eye Webサービスのフレームワークを定義するGXA ―　Microsoftが新SDKのGlobal XML Web Services Architecture（GXA）をデベロッパに提供開始した。GXAは、プラットフォーム間やインターネット上でのアプリケーション統合に適した、Webサービスを作るためのテクノロジ一式である　―
Greg DeMichillie 2002/11/08 Copyright(C) 2002, Redmond Communications Inc. and Mediaselect Inc.

---

本記事は、（株）メディアセレクトが発行する月刊誌「Directions on Microsoft日本語版」 2002年10月15日号 p.15の同名の記事を許可を得て転載したものです。同誌に関する詳しい情報は、本記事の最後に掲載しています。

　GXA（Global XML Web Services）はまだ発展段階であるが、解決すべき問題の最終的なリストは存在しない。また、MicrosoftとIBM（もう1つの大手Webサービス・プレーヤー）が、GXAが抱えるであろう問題の解決方法で合意するか否かも不透明だ。いずれにせよ、Microsoft製品と相互運用する必要のあるソフトウェアを開発している会社と、Microsoftのプラットフォームに依存するITソリューションを開発する企業は、GXAの発展を詳細に追跡すべきである。

　Microsoftは新しいプレリリース・ツールキット、Web Services Development Kit（WSDK）でGXAの一部を提供した（WSDKに関しては別掲の「コラム：Web Services Development Kitの最新プレビュー版が公開」参照）。

GXAのルーツと狙い

　GXAの狙いは、組織の境界を越えて使われ、異なるOSやインフラが関係するアプリケーションをWebサービスで統合できるようにすることである。Webサービスとは、標準的なインターネット・プロトコル（Simple Object Access Protocol［SOAP］やHypertext Transfer Protocol［HTTP］など）を用いてアクセスできる１つのアプリケーション・ロジック（在庫追跡システムなど）である。

　組織が内部アプリケーション用にWebサービスを使用すると、トランザクション・モニタやメッセージ・キューといった既存の（一貫性のある）インフラ・コンポーネント一式を利用できる。しかし、異なるプラットフォームやOS、開発ツールを用いる組織間で正しく使用するためには、Webサービスはこうした問題の多くに再度取り組み、いくつかの周知の汎用的テクノロジを、システムや組織間の相互運用性を保証するように作り直す必要がある。GXAは解決すべき問題とその解決方法について、Microsoftが提供する処方箋である。

　GXAのルーツは、IBMとMicrosoftが共同で作成し、2001年4月のWorld Wide Web Consortium（W3C）のWebサービスに関するワークショップに提出した書類にさかのぼることができる。この書類は「Web Services Framework」というタイトルで、異なる管理・インフラ・トラストドメインを持つ組織同士のアプリケーション間統合を、Webサービスがサポートする場合に取り組むべき具体的機能を定義していた。同書が列記していたいくつかの基本的要素を以下に挙げる。

• セキュリティ：メッセージの出所と内容に関する保証を確認する能力。
• トランザクション：土台となるデータベースの完全性を、複数のWebサービスからアクセスされた場合も保証する能力。
• コーディネーション：複数のWebサービス間におけるデータの流れを記述・定義する能力。
• 信頼できるメッセージング：メッセージが意図したとおりの受取人によって、実際に受け取られていることを保証する能力。
• ルーティングとリファーラル（Referral）：メッセージのルートを指定する能力。
• アタッチメント：メッセージに（テキストに加え）バイナリ・データを含める能力。

　こうした基本的要素の多くは、企業のIT管理者にとって聞き慣れたものだ。信頼できる安全な社内アプリケーションの構築を目指す管理者が過去20年間に直面してきたおなじみの問題である。

　最初の書類が公表されて以来、MicrosoftはWebサービスの多くの機能面に対処するためのプロトコルを開発してきた。開発はときにはIBMやBEA Systemsなどのパートナーと連携して、またときには独自に行われた。Eric Rudder上級副社長によると、GXAはこうしたプロトコルや仕様の「Microsoftによる実装のブランド名」である。

アーキテクチャ・コンポーネントの筆頭はセキュリティとトランザクション

　GXAを構成するプロトコルと仕様はすべて、SOAPやWeb Services Description Language（WSDL）といったWebサービス技術の共通基盤の上に構築されている（このアーキテクチャの図解は次の「Global XML Web Services Architecture」参照）。

Global XML Web Services Architecture

GXAはレイヤ化されたアーキテクチャであり、ベースラインWebサービス仕様（下）を土台としている。ベースラインWebサービス仕様にはSOAP（Simple Object Access Protocol）、UDDI（Universal Data Discovery Interface）、WSDL（Web Services Description Language）などが含まれる。 　上位のGXAプロトコルは2つのレイヤに分類できる。1つ目のレイヤ（中）はWS-SecurityやWS-AttachmentsなどのSOAPモジュールだ。これらのプロトコルは、主に個々のメッセージの内容と構造に関係している。例えば、WS-Security仕様は、Kerberosチケットなどのセキュリティ情報をSOAPメッセージに埋め込む方法などを規定する。 　2つ目のレイヤ（上）は、WS-Transactionや信頼性の高いメッセージングなどのインフラ・プロトコルから成る。インフラ・プロトコルは、ビジネス課題を解決するためにメッセージ・シーケンスを組み合わせる方法を規定する。例えば、WS-Transaction仕様は、連携動作して一連のデータベース更新を調整する必要がある複数のWebサービス間でやり取りされるSOAPメッセージのフローを規定する。 　一部のGXAプロトコルはすでに定義されており、部分的に実装されているものもある（WS-SecurityやWS-Transactionなど）。だが、信頼性の高いメッセージングを始めとするその他のGXAプロトコルは、まだ仕様が策定されていない。

セキュリティ
　Webサービスが商業的に広く採用されるためにはセキュリティが不可欠だ。ほぼすべてのアプリケーションは、以下に示すような何らかのセキュリティを必要とする。

• 暗号化：メッセージが許可されていない者に読まれるのを防ぐ。
• 認証：メッセージ送信者の身元を確実に確認できるようにする。
• デジタル署名：メッセージが送信から受信の間に改ざんされていないことを保証する。

　MicrosoftとIBM、VeriSignが共同で策定した仕様のWS-Securityは、上記の基本的なセキュリティ概念をWebサービスに実装する方法を述べている。同仕様はプレリリース版のWSDKに含まれている。

　WS-Securityは、セキュリティ・トークン（認証や発信者のグループ・メンバーシップに関する情報）をメッセージに結び付ける方法について記述している。WS-Securityは特定のタイプのトークンは要求しないが、2種類の一般的なセキュリティ証明書、すなわちX.509証明書（VeriSignなどの公共認証局がデジタル署名と暗号化に使うタイプのデジタル証明書）とKerberos証明書（Windowsだけでなく、多くのOSが認証に使用）のエンコード方法について述べる。

　Webサービスのユーザーは、証明書の添付に加え、メッセージ内容の暗号化と、メッセージの改ざん防止を図るためのデジタル署名を加える手段を必要とする。これらの機能は、W3C仕様のXML-EncryptとXML-Signatureにそれぞれ記載されている。WS-Securityは、これらの機能を用いてSOAPメッセージを暗号化し、デジタル署名を施す方法を記述している。

トランザクション
　トランザクションは、ほぼすべての業務別アプリケーションにとって重要な要件である。例えば小売組織は顧客の注文を処理するために、複数のWebサービスを使うかもしれない。個々のWebサービスは、銀行の提供する信用照会（顧客が利用できる信用を削減）、社内在庫コンポーネント（在庫数計量アイテムを削減）、さらには外注の注文処理コンポーネント（アイテムを出荷する必要性を記録）といったデータベースをアップデートする必要がある。これらのアップデートは、アプリケーションが正しく機能するように調整されなければいけない。

　トランザクションとは、データベースに対する一連の変更を調整して、元データの完全性と一貫性を保証する方法だ。前述の例でいうと、信用照会が失敗した場合には小売業務は商品の出荷を望まないし、商品の在庫がなければ顧客は課金を望まない。

　WS-TransactionはMicrosoftとIBM、BEAによって共同で策定された仕様で、Webサービスがどのように連携してトランザクションを実現するかについて記述している。ただし、まだ実装されていない（WS-Transactionに関する情報は、別掲の「コラム：WS-Transaction仕様がリリース」参照）。

コーディネーション
　コーディネーション言語を用いることで、開発者は複数のWebサービスの調整と、それらの間におけるデータの流れの定義を伴う複雑なプロセスを記述できる。MicrosoftとIBMはそれぞれ、XLANGとWeb Services Flow Language（WSFL）という独自のコーディネーション言語を定義した。例えばMicrosoft自体のBizTalkサーバは、XLANGを用いて企業間電子商取引を推進し、アプリケーション間のビジネス・データの受信、確認、変換、処理、送信にかかわるエンドツーエンドのやり取りを管理している。両社はBEAとともに、Business Process Execution Language for Web Services（BPEL4WS）という長々しい名称の統一仕様を策定した。

　MicrosoftとIBMはいずれもBPEL4WSをサポートするが、この仕様をサポートしている製品はまだ存在せず、他のベンダーとは異なるアプローチを取っている。Sun MicrosystemsはSAPと提携してWeb Services Choreography Interface（WSCI）を開発し、OracleはW3Cにこの問題に参加して規格を策定するよう要請した。

信頼できるメッセージング
　多くのアプリケーション・シナリオでは、たとえ通信の一方が一時的にアクセス不能でも、メッセージが正しく配信される保証が必要だ。例えばショッピング・アプリケーションは、倉庫アプリケーションが一時的にオフラインでも、出荷要求がいずれ倉庫に届くことを保証できなければならない。

　多くの企業ITプランナーは、すでにMicrosoft Message Queuing（MSMQ）やIBMのMQ Seriesといったキューイング製品を使って、こうした機能を社内アプリケーションに実装している。しかし、それらの製品はプラットフォーム間やファイアウォール越しに（専用ゲートウェイがなければ）相互運用できず、標準化されていないため、トランスポート独立ではない。

　IBMもMicrosoftも、信頼のおけるメッセージングに取り組む必要性を認めているが、仕様はまだリリースされていない。しかし、MicrosoftはMSMQの最新リリースで独自のコンセプトであるSOAP Reliable Messageプロトコルを実装した（詳細はDirections on Microsoft日本語版2002年10月15日号の「COM+とMSMQがWindows .NET Serverで進化――アプリ・サーバとしてのWindows強化を後押し」参照）。

ルーティングとリファーラル
　ルーティングの概念は、ある当事者から別の当事者にメッセージが送られるとき、恐らく1つ以上の仲介者を経由することになるが、それがどのような方法で送信されるかということである。例えば、ある金融機関から別の金融機関に向けたWebサービス・メッセージは、政府の規制に準拠するために情報を記録する仲介者を経由するよう義務付けられるかもしれない。

　WS-RoutingはMicrosoftが策定した仕様で、メッセージがどのような方法でルートを指定するかを記述している。WS-ReferralはWS-Routingをベースにしており、サーバが存在する仲介者と両者間で利用可能なルートを動的に発見する方法を定義する。これにより、（例えば）Webサービスをホスティングする新しいサーバは、ある組織がそのを通ファイアウォール過するWebサービス・トラフィックの制御に使っているプロキシ・サーバの所在を確認できる。また、WS-Referralを使って、Webサービス・ルータの負荷分散を行うことも可能だ。これはルータに対し、利用可能なリファーラルの送信履歴に応じてサーバを切り替えることで実現する。

　WS-RoutingとWS-Referralは、いずれもWSDKでサポートされている。

バイナリ添付
　WebサービスはSOAPとXMLをベースとするため、基本的にテキストベースの技術だ。ユーザーが送信したいデータの大部分（顧客の氏名や住所、注文情報など）はテキストで簡単に表現できるが、一部の情報（オーディオやビデオなど）は通常バイナリ情報で表現されており、SOAP経由で送信する前に（Base64暗号化というプロセスを用いて）テキスト・フォーマットに変換し、受信側でバイナリ形式に再変換する必要がある。この変換作業によって送信者と受信者の処理時間は増え、SOAPメッセージ自体のサイズも増大する。

　バイナリ・データをSOAPメッセージに添付できれば、追加処理を省いてメッセージ・サイズをかなり縮小できる。例えばメディア企業やライブラリが、所蔵している写真を会員にWebサービス経由で提供することに決めたなら、写真を可能な限り、迅速かつ効率的に送信できるようにしたいと考えるだろう。MicrosoftはDirect Internet Message Encapsulation（DIME）とWS-Attachmentsを開発した。これはそれぞれ、バイナリ・データをメッセージでカプセル化し、こうしたバイナリ・メッセージをSOAPメッセージに添付する方法を記述した仕様だ。Microsoftが行ったいくつかのデモでは、DIMEとWS-AttachmentsはWebサービス経由で毎秒送信できる画像の数を倍以上にできることが示された。

　WS-AttachmentsとDIMEはいずれもWSDKでサポートされ、標準化に向けてInternet Engineering Task Force（IETF）に提出されたが、これらはMicrosoftが単独で開発したものである。IBMやOASIS（Organization for the Advancement of Structured Information Standards）といったほかの組織はWS-AttachmentsおよびDIMEの支持に加わらず、別のアプローチを取っている。

INDEX
	Insider's Eye
	Webサービスのフレームワークを定義するGXA(1)
	Webサービスのフレームワークを定義するGXA(2)
	コラム：Web Services Development Kitの最新プレビュー版が公開
	コラム：WS-Transaction仕様がリリース

　

Insider's Eye

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