JP2011096045A - 計算機、計算機システム、及び、アプリケーション実行方法 - Google Patents

Abstract

【課題】システムを一時停止することなく、アプリケーションロジックの登録、削除、アップデートを行う。
【解決手段】ネットワークを介して少なくとも１以上のクライアントから１以上の処理要求を受信し、受信した処理要求をＪａｖａサーブレットを用いて処理するためのアプリケーションを実行する計算機であって、前記処理要求は、処理の要求先である１以上のアドレスを含み、前記計算機は、アプリケーションを一意に識別する識別子と、前記アプリケーションを実行するためのバイナリロジックとを対応させたアプリケーション情報、及び、前記識別子と前記各アドレスとを対応させたアダプタ情報を含むデータベースに接続され、前記計算機は、前記処理要求を受信した場合、前記受信した処理要求に含まれるアドレスに基づいて、前記バイナリロジックを特定し、前記特定されたバイナリロジックを実行することによって、前記アプリケーションを実行する。
【選択図】図１

Description

本発明は、計算機に関し、特に、アプリケーションを実行する計算機に関する。

以下に、現状のＪａｖａ ＨＴＴＰ（ＳＩＰ）サーブレット（アプリケーションロジック）の動作を説明する（「Ｊａｖａ」は登録商標、以下同じ）。

（サーブレット追加、削除、又はアップデート時の動作）
Ｊａｖａ ＨＴＴＰ（ＳＩＰ）サーブレットにおけるアプリケーションロジック（サーブレットロジックを含む）の登録、削除、又はアップデートは、原則、サーバを一旦停止して実施する。これはクライアントがサーブレットにアクセスをしている状態において、アプリケーションファイルがアップデートされた場合、アプリケーションファイルＩ／Ｏのブロックによるアップデート失敗、アクセス中のクライアントへの異常応答、又はサーバの異常動作等、予測しない状態になる可能性がある為である。

また、新しいアプリケーションロジックの登録、又は、既存アプリケーションロジックの削除の場合、外部ＩＦ（ＵＲＬ）の追加又は削除を行う必要があるが、サーブレットシステムのＩＦ規定はｗｅｂ．ｘｍｌ（ｓｉｐ．ｘｍｌ）で統一的に設定される為、外部ＩＦ設定を変更中は他の全ＩＦについてアプリケーションロジックが予測しない状態となる可能性がある為、サーバを一旦停止する。

（サーブレットの入力値及び出力値の規定）
各サーブレットの入力と出力とは、ＨＴＴＰ（ＳＩＰ）ＳｅｒｖｌｅｔＲｅｑｕｅｓｔクラス、ＨＴＴＰ（ＳＩＰ）ＳｅｒｖｌｅｔＲｅｓｐｏｎｓｅクラスに統一されている。通常、各サーブレットでは処理の内容が異なる為、入出力も変わるが、上記入出力クラスの中で”値の名称（キー）”と”値”は、ペアにしたハッシュマップによって管理される。つまり、各サーブレットにおいて、クライアントは、外部に具体的な入力値、出力値を明示せず、内部処理によってＨｔｔｐＳｅｒｖｌｅｔＲｅｑｕｅｓｔクラス、ＨｔｔｐＳｅｒｖｌｅｔＲｅｓｐｏｎｓｅクラスから自分の必要な値をハッシュマップから取得する。

既存の技術のうち、アプリケーションロジックのアップデート時にアプリケーションロジックの世代管理を行い、クライアント側のバージョンに合わせて適切な世代のアプリケーションモジュールを実行する技術が開示されている（例えば、特許文献１参照）。
（アプリケーションのアップデート処理）
この技術は、まず、サーバ側のアプリケーション実行モジュールを世代情報と関連付けてデータベースのアプリケーション管理テーブルによって管理する。また、クライアント側の世代管理情報もデータベース上の別のクライアント管理テーブルによって管理する。

特許文献１に記載された発明では、サーバ側によってアプリケーションロジックのアップデートを実施した場合、新しい世代情報を付与して、アプリケーション管理テーブルに登録する。また、アップデートされたバージョンのアプリケーションに対応するクライアントを配布する場合、サーバ側のアプリケーションロジックに付与した世代情報とクライアントとをクライアント管理テーブルに登録する。クライアントがサーバにアクセスを試みた場合、このクライアント管理テーブルから世代情報を確認し、対応するアプリケーション管理テーブルの該当世代のアプリケーションを起動する。

（特許文献１における効果）
特許文献１に記載された発明は、前述の構成によって、クライアント側が新旧世代が混在する状況においてもサーバが世代を認識した上でクライアントの世代に合致するアプリケーションを動作させる為、サーバ側、クライアント側の世代を同期させてアップデートする必要がなくなる。よって、世代交代の為にシステムを一旦停止して、アップデート時間を設ける必要がなくなる。

特開２００２−０９１７７４号公報

Ｊａｖａ Ｃｏｍｍｕｎｉｔｙ Ｐｒｏｃｅｓｓ、"JSR 315: JavaTM Servlet 3.0 Specification"、［ｏｎｌｉｎｅ］、［平成２１年１０月２０日検索］、＜ＵＲＬ：http://jcp.org/en/jsr/detail?id=315＞ Ｊａｖａ Ｃｏｍｍｕｎｉｔｙ Ｐｒｏｃｅｓｓ、"JSR 116: SIP Servlet API"、［ｏｎｌｉｎｅ］、［平成２１年１０月２０日検索］、＜ＵＲＬ：http://jcp.org/en/jsr/detail?id=116＞

特許文献１に記載の発明を、Ｊａｖａ ＨＴＴＰ（ＳＩＰ） Ｓｅｒｖｌｅｔに適用した場合、以下の課題が発生する。

（アプリケーション追加又は削除時のシステム停止）
特許文献１に記載の発明は、アプリケーションアップデート時の世代管理についてのみしか考慮されていない為、アプリケーションロジックの追加及び／又は削除による外部ＩＦ追加及び／又は削除時に、サーブレットのｗｅｂ．ｘｍｌ、ｓｉｐ．ｘｍｌを変更する必要が発生し、これらの設定によってサーブレットのシステムが一時停止する。

（サーブレットの入出力定義）
特許文献１において、各アプリケーションロジックの入出力についての定義は考慮されていない。これは、クライアントが専用クライアントとして世代管理されており、同一世代であれば入出力についてもサーバアプリケーションとクライアント側とが合致している事を前提としているからであると思われる。しかし、サーブレットは基本的にクライアントを専用クライアントに特定しない（一般的なＷｅｂブラウザ又はＳＩＰクライアントが使われる）。また、アプリケーションロジックを配置する場合、各ロジックはプログラム上で入力（引数）、出力（戻り値）が明示的に定義されている為、Ｗｅｂブラウザ又はＳＩＰクライアントが指定したパラメータをロジックの引数に変換する必要が発生する。

（アプリケーションロジック実装形式の制限）
アプリケーションロジックを実装する場合、Ｊａｖａ Ｓｅｒｖｌｅｔの規約に従い、クラス継承、関数のオーバロードを行った上で処理内容を実装する必要がある為、既存のプログラムコードをそのままの形でアプリケーションロジックとして利用する事が出来ない。

本発明の目的は、Ｊａｖａ ＨＴＴＰ（ＳＩＰ） Ｓｅｒｖｌｅｔを用いたシステムにおいて、データベースを用いることによって、システム停止を伴わないアプリケーションロジックの追加又は削除が可能なシステムを提供することであり、また、入出力情報の定義が可能なシステムを提供し、アプリケーションロジックの実装形式に対する制限を取り除くことである。

本発明の代表的な一例を示せば以下の通りである。すなわち、ネットワークを介して少なくとも１以上のクライアントから１以上の処理要求を受信し、前記受信した処理要求をＪａｖａサーブレットを用いて処理するためのアプリケーションを実行する計算機であって、前記処理要求は、前記処理の要求先である１以上のアドレスを含み、前記計算機は、前記アプリケーションを一意に識別する識別子と、前記アプリケーションを実行するためのバイナリロジックとを対応させたアプリケーション情報、及び、前記識別子と前記各アドレスとを対応させたアダプタ情報を含むデータベースに接続され、前記計算機は、前記処理要求を受信した場合、前記受信した処理要求に含まれるアドレスに基づいて、前記バイナリロジックを特定し、前記特定されたバイナリロジックを実行することによって、前記アプリケーションを実行する。

本発明の一実施形態によると、システムを停止することなく、アプリケーション追加及び又は削除などのアップデートが可能となる。

本発明の第１の実施形態のシステムのネットワークを示す説明図である。 本発明の第１の実施形態のアプリケーションサーバの機能を示すブロック図である。 本発明の第１の実施形態のアプリケーションサーバの物理構成を示すブロック図である。 本発明の第１の実施形態のＪａｖａ ＨＴＴＰ Ｓｅｒｖｌｅｔのサーブレット設定ファイル（ｗｅｂ．ｘｍｌ）を示す説明図である。 本発明の第１の実施形態のＪａｖａ ＳＩＰ Ｓｅｒｖｌｅｔのサーブレット設定ファイル（ｓｉｐ．ｘｍｌ）を示す説明図である。 本発明の第１の実施形態のアプリケーションサーバと情報端末との動作を示すシーケンス図である。 本発明の第１の実施形態の情報端末ＳＩＰクライアントがアプリケーションサーバに処理要求を送信する為のＳＩＰメッセージを示す説明図である。 本発明の第１の実施形態のアプリケーションサーバが情報端末ＳＩＰクライアントに処理結果を応答する為のＳＩＰメッセージを示す説明図である。 本発明の第１の実施形態の情報端末Ｗｅｂブラウザがアプリケーションサーバに処理要求を送信する為のＨＴＴＰメッセージを示す説明図である。 本発明の第１の実施形態のアプリケーションサーバが情報端末Ｗｅｂブラウザに処理結果を応答する為のＨＴＴＰメッセージを示す説明図である。 本発明の第１の実施形態のフレームワークアダプタの処理を示すフローチャートである。 本発明の第１の実施形態のアダプタＩＦ管理テーブルを示す説明図である。 本発明の第１の実施形態の入力値管理テーブルを示す説明図である。 本発明の第１の実施形態の入出力クラスバイナリ管理テーブルを示す説明図である。 本発明の第１の実施形態のフレームワーク部の処理を示すフローチャートである。 本発明の第１の実施形態のアプリケーションロジック管理テーブルを示す説明図である。 本発明の第１の実施形態のフレームワークアダプタの処理を示すフローチャートである。 本発明の第１の実施形態のエラー情報管理テーブルを示す説明図である。 本発明の第１の実施形態の出力値管理テーブルを示す説明図である。 本発明の第１の実施形態のフレームワーク部にアプリケーションロジックを新規登録する処理を示すシーケンス図である。 本発明の第１の実施形態のフレームワーク部からアプリケーションロジックを削除する処理を示すシーケンス図である。 本発明の第１の実施形態のフレームワーク部にすでに登録済みのアプリケーションロジック４６を新しいバージョンにアップデートする処理を示すシーケンス図である。 本発明の第１の実施形態の所定の世代のアプリケーションロジックのみを削除する処理を示すシーケンス図である。 本発明の第１の実施形態のアプリケーションロジックの特定世代のみを削除する処理を示すフローチャート図である。 本発明の第１の実施形態のアプリケーションロジックのアップデート又は削除を行った際に、情報端末から処理要求を受信した場合のアクセスを切り分けるシステムを示す説明図である。 本発明の第１の実施形態のアプリケーションサーバを利用して情報端末に表示される、Ｗｅｂ画面上の操作に世代振り分けを行うサーブレットフィルタを示す説明図である。 本発明の第１の実施形態のアプリケーションサーバを利用して情報端末に表示される、Ｗｅｂ画面上の操作に世代振り分けを行う処理を示すシーケンス図である。 本発明の第１の実施形態のアプリケーションサーバを利用して情報端末に表示される、Ｗｅｂ画面上の操作に対する世代振り分けを行う方法で世代番号を付与するフィルタの処理を示すフローチャートである。 本発明の第１の実施形態のＵＲＬ−世代番号管理テーブルを示す説明図である。 本発明の第１の実施形態のｒｅｆｅｒｅｒ−世代番号管理テーブルを示す説明図である。 本発明の第１の実施形態のＵｓｅｒ−Ａｇｅｎｔ−世代番号管理テーブルを示す説明図である。 本発明の第１の実施形態のアプリケーションロジックの連携パターンで世代振り分けを行う処理を示すシーケンス図である。 本発明の第１の実施形態のアプリケーションロジック連携世代管理テーブルを示す説明図である。

まず、本発明のアプリケーションサーバについて、端末―サーバ間における通信のネットワーク概要、及びアプリケーションサーバの物理的構造を示す。続いて、本発明を実現する為の論理的構造を示す。続いて、端末がサーバに対して処理要求を送信する時のシーケンス図を用いて、処理の全体の流れを説明し、シーケンス図上の各ポイントについて、サーバ内部の動作詳細をフローチャート、テーブル図を用いて説明する。続いて、アプリケーションサーバに対するアプリケーションロジック登録、削除、アップデートについてシーケンス図を用いて説明し、最後にアプリケーションアップデート時の世代管理方法についての動作を示す。

図１は、本発明の第１の実施形態のシステムのネットワークを示す説明図である。

図１は、アプリケーションサーバ１１とＳＩＰサーバ１２とに処理要求を送信する情報端末Ｗｅｂブラウザ１４及び情報端末ＳＩＰクライアント１５、アプリケーションサーバ１１において動作するアプリケーションロジックを開発し、開発されたアプリケーションロジックをアプリケーションサーバ１１に登録、削除、又はアップデートするロジック開発端末１６、及び、アプリケーションサーバ１１とＳＩＰサーバ１２とその他のサーバを含むサーバ群１３が、ネットワーク１７によって接続されるネットワーク図である。

アプリケーションサーバ１１は、本発明を導入したアプリケーションサーバ１１であり、Ｊａｖａ ＨＴＴＰ Ｓｅｒｖｌｅｔ（例えば、非特許文献１参照）、及び／又は、Ｊａｖａ ＳＩＰ Ｓｅｒｖｌｅｔ（例えば、非特許文献２参照）の規定に従ったＪａｖａ Ｓｅｒｖｌｅｔの概念によって動作するＨＴＴＰ及び／又はＳＩＰ Ｓｅｒｖｌｅｔサーバ（以下、ＨＴＴＰ／ＳＩＰ Ｓｅｒｖｌｅｔサーバと表記）である。

ただし、アプリケーションサーバ１１は、Ｊａｖａ Ｓｅｒｖｌｅｔの概念に従って動作するサーバであれば、前述の規定以外の規定に従ったサーバでもよく、アプリケーションサーバ１１において用いられる通信プロトコルは、ＨＴＴＰ、又は、ＳＩＰに限定されない。また、用いられるＨＴＴＰ Ｓｅｒｖｌｅｔ、又は、ＳＩＰ Ｓｅｒｖｌｅｔは、いずれのバージョンでもよい。また、アプリケーションサーバ１１は、複数存在してもよい。

情報端末Ｗｅｂブラウザ１４、及び情報端末ＳＩＰクライアント１５は、アプリケーションサーバ１１とＳＩＰサーバ１２とに処理要求を送信する端末である。以下において、情報端末Ｗｅｂブラウザ１４、及び情報端末ＳＩＰクライアント１５を情報端末と総称する。

ロジック開発端末１６は、アプリケーションサーバ１１において動作させるアプリケーションロジックを開発し、開発されたアプリケーションロジックをアプリケーションサーバ１１に登録、削除、又はアップデートする開発端末である。

また、ＳＩＰサーバ１２は、情報端末ＳＩＰクライアント１５と通信し、情報端末ＳＩＰクライアント１５がＳＩＰ Ｓｅｒｖｌｅｔによって構成される場合に、情報端末ＳＩＰクライアント１５が送信したＳＩＰメッセージを送信先の装置に転送するサーバである。

アプリケーションサーバ１１、ＳＩＰサーバ１２、情報端末Ｗｅｂブラウザ１４、情報端末ＳＩＰクライアント１５、及びロジック開発端末１６は、各々、少なくとも、プロセッサ、メモリ、入出力装置、及びネットワークインターフェースを備える。

前述した各サーバ及び端末は、ネットワーク１７を介して、処理要求の送信、処理結果の応答、並びに、アプリケーションロジックの登録、削除、及びアップデート等の通信を行う。中継網となるネットワーク１７は、例えば、情報端末Ｗｅｂブラウザ１４、及び情報端末ＳＩＰクライアント１５が一般家庭にあり、通信事業者が保持する各種サーバ群１３にアクセスする場合、通信事業者が保持するアクセスネットワーク、又はバックボーンネットワークである。

