JP2018532186A - 分割された構造によるアプリケーションの隔離 - Google Patents

Abstract

機能一体的アプリケーションが提供される。当該アプリケーションはアプリケーションサーバの第１のプログラムアドレス空間に常駐する。当該アプリケーションは、アプリケーションサーバの第２のプログラムアドレス空間に常駐するアプリケーション構成要素に発呼する。アプリケーション構成要素は機能一体的アプリケーションのフレームワーク上に確立される。機能一体的アプリケーションは依存先の第１のライブラリを少なくともロードして、第１のメソッドを呼び出す。アプリケーション構成要素は依存先の第２のライブラリを少なくともロードして、第２のメソッドを呼び出す。第１及び第２のライブラリは同一のライブラリの異なるバージョンであるにもかかわらず、アプリケーションサーバ上に共存し得る。

Description

関連出願の相互参照

本願は、米国特許出願第14/853,695号（2015年9月14日出願）の優先権を主張するものであり、当該出願の開示全体をここに参照のために取り込む。

本開示は概してアプリケーション構造（アーキテクチャ）に関する。より具体的には本開示は、アプリケーションをライブラリから隔離する、分割されたアプリケーション構造を作成するためのシステム及び方法に関する。

業界のエンティティ、企業等によって使用されるアプリケーションはしばしば第三者売主（ベンダ）のフレームワークに依存し又はそれ上に確立される。そのような第三者売主のフレームワークは、この文脈では、（例えばソフトウェア開発者によって使用される）ソフトウェアフレームワークを指してよく、標準アプリケーション構造を実装する。すなわち、一般的な機能がソフトウェア開発者へ提供可能なレベルへと、ソフトウェアは要約されてよい。この一般的な機能は次いで、カスタマイズされ、適合され、また変更されて、業界のエンティティ、企業等のためにアプリケーションを作成するそれらのソフトウェア開発者の要求及び／又は要件に適合する。

特に、ソフトウェアフレームワークは、普遍的な再利用可能なソフトウェア環境として考慮されてよい。これは、より大きいコンピューティング環境の一部（例えばハードウェア、オペレーティングシステム、ランタイムライブラリ等）として特定の機能を提供する。ソフトウェアフレームワークは、アプリケーション、製品及び／又はソフトウェア解決策の発展を支援する。ソフトウェアフレームワークは例えば、支援プログラム、コンパイラ、コードライブラリ、ツールセット及びアプリケーションプログラミングインタフェース（API）を含んでよい。

本開示の一実施形態によれば、方法は、非一時的なコンピュータ可読媒体のアプリケーションサーバの第１のプログラムアドレス空間に常駐する機能一体的アプリケーションによって、前記非一時的なコンピュータ可読媒体の第２のプログラムアドレス空間に常駐するアプリケーション構成要素へ発呼するステップを含む。方法は更に、前記機能一体的アプリケーションによって、依存先の第１のライブラリを少なくともロードして、第１のメソッドを呼び出すステップを含む。方法は更に、前記アプリケーション構成要素によって、依存先の第２のライブラリを少なくともロードして第２のメソッドを呼び出すステップを含む。

本開示の他の実施形態によれば、非一時的コンピュータ可読媒体は、コンピュータ実行可能なプログラムコードを有する非一時的コンピュータ可読媒体であって、前記コンピュータ実行可能なプログラムコードはコンピュータシステムに、
前記非一時的コンピュータ可読媒体の第１のプログラムアドレス空間に常駐する機能一体的アプリケーションを実行するステップであって、前記機能一体的アプリケーションを実行することは、
前記非一時的コンピュータ可読媒体の第２のプログラムアドレス空間に常駐するアプリケーション構成要素へ発呼することと、
前記機能一体的アプリケーショによって、依存先の第１のライブラリを少なくともロードして、第１のメソッドを呼び出すことと、
前記アプリケーション構成要素によって、依存先の第２のライブラリを少なくともロードして第２のメソッドを呼び出すことと、
を含む、実行するステップを実行させるよう構成される。

本開示の一実施形態によれば、アプリケーションサーバは、第１のプログラムアドレス空間と第２のプログラムアドレス空間とを少なくとも含むメモリユニットを含む。アプリケーションサーバは更に、ライブラリの第１のバージョンに依存する売主アプリケーションを含む。アプリケーションサーバは更に前記ライブラリの第２のバージョンに依存するカスタマイズされたアプリケーション構成要素を含み、前記売主アプリケーションは、実行中に、プロセス間通信によって、前記カスタマイズされたアプリケーション構成要素を発呼する。

本開示の態様は、添付の図面と関連して考慮されると、下記の様々な実施形態の詳細な説明を参照することで一層容易に理解される。
例示的な支払カードトランザクション処理システムを示す。 既存のアプリケーション機能を支援する、従来の一体的な構造の例を示す。 売主の改良を適用した後の非機能状態における、図２の従来の一体的な構造の例を示す。 図２の従来の一体的な構造の例を示す。ここでは分割された構造が使用され、本開示の様々な実施形態により、アプリケーション機能を実装する。 アプリケーションを実行する時に実行される例示的な処理を示すフローチャートである。ここでは、本開示による様々な実施形態により、隔離されたライブラリが使用される。 本開示の様々な実施形態の機能を実装するときに使用される例示的なコンピューティング構成要素を示す。

本開示及び下記の例において、図面はより詳細に開示される。図面は徹底的なものではなく、又は、様々な実施形態を、開示される形態そのものに限定しない。実施形態は修正及び変形を伴って実装されてよいことを理解されたい。

本開示の方法及びシステムについてのいくつかの例示的な実施形態の詳細が、下記の記載で規定される。他の機能、オブジェクト、本開示の効果は、下記の記載、図面、例及び請求項を吟味することで自明である。そのような全ての追加システム、方法、機能及び効果が本開示に含まれ、本実施形態の範囲内であり、及び特許請求の範囲によって保護されることが意図される。

上記で示唆されるように、エンティティは第三者売主のフレームワーク上にアプリケーションを確立してよい。そのようなフレームワークを使用することで、それらのアプリケーションはエンティティの要求及び／又は要件へとカスタマイズされてよい。アプリケーションが第三者売主のフレームワーク上に確立可能な業界の一例は、支払トランザクション（取引）処理業界である。カードを基礎とした支払のトランザクション処理は、承認側と清算側とを含んでよい。承認側は、カード保有者が、提示された支払に及び十分な信用供与を有することを確認する処理に関してよい。トランザクションの清算側は、発行者銀行から加盟店販売者銀行へ資金を移転する処理に関してよい。

