JP5237058B2 - コンピュータシステム - Google Patents

Description

本発明は、コンピュータシステムおよびフレームワーク管理装置に関し、特にＪａｖａ（登録商標）アプリケーションプログラム（以下、単にアプリケーションプログラムという）を利用したコンピュータシステムおよびフレームワーク管理装置に関する。

近年、例えば鉄鋼業界及び金融業界等に代表される各種業界では、規模の拡大や業務の効率化等を目的として、統合、合併または買収等（以下、単に統合等という）を行なう動きが盛んになっている。このような動きは、世界規模での競争激化に起因する業界再編によってもたらされたものであり、他社に対する競争優位を確立することが可能になるという効果が得られる。

しかしながら、統合等後の企業が一体となって機能するためには、解決すべき種々の問題が存在する。例えばコンピュータシステムの統合に関する問題がそれにあたる。

今日、多くの企業は、日常業務のかなりの部分をコンピュータシステム化している。このため、各企業がコンピュータシステムを構築するためにハードウエア及びソフトウエアへ投資した金額は膨大になる。したがって、コンピュータシステムを構成するハードウエア及びソフトウエアは、それを保有する企業にとって有形または無形の重要な資産の一部を形成している。

しかも、各企業が有するソフトウエアのうち、アプリケーションプログラムは、その企業における業務処理手順等の業務ノウハウをコンピュータプログラムによって具現化したものであり、他社に対する競争優位を確立するための源泉となっている。

しかしながら、上記のように業務ノウハウを具現化するアプリケーションプログラムが資産の中の重要な位置を占めているにもかかわらず、従来では、統合等の対象である複数の企業間でこれを自由に移植することができないという問題が存在する。これは、以下に述べる理由に起因している。

すなわち、アプリケーションプログラムが動作するコンピュータシステムの基盤を構成するものには、ハードウエアやＯＳ（オペレーティングシステム）やアプリケーションサーバなどのいわゆるプラットホームと呼ばれるものと、アプリケーションプログラムが使用する共通の機能を部品としてまとめたフレームワークと、が存在する。このうち、プラットホームについては、通常、各企業は、コンピュータシステムの供給元（以下、単にベンダという）が独自の仕様に従って作成した製品をそのまま購入して使用している。

一方、フレームワークは、アプリケーションプログラムの作成者が作成した部品と、他のベンダ（以下、サードベンダという）が供給元ベンダの仕様に沿って作成したミドルウエア部品とからなる。以下では、アプリケーションプログラムの作成者が作成した部品とミドルウエア部品とを総称してフレームワーク部品という。

これらフレームワーク部品は、いずれもベンダ独自の仕様に従って作成されているため、プラットホームに対する依存性を有している。また、このような依存性を備えたフレームワーク部品を利用するアプリケーションプログラムも、必然的にその基盤となるフレームワーク及びプラットホームに対する依存性を有している。従って、アプリケーションプログラムは、同じベンダから供給されたコンピュータ間、または、同じ仕様に基づいて作成されたプラットホーム及びフレームワークを有するコンピュータ間でなければ移植することができないという問題が存在する。

このような問題が存在するがために、統合等により一体として機能することを目指す複数の企業においてそれぞれが保有するアプリケーションプログラムを移植することができず、統合等前のままの状態である異なる業務処理手順等を用いて業務を遂行せざるを得ないという事例が往々にして存在した。

上記のような問題を解決するために、従来では、統合等をする企業のうち一方が保有するアプリケーションプログラムを、他方の企業が保有するプラットホームで開発したアプリケーションプログラムと同等の機能を有する新たなアプリケーションプログラムに手作業で再構築して、社内の業務処理手順等を統一化していた。

しかしながら、アプリケーションプログラムの再構築には多大な費用、時間および手間などを要する。このため従来では、統合等後の企業において共通のアプリケーションプログラムが利用できるまでに要する種々のコスト、すなわち、業務処理手順等が統一化されるまでに要する多大な費用、時間および手間などによって、統合等の目的である競争優位の効果が減殺されてしまっていた。

また、従来では、業務処理手順等を統一化したとしても、業務処理手順等に変更があった場合には、異なるプラットホームの同一機能を有するアプリケーションプログラムそれぞれに手作業で変更を加えなければならないため、この際の作業にも膨大な費用、時間および手間などを要してしまうという問題が生じていた。

さらに、統合等や業務処理手順等の変更に伴い、アプリケーションプログラムの手作業による変更の回数が増える。このことは、作業者による変更ミス等を増加させる要因となる。このように変更ミス等が増加すると、システムを停止等して作業しなければならない回数が増加するため、業務遂行に支障を招くという問題も生じてしまう。

以上のように、異なるプラットホームを有する企業が統合等する場合、従来では、それにより期待される効果を素早く且つ無駄なく発揮することができず、また、アプリケーションプログラム再構築後の維持管理に多大な負担を要していた。

