JP2005292986A - 業務処理用ｅｊｂコンポーネントシステム - Google Patents

Abstract

【課題】 コンポーネントごとにインターフェース変換を行うことなく、処理の改変や追加が容易な業務処理用ＥＪＢコンポーネントシステムを提供する。
【解決手段】 ウェブ部２からの要求を受けて処理の実行の要求を出力するサービスコンポーネント３と、サービスコンポーネント３から処理の実行要求を受けて、前記要求を処理すべきコンポーネントを選択し処理の実行の要求を出力するモデル操作コンポーネント４と、所定のルールをチェックして処理結果をモデル操作コンポーネント４に返すルールチェックコンポーネント６と、共有データの参照を行い、処理結果をモデル操作コンポーネント４に返す共有データ参照コンポーネント５と、データの検索と更新と電文の編集とを行い、処理結果をモデル操作コンポーネント４に返すデータ操作コンポーネント７と、を有する。
【選択図】 図１

Description

本発明は、ＥＪＢ（Enterprise JavaBeans: Java言語でプログラム部品を作成し、それらをつなぎ合わせてアプリケーションソフトを構築するためのJavaBeans仕様にネットワーク分散型ビジネスアプリケーションのサーバー側の処理に必要な機能を追加した仕様）コンポーネントを使用して企業等における業務処理を行うＥＪＢコンポーネントシステムに関する。

一般に関連したデータと処理とを一まとめにして、クラスとして開発するオブジェクト指向技術が知られている。

ＪＢ(JavaBeans)は、Java言語でプログラム部品を作成し、それらをつなぎ合わせてアプリケーションソフトを構築する仕様である。ＥＪＢはJavaBeans仕様にネットワーク分散型ビジネスアプリケーションのサーバー側の処理に必要な機能を追加したものである。

ＥＪＢコンポーネントは、ＥＪＢ仕様による機能を持ったプログラム部品または該プログラム部品を実行するハードウェアである。ＥＪＢコンポーネントは基本的には単体で使用せず、他のＥＪＢコンポーネントと組み合わせて機能を実現する。本発明にいう「ＥＪＢコンポーネントシステム」は、複数のＥＪＢコンポーネントを組み合わせて構成したシステムである。

なお、「コンポーネント」はソフトウェアを指すこともあるが、本発明ではコンポーネントの機能を実現するハードウェアを指すものとする。

従来から、上記ＥＪＢコンポーネントシステムを使用して、企業の業務処理を行うシステムはあった。

ここで、「企業の業務処理」とは、企業の経営資源を的確に把握し迅速な意思決定ができるための、財務会計や販売、在庫、流通、製造システムというような種類のデータ処理をいう。これらの業務処理用システムは、処理すべきビジネスロジックが異なるが、システムとして類似の構成にすることができる。

そこで、カスタマイズのしやすい業務処理システムを作ることが、システム開発において重要となってきている。

従前は、業務処理にオブジェクト指向技術を適用した結果、大きな粒度のクラスからなる業務処理システムができてしまい、処理の変更や追加が困難になってしまうことがしばしば起こった。

これに対して、最近は大きなクラスを分割し、役割ごとに分割したクラスで実装する手法が採られるようになった。

図５は、従来の業務処理用ＥＪＢコンポーネントシステムの一例を示している。

図５の業務処理用ＥＪＢコンポーネントシステム１３は、サービスコンポーネント１４と、ビジネスモデルコンポーネント１５とを有している。

サービスコンポーネント１４は、ＥＪＢ−コントローラー１６と、複数のステートハンドラー１７を有している。

ビジネスモデルコンポーネント１５は、ＥＪＢ−主クラス１８と、ＥＪＢ−主クラス１８のデータを保持するモデル−クラス１９と、データベースアクセスオブジェクトをなすパーシステンス２０と、ビジネスロジックインターフェースを有するプラガブルビジネスロジック２１と、ＸＭＬファイル２２とを有している。

ＥＪＢ−コントローラー１６はウェブ部（ウェブ層）から処理要求（イベントオブジェクト）を受け取り、そのクラス名からステートハンドラー名を引き当て、該当するステートハンドラー１７を起動する。