下記に詳述するように、支払トランザクション処理の状況では、多数及び／又は多くのかたまりのファイル及びデータ（例えば金銭ファイル、報酬ファイル、清算データ等）が、支払ネットワークとその顧客との間で移転（例えば銀行、販売者等へ、またはそこから）されてよい。これらのファイルの移転を有効にするために、エンティティ（例えば支払ネットワーク自体）はウェブアプリケーション、専用フレームワーク／ソフトウェア（例えば安全なトランスポートの、管理ファイル転送ソフトウェア）をカスタマイズしてよい。第三者売主のフレームワークに依存することを考慮すると、第三者売主のフレームワークによって使用される１以上のライブラリ間での任意の非互換性又は不釣り合いとそのフレームワークに対する任意のカスタマイズは、機能／システムの不全に至り得る。

下記で示すように、アプリケーション構造は、第三者売主のフレームワークで使用されるライブラリとエンティティ−アプリケーション開発で使用される特定のライブラリとが分離された状態に維持されるように、提供される。すなわち、様々な実施形態によるアプリケーション構造は、アプリケーションを売主フレームワークから隔離する。これによって、異なるライブラリバージョン（第三者売主／ベンダフレームワークによって使用されるものと、アプリケーションによって使用されるもの）の同時使用が可能である。これによって、アプリケーションとフレームワーク構成要素との間の「衝突」を排除できる。

様々な実施形態が適用可能なネットワーク環境及び状況的（コンテクスチュアルな）環境の例が、開示及び記載される。図１は、例示的な支払カードトランザクション処理システム１００を示す。ここでは分割された構造を有するアプリケーションが、様々な実施形態によって実装されてよい。

典型的なカードを基礎としたトランザクションシステムにおいて、カード保有者１０２は、商品及び／又は役務の購入のために、クレジット／デビット／プリペイドカード１０４を販売者１０６へ提示する。このトランザクションは矢印１０５で示される。本開示の「カード」１０４は、従来の磁気ストライプのクレジット若しくはデビットカード又は類似の近接支払カード（それ自身で使用され又は携帯電話、個人情報端末（PDA）等の他の装置に組み入れられる）を指してよい。これは、近距離無線通信（NFC）機能（例えばその内部に実装される無線周波数識別（RFID）チップ）を有する。「カード」は更に、仮想の又は使用が限定されたアカウント番号及び電子ウォレットを指してよい。

そのようなトランザクションが発生する前に、カード保有者１０２は、発行者銀行１１８によってカード１０４の発行を受ける。更に、販売者１０６は加盟店銀行１１０との関係を確立することを理解されたい。これによって、販売者１０６は、商品及び／又は役務の支払として、支払カードを受け取ることができる。すなわち、販売者銀行及び発行者銀行は、様々な支払ネットワーク（これは支払カードネットワーク１１２を含む）に参加してよい。そのような支払ネットワークの１つは、マスターカードインターナショナルリミテッド（本願の譲受人）によって操作される。

カード保有者１０２が支払カード１０４を販売者１０６へ提示した後、販売者１０６は承認要求（矢印１１９で示される）を、販売時点（POS）端末１０８を介して加盟店銀行１１０へ送信してよい。販売時点端末１０８は販売者１０６に位置し又は販売者１０６によって制御される。その後、加盟店銀行１１０は支払ネットワーク１１２と通信する（矢印１２１によって示される）。支払ネットワーク１１２は発行者銀行１１８と通信し（矢印１２３によって示される）、発行者銀行１１８が、カード保有者１０２が実行しようと試みるトランザクション１０５を承認するか否かを判定する。承認要求の承認又は拒否はその後、販売者１０６へ返信される（矢印１２５、１２７及び１２９で示される）。販売者１０６は次いでトランザクション１０５を、承認要求に対する応答に基づいて、完了又は拒否してよい。

もしトランザクション１０５が承認されれば、トランザクション金額は発行者銀行１１８から支払ネットワーク１１２を通って加盟店銀行１１０へ送信される。所定の手数料が引かれたトランザクション金額は、次いで、販売者１０６に属する銀行アカウント内に預金される。発行者銀行１１８は次いで、周期的にカード保有者明細書を送信することによって、トランザクション金額につきカード保有者１０２へ請求する（矢印１３１で示される）。カード保有者１０２は発行者銀行１１８へ支払を提出する（矢印１３３で示される）。カード保有者１０２によるこの支払の提出（矢印１３３）は、自動化されてよいし（例えばデビットトランザクションの場合）、明細期間中の全ての購入の合計金額に完全に一致する金額につきカード保有者１０２によって開始されてよいし（例えばクレジットカード又はクレジット残高で全額が支払われる）、及び／又は、購入金額とカード保有者１０２及び発行者銀行１１８の間で事前に合意した任意の金銭的請求とを反映する所定期間中に（部分的又は全体的に）提出されてよい（例えばクレジット残高を循環（revolve）する）。

支払ネットワーク１１２は好適には、少なくとも１つのサーバ１１４と少なくとも１つのデータベース１１６とを含む。サーバ１１４は様々なコンピューティング装置（例えばメインフレーム、パーソナルコンピュータ（PC）、ラップトップ、ワークステーション等）を含んでよい。サーバ１１４は処理装置を含んでよく、承認及び清算処理を実装するよう構成される。これは、サーバ１１４に関連付けられたコンピュータストレージに格納されてよい。データベース１１６はコンピュータ可読記憶媒体技術（例えばフロッピードライブ、ハードドライブ、テープドライブ、フラッシュドライブ、光ドライブ、読み取り専用メモリ（ROM）、ランダムアクセスメモリ（RAM）等）を含んでよい。サーバ１１４及びデータベース１１６はソフトウェア／ハードウェアによって制御されてよく、データを格納して、それが本開示の態様に沿って動作することを可能にしてよい。

POS端末１０８は、直接又は間接的に、少なくともときどき、例えば、支払ネットワーク１１２の一部であるアクワイアラのホストコンピュータ（不図示）とデータ通信を行う。POS端末１０８は、加盟店銀行１１０のために又は加盟店銀行１１０に代わって動作される。これは、販売者１０６についての支払カードランザクションを処理する。サーバ１１４は支払ネットワーク１１２によって又は支払ネットワーク１１２に代わって動作されてよく、また、支払カード連盟の会員金融機関の間で中央スイッチング及びメッセージルーティング機能を提供してよい。発行者銀行１１８はまた、好適には、イシュアのホストコンピュータ（不図示）とアクセスポイント（不図示）とを使用する。これを介して、イシュアのホストコンピュータはサーバ１１４とデータメッセージを交換する。実際、支払カードトランザクション処理システム１００は多数のカード保有者、POS端末、アクワイアラのホストコンピュータ、イシュアのホストコンピュータ及びアクセスポイントに関わってよいことを理解されたい。概してアクワイアラのホストコンピュータは承認要求をPOS端末から受信し、当該承認要求を支払ネットワーク１１２を介して転送し、承認応答を受信し、そしてPOS端末１０８へと当該承認応答を中継する。更にイシュアのホストコンピュータは概して、サーバ１１４から承認要求を受信し、当該承認要求に関する承認応答をサーバ１１４へ返信する。