このような問題を解決する方法としては、Ｊａｖａ（登録商標）の標準機能の集合体であるＪ２ＳＥ（Ｊａｖａ ２ Ｓｔａｎｄａｒｄ Ｅｄｉｔｉｏｎ）に企業の業務システムなどの開発に使われているサーバ用ＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍ Ｉｎｔｅｒｆａｃｅ）を付加したＪ２ＥＥ（Ｊａｖａ ２ Ｅｎｔｅｒｐｒｉｓｅ Ｅｄｉｔｉｏｎ）を利用する方法が存在する（例えば以下に示す非特許文献１参照）。このＪ２ＥＥは、Ｓｕｎ Ｍｉｃｒｏｓｙｓｔｅｍｓ（登録商標）社から提供されている汎用プラットホーム技術であり、同社によって単一の仕様が定められている。

このうち、Ｊ２ＳＥはプログラミング言語であるＪａｖａ（登録商標）の基本機能である。一方、サーバ用ＡＰＩは、サーブレット（Ｗｅｂサーバ対話処理）、ＪＳＰ（ＪａｖａＳｅｒｖｅｒ Ｐａｇｅｓ）、ＥＪＢ（Ｅｎｔｅｒｐｒｉｓｅ ＪａｖａＢｅａｎｓ）等、数多くのＡＰＩからなる。各ＡＰＩは、ソフトウエア開発で利用できる命令及び関数の集合と、これらを利用するための規約とから構成される。

『Ｊ２ＥＥ入門 〜いまさら聞けないＪ２ＥＥ〜』、富士通株式会社ホームページ、[online]、[平成２０年６月５日検索]、インターネット＜URL:http://segroup.fujitsu.com/sdas/technology/j2ee/＞

ところで、Ｊ２ＥＥを利用して作成したフレームワーク部品は、一般的には、汎用部品、すなわち異なるハードウエアやＯＳ等に依存することなく利用することができる部品として扱われる。このため、Ｊ２ＥＥを利用して汎用部品の集合よりなるフレームワークを構築した場合、あるプラットホームで開発したアプリケーションプログラムを再構築することなく他のプラットホームに移植することを可能にする汎用フレームワークの実現が期待される。

しかしながら、実際には、あるプラットホームでＪ２ＥＥを利用して作成したフレームワーク部品の中に、他のプラットホームで利用することができないものが存在する。このため、アプリケーションプログラムの再構築は回避できるものの、プラットホームに応じてフレームワークを作成または修正しなければならないという問題が存在した。

そこで本発明は、上記の問題に鑑みてなされたものであり、プラットホームに応じたフレームワークの作成または修正を必要としないコンピュータシステムおよびフレームワーク管理装置を提供することを目的とする。

かかる目的を達成するために、本発明によるコンピュータシステムは、ＥＪＢコンテナを備えるＪ２ＥＥアプリケーションサーバが実装されたコンピュータシステムであって、前記ＥＪＢコンテナ内に配置され、１つ以上の機能部品を含むフレームワークと、各機能部品に対応して前記ＥＪＢコンテナ内に配置され、前記ＥＪＢコンテナによって実現される実行環境に応じた機能差を吸収する補助部品と、前記実行環境において各機能が前記機能部品または前記補助部品のいずれに含まれるかを管理する管理テーブルと、前記各機能部品内に組み込まれた有効化スイッチと、を備え、前記有効化スイッチは、各機能の実行要求があった場合、前記管理テーブルに基づいて該機能を実現する機能部品または補助部品を特定し、特定した機能部品または補助部品を有効化することを特徴としている。

本発明によれば、ＥＪＢコンテナ内に所定機能を実現する補助部品を実装しているため、例えばＥＪＢコンテナと機能部品との両方が所定機能を実装していなかった場合でも、補助部品を用いてこの所定機能を実現することが可能となる。これにより、プラットホームに応じてフレームワークを作成したり修正したりすることなく、フレームワークを他の仕様の解釈に基づいて構築されたプラットホームが導入されたコンピュータシステムに移植することが可能となり、この結果、移植や保守管理等に要する費用、時間および手間などを削減することが可能なコンピュータシステムを実現することが可能となる。また、本発明における補助部品およびこれを有効化する有効化スイッチを汎用フレームワークにおける機能部品と対応付けて管理しておくことで、プラットホームに応じてフレームワークを作成したり修正したりすることなく、フレームワークを他の仕様の解釈に基づいて構築されたプラットホームが導入されたコンピュータシステムに移植することが可能となり、この結果、移植や保守管理等に要する費用、時間および手間などを削減することを可能にするフレームワーク管理装置を実現することが可能となる。

以下、本発明を実施するための最良の形態を図面と共に詳細に説明する。なお、以下の実施の形態により本発明が限定されるものではない。