起動されたステートハンドラー１７は、ウェブ部（ウェブ層）から送られたイベントオブジェクトの内容を解析し、必要なＥＪＢ−主クラス１８を呼び出す。

ＥＪＢ−主クラス１８は、プラガブルビジネスロジック２１に所定の処理（たとえば配送料計算等）の実行要求を送信し、その処理結果を受信してサービスコンポーネント１４に返す。

上記配送料の計算等においてプラガブルビジネスロジック２１は、モデル−クラス１９からデータ、ＸＭＬファイル２１から配送料の計算式を入力し、配送料の計算を行うようにしている。

サービスコンポーネント１４は、ビジネスモデルコンポーネント１５から処理結果を受け取り、図示しないウェブ部（ウェブ層）に返し、当該処理を終了する。

一方、ウェブ部（ウェブ層）は、ウェブを介して処理結果を要求したユーザーに送信し、当該処理を終了する。

先行技術文献
本発明は業務処理の基本的機能として所定のルールを参照して可否の判断および可否に伴う定型的処理を行う系統と、共有のデータを参照する系統と、データを検索や更新し、データの検索や更新に伴って電文を編集する系統とに分け、わずかな改変によって種々の業務処理に適用可能にしたものである。本発明は本願出願人が独自に考案したものであるため、本願出願人が知る限り先行技術文献が存在しない。

しかし、役割ごとにクラスを分割した従来のＥＪＢコンポーネントシステムは、コンポーネント（クラス）を呼び出すごとにコンポーネントが要求するインターフェースに合わせてパラメータをインターフェース変換する必要があった。

また、従来の業務処理用ＥＪＢコンポーネントシステムは、いったん特定の業務処理に適合するように構築すると、処理の変更をする際に、必要なデータがインターフェースに含まれていないことがあり、呼び出した側も含めて全体の変更が必要になるという問題があった。

たとえば、図５の配送料の計算の例において、仮に当初全国一律の配送料としていたところ、距離（すなわち住所）に応じて配送料を計算するように処理を変更しようとする場合を考えると、それまでの処理ではＥＪＢ−主クラス１８がデータとして配送先の住所としてデータを有していないところを、変更後のＥＪＢ−主クラス１８はデータとして配送先の住所を保持するようにしなければならない。このため、ＥＪＢ−主クラス１８を含めて全体の変更が必要になり、処理の変更が容易ではない。

このように、処理の変更や追加の容易性という観点では不十分な業務処理用ＥＪＢコンポーネントシステムとなっていた。

一般には、業務処理を行うシステムが扱う項目（データ）数は大量であり、カスタマイズ自体も項目の変更（追加や修正）に伴う対応（インターフェース変換）が多い。

そこで、本発明が解決しようとする課題は、コンポーネントごとにインターフェース変換を行うことなく、処理の改変や追加が容易な業務処理用ＥＪＢコンポーネントシステムを提供することにある。

本発明による業務処理用ＥＪＢコンポーネントシステムは、
ウェブ部からの要求を受けて処理の実行の要求を出力し、継続している処理を特定して処理が終了するまで登録しておくサービスコンポーネントと、
前記サービスコンポーネントから処理の実行要求を受けて、前記要求を処理すべきコンポーネントを選択し、該コンポーネントに処理の実行の要求を出力し、継続している処理を特定して処理が終了するまで登録しておくモデル操作コンポーネントと、
前記モデル操作コンポーネントから処理の実行要求を受けて、所定のルールをチェックして処理結果を前記モデル操作コンポーネントに返すルールチェックコンポーネントと、
前記モデル操作コンポーネントから処理の実行要求を受けて、共有データの参照を行い、処理結果を前記モデル操作コンポーネントに返す共有データ参照コンポーネントと、
前記モデル操作コンポーネントから処理の実行要求を受けて、データの検索と更新と電文の編集とを行い、処理結果を前記モデル操作コンポーネントに返すデータ操作コンポーネントと、を有し、
前記モデル操作コンポーネントは、前記ルールチェックコンポーネントあるいは前記共有データ参照コンポーネントあるいは前記データ操作コンポーネントから処理結果を受け、該処理結果を前記サービスコンポーネントに出力するとともに前記モデル操作コンポーネントにおける該処理を終了し、
前記サービスコンポーネントは、前記モデル操作コンポーネントから前記処理結果を受け、該処理結果をウェブ部に出力するとともに前記サービスコンポーネントにおける該処理を終了する、ことを特徴とするものである。