単年中のトランザクションにおいて１０００億ドルが関わることを考慮すると、現金無しのトランザクションの広い範囲で支払カードが使用されることは、現在の経済において偏在的になっている。例えばマスターカードインターナショナルリミテッドは、２３０カ国において１時間に１億６０００万のトランザクションを処理する。支払トランザクションを実行して調整するときに関わる情報及びリソースの量（技術資産）は、支払カードトランザクション処理システム１００の任意の点において莫大であることを理解されたい。

支払ネットワークは、様々な異なるプロトコル及び手順を使用して、様々な種別のトランザクションのために資金移転を処理してよい。支払ネットワークを介して実行されるトランザクションは、商品又は役務の購入と、クレジット購入と、デビットトランザクションと、資金移転と、口座引き落とし等とを含んでよい。支払ネットワークは、現金代替物によってトランザクションを実行するよう構成されてよく、これはギフトカードと、個人用のギフトカードと、支払カードと、信用紹介状と、小切手と、金融アカウント等とを含んでよい。したがって、支払ネットワークは様々なリソース（例えば様々なハードウェア及び／又はソフトウェアプラットフォーム、データベース、内部ネットワーク等）に依存している。

一方の当事者から他方へファイルの連続転送を実行するために、Global File Transfer(GFT)は、適切な接続を利用すると共に、ファイル転送プロトコル（FTP）サービスを提供しない。会員と売主／第三者との間の関係によって連続転送は実行されてよい。当業者によって理解されるように、GFTは、マスターカードインターナショナルインコーポレーテッドから利用可能なシステムである。ここではファイルは図１に示す種類の支払ネットワーク上を転送される。GFTは支払ネットワークを介するデータファイル転送の非限定例である。FTPは、インターネットプロトコルコンピュータネットワーク（例えばインターネット）上でファイルを交換し走査するために使用される標準ネットワークプロトコルである。FTPファイル転送は本発明の他の実施形態で実装可能である。適切なファイル保持及び／又は請求手段は、GFTネットワーク又は他のネットワーク内で設定されてよい。

支払システムを通してファイルを渡す方法は多く存在する。すなわち、仮想プライベートネットワーク（VPN）、又は、データをインターネット上で通信するためのインターネット使用の適切な安全技術（例えばマスターカードインターナショナルインコーポレイテッドのMFE（MASTERCARD FILE EXPRESS）あるいは、周知の安全ファイル転送プロトコル（SFTP）技術若しくは類似の技術）である。当業者に理解されるように、同じことは概して、いわゆるStraight-Through-Processing(STP)技術を指す。これは、電子的な支払が例えば企業のアカウント支払いシステムから銀行インフラストラクチャを通して売主のアカウント受信システムへと途切れなく流れることを可能にする。少なくともいくつかの実施形態では、STP技術はまた、上記のVPNファイル転送に関して実装されてよいことを理解されたい。STP転送セットはElectronic Payments Networkによって開発されたものであり、１以上の実施形態において実装可能な、広く適合された標準形態を示す。当業者はまた、MasterCard File Expressは（オンラインアクセス可能な）アプリケーションの一例であることを理解する。これは、データ転送のための圧縮及び暗号化を行う。

データ暗号化は、売主フレームワーク／製品に基づいてカスタマイズされてよい機能／アプリケーション／サービスである。例えば支払ネットワークは、データ通信につき暗号化プライバシーと認証（上記のもの）とを提供するために、プリティ・グッド・プライバシー（PGP）データ暗号化及び復号化を実装してよい。これは支払ネットワーク１００へ又は支払ネットワーク１００から転送される任意のデータ又はファイルへ、「飛行中」に適用されてよい。

図２は、従来実現されてきた例示的なアプリケーションプログラム（２０２）構造を示す。アプリケーションプログラム２０２はアプリケーションサーバ２００上に常駐する。アプリケーション２０２は１以上の構成要素（例えば売主アプリケーションフレームワーク２０４等）を含む。例示すると、売主アプリケーションフレームワーク２０４は安全転送売主アプリケーションフレームワークであってよい。これは、再び例示すると、フレームワークのバージョン５．０であってよい。上記の通り、売主アプリケーションフレームワーク２０４は、エンティティへ特定の一般的ファイル転送機能を提供する。当該エンティティは、図１の支払カードトランザクション処理システム１００及び／又は支払ネットワーク１１２を制御／操作する。

支払カードトランザクション処理システム１００内で所望される必須の機能を実現するために、カスタム機能が、売主アプリケーションフレームワーク１０４に基づいて確立されてよい。元来提供されたように、売主アプリケーションフレームワーク１０４はそこに、カスタムソフトウェアアプリケーション構成要素Ａ（２０６）を確立してよい。これはライブラリＡ v1.0（２０８）に依存する。カスタムソフトウェアアプリケーション構成要素Ａはファイル転送状況において、カスタムファイル検証構成要素であってよい。これは例えば、支払カードトランザクション処理システム１００内を（例えば販売者１０６、発行者銀行１１８、加盟店銀行１１０及び支払ネットワーク１１２の間を）転送されるファイルの内容、発信元等の検証／承認のために使用される。カスタム構成要素Ｂ（２１０）は、アプリケーションプログラム２０２の他の態様であってよい。一実施形態では、カスタム構成要素Ｂ（２１０）はカスタム暗号構成要素であってよく、これは他のライブラリ（すなわち、ライブラリＢv3.0（２１２））に依存する。これは、支払カードトランザクション処理システム１００内の転送ファイルを暗号化するために使用される。

カスタムソフトウェア構成要素Ａ（２０６）及びＢ（２１０）は、アプリケーションプログラム２０２（これはまた、Javaで書かれてよい）の態様であってよい。Javaはハイレベルのオブジェクト指向の言語であり、プラットフォーム不可知である。すなわち、Javaで書かれたプログラムは、JavaコンパイラによってJavaバイトコードへ翻訳（コンパイル）可能である。Javaプログラムが翻訳されると、それは特定目的マシン、Java仮想マシン（JVM）によって解釈される。これらはプラットフォーム上を駆動する。このため、プログラムはプラットフォーム上で実行されることができる。このとき、プログラムは、例えばプラットフォームの「ネイティブ」マシンのSコード／言語を用いて書かれる必要がない。JavaプログラムがJVM（シミュレーションマシン）によってJavaバイトコードへ翻訳されると、当該バイトコードは次いで駆動し、JVMは自身の言語で、処理作業を１以上のプラットフォームプロセッサへ渡す。JVM及びライブラリは、Javaラインタイム環境（JRE）を一般に指すものを作成する。

上記の通り、Javaはオブジェクト指向の言語である。このことは、コードがオブジェクトのクラスに関連付けられることを意味する。オブジェクトはシミュレーションされたデータ構造である。これはそのクラスの仕様に応じて振る舞う。Javaコードを作成することは、これらのクラスを作成し変更することに関わる。特定のクラスの振る舞いは、「メソッド」と呼ばれるコードの断片によって定義される。オブジェクトとクラスとのプロパティは「変数」によって定義される。

