|
|
|
|
|
|
| | | |
WebLogic Web サービスの開発
この章では、WebLogic Web サービスを開発する方法について説明します。
この章では、以下の手順についての詳細を説明します。
Web サービスを RPC スタイルにするかメッセージスタイルにするか、どの EJB でサービスを実装するかなどを決定します。 WebLogic Web サービスの設計では、設計の考慮事項について説明します。
WebLogic Web サービスの大部分を構成する EJB 用のビジネス ロジック Java コードを記述します。詳細については、 WebLogic Web サービスの実装を参照してください。
*.jar）にパッケージ化します。
この手順についての詳細は、『WebLogic Server アプリケーションの開発』を参照してください。
サービスを構成するすべてのコンポーネント（ステートレス セッション EJB、SOAP サーブレットへの参照を含む Web アプリケーションなど）を J2EE エンタープライズ アプリケーション アーカイブ（*.ear）ファイルにパッケージ化して、WebLogic Server にデプロイできるようにします。Java Ant を使用して WebLogic Web サービスをアセンブルします。アセンブルでは、他の J2EE コンポーネント、メッセージスタイル Web サービスの JMS の送り先などの設定も参照します。
詳細については、 WebLogic Web サービスのアセンブルを参照してください。
Web サービスをリモート クライアントで使用できるようにします。詳細については、 WebLogic Web サービスのデプロイを参照してください。
WebLogic Server には、RPC スタイル Web サービスおよびメッセージスタイル Web サービスを作成する両方の例と、Web サービスを呼び出す Java および Microsoft VisualBasic クライアント アプリケーションの両方の例があります。
これらの例は、BEA_HOME\samples\examples\webservices ディレクトリにあります。BEA_HOME は、メイン WebLogic Server インストール ディレクトリを指します。RPC スタイル Web サービスの例は rpc ディレクトリにあり、メッセージスタイル Web サービスの例は message ディレクトリにあります。
例を作成して実行する方法の詳細については、ブラウザで Web ページ BEA_HOME\samples\examples\webservices\package-summary.html を呼び出してください。
WebLogic Web サービスの大半は、SOAP リクエストが受信され、処理された後にバックグラウンドで作業を行う EJB です。
設計の最初の段階は、RPC スタイルまたはメッセージスタイルの Web サービスのどちらを作成するかを決定することです。詳細については、 RPC スタイルまたはメッセージスタイル Web サービスの選択を参照してください。
以下の節では、RPC スタイル設計の問題について説明します。
以下の節では、メッセージスタイル設計の問題について説明します。
以下の節では、両方のタイプの Web サービスに共通する問題について説明します。
RPC スタイルまたはメッセージスタイル Web サービスの選択
この節では、RPC スタイルまたはメッセージスタイルの Web サービスを使用する場合について説明します。
RPC スタイル Web サービスは、インタフェース駆動型であり、基礎ステートレス セッション EJB のビジネス メソッドによって Web サービスの動作が決定されます。クライアントが Web サービスを起動すると、パラメータ値が Web サービスに送信され、対応するメソッドが実行されて戻り値が送り返されます。関係は同期で、クライアントが Web サービスからの応答を待機してから残りのアプリケーションに移行します。
アプリケーションが以下の特性を持っている場合は、RPC スタイル Web サービスを作成します。
RPC スタイル Web サービスの例には、特定の地域の現在の天気情報の提供、指定株の現在の株価の表示、またはビジネス トランザクションが完了する前の取引先の信用状態のチェックなどがあります。それぞれのケースで、情報が即時に返され、クライアントと Web サービス間の同期関係を示しています。
アプリケーションが次の特性を持っている場合は、メッセージスタイル Web サービスを作成します。
メッセージスタイル Web サービスの例には、発注書の処理、新しい DSL ホーム サービスに対する要求の受け入れ、または顧客からの見積り注文要求に対する応答などがあります。それぞれのケースで、クライアントは発注書などのドキュメント全体を Web サービスに送信して Web サービスで何らかの方法で処理されることを想定していますが、クライアントへの即時応答が必要ないか、応答の必要がまったくありません。Web サービスがこの非同期のドキュメント駆動型で機能する場合、メッセージスタイル Web サービスとして設計する必要があります。
Web サービスのすべての実際の作業を実行するか、または他の EJB に作業を分配するステートレス セッション EJB を使用して RPC スタイル Web サービスを実装します。この EJB は、クライアントが WebLogic Web サービスを呼び出すときに実行するメソッドを定義します。
クライアントと Web サービス間でやり取りするデータが最小限になるように EJB を設計します。この対話は同期で Web 上で行われるため、リクエストと応答が少ないほど全体のトランザクション速度が速くなります。
EJB のパラメータおよび戻り値のデータ型は、サポートされている Web サービス データ型のリストに制限されています。 WebLogic Web サービスのパラメータおよび戻り値でサポートされているデータ型を参照してください。このデータ型制限により、たとえば、Microsoft SOAP ToolKit などの Java および Java 以外の他の Web サービス実装との相互運用が容易になります。
既存の EJB アプリケーションの RPC スタイル Web サービスへの変換
パラメータおよび戻り値のデータ型が WebLogic Web サービスのパラメータおよび戻り値でサポートされているデータ型のサポートされている Web サービス データ型のリストにあれば、既存のステートレス セッション EJB を RPC スタイル Web サービスに変換できます。
既存の EJB を変換できない場合は、Web サービスを実装する新しいステートレス セッション EJB を作成し、サポートされているデータ型を使用してパラメータおよび戻り値をクライアントと送受信して、これらの値を正しいデータ型に変換してから値を既存のステートレス セッション EJB に渡す必要があります。
または、既存のステートレス セッション EJB を再プログラムして、サポートされているデータ型のみをパラメータおよび戻り値として受け取るようにすることもできます。
ステートレス セッション EJB 内でのメソッドのオーバーロードの回避
SOAP 仕様の制限により、SOAP メッセージは異なるシグネチャを持つ同じ名前のメソッド（オーバーロードされたメソッド）を明確に識別することができません。このため、WebLogic Server は RPC スタイル Web サービスを構成する EJB 内でオーバーロードされたメソッドをサポートしていません。各メソッドは固有の名前を持っている必要があります。
たとえば、ステートレス セッション EJB が文字列または整数をパラメータとして使用できる myMethod() というメソッドを定義したとします。SOAP 仕様では SOAP メッセージ内でパラメータのデータ型を宣言するように強制しないため、クライアントが呼び出したときに WebLogic Web サービスが myMethod(String) または myMethod(int) のどちらを実行するかを判断できない場合があります。混乱を避けるために、オーバーロードされたメソッドの 1 つを名前変更します。
メッセージスタイル Web サービスでは、エントリ ポイントとしてステートレス セッション EJB ではなく JMS リスナ（メッセージ駆動型 Bean など）を使用します。この節では、JMS と WebLogic Web サービスの関係およびメッセージスタイル Web サービスを開発するための考慮事項について説明します。
JMS キューでは、1 つの宛先に対してメッセージが配信されるポイント ツー ポイント メッセージング モデルを実装します。JMS トピックでは、複数の宛先に対してメッセージが配信されるパブリッシュ/サブスクライブ メッセージ モデルを実装します。
メッセージスタイル Web サービスを実装するときには、次の 2 つの点を決定する必要があります。
使用する JMS の送り先のタイプを決定した後で、JMS の送り先からドキュメントを取得して処理する J2EE コンポーネントのタイプを決定する必要があります。一般的に、このタイプはメッセージ駆動型 Bean です。このメッセージ駆動型 Bean では、ドキュメント処理のすべての作業を実行するか、部分的またはすべての作業を他の EJB に分配します。メッセージ駆動型 Bean がドキュメントの処理を完了したら、Web サービスの実行は完了です。
ドキュメントを送信して Web サービスを呼び出すクライアントが応答またはデータを受け取るようにするには、クライアントが応答を取得するために次に呼び出す 2 番目のメッセージスタイル Web サービスを作成する必要があります。2 番目の Web サービスは、オリジナルの Web サービスに関連しています。これは、ドキュメントを処理したオリジナルのメッセージ駆動型 Bean が結果情報または応答を 2 番目の Web サービスに対応する JMS の送り先に配置するためです。ここでも、2 番目の JMS の送り先がトピックまたはキューのどちらであるかを決定する必要があります。
図 2-1 は、クライアントからドキュメントを受信する Web サービスと、クライアントへドキュメントを送信する Web サービスの 2 つの簡単な例を示しています。 2 つの Web サービスには、それぞれ独自の JMS の送り先があります。メッセージ駆動型 Bean は、最初の JMS の送り先からメッセージを取得して情報を処理し、メッセージを 2 番目の JMS の送り先に戻します。クライアントは、最初の Web サービスを呼び出してドキュメントを WebLogic Server に送信し、次に 2 番目の Web サービスを呼び出して WebLogic Server からドキュメントを受信します。
図2-1 メッセージスタイル Web サービスと JMS 間のデータ フロー
既存の JMS アプリケーションの Web サービスへの変換
JMS の送り先からメッセージを取得するメッセージ駆動型 Bean が JMS の送り先に送られる Java オブジェクトを処理できる場合は、既存の JMS アプリケーションをメッセージスタイル Web サービスに変換できます。たとえば、
次の表に、サポートされている XML データ型とそれに相当する Java との間のマッピングを示します。で説明しているように、WebLogic Web サービスではクライアントからの標準の XML ドキュメントを org.w3c.dom.Document オブジェクトに変換します。
既存のJMS アプリケーション内のメッセージ駆動型 Bean が他のタイプのドキュメント オブジェクトを予期している場合は、次の 2 つのいずれかを行うことができます。メッセージ駆動型 Bean を再プログラムして org.w3c.dom.Document オブジェクトを受け入れるようにするか、または org.w3c.dom.Document オブジェクトを受け入れる新しいメッセージ駆動型 Bean を作成し、オリジナルのメッセージ駆動型 Bean で使用できるデータ型に変換して、新しいオブジェクトを JMS の送り先に配置してオリジナルのメッセージ駆動型 Bean が取り出せるようにします。
WebLogic Web サービスのパラメータおよび戻り値でサポートされているデータ型
Java および Java 以外の他の Web サービス実装との相互運用性を容易にするため、WebLogic では Web サービスへのパラメータおよび戻り値として使用できるデータ型を制限しています。
次の表に、サポートされている Java データ型と相当するXMLとの間のマッピングを示します。
次の表に、サポートされている XML データ型とそれに相当する Java との間のマッピングを示します。
WebLogic Web サービスでの XML と Java 間の変換
WebLogic Web サービスは、次の 2 つのエンコーディング スタイルをサポートしています。
注意: 上記の URI は、ブラウザで実際には呼び出すことはできません。URI を使用したエンコーディング スタイルを示す標準の規則です。
WebLogic Web サービスがクライアントからデータを受信すると、SOAP メッセージで指定されているエンコーディング スタイルを使用してパラメータまたはメッセージのデータ型を識別して正しい Java オブジェクトに変換できるようにします。
注意: WebLogic で生成した Java クライアント JAR ファイルを使用して Java クライアントを作成する場合、Java クライアント JAR ファイルには処理のためのコードが含まれているので特定のエンコーディング スタイルの知識は必要ありません。この節は、WebLogic Web サービスを呼び出す Java 以外のクライアントを作成し、エンコーディング スタイルの処理方法を理解する必要があるプログラマのための説明です。
SOAP パケットが SOAP エンコーディング スタイルを指定する場合、Web サービスは SOAP メッセージの本文の XML データを WebLogic Web サービスのパラメータおよび戻り値でサポートされているデータ型にリストされている Java データ型の 1 つに変換します。
変換が失敗した場合（たとえば、パラメータの 1 つに対応する Java データ型が定義されていない場合）は、Web サービスは SOAP 障害を Web サービスを呼び出したクライアントに返します。
XML から Java への変換が正常に行われた場合は、Web サービスのスタイルによって次の異なるアクションが行われます。
javax.jms.ObjectMessage データ型にラップし、メッセージを適切な JMS の送り先に配置します。
SOAP パケットがリテラル XML エンコーディング スタイルを指定する場合、Web サービスでは Web サービスが RPC スタイルかメッセージスタイルかに応じて XML メッセージの本文の XML データを org.w3c.dom.Element データ型に変換して、ドキュメントをステートレス セッション EJB に送信するか、またはドキュメントを javax.jms.ObjectMessage データ型にラップしてメッセージを適切な JMS の送り先に配置します。
WebLogic Web サービスがデータをクライアントに戻したときには逆の動作が行われます。org.w3c.dom.Element 戻り値は、クライアントに戻される前にリテラル XML エンコーディング スタイルを使用してエンコードされ、その他の Java データ型は SOAP エンコーディング スタイルを使用してエンコードされます。
前述のように、WebLogic Web サービスは、標準 J2EE エンタープライズ アプリケーションとしてパッケージ化されます。したがって、Web サービスへのアクセスにセキュリティを設定するには、Web サービスを構成する以下の標準 J2EE コンポーネントのいくつかまたはすべてに対するアクセスにセキュリティを設定する必要があります。
ベーシック HTTP 認証または SSL を使用して、WebLogic Web サービスにアクセスするクライアントを認証できます。先のコンポーネントが標準の J2EE コンポーネントであるため、標準の J2EE セキュリティ プロシージャを使用してセキュリティを設定します。ベーシック HTTP 認証および SSL の一般的な情報については、『WebLogic Security プログラマーズ ガイド』を参照してください。
WebLogic の Web サービスを呼び出すクライアントがデジタル証明書の提示を必要とするように相互 SSL を実装する方法については、 WebLogic Web サービスを呼び出すときの相互 SSL の使い方を参照してください。
クライアントとサービス間の SOAP メッセージを処理する SOAP サーブレットのセキュリティを設定することによって、メッセージスタイル Web サービスのセキュリティを設定します。
注意: また、このメソッドを使用して RPC スタイル Web サービスのセキュリティを設定することもできますが、 RPC スタイル Web サービスのセキュリティ設定で説明しているように、BEA では代わりに EJB にセキュリティを設定することをお勧めします。
wsgen Ant タスクを使用するかまたは手動で WebLogic Web サービスをアセンブルするときに、Web アプリケーションの web.xml ファイル内の SOAP サーブレットを参照します。これらの SOAP サーブレットでは、WebLogic Server とクライアント アプリケーション間の SOAP メッセージ を処理します。これらは常に WebLogic Server 上でデプロイされ、デプロイされたすべての WebLogic Web サービスで共有されます。
Web サービスによって参照される特定の SOAP サーブレットは、そのタイプ（RPC スタイルまたはメッセージスタイル）によって決定されます。次のリストは、各 SOAP サーブレットについて説明しています。
weblogic.soap.server.servlet.DestinationSendAdapter − クライアント アプリケーションから JMS の送り先にデータを受信するメッセージスタイル Web サービス内の SOAP メッセージを処理します。
weblogic.soap.server.servlet.QueueReceiveAdapter − JMS キューからクライアント アプリケーションにデータを送信するメッセージスタイル Web サービス内の SOAP メッセージを処理します。
weblogic.soap.server.servlet.TopicReceiveAdapter − JMS トピックからクライアント アプリケーションにデータを送信するメッセージスタイル Web サービス内の SOAP メッセージを処理します。
weblogic.soap.server.servlet.StatelessBeanAdapter − RPC スタイル Web サービスとクライアント アプリケーション間の SOAP メッセージを処理します。
たとえば、クライアント アプリケーションが JMS の送り先にデータを送信するメッセージスタイル Web サービスを作成した場合には、SOAP メッセージを処理する SOAP サーブレットは weblogic.soap.server.servlet.DestinationSendAdapter です。Web サービスをアセンブルするために使用された wsgen Ant タスクは、次の要素をWeb アプリケーションの web.xml デプロイメント記述子に追加します。
<servlet>
<servlet-name>sender</servlet-name>
<servlet-class>
weblogic.soap.server.servlet.DestinationSendAdapter
</servlet-class>
<init-param>
<param-name>topic-resource-ref</param-name>
<param-value>senderDestination</param-value>
</init-param>
<init-param>
<param-name>connection-factory-resource-ref</param-name>
<param-value>senderFactory</param-value>
</init-param>
</servlet>
...
<servlet-mapping>
<servlet-name>sender</servlet-name>
<url-pattern>/sendMsg</url-pattern>
</servlet-mapping>
DestinationSendAdapter SOAP サーブレットへのアクセスを制限するには、セキュリティ レルムの 1 つまたは複数のプリンシパルにマップされるロールを定義してから、この SOAP サーブレットに適用するセキュリティ制約を次の web-resources-collection 要素内の url-pattern 要素を Web アプリケーションの web.xml デプロイメント記述子に追加することによって指定します。
<url-pattern>/sendMsg</url-pattern>
wsgen Ant タスクで作成されたエンタープライズ アプリケーション アーカイブの構造の詳細については、
Web サービス アーカイブ ファイルの手動によるアセンブルを参照してください。
サーブレットへのアクセスを制限する手順の詳細については、『Web アプリケーションのアセンブルとコンフィグレーション』を参照してください。
Web サービスを実装するステートレス セッション EJB へのアクセスを制限することによって RPC スタイル Web サービスへのアクセスを制限します。
RPC スタイル Web サービスを呼び出すクライアント アプリケーションは、常に Web アプリケーションおよび SOAP サーブレットへアクセスできますが、EJB を呼び出せない可能性があります。このタイプのセキュリティは、EJB のビジネス ロジックに誰がアクセスしたかを細かくモニタするが、Web サービス全体へのアクセスはブロックしないという場合に便利です。
EJB へのアクセスの制限については、『WebLogic エンタープライズ JavaBeans プログラマーズ ガイド』を参照してください。
WebLogic Web サービスを呼び出すときの相互 SSL の使い方
相互 SSL では、WebLogic Web サービスを呼び出すクライアント アプリケーションは、自分のデジタル証明書を WebLogic Server に提示する必要があります。WebLogic Server は、信頼性のある認証局のリストと照らし合わせてデジタル証明書を検証します。
相互 SSL を使用して WebLogic Web サービスを呼び出す Java クライアントの作成は、以下の手順で行います。
詳細については、『WebLogic Server 管理者ガイド』の「SSL プロトコルのコンフィグレーション」および「相互認証のコンフィグレーション」を参照してください。
System.out.println("********************** loading client certs");
InputStream certs[] = new InputStream[3];
certs[0]=new PEMInputStream(new FileInputStream("sample_key.pem"));
certs[1]=new PEMInputStream(new FileInputStream("sample_cert.pem"));
certs[2]=new PEMInputStream(new FileInputStream("sample_ca.pem"));
h.put(SoapContext.SSL_CLIENT_CERTIFICATE, certs);
String prov = "weblogic.net";
String s = System.getProperty("java.protocol.handler.pkgs");
if (s == null) {
s = prov;
} else if (s.indexOf(prov) == -1) {
s += "|" + prov;
}
System.setProperty("java.protocol.handler.pkgs", s);
このコードについて説明します。
注意: SSL 接続を確立するときは、デジタル証明書の主体の DN が、SSL 接続を開始するサーバのホスト名と一致している必要があります。一致していないと、SSL 接続は確立されません。WebLogic Server に付属するデモ用証明書を使用している場合は、ホスト名が一致しません。
これを防ぐには、クライアント アプリケーションを実行するときに、またはこの設定を常に有効にする場合は WebLogic Server を起動するときにも、-Dweblogic.security.SSL.ignoreHostnameVerification=true フラグを使用します。このフラグを設定すると、主体の DN とホスト名を比較するホスト名検証が無効になります。この方法は、開発環境でのみ推奨されます。発信 SSL 接続を行うサーバ用に新しいデジタル証明書を取得する方が、対応策として一層安全です。
WebLogic Web サービスの実装では、Web サービスのエントリ ポイントとして定義されるステートレス セッション EJB（RPC スタイル Web サービス用）または JMS リスナ（メッセージスタイル Web サービス用）の Java コードを記述します。JMS リスナは一般的に、メッセージ駆動型 Bean です。ステートレス セッション EJB または JMS リスナでは、すべての Web サービス機能を含んでいるか、または他の EJB を呼び出して作業を分配する場合があります。
ここでは、 WebLogic Web サービスの設計で説明した設計の問題を読み、理解していること、Web サービスを設計し終えていること、コード化する必要があるコンポーネントのタイプを理解していることを前提としています。
RPC スタイル Web サービスを実装するには、ステートレス セッション EJB 用の Java コードを記述します。 WebLogic Web サービスのパラメータおよび戻り値でサポートされているデータ型にリストされている EJB のパラメータおよび戻り値としてサポートされている Java データ型のみを使用してください。
ステートレス セッション EJB のプログラミングの詳細については、『WebLogic エンタープライズ JavaBeans プログラマーズ ガイド』を参照してください。
メッセージスタイル Web サービスには、 メッセージスタイル Web サービスと JMSに説明されているように Web サービスを呼び出すクライアントから XML データを受信するものと、XML データをクライアントに送信するものの 2 つのタイプがあります。
メッセージスタイル Web サービスを実装するには、次の手順に従います。
この手順の詳細については、 メッセージスタイル Web サービス用の JMS コンポーネントのコンフィグレーションを参照してください。JMS の一般的な情報については、『WebLogic Server 管理者ガイド』を参照してください。
メッセージ駆動型 Bean のプログラミングの詳細については、『WebLogic エンタープライズ JavaBeans プログラマーズ ガイド』を参照してください。
メッセージスタイル Web サービス用の JMS コンポーネントのコンフィグレーション
この節では、既に JMS サーバをコンフィグレーションしていること前提としています。JMS サーバのコンフィグレーションおよび JMS の一般的な情報については、『WebLogic Server 管理者ガイド』、および『WebLogic JMS プログラマーズ ガイド』を参照してください。
JMS の送り先（キューまたはトピック）および JMS 接続ファクトリをコンフィグレーションするには、次の手順に従います。
この節では、Web サービスのすべてのコンポーネントをアセンブルし、WebLogic Server にデプロイしてリモート クライアントでアクセスできるようにする方法について説明します。
Java Ant タスクを使用した WebLogic Web サービスのアセンブル
WebLogic Web サービスのアセンブルでは、RPC スタイル Web サービスを実装する EJB、サポート EJB、SOAP サーブレットを含む Web アプリケーションなどの Web サービスのすべてのコンポーネントをエンタープライズ アプリケーション アーカイブ（*.ear）にパッケージ化して、WebLogic Server にデプロイできるようにします。
開発者は、wsgen と呼ばれる Java Ant タスクを使用して WebLogic Web サービスをアセンブルします。wsgen Ant タスクでは、SOAP サーブレットおよびエンタープライズ アプリケーション アーカイブに関する application.xml ファイルを含む Web アプリケーションなど、ほとんどの WebLogic Web サービス コンポーネントを生成します。先に作成する必要がある唯一のコンポーネントは、Web サービスを実装する EJB またはメッセージ駆動型 Bean です。
Ant の一般的な情報については、http://jakarta.apache.org/ant/index.html を参照してください。
注意: WebLogic Server に付属する Java Ant ユーティリティは、ANTCLASSPATH 変数を設定するときに、BEA_HOME\bin ディレクトリにあるコンフィグレーション ファイル ant (UNIX) または ant.bat (Windows) を使用します。BEA_HOME は、WebLogic Server のインストール ディレクトリです。ANTCLASSPATH 変数を変更する必要がある場合は、これらのファイルもそれに合わせて更新する必要があります。
WebLogic Web サービスを手動でアセンブルする詳しい手順については、 Web サービス アーカイブ ファイルの手動によるアセンブルを参照してください。
WebLogic Web サービスを手動でアセンブルするには、次の手順に従います。
*.jar ファイルをサポート EJB とともにステージング ディレクトリにコピーします。
Windows NT の場合は、setEnv.cmd コマンドを実行します。このコマンドは BEA_HOME\config\domain ディレクトリにあります。BEA_HOME は WebLogic Server がインストールされているディレクトリで、domain はドメインの名前です。
UNIX の場合は、setEnv.sh コマンドを実行します。このコマンドは BEA_HOME/config/domain ディレクトリにあります。BEA_HOME は WebLogic Server がインストールされているディレクトリで、domain はドメインの名前です。
build.xml という名前のファイルを WebLogic Web サービスをアセンブルする Ant タスク要素を含むステージング ディレクトリ内に作成します。
build.xml ファイルの作成の詳細については、
Ant build.xml ファイルの例を参照してください。
$ ant
wsgen Ant タスクでは、ステージング ディレクトリ内にサービス コンポーネントを含む *.ear ファイルを作成します。以上でこの *.ear ファイルを WebLogic Server にデプロイできます。
WebLogic Server には、WebLogic Web サービスのコンポーネントをエンタープライズ アーカイブ ファイルに素早くアセンブルできるように wsgen Ant タスクが含まれています。
次の例は、1 つの RPC スタイル Web サービスと 2 つのメッセージスタイル Web サービス（メッセージの送信用と受信用）の 3 つの Web サービスをアセンブルする build.xml ファイルを示しています。
表 2-3 では、ファイル要素について説明します。
コード リスト 2-1 WebLogic Web サービスをアセンブルする build.xml ファイルの例
<project name="myProject" default="wsgen">
<target name="wsgen">
<wsgen
destpath="myWebService.ear"
context="/myContext"
protocol="http">
<rpcservices path="myEJB.jar">
<rpcservice
bean="statelessSession"
uri="/rpc_URI"/>
</rpcservices>
<messageservices>
<messageservice
name="sendMsgWS"
action="send"
destination="examples.soap.msgService.MsgSend"
destinationtype="topic"
uri="/sendMsg"
connectionfactory="examples.soap.msgService.MsgConnectionFactory"/>
<messageservice
name="receiveMsgWS"
action="receive"
destination="examples.soap.msgService.MsgReceive"
destinationtype="topic"
uri="/receiveMsg"
connectionfactory="examples.soap.msgService.MsgConnectionFactory"/>
</messageservices>
</wsgen>
</target>
</project>
表2-3 build.xml 例の説明
build.xml ファイルの要素および属性の詳細については、
build.xml の要素と属性を参照してください。
次の手順では、WebLogic Web サービスを正しくアセンブルするために build.xml ファイルに含める必要がある Ant タスク要素について説明します。前述の節の例をガイドとして使用してください。
次の手順で示される build.xml ファイルの要素および属性の詳細については、
build.xml の要素と属性を参照してください。
BEA XML エディタを使用した build.xml ファイルの作成および編集については、
XML ファイルの編集を参照してください。
WebLogic Web サービスのアセンブル用の build.xml Ant ビルド ファイルを作成するには、次の手順に従ってください。
build.xml という名前の空のファイルを作成します。
<project> 要素を 1 つ追加します。
<project> 要素内で、1 つの属性（name）を持つ <target> 要素を追加し、name 属性を wsgen に設定します。
<target> 要素内で、次の属性を持つ <wsgen> 要素を追加します。
<rpcservices> 要素を <wsgen> 要素内に追加します。
<rpcservices> 要素内で、アセンブルしている各 RPC スタイル Web サービスに対して次の属性を持つ <rpcservice> 要素を追加します。
<messageservices> 要素を <wsgen> 要素内に追加します。
<messageservices> 要素内で、アセンブルしている各メッセージスタイル Web サービスに対して、メッセージスタイル Web サービスに対して既に設定している JMS の送り先および接続ファクトリに関する次の属性を持つ <messageservice> 要素を追加します。
WebLogic Web サービスは、WSDL ファイルを JSP としてパブリッシュします。WSDL JSP は、特定の WebLogic Server のホストおよびポートをハードコード化したり、サービスをホストしている WebLogic Server に基づいてホストおよびポートを動的に生成したりできます。
一般的に、WebLogic Web サービスの WSDL でホストおよびポートを動的に生成する場合は、Web サービスのアセンブルに使用される build.xml Ant ファイル内の wsgen 要素の host および port 属性を指定しないで設定します。ただし、ホストおよびポートを WSDL JSP 内でハードコード化する場合は、host および port 属性を明示的に指定します。
WebLogic Web サービスをデプロイすることで、リモート クライアントで使用できるようにします。WebLogic Web サービスは標準 J2EE エンタープライズ アプリケーションとしてパッケージ化されているため、Web サービスのデプロイはエンタープライズ アプリケーションのデプロイと同じです。
エンタープライズ アプリケーションのデプロイの詳細については、『WebLogic Server 管理者ガイド』を参照してください。
この節では、製品例として BEA_HOME\samples\examples\rpc ディレクトリに収められているサンプルの RPC スタイル WebLogic Web サービスの開発、アセンブル、デプロイの開始から終了までのプロセスについて説明します。
サンプルの Weather RPC スタイル WebLogic Web サービスを開発するには、次の基本手順に従います。
Windows NT の場合は、setEnv.cmd コマンドを実行します。このコマンドは BEA_HOME\config\domain ディレクトリにあります。BEA_HOME は WebLogic Server がインストールされているディレクトリで、domain はドメインの名前です。
UNIX の場合は、setEnv.sh コマンドを実行します。このコマンドは BEA_HOME/config/domain ディレクトリにあります。BEA_HOME は WebLogic Server がインストールされているディレクトリで、domain はドメインの名前です。
詳細については、 EJB 用の Java コードの記述を参照してください。
詳細については、 EJB デプロイメント記述子の作成を参照してください。
weather.jar アーカイブ ファイルにアセンブルします。
詳細については、 EJB のアセンブルを参照してください。
build.xml Java Ant ビルド ファイルを作成します。
詳細については、 build.xml ファイルの作成を参照してください。
weather.jar ファイルおよび build.xml ファイルをステージング ディレクトリにコピーします。
weather.ear アーカイブ ファイルにアセンブルします。
$ ant
weather.ear アーカイブ ファイルを BEA_HOME\config\domain\applications ディレクトリにコピーして、Weather Web サービスをテスト目的のために自動デプロイします。BEA_HOME はメイン WebLogic Server インストール ディレクトリで、domain はドメインの名前です。
Weather Web サービスを Java および Visual Basic クライアント アプリケーションの両方から呼び出すには、BEA_HOME\samples\examples\webservices\rpc\javaClient および BEA_HOME\samples\examples\webservices\rpc\vbClient の例を参照してください。
クライアント アプリケーションのビルドおよび実行手順については、ブラウザで Web ページの BEA_HOME\samples\examples\webservices\package-summary.html を呼び出してください。
サンプル Weather ステートレス セッション EJB には、1 つのパブリック メソッド（getTemp()）が含まれます。このメソッドは単一の引数と郵便番号を持ち、郵便番号が 90210 で戻り値が -273.15 以外の場合に、77 の float 値を返します。
注意: このメソッドでは、指定した郵便番号地域の実際の気温を返す Web サービスをシミュレーションしています。
次の Java コードは、Weather EJB のパブリック インタフェースです。
package examples.webservices.rpc.weatherEJB;
import java.rmi.RemoteException;
import javax.ejb.EJBObject;
/**
* このインタフェース内のメソッドは WeatherBean のパブリック インタフェース。
* これらのメソッドのシグネチャは EJBean のシグネチャと同じだが、
* java.rmi.RemoteException を送出する点で異なる。
* EJBean はこのインタフェースを実装していないことに注意すること。対応する
* コード生成の EJBObject である WeatherBean は、このインタフェースを実装し
* Bean に委託する
*
* @author Copyright (c) 1998 by WebLogic, Inc. All Rights Reserved.
* @author Copyright (c) 2001 by BEA Systems, Inc. All Rights Reserved.
*/
public interface Weather extends EJBObject {
/**
* 指定した ZipCode 地域の気温を取得
*
* @param ZipCode String ZipCode
* @return double Temperature
* @exception 通信またはシステムに障害がある場合は
* RemoteException を送出
*/
public float getTemp(String ZipCode) throws RemoteException;
}
次の Java コードは、実際の ステートレス セッション EJB クラスです。
package examples.webservices.rpc.weatherEJB;
import javax.ejb.CreateException;
import javax.ejb.SessionBean;
import javax.ejb.SessionContext;
import javax.naming.InitialContext;
import javax.naming.NamingException;
/**
* WeatherBean は、ステートレス セッション Bean。この Bean は以下を表す
* <ul>
* <li> セッション Bean への呼び出しと呼び出しの間に永続性はない
* <li> 環境から値をルックアップ
* </ul>
*
* @author Copyright (c) 1998 by WebLogic, Inc. All Rights Reserved.
* @author Copyright (c) 2001 by BEA Systems, Inc. All Rights Reserved.
*/
public class WeatherBean implements SessionBean {
private static final boolean VERBOSE = true;
private SessionContext ctx;
private int tradeLimit;
// WebLogic のログ サービスの使用も検討すること
private void log(String s) {
if (VERBOSE) System.out.println(s);
}
/**
* このメソッドは EJB 仕様では必須。
* ただし、この例では使用されていない
*
*/
public void ejbActivate() {
log("ejbActivate called");
}
/**
* このメソッドは EJB 仕様では必須。
* ただし、この例では使用されていない
*
*/
public void ejbRemove() {
log("ejbRemove called");
}
/**
* このメソッドは EJB 仕様では必須。
* ただし、この例では使用されていない
*
*/
public void ejbPassivate() {
log("ejbPassivate called");
}
/**
* セッションのコンテキストを設定
*
* @param ctx SessionContext セッションのコンテキスト
*/
public void setSessionContext(SessionContext ctx) {
log("setSessionContext called");
this.ctx = ctx;
}
/**
* このメソッドは、ホーム インタフェース「WeatherHome.java」の create
* メソッドに対応する。
* 2 つのメソッドのパラメータ セットは同じ。クライアントが
* <code>WeatherHome.create()</code> を呼び出すと、コンテナが EJBean
* のインスタンスを割り当てて <code>ejbCreate()</code> を呼び出す
*
* @exception 通信またはシステムに障害がある場合は
* javax.ejb.CreateException を送出
* @see examples.ejb.basic.statelessSession.Weather
*/
public void ejbCreate () throws CreateException {
log("ejbCreate called");
try {
InitialContext ic = new InitialContext();
} catch (NamingException ne) {
throw new CreateException("Failed to find environment value "+ne);
}
}
/**
* 指定した ZipCode 地域の気温を取得
*
* @param ZipCode String ZipCode
* @return float Temperature
* @exception 通信またはシステムに障害がある場合は
* RemoteException を送出
*/
public float getTemp(String ZipCode) {
log("getTemp called");
Float result;
if (ZipCode.equals("90210")) {
result = new Float(77.0);
} else {
result = new Float(-273.15);
}
return result.floatValue();
}
}
次の Java コードは、Weather EJB のホーム インタフェースです。
package examples.webservices.rpc.weatherEJB;
import java.rmi.RemoteException;
import javax.ejb.CreateException;
import javax.ejb.EJBHome;
/**
* このインタフェースは、WeatherBean.java のホーム インタフェース。
* WebLogic では、コード生成のコンテナ クラスである WeatherBeanC
* によって実装される。ホーム インタフェースは、EJBeanで「ejbCreate」
* というメソッドに必ず対応する 1 つまたは複数の create メソッドをサポートできる
*
* @author Copyright (c) 1998 by WebLogic, Inc. All Rights Reserved.
* @author Copyright (c) 2001 by BEA Systems, Inc. All Rights Reserved.
*/
public interface WeatherHome extends EJBHome {
/**
* このメソッドは、「WeatherBean.java」の ejbCreate
* メソッドに対応する。
* 2 つのメソッドのパラメータ セットは同じ。クライアントが
* <code>WeatherHome.create()</code> を呼び出すと、コンテナが EJBean
* のインスタンスを割り当てて <code>ejbCreate()</code> を呼び出す
*
* @return Weather
* @exception 通信またはシステムに障害がある場合は
* RemoteException を送出
* @exception Bean の作成時に問題が生じた場合は
* CreateExceptionを送出
* @see examples.ejb.basic.statelessSession.WeatherBean
*/
Weather create() throws CreateException, RemoteException;
}
BEA XML エディタを使用した ejb-jar.xml ファイルおよび weblogic-ejb-jar.xml ファイルの作成および編集については、
XML ファイルの編集を参照してください。
次の例は、Weather EJB に関する ejb-jar.xml デプロイメント記述子を示しています。
<?xml version="1.0"?>
<!DOCTYPE ejb-jar
PUBLIC '-//Sun Microsystems, Inc.//DTD Enterprise JavaBeans 1.1//EN'
'http://java.sun.com/j2ee/dtds/ejb-jar_1_1.dtd'>
<ejb-jar>
<enterprise-beans>
<session>
<ejb-name>statelessSession</ejb-name>
<home>
examples.webservices.rpc.weatherEJB.WeatherHome
</home>
<remote>
examples.webservices.rpc.weatherEJB.Weather
</remote>
<ejb-class>
examples.webservices.rpc.weatherEJB.WeatherBean
</ejb-class>
<session-type>Stateless</session-type>
<transaction-type>Container</transaction-type>
</session>
</enterprise-beans>
<assembly-descriptor>
<container-transaction>
<method>
<ejb-name>statelessSession</ejb-name>
<method-intf>Remote</method-intf>
<method-name>*</method-name>
</method>
<trans-attribute>Required</trans-attribute>
</container-transaction>
</assembly-descriptor>
</ejb-jar>
次の例は、Weather EJB に関する weblogic-ejb-jar.xml デプロイメント記述子を示しています。
<?xml version="1.0"?>
<!DOCTYPE weblogic-ejb-jar
PUBLIC '-//BEA Systems, Inc.//DTD WebLogic 5.1.0 EJB//EN'
'http://www.bea.com/servers/wls510/dtd/weblogic-ejb-jar.dtd'>
<weblogic-ejb-jar>
<weblogic-enterprise-bean>
<ejb-name>statelessSession</ejb-name>
<caching-descriptor>
<max-beans-in-free-pool>100</max-beans-in-free-pool>
</caching-descriptor>
<jndi-name>statelessSession.WeatherHome</jndi-name>
</weblogic-enterprise-bean>
</weblogic-ejb-jar>
EJB クラス ファイルおよびデプロイメント記述子を weather.jar アーカイブ ファイルにアセンブルするには、次の手順に従います。
META-INF サブディレクトリを作成します。
META-INF サブディレクトリに ejb-jar.xml および weblogic-ejb-jar.xml デプロイメント記述子をコピーします。
weather.jar アーカイブ ファイルを作成します。
jar cvf weather.jar -C
staging_dir.
BEA XML エディタを使用した build.xml ファイルの作成および編集については、
XML ファイルの編集を参照してください。
次の build.xml ファイルは、weather.jar アーカイブ ファイルを WebLogic Web サービス weather.ear エンタープライズ アプリケーション アーカイブ ファイルにアセンブルする wsgen Java ant タスクを例示します。
<project name="weather-webservice" default="wsgen">
<target name="wsgen">
<wsgen
destpath="weather.ear"
context="/weather">
<rpcservices path="weather.jar">
<rpcservice bean="statelessSession" uri="/weatheruri"/>
</rpcservices>
</wsgen>
</target>
</project>
|
|
|