前記ルールチェックコンポーネントと前記共有データ参照コンポーネントと前記データ操作コンポーネントのいずれかと、前記サービスコンポーネントと、前記モデル操作コンポーネントとの間で送受信されるデータは、データ名とデータが入力可能な複数のコンテナを有するデータオブジェクトに格納されて送受信されるようにすることができる。

本発明によれば、データオブジェクトは、データ名自体を外部定義情報として設定することが可能となる。また、外部定義化により、ウェブ部及びデータベース部とのマッピング定義も外部定義情報により実現が可能となる。このデータオブジェクトはウェブ部とサービスコンポーネントとの間、共有データ参照コンポーネントあるいはデータ操作コンポーネント（場合によりルールチェックコンポーネントを含む）とデータベースの間に適用することができる。

前記データ操作コンポーネントあるいは前記共有データ参照コンポーネントからデータの参照あるいは検索あるいは更新の要求を受けて、データベースに対してデータの参照あるいは検索あるいは更新の処理を行い、処理結果を前記データ操作コンポーネントあるいは前記共有データ参照コンポーネントに返すデータベースハンドラーを有するようにすることができる。

前記ルールチェックコンポーネントと前記共有データ参照コンポーネントと前記データ操作コンポーネントのいずれかと、前記サービスコンポーネントと、前記モデル操作コンポーネントと、前記データベースハンドラーとの間の処理の要求は、インタフェース名を指定して送受信され、前記インタフェース名を入力し、対応する実装クラスを引き当て、前記ルールチェックコンポーネント、前記共有データ参照コンポーネント、前記データ操作コンポーネント、前記サービスコンポーネント、前記モデル操作コンポーネント、前記データベースハンドラーのいずれかに返し、その処理に供するファクトリユーティリティ部と、実装クラスを格納する実装クラス部と、を有するようにすることができる。

前記ファクトリユーティリティ部は、デフォルトの実装クラスを他の実装クラスに切り替える切替定義部を有するようにすることができる。

本発明は、ルールチェックコンポーネントと、共有データ参照コンポーネントと、データ操作コンポーネントとを有している。さらにこれらのコンポーネントに対してモデル操作コンポーネントによって処理を行うコンポーネントを選択する構成としている。

すなわち、本発明は、業務処理の基本的機能が、所定のルールを参照して可否を判断し、判断の可否に伴う定型的処理を行う系統と、共有のデータを参照する系統と、データを検索や更新し、データの検索や更新に伴って電文を編集する系統とに分けられることに着目し、これらの系統機能に対応するコンポーネントを設けている。

これにより、業務処理は上記３種類の系統機能の組合せによって構成することができ、種々の業務処理に対応することができる幅広い応用が可能な業務処理用ＥＪＢコンポーネントシステムを提供することができる。

また本発明は、システムを構成する全コンポーネントの間で、データ名とデータが入力可能なコンテナを複数個有しているデータオブジェクトに、データを格納して送受信するようにしている。

これにより、データを使用するコンポーネント側で使用時に必要なデータを前記データオブジェクトから取り出すようすることができる。このデータオブジェクトに全コンポーネントで使用するデータを予め格納するという使用方法が可能になり、これにより、使用するコンポーネント側で必要なデータを取り出して使用するようにすることができ、コンポーネントごとにインターフェース変換を行う必要をなくすことができる。

また、処理の変更や追加に対しても、変更や追加がされる処理を含めて必要なデータを予め前記データオブジェクトに格納していれば、処理の変更や追加によってコンポーネントを含めた全体の変更をする必要がなくなる。