＜実施の形態＞
以下において、本発明の実施の形態による汎用コンピュータシステムおよびフレームワーク管理装置の構成例を説明するにあたり、まず、統合等によるコンピュータシステム移植時の流れについて図面を用いて詳細に説明する。

図１は、コンピュータシステム間で汎用フレームワークを移植する際の概略フローを説明するためのブロック図である。なお、本説明では、移植元となるコンピュータシステム（以下、これを移植元コンピュータシステムという）１００Ａと移植先となるコンピュータシステム（以下、これを移植先コンピュータシステムという）１００ＢとがＪ２ＥＥの仕様についての異なる解釈に基づいて設計されたプラットホームを備えている場合を例に挙げる。

図１に示すように、移植元コンピュータシステム１００Ａは、例えばＯＳ（Ｘ）１０Ａ上にＪ２ＥＥアプリケーションサーバ（Ｘ）２０Ａが実装されたプラットホームを搭載するホストコンピュータ１１Ａを備える。一方、移植先コンピュータシステム１００Ｂは、例えばＯＳ（Ｙ）１０Ｂ上にＪ２ＥＥアプリケーションサーバ（Ｙ）２０Ｂが実装されたプラットホームを搭載するホストコンピュータ１１Ｂを備える。

ここで、Ｊ２ＥＥアプリケーションサーバ（Ｘ）２０Ａと（Ｙ）２０Ｂとは、異なるＪ２ＥＥの仕様の解釈に基づいて設計された汎用アプリケーションサーバであるとし、このために、移植元コンピュータシステム１００ＡにおけるＪ２ＥＥアプリケーションサーバ（Ｘ）２０Ａが実装する機能と移植先コンピュータシステム１０ＢにおけるＪ２ＥＥアプリケーションサーバ（Ｙ）２０Ｂが実装する機能とに差があるとする。また、移植元コンピュータシステム１００Ａにおいて汎用フレームワーク３０に要求される機能と移植先コンピュータシステム１００Ｂにおいて汎用フレームワーク３０に要求される機能とにも差があるとする。この結果、移植元コンピュータシステム１００Ａの設計に基づいて作成された汎用フレームワーク３０が移植先コンピュータシステム１００Ｂにおいて汎用フレームワーク３０に対して要求される機能を備えていないケースが発生する。

このようなケースの場合、移植元コンピュータシステム１００Ａに組み込まれている汎用フレームワーク３０をそのまま移植先コンピュータシステム１００Ｂに移植すると、Ｊ２ＥＥアプリケーションサーバ（Ｙ）２０Ｂと汎用フレームワーク３０とのいずれもが実装しない機能が存在するため、移植先コンピュータシステム１００Ｂにおけるアプリケーションプログラム４０が統合等後の汎用フレームワーク３０上でうまく動作しないことがある。以下に、このようなケースをフレームワーク部品の一つである排他部品を例に挙げて説明する。なお、フレームワーク部品とは、上述したように、アプリケーションプログラムの作成者が作成した部品や、サードベンダが供給元ベンダの仕様に沿って作成したミドルウエア部品などを含むソフトウエア部品であり、Ｊ２ＥＥアプリケーションサーバのＥＪＢコンテナによって要求される機能を実現するための機能部品である。また、排他部品とは、同時に実行できるアプリケーションプログラムを制御するための機能を提供するフレームワーク部品である。

図２は、データベース１２０の排他制御テーブル１２２をクローズする機能（以下、単に排他制御テーブルクローズ機能という）を備えていない排他部品３０２を含むフレームワーク３００ａが、排他制御テーブルクローズ機能を搭載していないＥＪＢコンテナ３００Ｂを備えたＪ２ＥＥアプリケーションサーバ（Ｙ）２０Ｂが実装された移植先コンピュータシステム１００Ｂに移植された場合に生じる弊害を説明するための図である。なお、図２に示す例では、アプリケーションプログラム４０である排他機能付きデータベース接続用アプリケーションプログラム（以下、排他機能付きＤＢ接続用ＡＰＰという）４０２が排他制御テーブル１２２を備えたデータベース１２０に対して排他を獲得しつつアクセスする。

図２に示す例において、移植元コンピュータシステム１００Ａでは、排他制御テーブルクローズ機能（ＥＪＢ内機能（クローズ機能）３０２ｃ）をＪ２ＥＥアプリケーションサーバ（Ｘ）２０ＡのＥＪＢコンテナ３００Ａが実装している。このため、移植元コンピュータシステム１００Ａでは、排他部品３０２を用いてオープンした排他制御テーブル１２２をＥＪＢコンテナ３００Ａが実装するＥＪＢ内機能（クローズ機能）３０２ｃを用いてクローズすることが可能である。

一方、移植先コンピュータシステム１００Ｂでは、ＥＪＢコンテナ３００Ｂが排他制御テーブルクローズ機能を実装していないため、排他部品３０２を用いてオープンした排他制御テーブル１２２をクローズする機能が存在しない。

