第15章
プロジェクトの設計、作成、およびテストを完了したら、次のステップではプロジェクトを実行するアプリケーションサーバに展開します。 Novell exteNd (Professional Edition、Enterprise Editionとも)には、Composerプロジェクトを展開するためのツールがあります。 Professional Editionの場合、exteNd Directorを使って展開します。 一方Enterprise Editionには、これ以外にも、Composerから対応アプリケーションサーバ(Novell exteNd、WebSphere、WebLogic、Tomcat)に、直接プロジェクトを展開する機能があります。Directorのパッケージ化機能は使う必要がありません。
この章では次のような事項を解説します。
展開用生成物の作成、管理に使う、Composerの設計時ユーザインタフェース(Enterprise Editionのみ)
Novell exteNd Directorに組み込まれている、Composer関係のウィザード(Professional Edition、Enterprise Editionとも)
アプリケーションサーバの管理その他については、 『Composer Enterprise Serverユーザガイド』を参照してください。 この章では解説していない事項については、この資料を参考にしてください。
注記: ここではJ2EE展開に関して基本的な知識があるものとして解説します。JAR (Java Archive)、WAR (Web Archive)、およびEAR (Enterprise Application Archive)のパッケージ化、展開記述子などといった事項です。必要に応じて、J2EE展開アーキテクチャに関する文献を参照してください。
Composerサービスを展開する前に、次の事項を検討する必要があります。
パッケージ化の有無 - Composerからアプリケーションサーバ環境に、個別にサービスを展開するか、それとも、プロジェクト全体(サービス群を含む)を、Novell exteNd Director(または同様の環境)で、WARまたはEARファイルとしてパッケージ化して展開するか?
トリガの必要性 - サービスがどのような形で起動されるようにするか? トリガオブジェクトとしては、サーブレット、EJB、サーブレット経由でトリガがかかるEJB、プログラム的に(直接)サービスを呼び出すカスタムJavaクラス、またはComposerタグライブラリルーチンを使うJSPがあります。 JMS ConnecFormリソースがインストールされていれば、キューに入って来る要求を(JMS) MessageListenerオブジェクトで監視(listen)し、サービスを起動することも可能です。 SAP Connectがあれば、SAP関数でサービスを起動することもできます (詳しくは該当する接続製品のユーザガイドを参照)。
着信データのパッケージ方法 - 着信データを、URI (HTTP GET)に追加されたURLエンコードされたparam/valueの対の形式にするか? サービストリガにより、マルチパートのMIME添付ファイルを使用してHTTP POSTから着信XMLを処理するか? あるいはSOAPサービスの形にするか? その場合、SOAPペイロードの暗号化やデジタル署名はどうするか?
共有リソース - WSDL、JSP、JAR、XSL、またはXSDファイルなどを、公開リソースとして展開し、他のComposerサービスと共有できるようにするか?
これらの事項は、Composerで作成したサービスの展開手順にも影響します。 サービスのタイプによっては、接続プール、コンテナベースのトランザクション管理、パスワードや公開キー情報のディレクトリ管理などについても検討する必要があります。
サービストリガとは、ある入力に応じてComposerサービスを起動するプロセス(サーブレット、Beanなど)のことです。 入力は、HTTP経由で受け取るか、SMTPを介して電子メールで受け取るか、JMSメッセージの形でキューに届けることができます。 受け付ける要求の種類、経由する伝送路により、さまざまなComposerトリガがあります トリガはComposerで作成するほか、exteNd Directorのコードウィザードで生成することもできます。
Composerは次のようなトリガを扱うことができます。
電子メール - サーバ上のあるプロセスが定期的にメールボックスを確認(ポーリング)し、所定のサイズ以下の電子メールが届いていれば、Composerサービスを起動します。
サーブレット付きのEJB - サーブレットはあるURLに対するHTTP要求を監視(listen)し、Beanを仲介としてComposerサービスを起動します。
ファイル - サーバ上のプロセスが物理ドライブ上のある場所を監視し、 ファイルが追加されていればComposerサービスを起動します。
JMS - JMSがトピックノードを監視し、 メッセージが届いていればComposerサービスを起動します (Novell exteNd Enterprise Editionに含まれるComposerのみ対応)。
JSP - Java Server Pageにスクリプトレットが含まれており、ここからComposerサービスを直接呼び出します。
これらの「イベント駆動」トリガのほか、カスタムJavaクラスからComposerサービスを直接呼び出すこともできます。 Novell exteNd Directorには、必要なコードを生成するウィザードがあります (「Director JSPウィザード」および「Javaクラスウィザード」を参照)。
他のプロセスとの関係で、トリガには2つの役割があります。 所定のイヴェント(HTTP要求、電子メールの到着など)を監視(listen)して対応する処理を行う、という役割に加え、XMLデータを取得または作成し、入力データとして適切にComposerサービスに渡さなければならないのです。 トリガはそのために、所定の経路からデータを収集し、Composerで扱える形式にパッケージ化する方法を知っている必要があります。 Composer Serverにはさまざまなヘルパクラスがあって、トリガサーブレットで適切にデータをマーシャリングすることができます。ヘルパクラスはComposer Serverのインストール時に組み込まれます (詳しくは付録の「コンバータクラス」にある、JSPタグライブラリのメソッドに関する解説を参照)。
サーブレットは、たとえばHTTP GETまたはHTTP POSTの一部として、データを取得することができます。 ごく簡単なやり方としては、URLの末尾に付加された名前と値の組を、ユーザデータとして扱う方法があります(HTTP GETの場合)。 ただし、これ以外にも、SOAP要求、HTTP POST上のXML(フォームフィールドにXMLを埋め込み、ストリームデータとしてXMLを転送、またはマルチパートMIME形式で添付)など、さまざまな方法があります。 また、電子メールが届くと起動するトリガも定義できます。 この場合、XMLは電子メールに添付される形で届きます。
以下の説明では、Composerで使える基本的なトリガについて習熟しているものとして解説します。 必要に応じ、『Composer Enterprise Serverユーザガイド』の、トリガアーキテクチャに関する解説を参照してください。
展開に当たっては、プロジェクト内のサービスをすべて、EAR (Enterprise application archive)としてパッケージ化します。 これを「展開EAR」と呼びます。 展開EARは次のような構成になっています。
Composerから直接展開する場合は、自動的に次のような処理が次の順序で行われます。
サービスを記述したメタデータ(XML)をはじめ、展開するリソースをプロジェクトJARにパッケージ化します。 このJARファイルを、ステージングディレクトリ(一般にはプロジェクトディレクトリ以下のサブディレクトリ)に格納します。次に挙げるファイルもやはりこのディレクトリに格納することになります。
WARファイルを作成します。 ここには、前記のJARファイルを指すマニフェストと、サービス(およびそのURLバインド)に適用されるトリガサーブレットをすべて記述したweb-xmlファイルの、2つをパッケージ化します。アプリケーションサーバはこの記述に従ってサービスを公開することになります。
最後の転送処理は、展開先アプリケーションサーバの種類(およびバージョン)によって、具体的な手順が異なります。 EAR(および展開記述子)をアプリケーションサーバに転送するための手順を記述した、バッチファイルを自動生成することもあります。 また、Composer Enterprise Server側が主導する形で、展開EARを転送させる場合もあります。 どちらの場合も、ステップ4でウェブブラウザが起動されます。ユーザID、パスワードその他、展開に必要な情報を入力してください。
EARの展開後、サーバを再起動しなければならない場合もあります(アプリケーションサーバによって異なるので、該当マニュアルを参照してください)。
注記: 展開する前に、アプリケーションサーバとComposer Enterprise Serverを起動しておく必要があります。
展開EARを作成、展開する手順には、次のように何種類かあります。
ひとつ目は、Composerの設計画面から、あるプロジェクトの展開オブジェクトを自動的にインストールする方法です (Composerのスタンドアローン版、またはexteNd Suite Enterprise Editionのいずれかが必要です。 Professional Editionではこの方法は使えません)。 Composerで作成したWebアプリケーションを展開する、最も手軽な方法です。
2つ目の方法は、exteNd Directorのユーティリティツール画面を使い、展開EARを作成またはカスタマイズ、あるいはその両方を行うというものです。 この方法は、大きな展開ファイルの一部として、ポータルコンポーネントなどほかのJavaオブジェクトとComposerプロジェクトをEARファイルにまとめる必要がある場合に便利です。
3つ目は、JAR、WAR、またはEAR、あるいはこれらすべてを手で(またはサードパーティ製ツールで)作成し、展開も手で行うという方法です。具体的な手順は、アプリケーションサーバの推奨手順に従います。 展開に当たって特別な措置が必要な場合にのみ、この方法を検討してください。
次に最初の2つの方法について詳しく解説します。最初はComposerの設計画面から展開する方法です。
Enterprise EditionのComposerがあれば、ここから直接プロジェクトを展開できます (Professional Editionにはこの機能がありません。 次の「exteNd Directorからの展開作業」まで読み飛ばしてください)。
Composerの設計環境からプロジェクトを展開する手順を大雑把にまとめると、次のようになります。
サーバプロファイルには、展開先サーバおよび当該サーバに特有の情報を定義します。 Composerプロジェクトをアプリケーションサーバに展開する際には必須です (Tomcat、Novell exteNd App Server、WebSphereWebLogicなど、アプリケーションサーバのタイプには依存しません)。
注記: サーバプロファイルは、プロジェクトごとに用意するリソースではありません。 初期設定ファイルに保存しておけば、DirectorやComposerの、どのプロジェクトでも同じものが使えます。
作成に先立ち、展開先アプリケーションサーバ、exteNd Composer Enterprise Server (および必要な接続製品)が稼動していることを確認してください。
［サーバ名］の指定は、サーバタイプにかかわらず必須です。 上の例ではlocalhost:80と入力されています。これはローカルにインストールされたexteNd Application Serverを表します。
注記: 既存のサーバプロファイルを修正したい場合は、［ツール］メニューの［プロファイル］を選択し、［サーバ］タブに切り替えます。 変更したいプロファイルを選択し、［編集］ボタンをクリックします。 同様に、サーバプロファイルを削除したい場合は、［削除］ボタンをクリックします。
サービス、コンポーネント、およびリソースなどといった展開オブジェクトも、Composer xObjectの一種です。 展開に関するメタデータが含まれており、 どのようなサービストリガを作成し、どのようなりソースを展開するかという情報を記述します。
注記: この節で説明する事項は、Professional Editionには当てはまりません。 xObjectの展開は、Enterprise EditionのComposerでのみ可能です。 Professional Editorを使っている場合は、Director環境で展開生成物を作成、管理してください。 詳しくは「exteNd Directorからの展開作業」を参照してください。
展開オブジェクトも他のxObjectと同様、Composerのナビゲータペインで操作できます。
展開xObjectの作成は、他のxObjectを作成する場合と同様のウィザードで進めることができます。
ナビゲータツリーの［展開］上で右クリックし、［新規］をクリックします (または［ファイル］メニューから［新規］>［xObject］の順に選択し、コンポーネントパネルで［展開］を選択します)。
［基本URL]として、サービストリガその他のリソース(JSP、イメージなど)を指定するURLのプレフィックスを入力します。
さらに、J2EE 1.3以降を使っている場合は、不正アクセスを防ぐため、［リソースセキュリティの役割］も指定できます。
注記: リソースを使うComposerサービスでは、リソースセキュリティの役割を指定しても無視されます。
この画面では、プロジェクト(およびそのサブプロジェクト)にある、プロジェクト変数の値を上書きできます。実行時にはこの値が参照されることになります。 テーブルには、定義済みのプロジェクト変数とその値が表示されています。
作成済みの展開オブジェクトも、他のxObjectと同様に、各画面がタブに分かれた形のウィザード画面で編集できます。展開オブジェクトを右クリックし、［プロパティ］を選択してください。 値は必要に応じ、［プロパティ］ダイアログで変更できます。 画面例を次に示します。
ここでは展開作業に関する各種の操作方法を解説します。スタンドアローン版またはEnterprise-EditionのComposer設計環境が対象です(Professional Editionは不可)。
注記: exteNd Suite Professional Editionを使っている場合は、「exteNd Directorからの展開作業」まで読み飛ばしてください。
重要: 作業を進めるためには、適切なサーバプロファイル(「サーバプロファイル」を参照)、およびこのプロジェクトの展開コンテンツをパッケージ化した展開オブジェクト(「xObjectの展開」を参照)が作成済みでなければなりません。 また、SOAPサービスの場合のWSDLリソースなど、サービスの種類によって必要になるリソースについても、あらかじめ作成し、展開オブジェクトに追加しておく必要があります。
ここではドロップ&ドラッグによる操作について、手順を追って解説します。 これにより、トリガをサービスに簡単に関連付けることができます。 メニューコマンドを使っても同じことができます (次の節を参照)。
ドラッグ&ドロップの操作は簡単です。
サービストリガを作成するには、まず、ナビゲータペイン上でオブジェクトを右クリックします。 ただし、ここで注意が必要です。 サービストリガを作成するためには、次の2つの条件を満たしていなければなりません。
この条件が満たされていれば、このオブジェクトを使って作成できるサービストリガが、サブメニューに表示されるはずです。
注記: サービスをSOAP HTTPとして展開するためには、WSDLリソースと関連付けられている(メニューに表示されている)必要があります。
メニュー上のいずれかの項目をクリックすると、(ドラッグ操作の場合と同様、)展開ツリーペイン上に該当するエントリが作成されます。さらに、展開プロパティペインに、対応するプロパティシートが現れます。
サービストリガは、(Composerのメインメニューバーにある)［コンポーネント］メニューの［サービストリガの作成］以下でも作成できます(下の図を参照)。
このサブメニューからトリガの種類を選択すると、次のような小さなダイアログが現れます。
トリガに対応付けるサービスを、プルダウンメニューから選び、 ［OK］ボタンをクリックします。
注記: サービストリガのうちJMSおよびSAPは、対応する接続製品がインストールされていなければ選択できません。
あるメールボックスに電子メールが届くとComposerサービスが起動されるよう設定することができます。 電子メールはペイロードとして扱われるので、関数アクションを使ってたとえばInput.getXML()の戻り値をSystem.outに出力すれば、次のように、電子メールメッセージ全体がXML形式でシステムコンソールに表示されます。
<?xml version="1.0" encoding="UTF-8"?>
<Message>
<X-Auth-OK>joeblow@smtp-send.myrealbox.com</X-Auth-OK>
<Return-Path><jblow@myrealbox.com></Return-Path>
<Received>from JBLOW-DT1 jblow@smtp-send.myrealbox.com [12.23.52.5]
by smtp-send.myrealbox.com with NetMail SMTP Agent $Revision: 3.42 $
on Novell NetWare;
Mon, 29 Sep 2003 13:09:23 -0600</Received>
<Message-ID><13140405.1064862444476.JavaMail.JBlow@JBLOW-DT1>
</Message-ID>
<Date>Mon, 29 Sep 2003 15:07:24 -0400 (EDT)</Date>
<From>joeblow@myrealbox.com</From>
<To>joeblow@myrealbox.com</To>
<Subject>Trigger Test Mail</Subject>
<Mime-Version>1.0</Mime-Version>
<Content-Type>text/plain; charset=ASCII</Content-Type>
<Content-Transfer-Encoding>7bit</Content-Transfer-Encoding>
<Body charset="ASCII" encoding="7bit" subtype="plain" type="text">This is a test message
</Body>
</Message>
電子メールトリガを作成するには次の情報が必要です。
アカウント名およびパスワードは、「Mail Simple認証」接続リソースの形式で記述しておく必要があります (作成手順については、「Mail Simple認証接続リソース」の、接続リソースに関する説明を参照)。 まだ作成していない場合は、次に進む前にここで作成しておいてください。
さらに、メールボックスを確認する頻度、所定のサイズ以上の電子メールは無視するかどうかも決めておく必要があります。
電子メールの到着を検知、処理すると、メールボックスからは削除されてしまうことに注意してください。 (サイズ制限などの理由で)処理されなかった電子メールメッセージはそのまま残ります。
サービスを展開ツリーの「電子メール」ノード(「サービストリガ」の下)にドラッグします。 マウスボタンを離すと、次のようなプロパティシートが表示されます。
［ポーリング間隔］に、メールボックスを確認する頻度(時間間隔)を、秒単位で指定します。
注記: 電子メールが届いてサービスが起動された場合、そのサービスの処理が終了するまでは、メールボックスの確認を行いません。 したがって、たとえば確認頻度を10秒と設定した場合、サービスの処理に2秒かかるとすれば、電子メールが検出されてから次にメールボックスを確認するまでに、12秒程度かかることになります。
［メッセージサイズ］に、キロバイト単位の数値を入力します。これより大きな電子メールメッセージは無視することになります。 これより小さな電子メールはすべて処理の対象になります。 サービスが起動され、これにメールが渡され、処理の中でメールボックスから削除されます。 指定サイズ以上の電子メールは無視されます。
EJBトリガをサービスに関連付ける手順は簡単です。 既に説明した、サーブレットやJSPの場合とほとんど同様です。
サービスを展開ツリーの「EJB」または「サーブレット付きのEJB」ノード(「サービストリガ」の下)にドラッグします。 サービスを「サーブレット付きのEJB」カテゴリノードにドロップすると、次のようなプロパティシートが表示されます。
(Enterprise Editionの場合のみ) ［トランザクション属性］ドロップダウンリストから、該当するJTAトランザクションを選択します。次のオプションを選択できます。
サービスの出力を変換するためにスタイルシートリソースを使う場合は、［スタイルシートリソース］プルダウンメニューから選択します。
注記: これを指定するのは一般に、［出力タイプ］としてXHTMLを選択した場合です。
複数の言語に対応したスタイルシートがあり、どの言語を使うか指定する場合は、［言語］ボタンをクリックします。ダイアログボックスが表示されます。
注記: このダイアログの詳細および想定する使い方については、「リソースの多言語対応機能」を参照してください。
J2EE 1.3以降用のアプリケーションであれば、［セキュリティ役割］を指定できます。
注記: これはアクセス制御のためにJ2EEで定義された機構です。 このレイヤの実装はアプリケーションサーバ依存です。 Composerには実装されていません。 J2EEのセキュリティ役割という概念については、Sunのウェブサイトまたはアプリケーションサーバの資料、あるいはその両方を参照してください。
注記: サーブレットを伴わない普通のEJBであれば、指定が必要なのは［JNDIパス］、［トランザクション属性］、および［セキュリティ役割］だけです。
ファイルトリガを使えば、ローカルハードディスク上の所定のパスに新規ファイルが追加されたのを検出し、サービスを起動するという設定ができます。 作業の流れに合わせ、ドキュメントの処理が必要になった都度、自動的に処理されるようにしたい場合に有用です。
ファイルトリガを使用すると、サーバ上のプロセスがローカルハードディスク上のあるフォルダ(またはそのサブディレクトリ)を定期的に監視し、新しいファイルが追加されていないかどうか調べます (時間間隔は自由に設定できます)。 追加されているのを検出すると、Composerサービスを起動し、ファイルを1つずつ渡して処理を任せます。 細かく言うと、ファイルを検出するごとに、次のイベントが発生します。
ファイルをコピー先ディレクトリにコピーします。 このコピー先ディレクトリは、設計時に、トリガの設定として指定できます(手順は後述)。 ここでは例として、コピー先が\destであるとします。 Composerは処理するべきファイルごとに、\dest以下に新しいフォルダを作成します。 フォルダ名はタイムスタンプを元に、 たとえば2003.09.30_08.54.48というようになります。 したがって元のファイルは、\dest\2003.09.30_08.54.48以下にコピーされることになります。
トリガに指定したファイル処理タイプにより、ファイルの中身そのもの、またはファイルのコピーを指すURIを、入力としてサービスに渡します。 ファイル処理オプションとしては次のようなものがあります。
サービスの出力メッセージパートは、(タイムスタンプを元にした名前のディレクトリ以下の、)output.xmlというファイルに書き込まれます。
ファイルトリガがサービスにデータを渡す方法は、次の3とおりから選択できます。
監視対象ディレクトリに追加されたファイルを、整形式XMLであると想定して処理します。
追加されるファイルがXML形式とは限らない場合に適しています (たとえば、 EDIファイル)。 ファイルの中身をそのままCDATAセクションに埋め込みます。したがって、サービスの入力ドキュメントは次のようになります。
<?xml version="1.0" encoding="UTF-8"?> <ルート> <![CDATA[ 入力ファイルの中身 ]]> </Root>
初期状態では、ルート要素の名前はRootとなっています。 後述のように、これは変更できます。
注記: バイナリファイルの中身をCDATAとして埋め込むと、XMLでは不正な文字が含まれる可能性があるので、適当ではありません。 したがって、バイナリファイルを処理する場合、またはXMLとして不正な文字が含まれうるファイルを処理する場合は、［XMLの埋め込みコンテンツ］は使用しないでください。 その場合は［ファイル参照］を指定して、コンポーネント内では、［Base64エンコード］を有効にした「URL/ファイルの読み込み」アクションでファイルを読み込むようにします (Base64エンコードを使わず、データをそのまま読み込んで処理する場合は、ファイルI/O操作を行うカスタムJavaクラスを用意してください)。
入力は次のようになります。
<?xml version="1.0" encoding="UTF-8"?> <Root>..\dest\2003.09.30_09.10.15\myIncomingFile.dat</Root>
初期状態では、ルート要素の名前はRootとなっています。 これは変更できます。
注記: パス名はすべて、アプリケーションサーバの\binを基準とした相対パスです。 ただし、この動作も変更できます。
サービスを展開ツリーの「ファイル」ノード(「サービストリガ」の下)にドラッグします。 マウスボタンを離すと、次のようなプロパティシートが表示されます。
［ソースディレクトリ］に、(ローカルディスク上の)監視対象ディレクトリを指すURIを入力します。 相対URIでも完全修飾URIでも構いません。相対URIであれば、アプリケーションサーバのインストールディレクトリ以下にある\binが基準となります。絶対URIならば、たとえばd:\tempというように指定します。
注記: ソースディレクトリをサービスの展開前に作成しておく必要はありません。
［入力タイプ］ドロップダウンメニューから、ファイルの中身をどのように処理するかを選択します (「ファイル処理オプション」の説明を参照)。
［XMLの埋め込みコンテンツ］または［ファイル参照］を指定した場合は、入力ドキュメントのルートノード名を入力します。 初期状態ではRootとなっています。 XMLとして適切ならば、どのような要素名にしても構いません。
［ポーリング間隔］に、ソースディレクトリにファイルが追加されていないか確認する時間間隔を、秒単位で指定します。
注記: サービスの実行中はこの確認を行いません。 処理が終了次第、時間の計測を再開します。
上述のように、追加されたファイルのコピーを作って処理することになりますが、そのコピー先ディレクトリを［Destination Directory］に入力します (処理対象ファイルごとに、タイムスタンプを元にした名前のフォルダがこの下に作られます)。
ファイルトリガを使うサービスのファイルI/O処理部分は、通常のデバッグ方法ではテストできません。トリガによるポーリングやファイル処理、および出力の機能は、サーバ上でしか動作しないからです。 ファイルトリガを使うサービスをテストするには、サーバに展開する必要があります。
もちろん「アクションモデル」で記述した部分は、サービスのビジネスロジックを実装した一般のコンポーネントと同じようにテスト、デバッグできます。 実際の入力データを使ってアクションモデルを動かしてみるためには、実稼働環境でComposerが作成するのと同様のXMLドキュメントを、仮に作っておく必要があるかも知れません (詳しくは「ファイル処理オプション」のXML例を参照)。 サンプルドキュメントを使ってアクションモデルをデバッグし、その後、サービスを展開してテストしてください。
サービスのフロントエンド部分をJSPで作成する場合、JSPからサービスへのバインドを、次のようにして設定します。 なお、当該Java Server Page用のJSPリソースは、事前に作成しておかなければなりません (具体的な手順は、リソースに関する章の「JSPリソースについて」を参照してください)。
JSPリソースが、トリガツリー内、JSPノードの下に追加されます。また、JSPプロパティシートが、右側のエディタペインに現れます(図を参照)。
注記: ［セキュリティ役割］はJ2EE 1.3でのみ有効です。
多くの場合、サービスを起動するサーブレットは、所定のURLに届いた要求を処理するようになっています (サーブレットはJSPから起動される場合とそうでない場合があります。 ここで解説するサーブレットは、JSPから起動されるものではありません。 JSPをあるサービスにバインドしたい場合は、「JSPベースのトリガの定義」を参照してください)。 サーブレットがデータを受け取る方法には、HTTP GETまたはHTTP POSTの2種類があります。HTTP POSTの場合、XMLデータはフォーム上のあるフィールドに入っているか、マルチパートMIME形式で受け取るか、またはコンテンツストリームの一部として受け取ることになります。
［URL］に展開URLを指定します。 これはサービスのURLの末尾部分になります。 最終的なURLは、たとえば次のようになります。
http://localhost:80/[MyDataBase]/[MyDeploymentEAR]/myurl
ここで[MyDataBase]は、アプリケーションサーバ上の展開先データベースを表します(Novell exteNdアプリケーションサーバのみ)。[MyDeploymentEAR]はComposerプロジェクト名(Professional Edition)または展開xObject名(Enterprise Edition)です。myurlは［URL］として指定した値です。
［サーブレットタイプ］ドロップダウンリストから、サービスへの入力として使うデータソースを選択します。 選択肢として次のようなものがあります。
［出力タイプ］ドロップダウンリストから、サービスの応答データのMIMEタイプを選択します。 選択肢として次のようなものがあります。
注記: ［セキュリティ役割］はJ2EE 1.3でのみ有効です。
SOAPトリガをWebサービスに関連付ける手順も、他のトリガの場合と同様です。
注記: 次の説明は、SOAP、WSDLおよびXML署名の概念に習熟しているものと想定しています。 先に進む前に、必要に応じてWebサイトhttp://www.w3.orgまたはその他の情報源、あるいはその両方を参照してください。
サービスを展開プロファイルツリーの「SOAP HTTP」ノード(「サービストリガ」の下)にドラッグします。 プロパティシートペインが次のように変わります。
プロパティシートで、サービスの［URL］を指定します。 これはURLの末尾部分です(完全なURLではありません)。
注記: このURLに対してHTTP GETを発行すると、このサービスのWSDLが返されます。 このURLに対して実際にSOAP要求を送れば、サービスが起動されます。
重要： 展開後、この値はサービスのWSDLの<service>要素に反映されます。 子要素<port>および<soap:address>にも反映されます。 <service>要素は、ここで指定したURLを使うようダイナミックに更新されます。
［バインド］が表示されていなければ、適切な値を選択します (WSDLによっては、複数のバインドが定義されていることがあります。この場合、先に指定したURLに適用するバインドを選択できます。 通常はデフォルト値のままで構いません)。
必要に応じ、［証明書リソース］を選択します。このドロップダウンリストには、プロジェクトに関連付けられている証明書リソースが列挙されています。 XML署名スキームを使って、外向きの応答に署名する場合にのみ必要です (証明書リソースの使い方については「証明書リソースについて」を参照)。
デジタル署名されたSOAP要求しか受け付けないことにする場合は、［XML署名の検証］チェックボックスをオンにします。
注記: このチェックボックスをオンにすると、要求のSOAPヘッダに、XML署名標準に準拠したデジタル署名が必要になります。 署名がなければSOAP障害が発生します。
タイマトリガは、イベントとは無関係に、定期的にComposerサービスを起動したい場合に使います。 用途はさまざまです。 たとえば、次のような用途があります。
Composerのタイマトリガには、起動時刻の指定方法によって、 2つの種類があります。 ひとつは「スケジュール」にもとづく方式で、 カレンダー上の日付を指定します。 これを「カレンダーベースの反復」、あるいは単に「反復」と呼びます。 Composerではいろいろな「反復」パターンを設定できます。 所定の日時に1回だけ処理を行う(0回の「反復」)ことも、日時をいくつも指定しておく(一定間隔でなくても可)こともできます。 ここで大切なのは、ある特定の日に処理が始まり、それが0回以上反復されるよう、「スケジュール」を決めることができるということです。
2つ目は、一定の間隔で、所定の回数だけ繰り返す、という形のタイマトリガです。 カレンダー上の日付とは無関係に、「Y秒間隔でX回処理を繰り返す」という形で起動するトリガです。 したがって、［count］と［interval］をパラメータとして指定します。
この2つを組み合わせれば、起動スケジュールをきめ細かく設定できます。 たとえば次のように使います。
Composerでは、日次、週次、月次の起動設定が可能です。 週次の場合、さらに細かく、毎日曜日、火曜から土曜、月水金、などといった指定もできます。 また、月次の場合、初日、末日、特定の日、という指定が可能です。
サービスを展開ツリーの「タイマ」ノード(「サービストリガ」の下)にドラッグします。 マウスボタンを離すと、次のようなプロパティシートが表示されます。
所定の日に起動されるよう設定したい場合は、［カレンダー］ボタンをクリックします。 次のようなダイアログが現れます。
ダイアログ上のボタン類を使って、サービスを最初に起動する日時を選択します。 ［OK］をクリックして、ダイアログボックスを閉じます。 この日時は、プロパティーシートの［日付と時刻］フィールドに表示されます。
反復プロセスにする場合は［反復］ボタンをクリックします (何も指定していない場合は、「非繰り返し」という表示になっています)。
注記: ［反復］ボタンを押せるのは、［日付と時刻］が指定されている時に限ります。 押せない状態であれば前のステップに戻ってください。
［時間］(ダイアログの下方)に、24時制で、サービスを起動する時刻を指定します。 必要に応じ、［時間の選択］ボタンを押して、時刻選択ダイアログを開きます。上下の矢印で時および分を指定することができます。
［終了日］に、サービスを起動する最終日を「YYYY-MM-DD」という形式で入力します。 必要に応じ、［日付の選択］ボタンを押して、日付選択ダイアログを開きます。マウス操作で日付を指定することができます。
［実行間隔］に、起動する時間間隔を指定します (Composerは、サービスの処理が終了した時点でタイマを0に戻し、次に起動するまでの時間を計り始めます)。 秒単位ならば「s」、時間単位ならば「h」、日単位ならば「d」という文字を数値の後に付けてください。 たとえば「8h」と書けば「8時間」の意味になります。 単位を明示しなければ秒単位と看做されます。
［反復］、「実行間隔］、［実行回数］の組み合わせによっては、あまり意味がない設定もあります(たとえば、日次、25時間ごと、10回、という指定)。 ただし、特に警告等が現れることはありません。 指定されたとおりに計時し、時刻が到来すればサービスを起動する、というだけのことです。 期待どおりの動作になるかどうかもわかりません。 パラメータの妥当性は自分で確認してください。
オブジェクト詳細ペインに並んでいるリソースオブジェクトは、展開の対象に追加することができます。その手順は簡単で、展開オブジェクトツリーペイン上の、該当するツリーノードにドラッグするだけです。 すると当該カテゴリに新しい子が追加されます。 ただし、カテゴリとして適切なノード上にしかドロップできません。 それ以外の箇所にマウスカーソルがある間は、円に斜線を引いた「進入禁止」カーソルになります。
ドラッグ&ドロップ方式で操作すると、手軽に展開のための作業ができます。 たとえば イメージリソースを展開する場合、そのリソースをオブジェクト詳細ペインから、展開ツリーペインの「イメージ」ノード上にドラッグします。 リソースに関連付けられているプロパティはないので、展開プロパティペインは空のままです。 URLは、リソースタイプ、および展開オブジェクトの作成時に定義された基本URLを元に、自動的にデフォルト値が決まります。
条件を満たせば、インスタンスペインでリソースを右クリックすると、オブジェクトを展開するためのコンテキストメニューが現れます。 そのためには次の2つの条件を満たす必要があります。
展開オブジェクトで「公開可能」、すなわち外部に対して公開して構わないと設定されたリソースであること。 たとえばイメージリソースは、あるURLで参照する形で公開できます。ただし、カスタムスクリプトリソースは一般に公開できません。Composerの内部で使うものだからです。
これらの条件が満たされている場合に限り、右クリックするとコンテキストメニューが現れます。その一番下に［発行］コマンドがあります。
必要なサービスやリソースをすべて展開xObjectに追加し、トリガとの関連付けも完了すれば、いよいよアプリケーションサーバへの展開作業に取り掛かります。
プログレスバーが100%に達すると、ブラウザが起動され、次のような画面になります (この例は、Novellアプリケーションサーバに展開すると想定したものです。 他のアプリケーションサーバの場合、画面構成が多少異なります)。
アプリケーションサーバにアクセスするためのユーザ名とパスワードを指定し、［次へ］ボタンをクリックします。 次の画面に切り替わります。
Novell 5.xアプリケーションサーバに展開する場合、プロジェクトEARを展開するための、データベース名を問い合わせる画面になります。 デフォルト値はSilverMasterです。
展開アーカイブ名(ページ上部に斜体で表示されているファイル名)をコピーし、テキストフィールドに貼り付けます (［参照］ボタンを使って、展開したいアーカイブをファイルシステム上で検索しても構いません)。 これはステージングエリアに作成された展開EARです(ステージングエリアについては「展開オブジェクトを作成する」を参照)。
［完了］ボタンをクリックします。 展開処理の結果が表示されます。
このページを見ると、プロジェクトが正常に展開されたかどうかを確認できます。 エラーが生じた場合は、通常、問題の解決に役立つよう、完全なスタックトレースが表示されます (上記の過程で、次の画面に進む間にかなりの遅延が生じると、タイムアウトにより接続が切れてしまうことがあります。 このような場合は展開作業を最初からやり直してください)。
プロジェクトをパッケージ化して展開EARアーカイブを作成する作業は、Composer側の組み込み機能を使うほか、exteNd Directorで行うこともできます。
注記: Professional EditionのexteNdはComposerの展開xObjectに対応していません。したがって、Professional Editionで作成したComposerアプリケーションの展開は、以下に説明する方法で進めるしかないことになります。 Enterprise Editionの場合は、次に説明するようにDirectorで展開する方法ばかりでなく、既述のようにComposerから直接展開する方法も使えます。
大雑把な流れだけ示すと、展開の基本的な手順はごく単純です。 Directorを立ち上げ、EARベースまたはDirectorのプロジェクトを作成またはオープンし、そのサブプロジェクトとしてComposerの.spfファイルを追加します。 次に、Directorの［ファイル］メニューから［新規］>［Webサービス］>［Composer Webサービス］の順に選択して、Webサービス(SOAP)、通常のサーブレット、EJB、Javaクラス、またはJSP用のウィザードを呼び出し、展開情報を作成します。 プロジェクト内のサービスすべてについて展開情報を作成した後、DirectorのJ2EE EAR/WARパッケージ化および展開ウィザードを使って、実際の展開作業を始めます。
Directorにはコード生成機能もあり、JavaコードからComposerサービスを直接起動する、さまざまなスケルトンファイルを生成できます (詳しくは後述)。 このごく単純なソースコードを元に、必要に応じて上書きや拡張を行うことにより、目的に合ったサービストリガを比較的容易に作成可能です。
注記: ほかにもDirectorには、J2EE展開をはじめさまざまな機能があります。詳しくはNovell exteNd Directorの関連資料を参照してください。
DirectorプロジェクトにComposerの(サブ)プロジェクトが含まれていれば、Directorウィザードを使ってサービスの展開パラメータを指定し、SOAPサーブレットで起動されるようにすることができます。 その手順を次に示します。
ComposerサービスをSOAPサービスとして展開するよう準備する
重要： 次の作業を進めるためには、EAR、WAR、またはEJB-JARプロジェクトをDirectorで開いておく必要があります。 また、そのサービスのWSDLも必要です (WSDLの自動生成については、リソースに関する章の「既存のサービスからWSDLリソースを生成する、またはXMLエディタでWSDLリソースを作成する」を参照してください)。
Directorで<Control>-<N>キーを押すか、［ファイル］メニューから［新規］>［ファイル］の順に選択します。 ［新規ファイル］ダイアログが表示されます。
［Webサービス］タブで、［Composer Webサービス］を選択して［OK］をクリックします。 Composer Webサービスウィザードの最初の画面が現れます。
必要ならば［ 要求のXML署名の検証］チェックボックスをオンにします。こうすると、(XML署名の標準に従い)デジタル署名されたSOAP要求しか受け付けないようになります。
DirectorプロジェクトにComposerの(サブ)プロジェクトが含まれていれば、Directorウィザードを使ってサービスの展開パラメータを指定し、サーブレットまたはJSPで起動されるようにすることができます。 その手順を次に示します。
Composer WebサービスにトリガをかけるサーブレットまたはJSPを作成する
重要： 次のステップを進めるためには、EAR、WAR、またはEJB-JARプロジェクトをDirectorで開いておく必要があります。
Directorで<Control>-<N>キーを押すか、［ファイル］メニューから［新規］>［ファイル］の順に選択します。 ［新規ファイル］ダイアログが表示されます。
［Webサービス］タブで、［Composer Webサービス］を選択して［OK］をクリックします。 Composer Webサービスウィザードの最初の画面が現れます。
プルダウンメニューで［サービスターゲットタイプ］を選択します。 プロジェクトのタイプおよび内容により、実際に表示される選択肢は異なります。Professional EditionかEnterprise Editionかによっても違います。
［出力タイプ］プルダウンメニューから、サーブレットの出力フォーマットとして、 XMLまたはHTMLのいずれかを選択します。
［URLパス］フィールドに、サーブレットのURL名をあらわす文字列を入力します。 たとえば次のようなURLで送られた要求を処理するサーブレットならば、「abcdef」と入力することになります。
上記の［入力タイプ］として［パラメータ(URL/フォーム)］を選択した場合、［入力ドキュメントのトリガ］グループに次の2つのフィールドが現れます。
Directorには、各種のカスタムサービストリガコードを作成するための、支援用ウィザードがあります。 JSP、サーブレット、カスタムJavaクラスのコードを生成しておけば、これを使ってComposerサービスを直接実行できるようになります。
Composerサービスにトリガをかけるための、サーブレットソースコードを生成できます。Directorの［ファイル］メニューから［新規］を選択して、サーブレットウィザードを起動します。 前述のウィザードとは少し違い、Directorプロジェクトをあらかじめ開いておく必要はありません。 したがって、たとえばソースコードファイルを単に生成するだけで、使うのは後でよいのであれば、EARまたはWARプロジェクトを開くことなく、以下のような手順で生成できます。
Composerサービスにトリガをかけるサーブレットコードを作成する
Directorで<Control>-<N>キーを押すか、［ファイル］メニューから［新規］>［ファイル］の順に選択します。 ［新規ファイル］ダイアログが表示されます。
現在開かれているプロジェクトにサーブレットを追加するのであれば、図のように、［開いているWARプロジェクトに追加する］ラジオボタンを選択します (プロジェクトを開いていない場合、このボタンは淡色表示になっています)。 作成したファイルをディスクに保存するだけでよければ、2番目の［プロジェクトなし -- ファイルをディスクに書き込む］ラジオボタンを選択します。
このようにプロジェクトを開かない状態でサーブレットコードを生成した場合、このサーブレットを使うWebアプリケーションに合わせて、自分でweb.xmlファイルを記述する必要があることに注意してください (WARプロジェクトを開いた状態でウィザードを起動した場合は自動生成されます)。
DirectorのJSPウィザードを使うと、タグライブラリを呼び出す形でComposerサービスを起動する、Java Server Pageを作成できます。 その手順を以下に示します。
Directorで<Control>-<N>キーを押すか、［ファイル］メニューから［新規］>［ファイル］の順に選択します。 ［新規ファイル］ダイアログが表示されます。
［次へ］(または［完了］)をクリックしてウィザードを終了します。 生成されたJSPコードは、コードエディタに表示されます。
状況によっては、HTTPベースのサーブレットやJSPセッションではなく、Javaクラスから直接Composerサービスを起動しなければならない、あるいはその方が便利であることもあります。 Novell exteNd Directorには、Composerサービスを直接呼び出すメソッドを持つ、Javaスタブクラスを自動生成するためのウィザードがあります。
Composerサービスをプログラムから呼び出すJavaクラスを、Directorのウィザードで作成する手順を次に説明します。
Composerプロジェクト、またはサブプロジェクトとしてComposerを含むDirectorプロジェクトを開きます。
Directorで<Control>-<N>キーを押すか、［ファイル］メニューから［新規］>［ファイル］の順に選択します。 ［新規ファイル］ダイアログが表示されます。
必要に応じ、チェックボックスで、クラスの可視性、デフォルトコンストラクタの有無、main()メソッドの有無などを指定します。
Directorにより生成されるコードはごく単純なものです。 サービスに関する情報(サービス名など)を埋め込むべき箇所はコメントで示されています。 このコードによりGXSServiceComponentBeanのインスタンスを生成し、このインスタンスを使ってサービスを起動します。
注記: GXSServiceComponentBeanおよびその他のComposerランタイムフレームワーククラスについて詳しくは、AppServer/Composer/api_xsディレクトリにある、関連Javadocおよびソースコードアーカイブを参照してください。
ComposerのEARおよびWARファイルは、Directorからも、［プロジェクト］メニューの［アーカイブの展開］で展開することができます。 詳しくは、Directorのマニュアルを参照してください。
サポートされているアプリケーションサーバ環境での展開に関する特徴は、製品のバージョンおよびベンダにより多少異なります。 Composerプロジェクトを個々のサーバに展開する手順については、 別冊『Composer Enterprise Server User\xd5 s Guide for the Novell exteNd Application Server』を参照してください。WebSphereおよびWebLogicサーバに関しては、別にマニュアルがあります。 展開の際に問題となる、次のような事項についても上記のマニュアルを参照してください。
Composer Enterprise Server Framework APIを使って、カスタムトリガオブジェクトを作成したり、Composerオブジェクトをプログラムで操作する方法
Composer Enterprise Serverの追加情報およびComposerサービス全般のランタイムアーキテクチャ
Copyright © 2004 Novell, Inc. All rights reserved. Copyright © 1997, 1998, 1999, 2000, 2001, 2002, 2003 SilverStream Software, LLC. All rights reserved. more ...