したがって、処理の変更や追加をより容易にすることができる。

さらに、本発明は、各コンポーネント間で送受信される処理要求を実装クラスのインターフェース名によって行い、実装クラスは実装クラス部に格納している。一方、ファクトリユーティリティ部を設け、前記インターフェース名に応じて実装クラスを引き当て、コンポーネントの処理に供するようにしている。これにより、実装部が分離され、処理の改変と実装クラスの改変を容易にすることができる。

また、ファクトリユーティリティ部において、切替定義部で実装クラスを切り替え定義することにより、デフォルトの実装クラスを任意の他の実装クラスに切り替えることもできる。

図１に本発明の一実施形態による業務処理用ＥＪＢコンポーネントシステムの構成を示す。

図１に示すように、本実施形態による業務処理用ＥＪＢコンポーネントシステム１は、ウェブ部２と、サービスコンポーネント３と、モデル操作コンポーネント４と、共有データ参照コンポーネント５と、ルールチェックコンポーネント６と、データ操作コンポーネント７と、データハンドラ８と、データベース９とを有している。

さらに、業務処理用ＥＪＢコンポーネントシステム１は、ファクトリユーティリティ部１０と、実装部１１とを有している。

ウェブ部２は、ウェブを介して業務処理用ＥＪＢコンポーネントシステム１を利用する者（ユーザー）から処理要求を受け、該ユーザーに処理結果を返す部分である。なお、ウェブ部２は、業務処理用ＥＪＢコンポーネントシステム１の必須構成要件ではなく、外部の装置からなっていてもよい。

サービスコンポーネント３は、ウェブ部２からの要求を受けて実体的な処理を行うコンポーネント４〜７に処理の実行の要求を出力するものである。サービスコンポーネント３は、継続している処理を特定して処理が終了するまで登録しておき、処理結果を要求元のウェブ部２に返すことも行う。

モデル操作コンポーネント４は、要求を処理すべきコンポーネント５〜７のいずれかを選択し、選択したコンポーネントに処理の実行の要求を出力するものである。

本発明では業務処理を、共有データを参照する処理の系統と、所定のルールをチェックしてそれに従って所定の処理を行う処理の系統と、データベースに対してデータの検索と更新を行い電文の編集を行う処理の系統に分類し、それぞれ共有データ参照コンポーネント５とルールチェックコンポーネント６とデータ操作コンポーネント７にそれらの役割を持たせている。

モデル操作コンポーネント４は、要求された処理の内容に応じて上記５〜７のいずれか
のコンポーネントを選択し、該コンポーネントに処理の要求を送る。

モデル操作コンポーネント４はまた、継続している処理を特定して処理が終了するまで登録しておき、処理結果を要求元のサービスコンポーネント３に返すようにする。

共有データ参照コンポーネント５は、データの参照を行うコンポーネントである。

データの参照とは、たとえば、残高照会や、在庫照会等、データベースの内容を改変することなく、単にデータを取得する処理である。

ルールチェックコンポーネント６は、所定のルールをチェックして処理結果を前記モデル操作コンポーネント４に返すコンポーネントである。

前記所定のルールとは、ビジネスロジックである。ビジネスロジックはこれに限られる意味ではないが、たとえば配送料計算の計算方法を参照し、配送を決定した後に在庫を減らし、流通部門に通知する等の処理である。

なお、ルールチェックコンポーネント６のルールは、ルールチェックコンポーネント６の内部に保持していてもよく、データベース化してデータハンドラ８によって参照するようにしてもよい。図１においてルールチェックコンポーネント６に対応するデータハンドラ８とデータベース９が破線で示されているのは、必要な場合と不要な場合があることを示すものである。

データ操作コンポーネント７は、データベースのデータを検索し更新し、また、所定のデータ操作（検索と更新、検索結果による判断）に伴って所定の処理（電文の編集等）を行うコンポーネントである。