また、ネットワーク１７は、例えば、ロジック開発端末１６が、開発者の宅内又はロジック開発ベンダの社内にある場合、サーバ群１３にアクセスする為に、通信事業者が用意した専用線網をであってもよい。ただし、本発明において、ネットワーク１７の具体的な経路は、特に限定されない。さらに、ネットワーク１７の通信プロトコルも、情報端末Ｗｅｂブラウザ１４及び情報端末ＳＩＰクライアント１５とサーバ群１３、ロジック開発端末１６が互いにネットワーク１７を介して、相互に到達可能であればＩＰプロトコルに限定されなくてもよい。

図２は、本発明の第１の実施形態のアプリケーションサーバ１１の機能を示すブロック図である。

図２に示すブロック図は、アプリケーションサーバ１１に備わるソフトウェアによって実装される機能の論理的な構成を示す図であるが、各機能ブロックの一部をハードウェアによって実装してもよい。また、同じ機能を実装できれば、異なる機能ブロックの構成であってもよい。

アプリケーション装置１１は、サーブレット処理要求送受信制御部３３−１、サーブレットロジック実行部３３−２、及びフレームサーク部３２を備える。

サーブレット処理要求受信制御部３３−１は、要求パケットを受信するユーザ処理要求パケット受信部４１、受信された要求パケットを分析する受信パケット受信部４２、受信した要求パケットに対する応答パケットを構築する送信パケット構築部４８、及び、構築された応答パケットを送信する処理応答パケット送信部４９を備える。

サーブレットロジック実行部３３−２は、フレームワークアダプタ４３を備える。フレームワークアダプタ４３は、後述するテーブルを更新及び参照する。

フレームワーク部３２は、アプリケーションロジック取得実行部４４、アプリケーション情報検索部４５、及びアプリケーションロジック４６を備える。アプリケーション情報検索部４５は、後述するアプリケーションロジック管理テーブル３６を更新及び参照する。

アプリケーションロジック管理テーブル３６、入力値管理テーブル３７、出力値管理テーブル３８、アダプタＩＦ管理テーブル３９、入出力クラスバイナリ管理テーブル４０、及び、エラー出力管理テーブル３０４には、テーブル形式によってデータが保持され、アプリケーション装置１１によって更新及び参照される。

図３は、本発明の第１の実施形態のアプリケーションサーバ１１の物理構成を示すブロック図である。

図３は、図２に示す機能ブロックを実装するハードウェアの構成を示すブロック図である。

アプリケーションサーバ１１は、メモリ２２、ストレージ２３、ＣＰＵ２４、データバス２５、ネットワークインターフェース２６、及びデータベースインターフェース２７を備える。また、アプリケーションサーバ１１は、データベースインターフェース２７を介してデータベース２８に接続される。また、管理コンソール２１も、アプリケーションサーバ１１に接続される。

図２に示す各機能ブロックを実行する為のモジュールは、通常時、ストレージ２３にファイルとして格納される。すなわち、サーブレット処理要求送受信制御部３３−１及びサーブレットロジック実行部３３−２のモジュールは、サーブレットプログラムファイル３０２に、サーブレットロジック実行部３３−２において実際に実行されるサーブレットロジック（本発明では、フレームワークアダプタ４３）のモジュールは、サーブレットロジックファイル３５に、フレームワーク部３２（イネーブラフレームワーク）のアプリケーションロジック取得実行部４４及びアプリケーション情報検索部４５（アプリケーションロジック４６本体を除く部分）のモジュールは、フレームワークプログラムファイル３４に格納される。また、アプリケーションロジック４６は、図３に示すデータベース２８のアプリケーションロジック管理テーブル３６にテーブルレコードとして格納される。

前述のモジュールは、実際に実行される際に、図３に示すＣＰＵ２４の命令によって、それぞれ格納された場所からデータバス２５を経由してメモリ２２に展開され、ＣＰＵ２４によって実行される。フレームワークプログラムファイル３４は、メモリ２２において、フレームワークプログラム３２０として展開され、サーブレットロジックファイル３５は、サーブレットロジック３０３として展開され、サーブレットプログラムファイル３０２は、サーブレットプログラム３３として展開される。アプリケーションロジック３１は、複数展開され、アプリケーションロジック４６を実行する。一時データ３０１は、一時的な記憶であり、処理が終了後、サーブレットシステムが不要であると判断したタイミングで消去される。

ネットワークインターフェース２６は、図１に示すネットワーク１７とアプリケーションサーバ１１との通信を接続し、複数個用いられてもよい。データベースインターフェース２７は、データベース２８とプリケーションサーバ１１との通信を接続する。

個々のモジュールが動作する際に必要なデータは、データベース２８及び／又はメモリ２２上の一時データ３０１に格納されている。一時データ３０１は、必要に応じて参照及び更新される。その際、データベース２８に格納されたデータは、インタフェース（ＩＦ）２７を経由して参照及び更新される。

なお、データベース２７とサーバ１１は物理的に異なる装置で構成してもよいし、同一装置内部に論理的に構成してもよい。

また、ＨＴＴＰ／ＳＩＰ Ｓｅｒｖｌｅｔにおける設定ファイルは、図３に示すストレージ２３のサーブレット設定ファイル３０５に格納される。このサーブレット設定ファイル３０５には、アプリケーションサーバ１１において扱うサーブレットロジックの名称定義、情報端末Ｗｅｂブラウザ１４及び情報端末ＳＩＰクライアント１５からの処理要求に記載されたアドレス（ＨＴＴＰにおけるＵＲＬ、ＳＩＰにおけるＳＩＰ−ＵＲＩ）、サーブレットロジックの対応、前述のアドレスへのフィルタ設定、存在しないアドレスにアクセスがあった場合の動作ポリシ等、Ｊａｖａ Ｓｅｒｖｌｅｔにおける外部インターフェースの設定が記載される。

サーブレット設定ファイル３０５における、サーブレットロジック名称定義部分と、情報端末からの処理要求に記載されたアドレスと、サーブレットロジックの対応、すなわち外部インターフェース定義部分とに関する記載内容を、図４及び図５において詳述する。

図４は、本発明の第１の実施形態のＪａｖａ ＨＴＴＰ Ｓｅｒｖｌｅｔのサーブレット設定ファイル３０５（ｗｅｂ．ｘｍｌ）を示す説明図である。

Ｊａｖａ ＨＴＴＰ Ｓｅｒｖｌｅｔのサーブレット設定ファイル３０５であるｗｅｂ．ｘｍｌは、ＸＭＬ形式によって記載される。図４に示す”ｓｅｒｖｌｅｔ”から”／ｓｅｒｖｌｅｔ”で囲まれる記載１９１が、サーブレットロジックの名称定義について記載された部分であり、”ｓｅｒｖｌｅｔ−ｍａｐｐｉｎｇ”から”／ｓｅｒｖｌｅｔ−ｍａｐｐｉｎｇ”で囲まれる記載１９４が、外部インターフェースの定義について記載された部分である。

まず、記載１９１に示すサーブレットロジックの名称定義について説明する。記載１９１のうち、記載１９２は、ＸＭＬ形式の”ｓｅｒｖｌｅｔ−ｎａｍｅ”要素によって括られた部分であり、サーブレットロジックの名称を定義する。図４に示すサーブレットロジックには、”ＳｅｒｖｌｅｔＡ”という名称のサーブレットが定義される。

記載１９１のうち、記載１９３は、ＸＭＬ形式の”ｓｅｒｖｌｅｔ−ｃｌａｓｓ”要素によって括られた部分であり、記載１９２において定義された名称に対応する実際のＪａｖａのクラス名称を定義する。図４に示すサーブレットロジックには、Ｊａｖａクラスとして”ｊｐ．ｃｏ．ａａａ．ｂｂ．ｓｅｒｖｌｅｔ”パッケージの”ＳｅｒｖｌｅｔＡ”クラスが定義される。

これら記載１９２及び記載１９３を含む各要素を、記載１９１に示すＸＭＬ形式の”ｓｅｒｖｌｅｔ”要素によって括ることで、各サーブレットロジック名称と実際のＪａｖａクラス名称とのペアが、定義される。

次に、記載１９４に示す外部インターフェース定義について説明する。記載１９５は、ＸＭＬ形式の”ｓｅｒｖｌｅｔ−ｎａｍｅ”要素によって括られた部分であり、外部インターフェースを定義する対象サーブレットの名称が記載される。このサーブレット名称は、記載１９１のサーブレットロジックの名称定義において定義されたサーブレットロジックの名称が記載される。図４に示す外部インターフェース定義では、記載１９１において定義された”ＳｅｒｖｌｅｔＡ”を対象サーブレットとして定義する。

記載１９６は、ＸＭＬ形式の”ｕｒｌ−ｐａｔｔｅｒｎ”要素によって括られた部分であり、外部インターフェースの名称が定義される。図４に示す外部インターフェース定義は、Ｊａｖａ ＨＴＴＰ Ｓｅｒｖｌｅｔの場合の記載であり、外部インターフェースとしてＵＲＬ”／ｓｅｒｖｌｅｔａｐｐ／＊”が定義される。

これら記載１９５及び記載１９６を含む各要素を、記載１９４に示すＸＭＬ形式の”ｓｅｒｖｌｅｔ−ｍａｐｐｉｎｇ”要素によって括ることで、各サーブレットロジックの名称に対応する外部インターフェースを定義する。

図４に示すサーブレット設定ファイル３０５によって、情報端末が、”ｈｔｔｐ：／／［サーバ名称］／ｓｅｒｖｌｅｔａｐｐ／＊”のＵＲＬ（“＊”は、任意の文字列を示す）を、処理要求に含めて送信した場合、サーブレットロジック名称”ＳｅｒｖｌｅｔＡ”として定義されたＪａｖａの”ｊｐ．ｃｏ．ａａａ．ｂｂ．ｓｅｒｖｌｅｔ．ＳｅｒｖｌｅｔＡ”クラスに記載されたプログラムが、サーブレットロジックとして実行される。

図５は、本発明の第１の実施形態のＪａｖａ ＳＩＰ Ｓｅｒｖｌｅｔのサーブレット設定ファイル３０５（ｓｉｐ．ｘｍｌ）を示す説明図である。

Ｊａｖａ ＳＩＰ Ｓｅｒｖｌｅｔのサーブレット設定ファイル３０５であるｓｉｐ．ｘｍｌの、基本的な記述方法は、図４に示すＪａｖａ ＨＴＴＰ Ｓｅｒｖｌｅｔのｗｅｂ．ｘｍｌと同様である。

ＸＭＬ形式によって記載２８１に、サーブレットロジックの名称が定義され、記載２８４に、外部インターフェース定義が記載される。記載２８１は、Ｊａｖａ ＨＴＴＰ Ｓｅｒｖｌｅｔにおける記載１９１と同じであり、記載２８２においてサーブレットロジック名称が定義され、記載２８３において実際に呼び出すＪａｖａクラス名称が定義される。

記載２８４の外部インターフェース定義も、Ｊａｖａ ＨＴＴＰ Ｓｅｒｖｌｅｔにおける記載１９４と同様である。記載２８５には、記載１９５と同じく、定義されたサーブレットロジックの名称が記載される。一方、記載２８６には、アドレス名が記載されるが、Ｊａｖａ ＨＴＴＰ Ｓｅｒｖｌｅｔと記載方法が異なる。

記載２８６は、まずＸＭＬ形式の”ｐａｔｔｅｒｎ”要素によって括られた部分であり、記載２８６には、ＳＩＰメッセージメソッド、及びＵＲＩ等のパターン定義が記載される。記載２８７は、パターン定義が記載された部分である。

記載２８７の１行目は、ＳＩＰメッセージメソッド（ＸＭＬ形式の”ｖａｒ”要素によって定義）が”ＭＥＳＳＡＧＥ”（ＸＭＬ形式の”ｖａｌｕｅ”要素によって定義）と一致する（ＸＭＬ形式の”ｅｑｕａｌ”要素によって定義）場合を示す。２、３行目も同じ形式によって記載される為、それぞれＳＩＰメッセージメソッドが”ＲＥＧＩＳＴＥＲ”、”ＩＮＶＩＴＥ”に一致する場合を示す。

さらに、記載２８７の三つの行を記載２８６のＸＭＬ形式の”ｏｒ”要素によって括ることで、３行のうち何れかの条件となった場合（ｏｒ条件）であることを示す。

よって、図５に示すｓｉｐ．ｘｍｌは、情報端末によって、”ＭＥＳＳＡＧＥ”、”ＲＥＧＩＳＴＥＲ”、又は、”ＩＮＶＩＴＥ”の何れかのＳＩＰメッセージメソッドを含んだ処理要求が送信された場合、アプリケーションサーバ１１が、サーブレットロジック名称”ＳＩＰＳｅｒｖｌｅｔＡ”として定義された”ｊｐ．ｃｏ．ａａａ．ｂｂ．ｓｅｒｖｌｅｔ．ＳＩＰＳｅｒｖｌｅｔＡ”クラスに記載されたプログラムをサーブレットロジックとして実行することを意味する。

次に、図６のシーケンス図を用いて、図１に示す情報端末ＳＩＰクライアント１５が、アプリケーションサーバ１１に処理要求を送信してから、処理結果を受信するまでの一連のシーケンスについての概要を説明する。

図６は、本発明の第１の実施形態のアプリケーションサーバ１１と情報端末ＳＩＰクライアント１５との動作を示すシーケンス図である。図６に示すシーケンス図において、アプリケーションサーバ１１と通信する情報端末は、ＳＩＰクライアントである場合の動作を示す。また、送受信メッセージは、後述する図７及び図８に示す形式を用いる。また、情報端末ＳＩＰクライアント１５を用いるユーザは、ＵｓｅｒＡである。

なお、アプリケーションサーバ１１と通信する情報端末は、Ｗｅｂブラウザであってもよい。

まず、情報端末ＳＩＰクライアント１５は、ステップ５１において、ＳＩＰサーバ１２に図７に示すＳＩＰメッセージを送信する。ＳＩＰサーバ１２は、ＳＩＰメッセージを受信すると、受信したメッセージの後述する記載７３に基づいて宛先を取得し、ステップ５２においてこのメッセージをアプリケーションサーバ１１に転送する。その際、ＳＩＰサーバ１２はメッセージにＶＩＡヘッダ等の値を追記するが、その内容については本発明では扱わない内容である為、割愛する。

ＳＩＰメッセージを、図７及び図８に示す。

図７は、本発明の第１の実施形態の情報端末ＳＩＰクライアント１５がアプリケーションサーバ１１に処理要求を送信する為のＳＩＰメッセージを示す説明図である。

情報端末ＳＩＰクライアント１５がアプリケーションサーバ１１と通信する場合、通信プロトコルにはＳＩＰ（Ｔｈｅ Ｉｎｔｅｒｎｅｔ Ｅｎｇｉｎｅｅｒｉｎｇ Ｔａｓｋ Ｆｏｒｃｅ、”ＩＥＴＦ ＲＦＣ３２６１”、［ｏｎｌｉｎｅ］、［平成２１年１０月２０日検索］、＜ＵＲＬ：http://www.ietf.org/rfc/rfc3261.txt?number=3261＞参照）を用いる。

図７に示す記載７１は、ＳＩＰリクエストライン部及びヘッダ部であり、記載７２は、メッセージボディ部である。アプリケーションサーバ１１に送られるＳＩＰメッセージは、記載７１及び記載７２を含む。

図８は、本発明の第１の実施形態のアプリケーションサーバ１１が情報端末ＳＩＰクライアント１５に処理結果を応答する為のＳＩＰメッセージを示す説明図である。

また、図８は、図７で送信した処理要求メッセージに対するアプリケーションサーバ１１からの応答メッセージである。図８に示す記載２６１は、ＳＩＰリクエストライン部及びヘッダ部であり、記載２６２は、メッセージボディ部である。アプリケーションサーバ１１からの応答メッセージは、記載２６１及び記載２６２を含む。

図７に示すＳＩＰメッセージは、ＳＩＰのＭＥＳＳＡＧＥメソッドを用いて、処理要求に付随する入力値をメッセージボディ部７２に記載する形式によって、アプリケーションサーバ１１に処理要求を送信する。ただし、処理要求に利用するＳＩＰメッセージのメソッド、ヘッダ構成、入力値の記載位置、及び記載フォーマットについては特に限定しない。

記載７１は、処理要求のアドレス、すなわちＳＩＰ−ＵＲＩを示す記載７３と、後述するＵｓｅｒ−Ａｇｅｎｔヘッダを示す記載７６とを含む。また、記載７２は、パラメータの値を示す記載７４と、パラメータの数値を示す記載７５とを含む。記載７３〜７６についての詳細を後述する。