最近のオペレーティングシステム（OS）に関して、再利用可能なコードの大部分は、開発者の仕事を単純にするために提供される。このコードは典型的には、動的にロード可能なライブラリのセットとして提供される。これは、ランタイム（実行時）にてアプリケーションによって呼び出されることができる。Javaプラットフォームは任意の特定のOSに依存しないので、アプリケーションは任意の既存のOSライブラリに依存しない。代わりにJavaプラットフォームは自身の標準クラスライブラリの包括セットを提供する。これは、最近のオペレーティングシステムで一般に見られる同一の利用可能な機能の多くを含む。ほとんどのシステムライブラリはまた、Javaで書かれる。

Javaクラスライブラリは少々の目的に対して役立つ。他の標準コードライブラリのように、Javaライブラリは開発者へ周知の機能のセットを提供し、共通のタスク（例えば項目のリストを維持すること又は複雑な文字列解析を実行すること）を実行する。第２に、クラスライブラリはタスクへ抽象インタフェースを提供する。これは通常、ハードウェアとオペレーティングシステムとに非常に依存する。タスク（例えばネットワークアクセス及びファイルアクセス）はしばしば、各プラットフォームの特有の実装と非常に頻繁に組み合わされる。Javaの機能はそのアプリケーションプログラミングインタフェース（API）に由来する。これは、その開発環境に自動的に含まれる。それは複雑なデータ構造、分類アルゴリズム、ネットワーキングプロトコル、クラス及びメソッドを処理し、グラフィカルユーザインタフェース等を作成する。そのようなライブラリの多くのバージョンが存在してよい。ライブラリの新たなバージョンは、古いバージョンから、クラスを変更、追加又は削除してよい。開発者はプログラムを作成するとき、自身のプログラムがどのライブラリのバージョンに依存するかを選択してよい。

第三者売主によるライブラリ選択における変更は、任意の既に開発されたアプリケーション（例えば既存のライブラリ／ライブラリバージョンに基づいて開発されたアプリケーション（例えば図２に示されたものや上記のもの））に対し即座及び甚大な（有害な）影響を有し得る。例えば技術的なリフレッシュ中に、第三者売主フレームワークは売主によって更新されてよい。売主は、１以上の他のカスタマイズされた態様によって依存される同一のライブラリに依存する新たな機能／特徴を実装してよい。売主が同一ライブラリの異なるバージョンに依存することを選択する場合、非互換性が生じる。例えばカスタム構成要素Ａ（２０６）とカスタム構成要素Ｂ（２１０）との場合において、売主は、ライブラリＡ（２０８）とライブラリＢ（２１２）とに依存する自身の暗号機能をリリースするかもしれない。しかし、売主は、カスタム構成要素Ａとカスタム構成要素Ｂとによって現在使用されるバージョンとは異なる（新しいか古いかのどちらかの）ライブラリＡ（２０８）とライブラリＢ（２１２）とのバージョンを使用することを選択したかもしれない。このことが生じると、ライブラリＡ（２０８）又はライブラリＢ（２１２）のいずれかを（カスタム構成要素Ａ（２０６）又はカスタム構成要素Ｂ（２１０）のそれぞれによって）ロードして発呼（コール）を行う任意の試行につき、売主が選択したライブラリはもはや、カスタム構成要素Ａ（２０６）とカスタム構成要素Ｂ（２１０）とによって依存される必須のメソッド及び／又はクラスを有さないかもしれない。仮にエンティティが、例えば売主によって使用されるライブラリを、ライブラリＡ（２０８）とライブラリＢ（２１０）とに置き換えようとしても、売主実装の暗号機能は、ライブラリＡ（２０８）とライブラリＢ（２１０）とにもはや存在しないメソッド／クラスに依存するかもしれない。

図３は、ライブラリ間での非互換性が生じる例示的な使用例のシナリオを示す。また、アプリケーションプログラム２０２はアプリケーションサーバ２００上に常駐してよいし、１以上の構成要素（例えば売主アプリケーションフレームワーク２０４）を含んでよい。売主アプリケーションフレームワークは例えば安全転送売主アプリケーションフレームワークであってよい。売主アプリケーションフレームワーク２０４の有効バージョンはバージョン5.0であってよい。上記の通り、売主アプリケーションフレームワーク２０４は、エンティティへ特定の一般的ファイル転送機能を提供する。当該エンティティは、図１の支払カードトランザクション処理システム１００及び／又は支払ネットワーク１１２を制御／操作する。当該エンティティは売主アプリケーションフレームワーク２０４をカスタマイズして、支払カードトランザクション処理システム１００のエンティティ（例えば販売者１０６、加盟店銀行１１０、発行者銀行、支払ネットワーク１１２）間でのファイル／データの転送のために、GFTサービスを作成してよい。

売主アプリケーションフレームワーク２０４はそこに、カスタムソフトウェアアプリケーション構成要素Ａ（２０６）を確立してよい。これはライブラリＡ v1.0（２０８）に依存する。カスタムソフトウェアアプリケーション構成要素Ａはファイル転送状況において、カスタムファイル検証構成要素であってよい。これは例えば、支払カードトランザクション処理システム１００内を（例えば販売者１０６、発行者銀行１１８、加盟店銀行１１０及び支払ネットワーク１１２の間を）転送されるファイルの内容、発信元等の検証／承認のために使用される。カスタム構成要素Ｂ（２１０）は、アプリケーションプログラム２０２の他の態様であってよい。一実施形態では、カスタム構成要素Ｂ（２１０）はカスタム暗号構成要素であってよく、これは他のライブラリ（すなわち、ライブラリＢv3.0（２１２））に依存する。これは、支払カードトランザクション処理システム１００内の転送ファイルを暗号化するために使用される。

例えば技術的なリフレッシュ中（例えば売主アップグレード）に、第三者売主は売主アプリケーションフレームワーク２０４の新たなバージョンを開発してよい。これは、売主アプリケーションフレームワークv6.0（３０４）となる。ライブラリ依存関係は、売主アプリケーションフレームワーク３０４の新たなバージョンによって変更されてよい。例えば売主アプリケーションフレームワーク３０４は以前のライブラリＡv1.0への依存関係を、ライブラリＡv2.0へ変更してよい。したがって、以前にカスタム構成要素Ａ（２０６）によって依存されていたライブラリＡv1.0（２０８）は、カスタム構成要素Ａ（２０６）によって予期されるように、もはや存在しない。すなわち、もしカスタム構成要素Ａ（２０６）がライブラリＡをロードして特定の発呼を行うとき、ライブラリＡv2.0（３０８）はもはや、カスタム構成要素Ａ（２０６）が依存する必須のメソッド／クラスを有さない（しかし、以前は、ライブラリＡv1.0を発呼可能であった）。JRE内のクラスロード器は任意の一時点でライブラリの単一バージョンをロードするだけである（すなわち、それはライブラリの異なるバージョンを区別できない）ことを理解されたい。すなわち、ライブラリＡv1.0（２０８）及びライブラリＡv2.0には互換性が無い。