具体的には、汎用フレームワーク３０上の排他機能付きＤＢ接続用ＡＰＰ４０２がデータベース１２０へアクセスする場合、排他機能付きＤＢ接続用ＡＰＰ４０２は、ＥＪＢコンテナ３００Ａに対してフレームワーク３００ａに含まれる排他部品３０２を呼び出す（排他部品呼出し制御Ｃ１）。呼び出された排他部品３０２は、自身が実装する部品内機能（オープン機能）３０２ａを用いてデータベース１２０の排他制御テーブル１２２をオープンする（排他制御テーブルオープン制御Ｃ２）。排他制御テーブル１２２は、データベース１２０へのアクセスを管理するための構成である。したがって、この排他制御テーブル１２２の制御により、排他機能付きＤＢ接続用ＡＰＰ４０２がデータベース１２０へのアクセス許可および排他を獲得する。

このように排他制御テーブル１２２をオープンして排他が獲得されると、排他制御テーブル１２２は、通常、その後クローズされる。ここで、排他制御テーブル１２２をどの機能を用いてクローズするかは、上述したように、Ｊ２ＥＥの仕様の解釈等によって差が生じる。以下、この解釈の相違によって生じる機能の差を機能差という。

図２に示す例では、移植対象の排他部品３０２が排他制御テーブルクローズ機能を備えておらず、且つ、移植先コンピュータシステム１００ＢにおけるＥＪＢコンテナ３００Ｂも排他制御テーブルクローズ機能を備えていないケースである。このため、移植先コンピュータシステム１００Ｂにおいて排他機能付きＤＢ接続用ＡＰＰ４０２が排他部品３０２を呼び出してデータベース１２０へアクセスすると、オープンされた排他制御テーブル１２２がクローズされないという事態が生じる。このような事態が生じると、ＥＪＢコンテナ３００Ｂが排他機能付きＤＢ接続用ＡＰＰ４０２へ異常を通知してしまうことになり（異常通知Ｃ４）、これにより、排他機能付きＤＢ接続用ＡＰＰ４０２がエラー動作を実行してしまう。

そこで本実施の形態では、上記のような解釈の相違によって生じる機能差を吸収することができる機能差吸収手段５０を移植先コンピュータシステム１００Ｂへ汎用フレームワーク３０と共に導入することで、機能差によって生じる不具合を解消する。図３に、本実施の形態による機能差吸収手段５０を用いたコンピュータシステム間の汎用フレームワーク３０移植フローの概略を示す。

図３に示すように、本実施の形態では、汎用フレームワーク３０を移植元コンピュータシステム１００Ａから移植先コンピュータシステム１００Ｂへ移植する際、機能差吸収手段供給手段２から供給された機能差吸収手段５０も移植先コンピュータシステム１００Ｂへ導入する。

ここで、本実施の形態による機能差吸収手段５０について、図４を用いて詳細に説明する。図４は、機能差吸収手段５０の構成を説明するためのブロック図である。図４に示すように、機能差吸収手段５０は、機能差吸収部品５１と有効化スイッチ５２とからなる。

機能差吸収部品５１は、上記のような理由によって生じる機能差を吸収することでフレームワーク部品３００を汎用可能にするための部品であり、例えばフレームワーク部品３００が備えていない機能を補完するための補助部品である。この機能差吸収部品５１は、汎用フレームワーク３０の導入先（例えば移植先コンピュータシステム１００Ｂ）に、例えば複数のフレームワーク部品３００よりなるフレームワーク３００ａごと実装される。

また、有効化スイッチ５２は、補助部品である機能差吸収部品５１を有効とするか否かを設定するためのスイッチである。この有効化スイッチ５２は、例えばフレームワーク部品３００と機能差吸収部品５１とのうち何れを用いて要求された機能を実現するかを切り替えるための切換手段としても機能する。なお、この有効化スイッチ５２は、例えば移植対象であるフレームワーク部品３００内部に組み込まれる。なお、「要求された機能」とは、Ｊ２ＥＥの仕様に従ってＪ２ＥＥアプリケーションサーバ（以下、汎用フレームワーク３０の組み込み先となるＪ２ＥＥアプリケーションサーバの符号を２０とする）が要求する機能である。

管理テーブル３０Ａは、上記フレームワーク部品３００と機能差吸収部品５１とのうち何れを用いて要求された機能を実現するかを管理するための構成であり、例えばフレームワーク部品３００が対象の機能を備えているか否かをテーブル形式に登録して管理する。この管理テーブル３０Ａは、例えばフレームワーク３００ａの外部に設けられ、適宜、フレームワーク３００ａによって参照される。フレームワーク３００ａは、有効化スイッチ５２に従って管理テーブル３０Ａを参照し、参照した登録内容に従って要求された機能を実現する。すなわち、管理テーブル３０Ａも上記の有効化スイッチ５２と共に要求された機能を実現する構成を切り替えるための切替手段として機能する。