図８に示すＳＩＰメッセージは、ＳＩＰの２００ ＯＫ応答を用いて、処理結果である出力値をメッセージボディ部２６２に記載する形式によって、情報端末ＳＩＰクライアント１５に処理応答を送信する。ただし、図７と同じく、ＳＩＰメッセージのヘッダ構成、出力値の記載位置、及び記載フォーマットについては特に限定しない。

情報端末に、情報端末ＳＩＰクライアント１５を用いず、情報端末Ｗｅｂブラウザ１４を用いる場合、アプリケーションサーバ１１に送信するメッセージは、ＨＴＴＰメッセージである。図９及び図１０に、ＨＴＴＰメッセージを示す。

図９は、本発明の第１の実施形態の情報端末Ｗｅｂブラウザ１４がアプリケーションサーバ１１に処理要求を送信する為のＨＴＴＰメッセージを示す説明図である。

図１０は、本発明の第１の実施形態のアプリケーションサーバ１１が情報端末Ｗｅｂブラウザ１４に処理結果を応答する為のＨＴＴＰメッセージを示す説明図である。

図９に示す記載８１は、ＨＴＴＰリクエストライン部及びヘッダ部であり、記載８２は、メッセージボディ部である。図１０に示す記載２７１は、ＨＴＴＰリクエストライン部及びヘッダ部であり、記載２７２は、メッセージボディ部である。

図９に示すＨＴＴＰ ＰＯＳＴメソッドを用いて、メッセージボディ部にパラメータの入力値を示し、図１０に示す２００ ＯＫ応答を用いて、メッセージボディ部に出力値を示す形式であるが、ＳＩＰメッセージの場合と同じく、処理要求、応答に利用するＨＴＴＰメソッド、ヘッダ構成、入出力値の記載位置、及び記載フォーマットについては限定しない。

なお、ＳＩＰ及びＨＴＴＰ以外のプロトコルを利用する情報端末とアプリケーションサーバ１１とが通信し、情報端末とアプリケーションサーバ１１とにおけるプロトコルが各々異なる場合であっても、アプリケーションサーバ１１が、Ｊａｖａ Ｓｅｒｖｌｅｔの概念に従ったサーバであれば、通信プロトコルについてはいずれのプロトコルでもよい。

図６に示すステップ５２において、ＳＩＰサーバ１２が送信したＳＩＰメッセージは、アプリケーションサーバ１１のサーブレット処理要求送受信制御部３３−１によって受信される。具体的には、図２のユーザ処理要求パケット受信部４１によって受信される。受信されたＳＩＰメッセージのパケットは、サーブレット処理要求送受信制御部３３−１において、受信パケット分析部４２に送信される。受信パケット分析部４２の処理について具体的に後述する。

ここで、本実施形態のＪａｖａ Ｓｅｒｖｌｅｔのサーブレットロジックの定義について説明する。Ｊａｖａ Ｓｅｒｖｌｅｔでは、前述したサーブレット設定ファイルである、図４に示すｗｅｂ．ｘｍｌ、及び、図５に示すｓｉｐ．ｘｍｌに、各サーブレットロジックの名称定義、及び情報端末から送信された処理要求メッセージに含まれたアドレスとサーブレットロジックとの対応を、複数記載することによって、一つのアプリケーションサーバ１１上で複数のサーブレットロジック、及び各サーブレットロジックと外部インターフェース定義との対応を持つことが可能である。

本実施形態のＪａｖａ Ｓｅｒｖｌｅｔ部分において定義されるサーブレットロジック、及び外部インターフェース定義は、一つだけである。

具体的には、本実施形態のサーブレットロジックには、図２に示すフレームワークアダプタ４３のみが定義され、このフレームワークアダプタ４３のサーブレットロジックに対する外部インターフェースのアドレス定義として、どのアプリケーションサーバ１１においても処理する可能性のあるＵＲＬの全パターンにマッチする様に定義される（例えば、Ｊａｖａ ＨＴＴＰ Ｓｅｒｖｌｅｔでワイルドカード（”＊”）として記載して、情報端末がどのＵＲＬに処理要求を送信してきても全てフレームワークアダプタ４３のサーブレットロジックを呼び出したり、Ｊａｖａ ＳＩＰ ＳｅｒｖｌｅｔによってＳＩＰメッセージメソッドとして”ＭＥＳＳＡＧＥ”を定義し、情報端末が送信してきた全てのＭＥＳＳＡＧＥメソッドのＳＩＰメッセージに対してフレームワークアダプタ４３を呼び出したりなど）。

受信パケット分析部４２は、図６に示すステップ５３において、サーブレットロジック実行部３３−２によって呼び出されるサーブレットロジックを決定する為、まず、受信したメッセージを分解し、情報端末ＳＩＰクライアント１５が指定した処理要求のアドレス（図７に示す記載７３）によって、及び図３に示すサーブレット設定ファイル３０５を検索することによって、該当するサーブレットロジックを選択する処理を実行する。

しかし、前述した様に、本実施形態のサーブレット設定ファイル３０５では、アプリケーションサーバ１１において処理を行う可能性のあるアドレスについて、全てサーブレットロジックとしてフレームワークアダプタ４３を指定している為、結果として本実施形態のアプリケーションサーバ１１上のＪａｖａ Ｓｅｒｖｌｅｔは情報端末ＳＩＰクライアント１５からどのアドレスを指定して処理要求を送信されても、アプリケーションサーバ１１において処理を行う可能性がある限り、受信パケット分析部４２は、すべてフレームワークアダプタ４３をサーブレットロジックとして選択する。つまり、実施形態では、サーブレット設定ファイル３０５に記載する呼び出すサーブレットロジック１種類のみであり、システム起動後にこの設定ファイルを更新する必要はない。

これによって、受信パケット分析部４２は、本実施形態における図６に示すステップ５３において、図７の記載７３に示すＳＩＰ−ＵＲＩ”ｓｉｐ：ａｐｐ１＠ａｂｃ．ｃｏｍ”の値に関わらず、サーブレットロジックとしてフレームワークアダプタ４３を選択する。そして、受信パケット分析部４２は、処理要求メッセージをサーブレットロジック実行部３３−２に備わる、ステップ５３において選択されたフレームワークアダプタ４３に送る。

アプリケーションサーバ１１は、ステップ５３においてサーブレットロジックとしてフレームワークアダプタ４３が選択されると、ステップ５４において、フレームワークアダプタ４３を呼び出し、ステップ５７、５８、及び５５においてフレームワークアダプタ４３を実行する。

ステップ５７における世代番号確認、及びステップ５８における世代番号付与の世代管理については、後述する。以下においては、ステップ５５におけるフレームワークアダプタ４３の処理の詳細を、図１１に示すフローチャートを用いて説明する。

図１１は、本発明の第１の実施形態のフレームワークアダプタ４３の処理を示すフローチャートである。

フレームワークアダプタ４３は、図１１に示すステップ９１において、まず、受信パケット分析部４２から処理要求メッセージを受信する。

フレームワークアダプタ４３は、ステップ９２において受信した、受信パケット分析部４２が処理要求メッセージを分析した結果（図６に示すステップ５３において取得された結果）、取得されたアドレス情報（例えば、Ｊａｖａ ＨＴＴＰ Ｓｅｒｖｌｅｔの場合はＵＲＬ情報、Ｊａｖａ ＳＩＰ Ｓｅｒｖｌｅｔの場合はＳＩＰ−ＵＲＩ、等）と、フレームワークアダプタ４３自身のアダプタ識別子とをキーに、アダプタＩＦ管理テーブル３９を検索する。そして、フレームワーク部３２におけるアプリケーションロジック４６を特定する為の、ＩＦ名称を特定する。

ここでフレームワークアダプタ４３自身のアダプタ識別子は、例えば、フレームワークアダプタ４３自身のクラス名称が考えられるが、アダプタ識別子の命名規則については特に限定されない。アダプタ識別子は、フレームワークアダプタ４３の種類を識別できればどの様な値でもよい。さらに、フレームワークアダプタ４３が複数存在しない場合、フレームワークアダプタ４３は、識別されなくてもよい。

図１２は、本発明の第１の実施形態のアダプタＩＦ管理テーブル３９を示す説明図である。アダプタＩＦ管理テーブル３９は、ステップ９２においてフレームワークアダプタ４３によって検索される。

アダプタ管理テーブル３９において、カラム１７２の値がアダプタ識別子を示し、カラム１７３の値がアドレス情報を示し、カラム１７４の値がフレームワーク部３２において呼び出されるアプリケーションロジック４６のＩＦ名称を示す。Ｊａｖａ Ｓｅｒｖｌｅｔの仕様、フレームワークの動作仕様、又はＪａｖａ Ｓｅｒｖｌｅｔ側のアドレス情報の記載フォーマット等に従って、このアダプタ管理テーブル３９のテーブル構成は、変更されてもよい。

また、アプリケーションサーバ１１毎に同じアプリケーションロジック４６を呼び出す為のアドレスを変更させる場合、又は、同一アドレスであっても呼び出すアプリケーションロジック４６を変更させる場合、カラム１７３に示すアドレス情報は、カラム１７５に示す様に、”アドレス情報”＿”サーバのドメイン名”の形式によって値を格納されてもよい。

この様な記載によって、図１１に示すアダプタＩＦ管理テーブル３９は、例えばレコード１７６とレコード１７７との様に、ドメイン名が”ｄｏｍａｉｎ１”であるサーバのアドレス”／ａｐｐ／ｆｕｎｃ１．ｄｏ”と、ドメイン名が”ｄｏｍａｉｎ２”であるサーバのアドレス”／ａｐｐ／ｆｕｎｃ１．ｄｏ”とを識別し、異なるＩＦ名称を付与する。また、レコード１７６とレコード１７８との様にドメイン名が”ｄｏｍａｉｎ１”であるサーバのアドレス”／ａｐｐ／ｆｕｎｃ１．ｄｏ”と、ドメイン名が”ｄｏｍａｉｎ２”であるサーバのアドレス”／ａｐｐ／ｆｕｎｃＡ．ｊｓｐ”とに同一ＩＦ名称”ｆｕｎｃｔｉｏｎ１”を付与する。

フレームワークアダプタ４３は、次のステップ９３においてステップ９２におけるＩＦ名称の特定が成功したか否か、すなわち、対応するＩＦ名称がアダプタＩＦ管理テーブル３９に存在するか否かを判定する。対応するＩＦ名称が存在しないと判定した場合、フレームワークアダプタ４３は、ステップ１０２においてＩＦエラーと判断し、ステップ１０３でエラー応答を行う。

ステップ１０３においてフレームワークアダプタ４３は、例えば、Ｊａｖａ ＳＩＰ Ｓｅｒｖｌｅｔの場合、エラー応答として２００ ＯＫ応答以外の４０４ Ｎｏｔ Ｆｏｕｎｄ応答や５００ Ｓｅｒｖｅｒ Ｉｎｔｅｒｎａｌ Ｅｒｒｏｒ応答等を返信してもよいし、２００ ＯＫ応答のメッセージボディ内部にエラーである旨を記載して返信してもよい。エラー応答は、ＳＩＰサーバを介して、情報端末ＳＩＰクライアント１５に送信される。応答方法について、本発明では特に限定しない。

ステップ９３において対応するＩＦ名称が存在する場合、次に、フレームワークアダプタ４３は、ステップ９４においてユーザが送信した入力値を、アプリケーションロジック４６が規定するロジック値に変換する為に、入力値管理テーブル３７をステップ９２において取得したフレームワーク部３２上でのＩＦ名称、及び世代情報をキーにして検索する。世代情報については後述する。

図１３は、本発明の第１の実施形態の入力値管理テーブル３７を示す説明図である。

入力値管理テーブル３７において、カラム１６２の値がＩＦ名称を示し、カラム１６３の値がアプリケーションロジック４６を呼び出す際に指定する引数の記載順を示し、カラム１６４の値がこの引数の親メンバの名称（カラム１６６引数名の値）を示し、カラム１６５の値がアプリケーションロジック４６のＪａｖａの引数の型を示し、カラム１６６の値がアプリケーションロジック４６の引数の名称を示し、カラム１６７が情報端末ＳＩＰクライアンｔント１５からの処理要求メッセージに含まれる入力値のパラメータ名を示し、カラム１６８がアプリケーションロジック４６の世代番号情報である。アプリケーションロジック４６の引数仕様、フレームワークの動作仕様等に従って、この入力値管理テーブル３７のテーブル構成は、変更されてもよい。

ステップ９４において、フレームワークアダプタ４３は、検索によって特定したカラム１６２のレコードの全カラムの値を取得する。アプリケーションロジック４６の引数が複数ある場合、又は、引数がＪａｖａクラスであり引数クラスが内部に複数のメンバを持つ場合などには、フレームワークアダプタ４３は、複数レコードを特定する場合もある。

ステップ９４において取得された全レコードについて、フレームワークアダプタ４３は、情報端末ＳＩＰクライアント１５からの処理要求メッセージをアプリケーションロジック４６によって利用できる様な引数の形式に変換する（ステップ９５）。

図１３に示す入力値管理テーブル３７において、ＩＦ名称であるカラム１６２が”ｆｕｃｔｉｏｎ１”に対応するレコードは、レコード３１１、３１２、３１３、及び３１４の四つである。そして、レコード３１１は、カラム１６４が空であることから、各パラメータを格納する為のＪａｖａの親クラスである為、”ｆｕｃｔｉｏｎ１”の引数は、レコード３１２、３３１３、及び３１４が示す三つの引数である。

図１３に示すレコード３１１は、アプリケーションロジック４６の第１引数であるＪａｖａクラス名を”ＩｎｐｕｔＣｌａｓｓＡ”と定義する。実際にアプリケーションロジック４６を呼び出す時、このクラスのメンバに入力値を格納して呼び出すが、入力値を格納する為のクラスメンバをレコード３１２、及び、３１３によって定義する。

レコード３１２、及び、３１３は、カラム１６４に”ｉｎｐｕｔＡ”を格納されることによって、レコード３１１のカラム１６６の値である”ｉｎｐｕｔＡ”と対応付けられ、これらレコードの値がレコード３１１で定義したクラスのメンバである事を定義する。この様に、親クラスのレコードによって定義された引数名を、下位のメンバ又はクラスを定義するレコード上のカラム１６４の親引数によって定義することによって、各レコードの親子関係を定義することができる。従って、アプリケーションロジック４６の引数が、内部に他のメンバを複数持つ場合においても、入力値管理テーブル３７によって、引数を定義可能である。

ただし、入力値管理テーブル３７の構成については、アプリケーションロジック４６の引数が多段でメンバ変数を持つことを表現できれば、他の構成を用いてもよい。

レコード３１２、及び３１３は前述の通り、レコード３１１の下位メンバであり、これらレコードはカラム１６７の元パラメータの値が空でない為、情報端末ＳＩＰクライアント１５からの処理要求メッセージに含まれる入力値情報を、これらレコード３１２、及び３１３に従い変換する必要がある。

レコード３１２は、元パラメータを示すカラム１６７の値が”ｌａｔｉｔｕｄｅ”である。この為、フレームワークアダプタ４３は、本実施形態において、情報端末ＳＩＰクライアント１５から送られた処理要求メッセージのパラメータである図７に示す記載７２のうち、ＸＭＬ要素の”ｎａｍｅ”の部分が、図７に示す記載７４の様に”ｌａｔｉｔｕｄｅ”である要素の値７５を、アプリケーションロジック４６の入力値に変換する。

また、変換後の入力値の型は、レコード３１２のカラム１６５が示す引数の値が”ｆｌｏａｔ”である為、ｆｌｏａｔ型である。よって、フレームワークアダプタ４３は、記載７５に示す入力値”４７．２２３”をＪａｖａのｆｌｏａｔ型に変換して、ＩｎｐｕｔＣｌａｓｓＡクラスのメンバ変数に格納するが、その際、レコード３１１において定義されたＩｎｐｕｔＣｌａｓｓＡクラスをアプリケーションロジック４６の引数用にインスタンス化する必要がある。ＩｎｐｕｔＣｌａｓｓＡクラスをインスタンス化する動作について説明する。

図１４は、本発明の第１の実施形態の入出力クラスバイナリ管理テーブル４０を示す説明図である。

入出力クラスバイナリ管理テーブル４０において、カラム２９１の値は、ＩＦ名称を示す。カラム２９２の値は、入出力情報として利用するクラスのＪａｖａプログラムバイナリを示す。カラム２９３の値は、カラム２９２に格納されたプログラムバイナリによって定義されたクラスの名称を示す。カラム２９４の値は、世代番号を示す。

