(57)【要約】【課題】  本発明はEnterprise Java Beanで提案されたエンティティビーン、セッションビーン、メッセージ駆動ビーン以外にスレッドビーンという新しい形態のビーンを導入する。【解決手段】  本発明は独立的スレッドの割り当てを受けてルーピング(looping)しながら決まったメッセージの目的地に入って来たメッセージを処理しあるいは周期的に駆動されて特定作業を遂行する、ビジネスロジッグを処理するEJBとして、スレッドビーンを定義する。【選択図】  図１
2005182743.tif 000002
【特許請求の範囲】
【請求項１】
独立的スレッドの割り当てを受けルーピング(looping)しながら決まったメッセージの目的地に入って来たメッセージを処理しあるいは周期的に実行されて特定作業を遂行する、ビジネスロジッグを処理するEJBとしての、EJBコンテナ上で実行されるスレッドビーン。
【請求項２】
独立的スレッドの割り当てを受けルーピング(looping)しながら決まったメッセージの目的地に入って来たメッセージを処理しあるいは周期的に実行されて特定作業を遂行する、ビジネスロジッグを処理するEJBとして定義されたスレッドビーン(ThreadBean)をEJBコンテナ上で実行するスレッドビーンの実行方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明はスレッドビーン及びスレッドビーンの実行方法に関するものであり、より詳しくはEJBでスレッドを使ってビジネスアプリケーションを開発しようとするときに、これを支援するための、EJBコンテナ上で実行されるスレッドビーン及びスレッドビーンの実行方法に関するものである。
【背景技術】
【０００２】
既存のEJBはエンティティビーン(Entity Bean)、セッションビーン(Session Bean)、メッセージ駆動ビーン(Message Driven Bean)で構成されているが、内部で新しいスレッドを生成して使うことは禁止されているため、次のような作業を遂行するビジネスアプリケーションは便法を取らなければ、EJBとしてはスペック上不可能になっている。
【０００３】
このようなビジネスアプリケーションには、特定のソケットポットをモニタリングしながら入って来るデータを処理するビジネスアプリケーション、特定のメールアカウントをモニタリングしながら入って来たメールを処理するビジネスアプリケーション、特定のインスタンスメッセージをモニタリングしながら入って来るメッセージを処理するビジネスアプリケーション、周期的に駆動されてファイルをバックアップしたり統計を作成したりしなければならないビジネスアプリケーションなどがある。
【０００４】
一方、Java（登録商標）メッセージサービスのトピック（Topic）やキュー（Queue）に入って来るデータは、EJB 2.0でメッセージ駆動ビーンとして処理することができる。しかし、これもやはり他のビーン等と同じようにスレッドとは無関係にメッセージビーンのコンテナが内部的に処理する。すなわち、開発者が意図的にスレッドの使用を要する場合に、これを支援するための方法がなく、Javaメッセージサービスのメッセージのみを非同期的に処理することができるようになっているだけである。
【０００５】
EJB 2.1では、これをより拡張しており、スレッドの使用に柔軟性を付与した。EJB 2.1ではデータベース、ERP、メール、Javaメッセージサービスなどを提供する会社があり、これらがアプリケーションサーバーに自分たちの製品を統合するためにリソースアダプダというものをEJB 2.1スペックで提案した方法で具現して提供することが強制される。これはEJB 2.0でも同じであるが、EJB 2.0が非同期メッセージを処理するためにJavaメッセージサービスとしてリソースを限定したのに対して、EJB 2.1は多様な形態のメッセージを非同期的に処理するようにした。このとき、特定メッセージの目的地をモニタリングできるようにする方法が必要であるが、これのためにEJB 2.1ではリソース販売会社がリソースと一緒にリソースアダプダを提供しながらメッセージの目的地に対するモニタリング作業をアプリケーションサーバーに依頼する方式を取る。
【０００６】
リソースアダプダは、ワーク(Work)という客体をアプリケーションサーバーに提供し、アプリケーションサーバーは可用のスレッドを割り当ててリソースアダプダを代理してワーク客体を駆動させることによって、モニタリング作業を遂行する。この方法はリソースが存在しなければリソースアダプダが存在しないので、モニタリングする対象がなくなる。すなわち、リソースが提供した作業のためにアプリケーションサーバーがスレッドを割り当てて駆動させる。このために提案されたインタフェースもEJBインタフェースとは異なっているので、全然違った方式でスレッドが生成され管理される。結果的に、開発者がビジネスアプリケーションの必要に応じてスレッドを駆動させ特定作業を遂行しようとするとき、既存のEJBと等しい方式でこれを具現する方法がない実情である。
【発明の開示】
【発明が解決しようとする課題】
【０００７】
従って、本発明は上記した従来の問題点を解決するためのものであって、本発明の目的は開発者がスレッドを使うアプリケーションを、既存のEJBと同等の方法で開発して実行できるように、EJBコンテナ上で実行される新しいEJBビーンとしてスレッドビーンというEJBビーンを提供することにある。
【課題を解決するための手段】
【０００８】
このような技術的課題を果たすために本発明ではスレッドビーンに対するインタフェースを定義する。
【０００９】
また、独立的スレッドの割り当てを受けてルーピング(looping)しながら決まったメッセージの目的地に入って来たメッセージを処理しあるいは周期的に実行されて特定作業を遂行する、ビジネスロジッグを処理するEJBとして、EJBコンテナ上で実行されるスレッドビーンを定義する。
【発明の効果】
【００１０】
本発明によれば、スレッドの割り当てを受けて特定作業を遂行する、新しい形態のEJBを作成することによって、独立的スレッドが必要なビジネスロジッグ、すなわち、ソケットやJavaメッセージサービス、特定のメールアカウントに入って来るメッセージを処理し、又は周期的に駆動されてファイルバックアップや統計処理などの特定作業を遂行するアプリケーションを追加でき、EJBの処理機能を拡張できる。
【００１１】
また、コンテナが提供する多様な機能、すなわち、保安管理、トランザクション管理、インスタンスのライフサイクル管理などを新しく提案したスレッドビーンに同等の方式で適用して使うことができる。
【００１２】
また、スレッドビーンがモニタリングしたり作業したりする詳細内容は、ビーンの開発者が作成し、コンテナはスレッドビーンのライフサイクルとスレッドのみを管理し、スレッドビーンの設定に必要なすべての情報は配布の明細に明示することによって、多様な形態の作業をコンテナと独立に設計して抜き挿すことができる、抜き挿し可能性（pluggability）を提供する。
【発明を実施するための最良の形態】
【００１３】
以下、本発明による実施の形態を、添付した図面を参照しながら詳しく説明する。
【００１４】
図１は、スレッドビーンとスレッドビーンコンテキスト(Context)のためのインタフェースの定義である。 
これのジャバパッケージは、既存のEJBパッケージと等しいjavax.ejbである。スレッドビーンはエンタープライズビーン(EnterpriseBean)のすべてのメッソドを受け継ぎ、さらにrun()１０１とstop()１０２を定義する。run()ではビーンの開発者がスレッドを利用して、自分のしようとする作業(すなわち、特定のポットに対するモニタリングやルーピングを周期的に遂行する作業)をプログラムし、stop()では開発者がスレッドビーンを停止させるために必要な作業を遂行する。スレッドビーンコンテキストはスレッドビーンの実行に必要な情報を含み、EJBコンテキストのメッソド等を承継する。スレッドビーンの実行に必要な多様な情報は配布の明細（配置記述子）に定義する。
【００１５】
図3はこのような配布の明細を現わす。配布の明細はスペックで定義された共通のタグと共にメッセージの目的地をモニタリングする客体のタイプを指定するタグ３０１とスレッドビーンの駆動に必要な設定情報を伝逹するための設定情報タグ３０２が加えられる。このような配布の明細に定義された情報を実行時にスレッドビーンに伝逹するためにスレッドビーンコンテキストが利用される。図１の１０３、１０４はスレッドビーンコンテナがスレッドビーンを生成しながら図３の配布の明細を入力受けてハッシュマップの資料構造として好ましい値等を設定してスレッドビーンに伝逹するためのインタフェースを現わしており、図２の２０２のように使われる。
【００１６】
図２はスレッドビーンに対する簡単な例題を示している。実際、スレッドビーンでは図２の２０３、２０４のように設定情報を使う。ここで、コンフィギュレーション(Configuration)客体は配布の明細に明示された設定情報を含む客体として、設定情報の名前、値、タイプなどを持っている。スレッドビーンがメッセージの目的地をモニタリングしたり、周期的作業を遂行したりできるように、開発者はメッセージの類型に当たるようにリスナーインタフェース２０１を定義し、これをスレッドビーンで具現しなければならない。メッセージの目的地をモニタリングしないで周期的作業を遂行するスレッドビーンの場合、リスナーインタフェースは周期的作業を遂行するメッソドを定義したインタフェースになる。本発明では理解の便宜のために、このような場合のインタフェースもリスナーインタフェースと称する。
【００１７】
図２の２０３は、javax.jms.MessageListenerに存在するメッソドとして開発者が具現し、スレッドビーンコンテナは独立的スレッドを通じてスレッドビーンのrun()メッソドを実行する。メッセージが伝逹されればコンテナが伝逹したメッセージを受けて最終的に開発者が定義したメッソド２０３を通じて、好ましい作業を遂行するようにする。メッセージ受信にコンテナが関与する理由は、他のEJBと同じくコンテナが提供する保安検査やトランザクション検査などの機能を遂行した後、最終的にスレッドビーンに開発者がプログラムした作業を実行させるためである。
【００１８】
コンテナがメッセージ伝逹に関与するために、配布のツールはスレッドビーン配布の明細(図３)と開発者が提供したスレッドビーン(図２)を利用してコンテナが使うリスナー具現コードを生成する。図５はこのような過程を現わしたものであり、図４は配布のツールによって生成された例題のリスナー具現コードを示している。
【００１９】
図６はこのような過程を経ってスレッドビーンコンテナが生成された後、スレッドビーンが駆動されるまでの過程を現わす。
【００２０】
６０１ステップは、配布者が スレッドビーンを配布する。
【００２１】
６０２ステップは、エンティティ、セッション、メッセージ駆動、スレッドビーンコンテナを生成するコンテナファクトリー(ContainerFactory)がスレッドビーンコンテナを生成する。このとき、XMLと定義された配布の明細書が一緒に提供される。
【００２２】
６０３ステップは、生成された スレッドビーンコンテナはアプリケーションサーバーに存在するスレッドマネージャーに可用のスレッドを一つ要請する。スレッドマネージャーはあらかじめプーリングしていたスレッドを返し、スレッドがなければ新たに生成して渡す６０３−１。
【００２３】
６０４ステップは、スレッドビーンコンテナはアプリケーションサーバーに存在するインスタンスマネージャー(それぞれのEJBインスタンスのライフサイクルを管理しており、キャッシュ、プーリングなどの機能を提供する管理客体)にスレッドビーンのインスタンスを要請する。インスタンスマネージャーは決まった数の予めプーリングしていたスレッドビーンを渡し、スレッドビーンがなければ生成して渡す６０４−１。
【００２４】
６０５ステップは、６０２ステップで入力されたスレッドビーン配布の明細からスレッドビーン実行に必要な多様な情報を得た後、これを含むコンフィギュレーション客体を生成する。前にも述べたようにコンフィギュレーション客体は、図３の３０２タグに明示された値などを格納するための客体として名前、タイプ及び値を設定して返すJavaビーン客体である。
【００２５】
６０６ステップは、スレッドビーン実行環境を格納するスレッドビーンコンテキスト客体を生成する。
【００２６】
６０７−１ステップは、６０５ステップで生成したコンフィギュレーション客体をスレッドコンテキストに設定する。
【００２７】
６０８−１ステップは、６０３ステップでスレッドマネージャーから新しく得られたスレッドにスレッドビーンを割り当てる。
【００２８】
６０９ステップは、スレッドのrun()メッソドを呼び出す。 
６１０ステップは、run()要請を受けたスレッド客体は６０４過程で選択されたスレッドビーン客体にrun()メッソド実行を要請する。
【００２９】
このような過程を経って開発者が配布したスレッドビーンのrun()メッソドはアプリケーションサーバーが割り当てたスレッドによって呼び出しされ、メッセージを待機し、又は周期的に実行されて作業を遂行する。スレッドを通じて作業を遂行しなければならないビジネスアプリケーションを作成するとき、開発者はrun()メッソドの中で所望のアプリケーションを自由に記述し、このとき必要な実行環境等はスレッドビーンコンテキストを通じて使う。すなわち、開発者はアプリケーションサーバーが提供するスレッド、トランザクション及び保安のようなミドルウェア機能を他のEJBと等しく支援を受けて、実際遂行される作業と無関係に(メッセージ類型が何か、どんな情報が必要なのかなどは分かる必要が無い)、 スレッドビーンを定義して管理することができて、どんな類型のサービスでも自由に抜き挿すことができる。EJB 2.0ではメッセージ駆動ビーンを定義するとき、配布の明細にコンフィギュレーション形態ではない明示的タグで必要な実行環境を定義し、コンテナもこのタグを明示的に使うことで拡張性が低下した。
【００３０】
run()を通じてスレッドビーンが実際に駆動された後、run()の中では図２の２０５のような過程を経てスレッドビーンがモニタリングする目的地に対するリスナー客体をコンテナから割り当てられなければならない。このような作業のために提案したものがリスナーファクトリーである。リスナーファクトリーはスレッドビーンを提供するためにコンテナが提供すべきまた別の客体として、配布のツールが生成したリスナー具現クラスの客体を生成して返す役目を遂行する。
【００３１】
図７はスレッドビーンのrun()メッソドの実行とメッセージの受信準備過程を現わす。
【００３２】
７０１ステップはスレッドビーンコンテナが図６の６０３過程で割り当て受けたスレッドにrun()を呼び出す。
【００３３】
７０２ステップは、割り当てられたスレッドがスレッドビーンのrun()を呼び出す。
【００３４】
７０３ステップは、図２の２０５のようにリスナーファクトリーにリスナー具現コードを要請する。
【００３５】
７０４ステップは、リスナーファクトリーは配布のツールが生成したリスナー具現クラス等をメモリーにローディングする。
【００３６】
７０５ステップは、ローディングされたクラスの中で要請したスレッドビーンが所望するリスナー具現クラスを探す。
【００３７】
７０６ステップは、探したリスナー具現クラスのインスタンスを生成する。
【００３８】
７０７ステップは、スレッドビーンコンテナがメッセージ処理の中間に関与することができるようにコンテナInvocationHandler客体を図４の４０４を利用して設定する。コンテナInvocationHandlerは図４の４０３のようにリスナーインタフェースに定義されたメッソド(図４の場合onMessage())を途中で横取りしてコンテナに伝逹し、コンテナがこのメッセージを受けて保安検査、トランザクション検査あるいは接近履歴処理のような作業を遂行し、最終的に開発者が作成した該当のスレッドビーンのonMessage()を(図２の２０７)呼び出すことができるようにするためのハンドラー客体として、アプリケーションサーバーの具現毎に相異なっていることができる。
【００３９】
７０８ステップは、生成されたリスナー具現客体を返還する。 
７０９ステップは、スレッドビーンのrun()で返されたリスナー具現コードを利用して図２の２０６のようにメッセージの目的地をモニタリングする。
【００４０】
７０１０ステップは、それぞれのメッセージソースからメッセージが伝逹される。
【００４１】
このような過程を通じてメッセージの目的地に対するモニタリングの成り立った後、メッセージが伝逹されれば図８の過程を経ってメッセージは処理される。
【００４２】
８０１ステップは、リスナーファクトリーから割り当て受けたリスナー客体がメッセージの目的地を監視する。
【００４３】
８０２ステップは、外部のメッセージソースがメッセージを送る。
【００４４】
８０３ステップは、メッセージがリスナー具現客体に伝逹される。
【００４５】
８０４ステップは、メッセージ具現客体は自分の持っているコンテナInvocationHandler客体に該当のメッセージを伝逹する。使用者が定義したリスナーには一つ以上のメッソドが存在することもあり得るので、図４のようにメッソド客体とパラメーターとしてコンテナInvocationHandlerを呼び出す。
【００４６】
８０５ステップは、コンテナInvocationHandlerはスレッドビーンコンテナにこれを伝逹する。
【００４７】
８０６ステップは、スレッドビーンコンテナは伝逹されたメッセージを処理するために保安検査やトランザクション検査あるいはログインのような作業を遂行する。
【００４８】
８０７ステップは、最終的に開発者が配布したスレッドビーン客体のメッソドを呼び出す。
【００４９】
８０８ステップは、該当のメッソドは開発者が意図したビジネスロジッグを遂行する。
【００５０】
図９は作業を完了又は非正常的な動作に基づきコンテナがスレッドビーンの実行を停止させる過程を表す。 
９０１ステップは、スレッドビーンのrun()の内でstop()を呼び出し又はスレッドビーンコンテナが管理目的のためにスレッドビーンのstop()を呼び出す。
【００５１】
９０２ステップは、スレッドビーンを行ったスレッドがstop()メッソドの呼び出しを感知する。
【００５２】
９０３ステップは、スレッドビーンコンテナにスレッドビーンの使用を終了することを要請する。
【００５３】
９０４ステップは、スレッドビーンコンテナはアプリケーションサーバーが持っているインスタンスマネージャーに該当の使ったスレッドビーンを返す。
【００５４】
９０５ステップは、インスタンスマネージャーは使用が完了したスレッドビーンインスタンスのejbRemove()メッソドを呼び出して内部的変数等を初期化した後、プールに入れて再使用する。
【００５５】
９０６ステップは、スレッドビーンコンテナはスレッドビーン実行を担当したスレッドをスレッドマネージャーに返す。
【００５６】
９０７ステップは、スレッドマネージャーは返されたスレッドを内部初期化過程を経った後、プールに入れて再使用する。
【００５７】
以上で説明したことは、本発明を実施するための一つの例に過ぎないものであって、本発明は上記の実施の形態に限ることなく、特許請求の範囲で請求する本発明の要旨を脱することなしに、発明の属する分野において通常の知識を有する者なら誰でも多様な変更実施が可能な範囲まで適用される。
【図面の簡単な説明】
【００５８】
【図１】本発明によるスレッドビーンとスレッドコンテキストを定義したインタフェースの例を示す図である。
【図２】本発明によるスレッドビーンの具現コードに対する例示図である。
【図３】本発明によるスレッドビーンと共に提供すべき配布の明細書に対する例を示す図である。
【図４】本発明によるJavaメッセージサービスのためのメッセージリスナーImplコードに対する例を示す図である。
【図５】本発明によるスレッドビーンを作成した後、配布のツールによって配布の明細に定義されたリスナーのタイプに当たるリスナーImplコードを生成する過程の例を示す図である。
【図６】本発明によるスレッドビーンコンテナの生成とスレッドビーンの実行過程の例を示す図である。
【図７】本発明によるスレッドビーンが実行された後、モニタリングするメッセージの目的地からメッセージを受信するための準備過程の例を示す図である。
【図８】本発明によるメッセージ受信後、スレッドビーンコンテナを経て該当のスレッドビーンのメッセージ処理関数でメッセージが伝逹され処理される例を示す図である。
【図９】本発明によるスレッドビーンが終わった後、割り当てられたスレッドと、使ったスレッドビーンとを再使用するためにプールに入れる過程の例を示す図である。
【図１】
2005182743.tif 000003
【図２】
2005182743.tif 000004
【図３】
2005182743.tif 000005
【図４】
2005182743.tif 000006
【図５】
2005182743.tif 000007
【図６】
2005182743.tif 000008
【図７】
2005182743.tif 000009
【図８】
2005182743.tif 000010
【図９】
2005182743.tif 000011