なお、機能差吸収手段５０は、例えば図３に示すように、移植時にパーソナルコンピュータなどで構成された機能差吸収手段作成手段２１を用いて作成されてもよいし、予め予測される機能差に応じて作成しておいたものをファイルサーバなどで構成された機能差吸収手段保持手段２２に蓄積しておいてもよい。また、管理テーブル３０Ａは、例えばパーソナルコンピュータ等を用いて手作業により作成したものをホストコンピュータ１１に格納するなど、種々の方法を用いて作成することが可能である。

次に、本実施の形態による機能差吸収手段５０の動作を、具体例を用いて詳細に説明する。図５は、移植対象の排他部品３０２と移植先コンピュータシステム１００Ｂとのいずれもが排他制御テーブルクローズ機能を備えておらず、この機能を機能差吸収部品（オープン／クローズ機能）５１２ａ、有効化スイッチ５２２ａおよび管理テーブル３０Ａを用いて補完する場合の具体例を示すブロック図である。

図５に示すように、排他機能付きＤＢ接続用ＡＰＰ４０２は、データベース１２０へアクセスするにあたり、まず、排他部品３０２を呼び出す。これにより、図２を用いて説明した動作と同様に、排他部品３０２が呼び出されて排他制御テーブル１２２がオープンされる（Ｃ１，Ｃ２）。

また、排他部品３０２が呼び出されると、移植先コンピュータシステム１００Ｂは、排他部品３０２の有効化スイッチ５２２ａに従って管理テーブル３０Ａを参照することで、この排他部品３０２に関する各機能に対しての登録内容を取得する。なお、排他部品３０２に関する各機能とは、Ｊ２ＥＥの仕様において要求される１つ以上の機能を意味する。

ここで、本実施の形態による管理テーブル３０Ａの構成例を図６に示す。図６に示すように、本実施の形態による管理テーブル３０Ａは、各フレームワーク部品（図８の符号３０１〜３０７参照）に関する機能ごとに、各機能がサポートされているか否か、及び、どのようにサポートされているか否かを管理する。例えば排他部品３０２についてのテーブル（排他部品用テーブル３２Ａ）では、排他制御テーブルクローズ機能（クローズ機能）と排他制御テーブルオープン／クローズ機能（オープン／クローズ機能）とのそれぞれについて、排他部品３０２が備えているか否かと機能差吸収部品が組み込まれているか否かとが管理される。なお、各フレームワーク部品における機能をサポートする構成の区分は、排他部品３０２の区分例（「部品内機能」、「機能差吸収部品」）に限らず、種々変形することが可能である。また、図６に例示されている他の部品については、後述において詳細に説明する。

そこで本例では、図６の管理テーブル３０Ａにおける排他部品用テーブル３２Ａにおいて、部品内機能として排他制御テーブルオープン機能は備えているものの、排他制御テーブルオープン／クローズ機能は備えておらず、また、排他制御テーブルオープン機能の機能差吸収部品は備えていないものの、排他制御テーブルオープン／クローズ機能の機能内部品は備えていることが登録されているため、図５では、機能差吸収部品（オープン／クローズ機能）５１２ａを呼び出して有効化するように動作する（有効化スイッチ５２２ａの「設定２」）。

したがって、Ｊ２ＥＥの仕様に従ってＪ２ＥＥアプリケーションサーバ２０から排他制御テーブル１２２のクローズが要求されると、有効化スイッチ５２２ａに従って機能差吸収部品（オープン／クローズ機能）５１２ａが呼び出される（有効化スイッチ５２２ａの「設定２」）。呼び出された機能差吸収部品（オープン／クローズ機能）５１２ａは、部品内機能（オープン機能）３０２ａまたは自身によってオープンされた排他制御テーブル１２２をクローズする制御を行なう（排他制御テーブルクローズ制御Ｃ３２）。これにより、排他制御テーブルクローズ機能を備えていない排他部品３０２が排他制御テーブルクローズ機能（３０２ｃ）を搭載していないＪ２ＥＥアプリケーションサーバ（Ｙ）２０Ｂ（図３参照）上に組み込まれた場合でも、排他制御テーブル１２２がクローズされないことによって排他機能付きＤＢ接続用ＡＰＰ４０２がエラー動作することを回避することが可能となる。

ここで参考として、排他部品３０２が実装する排他制御テーブルクローズ機能を有効化する場合についても、図５および図６を用いて以下に説明する。

図６において、排他部品用テーブル３２Ａの「部品内機能」には、「有」が対応付けられている。この場合では、図５で示すように、排他部品３０２が実装する部品内機能（クローズ機能）３０２ａを用いてオープンされている排他制御テーブル１２２をクローズする（有効化スイッチ５２２ａの「設定１」、排他制御テーブルクローズ機能Ｃ３）。