入出力値のＪａｖａクラス情報について、全てのクラス情報が入出力クラスバイナリ管理テーブル４０に格納される必要はない。例えば、入出力値のクラスが、Ｊａｖａの標準ライブラリとして用意されたクラス（Ｌｉｓｔ型等）である場合、フレームワークプログラム３２０がデフォルトで呼び出すライブラリファイルの中にプログラムバイナリが含まれている筈である。

また、例えばユーザーＩＤと位置情報との組み合わせの様に、汎用性の高い入出力値について、フレームワーク部３２上でアプリケーションロジック４６の共通入出力クラスとして定義し、Ｊａｖａの標準ライブラリが管理するクラスと同様、フレームワークプログラム３２０がデフォルトで呼び出すライブラリファイルの中に、このクラスのプログラムファイルを導入しておけば、全てのクラス情報が入出力クラスバイナリ管理テーブル４０に格納される必要はない。

入出力クラスバイナリ管理テーブル４０に格納されるプログラムバイナリ情報は、あくまで各アプリケーションロジック４６が利用する独自の入出力クラスであればよい。

ステップ９５において、フレームワークアダプタ４３は、入力値管理テーブル３７に示すレコード３１２のカラム１６５に格納されたＪａｖａクラス名称が、Ｊａｖａ標準ライブラリによって定義されたクラス、又はフレームワーク部３２上で定義された共通クラスの、どちらでもないことを確認し、入力値管理テーブル３７のカラム１６５に記載されたクラス名称をキーにして、入出力値クラスバイナリ管理テーブル４０のカラム２９３を検索し、カラム２９２からプログラムバイナリを取得する。

なお、カラム１６５に格納されたＪａｖａクラス名称が、Ｊａｖａ標準ライブラリによって定義されたクラス、又はフレームワーク部３２上で定義された共通クラスの、どちらかであった場合、フレームワークアダプタ４３は、ステップ９８に移る。

ステップ９５において、フレームワークアダプタ４３は、取得されたプログラムバイナリを、図２に示すメモリ２２にインスタンスとして展開し、このインスタンスに含まれる各メンバの値を格納する。

フレームワークアダプタ４３は、レコード３１３についても同じく、情報端末ＳＩＰクライアント１５からの処理要求メッセージに含まれる”ｌｏｎｇｉｔｕｄｅ”の値を、Ｊａｖａのｆｌｏａｔ型に変換してメンバ変数として格納する。

この様にして生成されたＩｎｐｕｔＣｌａｓｓＡクラスのインスタンスが、ＩＦ名称”ｆｕｎｃｔｉｏｎ１”によって指定されるアプリケーションロジック４６の引数となるが、図１３に示すレコード３１１〜３１３のカラム１６３が示す引数番号の値が”１”である為、この引数は、アプリケーションロジック４６の第１引数となる。

同じく、ＩＦ名称”ｆｕｎｃｔｉｏｎ１”で指定されるアプリケーションロジック４６の引数の中の第２引数は、図１３のレコード３１４に示されるＪａｖａ Ｓｔｒｉｎｇ型の”ｎａｍｅ”である。この第２引数も、前述の第１引数と同じく情報端末ＳＩＰクライアント１５からの処理要求メッセージに含まれる入力値”ｉｄ”の値を、ＪａｖａのＳｔｒｉｎｇ型に変換して引数とする。

図１１に示すステップ９５において、フレームワークアダプタ４３は、前述の処理をステップ９４において図１３に示す入力値管理テーブル３７から取得された全レコードについて行う。

フレームワークアダプタ４３は、ステップ９５において、全レコードへの変換処理が全て完了すると、次にステップ９６においてアプリケーションロジック４６の入力値に過不足があるか否かを判定する。

例えば、図１３に示す入力値管理テーブル３７から取得されたレコードについて、情報端末ＳＩＰクライアント１５からの処理要求メッセージに含まれる入力値情報に記載されていない値が一つでも存在した場合、すなわち、処理要求メッセージに含まれる入力値情報の項目不足があった場合、又は、情報端末ＳＩＰクライアント１５からの処理要求メッセージに含まれる入力値情報の全てが、図１３に示す入力値管理テーブル３７から取得されたレコードに対応付けられなかった場合、すなわち、入力値管理テーブル側のレコード不足があった場合、フレームワークアダプタ４３は、ステップ９６からステップ１０１に進む。

さらに、フレームワークアダプタ４３は、ステップ１０１において、エラー内容を入力値エラーと判定し、ステップ１０３において入力値エラーをエラー応答として情報端末ＳＩＰクライアント１５に返信する。返信方法は、ステップ１０２においてＩＦエラーが判定された場合と同じである。しかし、ステップ１０２とステップ１０１とでは、エラー内容が異なる。

ステップ９６において、入力値に過不足はないと判定された場合、フレームワークアダプタ４３は次に、ステップ９７において、入力値をアプリケーションロジック４６の引数に変換できなかったレコードがあるか否かを判定する。入力値を引数に変換できない場合とは、例えば、アプリケーションロジック４６側のＪａｖａの型はｆｌｏａｔ型であるが、情報端末ＳＩＰクライアント１５からの処理要求メッセージに含まれる入力値情報の値は文字列であり、文字列を数値型であるｆｌｏａｔ型に変換する事ができない様な場合である。

ステップ９７において、入力値を引数に変換できなかったレコードがあった場合、ステップ９６と同じく、フレームワークアダプタ４３は、ステップ１０１において、入力内容を入力エラーと判定する。そして、ステップ１０３においてエラー応答を情報端末ＳＩＰクライアント１５に返信する。

なお、本実施形態におけるステップ９７において、フレームワークアダプタ４３は、情報端末ＳＩＰクライアント１５からの入力値とＪａｖａの型への変換可否とについてのみを判定したが、例えば、図１３に示す入力値管理テーブル３７にアプリケーションロジック４６の各引数について値の範囲（例えば、０より大きな数字、かつ、３０文字以下の文字列等）を定義し、その値の範囲を超えていた場合エラーと判定する処理を追加してもよい。

以上の処理によって、フレームワークアダプタ４３は、図６に示すステップ５５を終了する。

ステップ９７における判定によって、入力値を引数に変換できないレコードはないと判定された場合、アプリケーションロジック４６による実行が可能である為、フレームワークアダプタ４３は、ステップ９８において、フレームワーク部３２の処理を呼び出し、ステップ９９におけるフレームワーク部による処理に続く。

この図１１に示すステップ９８は、図６に示すステップ５６のフレームワーク呼び出しに相当する。具体的には、図２に示すフレームワーク部３２のアプリケーションロジック取得実行部４４を呼び出す。その際に、ステップ９２において取得されたＩＦ名称とステップ９５において変換したアプリケーションロジック４６の引数、及び他の付随情報（例えば、世代情報等）とを、処理要求としてアプリケーションロジック取得実行部４４に送信する。

次に、図６に示すステップ５６において呼び出されたフレームワーク部３２上で実行するステップ５９のロジック選択及び実行処理について、図１５に示すフローチャート図を用いて詳述する。

図１５は、本発明の第１の実施形態のフレームワーク部３２の処理を示すフローチャートである。

フレームワーク部３２のアプリケーションロジック取得実行部４４は、ステップ１１１において、フレームワークアダプタ４３から処理要求を受信する。そして、アプリケーションロジック４６のプログラム情報を取得する為に、ステップ１１２において、フレームワークアダプタ４３か受信したＩＦ名称をキーにして、アプリケーションロジック管理テーブル３６を検索する。後述の世代情報も管理される場合は、世代番号も検索キーに含める。

なお、実際の検索処理は、図２に示すフレームワーク部３２のアプリケーション情報検索部４５がアプリケーションロジック管理テーブル３６にアクセスして検索する。

図１６は、本発明の第１の実施形態のアプリケーションロジック管理テーブル３６を示す説明図である。

アプリケーションロジック管理テーブル３６において、カラム１５２の値がアプリケーションロジック４６のＩＦ名称を示し、カラム１５３の値がアプリケーションロジック４６のプログラムバイナリを示し、カラム１５４の値がアプリケーションロジック４６のＪａｖａクラス名称を示し、カラム１５５の値がアプリケーションロジック４６のＪａｖａメソッド名称を示し、カラム１５６の値が各アプリケーションロジック４６の世代番号を示す。

アプリケーションロジック管理テーブル３６は、アプリケーションロジック４６のインスタンス化の方法、又は、フレームワーク部３７の動作仕様等に合わせて、異なる構成によって構築されてもよい。

アプリケーションロジック取得実行部４４は、ステップ１１２において、テーブル１５１を検索した後、ステップ１１３において、対応するバイナリが存在するか否かを判定する。ステップ１１２においてレコードを取得した場合、対応するバイナリは存在したと判定し、レコードを取得できなかった場合、対応するバイナリは存在しなかったと判定する。

ステップ１１３において、対応するバイナリが存在しないと判定した場合、アプリケーションロジック取得実行部４４は、ステップ１２２に進み、エラー内容をＩＦエラーと判定する。そして、ステップ１１８において、フレームワーク部の呼び出し元であるフレームワークアダプタ４３に、エラー内容を返信する。エラー内容を返信する方法は、Ｊａｖａの例外をスローする方法、又は、エラー出力を戻す方法等のいずれでもよく、本発明においては、特に限定しない。

ステップ１１３において、対応するバイナリが存在したと判定した場合、アプリケーションロジック取得実行部４４は、ステップ１１４において、ステップ１１２において取得されたバイナリ情報を、図３に示すメモリ２２上にアプリケーションロジック３１の形式によって展開する。

なお、取得されたバイナリ情報は、図１６に示すカラム１５４に記載されたクラス名称に従ったクラスとしてインスタンス化され、メモリ２２に展開される。つまり、図３に示すアプリケーションロジック４６３３は、アプリケーションサーバ１１上で管理するアプリケーションロジック４６の数、又は情報端末ＳＩＰクライアント１５からの処理要求メッセージの数分だけ存在することとなる。

アプリケーションサーバ１１上で、アプリケーションロジック４６を用いる際に、一つのアプリケーションロジック４６についてインスタンス化してメモリ２２上に展開するバイナリを一つに限定し、各情報端末からの処理要求メッセージについて一つのインスタンスを使いまわす場合、アプリケーションロジック４６３３の数は、アプリケーションサーバ１１上で定義するロジック数となる。また、各情報端末からの処理要求毎にアプリケーションロジック４６のバイナリをインスタンス化した場合、処理要求の数だけアプリケーションロジック４６のインスタンスがメモリ２２に存在することとなる。本実施形態においては、上記二つの方法のどちらを採ることも可能であり、どちらかに限定しない。

ステップ１１４において、アプリケーションロジック３１をメモリ２２上に展開した後、アプリケーションロジック取得実行部４４は、ステップ１１５におけるアプリケーションロジック４６を実際に呼び出す。アプリケーションロジック４６のメソッド名は、カラム１５５に記載されたメソッド名とする。また、アプリケーションロジック４６の引数は、フレームワークアダプタ４３によって変換された引数群を用いる。具体的には、図２に示すアプリケーションロジック取得実行部４４がアプリケーションロジック４６を呼び出すことによってアプリケーションロジック４６を実行する。

その後、アプリケーションロジック３１毎の処理が実施され、アプリケーションロジック取得実行部４４は、その結果を受信すると、ステップ１１６において、処理結果を確認する。アプリケーションロジック４６から例外が出力されたり、処理失敗をしたりなどを示す出力値等を確認した場合、ステップ１２１においてアプリエラーと判定し、ステップ１１８において、フレームワークアダプタ４３にエラーであることを返信する。エラー返信の方法は、ステップ１２２におけるＩＦエラーと同じく、Ｊａｖａの例外をスローする方法、又はエラー出力を戻す方法等のいずれでもよく、本発明においては、特に限定しない。

ステップ１１６において、処理成功と判定された場合、アプリケーションロジック取得実行部４４は、ステップ１１７において、処理成功と判定して、ステップ１１８においてフレームワークアダプタ４３に処理成功を返信する。また、アプリケーションロジック４６が出力値を持つ場合、出力値も同時に返信する。

図６に示すシーケンス図では、ステップ６０の処理結果返信が、図１５に示すステップ１１８に相当する。フレームワーク部３２の処理が終了すると、ステップ１１９に示す様に、処理結果を受信したフレームワークアダプタ４３の処理に続く。

次に、図６に示すステップ６１におけるフレームワークアダプタ４３の処理について、処理詳細を図１７に示すフローチャートを用いて説明する。

図１７は、本発明の第１の実施形態のフレームワークアダプタ４３の処理を示すフローチャートである。

フレームワーク部３２のフレームワークアダプタ４３は、ステップ１３１においてアプリケーションロジック取得実行部４４から処理結果を受信すると、まずステップ１３２においてエラー応答を受信したか否かを判定する。 図１８は、本発明の第１の実施形態のエラー情報管理テーブル３０４を示す説明図である。エラー情報管理テーブル３０４は、ステップ１３４において、各アプリケーションロジック４６によって出力されるエラー情報を、アプリケーションサーバ１１が管理する為のテーブルである。

エラー情報管理テーブル３０４において、カラム３４１の値がＩＦ名称を示し、カラム３４２の値がエラーの名称を示す。また、カラム３４３の値は、入力値管理テーブル３７における入力値情報と同じく、各エラー情報がＪａｖａクラス、及びクラスメンバの様に階層構造を持つ場合に、親となるエラー情報、すなわち上位エラーの、カラム３４２が示すエラー名称の値を示す。

カラム３４４の値は、エラー情報の出力形式区分を示す。カラム３４５の値は、エラーパラメータの名称を示し、エラー区分、すなわちカラム３４４に従って値が変化する。カラム３４６は、カラム３４５に格納されたエラーパラメータに関連する値がエラーと判定される際の値を示す。カラム３４７は、エラーが発生した場合、情報端末ＳＩＰクライアント１５に送信する処理エラー応答に含むエラー情報のパラメータ名称を示す。カラム３４８は、カラム３４７において定義されたパラメータの値を示す。カラム３４９は、世代番号を示す。

エラー出力管理テーブル３０４のカラム３４４、及び３４５の値について、以下に例を示す。

Ｊａｖａメソッドの形式によって定義されたアプリケーションロジック４６は、エラー出力として、戻り値に特殊な値を挿入する方法、又は、例外をスローする方法等、様々な方法を用いる。カラム３４４形式区分は、このエラー情報がアプリケーションロジック４６からどの様な形式によって出力されるかを判定する為の値である。

例えば、図１８に示すカラム３６１の様に、”１”をＪａｖａの例外スロー、”２”をＪａｖａ例外に含まれるメンバ変数の値、及び、”３”を戻り値の値として定義する。この様にエラーの区分を定義すれば、フレームワークアダプタ４３はＪａｖａのプログラムとしてエラーを確認する方法を、カラム３４４の値によって判定することができる。

例えば、レコード３６２に示すカラム３４４の形式区分が”１”のエラーには、Ｊａｖａプログラム上では例外をキャッチする方法によってエラー確認すればよい。また、レコード３６３に示すカラム３４４の形式区分が”２”のエラーには、Ｊａｖａプログラム上では例外をキャッチした後、その例外のメンバを確認すればよい。レコード３６４に示すカラム３４４の形式区分が”３”のエラーには、アプリケーションロジック４６のメソッドを呼び出した後、戻り値の内容を確認すればよい。

この様にエラー発生パターンをエラー情報の一部に持つことによって、アプリケーションロジック４６による様々なエラー出力の形態に対応でき、アプリケーションロジック４６として登録可能なＪａｖａプログラムの幅が広がる。すなわち、アプリケーションロジック４６のＪａｖａクラス定義、Ｊａｖａ継承定義、戻り値定義、引数定義、及び、エラー出力定義を制限せずに登録することができる。

カラム３４５の値は、カラム３４４の形式区分の値に従って、変化する。例えば、形式区分が”１”の場合、レコード３６２の様にカラム３４４にＪａｖａの例外クラス名が格納され、形式区分が”２”の場合、レコード３６３の様にカラム３４４に例外クラスのメンバ名称が格納され、形式区分が”３”の場合、レコード３６４の様に戻り値のＪａｖａの型が格納される。

この様にカラム３４５に、各形式区分毎に必要となる情報を格納することによって、例えば、レコード３６２の場合なら、キャッチしたＪａｖａ例外のクラスを検索し、カラム３４５に格納されたクラスと合致するかを確認することによって、エラー情報を確定させることができる。レコード３６３の場合であれば、キャッチしたＪａｖａ例外についてカラム３４５に記載した名称のメンバの値を確認することによって、エラー情報を確定させることができる。レコード３６４の場合であれば、アプリケーションロジック４６の戻り値をカラム３４５に記載した型に変換して値を確認することによって、エラー情報を確定させることができる。