他の例として、売主アプリケーションフレームワークv6.0（３０４）の開発において、第三者売主は新たな又は追加の特徴／機能を実装してよい。この新たな特徴／機能を支援するために、第三者売主はライブラリＢv2.0への新たな依存関係を作成してよい。しかし、売主アプリケーションフレームワークv5.0において、カスタム構成要素Ｂ（２１０）はライブラリＢの最新バージョン（すなわち、ライブラリＢv3.0（２１２））に依存している。ライブラリＢv2.0（３１２）への新たな依存関係によって、カスタム構成要素Ｂ（２１０）によって要求されるメソッド／クラスは、以前のバージョン（すなわち、ライブラリＢv2.0（３１２））によって支援されない。更に、カスタム構成要素Ｂ（２１０）が有効でないだけでなく、売主アプリケーションフレームワークv6.0（３０４）に基づくアプリケーションプログラム２０２は、ライブラリＢv3.0（２１２）を用いて駆動しない。

上記シナリオの影響は、アプリケーションプログラム２０２が危険にさらされることである。救済のためのいくつかの形態がなければ、売主アプリケーションフレームワーク及び稼働中のシステムは、支援を受けられない。更にパッチ外に落ちてしまえば、プログラムは業界標準に違反して駆動することになる。例えばパッチにつき最新に維持できなければ、アプリケーションプログラム２０２はPayment Card Industry Data Security Standard(PCI DSS)に違反する。

ライブラリに互換性が無いという上記問題に対処するために、本開示の様々な実施形態は、別々のランタイム環境（例えばJRE）において衝突する構成要素を隔離するメカニズムを提供する。これにより、衝突する予定の構成要素は、従来の一体的な構造で衝突していたであろうライブラリの異なるバージョンを使用することができる。すなわち、アプリケーションの構成要素（例えばカスタム構成要素）は退けられ、プログラムアドレス空間を分離してよい。これによって、分割された一体的な構造となり、プロセス間通信を介して発呼される。この機能を実現するために、APは、Java Remote Method Invocation(RMI)インタフェースを用いて構成要素間で露出する。Java RMIは、オブジェクト指向の、遠隔手続き呼出しの同等物を実行するAPIであり、連続するJavaクラスの直接転送と、分散した不要データの収集とについての支援を有する。

アプリケーション／アプリケーション構成要素を別の処理空間に移動することによって、そのアプリケーション／アプリケーション構成要素は自由に、ライブラリ内の第三者売主の選択物にかかわらず、任意のライブラリの任意のバージョンに依存する。プログラムアドレス空間は、メモリ空間を指してよい。ここでは、例えばスレッドが駆動し、スレッドはプログラム内の制御フローとして考慮されてよい。したがって、新たなライブラリ及び／又はライブラリの異なるバージョンを追加することは、別のプログラムアドレス空間で駆動するアプリケーション／アプリケーション構成要素へ何らの影響も及ぼさない。更に、アプリケーション内のライブラリ変更に関連するテストは、売主フレームワークに対する潜在的影響を取り除き得る。

図４は一体的な構造の例を示す。ここでは分割された構造が使用され、本開示の様々な実施形態により、アプリケーション機能を実装する。図２及び図３に示される上記の例を維持すると、売主アプリケーションフレームワークv5.0（２０４）は例えば安全転送売主アプリケーションフレームワークであってよい。上記の通り、売主アプリケーションフレームワーク２０４は、エンティティへ特定の一般的ファイル転送機能を提供する。当該エンティティは、図１の支払カードトランザクション処理システム１００及び／又は支払ネットワーク１１２を制御／操作する。当該エンティティは売主アプリケーションフレームワークv5.0（２０４）をカスタマイズして、支払カードトランザクション処理システム１００のエンティティ（例えば販売者１０６、加盟店銀行１１０、発行者銀行、支払ネットワーク１１２）間でのファイル／データの転送のために、GFTサービスを作成してよい。

しかし、図２及び３で示される例とは異なり、アプリケーションサーバ２００は別のプログラムアドレス空間へ分割されてよい。すなわち、売主アプリケーションフレームワークv5.0（２０４）は、第１のプログラムアドレス空間４００内に常駐してよい。ここでは第１のJREが保持される。

売主アプリケーションフレームワークv5.0（２０４）はそこに、カスタムソフトウェアアプリケーション構成要素Ａ（２０６）を確立してよい。これはライブラリＡ v1.0（２０８）に依存する。カスタムソフトウェアアプリケーション構成要素Ａはファイル転送状況において、カスタムファイル検証構成要素であってよい。これは例えば、支払カードトランザクション処理システム１００内を（例えば販売者１０６、発行者銀行１１８、加盟店銀行１１０及び支払ネットワーク１１２の間を）転送されるファイルの内容、発信元等の検証／承認のために使用される。売主アプリケーションフレームワークv5.0（２０４）のように、カスタム構成要素Ａ（２０６）及びそれが依存するライブラリＡ v1.0（２０６）は、第２のプログラムアドレス空間４２０における第２のJRE内に常駐してよい。

カスタム構成要素Ｂ（２１０）はアプリケーションプログラム２０２の他の態様であってよいし、ライブラリＢv3.0（２１２）に依存するカスタム暗号構成要素であってよく、支払カードトランザクション処理システム１００内の転送ファイルを暗号化するために使用される。売主アプリケーションフレームワークv5.0（２０４）及びカスタム構成要素Ａ（２０６）のように、カスタム構成要素Ｂ（２１０）は第３のプログラムアドレス空間４４０に常駐し、ここでは第３のJREが実装される。

売主アプリケーションフレームワークv5.0（２０４）、カスタム構成要素Ａ（２０６）及びカスタム構成要素Ｂ（２１０）はそれぞれ、別のプログラムアドレス空間４００、４２０及び４４０に常駐するので、ライブラリへの依存関係は区別できる。すなわち、仮に売主が新たな依存関係を導入し又はそれ自身のフレームワークへの依存関係を変更しても、カスタム構成要素Ａ（２０６）及びカスタム構成要素Ｂ（２１０）への影響はない。実際、図４に示されるように、プログラムアドレス空間に常駐することによって、ライブラリＡv2.0（３０８）への依存関係における変更及び／又はライブラリＢv2.0（３１２）への新たな依存関係が生じうるし、及び／又は、カスタム構成要素Ａ（２０６）又はカスタム構成要素Ｂ（２１０）への影響無く作成され得る。１以上のライブラリ間での１以上の非互換性が生じる図２の例とは異なり、カスタム構成要素Ａ（２０６）はライブラリＡv1.0（２０８）への依存を維持してよい。同様に、カスタム構成要素Ｂ（２１０）はライブラリＢv3.0（２１２）への依存を維持してよい。