次に、本実施の形態による機能差吸収手段５０が組み込まれた汎用コンピュータシステムの一例を、図面を用いて詳細に説明する。図７は、本実施の形態による汎用コンピュータシステムの概略構成を示すブロック図である。なお、図７に示す汎用コンピュータシステムは、汎用フレームワーク３０を移植した後の構成であっても、移植する前の構成であってもよい。すなわち、本実施の形態では、汎用フレームワーク３０の移植の有無にかかわらず、図７に示すような汎用コンピュータシステムを構築することが可能であり、このような汎用コンピュータシステムを構築しておくことで、汎用フレームワーク３０の管理や移植等が容易となるため、移植や保守管理等に要する費用、時間および手間などを削減することが可能となる。

図７に示すように、汎用コンピュータシステムは、１つ以上のコンピュータシステム１Ａ、１Ｂ、…（以下、任意のコンピュータシステムの参照符号を１とする）と、これらのうち少なくとも１つと所定のネットワーク４を介して接続された１つ以上のクライアント端末３Ａ、３Ｂ、３Ｃ、…（以下、任意のクライアント端末の参照符号を３とする）と、移植や保守管理等の対象となる汎用フレームワーク３０および機能差吸収手段５０を管理する汎用フレームワーク管理サーバ２０１と、を備える。なお、汎用コンピュータシステムは、機能差吸収手段５０を作成して、これを汎用フレームワーク管理サーバ２０１へ格納するための機能差吸収手段供給手段２を含んでも良い。

ここで、図７に示す汎用フレームワーク管理サーバ２０１の具体的な構成例を図８に示す。図８に示すように、汎用フレームワーク管理サーバ２０１は、アプリケーションエンジン（以下、単にＡＰエンジンという）３０１、排他部非３０２、採番部品３０３、キュー連携３０４、チェック部品３０５、画面部品３０６、ＤＡＯ（Ｄａｔａｂａｓｅ Ａｃｃｅｓｓ Ｏｂｊｅｃｔ）部品３０７、…などの種々のフレームワーク部品と、これらフレームワーク部品それぞれについて、Ｊ２ＥＥの仕様の解釈の相違によって生じる機能差を吸収するための機能差吸収手段５０１〜５０７と、を保持する。ここで、まず上記で例示した各フレームワーク部品について説明する。

・ＡＰエンジン
ＡＰエンジン３０１は、アプリケーションプログラムのビジネスロジックをコンポーネントという単位で作成したフレームワーク部品であり、それぞれのコンポーネントの組合せによって処理フローを構成している。また、ＡＰエンジン３０１は、この組合せによって構成された処理フローを、指定した順序に従って実行させるための機能も含む。さらに、ＡＰエンジン３０１は、処理フロー同士をつなげてバッチ処理を行なう機能も含んでいる。

・排他部品
排他部品３０２は、上述したように、同時に実行できるアプリケーションプログラムを制御するための機能を提供するフレームワーク部品である。すなわち、排他部品３０２は、あるアプリケーションプログラムが他の関連するアプリケーションプログラムと同時に実行されてはならない場合などにおいて、他のアプリケーションプログラムが同時に実行されることを制限する機能を提供する。

・採番部品
採番部品３０３は、あるデータベースに対して主キーを作成したり取得したりする機能を提供するフレームワーク部品である。採番部品３０３によって生成されるキーは、例えばアルファベッドの連番および接頭子等からなる。また、発行されたキーは採番テーブルと呼ばれる専用のテーブルで管理される。

・キュー連携
キュー連携３０４は、キューを用いて、メッセージの送受信やデータの送受信を行なう機能を提供するフレームワーク部品である。

・チェック部品
チェック部品３０５は、データのチェックに必要なルールを選択して実行する機能を提供するフレームワーク部品である。チェック部品３０５は、予めルールデータベースに登録されているルールに沿ってデータをチェックする。従って、チェック部品３０５を用いてチェックエンジンを起動すると、このルールに対応したチェックが実行される。

・画面部品
画面部品３０６は、プルダウン機能、入力補助機能、一覧表示機能、メッセージ表示機能等を提供するフレームワーク部品である。また、画面部品３０６には、オンライン画面を構成するために必要な部品群も含まれている。

・ＤＡＯ部品
ＤＡＯ部品３０７は、データベースアクセス処理を一括して管理する機能を提供するフレームワーク部品である。このＤＡＯ部品３０７を用いることで、アプリケーションプログラムに対してＳＱＬ（Ｓｔｒｕｃｔｕｒｅｄ Ｑｕｅｒｙ Ｌａｎｇｕａｇｅ）を隠蔽することが可能となるため、データベースの物理構造が変更されたとしてもアプリケーションコードへの影響が生じないシステムを構築することが可能となる。