また、全てのエラー情報がエラー出力管理テーブル３０４に格納される必要はない。例えば、Ｊａｖａの標準ライブラリが出力するエラーであれば、予めフレームワークアダプタ４３のプログラム上にデフォルト処理として導入して置けばよい。また、文字数超過やデータベース接続失敗と言った汎用性の高いエラーは、フレームワーク上でアプリケーションロジック４６の共通エラーとして定義しておけば、Ｊａｖａの標準ライブラリが出力するエラーと同じく、フレームワークアダプタ４３のプログラム上にデフォルト処理として導入しておけばよい。エラー出力管理テーブル３０４に格納されるエラー情報は、あくまで各アプリケーションロジック４６が出力する独自のエラーのみを記載しておけばよい。

エラー応答を受信した場合、フレームワークアダプタ４３は、ステップ１４２においてアプリ処理エラーと判定し、ステップ１４３において情報端末ＳＩＰクライアント１５にエラー応答を返信する。その場合、該当するエラー情報のカラム３４７に記載されたパラメータ名称であるカラム３４８に格納された値を、エラー応答に含める。エラー応答の返信方法は、図１１に示すステップ１０３のエラー応答と同じである。

ステップ１３２において、正常応答を受信した、すなわちエラー応答は受信していないと判定した場合、フレームワークアダプタ４３は、情報端末ＳＩＰクライアント１５が処理要求メッセージに付与してきた入力値を、アプリケーションロジック４６用の形式に変換した図１１に示す処理とは逆に、アプリケーションロジック４６からの出力値を、情報端末ＳＩＰクライアント１５に送る処理応答に付与する出力値情報の形式に変換する処理を行う。処理方法は、入力値変換とほぼ同様であり、まず、ステップ１３３において、出力値管理テーブル３８を、ＩＦ名称をキーにして検索し、全出力値を取得する。

図１９は、本発明の第１の実施形態の出力値管理テーブル３８を示す説明図である。

出力値管理テーブル３８において、カラム１８２の値がＩＦ名称を示し、カラム１８３の値がこの戻り値の親メンバの名称（カラム１８５に格納される戻り値名の値）を示し、カラム１８４の値がアプリケーションロジック４６の戻り値のＪａｖａの型を示し、カラム１８５の値がアプリケーションロジック４６の戻り値の名称を示し、カラム１８６が情報端末ＳＩＰクライアント１５への処理応答に含む出力値のパラメータ名を示し、カラム１８７がアプリケーションロジック４６の世代番号情報を示す。出力値管理テーブル３８は、アプリケーションロジック４６の戻り値仕様、又はフレームワークの動作仕様等に合わせて、異なる構成によって構築されてもよい。

フレームワークアダプタ４３は、ステップ１３３において、検索によって特定された出力値管理テーブル３８のレコードの全カラムの値を取得する。アプリケーションロジック４６の戻り値がＪａｖａクラスであり、戻り値クラスが内部に複数のメンバを持つ場合は複数レコードを特定する場合もある。

フレームワークアダプタ４３は、ステップ１３４において、ステップ１３３において取得された全レコードに基づいて、アプリケーションロジック４６から受信した戻り値を、情報端末ＳＩＰクライアント１５への処理応答の形式に変換する。

図１９に示す出力値管理テーブル３８において、カラム１８２が示すＩＦ名称が”ｆｕｎｃｔｉｏｎ１”であるレコードは、レコード３２１、３２２、及び３２３の三つであり、レコード３２１は、各パラメータを格納する為のＪａｖａの親クラスの情報を示す為、戻り値としては、レコード３２２、及び３２３の二つの値が存在することになる。

レコード３２１は、アプリケーションロジック４６の戻り値のＪａｖａクラス名を”ＯｕｔｐｕｔＣｌａｓｓＡ”と定義する。これによって、アプリケーションロジック４６からの戻り値は、このクラス”ＯｕｔｐｕｔＣｌａｓｓＡ”となる。

また、”ＯｕｔｐｕｔＣｌａｓｓＡ”には戻り値の具体的な値を格納する為のクラスメンバが存在し、そのメンバがレコード３２２、及び３２３によって定義される。レコード３２２と３２３とは、カラム１８３の値を”ｏｕｔｐｕｔＡ”と指定することによって、レコード３２１のカラム１８５の値”ｏｕｔｐｕｔＡ”と対応付けられ、これらレコードの値がレコード３２１で定義したクラスのメンバであることが定義される。

これらのカラム１８３及びカラム１８５の関係と、図１３に示す入力値管理テーブル３７のカラム１６４及びカラム１６６の関係と同じである。

また、本テーブルの構成については、入力値管理テーブル３７と同様、アプリケーションロジック４６の引数が多段でメンバ変数を持つ構成である事を表現できれば、他の構成方法を用いても構わない。

レコード３２２、及び３２３は前述の通り、レコード３２１の下位メンバであり、これらレコードは、カラム１８６の出力パラメータの値が空でない為、アプリケーションロジック４６からの戻り値をこれらレコードの法則に従い、情報端末ＳＩＰクライアント１５への処理応答に変換する必要がある。

レコード３２２は、戻り値としてアプリケーションロジック４６から取得されたＪａｖａクラス名”ＯｕｔｐｕｔＣｌａｓｓＡ”のインスタンスの内部メンバである”ｐｒｅｆｅｃｔｕｒｅ”（カラム１８５の値）が一つ目の出力であり、情報端末ＳＩＰクライアント１５に処理応答においてカラム１８６に示す出力パラメータ名”ｐｒｅｆｅｃｔｕｒｅ”として、その戻り値を出力すること示す。よって、戻り値の値からメンバ変数”ｐｒｅｆｅｃｔｕｒｅ”を取得し、その戻り値を出力パラメータ”ｐｒｅｆｅｃｔｕｒｅ”として出力する形式に変換する。

レコード３２３についても同じであり、アプリケーションロジック４６からの戻り値からメンバ変数”ｃｉｔｙ”を取得し、その値を出力パラメータ”ｃｉｔｙ”として出力する形式に変換する。

図１７に示すステップ１３４では、上記処理をステップ１３３において、図１９に示す出力値管理テーブル３８から取得された全レコードに変換処理を行う。

図８に示す記載２６２は、出力値を変換した結果の記載例である。出力値の記載フォーマットについては本発明では特に限定されない。

ステップ１３４において出力値を変換した後、フレームワークアダプタ４３は、ステップ１３５において、出力変換に過不足があるか否かを判定する。出力値変換は、入力値変換と異なり、アプリケーションサーバ１１内で管理されたアプリケーションロジック４６が出力する戻り値を、同じアプリケーションサーバ１１内で管理する出力値管理テーブル３８によって変換する為、システム上の矛盾がない限り出力値変換の過不足は発生しないはずである。

よって、ステップ１３５において出力値に過不足があると判定された場合、フレームワークアダプタ４３は、ステップ１４１においてシステムエラーと判定し、ステップ１４３においてその旨を情報端末ＳＩＰクライアント１５に処理応答として送信する。

ステップ１３５において出力値の過不足がないと判定された場合、フレームワークアダプタ４３は、ステップ１３６において情報端末ＳＩＰクライアント１５に正常応答を行う。具体的には、フレームワークアダプタ４３は、Ｊａｖａ Ｓｅｒｖｌｅｔの機能ブロックである図２に示す送信パケット構築部４８を、処理応答返信に必要なパラメータを付与して呼び出す。ステップ１３６は、図６に示すシーケンス図のステップ６２の結果返信に相当する。

処理応答返信要求を受信した送信パケット構築部４８は、各Ｊａｖａ Ｓｅｒｖｌｅｔの仕様に従い、図８、及び図１０の様な返信用の通信パケットを生成し、処理応答パケット送信部４９に生成された通信パケットを送る。そして、処理応答パケット送信部４９は、図６に示すステップ６３において処理結果応答のＳＩＰメッセージをＳＩＰサーバ１２に送信する。

ＳＩＰサーバ１２は、応答ＳＩＰメッセージのあて先を確認し、ステップ６４においてそのメッセージをＵｓｅｒＡが使用する情報端末ＳＩＰクライアント１５に転送する。これによって、ＵｓｅｒＡが使用する情報端末ＳＩＰクライアント１５は、ステップ５１において送信した処理要求に対する応答を受信する。

以上、図６に示す処理において、本発明は、ｗｅｂ．ｘｍｌ及びｓｉｐ．ｘｍｌによって取得されていたＩＦ規定を、フレームワークアダプタ４３がデータベース２８を検索することによって取得するため、ＩＦ規定を更新する際にｗｅｂ．ｘｍｌ又はｓｉｐ．ｘｍｌをアップデートする必要が無くなり、結果サーブレットロジック実行部３３−２を停止することなく、アップデートをすることが可能となる。

また、本発明は、データベース２８を用いることによって、各テーブルの情報にロックをかけることができるため、データベース２８の情報を更新する際も、システムを停止しなくてもよい。

また、本発明は、ステップ５５において、情報端末から送信される処理要求メッセージに含まれた入力情報を、アプリケーションロジック４６に対応した入力値に変換する。そして同じく、ステップ６１において、アプリケーションロジック４６から出力された出力値を、情報端末に対応した出力値に変換する。

以下において、世代番号を用いたアプリケーションロジック４６の実行を説明する。

図２０、図２１、図２２、及び、図２３に示すシーケンス図を用いて、ロジック開発端末１６から本発明のフレームワーク部３２にアプリケーションロジック４６の新規登録、削除、ロジックアップデート、前世代ロジックの削除を行うケースについて説明する。

図２０は、本発明の第１の実施形態のフレームワーク部３２にアプリケーションロジック４６を新規登録する処理を示すシーケンス図である。

以下に示す登録作業は、すべてロジック開発端末１６によって行われる。

アプリケーションロジック４６の新規登録において、ロジック開発端末１６は、まずステップ２０１において新アプリケーションロジック４６のＩＦ名称を決め、アプリケーションロジック管理テーブル３６にＩＦ名称とプログラムのバイナリデータとを新規レコードとして登録する。そして、カラム１５４のクラス名称には、登録する新アプリケーションロジック４６のプログラムバイナリ内で定義される新アプリケーションロジック４６のクラス名称が登録され、カラム１５５には、新アプリケーションロジック４６のプログラムバイナリ内のクラスで定義されるロジックメソッド名称が登録され、カラム１５５の世代番号には、新規登録である為、”１”を付与されたレコードが登録される。

次に、ステップ２０２において新規登録するアプリケーションロジック４６の引数情報について、入力値管理テーブル３７に入力値変換ルールが登録される。カラム１６２には、ステップ２０１において登録されたアプリケーションロジック４６のＩＦ名称が登録される。カラム１６３には、アプリケーションロジック４６のメソッドの引数の順番が登録される。

例えば、アプリケーションロジック４６のメソッドが、
“ｐｕｂｌｉｃ Ｓｔｒｉｎｇ ＭｅｔｈｏｄＡ（Ｓｔｒｉｎｇ ｉｄ、 ｉｎｔ ｎｏ）｛・・・”
と定義されていた場合、引数”ｉｄ”は、第１引数なのでカラム１６３の値は”１”となり、引数”ｎｏ”は第２引数なのでカラム１６３の値は”２”となる。

もし、引数がＪａｖａクラスの形式を採り、その下位メンバを入力値管理テーブル３７において定義する場合、カラム１６３の値は、親のクラスの番号に合わせるか、又は、値を入れないか、いずれかの方法によって登録されてよいが、本実施形態においては、特に記載方法については限定しない。

カラム１６４には、上記の様にこの引数が親クラスの下位メンバである場合、親クラスのカラム１６６の引数名の値が登録される。カラム１６５には、この引数のＪａｖａクラス名が登録される。カラム１６６には、この引数の引数名を登録時に定義され、その値が登録される。カラム１６７には、この引数が情報端末の送信する処理要求に含まれる入力値の内で本引数に対応させるパラメータ名を登録する。カラム１６８には、ステップ２０１において、登録されたアプリケーションロジック４６と同じ世代番号が登録される。

この様にして、アプリケーションロジック４６の全引数（ある引数がＪａｖａクラスである場合は、その下位メンバも含めて）は、１引数１レコードの形式によって登録される。

次に、ステップ２０３において、新規登録するアプリケーションロジック４６の戻り値情報について、出力値管理テーブル３８に出力値変換ルールが登録される。カラム１８２には、ステップ２０１において登録されたアプリケーションロジック４６のＩＦ名称が登録される。カラム１８３には、入力値登録における入力値管理テーブル３７のカラム１６４と同じく、出力値に親クラスが存在する場合、親クラスのカラム１８５の戻り値名が登録される。

カラム１８４には、この戻り値のＪａｖａクラス名が登録される。カラム１８５には、この戻り値の戻り値名を登録時に定義し、その値が登録される。カラム１８６には、この戻り値が情報端末へ送信する処理応答に含ませる出力値の中に出力値を記載する時に指定されるパラメータ名が登録される。カラム１６８は、ステップ２０１において登録されたアプリケーションロジック４６と同じ世代番号が登録される。

この様にして、アプリケーションロジック４６の全戻り値（戻り値がＪａｖａクラスである場合は、その下位メンバも含めて複数となる可能性もある）は、１戻り値１レコードの形式によって登録される。

次に、ステップ２０４において新規登録したアプリケーションロジック４６に対応するアドレス情報を登録する。カラム１７２には、このアプリケーションロジック４６を呼び出すフレームワークアダプタの識別子が登録される。カラム１７３には、情報端末が本アプリケーションロジック４６を実行する為にカラム１７２に登録されたフレームワークアダプタ４３に送信する処理要求に記載するアドレス情報が登録される。ただし、前述した様にシステムによっては、このカラム１７３に、サーバドメインの情報を加えられたアドレス情報が登録されてもよい。カラム１７４には、ステップ２０１において登録されたアプリケーションロジック４６のＩＦ名称が登録される。

次に、ステップ２０５において、新規登録するアプリケーションロジック４６の引数及び戻り値が、独自に定義するＪａｖａクラスであった場合、そのプログラムのバイナリデータが登録される。カラム２９１には、ステップ２０１において登録されたアプリケーションロジック４６のＩＦ名称が登録される。カラム２９２には、入出力によって利用されるクラスのプログラムバイナリが登録される。カラム２９３には、カラム２９２に登録されたプログラムによって定義されたクラス名称が登録される。カラム２９４には、ステップ２０１において登録されたアプリケーションロジック４６と同じ世代番号が登録される。

以上によって、ステップ２０１からステップ２０６までのアプリケーションロジック４６の新規登録時の処理シーケンスを説明したが、これら処理の順番は、システムに従って前後してもよい。

図２１は、本発明の第１の実施形態のフレームワーク部３２からアプリケーションロジック４６を削除する処理を示すシーケンス図である。

本実施形態におけるアプリケーションロジック４６を削除する処理は、ステップ２１１、２１２、２１３、２１４、２１５、及び２１６の順番によって、各テーブルに登録されたアプリケーションロジック４６に関するレコードを全て削除することによって行われる。図２０に示す新規登録の処理と同じく、ロジック開発端末１６は、アプリケーションロジック管理テーブル３６、入力情報管理テーブル３７、出力情報管理テーブル３８、アダプタＩＦ管理テーブル３９、入出力クラスバイナリ管理テーブル４０、及びエラー出力管理テーブル３０６から、アプリケーションロジック４６に関するレコードを全て削除する。

本処理もアプリケーションロジック４６の新規登録と同じく、処理の順番をシステムに従って変更されてもよい。

図２２は、本発明の第１の実施形態のフレームワーク部３２にすでに登録済みのアプリケーションロジック４６を新しいバージョンにアップデートする処理を示すシーケンス図である。

アプリケーションロジック４６をアップデートする処理において、ロジック開発端末１６は、まずステップ２２１において新バージョンのアプリケーションロジック４６をアプリケーションロジック管理テーブル３６に登録する。この登録処理において、本実施形態のロジック開発端末１６は、既存のアプリケーションロジック４６のレコードを上書きしない。かわりに、ロジック開発端末１６は、アプリケーションロジック管理テーブル３６に新しいレコードを登録する。

ロジック開発端末１６が新しく登録するレコードは、アプリケーションロジック管理テーブル３６におけるカラム１５２、１５４、及び１５５の値が、バージョンアップ対象となるアプリケーションロジック４６の元の値を踏襲して登録され、カラム１５３の値が新しいアプリケーションロジック４６のプログラムバイナリを登録される。

