第3章 ハイエンドコンピューティング研究開発の動向
藤田 悟 講師
1. はじめに
インターネットを通じてシステムを連携させる技術として、Webサービスが注目を集めてきている。Webサービスという概念は、元々、サービス指向アーキテクチャという発想から生まれたものである。すなわち、大きなビジネスを動かすシステムを設計する時に、全てをゼロから作り始めるのではなく、既存のサービスを利用して、それらを組み合わせることでビジネス全体を構成していくという考えに基づく。このサービス指向アーキテクチャを、サービス提供者、サービス要求者、そして、サービス仲介者の3者の関係として図1に示す。まず、サービス提供者とは文字通りサービスを保有していて、第三者に対してそれを提供する役割である。サービス提供者は、第三者から自分のサービスを見つけてもらうために、サービス仲介者にサービスの登録を行い、サービスを公開する必要がある。このサービス公開時に重要なことは、アクセスするインタフェース情報と、エンドポイントを明確にすることである。一方、サービス利用者は、サービス仲介者に対して、サービス検索の要求を出す。検索結果として、必要なサービスにアクセスするためのインタフェースとエンドポイントを取得する。後は直接にサービス利用者からサービス提供者に対してサービスの結合を行い、相互に通信を行って、サービスを利用することができる。
図1 Webサービスアーキテクチャ
このサービス指向アーキテクチャを支える重要な技術は、インタフェース定義と、インターネットを通じた通信手順と、サービス登録/検索技術である。インターネットという疎結合な環境で利用することを考慮し、また、計算機やOSに非依存な技術を利用するという考えから、全てをXML(eXtensible Markup Language)で記述する標準化が進められてきた。これがインタフェース定義言語である WSDL (Web Services Description Language)[1]と、通信規約である SOAP (Simple Object Access Protocol)[2]と、サービスディレクトリ UDDI (Universal Discription, Discovery, and Integration)[3] である。本報告では、これらのWebサービスの基本となっている技術を中心に概説した後、いくつかの課題を解決するための技術動向について紹介する。
本論に入る前に、SOAPが、Webサービスの必要条件というわけではないことも述べておきたい。例えば、WSDLによるインタフェースを中心にして、CORBA、Java RMI等の状況に応じた通信規約を用いるものもWebサービスに含めるという考え方もある。また、UDDIのようなサービスディレクトリを設けずに、個別のサービスがインタフェース定義を持つという考え方(WSIL: Web Services Inspection Language)[4]もある。W3CのWeb Services Architecture WG[5] によるWebサービスの定義を次に示すが、この定義の中にも、SOAPというキーワードはでは、直接現れていない。
「Webサービスとは、URIで識別できるソフトウェアシステムであり、インタフェースとバインディングがXMLを用いて定義され、記述されているものである。他のソフトウェアシステムは、この定義を検索できる。これらシステムは、定義に示された方法で、インターネットプロトコルによって伝送されるXMLベースのメッセージを利用して、Webサービスと相互通信することができる。」
それでは、SOAPはWebサービスにとって重要でないかというとそうは言っておらず、W3CによるWebサービスの定義文に続く説明にも、参照アーキテクチャとして、また、Webサービスを汎用につなぐための上位レベルの表現として、SOAP、WSDL が標準的技術であることが示されている。SOAPの出現により、Webサービスという考え方が広まり、Webサービス自体は、SOAPに限定されない広い概念として拡張されてきていると考えた方が良いであろう。
2. Webサービスの基本技術
2.1 SOAP
SOAP は、XML を用いてメッセージ交換するための通信規約である。下位の通信層は通常HTTPを用いるが、これに限定した仕様ではなく、例えばSMTPを用いることもできる。SOAPの語源は、Simple Object Access Protocolの頭文字をとったものであるが、オブジェクト指向的な側面は少なく、また、最近はsimpleでもなくなったということから、SOAPという名前だけ残り、その語源は問わないようになってきている。
SOAPによって送受信されるXMLは、ルートにEnvelope要素があり、その下位要素に、HeaderとBody要素が存在する構造を持つ。Header部は、主にメッセージの制御のために扱われ、例えば、署名情報などが格納される。Body要素に、通信したい内容が格納される。このBodyの中身は、XML Schema[6] で定義した任意のXML文書が記述できるが、特にRPC(Remote Procedure Call)を実現するために用いる表現の規約を持っている。図2にその典型的なSOAP RPCに対するXML文書の送受信例を示す。
図2 SOAP のメッセージ例
これは、株価を検索する例であり、要求側では、Body要素の中に、メソッド名に相当するGetLastTradePriceという要素を作成し、その中に、引数に相当するCompanyName要素を添える形でXML文書を作成している。一方、応答側は、GerLastTradePriceResponseという返答を表す要素中に、price要素を用いて現在の株価を返却する。このように、SOAP RPCはメソッドコールと返却値の関係を、直感的にXMLでシリアライズしたものと考えて良い仕様になっている。このRPCに用いる引数や返却値に利用できる型は、XML Schemaで定義された基本データ型(byte, short, integer, double など)と、その複合型(構造体と配列)である。構造体は、XML Schemaの文書型定義を用いて表現し、配列は、SOAP encodingによる特別な表現が用意されている。
この他、SOAPには、SOAP Messages with Attachments [7]という仕様があり、MIMEなどでエンコーディングした複数のパートにまたがる文書を転送することができる。文書の本体でSOAPによる通信方法を規定し、添付ファイルで付属情報としての画像やテキストなどを付加して転送することが可能になっている。
2.2 WSDL
WSDLは、WebサービスのサービスインタフェースをXMLで定義するための言語である。CORBAのIDLや、Javaのinterfaceに近いものであると考えて良い。WSDLのXML 文書は、definitions 要素によって記述されており、その中に次のような要素が含まれている。
SOAPの説明で用いたメッセージ例について、そのインタフェース定義を行うWSDLの例を図3に掲載する。
図3のように、WSDLは非常に複雑であり、これを人手で記述するのは困難である。通常は、例えば、Javaのinterfaceを定義し、そのinterface定義から、WSDLを自動生成することができる。また、逆に、WSDL定義から、Javaのstubクラスを自動生成することもできる。言い換えれば、Javaでサービスのプログラムを作成し、そのインタフェース定義からWSDLを生成し、呼び出し側はWSDLからJavaのアクセスクラスを生成して、それに対してサービス呼び出しを行うクライアントプログラムを作成するという形になり、プログラマは、Javaのプログラミングをするだけで、クライアントとサーバの間のRPCをSOAPとWSDLを用いて通信するWebサービスプログラムが書けるようになっている。
2.3 UDDI
UDDIは、Webサービスの公開と検索を行うレジストリの仕様を規定しており、主にレジストリのデータ構造と、レジストリへのアクセスインタフェースの定義を行っている。まず、データ構造は、businessEntity, businessService, bindingTemplateの3階層からなるXML文書と、tModelを表現するXML文書からなる。
これらの情報を登録、検索するためのAPIとしては、次のものが用意されている。ただし、XXXで示される部分には、検索の対象となるbusinessEntity、businessService、bindingTemplate、tModelを入れたものが用意されている。
モfind_XXX: キーワードなどを用いた検索のためのAPI。検索の結果は対象となった要素のキーがリスト形式で返される。
モget_XXX: find_XXXで検索されたキーから、その実体(内容)を取り出すときに使用するAPI。
モsave_XXX: オブジェクトを登録するためのAPI。
モdelete_XXX: レジストリのエントリを削除するためのAPI。
UDDIは、サービス提供者とサービス要求者を結びつける役割を果たす。当初は、世界共通のグローバルUDDIを立ち上げたが、その後、企業内や団体内においてプライベートな用途のUDDIを立ち上げる要求が高まってきている。また、Webサービスは、必ずしもUDDIを必要としていない現状もある。Webサービスを利用していると言われる多くのシステムは、WSDLとSOAPを用いて直接に相手と接続しており、UDDI を利用した動的なサービス検索、サービス呼び出しというレベルには至っていない。