ところで、商品の注文のシステムを例にして言えば、最初に共有データ参照コンポーネント５によって在庫を確認し、ルールチェックコンポーネント６によって配送料等の計算を行い、データ操作コンポーネント７によって在庫のデータを書き換え、発送のための電文を編集するなど、上記５〜７のコンポーネントは、適宜組み合わせて一つの業務処理システムを構成することができる。

なお、本発明におけるコンポーネントは、前述したように、所定の機能を持ったプログラム部品を実行するハードウェアであって、他のコンポーネントと組み合わせて機能を実現する。このように複数のコンポーネントを組み合わせることによって業務処理のためのコンポーネントシステムができる。

データハンドラ８は、データベースに対するアクセス、検索、更新等を行うものである。共有データ参照コンポーネント５のデータハンドラ８はデータの検索のみを行うのに対し、データ操作コンポーネント７のデータハンドラ８は、データの検索のみならず更新をも行うことができる。

データベース９は、データを体系的に記憶し、検索・更新等の操作を行うことがてきるようにした装置である。

データベース９には参照や検索用のマスタ系テーブルと、トランザクション処理を行うためのトランザクション系テーブルとが格納されている。

ファクトリユーティリティ部１０は、上記３〜７の各コンポーネントが指定した処理クラスを指定するインターフェース名によって対応する実装クラスを引き当て、該コンポーネントの処理に供するものである。

実装部１１は、上記ファクトリユーティリティ部１０によって引き当てられる実装クラスを格納した部分である。

本発明は、ウェブ部２、サービスコンポーネント３、モデル操作コンポーネント４、共有データ参照コンポーネント５、ルールチェックコンポーネント６、データ操作コンポーネント７、データハンドラ８の間でやりとりされるデータは、データオブジェクト１２というオブジェクトに入れられてやりとりされる。

本発明におけるデータオブジェクト１２は、データ名とデータが入力可能な複数のコンテナを有している。コンテナは、概念的には未定義のデータの容器ということができる。コンテナの数は十分にするのが好ましい。

本発明におけるデータオブジェクト１２は、システムに包含される全オブジェクトが使用するデータを格納し、受信した特定のコンポーネントが使用するか否かに拘わらず、全部のデータを格納したまま送受信される。

また、システムに包含される全オブジェクトで共通のデータ名を使用するようにする。

図２は、データオブジェクトのシステム外部と内部における変換を例示したものである。

本発明の外部のシステム、たとえばウェブ部２やデータベース９は、同一のデータに本発明のシステムで使用するデータ名と異なるデータ名を付して使用していることが多い。

この場合に、図２に示すように、外部のデータを本発明のシステムに取り込むときは、外部のデータ名を本発明のシステムのデータ名に変換し、データオブジェクト１２にデータ名を定義してデータを格納する。

また、本発明のデータオブジェクト１２によって外部のデータベース９を検索するときは、本発明のシステムで使用するデータ名をデータベースのエンティティにマッピングし、データベースに対してデータの検索や更新を行う。

図２の例では、入力側の外部データのデータ項目、ContractID, InsurantName, RegisteredDate, InsuranceType, ContractPeriodは、それぞれ業務モデルパラメータ（業務モデルが使用するデータ）の契約番号、被保険者氏名、登録日付、保険種類、保険期間に変換定義されてデータオブジェクト１２に格納され、本発明のシステムのコンポーネントの処理に供される。

一方、データベース９を使用するときは、業務モデルパラメータの契約番号、被保険者氏名、保険種類、保険期間、登録日付はそれぞれデータベースのデータ項目のid, insurant, type, term, date_of_contract等にマッピングされてデータの検索や更新等に使用される。

本発明のデータオブジェクト１２は、前述したように、システムの全コンポーネントで使用するデータを含み、受信するコンポーネントで必要とされるか否かに拘わらず、全データを送受信する。このようにすることにより、データを使用するコンポーネントにおいて使用時にその都度インターフェース変換をする必要がなくなる。

図３(a),３(b)は、本発明におけるデータの送受信と従来のＥＪＢコンポーネントシステムのデータの送受信を比較して示したものである。