新しく登録されるレコードのカラム１５６の世代番号には、アプリケーションロジック管理テーブル３６に登録されたＩＦ名称が同一のアプリケーションロジック４６のうち、登録処理時点において、最大値である世代番号に＋１した値の世代番号が登録される。例えば、レコード３３１の様に、ＩＦ名称”ｆｕｎｃｔｉｏｎ１”のアプリケーションロジック４６をアップデートした場合、レコード３３１のカラム１５６の値”１”を＋１した”２”が、レコード３３２の様にカラム１５６の世代番号に登録される。

本実施形態においては、世代番号を正の整数で示し、世代番号はアップデートされる毎に＋１される方法によって世代を識別する方法を示したが、本発明では、世代管理の方法を特に限定しない。

次に、ロジック開発端末１６は、ステップ２２２、２２３、２２４、及び２２５において、それぞれ入力値管理テーブル３７、出力値管理テーブル３８、入出力クラスバイナリ管理テーブル４０、及びエラー出力管理テーブル３０６に、アップデート後のアプリケーションロジック４６についての各種情報を登録する。ただし、これらの登録は、各情報がアップデートによって変更される場合と変更されない場合において、それぞれ処理が異なる。

各種情報がアップデートによって変更される場合、基本的な処理内容は、前述したアプリケーションロジック４６の新規登録時の処理と同様である。ただし、各テーブルの世代番号を示すカラムの値は、アプリケーションロジック管理テーブル３６のカラム１５６に登録した値と同じ値が登録される。

各種情報がアップデートによって変更されない場合、各テーブルについて、アップデート前のアプリケーションロジック４６を示すレコードを抽出し、該当レコードの世代番号を示すカラムの値をアップデート後のアプリケーションロジック４６の世代番号（アプリケーションロジック管理テーブル３６のカラム１５６に登録した値）に更新する。

この様に、世代番号のみを更新することによって、アップデート後のアプリケーションロジック４６を動作させる場合は、アプリケーションサーバ１１は、同一世代番号の情報を用いてアップデート後のアプリケーションロジック４６を動作させることができる。また、アップデート前のアプリケーションロジック４６を動作させる場合、同一世代番号のアプリケーションロジック４６の情報が上記更新によって無くなる為、アプリケーションサーバ１１は、「自分の世代番号以上の値のうち最も小さな値」の世代番号を持つアプリケーションロジック４６の情報を用いて、アップデート前のアプリケーションロジック４６を動作させる。

例えば、入力値管理テーブル３７について、世代番号”１”のアプリケーションロジック４６がアップデートされて、世代番号”２”のアプリケーションロジック４６が登録されたが入力値は変更されない場合、世代番号”１”の入力値情報のレコードは、世代番号”２”に更新される。その後、さらにアプリケーションロジック４６がアップデートされて世代番号”３”のアプリケーションロジック４６が登録され、入力値が変更される場合、世代番号”２”の入力値情報のレコードはそのまま変更されず、世代番号”３”の入力値情報のレコードを新規登録する。

前述の場合、世代番号”１”のアプリケーションロジック４６が入力値情報を求める際は、自分の世代番号である１よりも大きい値を示す世代番号のうち、最小の世代番号の値を持つアプリケーションロジック４６を抽出する。そして、世代番号”２”の入力値情報のレコードはまだ存在している為、このレコードを利用することとなる。つまり、入力値情報が変更された世代番号”３”の入力値情報は用いられず、正しい入力値情報である世代番号”２”の入力値情報を用いることができる。

これらのアップデート処理も、アプリケーションロジック４６の新規登録時と同じく、処理の順番をシステムに応じて前後されてもよい。

図２３は、本発明の第１の実施形態の所定の世代のアプリケーションロジック４６のみを削除する処理を示すシーケンス図である。フレームワーク部３２に登録済みのアプリケーションロジック４６は、複数世代に渡ってフレームワーク部３２に登録されているものとする。

アプリケーションロジック４６のうち、所定の世代番号を持つアプリケーションロジック４６のみを削除する処理は、まずステップ２２１においてアプリケーションロジック管理テーブル３６から該当アプリケーションロジック４６のレコードを削除する。

次にステップ２２２、２２３、２２４、及び２２５において、ロジック開発端末１６は、入力値管理テーブル３７、出力値管理テーブル３８、入出力クラスバイナリ管理テーブル４０、及びエラー出力管理テーブル３０６に、必要があれば各情報を更新、又は削除する。以下更新、及び削除を実施するときの処理手順について、図２４に示すフローチャートを用いて説明する。

図２４は、本発明の第１の実施形態のアプリケーションロジック４６の特定世代のみを削除する処理を示すフローチャート図である。

まず、アプリケーションサーバ１１は、ロジック開発端末１６からロジック削除（ステップ２２１）の要求を受けると、ステップ３５１において、各テーブルのレコードに、削除するアプリケーションロジック４６と同一のＩＦ名称であり、かつ同一の世代番号であるレコードの存在の有無を判定する。

該当するレコードが存在しない場合、アプリケーションサーバ１１は、更新対象がない為、更新処理を行わずに処理を終了する。

該当するレコードが存在する場合、アプリケーションサーバ１１は、ステップ３５３において、アプリケーションロジック管理テーブル３６上に登録された同一ＩＦ名称のアプリケーションロジック４６のうち、削除するアプリケーションロジック４６の世代番号より小さく、かつ最も大きな世代番号の値を取得する。

例えば、世代番号が”１”、”３”、”４”、及び”６”であるアプリケーションロジック４６がアプリケーションロジック管理テーブル３６に存在し、世代番号”６”のアプリケーションロジック４６を削除する場合、取得する世代番号は、”４”となる。この処理は、アプリケーションロジック管理テーブル３６上に存在する同一ＩＦ名称のアプリケーションロジック４６の中で、削除対象ロジックの一つ前の世代番号を取得する処理である。

世代番号を取得する処理において、削除するアプリケーションロジック４６の世代番号から−１した値を取得する対象としない理由は、すでに−１した値の世代番号を持つアプリケーションロジック４６が削除済みであり、世代番号が歯抜けの状態である場合、単純に−１した値を取得する対象とすることはできないからである。

次にステップ３５４において、アプリケーションサーバ１１は、更新及び／又は削除対象となるアプリケーションロジック管理テーブル３６上に、ステップ３５３において取得された世代番号のレコードが存在するか否かを判定する。

ステップ３５３において取得されたレコードが存在しない場合は、アプリケーションサーバ１１は、ステップ３５５において、削除されるアプリケーションロジック４６の世代番号を持つレコードのカラム１５６の値を、ステップ３５３において取得された値に更新する。

これは、ステップ３５３において取得された世代番号のアプリケーションロジック４６から、削除対象となる世代番号のアプリケーションロジック４６にアップデートする時に、対象情報に変更はなく、ステップ３５３において取得された世代番号のアプリケーションロジック４６が、削除対象となる世代番号の情報を参照して作成されている為である。また、削除対象のアプリケーションロジック４６の世代番号の情報を、そのまま削除してしまうと、ステップ３５３において取得された世代番号のアプリケーションロジック４６が用いる各種情報が存在しなくなったり、又は間違った世代の情報が参照されてしまったりする。

削除対象となる世代番号を持つレコードの値を、ステップ３５３において取得された世代番号の値に更新することによって、ステップ３５３において取得された世代番号のアプリケーションロジック４６は、正確な各種情報を参照することができる。

ステップ３５３において取得されたレコードが存在する場合は、アプリケーションサーバ１１は、ステップ３５３において取得されたレコードを削除する（ステップ３５６）。これは、ステップ３５３において取得された世代番号のアプリケーションロジック４６から削除対象となる世代番号のアプリケーションロジック４６にアップデートする時に、対象となる情報に変更が発生し、新たに各種情報のレコードを登録した為、該当レコードを削除しても、ステップ３５３において取得された一つ前の世代番号のアプリケーションロジック４６が利用する各種情報には影響が出ない為である。

前述の様な処理を、各テーブルについて実施することによって、不要な各種情報を削除することができる。また、本処理もアプリケーションロジック４６の新規登録と同じく、処理の順番をシステムに従って前後させてもよい。

図２５は、本発明の第１の実施形態のアプリケーションロジック４６のアップデート又は削除が行われる際に、情報端末から処理要求を受信した場合のアクセスを切り分けるシステムを示す説明図である。

図２５は、アプリケーションロジック４６が世代管理された状態において、アプリケーションロジック４６がアップデートを実施された瞬間、又はアプリケーションロジック４６を削除された瞬間に、処理要求を送信する情報端末毎に適切な世代のアプリケーションロジック４６を処理させる為の、アプリケーションサーバ１１内部の装置構成を示した図である。また、図２５の説明とあわせて、ユーザからの要求を処理する途中でアプリケーションロジック４６のアップデート、又は、削除が発生した場合のアプリケーションサーバ１１による処理について説明する。

アプリケーションロジック４６をアップデートした場合、図２２に示すシーケンスの様にアプリケーションロジック管理テーブル３６、入力値管理テーブル３７、出力値管理テーブル３８、入出力クラスバイナリ管理テーブル４０、及びエラー情報管理テーブル３０４の各テーブルに、図２５に示すロジック情報２４６、入力情報２４９、出力情報２５２、入出力バイナリ２５８、及びエラー情報３７１の様に新しい世代番号のアプリケーションロジック４６に関連する情報を新規登録するか、又は、既存情報の世代番号の更新を実行する。図２５に示す例では全て新規登録する（前世代番号と内容が変わる）ケースについて記載する。

ある世代番号の処理を実施中に、次の世代番号のアプリケーションロジック４６が登録された場合、図２５に示すロジック情報２４５及び２４６、入力情報２４８及び２４９、出力情報２５１及び２５２、入出力バイナリ２５７及び２５８、並びに、エラー情報２６０及び３７１の様に、各テーブルに同じアプリケーションロジック４６について、世代番号が異なる二つ以上のレコードが存在することになる。

アプリケーションサーバ１１は、この様な場合においても、間違った世代番号のデータを利用しない様にする為に、図６に示すステップ５７において、これから実行するアプリケーションロジック４６の世代番号を確認した後、ステップ５８において図２５に示すメモリ２４１の様に、アプリケーションサーバ１１内部のメモリ２２上に現在処理中のアプリケーションロジック４６の世代番号を記憶する。

メモリ２４１には、処理番号と、世代番号とが格納される。処理番号とは、アプリケーションサーバ１１が現在処理中の処理要求を識別する為に処理を開始する毎に付与されるアプリケーションサーバ１１内でユニークな識別子である。また、図６に示すステップ５８以降の処理において、各テーブルからアプリケーションロジック４６情報を取得する時は、必ずメモリ２４１に含まれる世代番号が用いられる。この様に処理開始の時点で世代番号を記憶しておくことによって、以後の処理においても正しい世代番号のアプリケーションロジック４６情報を取得することが可能となる。

アプリケーションロジック４６を削除する場合、アプリケーションサーバ１１は、図２１に示すシーケンス図の様にアプリケーションロジック管理テーブル３６、入力値管理テーブル３７、出力値管理テーブル３８、アダプタＩＦ管理テーブル３９、入出力クラスバイナリ管理テーブル４０、及びエラー情報管理テーブル３０４の各テーブルから、図２５に示すロジック情報２４４、入力情報２４７、出力情報２５０、入出力バイナリ情報２５６、エラー情報２５９の様に、アプリケーションロジック４６に関連する情報を削除する。

しかし、あるアプリケーションロジック４６の処理を実行中にそのアプリケーションロジック４６を削除した場合、図２５に示すロジック情報２４４、入力情報２４７、出力情報２５０、入出力バイナリ情報２５６、及びエラー情報２５９の様に各テーブルからアプリケーションロジック４６についてのレコードが削除された状態となる。この様な状態が発生すると、処理途中においてアプリケーション情報が必要になった時にレコードが存在せず処理が出来ない状態が発生する。

そこでアプリケーションサーバ１１は、アプリケーションロジック４６を削除する時、図２５に示すメモリ２２を参照し、メモリ２４１に相当する全データを参照する。そこで、削除対象となるアプリケーションロジック４６を利用しているデータが抽出できた場合、削除処理を一旦保留し、全利用情報が無くなった時点で削除する。

ただし、上記処理については、アプリケーションロジック４６のアップデート時に、処理中のフローが正しい世代の情報を参照でき、かつ、処理中のフローが存在する状態でアプリケーションロジック４６を削除しても処理に矛盾が生じない様にできれば、他の方法を用いてもよい。

次に、アプリケーションロジック４６が複数世代登録されていた状態において、各ユーザからの処理要求に対してどの世代のアプリケーションロジック４６を呼び出すかを振り分ける為の方法について説明する。本発明においては、アプリケーションロジック４６の振り分け方法について、以下四つの例を挙げ、順に説明する。

１．アプリケーションサーバ１１を利用して情報端末に表示される、Ｗｅｂ画面上での操作に対する世代振り分け
２．処理要求を受信したときのｒｅｆｅｒｅｒ（送信元ＵＲＬ情報）を利用した、世代振り分け
３．ＳＩＰのＵｓｅｒ−Ａｇｅｎｔヘッダを利用した世代振り分け
４．アプリケーションロジック４６の連携パターンによる世代振り分け
まず、アプリケーションサーバ１１を利用して表示するＷｅｂ画面上の操作に対する世代振り分けを行う方法を図２７に示すシーケンス図、図２９に示すテーブル構成図、及び図２６に示す構成図を用いて説明する。

アプリケーションサーバ１１は、Ｊａｖａ Ｈｔｔｐ Ｓｅｒｖｌｅｔの機能も有する為、ユーザに対してＨＴＭＬを送信し、Ｗｅｂ画面の表示を制御することも可能である。本実施形態において、このアプリケーションサーバ１１は、自身が生成するＨＴＭＬ画面上で、ユーザがアプリケーションロジック４６への処理要求を送信する為のアクションが記載されている部分（ＨＴＭＬ画面におけるｆｏｒｍタグ等）にｈｉｄｄｅｎタグ等を用いることによって、利用するアプリケーションロジック４６の世代番号を埋めこむ。

図２７に示すシーケンス図と、図２６に示す説明図とを用いて、その手順を説明する。

図２６は、本発明の第１の実施形態のアプリケーションサーバ１１を利用して、情報端末に表示されるＷｅｂ画面上の操作に世代振り分けを行うサーブレットフィルタを示す説明図である。

図２６に示す構成は、図２に示すアプリケーションサーバ１１の構成に、サーブレットフィルタ部４５２を追加した構成である。サーブレットフィルタ部４５２には、世代番号付与部４５３が備わる。その他のフレームワーク部３２、及びサーブレット処理要求送受信制御部３３−１等は、図２に示す構成と同じである。また、アプリケーションサーバ１１に接続される各データベースも、図２に示す各データベースと同じである。

フレームワークアダプタ４３は、情報端末において表示される画面のＨＴＭＬを生成する。また、世代番号付与部４５３は、生成されたＨＴＭＬに世代番号を付与する。

図２７は、本発明の第１の実施形態のアプリケーションサーバ１１を利用して、情報端末に表示されるＷｅｂ画面上の操作に世代振り分けを行う処理を示すシーケンス図である。

まず、ＵｓｅｒＡが用いる情報端末Ｗｅｂブラウザ１４は、自身のＷｅｂブラウザに画面を表示する為に、ステップ３８１において、ＵＲＬが指定されたＨＴＴＰ ＧＥＴ（画面ＨＴＭＬの取得要求）をアプリケーションサーバ１１に送信する。このＨＴＴＰ ＧＥＴは、図２６に示すユーザ処理要求パケット受信部４１によって受信され、受信パケット分析部４２によってその内容を分析される。そして、分析されたＨＴＴＰ ＧＥＴがサーブレットロジック実行部に送信されると、サーブレットロジック実行部３３−２に登録されたサーブレットロジック３０３の中から、呼び出すサーブレットロジック３０３が選択される。

これら一連の処理は、図６に示すステップ５３及び５４の処理と同じである。既存技術のみで実現可能なＪａｖａ ＨＴＴＰ Ｓｅｒｖｌｅｔを利用したＷｅｂ画面表示の様なケースでは、図４に示す設定ファイルに、一般的なＨＴＴＰ Ｓｅｒｖｌｅｔと同じ様にＵＲＬとサーブレットロジックの組み合わせを記載すればよい。

その後、アプリケーションサーバ１１は、フレームワークアダプタ４３を呼び出し、図２７のステップ３８２において、ＨＴＭＬを生成する。