更に、プロセス間通信は、区別される第１、第２及び第３のJRE間で有効にされる。すなわち、売主アプリケーションフレームワークは、RMI発呼によって、カスタム構成要素Ａ、この例では、カスタムファイル検証構成要素（これは、今度はライブラリＡv1.0（２０８）をロードして必要な発呼を行ってよい）を使用してよい。このとき、互換性の無いライブラリ（ライブラリＡv1.0（２０８）及びライブラリＡv2.0（３０８））を発行することがない。類似の方法で、売主アプリケーションフレームワークは、RMI発呼によって、カスタム構成要素Ｂ（２１０）、この例では、カスタム暗号構成要素（これは、今度はライブラリＢv3.0（２１２）をロードし、発行はない（すなわち、ライブラリＢ2.0（３１２）との非互換性））を使用してよい。自身のプログラムアドレス空間内で各処理を隔離するにもかかわらず、各処理／アプリケーション構成要素は、アプリケーションサーバ２００上で駆動する一体的なアプリケーションとして共に動作／行動可能である。

図５は、本開示の様々な実施形態による、１以上のアプリケーションプ又は分割された構造内のアプリケーション構成要素を実行するために実行されることができる例示的処理を示す。動作５００にて、第１のプログラムアドレス空間に常駐する機能一体的アプリケーションは、第２のプログラムアドレス空間に常駐するアプリケーション構成要素へ発呼を行う。動作５０２にて、アプリケーションは少なくとも、それが依存する第１のライブラリをロードして、第１のメソッドを呼び出す。第１のライブラリは第１のプログラムアドレス空間に常駐する。動作５０４にて、アプリケーション構成要素は少なくとも、それが依存する第２のライブラリをロードして、第２のメソッドを呼び出す。第２のライブラリは第２のプログラムアドレス空間に常駐する。

１以上のアプリケーション構成要素をカプセル化して自身のJVM下で（例えばアプリケーションサーバ上の）アプリケーションサービスを設定することによって、APは（RMI発呼を用いてアプリケーション構成要素にアクセスして）、アプリケーション構成要素を発呼するために使用される同一の露出したメソッドと共に駆動する。すなわち、売主アプリケーションフレームワーク内から１以上のアプリケーション構成要素へのRMI発呼が実行される。アプリケーション構成要素は（同一のJREによって制限されるとき）、従来実行されたのとほぼ同一の方法で呼び出されてよい。このように、任意のカスタム機能はスタンドアロンのRMIライブラリへ確立されてよい。売主アプリケーションフレームワークは売主アプリケーションフレームワークから発呼を行ってよい。各カスタム機能（アプリケーション構成要素）は、それが希望する依存先として、ライブラリの任意のバージョンに依存可能である（互換性の観点からは、互いに完全に独立する）。自身のプログラムアドレス空間にて各プロセスを確立しつつも、プロセス間でのプロセス間通信を可能にして１つの結合システム（各構成要素は、自身のそれぞれのプログラムアドレス空間内に常駐する自身のライブラリを有する特定のサービスに責任を有する）を形成することは、ライブラリのバージョン間での任意の潜在的な非互換性を排除する。

本開示の様々な実施形態が、支払カードトランザクションのファイル／データ転送の文脈で提示及び記載されるが、分割されたアプリケーション構造を有する一体的なアプリケーションの概念は一般に適用可能であること、また、任意の他の状況で実装するために他の実施形態が考慮されることに留意されたい。これによって、アプリケーションフレームワークに依存するアプリケーションに対する任意の有害な影響を防ぎ又は解決することができる。様々な実施形態はまた、構成要素を隔離してサービスを基礎にした構造を確立するために使用されてよい。例えば様々な実施形態はマルチメディアのタスクの状況に適用されてよい。ここでは、異なるプログラムが、インストールされたオペレーティングシステム上で駆動するマルチメディアのタスクを処理するために、APIの集合物の異なるバージョンを要求してよい。更に様々な実施形態はJavaを基礎にしたアプリケーションの文脈で記載されるが、他のプログラミングスキーマ／言語が、他の実施形態に応じて使用されてよい。様々な実施形態は分割された構造を使用することを考慮するので（ここでは、アプリケーション／アプリケーション構成要素が自身のアドレス空間内で実行される）、当該構造の各部分は、API集合物の自身のバージョンに依存してよい。１つの一体的なシステム／エンティティが分割されるが、それは依然として、タスクの異なるバージョンを駆動可能な１つの論理的エンティティとして動作する。

本開示のように、構成要素との用語は、機能についての所定の機能部を示す。これは本願の１以上の実施形態にしたがって実行されてよい。本開示のように、構成要素は任意の形式のハードウェア、ソフトウェア又はそれらの組合せを使用して実装されてよい。例えば１以上のプロセッサ、コントローラ、ASIC、PLA、PAL、CPLD、FPGA、論理構成要素、ソフトウェアルーティン又は他のメカニズムが、構成要素を作成するために実装されてよい。実装時に、本開示の様々な構成要素は、個別の構成要素又は機能として実装されてよい。本開示の特徴は１以上の構成要素間で、部分的に又は全体的に共有されてよい。言い換えれば、本開示を読んだ後の当業者にとって自明なように、本開示の様々な特徴及び機能は、任意の所定のアプリケーションとして実装されてよいし、様々な組み合わせ及び交換における１以上の別々の又は共有された構成要素において実装されてよい。仮に様々な特徴又は機能の要素が個別に記載され又は別々の構成要素として特許請求されても、当業者は、これらの特徴及び機能は１以上の一般のソフトウェア及びハードウェア要素間で共有されてよいことを理解する。そのような記載は、別々のハードウェア又はソフトウェア構成要素がそのような特徴又は機能を実装するために使用されることを要求しないし示唆しない。

アプリケーション構成要素がソフトウェアを用いて全体的に又は部分的に実装されると、一実施形態では、これらのソフトウェア要素は、関連して記載される機能を実行可能なコンピューティング構成要素又は処理構成要素と協働するよう実装されてよい。１つのそのような例示的コンピューティング構成要素は図６に示される。様々な実施形態は、この例示的コンピューティング構成要素６００に関して記載される。本開示を読んだ後、当業者にとって、他のコンピューティング構成要素又は構造を用いてアプリケーションをどのように実装するかは自明である。

図６は、例示的コンピューティング構成要素６００を示す。この例は、本開示で開示されるシステム及び方法の様々な特徴及び／又は機能を実装するために使用されるビジネスエコシステムツールを実行するためのプロセッサであってよい。コンピューティング構成要素６００は、例えば、デスクトップ、ラップトップ、ノートブック及びタブレットコンピュータ、携帯型コンピューティング装置（タブレット、PDA、スマートフォン、携帯電話、パームトップ等）、メインフレーム、スーパーコンピュータ、ワークステーション又はサーバ、所定のアプリケーション又は環境にとって望ましい又は適切な任意の種別の特定目的又は汎用目的コンピューティング装置内で見られる、コンピューティング機能又は処理機能を提示してよい。コンピューティング構成要素６００はまた、所定の装置内で実装される又は所定の装置で利用可能なコンピューティング機能を提示してよい。例えばコンピューティング構成要素は、他の電子装置（例えばデジタルカメラ、案内システム、携帯電話、携帯コンピューティング装置、モデム、ルータ、WAP、端末、及び、処理能力についての何らかの形態を含む他の電子装置）内にあってよい。

