WebLogic Workshop で Web サービスを構築する

XML、SOAP、および WSDL は Web サービスの主要な技術を構成していますが、WebLogic Workshop を操作する開発者は、そうした技術の煩雑な詳細からはほとんど解放されます。WebLogic Workshop を使用すると、開発者は XML、SOAP、および WSDL ファイルの複雑な構文よりも、Web サービスのアプリケーション ロジックに専念できるため、Web サービスの開発が簡単になります。WebLogic Workshop では機能中心の方法で開発タスクを行うことができます。Web サービスに持たせる機能を WebLogic Workshop に指示すると、WebLogic Workshop はその指示に従って Web サービスの主要技術を実装します。WebLogic Workshop のビジュアル開発環境は、開発中の Web サービスをグラフィカルに表現します。開発者はさまざまな部分から成る Web サービスの全体図を参照したり、Web サービスが他のソフトウェア アプリケーションやデータ リソースとどのように接続するかを把握したりできます。以下のトピックでは、WebLogic Workshop で Web サービスの構築を始める際に必要な基本概念について説明します。

JWS ファイル

Java Web サービス(JWS)ファイルは Web サービスの中心部分です。JWS ファイルには、Web サービスの動作方法を決定する Java コードが含まれています。実際には、JWS ファイルは通常の Java クラス ファイルと変わりありません。この点で、WebLogic Workshop で構築される Web サービス を、XML メッセージを通じて外部と通信する Java クラスとして考えることができます。Java のプログラミングに慣れていない場合は、Java の概要を参照してください。

WebLogic Workshop のユーザ インタフェースでは、ソース ビューとデザイン ビューの 2 通りで JWS ファイルを表示できます。ソース ビューは JWS ファイル内のコードを直接表示し、デザイン ビューは JWS ファイルのコードをグラフィカルに表現します。

デザイン ビューまたはソース ビューで Web サービスを表示できるのと同様に、デザイン ビューまたはソース ビューで Web サービスを編集することもできます。デザイン ビューで Web サービスを変更すると、それに対応して基底のコードも変更されます。同様に、ソース ビューでコードを直接変更すると、その変更はデザイン ビューに自動的に反映されます。

JWS ファイルの詳細については、JWS ファイル : Java Web サービスを参照してください。

デザイン ビューを操作する

デザイン ビューで JWS ファイルを表示すると、Web サービスは画面の中央に、クライアント アプリケーションは左側に、Web サービスのデータ リソースは右側に描かれています。クライアント、つまり Web サービスを呼び出すアプリケーションには、Java アプリケーション、VisualBasic アプリケーション、他の Web サービスなど、XML メッセージを送信および受信するように設計された任意のアプリケーションが考えられます。同様に、Web サービスのデータ リソースは、XML メッセージを送信および受信できるものであれば、データベースや他の Web サービスなどあらゆる種類のアプリケーションが該当します。原則として、新しい Web サービスを構築するときはデザイン ビューから開始します。最初のデザイン ビューでは、Web サービスが利用するデータ リソース、Web サービスがクライアント アプリケーションやデータ リソースと対話する方法を定義できます。デザイン ビューで Web サービスの基本型を定義したら、ソース ビューの操作を始めます。ソース ビューでは Web サービスの内部情報の詳細を定義できます。

デザイン ビューの詳細については、ユーザ インタフェース リファレンスを参照してください。

クライアント インタフェース

デザイン ビューで Web サービス(JWS ファイル)を見てみると、クライアント アプリケーションと Web サービスの間をつなぐ矢印があります。この矢印はクラインアント アプリケーションと Web サービス間のインタフェース、つまり「パブリック コントラクト」を表します。クライアントから Web サービスに向いた矢印は、クライアントが Web サービスの機能を呼び出すためのメソッドを表します(クライアントに公開されるメソッドは、Web サービス内の他のメソッドと区別するために操作と呼ばれる場合があります)。Web サービスからクライアントに向いた矢印はコールバックを表します。コールバックは、Web サービスがクライアント アプリケーションに情報を返信できる方法の 1つです。コールバックはネットワーク コンテキストでの通信に特に便利です。コールバックを使用すると、クライアント アプリケーションはプロセスを停止して低速で遅延する Web サービスからの応答を待機する代わりに、プロセスを継続することができるためです。たとえば、 Web サービスに時間のかかる処理の実行を要求した場合、処理の完全な結果の代わりに、クライアント リクエストの確認応答をすぐに送信することで、クライアントのプロセスを解放することができます。処理が完了したら、Web サービスはコールバックを使って完全な結果をクライアントに送信できます。このような形式のアプリケーション間通信は、非同期通信と呼ばれます。これに対し、同期通信では、クライアントのプロセスと別のマシンで呼び出されたプロセスを同期させる必要があります。同期通信の場合、クライアント アプリケーションは、外部マシンの操作を呼び出すたびに中断し、完全な結果が返されるのを待つ必要があります。

Web サービスにおける非同期通信の詳細については、非同期性を利用して長期間の処理を実現するを参照してください。

コントロール

他のリソース(データベース、レガシー アプリケーション、他の Web サービスなど)からデータを取り出す必要のある Web サービスを構築する場合、コントロールを使用してリソースを設計に組み込むことができます。コントロールではコントロール メソッドコールバック ハンドラによって、Web サービスとデータ リソース間の通信を管理します。コントロール メソッド(Web サービスからコントロール経由でデータ リソースに向う矢印として描かれる)を使用すると、Web サービスはデータ リソースの機能を呼び出せます。コールバック ハンドラ(データ リソースからコントロール経由で Web サービスに向う矢印として描かれる)を使用すると、Web サービスはデータ リソースからのコールバックをリスンして受信できます。