図３(a)に示すように、従来のＥＪＢコンポーネントシステムは、たとえばコンポーネントＡが業務パラメータＡ（UserName satou, accountNo 100123, deposit 10,000）を有し、次に処理を行うコンポーネントＢが業務パラメータＢ（UserName satou, accountNo 100123）を使用する場合、
B.userName=A.userName
B.accountNo=A.accountNo
というように、パラメータのインターフェース変換を行う必要があった。

業務パラメータＣ（accountNo 100123, deposit 10,000）についても、使用時に同様に業務パラメータＡを業務パラメータＣに変換する必要があった（図３(a)参照）。

これに対して、本発明によれば、システムの内部では一貫して業務パラメータＡ（UserName satou, accountNo 100123, deposit 10,000）を使用する。そして、コンポーネントＢやコンポーネントＣは、使用時に業務パラメータＡ（UserName satou, accountNo 100123, deposit 10,000）の中から必要なパラメータを取り出して使用する（図３(b)参照）。

図３(a)と図３(b)とを比較すれば明らかなように、本発明は従来のインターフェース変換を省略している。

また、データオブジェクト１２にすべての業務用パラメータを格納しておくことにより、処理の変更にも容易に対応することができる。

たとえば、前出の図５の例で言えば、当初全国一律の配送料としていたところを距離（すなわち住所）に応じて配送料を計算するような処理に変更する場合、本発明によれば、データオブジェクト１２に配送先住所を含むすべてのデータを格納し、コンポーネントがデータオブジェクト１２から必要なデータを取得して使用することができ、配送料の計算で新たなパラメータを使用する時には必要なパラメータを取り出すようにすることができる。

このようにすれば、影響が変更しようとするコンポーネントに限られるようになり、少ない労力で処理を変更することができる。

さらに、本発明によれば、ファクトリユーティリティ部１０により実装クラスを切り替えることができる。

図４に実装クラスの切替を例示する。

図１と図４から明らかなように、本発明の業務処理クラスは、利用したいインターフェース名をファクトリユーティリティ部１０に指示する。これに対してファクトリユーティリティ部１０は、インターフェース名により実装部１１から実装クラスを引き当ててそれを利用する業務処理クラスに返す。前記ファクトリユーティリティ部１０から実装クラスを受け取った業務処理クラスは、該実装クラスをインターフェースにキャストする。以降は、業務処理クラスはインターフェースのメソッドを操作して処理を行う。

図４に示すように、本発明では、ファクトリユーティリティ部１０により実装クラスを切り替えることができる。すなわち、実装クラスにおいてデフォルトの実装クラスに対して拡張実装クラスを設け、ファクトリユーティリティ部１０においてデフォルト実装クラスを拡張実装クラスに切り替えることができる。

図４の例では、デフォルトの実装クラスは"DefaultCalc"であり、これに対して"xxCalc"という拡張実装クラスを用意し、ファクトリユーティリティ部１０の「計算処理部品のインターフェース名と実装を定義」と記した部分で、計算処理実装部品を"DefaultCalc"から"xxCalc"に切り替えている。

このように、本発明によれば、システムの本体を改変することなく、実装クラスを切り替えることができ、種々の業務処理の変更に簡単に対応することができる。

なお、上記ファクトリユーティリティ部１０の「計算処理部品のインターフェース名と実装を定義」と記した部分は、ファクトリユーティリティ部の「切替定義部」をなしている。

本発明の業務処理用ＥＪＢコンポーネントシステム一実施形態の構成を示したブロック図。 本発明における外部データ項目と業務パラメータ項目とデータベースエンティティ項目の置き換えを説明する図。 本発明によるデータオブジェクトの作用を従来の業務処理コンポーネントにおけるインターフェース変換と比較した説明図。 本発明による実装クラスの切替を説明するための説明図。 従来の業務処理用ＥＪＢコンポーネントシステムの一例の構成図。

符号の説明