また、図８に示す例では、例えばＡＰエンジン３０１についての機能差吸収手段として機能差吸収部品５１１および有効化スイッチ５２１が管理されており、排他部品３０２についての機能差吸収部品として機能差吸収部品５１２および有効化スイッチ５２２が管理されている。さらに、採番部品３０３、キュー連携３０４、チェック部品３０５、画面部品３０６およびＤＡＯ部品３０７、…についても同様に、それぞれの機能差吸収手段として機能差吸収部品５１３〜５１７、…および有効化スイッチ５２３〜５２７、…が管理されている。また、本実施の形態は、管理テーブル３０Ａが全てのフレームワーク部品についての機能を管理すると共に、全てのフレームワーク部品に対して各機能を有効化するための有効化スイッチを設けるように構成されているが、本発明はこれに限定されず、機能の管理が必要なフレームワーク部品についてのみ、管理テーブル３０Ａを用いた機能の管理と有効化スイッチを用いた機能の有効化とを行なうように構成してもよい。

図７に戻り説明する。コンピュータシステム１は、例えばサーバやメインフレームなどで実現されたホストコンピュータ１１と、これと内部バスまたは外部バスを介して接続された記憶部１２とを含む。ここで図９に、コンピュータシステム１のより詳細な構成を示す。図９に示すように、ホストコンピュータ１１は、ＯＳ１０と、ＯＳ１０上に実装されたＪ２ＥＥアプリケーションサーバ２０と、Ｊ２ＥＥアプリケーションサーバ２０上に実装された汎用フレームワーク３０と、汎用フレームワーク３０上に実装されたアプリケーションプログラム４０と、から構成される。

Ｊ２ＥＥアプリケーションサーバ２０上の汎用フレームワーク３０は、例えば図８に示す汎用フレームワーク管理サーバ２０１において管理されている汎用フレームワーク３０がそのままホストコンピュータ１１におけるＪ２ＥＥアプリケーションサーバ２０上に導入されたものであっても良い。したがって、汎用フレームワーク３０は、そのフレームワーク部品として、例えば、ＡＰエンジン３０１、排他部品３０２、採番部品３０３、キュー連携３０４、チェック部品３０５、画面部品３０６およびＤＡＯ部品３０７などのフレームワーク部品と、これらフレームワーク部品における機能差を吸収するための機能差吸収部品５１１〜５１７および有効化スイッチ５２１〜５２７と、を含む。なお、汎用フレームワーク３０の導入は、例えば各コンピュータシステム１と汎用フレームワーク管理サーバ２０１とをインターネットやＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）などの所定のネットワークを介して接続し、このネットワークを介して行なっても良いし、例えばＣＤ−ＲＯＭやＤＶＤ−ＲＯＭなどの携帯可能なメディアを介して行なっても良い。

汎用フレームワーク３０上のアプリケーションプログラム４０は、例えばホストコンピュータ１１に接続された記憶部１２のアプリケーションプログラム管理部１２４において管理されており、このアプリケーションプログラム管理部１２４から適宜ホストコンピュータ１１に読み込まれ、汎用フレームワーク３０上に実装される。

また、ホストコンピュータ１１は、内部または外部の記憶領域に管理テーブル３０Ａを保持している。この管理テーブル３０Ａは、上述したように、各フレームワーク部品の有効化スイッチ５２を機能させる際に適宜Ｊ２ＥＥアプリケーションサーバ２０によって参照される。

図７に戻り説明する。図７において、クライアント端末３は、例えばデスクトップ型のパーソナルコンピュータやラップトップあるいはノート型のパーソナルコンピュータなどである。ただし、これらに限定されず、クライアント・サーバシステムを実現する種々の情報処理システムを適用することが可能である。

また、例えば図７に示す汎用コンピュータシステムをいわゆるサーバサイドシステムとして構築した場合、アプリケーションプログラム４０の実行に際してユーザは、クライアント端末３を用いてコンピュータシステム１へアクセスし、これのホストコンピュータ１１に対して所望のアプリケーションプログラム４０の起動を要求する。ホストコンピュータ１１は、クライアント端末３からの要求に応じて該当するアプリケーションプログラム４０を記憶部１２におけるアプリケーションプログラム管理部１２４から読み込んで実行し、その結果をクライアント端末３に送信して表示させる。

以上のように、本実施の形態では、対象の機能を実現する補助部品として機能差吸収部品を実装しているため、例えばＥＪＢコンテナとフレームワーク部品との両方が対象の機能を実装していなかった場合でも、機能差吸収部品を用いて対象の機能を実現することが可能となる。これにより、１つ以上のフレームワーク部品を含む汎用フレームワークを再構築や設計変更せずとも、これを他の仕様の解釈に基づいて構築されたコンピュータシステムに移植することが可能となり、移植や保守管理等に要する費用、時間および手間などを削減することが可能な汎用コンピュータシステムを実現することが可能となる。