その後、アプリケーションサーバ１１は、サーブレットフィルタ部４５２の世代番号付与部４５３によって、ステップ３８２において生成されたＨＴＭＬの必要な部分に、世代番号情報を埋め込む（ステップ３８３）。サーブレットフィルタ部４５２は、既存のＪａｖａ Ｓｅｒｖｌｅｔに用意された機能であり、図４において説明したサーブレット設定ファイルにフィルタを実行する為のＵＲＬパターンと呼び出すフィルタロジックとを記載することによって、自由なフィルタプログラムを呼び出すことが可能である。

本実施形態においては、フレームワーク部３２用に用意された世代番号付与部４５３をフィルタとして用意して、実行させる。世代番号付与部４５３の処理について、図２８のフローチャートを用いて詳述する。

図２８は、本発明の第１の実施形態のアプリケーションサーバ１１を利用して情報端末に表示される、Ｗｅｂ画面上の操作に対する世代振り分けを行う方法によって世代番号を付与するフィルタの処理を示すフローチャートである。

図２８のフローチャートにおいて、世代番号付与部４５３は、まずアプリケーションサーバ１１のフレームワークアダプタ４３によって生成されたＨＴＭＬを受信し、受信したＨＴＭＬの中に、フレームワーク部３２において実行されるアプリケーションロジック４６に処理要求をする為の表記があるか否かを判定する。すなわち、世代番号付与部４５３は、ステップ４６１において、ＨＴＭＬに含まれるアドレス情報と、アダプタＩＦ管理テーブル３９に含まれるアドレス情報とが一致（マッチ）する、アダプタＩＦ管理テーブル３９のレコード（マッチング箇所）を取得する。

Ｗｅｂ画面上からアプリケーションロジック４６に処理要求をする場合、情報端末から送られるＨＴＭＬには、そのアドレス情報（ＵＲＬ）が含まれる。この為、アダプタＩＦ管理テーブル３９のカラム１７３によって管理されるアドレス情報の何れかがＨＴＭＬに含まれる場合、世代番号付与部４５３は、アプリケーションロジック４６を呼び出す処理であると判定できる。

世代番号付与部４５３は、ステップ４６２において、マッチング箇所が取得されたか否かを判定する。

マッチング箇所が取得された場合、すなわち、ＨＴＭＬにアドレス情報と、アダプタＩＦ管理テーブル３９に含まれるアドレス情報とが一致する場合、世代番号付与部４５３は、該当アドレス情報が記載されたアダプタＩＦ管理テーブル３９のレコード内のカラム１７４が示されるＩＦ名称を、後述する処理の為に記憶する。そして、ステップ４６３に進む。

また、マッチング箇所が取得されなかった場合、世代番号付与部４５３は、そのまま処理を終了する。

世代番号付与部４５３は、ステップ４６３において、ＵＲＬ−世代番号管理テーブル３９１の情報を利用して、ステップ４６１において取得されたアプリケーションロジック４６に対する処理要求についての記載部分に、呼び出すロジックの世代番号情報を埋め込む処理を実施する。

図２９は、本発明の第１の実施形態のＵＲＬ−世代番号管理テーブル３９１を示す説明図である。

ＵＲＬ−世代番号管理テーブル３９１において、カラム３９２の値がＩＦ名称を示す。カラム３９３の値が、表示するＷｅｂ画面のＵＲＬを示す。カラム３９４の値が、対応する世代番号を示す。ＵＲＬ−世代番号管理テーブル３９１は、データベース２８に格納される。

すなわち、このＵＲＬ−世代番号管理テーブル３９１は、例えば、あるユーザがカラム３９３に格納されたＵＲＬにアクセスし、Ｗｅｂ画面を表示させようとする際において、一方で、アプリケーションサーバ１１から返信されるＨＴＭＬ情報の中には、カラム３９２に格納されたＩＦ名称のアプリケーションロジック４６に処理要求を実行する様な記載がある場合、返信されるＨＴＭＬ情報の世代番号には、カラム３９４に記載された値が格納される、といった情報を示す。

世代番号付与部４５３は、ステップ４６１において取得されたアダプタＩＦ管理テーブル３９のカラム１７４のＩＦ名称の値と、図２７に示すステップ３８１のＨＴＴＰ ＧＥＴメッセージによって情報端末Ｗｅｂブラウザ１４が指定したＵＲＬとに基づいて、ＵＲＬ−世代番号管理テーブル３９１を検索し、該当レコードのカラム３９４が示す世代番号の値を取得する。そして、ＨＴＭＬ記述の中にｈｉｄｄｅｎタグ等を用いて、この世代番号を埋め込む（ステップ４６３）。

ステップ４６３の処理が完了すると、世代番号付与部４５３は、ステップ４６４において、全てのＨＴＭＬを解析したか否かを判定する。解析されていないＨＴＭＬが残っている場合、アプリケーションサーバ１１はステップ４６１に戻り再度解析を開始する。そして、全てのＨＴＭＬを解析した場合、処理を終了させる。

前述の処理、すなわち図２８に示す処理であり、図２７に示すステップ３８３に相当する処理によって、ＨＴＭＬの情報に世代番号を埋め込んだ後、世代番号付与部４５３は、ステップ３８４において、ＵｓｅｒＡが用いる情報端末Ｗｅｂブラウザ１４にＨＴＭＬ情報を返信する。

その後、ＵｓｅｒＡ（ユーザ）が使用する情報端末Ｗｅｂブラウザ１４に表示されたＷｅｂ画面上で、ユーザがステップ３８５の様にアプリケーションロジック４６に処理要求を送信するボタンを押下するなどの操作を行うと、ステップ３８６において、アプリケーションサーバ１１にアプリケーションロジック４６を実行する処理要求（本実施形態においては、ＨＴＴＰ ＰＯＳＴメッセージ）を送信する。

アプリケーションサーバ１１は、ＨＴＴＰ ＰＯＳＴメッセージによる処理要求を受信すると、図６に示すステップ５３からステップ６２までの処理を実行する。その際に、ステップ５７の世代番号確認の処理において、ＨＴＭＬに埋め込まれ、ＨＴＴＰ ＰＯＳＴのパラメータの一部として処理要求に付与されてきた世代番号を取得することによって、呼び出すアプリケーションロジック４６の世代番号を取得する（図２７に示すステップ３８７のバージョン番号確認が本処理に相当する）。その後、取得された世代番号のアプリケーションロジック４６を実行し（図２７に示すステップ３８８に相当。詳細は図６に記載）、ステップ３８９によって処理結果を返信する。

この様に、フィルタ機能、すなわち、サーブレットフィルタ部４５２が備える世代番号付与部４５３を利用して、アプリケーションサーバ１１自身が生成するＨＴＭＬに世代番号を付与することによって、アプリケーションサーバ１１が備える内部情報のみにおいて利用されるアプリケーションロジック４６の世代番号を管理することが可能となる。また、Ｊａｖａ Ｓｅｒｖｌｅｔによって規定されたフィルタ機能を用いて世代番号付与部４５３を導入する為、サーブレットロジック（フレームワークアダプタ４３）をフレームワーク部３２専用に開発しなくても世代番号を付与することが可能となり、利用可能なサーブレットロジックの幅が広がる。

また、本実施形態において、ユーザに送信するＨＴＭＬに世代番号を埋め込むことによって、世代振り分けを実現したが、Ｊａｖａ Ｓｅｒｖｌｅｔのセッションオブジェクトを利用してもよい。

さらに、ＨＴＴＰには、Ｃｏｏｋｉｅ等を用いることによって、ＨＴＴＰリクエストメッセージが一連性を持つことを示すセッションの概念がある。セッションオブジェクトとは、Ｊａｖａ Ｓｅｒｖｌｅｔがユーザからの同一ＨＴＴＰセッション上でのアクセスに対して、サーバ内部でそのセッションにおいて用いられる一時的な情報をメモリ上に保持しておく為の格納領域のことである。ユーザからのＨＴＴＰアクセスに対してアプリケーションサーバ１１側が前のアクセスと同一セッションであると判定した場合、メモリ２２上から前回アクセス時に生成した情報を取り出すことができる。

例えば、Ｗｅｂショッピングサイトなどにおいて、前に表示されたＷｅｂ画面上で選択された商品を、次の画面上に表示させる様な処理は、前のＷｅｂ画面上において選択された商品の情報をセッションオブジェクトに一旦保持し、次のＷｅｂ画面を表示する時は、セッションオブジェクトから商品情報を取得して表示することによって実現される。

今回のフレームワーク部３２の場合においても、上記説明内のＨＴＭＬに世代管理番号を埋め込む処理の代わりに、セッションオブジェクトに世代管理番号を記憶する処理に変更すれば、ユーザが同一セッション内でアクセスしてくる限り、サーバ側で保持する世代管理番号を利用することができ、上記説明と同様の機能を実現することができる。

次に、処理要求を受信したときのｒｅｆｅｒｅｒ（送信元ＵＲＬ情報）を利用した世代振り分け方法について、図９及び図３０を用いて説明する。

一般的なＨＴＴＰメッセージには、図９に示す記載８４の様なＲｅｆｅｒｅｒヘッダが付与されている。このＲｅｆｅｒｅｒヘッダは、情報端末Ｗｅｂブラウザ１４がＨＴＴＰメッセージを送信する時に付与するヘッダであり、送信するＨＴＴＰメッセージがどのＵＲＬのＷｅｂページを辿って送信されているかを示す情報を含む。

例えば、ユーザが、”ｈｔｔｐ：／／ａａａ．ｃｏ．ｊｐ／ｉｎｄｅｘ．ｈｔｍｌ”のＵＲＬによって表示されるＷｅｂページ上にあるリンクをクリックして”ｈｔｔｐ：／／ｂｂｂ．ｃｏ．ｊｐ／ｉｎｄｅｘ．ｈｔｍｌ”のＵＲＬのページを表示する場合、Ｗｅｂサーバに送信するＨＴＴＰメッセージには、”ｈｔｔｐ：／／ａａａ．ｃｏ．ｊｐ／ｉｎｄｅｘ．ｈｔｍｌ”が含まれたＲｅｆｅｒｅｒヘッダが付与される。本発明のフレームワーク部３２は、ｒｅｆｅｒｅｒ−世代番号管理テーブル４０１と、このＲｅｆｅｒｅｒヘッダの値とを利用して、アプリケーションロジック４６の世代振り分けを可能にする。

図３０は、本発明の第１の実施形態のｒｅｆｅｒｅｒ−世代番号管理テーブル４０１を示す説明図である。

ｒｅｆｅｒｅｒ−世代番号管理テーブル４０１において、カラム４０２の値がＩＦ名称を示す。カラム４０３の値が、ユーザから受信する処理要求に含まれるＲｅｆｅｒｅｒヘッダの値を示す。カラム４０４の値が、アプリケーションロジック４６の世代番号を示す。ｒｅｆｅｒｅｒ−世代番号管理テーブル４０１は、データベース２８に格納される。

本実施形態においてアプリケーションサーバ１１は、ユーザからの処理要求を受信し、図１１に示すステップ９２においてＩＦ名称を取得し、ステップ９３において対応ＩＦ名称が存在することを判定する。そして、アプリケーションサーバ１１は、ステップ９４の処理の前にｒｅｆｅｒｅｒ−世代番号管理テーブル４０１を、受信した処理要求に記載されていたＲｅｆｅｒｅｒヘッダの値とＩＦ名称とを用いて検索し、検索結果として得られたレコードのカラム４０４の値をアプリケーションロジック４６の世代番号として処理を続ける。

この様に、アプリケーションサーバ１１が、Ｗｅｂブラウザ１４等がデフォルトで付与するヘッダ情報を利用してアプリケーションロジック４６の世代番号を管理することによって、アプリケーションサーバ１１以外のサーバが生成したＨＴＭＬからの処理要求についてアプリケーションロジック４６の世代振り分けを実行することが可能となる。

次に、ＳＩＰのＵｓｅｒ−Ａｇｅｎｔヘッダを利用した世代振り分け方法について、図７と図３１とを用いて説明する。

一般的なＳＩＰメッセージには、図７に示す記載７６の様なＵｓｅｒ−Ａｇｅｎｔヘッダが付与される。このＵｓｅｒ−Ａｇｅｎｔヘッダは、ＩＰ電話等のＳＩＰ端末がＳＩＰメッセージを送信する時に付与されるヘッダであり、自身の端末の種類、及び端末のバージョン番号をＳＩＰサーバに通知する為に用いる。本発明のフレームワーク部３２においてはＵｓｅｒ−Ａｇｅｎｔ−世代番号管理テーブル４１１と、このＵｓｅｒ−Ａｇｅｎｔヘッダとの値を利用してアプリケーションロジック４６の世代振り分けを可能にする。

図３１は、本発明の第１の実施形態のＵｓｅｒ−Ａｇｅｎｔ−世代番号管理テーブル４１１を示す説明図である。

Ｕｓｅｒ−Ａｇｅｎｔ−世代番号管理テーブル４１１において、カラム４１２の値が、ＩＦ名称を示す。カラム４１３の値が、ユーザから受信する処理要求に含まれるＵｓｅｒ−Ａｇｅｎｔヘッダの値を示す。カラム４１４の値が、アプリケーションロジック４６の世代番号を示す。Ｕｓｅｒ−Ａｇｅｎｔ−世代番号管理テーブル４１１は、データベース２８に格納される。

ＳＩＰメッセージを受信した場合の、アプリケーションロジック４６を振り分ける方法は、前述のＲｅｆｅｒｅｒヘッダを用いた世代番号の振り分け方法における処理と同じである。アプリケーションサーバ１１は、図１１に示すステップ９４の処理の前にＵｓｅｒ−Ａｇｅｎｔ−世代番号管理テーブル４１１を、受信した処理要求に含まれたＵｓｅｒ−Ａｇｅｎｔヘッダの値とＩＦ名称とを用いて検索する。そして、検索結果として得られたレコードのカラム４１４の値を、アプリケーションロジック４６の世代番号とし、以降の処理を続ける。

この様に、情報端末ＳＩＰクライアント１５がデフォルトで付与するヘッダ情報を利用してアプリケーションロジック４６の世代番号を管理することによって、情報端末ＳＩＰクライアントからの処理要求についてアプリケーションロジック４６の世代振り分けを実行することが可能となる。

次に、アプリケーションロジック４６の連携パターンによる世代振り分けの方法について図３２、及び３３を用いて説明する。この方法は、あるアプリケーションロジック４６が他のアプリケーションロジック４６を呼び出す様な、アプリケーションロジック４６間の連携が発生する場合に、用いられる方法である。

図３２は、本発明の第１の実施形態のアプリケーションロジック４６の連携パターンで世代振り分けを行う処理を示すシーケンス図である。

図３２に示すステップ４３１において、ＵｓｅｒＡが用いる情報端末ＳＩＰクライアント１５がアプリケーションサーバ１１に処理要求を送信し、ステップ４３２においてＡＰＰ１のアプリケーションロジック４６が実行されるまでは、図６に示すシーケンス図におけるステップ５９までの処理と同じである。処理が完了して、処理応答を返信するとき（図６に示すステップ６０から）、アプリケーションサーバ１１は、図３２に示すステップ４３３において処理されたＡＰＰ１ロジックの世代番号、及び、ＡＰＰ１ロジックを実行したことを示す情報を含んだ処理応答を、情報端末ＳＩＰクライアント１５に返信する。

次に、ＵｓｅｒＡが用いる情報端末ＳＩＰクライアント１５は、ステップ４３６において、アプリケーションサーバ１１にＡＰＰ２のアプリケーションロジック４６を実行する為の処理要求を送信する。その際に、情報端末ＳＩＰクライアント１５は、ステップ４３４において受信したＡＰＰ１の世代番号情報を付与して処理要求を送信する。

アプリケーションサーバ１１は、ステップ４３７の世代特定処理の部分で、アプリケーションロジック連携世代番号管理テーブル４２１を検索することによって、この処理で実行するＡＰＰ２の世代番号を判定する。

図３３は、本発明の第１の実施形態のアプリケーションロジック連携世代管理テーブル４２１を示す説明図である。

アプリケーションロジック連携世代管理テーブル４２１において、カラム４２２の値は、連携元アプリケーションロジック４６のＩＦ名称を示す。カラム４２３の値は、連携元アプリケーションロジック４６の世代番号を示す。カラム４２４の値は、連携先アプリケーションロジック４６のＩＦ名称を示す。カラム４２５の値は、連携先アプリケーションロジック４６の世代番号を示す。