コンピューティング構成要素６００は例えば、１以上のプロセッサ、コントローラ、制御構成要素、又は他の処理装置（例えばプロセッサ６０４）を含んでよい。プロセッサ６０４は汎用目的又は特定目的処理エンジン（例えばマイクロプロセッサ、コントローラ、他の制御ロジック）を用いて実装されてよい。開示される例において、プロセッサ６０４はバス６０２に接続される。もっとも任意の通信媒体は、コンピューティング構成要素６００の他の構成要素との相互作用を支援するために、又は、外部と通信することを支援するために使用されてよい。

コンピューティング構成要素６００はまた、１以上のメモリ構成要素を含んでよい。これは、本開示にてメインメモリ６０８を指す。例えば好適には、ランダムアクセスメモリ（RAM）又は他の動的メモリは、情報を、及び、プロセッサ６０４によって実行される命令を格納するために使用されてよい。メインメモリ６０８はまた、プロセッサ６０４によって実行される命令の実行中に一時的な変数又は他の中間情報を格納するために使用されてよい。コンピューティング構成要素６００は同様に、読み取り専用メモリ（「ROM」）又は、プロセッサ６０４のための静的情報及び命令を格納するためにバス６０２に接続された他の静的ストレージ装置を含んでよい。

コンピューティング構成要素６００はまた、１以上の様々な形態の情報ストレージ装置６１０を含んでよい。これは例えばメディアドライブ６１２とストレージユニットインタフェース６２０とを含んでよい。メディアドライブ６１２はドライブ又は他のメカニズムを含んで、固定又は取り外し可能なストレージ媒体６１４を支援してよい。例えばハードディスクドライブ、フロッピーディスクドライブ、磁気テープドライブ、光ディスクドライブ、CD又はDVDドライブ（R又はRW）又は他の取り外し可能な若しくは固定のメディアドライブが提供されてよい。したがって、ストレージ媒体６１４は例えばハードディスク、フロッピーディスク、磁気テープ、カートリッジ、光ディスク、CD又はDVD、又は、メディアドライブ６１２によって読み取られ、書き込まれ若しくはアクセスされる固定の若しくは他の取り外し可能な媒体を含んでよい。これらの例のように、ストレージ媒体６１４は、コンピュータソフトウェア又はデータを格納したコンピュータ使用可能なストレージ媒体を含んでよい。

代替例において、情報ストレージ装置６１０は、コンピュータプログラム又は他の命令若しくはデータがコンピューティング構成要素６００にロードされることを可能にする他の類似の手段を含んでよい。そのような手段は例えば、固定又は取り外し可能なストレージユニット６２２とインタフェース６２０とを含んでよい。そのようなストレージユニット６２２とインタフェース６２０との例は、プログラムカートリッジ又はカートリッジインタフェースと、取り外し可能なメモリ（例えばフラッシュメモリ又は他の取り外し可能なメモリ構成要素）と、メモリスロットと、PCMCIAスロット及びカードと、他の固定又は取り外し可能なストレージユニット６２２とインタフェース６２０とを含んでよい。これらは、ソフトウェア及びデータが、ストレージユニット６２２からコンピューティング構成要素６００へ転送されることを可能にする。

コンピュータシステム６００はまた、通信インタフェース６２４を含んでよい。通信インタフェース６２４は、ソフトウェア及びデータが、コンピュータシステム６００と外部装置との間で転送されることを可能にしてよい。通信インタフェース６２４の例は、モデム、ソフトモデム、ネットワークインタフェース（例えばイーサネット、ネットワークインタフェース、WiMedia、IEEE802.XX又は他のインタフェース）、通信ポート（例えばUSBポート、IRポート、RS232ポートBluetooth（登録商標）インタフェース、又は他の通信インタフェース）を含んでよい。通信インタフェース６２４を介して転送されるソフトウェア及びデータは、典型的には信号上で伝送される。これは電子的、電磁気的（これは光を含む）、又は、所定の通信インタフェース６２４によって交換されることができる他の信号であってよい。これらの信号はチャネル６２８を介して通信インタフェース６２４へ提供されてよい。このチャネル６２８は信号を伝送してよいし、有線又は無線の通信媒体を用いて実装されてよい。チャネルのいくつかの例は、電話線、携帯リンク、RFリンク、光リンク、ネットワークインタフェース、ローカル又はワイドエリアネットワーク、及び他の有線又は無線の通信チャネルを含んでよい。

本書において、「コンピュータプログラム媒体」及び「コンピュータ使用可能な媒体」との用語は概して、一時的又は非一時的な媒体（例えばメモリ６０８、ストレージユニット６２０、媒体６１４及びチャネル６２８）を指すために使用される。これらの及び他の様々な携帯のコンピュータプログラム媒体又はコンピュータ使用可能な媒体は、１以上の命令の１以上の一続き（シーケンス）を実行のための処理装置へ伝送することに関わってよい。媒体上に実装されたそのような命令は概して、「コンピュータプログラムコード」又は「コンピュータプログラム製品」（これはコンピュータプログラム又は他の群の形態で集められてよい）。実行されると、そのような命令はコンピューティング構成要素６００に、本開示のように本願の特徴又は機能を実行させてよい。

様々な実施形態は、特定の例示的な特徴に関して記載される。しかし、請求項に記載されるように、より広い趣旨及び範囲から逸脱することなく様々な修正又は変形がなされてよいことは自明である。したがって、明細書及び図面は、限定的な意味ではなく例示的な意味として考慮される。

様々な例示的な実施形態及び実装が上記されるが、１以上の個別の実施形態で記載される様々な特徴、態様及び機能は、その適用性につき特定の実施形態へ限定されないことと、本願の１以上の他の実施形態に対し単独で又は様々に組合せて適用可能であることとを理解されたい。このことは、そのような実施形態が記載されるか否かと、そのような特徴が本開示の一部として提示されるか否かとにかかわらない。したがって、本願の広がり及び範囲は、上記の例示的な実施形態のいずれにも限定されない。

本願で使用される用語及び句、そしてそれらの変形は、明示されない限り、制限的としてではなく、非制限的（オープンエンド）として解釈されたい。「含む」との用語は、「含み、限定されない」との意味等として読まれたい。「例」との用語は、議論される項目の例を提供するために使用されるものであり、徹底的又は限定的なものではない。「１（一）」との用語は、「少なくとも１つ」、「１以上の」等の意味として読まれたい。「従来の」、「伝統的な」、「通常の」、「標準的な」、「周知（既知）の」及び類似の意味を有する形容詞は、その記載された項目を所定の時期に限定しないし、所定の時期に利用可能な項目に限定しないが、代わりに、現在又は将来の任意の時点で利用可能な又は既知である、従来の、伝統的な、通常の、又は標準的な技術を包含するものとして読まれたい。同様に、本書は、当業者にとって自明又は既知の技術を指す。そのような技術は現在又は将来の任意の時点で当業者にとって自明又は既知の技術を包含する。

