Oliverの日記： ウェブサービス：SOAPとWSDL

職場でシステム管理目的にウェブサービスを準備中だ。数千のアカウントと数百のホストに数十のサーバ。これまでもこれらの情報は集中してデータベースにつっこんで管理していたが、読み出すのが大変。セミナーの申込みや課題最低の提出時に学生がユーザ名とパスワードを入力して個人認証するだけでも、最低で研究室の数だけのウェブサーバと最大で講義やセミナーの合計数だけのシステムからアクセスがある。(集中化すればいい、という意見はここが利権と政治の巣窟たる大学、しかも各自が自分のシステムを実装できる技量を持つ情報学部であることを考えてからにして欲しい。) そして、それらの利用者には連絡先などの個人情報なども含まれるデータベースには一切さわらせたくない、近寄らせてすらならない。ということで、これまではユーザネームとパスワードを入力したら1か0のリターンコードを返すプログラムしか起動できない様にしたSSHアカウントを各研究室に提供したり、印刷quotaの残数を表示するHTMLを吐き出すCGIを提供したりしている。想像の通り、利用者側からすれば、外部プログラムを呼び出さなければいけなかったり、明確な呼び出し規則もなければ、帰ってくるHTMLも人が読むことを前提にしていて共通の構造すらないCGIを叩いたり、泣けるくらいに使いにくい。僕らは知らない事になっているが、なかには学生が入力したユーザ名とパスワードで学生向けのIMAP/Sサーバにアクセスして、ログインできたら認証、なんて裏技なことをやってる助手もいたりする。もちろん、情報を管理する僕らからしても、設定してあるアクセス制限よりも細かく、誰がいつどこでどうようにアクセスしたかの情報は多数の形式の違うログファイルに分散していて集中的に把握もできなければ、新しい情報を提供するたびに新しいインタフェースを考えて、実装しなければならない、という悪夢だ。

この実態を暴露するのは恥ずかしいが、慢性的に人員不足で、しかも任務が多岐に渡り、ほぼなにもプロセス化できない状態で、自分が参加するずっと前、そしてそれからもクイックハックを積み重ねてきたのだから、こんなもんだろう。だが、ウェブサービスの導入で状況は劇的に変わろうとしている。

ウェブサービスは流行りのキーワードだが、身も蓋もないいいかたをすれば、単なるRPCのことだ。これまでもSunRPCやRMI、drb、DCOMといった仕組みが存在したが、いずれも特定の言語の仕様やプラットフォームに縛られている。プラットフォーム非依存のものとしてはCORBAがあるが、複雑すぎるので、あまり利用されていない。ウェブサービスの目新しい所は、その基盤にXMLとHTTPといったウェブから発展した技術を使っていることだ。これによって、理解しやすくなっただけでなく、これまでのものよりは簡単にいろんな処理系に実装できる。また、これまでのRPCメカニズム とは違って、「型」という概念をすて、「メッセージ」を入出力している。メッセージといっても、その正体はXMLドキュメントなので、動的タイピングなLightweight Languageでも静的タイピングなJavaなどの言語でもうまく、言語とプラットフォームごとの約束事を越えてうまく扱える。

で、本題にはいり、自分がなにをやってるのかというと、ウェブサービスの詳細を知らない人が書いたメソッドがつまったRubyのModuleを受取り、各メソッドのシグネチャをAuthenticationTokenが受け渡されるように改変したものをウェブサービスのRPCメカニズムであるSOAPのサービスとしてエキスポートし、中継途中で認証と承認(AuthenticationとAuthorization)、そしてログ取り(Auditing)を自動的にするフレームワークの構築だ。複雑そうに聞こえるが、そこはLightweight Language。試行錯誤の結果、合計で150行もなかったりする。

そして、そこでエキスポートされるサービスをWSDLでリストアップする。WSDLはWeb Service Description Languageという名の通り、提供されるサービスの入出力メッセージのスキーマとサービスがどこのURLでどういう形式(SOAPとかXML-RPCとかCGIとか)で提供されているのかXML形式で定義するものだ。

ここからが素晴らしい。Rubyだろうが、Perlだろうが、Javaだろうが、PHPだろうが、このWSDLファイルから自動的にクライアントのスタブが生成でき、あとはRPCであるとかSOAPやHTTPなど、いっさい気にしなくてもサービスが使える。試しにこれらの言語でクライアントを書いてみたが、感動するぐらい楽だった。

全てをハッシュとして扱うPerlのSOAP::LiteがカスタムのcomplexTypeのXMLネームスペースを保持してくれないので、小技が必要だったり、WSDL内で出力メッセージのpart名がreturnじゃないとJava用Apache AxisライブラリのWSDL2Javaがそれをメソッドのリターンタイプとして認識してくれない、といった細かい問題はあるが、これだけ楽に好きな言語からサービスにアクセスできるとなると、各研究室も喜んで使ってくれるだろう。SOAPとWSDL、好きになってしまった。