ステップ４３７の世代特定処理では、アプリケーションサーバ１１は、ステップ４３６において受信した処理要求に含まれる、前に処理されたアプリケーションロジック４６のＩＦ名称と、世代番号と、図１１のステップ９２において取得された、これから処理するアプリケーションロジック４６のＩＦ名称とを用いて、アプリケーションロジック連携世代管理テーブル４２１を検索する。この検索によって取得されたレコードのカラム４２５の値を、これから処理するアプリケーションロジック４６の世代番号として、以降のＡＰＰ２のアプリケーションロジック４６の実行（ステップ４３８）、及び、情報端末ＳＩＰクライアント１５への結果応答（ステップ４３９）を行う。

この様に、連携元のアプリケーションロジック４６は自分の世代番号を付与し、アプリケーションサーバ１１が連携元と先の世代番号との対応関係をアプリケーションロジック連携世代管理テーブル４２１上で管理することによって、連携元のアプリケーションロジック４６は、連携先のアプリケーションロジック４６が現在保持する世代番号を気にせずにアプリケーションロジック４６間の連携を実現することが可能となる。

すなわち、連携元のアプリケーションロジック４６が、呼び出す連携先のアプリケーションロジック４６の世代番号を変更する場合、連携元及び連携先のアプリケーションロジック４６の変更は不要であり、アプリケーションロジック連携世代管理テーブル４２１の設定を変更するのみによって、呼び出し世代番号の変更を実現可能である。

また、図３２に示すシーケンス図においては、ＡＰＰ１の処理が完了した後、ステップ４３４において、ＵｓｅｒＡが用いる情報端末ＳＩＰクライアント１５に処理結果を返信した後、ＵｓｅｒＡが用いる情報端末ＳＩＰクライアント１５が次の処理であるＡＰＰ２に処理要求を送信している。しかし、本シーケンス図のステップ４３４、及び４３６を省略して、アプリケーションサーバ１１内部でアプリケーションロジック４６間の連携を実行してもよい。

この様な場合においても基本的な考え方は同じであり、アプリケーションサーバ１１は、ステップ４３３において付与された世代番号を、アプリケーションサーバ１１内部でアプリケーションロジック４６間の連携を行い、ＡＰＰ２を呼び出す際に付与することによって、ＡＰＰ２の世代番号を取得する。

なお、本実施形態において、世代番号は図２に示す各データベース内の１カラムに格納されたが、アプリケーションロジック４６をキーとして世代番号のデータベースに格納されてもよい。

前述の通り本実施形態によれば、既存のＪａｖａ Ｓｅｒｖｌｅｔの上位部分に、アプリケーションロジック４６を管理する為のフレームワーク部３２を備える。また、フレームワーク部３２において、各アプリケーションロジック４６は、外部ＩＦ、アプリケーション本体情報、入力情報、出力情報、入出力情報において利用されるプログラムバイナリ、及びエラー情報を組み合わせて、所定のデータベースのテーブル上で管理される。

また、Ｊａｖａ Ｓｅｒｖｌｅｔ側には本フレームワーク部３２と既存Ｓｅｒｖｌｅｔの橋渡しを行うアダプタを備え、入出力値、及びアプリケーションロジック４６のエラー出力に対する変換処理を行う。また、アプリケーションロジック４６の世代情報が、上記各情報に付随して管理される。

これらの構成によって、本発明は以下の処理が可能となる。

１．ＩＦ情報とアプリケーションロジック４６情報とを関連付けてデータベース管理することによって、アプリケーションの追加又は削除、アップデートを、ｗｅｂ．ｘｍｌ、ｓｉｐ．ｘｍｌの書き換え無しに、行うことができる。その結果、システムを停止することなく、アプリケーションロジック４６の追加、削除、又は、アップデートが可能となる。

２．アプリケーションロジック４６の入出力情報についても合わせて管理し、フレームワーク部３２部分において変換を実施する為、アプリケーションロジック４６側の引数、戻り値を自由に設定することが可能である。また、入力値が間違った処理要求を受信しても、アプリケーションロジック４６を実行する前に、フレームワーク部３２部分でエラー判定を行うことができる。

３．アプリケーションファイル本体に加え、入出力情報、及びエラー出力情報等をデータベース上で管理することによって、アプリケーションロジック４６のプログラム仕様がＪａｖａ Ｓｅｒｖｌｅｔの規定に縛られなくなり、自由度が高くなる。

４．Ｊａｖａ Ｓｅｒｖｌｅｔ上にフレームワーク部３２を構築する為、Ｊａｖａ Ｓｅｒｖｌｅｔの規定を満足するサーバであれば本体を選ばない。

５．アプリケーションロジック４６情報をデータベース２８上で管理する為、アプリケーション追加、削除、又はアップデートが容易になる。従来のサーブレットでは、アプリケーションサーバ１１に対してＳＳＨ又はＴｅｌｎｅｔでログインし、ｗｅｂ．ｘｍｌ、ｓｉｐ．ｘｍｌを書き換え、さらにアプリケーションファイルを配置する必要があったが、これら操作を全てデータベース接続とＳＱＬクエリ発行で実施可能となる為である。開発環境側でのアプリケーション追加、削除、又は、アップデートツール作成もサーバへのＳＳＨ、Ｔｅｌｎｅｔ接続、又はファイルコピー操作等を実施せず、一般的なＤＢ接続のみによって実行可能となる為、容易になる。

Claims (18)

1. ネットワークを介して少なくとも１以上のクライアントから１以上の処理要求を受信し、前記受信した処理要求をＪａｖａサーブレットを用いて処理するためのアプリケーションを実行する計算機であって、
   前記処理要求は、前記処理の要求先である１以上のアドレスを含み、
   前記計算機は、前記アプリケーションを一意に識別する識別子と、前記アプリケーションを実行するためのバイナリロジックとを対応させたアプリケーション情報、及び、前記識別子と前記各アドレスとを対応させたアダプタ情報を含むデータベースに接続され、
   前記計算機は、
   前記処理要求を受信した場合、前記受信した処理要求に含まれるアドレスに基づいて、前記バイナリロジックを特定し、
   前記特定されたバイナリロジックを実行することによって、前記アプリケーションを実行することを特徴とする計算機。
2. 前記計算機は、
   前記アプリケーションを実行するフレームワークと、前記受信した処理要求を前記フレームワークに送る１以上のフレームワークアダプタとを備え、
   前記各フレームワークアダプタは、
   前記データベースに接続され、
   前記アダプタ情報を検索することによって、前記受信した処理要求に含まれるアドレスに対応する前記識別子を取得し、
   前記フレームワークは、
   前記取得した識別子に基づいて、実行されるアプリケーションのバイナリロジックを前記アプリケーション情報から特定し、
   前記データベースの更新が要求された場合には、前記識別子に対応するアプリケーション情報に従って処理を実行し、当該処理の終了後に前記データベースが更新されることを特徴とする請求項１に記載の計算機。
3. 前記データベースは、前記アプリケーションへの入力形式に変換するための入力値情報と、前記アプリケーションからの出力形式を変換するための出力値情報とを含み、
   前記フレームワークアダプタは、
   前記識別子に基づいて、前記アプリケーションへの入力形式に変換するための情報を前記入力値情報から取得し、
   前記入力値情報から取得した情報を用いて、前記受信した処理要求に含まれる入力値を、前記取得した入力形式に変換し、
   前記取得した識別子に基づいて、前記アプリケーションからの出力形式を変換するための情報を前記出力値情報から取得し、
   前記出力値情報から取得した情報を用いて、前記アプリケーションからの出力を、前記クライアントに送信する形式に変換することを特徴とする請求項２に記載の計算機。
4. 前記データベースは、前記識別子と、前記アプリケーションに入力値を入力するための入力クラス及び前記アプリケーションからの出力値を出力するための出力クラスとを対応させた入出力クラス情報を含み、
   前記フレームワークアダプタは、前記取得した識別子に基づいて、前記入力クラスを前記入出力情報から取得し、
   前記アプリケーションは、前記取得した入力クラスを参照して、前記入力値を受け取ることを特徴とする請求項３に記載の計算機。
5. 前記データベースは、前記識別子と、前記アプリケーションから出力されたエラーの種類と、前記エラーを前記クライアントに応答するための形式とを対応させたエラー情報を含み、
   前記フレームワークアダプタは、
   前記取得した識別子に基づいて、前記エラーを前記クライアントに応答するための形式を、前記エラー情報から取得し、
   前記エラー情報から取得したエラー情報を用いて、前記アプリケーションから出力されたエラーを、前記クライアントに応答するための形式に変換することを特徴とする請求項３に記載の計算機。
6. 前記データベースは、前記アプリケーションを、その変更毎に一意に識別するための世代番号を含み、
   前記フレームワークアダプタは、前記クライアントから送られた処理要求に対する応答に、前記処理要求を処理した前記アプリケーションの前記世代番号を付与し、
   前記フレームワークは、前記クライアントから再度送られた処理要求に前記世代番号が含まれる場合、前記処理要求に含まれる世代番号によって識別されるアプリケーションによって、前記処理要求を処理することを特徴とする請求項３に記載の計算機。
7. ネットワークを介して少なくとも１以上のクライアントから１以上の処理要求を受信し、前記受信した処理要求をＪａｖａサーブレットを用いて処理するためのアプリケーションを実行する計算機を備える計算機システムであって、
   前記処理要求は、前記処理の要求先である１以上のアドレスを含み、
   前記計算機は、前記アプリケーションを一意に識別する識別子と、前記アプリケーションを実行するためのバイナリロジックとを対応させたアプリケーション情報、及び、前記識別子と前記各アドレスとを対応させたアダプタ情報を含むデータベースに接続され、
   前記計算機は、
   前記処理要求を受信した場合、前記受信した処理要求に含まれるアドレスに基づいて、前記バイナリロジックを特定し、
   前記特定されたバイナリロジックを実行することによって、前記アプリケーションを実行することを特徴とする計算機システム。
8. 前記計算機は、
   前記アプリケーションを実行するフレームワークと、前記受信した処理要求を前記フレームワークに送る１以上のフレームワークアダプタとを備え、
   前記各フレームワークアダプタは、
   前記データベースに接続され、
   前記アダプタ情報を検索することによって、前記受信した処理要求に含まれるアドレスに対応する前記識別子を取得し、
   前記フレームワークは、
   前記取得した識別子に基づいて、実行されるアプリケーションのバイナリロジックを前記アプリケーション情報から特定し、
   前記データベースの更新が要求された場合には、前記識別子に対応するアプリケーション情報に従って処理を実行し、当該処理の終了後に前記データベースが更新されることを特徴とする請求項７に記載の計算機システム。
9. 前記データベースは、前記アプリケーションへの入力形式に変換するための入力値情報と、前記アプリケーションからの出力形式を変換するための出力値情報とを含み、
   前記フレームワークアダプタは、
   前記識別子に基づいて、前記アプリケーションへの入力形式に変換するための情報を前記入力値情報から取得し、
   前記入力値情報から取得した情報を用いて、前記受信した処理要求に含まれる入力値を、前記取得した入力形式に変換し、
   前記取得した識別子に基づいて、前記アプリケーションからの出力形式を変換するための情報を前記出力値情報から取得し、
   前記出力値情報から取得した情報を用いて、前記アプリケーションからの出力を、前記クライアントに送信する形式に変換することを特徴とする請求項８に記載の計算機システム。
10. 前記データベースは、前記識別子と、前記アプリケーションに入力値を入力するための入力クラス及び前記アプリケーションからの出力値を出力するための出力クラスとを対応させた入出力クラス情報を含み、
    前記フレームワークアダプタは、前記取得した識別子に基づいて、前記入力クラスを前記入出力情報から取得し、
    前記アプリケーションは、前記取得した入力クラスを参照して、前記入力値を受け取ることを特徴とする請求項９に記載の計算機システム。
11. 前記データベースは、前記識別子と、前記アプリケーションから出力されたエラーの種類と、前記エラーを前記クライアントに応答するための形式とを対応させたエラー情報を含み、
    前記フレームワークアダプタは、
    前記取得した識別子に基づいて、前記エラーを前記クライアントに応答するための形式を、前記エラー情報から取得し、
    前記エラー情報から取得したエラー情報を用いて、前記アプリケーションから出力されたエラーを、前記クライアントに応答するための形式に変換することを特徴とする請求項９に記載の計算機システム。
12. 前記データベースは、前記アプリケーションを、その変更毎に一意に識別するための世代番号を含み、
    前記フレームワークアダプタは、前記クライアントから送られた処理要求に対する応答に、前記処理要求を処理した前記アプリケーションの前記世代番号を付与し、
    前記フレームワークは、前記クライアントから再度送られた処理要求に前記世代番号が含まれる場合、前記処理要求に含まれる世代番号によって識別されるアプリケーションによって、前記処理要求を処理することを特徴とする請求項９に記載の計算機システム。
13. ネットワークを介して少なくとも１以上のクライアントから１以上の処理要求を受信し、前記受信した処理要求をＪａｖａサーブレットを用いて処理するための計算機におけるアプリケーション実行方法であって、
    前記処理要求は、前記処理の要求先である１以上のアドレスを含み、
    前記計算機は、前記アプリケーションを一意に識別する識別子と、前記アプリケーションを実行するためのバイナリロジックとを対応させたアプリケーション情報、及び、前記識別子と前記各アドレスとを対応させたアダプタ情報を含むデータベースに接続され、
    前記方法は、
    前記計算機が、前記処理要求を受信した場合、前記受信した処理要求に含まれるアドレスに基づいて、前記バイナリロジックを特定し、
    前記計算機が、前記特定されたバイナリロジックを実行することによって、前記アプリケーションを実行することを特徴とするアプリケーション実行方法。
14. 前記計算機は、前記アプリケーションを実行するフレームワークと、前記受信した処理要求を前記フレームワークに送る１以上のフレームワークアダプタとを備え、
    前記各フレームワークアダプタは、前記データベースに接続され、
    前記方法は、
    前記各フレームワークアダプタが、前記アダプタ情報を検索することによって、前記受信した処理要求に含まれるアドレスに対応する前記識別子を取得し、
    前記フレームワークが、前記取得した識別子に基づいて、実行されるアプリケーションのバイナリロジックを前記アプリケーション情報から特定し、
    前記フレームワークが、前記データベースの更新が要求された場合には、前記識別子に対応するアプリケーション情報に従って処理を実行し、当該処理の終了後に前記データベースが更新されることを特徴とする請求項１３に記載のアプリケーション実行方法。
15. 前記データベースは、前記アプリケーションへの入力形式に変換するための入力値情報と、前記アプリケーションからの出力形式を変換するための出力値情報とを含み、
    前記方法は、
    前記フレームワークアダプタが、前記識別子に基づいて、前記アプリケーションへの入力形式に変換するための情報を前記入力値情報から取得し、
    前記フレームワークアダプタが、前記入力値情報から取得した情報を用いて、前記受信した処理要求に含まれる入力値を、前記取得した入力形式に変換し、
    前記フレームワークアダプタが、前記取得した識別子に基づいて、前記アプリケーションからの出力形式を変換するための情報を前記出力値情報から取得し、
    前記フレームワークアダプタが、前記出力値情報から取得した情報を用いて、前記アプリケーションからの出力を、前記クライアントに送信する形式に変換することを特徴とする請求項１４に記載のアプリケーション実行方法。
16. 前記データベースは、前記識別子と、前記アプリケーションに入力値を入力するための入力クラス及び前記アプリケーションからの出力値を出力するための出力クラスとを対応させた入出力クラス情報を含み、
    前記方法は、
    前記フレームワークアダプタが、前記取得した識別子に基づいて、前記入力クラスを前記入出力情報から取得し、
    前記アプリケーションが、前記取得した入力クラスを参照して、前記入力値を受け取ることを特徴とする請求項１５に記載のアプリケーション実行方法。
17. 前記データベースは、前記識別子と、前記アプリケーションから出力されたエラーの種類と、前記エラーを前記クライアントに応答するための形式とを対応させたエラー情報を含み、
    前記方法は、
    前記フレームワークアダプタが、前記取得した識別子に基づいて、前記エラーを前記クライアントに応答するための形式を、前記エラー情報から取得し、
    前記フレームワークアダプタが、前記エラー情報から取得したエラー情報を用いて、前記アプリケーションから出力されたエラーを、前記クライアントに応答するための形式に変換することを特徴とする請求項１５に記載のアプリケーション実行方法。
18. 前記データベースは、前記アプリケーションを、その変更毎に一意に識別するための世代番号を含み、
    前記方法は、
    前記フレームワークアダプタが、前記クライアントから送られた処理要求に対する応答に、前記処理要求を処理した前記アプリケーションの前記世代番号を付与し、
    前記フレームワークが、前記クライアントから再度送られた処理要求に前記世代番号が含まれる場合、前記処理要求に含まれる世代番号によって識別されるアプリケーションによって、前記処理要求を処理することを特徴とする請求項１５に記載のアプリケーション実行方法。