Webアプリケーションの開発に使われる開発ツールには、多様な「言語」に対応できる機能と能力が求められる。業務アプリケーションをアプリケーション・サーバで動作させるという、最も典型的なケースで最低限必要になるのは、JavaとHTMLだ。JavaはWebコンテナで動作させるServletとEJBコンテナで動作させるEJB、そしてHTMLはWebコンテナのJSP内で使われる。JSPで作成するまでもない単純な画面は、スタティックなHTMLで作成されることが多い。また、デプロイ（配置）の際に参照される配置記述（DD）や種々のデータ記述にはXMLが多く使われる。

　Webサービス対応ソフトウェアを作成するための開発ツールには、以上の言語に対応した、編集、ビルド、テスト、配布の機能に加えて、Webサービスの定義に使われる2種類のデータ、UDDI（Universal Description, Discovery and Integration）とWSDL（Web Services Description Language）を取り扱うための機能も必要となる。

　UDDIは、BtoBコマースで使われるユーザー認証と決済に関する情報をインターネット上で容易に検索できるようにすることを目的に、2000年9月にIBM、マイクロソフト、アリバの3社が始めたプロジェクトおよびその仕様の名称である。このユーザー認証と決済は、さまざまな企業のコンピュータでインターネットに公開されたサービス（つまりWebサービス）で行われることになっていて、どのサイトでどのようなサービスが提供されているかは、インターネット上に設けられた検索用サイト（UDDIレジストリ）に問い合わせることで入手できる。

　UDDIが取り決めているのは、このUDDIレジストリの内容、問い合わせの仕方、得られる応答の内容の3点だ。UDDIレジストリに登録される情報には、businessEntity（サービスの集合に関する情報を公開している当事者に関する情報）、businessService（特定のサービスに関する記述的情報）、bindingTemplate（サービスのエントリ・ポイントと構成仕様に関する技術情報）、tModel（サービスの仕様または分類法の記述）、publisherAssertion（2つの当事者間の関係についての、片方の当事者によって表明されている情報）の5種類があり、約25種類の問い合わせ要求と5種類の応答がUDDIで規格化されている。

　UDDIレジストリに対する問い合わせとその応答の処理は、2つの方法で行うことができる。より手軽なのはUDDIが運営する所定のWebページをWebブラウザで開いて行う方法だ（画面1）。だが、すべて手作業ベースとなるので、業務として行うには適さない。

画面1　UDDIのWebサイトからUDDIレジストリを問い合わせることができる（画面をクリックすると拡大表示できます）

　もう1つは、UDDIレジストリの読み書きをするためのGUIツール（UDDIブラウザなどと呼ばれる）が添付された開発ツールを購入して、ソフトウェア開発作業の一環として行う方法だ。こちらの方法では、問い合わせによって得られたUDDIレジストリの内容を開発プロジェクトのデータとして保管しておくことができる。なお、UDDIレジストリには、インターネット全体に開かれたパブリックなものと、企業内使用やテスト用のプライベートなものがある。オールラウンドな開発ツールとして使うには、パブリックなUDDIレジストリの読み出しと更新だけでなく、プライベートなUDDIの作成、読み出し、更新もできることが望ましい。

　次にWSDLだが、WebサービスごとにUDDIレジストリに登録しておく定義データで、そのWebサービスを利用するアプリケーション開発時に必要な諸設定を収めておくために使われる。具体的な内容は、Webサービスにおけるアクセス・ポイント（URL）、プロトコル（SOAP、HTTP、MIME）、メッセージ形式（XML Schema）、ポートの割り当て、署名、対話の要件などだ。WSDLはWebサービスを公開する企業が作成することになっているので、公開側の企業にはWSDL作成機能が装備された開発ツール、利用側の企業にはWSDL参照機能が付いた開発ツールが必要となる。

　現在販売されているWebサービス対応開発ツールの多くは、WSDL作成機能とWSDL参照機能の両方を標準で装備している。WSDL作成機能の実体はソースコード・ジェネレータで、既存ソフトウェアのソースコードを入力としすると、XMLで記述されたWSDLが出力側に得られるという仕組みだ。これを、UDDIブラウザなどの機能を利用して、UDDIレジストリに登録すればよい。WSDL参照機能はこれと逆の動作をするソースコード・ジェネレータになっていて、UDDIから取り寄せたWSDLを入力すると、それを利用するためのソフトウェアの原型（プロキシコード）が自動生成される。このプロキシコードにビジネスロジックを追加すれば、Webサービスを利用するソフトウェアは出来上がる。

　IBMのWebアプリケーション開発ツールとして販売されているのは、「IBM WebSphere Studio」製品群である。この製品群にはいくつかのエディションがあるが、Webサービス対応なのは、次の3つのエディションだ。

●Site Developer Advanced
●Application Developer
●Integration Edition

　「WebSphere Studio Application Developer」（画面2）は、Site Developer AdvancedにJ2EEアプリケーション開発機能を付加したエディション、「Integration Edition」はApplication Developerにエンタープライズ・サービス（J2C開発ツール、CICS・IMS・HOD開発用コネクタ）をプラスしたエディションという位置付けだ。

画面2　IBMの統合開発環境「WebSphere Studio Application Developer」の画面（画面をクリックすると拡大表示します）

　Webサービス対応ソフトウェアを開発するための具体的な方法は以上のどのエディションでも共通で、発見（discover）、作成と変換（create and transform）、構築（build)、配置（deploy）、テスト（test）、開発（develop）、公開（publish）の7機能から必要なものを選んで実行していけばよい。処理のほとんどはメニューに割り付けられたウィザードが自動的に行ってくれるので、操作そのものは非常に簡単である。

　ほかの企業が公開しているWebサービスを利用するソフトウェアを作成する場合は、まず、discover機能のUDDI explorerを使ってUDDIの内容を取り寄せ、develop機能でWSDLからサンプルアプリケーション（プロキシコード）を生成させる。次に、WebSphere Studioの通常のプログラミング機能を利用してビジネスロジックを追加し、test機能を利用してローカルまたはリモートのテストを実施する。コードが完成した後の作業、例えばアプリケーション・サーバへの配布は、通常のソフトウェアと同じ方法で行えばよい。

　逆に、その企業で作成したソフトウェアをインターネット上に公開して他企業に使ってもらうには、まず、提供するソフトウェア機能がWebSphere Application Serverで動作可能な状態にしておく。必要な機能を備えたソフトウェアがすでに存在しているのなら、あえて新規開発する必要はない。次に、create and transform機能を使って、そのソフトウェアをWebサービスに変換する。この機能では、狭義のソフトウェアのほかに、URL、DB2 XML Extender呼び出し、DB2のストアド・プロシージャ、SQL照会などもWebサービスに変換することが可能だ。この作業と並行して、WSDLを生成させるために、build機能も実行しておく。公開予定のWebサービスのテストランは、deploy機能でWebSphere Application ServerかTomcatテスト環境に配置した後、test機能で行う。完成後のUDDIレジストリへの登録を行うのはpublish機能だ。

　次回は、企業内の業務アプリケーションを、Webサービスとどのように連携させていくのかを考察しよう。

Index
Webサービス時代のプラットフォームの条件
	第1回	次世代プラットフォームはWebサービスで決まり
	第2回	競争力を左右する統合開発環境
	第3回	Webアプリケーション・サーバを業務に導入する場合のポイント