この講座のメインテーマは、JavaでのWebサービス利用の基本的な手法になりつつあるJAX-RPCへのイントロダクションです。JavaやXMLは知っているがWebサービスははじめてという人を対象にしています。講座で皆さんが獲得されることが稔り多いものになるように、この講座を通じて学んでもらいたいことを、あらかじめ示しておきたいと思います。
第一の目標は、Webサービスを、SOAPをワイアリング・プロトコルとして利用したRPCとして捉えることです。自明のことのように思われる人もいらっしゃるかも知れませんが、このことを明確に意識することで、それに続く、JMSやsaajのような疎結合のメッセージング技術の意味もはっきりと認識できると筆者は考えています。「Webサービス＝SOAP-RPC」という認識を深めるために、講座では次の二つのことをしたいとおもっています。第一は、RPCの引数／返り値としてHTTPのRequest / Responseに乗せられるSOAPメッセージ上で、基本的なデータ達がどのようにEncodingされているかを少し詳しく見ることです。第二は、こうした多様なデータ型を表現するSOAPメッセージのやり取りによってSOAP-RPCが実現されることを確認するとともに、RPCの記述としてWSDLを捉える練習をします。具体的には、沢山、WSDLのサンプルを読んでもらおうと思っています。
第二の目標は、WSDL / XMLとJavaとの対応関係をはっきりと捉えることです。XMLのデータ型がJavaの型に対応するだけでなく、WSDLのPort TypeはJavaのInterfaceに、WSDLのOperationはJavaのmethodに対応します。こうした対比は、WSDL全体がJavaの一つのpackageに対応するというところまで拡張されます。もっと一般的な言い方をすれば、WSDLは直接にはSOAP-RPCの記述として生まれたものですが、それは、一般的なRPCを記述する能力を持っているということです。そのことをJavaで確認していきたいと思います。この関係は双方向のもので、我々は、WSDLが与えられれば対応するJavaのクラス群を生成できるだけではなく、Javaのクラス達から対応するWSDLを書き上げることが出来るのです。
第三の目標は、Javaの世界でのサーバ側でのWebサービスの基本的な手法になろうとしているJAX-RPCを、Javaの世界の標準的なネットワーク技術であるRMIの拡張として捉えることです。もともと、RMI（Remote Method Invocation）とRPC（Remote Procedure Call）は、基本的には同じものと考えて構いません。JAX-RPCは、SOAPをワイアリング・プロトコルとしたRMI、RMI over SOAPと考えることが可能です。先に見たWSDL / XMLとJavaとの対応関係は、SOAP-RPCからJAX-RPCへの移行を自然に説明します。そればかりではありません。JAX-RPCをRMI over SOAPと捉えることが、最近の大きな話題にであるWebサービスとJ2EEという二つの大きな技術の「合流」を理解する上で、きわめて重要だと考えられます。時間の関係で、この第三の目標は、本講座に続く後半の「Webサービス」コースで本格的に議論されることになるでしょう。
講座の流れは「SOAP」->「WSDL」->「JAX-RPC」と進んでいきますが、解りやすくするために最初は基本的なデータ型だけを取り上げます。ひととおり進んだあと、複雑なデータ型についても、もう一度SOAPから学んでゆきます。
「Webサービス」という技術の名前は、今はだいぶ良くなったかもしれませんが、いろいろ誤解を招いていることがあります。インターネットのWebについては、ほとんどの人が何かを知っていますし、また、「サービス」という言葉も誰もが知っています。だから、「Webサービス」についても、何か分かるような気がするのでしょう。もしも、誰かさんが、Webサービスを、「あのWebを利用したサービスだろう」と考えていたら、大体は、それは誤解だと考えてまちがいではありません。（「100%間違っている」と断言できない理由は、すぐ後で述べます。）
「あのWebを利用したサービス」と「Webサービス」との大きな違いは、次のところにあります。「あのWeb」と言うとき、人がイメージしているのは、誰かが、Webのブラウザを使ってインターネットを見ているところのイメージだと思います。残念ながら、Webサービスでは、Webのブラウザが大きな役割を果たすことは、あまりありません。「Webサービス」は、人間ではなくマシンを相手にしたサービスだと考えたほうがいいのです。それでは、どうして「Webサービス」などという名前がついたのでしょうか?それは、Webサービスが、「あのWeb」のクライアントであるブラウザではなく、Webの「サーバ」の機能を利用して、クライアントがサービスを受け取るシステムだからです。サーバに注目するならば、Webサービスは、「あのWebを利用したサービス」と言えない事もないのです。
HTMLがXMLに変わったくらいで、ほとんど同じ仕掛けであることがわかると思います。このようにWebサービスのサーバは、Webのサーバに他なりません。ただ、Webサービスの本体は、リクエストに対してレスポンスを返すWebサーバ上のServletとして実現されています。
Webサービスの世界では、Webサービスのサーバのことをサービス・プロバイダと呼び、クライアントのことをサービス・リクエスタと呼びます。サービス・リクエスタがサービス・プロバイダからサービスを受け取ることをバインド(bind)と呼びます。
Webサービスでは、Webブラウザが大きな役割を果たさないことは、すでに述べました。このことは、Webサービスが、ブラウザを中心にした、強力な「あのWeb」のイメージによってではなく、もうすこし古典的な「サーバ・クライアント・モデル」の枠組みで理解されるべきことを意味しています。
サーバ・クライアント・モデルでは、アプリケーション毎にサーバとクライアントを開発し、かつ、サーバとクライアント間のプロトコルを設計しなければなりません。これは当然のことですが、開発の負荷は高いものです。「大部分は同じだが少しは違う」サーバ・プロセスやプロトコルを、アプリケーション毎に書き分けるのは、単純ですが、手間がかかります。
Webサービスの発想は、アプリケーション毎に無数にサーバとクライアントを作ることをやめて、少なくともサーバとサーバ・クライアント間のプロトコルについては、ひとつの汎用のサーバ、ひとつの共通なプロトコルで済ませようというものです。Webサービスは、その「ひとつの汎用のサーバ」と「ひとつの共通なプロトコル」として、WebのサーバとHTTPを選んだのだと理解すればいいと思います。
では、なぜ、「無数」に存在するサーバの中から、Webのサーバが選ばれたのでしょうか？
それは意外と簡単な理由からだと思います。確かに、サーバ・クライアントのアプリケーションの数だけサーバのプログラムは存在するのですが、世界で一番数多く普及しているサーバは、Webのサーバです。もちろん、ベンダーは違っても、それらはすべて同じプロトコルを話します。
ちなみに、SunのJ2EEの基本的な発想は、無数にあるサーバ・クライアントのアプリケーションの中で、世界で一番普及しているクライアント・ソフトであるWebブラウザに注目したものと考えることができます。こちらは、アプリケーション毎に異なるクライアントを開発するのをやめて、「汎用クライアント」としてWebのブラウザを利用しようとする試みであると思えばよいのです。もちろん、アプリケーション毎にサーバの機能は異なるので、このアプローチでは、本来のサーバと「汎用クライアント」としてのWebブラウザの「中間」に、本来のサーバの言葉をクライアントであるWebブラウザ向けに変換するサーバが介在することになります。これが、ミドルウェア・サーバです。
Apache Axisはオープンソース・プロジェクトであるApache XMLプロジェクトのサブ・プロジェクトApache SOAPが前身のWebサービスのプロジェクトでSOAPのJavaによる実装です。SUNのWebサービスのAPIであるJAX-RPCをいち早く実装しています。AxisはIBMなどから貢献を受け、技術的にも先進性を持っています。
最近SUN自身がJAX-RPCの実装JWSDPを発表しており、こちらの方は後半の「Webサービスコース」で取り上げられることになっています。
本講座ではAxisを使用してWebサービスの開発を進めます。インストールや設定方法は演習課題の方を参照してください。