１ 業務処理用ＥＪＢコンポーネントシステム
２ ウェブ部
３ サービスコンポーネント
４ モデル操作コンポーネント
５ 共有データ参照コンポーネント
６ ルールチェックコンポーネント
７ データ操作コンポーネント
８ データハンドラ
９ データベース
１０ ファクトリユーティリティ部
１１ 実装部
１２ データオブジェクト
１３ 業務処理用ＥＪＢコンポーネントシステム
１４ サービスコンポーネント
１５ ビジネスモデルコンポーネント
１６ ＥＪＢ−コントローラー
１７ ステートハンドラー
１８ ＥＪＢ−主クラス
１９ モデル−クラス
２０ パーシステンス
２１ プラガブルビジネスロジック
２２ ＸＭＬファイル

Claims (5)

1. ウェブ部からの要求を受けて処理の実行の要求を出力し、継続している処理を特定して処理が終了するまで登録しておくサービスコンポーネントと、
   前記サービスコンポーネントから処理の実行要求を受けて、前記要求を処理すべきコンポーネントを選択し、該コンポーネントに処理の実行の要求を出力し、継続している処理を特定して処理が終了するまで登録しておくモデル操作コンポーネントと、
   前記モデル操作コンポーネントから処理の実行要求を受けて、所定のルールをチェックして処理結果を前記モデル操作コンポーネントに返すルールチェックコンポーネントと、
   前記モデル操作コンポーネントから処理の実行要求を受けて、共有データの参照を行い、処理結果を前記モデル操作コンポーネントに返す共有データ参照コンポーネントと、
   前記モデル操作コンポーネントから処理の実行要求を受けて、データの検索と更新と電文の編集とを行い、処理結果を前記モデル操作コンポーネントに返すデータ操作コンポーネントと、を有し、
   前記モデル操作コンポーネントは、前記ルールチェックコンポーネントあるいは前記共有データ参照コンポーネントあるいは前記データ操作コンポーネントから処理結果を受け、該処理結果を前記サービスコンポーネントに出力するとともに前記モデル操作コンポーネントにおける該処理を終了し、
   前記サービスコンポーネントは、前記モデル操作コンポーネントから前記処理結果を受け、該処理結果をウェブ部に出力するとともに前記サービスコンポーネントにおける該処理を終了する、ことを特徴とする業務処理用ＥＪＢコンポーネントシステム。
2. 前記ルールチェックコンポーネントと前記共有データ参照コンポーネントと前記データ操作コンポーネントのいずれかと、前記サービスコンポーネントと、前記モデル操作コンポーネントとの間で送受信されるデータは、データ名とデータが入力可能な複数のコンテナを有するデータオブジェクトに格納されて送受信されることを特徴とする請求項１に記載の業務処理用ＥＪＢコンポーネントシステム。
3. 前記データ操作コンポーネントあるいは前記共有データ参照コンポーネントからデータの参照あるいは検索あるいは更新の要求を受けて、データベースに対してデータの参照あるいは検索あるいは更新の処理を行い、処理結果を前記データ操作コンポーネントあるいは前記共有データ参照コンポーネントに返すデータベースハンドラーを有することを特徴とする請求項１または２に記載の業務処理用ＥＪＢコンポーネントシステム。
4. 前記ルールチェックコンポーネントと前記共有データ参照コンポーネントと前記データ操作コンポーネントのいずれかと、前記サービスコンポーネントと、前記モデル操作コンポーネントと、前記データベースハンドラーとの間の処理の要求は、インタフェース名を指定して送受信され、
   前記インタフェース名を入力し、対応する実装クラスを引き当て、前記ルールチェックコンポーネント、前記共有データ参照コンポーネント、前記データ操作コンポーネント、前記サービスコンポーネント、前記モデル操作コンポーネント、前記データベースハンドラーのいずれかに返し、その処理に供するファクトリユーティリティ部と、
   実装クラスを格納する実装クラス部と、を有する請求項３に記載の業務処理用ＥＪＢコンポーネントシステム。
5. 前記ファクトリユーティリティ部は、デフォルトの実装クラスを他の実装クラスに切り替える切替定義部を有することを特徴とする請求項４に記載の業務処理用ＥＪＢコンポーネントシステム。

Images