また、本実施の形態における機能差吸収部品およびこれを有効化する有効化スイッチを汎用フレームワークにおけるフレームワーク部品と対応付けて管理しておくことで、汎用可能な汎用フレームワークを一箇所（汎用フレークワーク管理サーバ）で一元管理することが可能となるだけでなく、移植や保守管理等に要する費用、時間および手間などを削減することを可能にするフレームワーク管理サーバ（フレームワーク管理装置）を実現することが可能となる。

また、上記実施の形態は本発明を実施するための例にすぎず、本発明はこれらに限定されるものではなく、仕様等に応じて種々変形することは本発明の範囲内であり、更に本発明の範囲内において、他の様々な実施の形態が可能であることは上記記載から自明である。

コンピュータシステム間で汎用フレームワークを移植する際の概略フローを説明するためのブロック図である。 排他制御テーブルクローズ機能を備えていない排他部品を排他制御テーブルクローズ機能を排他部品に要求するＥＪＢコンテナを備えたＪ２ＥＥアプリケーションサーバを実装する移植先コンピュータシステムに移植した場合に生じる弊害を説明するための図である。 本発明の実施の形態による機能差吸収手段を用いたコンピュータシステム間の汎用フレームワーク移植フローの概略を示すブロック図である。 本発明の実施の形態による機能差吸収手段の構成を説明するためのブロック図である。 移植対象の排他部品と移植先コンピュータシステムとのいずれもが排他制御テーブルクローズ機能を備えておらず、この機能を本発明の実施の形態による機能差吸収部品（オープン／クローズ機能）、有効化スイッチおよび管理テーブルを用いて補完する場合の具体例を示すブロック図である。 本発明の実施の形態による管理テーブルの構成例を示す図である。 本発明の実施の形態による汎用コンピュータシステムの概略構成を示すブロック図である。 本発明の実施の形態による汎用コンピュータシステムにおける汎用フレームワーク管理サーバの具体的な構成例を示すブロック図である。 本発明の実施の形態による汎用コンピュータシステムにおけるコンピュータシステムのより詳細な構成を示すブロック図である。

符号の説明

１０、１０Ａ、１０Ｂ オペレーティングシステム
１、１Ａ、１Ｂ コンピュータシステム
２ 機能差吸収手段供給手段
３Ａ、３Ｂ、３Ｃ クライアント端末
４ ネットワーク
１１、１１Ａ、１１Ｂ ホストコンピュータ
１２ 記憶部
２０、２０Ａ、２０Ｂ Ｊ２ＥＥアプリケーションサーバ
２１ 機能差吸収手段作成手段
２２ 機能差吸収手段保持手段
３０ 汎用フレームワーク
３０Ａ 管理テーブル
３２Ａ 排他部品用テーブル
４０ アプリケーションプログラム
５０１〜５０７ 機能差吸収手段
５１、５１１〜５１７ 機能差吸収部品
５２、５２１〜５２７ 有効化スイッチ
１００Ａ 移植元コンピュータシステム
１００Ｂ 移植先コンピュータシステム
１２０ データベース
１２２ 排他制御テーブル
１２４ アプリケーションプログラム管理部
２０１ 汎用フレームワーク管理サーバ
３００ フレームワーク部品
３００Ａ、３００Ｂ ＥＪＢコンテナ
３００ａ フレームワーク
３０２ 排他部品
３０２ａ 部品内機能（オープン機能）
３０２ｃ ＥＪＢ内機能（クローズ機能）
４０２ 排他機能付きデータベース接続用アプリケーションプログラム
５１２ａ 機能差吸収部品（排他制御テーブルクローズ機能）
５２２ａ クローズ機能有効化スイッチ
Ｃ１ 排他部品呼出し制御
Ｃ２ 排他制御テーブルオープン制御
Ｃ３、Ｃ３１ 排他制御テーブルクローズ制御
Ｃ４ 異常通知

Claims (1)

1. ＥＪＢコンテナを備えるＪ２ＥＥアプリケーションサーバが実装されたコンピュータシステムであって、
   前記ＥＪＢコンテナ内に配置され、１つ以上の機能部品を含むフレームワークと、
   各機能部品に対応して前記ＥＪＢコンテナ内に配置され、前記ＥＪＢコンテナによって実現される実行環境に応じた機能差を吸収する補助部品と、
   前記実行環境において各機能が前記機能部品または前記補助部品のいずれに含まれるかを管理する管理テーブルと、
   前記各機能部品内に組み込まれた有効化スイッチと、
   を備え、
   前記有効化スイッチは、各機能の実行要求があった場合、前記管理テーブルに基づいて該機能を実現する機能部品または補助部品を特定し、特定した機能部品または補助部品を有効化することを特徴とするコンピュータシステム。

Images