コントロールの基底の Java コードは Web サービスの JWS ファイルには直接組み込まれません。コントロールのコードは独立した CTRL ファイルに格納されます。このようなファイルを使用することで、同じ Java コードを何度も記述しなくても、同じコントロールをさまざまな Web サービスで再利用できます。   

コントロールによって、Web サービスを他のアプリケーションと相互運用させるという複雑なタスクが非常に簡単になります。Web サービスと他のアプリケーションの間に特別なインタフェースを断片的に構築するのではなく、コントロールはさまざまなアプリケーションとのインタフェースに単一のモデルを提供します。アプリケーションがデータベースであろうと他の Web サービスであろうと、コントロールを使うと、Web サービスの Java コードからコントロール メソッドを直接呼び出すだけで、Web サービスからアプリケーションにアクセスできます。さらに WebLogic Workshop では、コントロールを自動生成するための強力なツールも用意しています。たとえば、WebLogic Workshop は WSDL ファイルに基づいて CTRL ファイルを自動的に生成します。Web サービスは、インターネット上の他の Web サービスとの間に簡単にインタフェースを持つことができます。

WebLogic Workshop では以下の種類のコントロールをサポートしています。

サービス コントロール ― サービス コントロールは他の Web サービスへのインタフェースを提供します。サービスは他のサービスのメソッドを呼び出したりコールバックを処理したりできます。他の Web サービスは、WebLogic Workshop で開発したものでも、WSDL ファイルが使用できる任意の Web サービスでもかまいません。

タイマー コントロール ― タイマー コントロールは、指定した期間が経過した場合、または指定した絶対時間に達した場合に、Web サービスに通知します。

EJB コントロール ― EJB コントロールは、エンタープライズ JavaBean(EJB)へアクセスするためのインタフェースを提供します。EJB はエンタープライズ アプリケーションの Java ソフトウェア コンポーネントです。

データベース コントロール ― データベース コントロールは、リレーショナル データベースへのアクセスを提供します。Web サービスは、Java メソッドを呼び出して Java オブジェクトを操作することにより、データベースへの問い合わせを行います。データベース コントロールでは、データベース クエリと Java オブジェクト間の変換を自動的に実行します。

JMS コントロール ― JMS コントロールを使用すると、Web サービスは Java Message Service(JMS)実装を提供するメッセージング システムと簡単に対話できます。

コントロールの詳細については、コントロール : Web サービスからリソースを使用するを参照してください。

プロパティを設定する

WebLogic Workshop では、基底の Web サービス技術の複雑さよりもアプリケーション ロジックに専念するための方法を他にも用意しています。それは、Web サービスのプロパティをグラフィカル ユーザ インタフェースで直接設定することです。Web サービスでエンタープライズ レベルの機能をサポートするために、複雑な Java コードを記述しないでも、WebLogic Workshop を使用するだけで、そうした機能を Web サービスに実装できます。個々のメソッドからコントロールまで、さらに Web サービス全体も含めて、サービス設計の項目ごとにプロパティのセットが表示され、デザイン ビューから直接変更できます。

プロパティを設定するだけで使用できる機能として、以下のような例が挙げられます。

デザイン ビューでプロパティを設定すると、ソース コードには Javadoc のコメントが追加されます。Javadoc はその名のとおり、元々はソース内のドキュメントを抽出する技術でした。Javadoc の技術によって Web サービスの特徴とプロパティの関連付けを行います。

WebLogic Workshop で使用される Javadoc タグは @jws プレフィックスで始まります。@ 記号は Javadoc の規則で、Javadoc タグとして解釈すべき語があることをコンパイラに知らせるためのものです。「jws」プレフィックスは「Java Web サービス」の意味で、Web サービス タグを他の Javadoc タグ(たとえば、Web サービスにコメントを埋め込むために独自の Javadoc タグを使用できる)と区別します。

以下の例には 3 つの Javadoc タグが含まれています。@jws:operation は、requestReport メソッドがクライアントから呼び出せるように公開されることを示してます。@jws:conversation は、requestReport メソッドが会話を開始することを示します。@jws:message-buffer は、requestReport メソッドがやり取りする XML メッセージがキューに入れられることを示します。

/**
* @jws:operation
* @jws:conversation phase="start"
* @jws:message-buffer enable="true"
*/
public void requestReport(String id)
{...}

Javadoc タグの詳細については、Javadoc タグ リファレンスを参照してください。

XML マップ

Web サービスは外部のアプリケーションと XML メッセージで通信するため、Web サービスを構築する主な作業には、XML と、Web サービス内部のアプリケーション ロジックを実装する言語との間の変換処理も含まれています。Web サービスの内部実装が Java で記述されている場合、送信するメッセージは Java のメソッド呼び出しから適切な XML メッセージに変換される必要があります。同様に、受信する MXL メッセージは適切な Java メソッド呼び出しに変換します。WebLogic Workshop の場合、この変換作業はすべてユーザに代わって行われます。受信 XML メッセージを個別に解析するスクリプトや、送信 XML メッセージを組み立てるスクリプトを記述する必要はありません。ただし、必要に応じて、XML マップや ECMAScript を使用して、XML と Java の変換プロセスにアクセスしたりカスタマイズしたりできます。

XML マップの詳細については、XML マップを使用して XML メッセージを処理および成形するを参照してください。