第13章
「サービス」は、Composerにおける実行の基本単位です。 Composerオブジェクト(xObject)は、作成するさまざまなコンポーネントをラップして、アプリケーションサーバ環境(要求で開始され、結果として応答を返す)内に処理の論理単位を作成するために使用されます。 サービスは通常、要求に応じる形で起動されます。複数のコンポーネントを順に実行する、条件により分岐する、といった形で実行されます(他のサービスを起動することもあります)。 サービスはURLで指定され、サーブレットからのトリガにより起動されます(そうしなくても構いません)。
Composerで作成されたWebアプリケーションの入り口点は「サービス」xObjectです。したがって、サービスに関する設計上の考え方や、サービスを処理するComposer実行時アーキテクチャについて理解しておくことが大切です。 この章では、サービスを作成し、効果的に使うために必要な事項を解説します。
この章では「Webサービス」という用語を汎用的に使います。 すなわち、アプリケーションサーバ上で動作するサービスのうちComposerで作成されたものは、すべて「Webサービス」と呼びます。HTTPセッションでサーブレット要求により起動されるもの、電子メールの到着により起動されるもの、独自のJavaクラスから直接起動されるものなど、形態を問いません。 さらに、Webに対するインタフェースを、WSDLで記述したものでも構いません(そうでなくても構いません)。
Composerでは、「SOAPサービス」自体はサービスタイプではなく、サーバ上でどのように起動されるかを指定する方法に過ぎません(データをマーシャリングするか否かにも無関係です)。 Composerでは、SOAP-HTTPを「トリガタイプ」として指定します。 サービスにトリガをかけるために、特別なサーブレットを使います。
同じサービスをさまざまな種類のトリガで起動できることも、指摘しておいた方がよいでしょう。 たとえば、(あまり現実的ではありませんが) HTTP GETで渡されるデータを処理するサーブレットや、フォームに入力されたデータをHTTP POSTで取得して処理する(他のURLの)サーブレットから起動でき、さらに、サーバ上のカスタムアプリケーションから、文字列オブジェクトの形でデータを渡して起動するようなサービスも作成できます。
exteNdには2種類のサービスがあります。 すなわち、WebサービスとJMSサービスです (JMSとはJava Messaging Serviceの略で、Sunが定義した、メッセージ指向ミドルウェアのインタフェースです)。 (通常) EARファイルとして展開するプロジェクトには、いずれかまたは両方のサービスが含まれます。 2つのサービスタイプは、Composerのナビゲーションフレームの［サービス］という見出しの下に、2つの異なるアイコンとして表示されます(次を参照)。
JMSサービスタイプをComposerで扱うためには、Novell exteNd Composer JMS Connectをインストールしておく必要があります(Novell exteNd Enterprise Editionに同梱)。ただし、Webサービスカテゴリは常に表示されます。
JMSサービスの決定的な特徴は、そのトリガ方法にあります。企業メッセージングを使用するサービスがWebからトリガされる場合、そのサービスは、Webサービスとして作成される必要があります。また、メッセージの着信によってトリガされる場合は、JMSサービスとして作成される必要があります。
サービスは、実質的にはexteNdコンポーネントの専用タイプです。 既に述べたように、サービスのアクションモデルでも、XMLマッピング、ループ、ログ出力、Try/On Fault、「決定」アクションや「スイッチ」アクションによる条件ブランチなど、コンポーネントが実行する処理のほとんどを実行できます。ただし、設計に当たっては、例外処理に関するものを除き、ビジネスロジックはコンポーネント側に記述するようにしてください。 「サービス」側で使うのは、コンポーネント、ログ、決定、関数、Try/On Fault、障害のスローの各アクションに限定するとよいでしょう (これらのサービスの使用例はコンポーネントを使用したサービスの作成を参照)。 接続やデータ関係の処理、ビジネスロジックの実装は、コンポーネントレベルで行います。
注記: サービスで実行できるコンポーネントに、数やタイプ(JDBC、XMLマップ、LDAPなど)の制限はありません。また、各コンポーネントを同期に(ひとつずつ順に)実行することも、非同期に(すべて同時に)実行することも可能です。 さらに、他のサービスを起動することもできます。
アプリケーションサーバでの処理の基本単位として「サービス」を使用することは、Composerアプリケーションの設計における主要な目的です。
Composer Webサービスは、URLで展開されたWSDL記述のサービスにすることができます(必須ではありません)。簡単に言うと、Composer Webサービスは、単に他のコンポーネントを呼び出すコンポーネントです。 コンポーネントではなく「サービス」である条件として、WebサービスのxObjectはサーバにあるサーブレットまたはJavaオブジェクトからトリガできることが必要でする。これに対して、コンポーネントのxObjectは、この方法ではトリガされません (Componentは「サービスによって呼び出されます」)。 サービスが通常の意味の「Webサービス」であるというのは、対応するWSDLファイルの記述に従ってエンドポイントとして公開されていることを意味します。
Webサービスを使用すると、 WSDLによって示される操作パターン(通知、一方向、要求-応答、または依頼-応答)を実装できます。 また、パブリックURLに展開したり、ローカルアプリケーションとして実行したりすることもできます。さらに、WSDLとの関連付けやSOAP要求の受け付けを行ったり行わなかったりすることもできます。
Webサービスの部分と機能は、次の図のとおりです。図の次には説明があります。
図の中で、グレーの大きな長方形は、Webサービスを表しています。数字が付いた影付きの楕円は、アクションモデルのアクションを表しています。入力XMLファイルと出力XMLファイル(正方形)、および呼び出されるコンポーネント(サービスの外にある小さな長方形)も表示されています。
このサービスの目的は、請求書(業界標準の形式で)を受信し、請求書が受信されたことを送信者に通知することです。サービスの完了には、XMLドキュメントとして受信される請求書の操作がいくつか必要です。
サービスは、次のように機能します。
サービスは、サービストリガ(展開時に作成されるオブジェクトで、一部の外部イベントに応答してサービスを起動するよう設計されている)によって呼び出されます。サーブレットは、そのサーブレットにHTTP Postを発行するビジネスパートナーのアプリケーションサーバによって起動したり、(グレーの長い矢印で示されているように)ホストサーバのJavaプロセスによってプログラムで起動したりできます。
この例の場合、サービスの最初のジョブは、ファイルを記述するログアクションを実行して、サービスのアクティビティを実行時に記録することです。
「独自の形式に変換」コンポーネントでは、業界標準の請求書形式を入力として使用し、企業の内部形式(独自の形式)にフォーマットされたXMLファイルを出力として返します。
サービスでは、別のコンポーネントアクションを実行して、メールの送信コンポーネントを呼び出します。「独自の形式」ファイルは、メールの送信コンポーネントに対する入力になります。
メールの送信コンポーネントでは、複数のアクションを実行し(XML交換アクションを使用して請求書から電子メールアドレスを抽出したり、メールの送信アクションを使用して電子メールを送信したりする)、XMLファイルであるeMailを返します。
JMSサービスの部分と機能は、次の図のとおりです。
JMSサービスは、前に説明したWebサービスと実質的な違いはなく、主な相違点は、メッセージがキュー(パブリッシュ/サブスクライブに関する用語では「トピック」)に入るとJMSサービスが起動されることにあります。JMSサービスでは、リスナによって登録されているキュー(またはトピック)にメッセージが入るとonMessage()メソッドが自動的に呼び出されるMessageListenerオブジェクトを実装します。onMessage()メソッドがサービスを実行します。
JMSサービスには、その性質上、JMS Connectを使用して作成されたメッセージの受信アクションが1つだけ含まれている必要があります。メッセージの受信アクションを使用すると、サービスでは、受信メッセージのデータにアクセスしたり、その受信を適切に確認することができます。
このサービスに対するアクションモデルの残りは、先に説明したWebサービスの場合と同様です。
注記: この例は、Novell Composer JMS Connectを購入してインストールした場合にのみ該当します。
新しいサービスは、新しいXMLマップコンポーネントを作成する場合と同様に作成します。XMLマップコンポーネントをまだ作成していない場合は、サービスを作成する前に必要なXMLテンプレートを作成する必要があります。 詳細については、XMLテンプレートの作成を参照してください。
サービスを作成する場合は、コンポーネントの場合と同様に、入力テンプレートと出力テンプレートを指定します。 サービスが、データを直接処理するようにではなく、コンポーネントを呼び出すよう設計されている場合、そのサービスに対して選択する入力テンプレートは、最初のコンポーネントによって使用されるテンプレートと同じになることがよくあります。また、出力テンプレートは、シーケンスの最後のコンポーネントに対する出力テンプレートと同じになることがよくあります。
独自のSOAPヘッダを使うSOAPサービスを作成する場合、ヘッダ用XMLテンプレートを別に作成しておく必要があります。
Composerウィンドウの［ファイル］メニューから、［新規］>［xObject］の順に選択し、［プロセス/サービス］タブから ［Webサービス］を選択します。
入力テンプレートおよび出力テンプレートを次のとおりに指定します。ヒントについては、サービスに対するXMLテンプレートの指定についてを参照してください。
［次へ］をクリックします。 一時/障害テンプレートパネルが表示されます。
必要ならば、スクラッチパッドとして使うテンプレートを、ダイアログの「一時メッセージ」ペインに指定します。 コンポーネントの処理に当たって一時的に使うだけの値を保持する、あるいは参照用としてのみ使う場合に便利です。 「障害メッセージ」ペインで、障害が起こった際、必要な情報をクライアントに返すためのXMLテンプレートを選択します。
入力XMLテンプレートをさらに追加するには、［追加］をクリックして、それぞれにパート名、テンプレートカテゴリ、およびテンプレート名を選択します。この手順を必要なだけ繰り返します。入力XMLテンプレートを「削除する」には、エントリを選択して［削除］をクリックします。
［次へ］をクリックします。 入力/出力ヘッダパネルが表示されます。
SOAPサービストリガを使う場合は、入力/出力/一時/障害ドキュメントを追加する(上述の)手順と同様に、入力/出力ヘッダパートを指定します。
［完了]をクリックします。すると、コンポーネントが作成され、サービスエディタが表示されます。
テンプレートにネームスペース宣言が存在する場合、Composerによって、ネームスペースの宣言アクションが新しいアクションモデルの上に自動的に生成されます。
JMSサービスの作成は、Webサービスウィザードと多くの共通点を持つウィザードを使用して行います。 段階的な手順については、『exteNd JMS Connectユーザガイド』を参照してください。
インポート機能を使用すると、別のプロジェクトで作成されたComposerサービスのコピーを作成できます。インポートしたら、現在のプロジェクト内で使用するためにサービスをカスタマイズすることができます。
exteNd Composerウィンドウの［サービス］項目を右クリックするか、またはメインの［ファイル］メニューから［xObjectのインポート］を選択します。
［ファイル名］フィールドで、インポートするサービスの名前を入力するか、または［参照］ボタンを使用してサービスを検索します。 URLを指定してファイルをインポートすることもできます。「http://」、「https://」、あるいは「ftp://」という文字列を、ファイル名の前に置いて明示してください。
サービスエディタは、(通常は)コンポーネントやサービスの実行を指定したり、エラーログ、決定、および機能を実行したりする場所です。また、入力および出力の構造やデータをマップ、変換、および転送することもできます。
サービスエディタを使用すると、サービスの入力、出力、およびアクションを視覚化して操作するための論理的な作業環境が提供されます。サービスエディタは、複数のマッピングペインと1つのアクションモデルペインで構成されます。マッピングペインには、サンプル入力ドキュメントとサンプル出力ドキュメントのDOMが表示されます。 アクションモデルには、DOMで動作するアクションが表示されます( この環境は、実質的にはXMLマップコンポーネントエディタと同じです)。
サービスエディタには、XMLマップコンポーネントエディタと同じ機能がすべて備わっています。サービスエディタの使用の詳細については、次のトピックを参照してください。
サービスは、通常は、1つまたは複数のコンポーネントアクションで構成されます。それぞれのアクションでは、アプリケーション内で呼び出される次のコンポーネントまたはサービスで使用するデータのマッピング、変換、または転送、あるいはこれらすべてを行う特定のタスクを実行します。
指定したランタイムの入力DOMおよび出力DOMが存在するコンポーネントまたはサービスを呼び出して実行するには、コンポーネントアクションを使用します。
アクションモデルで、コンポーネントまたはサービスへの呼び出しを配置する行を選択します。選択した行の下に新しいアクションが挿入されます。
［アクション］メニューから、［新規アクション］、［コンポーネント］の順に選択します。［アクションコンポーネント情報］ダイアログボックスが表示されます。
［事前定義］ラジオボタンが選択されていない場合、クリックしてオンにします (コンポーネントアクションの事前定義とダイナミックの違いについては、第7章を参照)。
Componentアクションは、サービスに対して追加すると、サービスエディタのアクションモデルペインに表示されます。 サービスのアクションモデルは、コンポーネントが呼び出される順序を表します。
アクションモデルの例は、次のとおりです。
アクションモデルの機能にはログ機能がいくつかあり、コンポーネントを次のとおりに実行します。
最初のComponentアクションでは、コンポーネント(ProductLookup)を呼び出します。 これによって、DOMは、コンポーネントがサービスからデータを受信する入力ドキュメントハンドル(Input)として渡されるよう指定され、また、コンポーネントの出力(ProductLookupOutput)を受信するようにも指定されます。
2番目のComponentアクションでは、コンポーネント(InventoryLookup)を呼び出します。 これによって、DOMは、コンポーネントがサービスからデータを受信する入力ドキュメントハンドル(Input)として渡されるよう指定され、また、コンポーネントの出力(InventoryLookupOutput)を受信するようにも指定されます。
3番目のComponentアクションでは、コンポーネント(MergeProductAndInventory)を呼び出します。 これによって、Input DOMおよびInput1 DOMとしてコンポーネントがサービスからデータを受信するProductLookupOutputおよびInventoryLookupOutputというDOMが渡され、サービスDOMはコンポーネントの出力(Output)を受信するよう指定されます。
exteNdには、異なるコンピューティング環境にアクセスできるさまざまなConnectコンポーネントが用意されています。すべてのコンポーネントタイプの入力および出力は、単にXMLドキュメントです。これは、異なるコンポーネントタイプ間での通信が直接的および簡単であることを意味します。
コンポーネント間でデータを渡すには、基本的な方法が2つあります。最初の方法では、個別に呼び出されるコンポーネントから入力および出力ドキュメントを渡したり受信したりするサービスを使用します。 この方法では、コンポーネントは直接通信せず、代わりにサービスが連絡先として使用されます。2番目の方法では、互いを直接呼び出すコンポーネントを使用します。選択する方法は、サービスの設計の仕方や、実行されるタスクのタイプによって異なります。
これは、サービスが配備されている方法によって異なります。 サービスがSOAPサービスとして配備されている場合、SOAPサーバでは、複数の入力ドキュメントをサービスに渡すことができます(複数の入力がサービスのWSDLで指定されている場合)。4つの標準的なComposerサービストリガタイプであるParams (URL/フォーム)、XML (MIMマルチパート)、XML (HTMLフォームフィールド)、およびXML (HTTP POST)を含む、その他のすべての状況では、入力として受け付けることができるXMLドキュメントの数は「1つ」だけです。
展開の詳細については、『Composer Enterprise Serverユーザガイド』を参照してください。
2つのコンポーネントを呼び出す1つのサービスを含むプロジェクトを作成した場合、2番目のコンポーネントを呼び出すサービスに出力を返す前に3番目のコンポーネントを呼び出すよう最初のコンポーネントを指定することは、設計上可能です。技術的には、3番目のコンポーネントは「サービス内に含まれている」わけでも、そこから直接呼び出されるわけでもありません。サービスについて理解するのに重要なことは、アプリケーションサーバ上の「サービストリガ」オブジェクトによって呼び出されるのはサービスだけであるということです。 コンポーネントはサービスに直接リンクされている必要はありませんが、一連のイベントにおいて何らかの理由によりコンポーネントが呼び出されない場合、そのコンポーネントは実行されません。
サーバトリガオブジェクトは、exteNdの配備フレームワークで作成するJavaサーブレット、EJB、またはMessageListener (JMSの場合)です。このオブジェクトは、Webページに埋め込まれているURL、またはWeb上の別のプログラムから呼び出されるURLによってトリガされます。トリガされると、サーブレットまたはEJBによってComposerサービスが開始されます。
繰り返しますが、展開、サービストリガ、フレームワークオブジェクトなどの詳細については、『Composer Enterprise Serverユーザガイド』を参照してください。
プロジェクトはJARファイルとして配備され、通常は、プロジェクト内のサービスやコンポーネントで「他の」サービスまたはコンポーネント、あるいはその両方を呼び出す必要がある場合、その「呼び出される」サービス/コンポーネントは同じJARファイルに保存されます。ただし、場合によっては、「異なる」JARファイル(つまり、配備された別のプロジェクト)に存在する別のサービスを呼び出すようサービスを指定すると便利(または必要)なことがあります。この操作は、XML交換アクションにより実行できます。
XML交換アクションを使用すると、コンポーネントやサービスでは、HTTP GET、PUT、またはPOSTプロトコルを介してXMLドキュメントを出力できます。別のComposerサービスのURLを入力することで、XML交換アクションにより質問のサービスに対するサーブレットトリガを起動できます。次の図を参照してください。
この図では、プロジェクトAのWebサービス2によりプロジェクトBのWebサービス3を呼び出そうとしています。同じプロジェクトJARに存在するためWebサービス2からWebサービス1を直接呼び出すことはできますが、Webサービス3に直接接続することはできません。このため、リモートサービスのサービストリガを起動するXML交換アクションを実行する必要があります。
ログアクションでは、サービス内のコンポーネントのアクティビティに関する情報が書き込まれます。 サービス内におけるすべてのコンポーネントのアクティビティを記録する単一ログファイルを作成するには、サービスと各コンポーネントで使用されるそれぞれのログアクションに対して、［ログ先:］フィールドに 同じファイル名を単に指定します。ログアクションの詳細については、ログアクションを参照してください。
注記: 複数のログアクションに対して同じファイル名を指定する場合は、［ログファイルのクリア］チェックボックスがオフになっていることを確認してください。このチェックボックスをオンにすると、各ログアクションによって書き込みが行われる前にログファイルが消去されてしまいます。ただし、サービス内に含まれる最初のログアクションに対しては、このオプションを選択することができます。このオプションを選択すると、ログがクリアされ、ファイルの最後にメッセージを追加し続けることなく、アクションモデルを複数回トラブルシューティングしたり、アニメーション表示したりすることが可能になります。
コンポーネントを使用する場合と同様に、サービスに対して入力として使用するXMLテンプレートには、複数のサンプルドキュメントを含めることができます。テストの実行中は、サービスのアクションを順に進みながら、適切なサンプルドキュメントをロードして、サービスで各インスタンスを処理できるかどうかを確認できます。
詳細については、サンプルドキュメントのロードを参照してください。
Copyright © 2004 Novell, Inc. All rights reserved. Copyright © 1997, 1998, 1999, 2000, 2001, 2002, 2003 SilverStream Software, LLC. All rights reserved. more ...