いくつかの実施形態にて意味を拡張する単語又は句（例えば「１以上の」、「少なくとも１つの」、「限定されない」又は類似の句）は、そのような拡張句が存在しないときに、より範囲が狭い場合が意図され要求されることを意味しない。「構成要素」との使用は、構成要素の一部として記載され又は特許請求される構成要素又は機能全てが共通のパッケージ（括り）で構成されることを示唆しない。実際、任意の又は全ての様々な構成要素の構成要素は、制御ロジックと他の構成要素とのどちらであろうが、単一のパッケージで組み合わされ又は別々に維持されることが可能であり、更に、複数の群又はパッケージで配布され又は複数の位置に亘って配布されることが可能である。

更に、本開示の様々な実施形態は、例示的なブロック図、フローチャート及び他の指示に関して記載される。本書を読んだ当業者にとって自明なように、例示される実施形態及びその様々な変形例は、例示された実施形態への限定無く実装可能である。例えばブロック図及びそれらに付随する記載は、特定の構造又は構成を指定するものとして解釈されてはならない。

Claims (20)

1. 非一時的なコンピュータ可読媒体のアプリケーションサーバの第１のプログラムアドレス空間に常駐する機能一体的アプリケーションによって、前記非一時的なコンピュータ可読媒体の第２のプログラムアドレス空間に常駐するアプリケーション構成要素へ発呼するステップと、
   前記機能一体的アプリケーションによって、依存先の第１のライブラリを少なくともロードして、第１のメソッドを呼び出すステップと、
   前記アプリケーション構成要素によって、依存先の第２のライブラリを少なくともロードして第２のメソッドを呼び出すステップと、
   を含む方法。
2. 請求項１に記載の方法において、前記第１のアドレス空間内に第１のランタイム環境を実装するステップを更に含む方法。
3. 請求項２に記載の方法において、前記第２のアドレス空間内に第２のランタイム環境を実装するステップを更に含む方法。
4. 請求項１に記載の方法において、前記第１のライブラリは、前記第２のライブラリの異なるバージョンである、方法。
5. 請求項４に記載の方法において、前記第１のメソッドと、前記第１のライブラリによって支援される第１のクラスとの少なくとも１つは前記第２のライブラリによって支援されない、方法。
6. 請求項４に記載の方法において、前記第２のメソッドと、前記第２のライブラリによって支援される第２のクラスとの少なくとも１つは前記第１のライブラリによって支援されない、方法。
7. 請求項１に記載の方法において、前記機能一体的アプリケーションはアプリケーションプログラミングインタフェースを含む、方法。
8. 請求項７に記載の方法において、遠隔手続き呼出しによって前記アプリケーション構成要素を発呼するステップを更に含む方法。
9. 請求項８に記載の方法において、前記遠隔手続き呼出しによって前記アプリケーション構成要素を発呼するステップはプロセス間通信を含む、方法。
10. コンピュータ実行可能なプログラムコードを有する非一時的コンピュータ可読媒体であって、前記コンピュータ実行可能なプログラムコードはコンピュータシステムに、
    前記非一時的コンピュータ可読媒体の第１のプログラムアドレス空間に常駐する機能一体的アプリケーションを実行するステップであって、前記機能一体的アプリケーションを実行することは、
    前記非一時的コンピュータ可読媒体の第２のプログラムアドレス空間に常駐するアプリケーション構成要素へ発呼することと、
    前記機能一体的アプリケーショによって、依存先の第１のライブラリを少なくともロードして、第１のメソッドを呼び出すことと、
    前記アプリケーション構成要素によって、依存先の第２のライブラリを少なくともロードして第２のメソッドを呼び出すことと、
    を含む、実行するステップを実行させるよう構成される、非一時的コンピュータ可読媒体。
11. 請求項１０に記載の非一時的コンピュータ可読媒体において、前記コンピュータ実行可能なプログラムコードは更に、前記コンピュータシステムに、前記第１のアドレス空間内で第１のランタイム環境を実装させるよう構成される、非一時的コンピュータ可読媒体。
12. 請求項１１に記載の非一時的コンピュータ可読媒体において、前記コンピュータ実行可能なプログラムコードは更に、前記コンピュータシステムに、前記第２のアドレス空間内で第２のランタイム環境を実装させるよう構成される、非一時的コンピュータ可読媒体。
13. 請求項１０に記載の非一時的コンピュータ可読媒体において、前記第１のライブラリは前記第２のライブラリの異なるバージョンである非一時的コンピュータ可読媒体。
14. 請求項１３に記載の非一時的コンピュータ可読媒体において、前記第１のメソッドと、前記第１のライブラリによって支援される第１のクラスとの少なくとも１つは、前記第２のライブラリによって支援されず、前記第２のメソッドと、前記第２のライブラリによって支援される第２のクラスとの少なくとも１つは前記第１のライブラリによって支援されない、非一時的コンピュータ可読媒体。
15. 請求項１０に記載の非一時的コンピュータ可読媒体において、前記機能一体的アプリケーションはアプリケーションプログラミングインタフェースを含む、非一時的コンピュータ可読媒体。
16. 請求項７に記載の非一時的コンピュータ可読媒体において、前記コンピュータ実行可能なプログラムコードは前記コンピュータシステムに、遠隔手続き呼出しによって前記アプリケーション構成要素を発呼させるよう更に構成される、非一時的コンピュータ可読媒体。
17. アプリケーションサーバにおいて、
    第１のプログラムアドレス空間と第２のプログラムアドレス空間とを少なくとも含むメモリユニットと、
    ライブラリの第１のバージョンに依存する売主アプリケーションと、
    前記ライブラリの第２のバージョンに依存するカスタマイズされたアプリケーション構成要素と、を含み、
    前記売主アプリケーションは、実行中に、プロセス間通信によって、前記カスタマイズされたアプリケーション構成要素を発呼する、アプリケーションサーバ。
18. 請求項１７に記載のアプリケーションサーバにおいて、前記売主アプリケーションは第１のランタイム環境で実行し、前記カスタマイズされたアプリケーション構成要素は第２のランタイム環境で実行し、前記ライブラリの前記第１及び第２のバージョンは前記アプリケーションサーバ内に共存する、アプリケーションサーバ。
19. 請求項１７に記載のアプリケーションサーバにおいて、前記カスタマイズされたアプリケーション構成要素は売主アプリケーションフレームワーク上に確立される、アプリケーションサーバ。
20. 請求項１７に記載のアプリケーションサーバにおいて、前記プロセス間通信は遠隔手続き呼出しによって実現される、アプリケーションサーバ。

Images