CN108027743A - 具有分段架构的隔离应用 - Google Patents

Abstract

提供了操作上的单体应用，其中，应用驻留在应用服务器的第一程序地址空间中。应用调用驻留在应用服务器的第二程序地址空间中的应用组件，应用组件构建在操作上的单体应用的框架上。操作上的单体应用至少加载其所依赖以用于调用第一方法的第一库，并且应用组件至少加载其所依赖以用于调用第二方法第二库。尽管第一库和第二库是相同库的不同版本，但是第一库和第二库可共存于应用服务器上。

Description

具有分段架构的隔离应用

相关申请的交叉引用

本申请要求2015年9月14日提交的序列号为14/853,695的美国申请的优先权和权益，通过引用的方式将其全部内容合并于本文中。

技术领域

本公开总体上涉及应用架构。更特别地，本公开涉及用于创建使应用与库隔离的分段应用架构的系统和方法。

背景技术

行业实体、企业等所使用的应用通常可能依赖于或建立在第三方供应商框架之上。在此上下文中使用的这样的第三方供应商框架可以指例如由软件开发者使用以实现标准应用结构的软件框架。也就是说，软件可以抽象到可以向软件开发者提供通用功能的水平。然后可以添加该通用功能、对该通用功能进行自定义、调适或以其他方式更改以适应为行业实体、企业等创建应用的那些软件开发者的需要和/或需求。

特别地，可以认为软件框架是提供作为更大计算环境(例如，硬件，操作系统，运行时库等)的一部分的某种功能的通用、可重用的软件环境。软件框架可便于应用、产品和/或软件解决方案的开发。例如，软件框架可以包括支持程序、编译器、代码库、工具集和应用编程接口(API)。

发明内容

根据本公开的一个实施例，一种方法包括：通过驻留在非暂时性计算机可读介质的应用服务器的第一程序地址空间中的操作上的单体应用调用驻留在所述非暂时性计算机可读介质的第二程序地址空间中的应用组件。所述方法还包括通过操作上的单体应用至少加载其所依赖以用于调用第一方法的第一库。所述方法还包括通过所述应用组件至少加载其所依赖以用于调用第二方法的第二库。

根据本公开的另一个实施例，一种其上实现有计算机可执行程序代码的非暂时性计算机可读介质，所述计算机可执行程序代码被配置为使计算机系统：执行驻留在所述非暂时性计算机可读介质的第一程序地址空间中的操作上的单体应用。执行操作上的单体应用包括：调用驻留在非暂时性计算机可读介质的第二程序地址空间中的应用组件；通过操作上的单体应用至少加载其所依赖以用于调用第一方法的第一库；以及通过应用组件至少加载其所依赖以用于调用第二方法的第二库。

根据本公开的再另一个实施例，一种应用服务器包括存储器单元，存储器单元至少包括第一程序地址空间和第二程序地址空间。所述应用服务器还包括供应商应用，其中，所述供应商应用依赖于库的第一版本。另外，所述应用服务器还包括自定义应用组件，其中，所述自定义应用组件依赖于所述库的第二版本，并且其中，所述供应商应用在执行期间经由进程间通信调用所述自定义应用组件。

附图说明

当结合附图阅读下面所述的对本公开的各个实施例的详细描述时，本公开的其他方面将更容易理解。

图1示出了示例性的支付卡交易处理系统。

图2示出了支持现有的应用功能的传统的单体架构的示例。

图3显示了在应用供应商升级后处于非功能状态的图2的传统的单体架构的例子。

图4示出图2的单体架构的示例，其中根据本公开的各种实施例利用分段架构来实现应用功能。

图5是示出根据本公开各种实施例的使用隔离的库执行应用时所执行的示例过程的流程图。

图6示出可用于实现本公开的各种实施例的特征的示例性计算组件。

在下面的说明和例子中更详细地描述附图。附图并非旨在穷举或将各种实施例限制为所公开的精确形式。应该理解的是，可以通过修改和变更来实施实施例。

具体实施方式

在下面的描述中阐述了本公开的方法和系统的一些示例性实施例的细节。通过研究以下的说明书、附图、示例和权利要求书，本公开的其他特征、目的和优点将变得明显。打算将所有这些附加系统、方法、特征和优点都包括在本说明书内，包括在本公开的范围内，并且由所附的权利要求保护。

如上所述，实体可以在第三方供应商框架之上构建应用。通过使用这样的框架，可以根据实体的需要和/或需求而对这些应用进行自定义。其中应用可以构建在第三方供应商框架之上的行业的一个例子是支付交易处理行业。基于卡的支付的交易处理可以包括授权侧和清算侧。授权侧可能涉及确认持卡人具有足够的信用额度来支付提出的支付的过程。交易的清算侧可能涉及将资金从发行银行转移到收单商家银行的过程。

在支付交易处理的情况下，可能在支付网络与其客户之间传送大数量和/或批量的文件和数据(例如，货币文件、奖励文件、结算清算数据等)(例如，到和来自银行、商家等)，这将在下面更详细地描述。为了实现这些文件的传输，例如支付网络本身的实体可以自定义Web应用、专用框架/软件(例如，安全传输管理文件传输软件(MFTS))。鉴于对第三方供应商框架的依赖，第三方供应商框架使用的一个或多个库与对框架的任何自定义之间的任何不匹配或不一致都可能导致功能/系统无法操作。

正如下面将要讨论的，提供了一种应用架构，使得在第三方供应商框架中使用的特定库和在实体应用开发中使用的库可以保持分离。也就是说，根据各种实施例的应用架构将应用与供应商框架隔离开来。这使得可以同时使用(第三方供应商/供应商框架所使用的以及应用所使用的)不同的库版本，从而消除了应用和框架组件之间的“冲突”。

将示出和描述各种实施例可适用于其中的网络和上下文环境的示例。图1示出了示例性支付卡交易处理系统100，可以在示例性支付卡交易处理系统100中根据各种实施例来实现具有分段架构的应用。

在典型的基于卡的支付交易系统中，持卡人102向商家106呈递信用卡/借记卡/预付卡104以购买货物和/或服务。该交易由箭头105指示。当在本文中使用时，“卡”104可以指传统的磁条信用卡、借记卡、或具有近场通信(NFC)能力(例如，在其中实现有射频识别(RFID)芯片)的类似的邻近支付设备(单独使用或者并入另一设备，例如移动电话、个人数字助理(PDA)等)。“卡”可以进一步指虚拟或有限使用的账号和电子钱包。

可以理解的是，在发生这样的交易之前，发行银行118向持卡人102发行卡104。此外，应该理解的是，商家106已经与收单银行110建立了关系，从而允许商家106接收支付卡来到对货物和/或服务进行支付。也就是说，商家银行和发行银行可以参加到各种支付网络(包括支付网络112)中。一个这样的支付网络是由本公开的受让人万事达卡国际公司运营的支付网络。

在持卡人102向商家106呈递支付卡104之后，商家106可以通过位于商家106处或以其他方式由商家106控制的销售点(POS)终端108向收单银行110发送授权请求(由箭头119指示)。进而，收单银行110与支付网络112通信(由箭头121指示)，且支付网络112与发行银行118通信(由箭头123指示)以确定发行银行118是否将批准持卡人102试图进行的交易105。此后将对授权请求的批准或不批准传送回商家106(由箭头125,127和129指示)。然后，商家106可以基于对授权请求的响应来完成或取消交易105。

如果交易105被批准，则将通过支付网络112从发行银行118将交易金额发送到收单银行110。交易金额减去一定费用之后将被存放在属于商家106的银行账户内。然后，发行银行118可以通过发送定期的持卡人账单来向持卡人102开出该交易金额的账单(由箭头131指示)。持卡人102接着向发行银行118提交支付(如箭头133指示)。持卡人102提交该支付(如箭头133指示)可以是自动的(例如，在借记交易的情况下)，可以在账单周期(例如，签账卡或信贷余额全额支付)由持卡人102针对与所有购买的总花费匹配的确切金额发起，和/或可以在一段时间内提交(提交部分或全部)，从而提交的支付反映了购买花费加上持卡人102和发行银行118之间事先商定的任何财务费用(例如循环信贷余额)。

支付网络112优选地包括至少一个服务器114和至少一个数据库116。服务器114可以包括各种计算设备，例如大型机、个人计算机(PC)、膝上型计算机、工作站等。服务器114可以包括处理设备并且被配置为实施授权和清算过程，授权和清算过程可以存储在与服务器114相关联的计算机存储装置中。数据库116可以包括计算机可读介质存储技术，例如，软盘驱动器、硬盘驱动器、磁带驱动器、闪存驱动器、光学驱动器、只读存储器(ROM)、随机存取存储器(RAM)和/或其他计算机可读介质存储技术。服务器114和数据库116可以由软件/硬件控制并且可以存储数据以允许其根据本公开的各方面进行操作。

POS终端108直接或间接地并且至少不时地与例如收单方主计算机(未示出)进行数据通信，收单方主计算机是支付网络112的一部分并且为处理商家106的支付卡交易的收单银行110或者代表收单银行110进行操作。服务器114可以通过支付网络112操作或代表支付网络112来操作，并且可以在支付卡协会的成员金融机构之间提供中央交换和消息路由功能。发行银行118还优选地使用发行方主计算机(未示出)和发行方主计算机通过其与服务器114交换数据消息的接入点(未示出)。应该注意，实际上，支付卡交易处理系统100可以包括大量的持卡人、POS终端、收单方主计算机、发行方主计算机和接入点。通常，收单方主计算机可以接收来自POS终端的授权请求、通过支付网络112转发授权请求、接收授权响应并将授权响应中继给POS终端108。此外，发行方主计算机通常可以一般说来接收来自服务器114的授权请求，并将关于该授权请求的授权响应传送回服务器114。

在当前的经济中，使用支付卡进行广泛的无现金交易已经无处不在，一年内交易额达数千亿美元。例如，万事达卡国际公司在230多个国家每小时处理超过1.6亿单交易。应该意识到，在支付卡交易处理系统100中的任何点执行和协调支付交易所涉及的信息和资源(例如，技术资产)的数量是巨大的。

支付网络可以使用各种不同的协议和程序来处理各种类型交易的货币转移。可以通过支付网络执行的交易可以包括产品或服务购买、信用购买、借记交易、资金转账、账户取款等。支付网络可以被配置为通过现金替代物来执行交易，现金替代物可以包括礼品卡、个性化礼品卡、支付卡、信用证、支票、财务账户等。因此，支付网络依赖于各种资源，例如各种硬件和/或软件平台、数据库、内部网络等。

为了将文件从一方直接传输到另一方，全球文件传输(GFT)利用就地连接性，并且不提供文件传输协议(FTP)服务。由于与成员和供应商/第三方的关系，所以可以进行直接传输。正如本领域普通技术人员将会理解的那样，GFT是可从万事达卡国际公司获得的系统，其中文件通过图1所示种类的支付网络传输，并且GET是经由支付网络传输数据文件的非限制性示例。FTP是用于通过互联网协议计算机网络(例如，互联网)交换和操纵文件的标准网络协议。可以在本发明的其他实施例中采用FTP文件传输。可以在GFT网络或其他网络中设置合适的文件保留和/或计费策略。

有许多通过支付系统传递文件的方法；例如：虚拟专用网络(VPN)或互联网-使用通过互联网传送数据的合适的安全技术，举例来说，例如万事达卡国际公司的MFE(万事达卡文件速递(MASTERCARD FILE EXPRESS))的现有方法或公知的安全文件传输协议(SFTP)技术或类似技术。如本领域普通技术人员将理解的，其通常代表所谓的直通式处理(STP)技术，STP技术使得电子支付能够从例如公司的应付账款系统通过银行基础设施无缝流动到供应商的应收帐款系统。请注意，至少在某些情况下，STP技术也可以结合上面讨论的VPN文件传输来使用。STP交易集由电子支付网络开发，并且表示可以在一个或多个实施例中采用的广泛采用的标准化格式。本领域的普通技术人员还将认识到，万事达卡文件速递是处理对数据的压缩和加密以进行传输的应用(可在线访问)的示例。

数据加密是可以基于供应商框架/产品自定义的这样的一种功能/应用/服务。例如，支付网络可以实现完美隐私(PGP)数据加密和解密，以用于提供例如先前描述的加密隐私和数据通信的认证。可以“在飞行中(inflight)”地将其应用于正传输到支付网络100以及从支付网络100传输的任何数据或文件。

图2示出了常规实现的示例性应用程序(202)架构。应用程序202可以驻留在应用服务器200上。应用202可以包括一个或多个组件，例如供应商应用框架204。为了提供示例，供应商应用框架204可以是安全传输供应商应用框架，同样为了提供示例，其可以是框架的版本5.0。如前所述，供应商应用框架204可以向正在控制/操作图1的支付卡交易处理系统100和/或支付网络112的实体提供某些通用文件传输功能。

为了实现支付卡交易处理系统100内所需的必要功能，自定义特征可以基于供应商应用框架204/在供应商应用框架204上被构建。当最初提供时，供应商应用框架204可以在其上构建有自定义软件应用组件A(206)，其依赖于库A版本1.0(208)。自定义软件应用组件A在文件传输的情况下可以是自定义文件验证组件，其可以用于例如验证/认证待在支付卡交易处理系统100内(例如，在商家106、发行银行118、收单银行110中的一个和支付网络112之间)传输的文件的内容、来源等。自定义组件B(210)可以是应用程序202的另一个切面(aspect)。根据一个实施例，自定义组件B(210)可以是依赖于另一个库(即，库B版本3.0(212))的自定义加密组件，其用于对在支付交易处理系统100内的传输文件进行加密。

自定义软件组件A(206)和B(210)可以是应用程序202(其也可以用Java编写)的切面。Java是一种与平台无关的高级别面向对象语言。也就是说，用Java编写的程序可以由Java编译器编译成Java字节码。一旦Java程序编译完成，它就会被在平台上运行的专用机器Java虚拟机(JVM)解译，这样程序就可以在平台上执行，而不需要使用例如平台的“原生”机器码/语言来编写程序。一旦Java程序被JVM(模拟机)解译为Java字节码，字节码就可以运行，并且JVM将处理工作传递给一个或多个使用其自己的语言的平台处理器。JVM和库构成了通常所称的Java运行时环境(JRE)。

如上所述，Java是一种面向对象的语言，这意味着代码与对象类相关联。对象是按照它的类的规范而作出行为的模拟的数据结构-制作Java代码的动作涉及创建和改变这些类。特定的类行为由称为“方法”的代码片段定义，对象和类的属性由“变量”定义。

对于大多数现代操作系统(OS)来说，提供了大量可重用代码以简化开发者的工作。通常将该代码作为可动态加载的库的集来提供，应用可以在运行时调用这些库。由于Java平台不依赖于任何特定的操作系统，所以应用可以不依赖任何预先存在的操作系统库。相反，Java平台提供了其自身标准类库的综合集，其中包含与现代操作系统中常见的可重用函数相同的可重用函数中的许多。大部分系统库也是用Java编写的。

Java类库有几个用途。像其他标准代码库一样，Java库为开发者提供周知的函数集以执行常见任务，例如，维护项目列表或执行复杂的字符串剖析。其次，类库为通常非常依赖硬件和操作系统的任务提供抽象接口。例如网络访问和文件访问之类的任务通常与每个平台的独特实现方式紧密交缠在一起。Java的功能来自其应用编程接口(API)，该接口自动包含在开发者环境中。它可以处理复杂的数据结构、排序算法、网络协议、创建图形用户界面的类和方法等等。这样的库可能有多个版本，并且较新版本的库可能会更改、添加或从旧版本中删除类。开发者在创建程序时可以选择他们希望他们的程序依赖的库的版本。

第三方供应商对库选择的改变可以对任何已经开发的应用(举例来说，例如图2示出的和上文描述的基于现有库/库版本开发的应用)产生直接且重大(有害)的影响。例如，在技术更新期间，第三方供应商框架可以由供应商更新。这可能是供应商实现了新功能/特征，该新功能/特征依赖的库与一个或多个其他自定义切面依赖的库相同。如果供应商选择依赖该相同库的不同版本，则会出现不兼容性。例如，并且对于自定义组件A(206)和自定义组件B(210)来说，可能是供应商发布其依赖于库A(208)和库B(212)的加密能力。但是，供应商可能已经选择使用与自定义组件A和B当前使用的版本不同(较早或较晚)的库A(208)和库B(212)的版本。如果发生这种情况，加载库A(208)或库B(212)(分别由自定义组件A(206)和自定义组件B(210))以进行调用的任何尝试，则供应商选择的库可能不再具有自定义组件A(206)和自定义组件B(210)所依赖的必要方法和/或类。即使实体尝试例如用库A(208)和库B(210)替换供应商使用的库，供应商实现的加密能力也可能依赖于不再存在于库A(208)和库B(210)中的方法/类。

图3示出了其中库之间发生不匹配的示例性用例情形。再次，应用程序202可以驻留在应用服务器200上，并且可以包括一个或多个组件，例如供应商应用框架204。例如，供应商应用框架可以是安全传输供应商应用框架。供应商应用框架204的操作版本可以是版本5.0。如前所述，供应商应用框架204可以向控制/操作图1的支付卡交易处理系统100和/或支付网络112的实体提供某些通用文件传输功能。实体可以自定义供应商框架204以创建用于在支付卡交易处理系统100的实体(例如，商家106、收单银行110、发行银行和支付网络112)之间传输文件/数据的GFT服务。

供应商应用框架204可以在其上构建有的依赖于库A版本1.0(208)的自定义软件应用组件A(206)。自定义软件应用组件A在文件传输的情况下可以是自定义文件验证组件，其可以用于例如验证/认证待在支付卡交易处理系统100内(例如，在商家106、发行银行118、收单银行110中的一个和支付网络112之间)传输的文件的内容、来源等。自定义组件B(210)可以是应用程序202的另一个切面。根据一个实施例，自定义组件B(210)可以是依赖于另一个库(即，库B版本3.0(212))的自定义加密组件，其用于对在支付交易处理系统100内的传输文件进行加密。

在技术更新(例如，供应商升级)期间，第三方供应商可开发供应商应用框架204的新版本，形成供应商应用框架版本6.0(304)。库的依赖关系可能随供应商应用框架304的这个新版本而改变。例如，供应商应用框架304可能将先前对库A版本1.0(208)的依赖改变为对库A版本2.0(308)的依赖。因此，自定义组件A(206)之前依赖的库A版本1.0(208)不再像自定义组件A(206)被期望的那样存在。也就是说，如果自定义组件A(206)要加载库A以进行某些调用，则库A版本2.0(308)可能不再具有自定义组件A(206)依赖的必要方法/类(但以前是能够通过库A版本1.0(208)调用)。应该指出的是，JRE中的类加载器可能在任何一次只加载库的单个版本，即它不能区分不同版本的库。也就是说，库A版本1.0(208)和库A版本2.0(308)不兼容。

作为另一个例子，在开发供应商应用框架版本6.0(304)时，第三方供应商可能已经实现了新的或附加的特征/功能。为了支持该新特征/功能，第三方供应商可能已经创建了对库B版本2.0(312)的新的依赖关系。然而，在供应商应用框架版本5.0(204)中，自定义组件B(210)依赖于库B的更新版本，即库B版本3.0(212)。由于对库B版本2.0(312)的新的依赖关系，早期版本即库B版本2.0(312)可能不支持自定义组件B(210)所需的方法/类。此外，并且不仅自定义组件B(210)不再可操作，而且基于供应商应用框架版本6.0(304)的应用程序202可能将不能使用库B版本3.0(212)进行操作。

上述情况的影响是应用程序202处于危险之中。如果没有某种形式的修复，供应商应用框架和操作系统将从支持中退出。此外，在补丁上落后可能会导致程序违反行业标准。例如，未能使补丁保持最新可能导致应用程序202违反支付卡行业数据安全标准(PCIDSS)。

为了解决与不兼容库有关的上述问题，本公开的各种实施例提供了用于在单独运行时环境(例如，JRE)中隔离冲突组件的机制，从而允许将会冲突的组件使用不同版本的库，而如果不是这样的话这些不同版本的库在传统的单体软件架构中将发生冲突。也就是说，可以将应用的组件(例如，自定义组件)移交到分离的程序地址空间，从而产生分段但仍然单体的架构，并且应用的组件可以经由进程间通信调用。为了实现该功能，使用Java远程方法调用(RMI)接口将API暴露在组件之间。Java RMI是执行远程过程调用(RPC)的面向对象等效的API，其支持直接传输序列化的Java类和分布式垃圾回收。

通过将应用/应用组件移动到分离的进程空间中，该应用/应用组件自由地依赖于任何库的任何版本，而不管第三方供应商在库中的选择如何。程序地址空间可以指例如线程在其中运行存储器空间，并且线程可以被认为是程序内的控制流。因此，添加新的库和/或不同版本的库对在分离的程序地址空间中运行的应用/应用组件没有影响。此外，与应用中库改变相关的测试可以排除对供应商框架的潜在影响。

图4是单体架构的示例，其中根据本公开的各种实施例利用分段架构来实现应用功能。与图2和3所示的先前例子一致，并如上所述，例如，供应商应用框架版本5.0(204)可以是安全传输供应商应用框架。如前所述，供应商应用框架204可以向控制/操作图1的支付卡交易处理系统100和/或支付网络112的实体提供某些通用文件传输功能。实体可以自定义供应商应用框架版本5.0(204)以创建/支持用于在支付卡交易处理系统100的实体(例如，商家106、收单银行110、发行银行和支付网络112)之间传输文件/数据的GFT服务。

但是，与图2和图3所示的例子不同，可以将应用服务器200分段成分离的程序地址空间。也就是说，供应商应用框架版本5.0(204)可以驻留在保持第一JRE的第一程序地址空间400中。

供应商应用框架版本5.0(204)可以在其上构建有依赖于库A版本1.0(208)的自定义软件应用组件A(206)。自定义软件应用组件A在文件传输的情况下可以是自定义文件验证组件，其可以用于例如验证/认证待在支付卡交易处理系统100内(例如，在商家106、发行银行118、收单银行110中的一个和支付网络112之间)传输的文件的内容、来源等。像供应商应用框架版本5.0(204)一样，其依赖的自定义组件A(206)和库A版本1.0(206)可驻留在第二程序地址空间420的第二JRE中。

自定义组件B(210)可以是应用程序202的另一个切面，并且可以是依赖于库B版本3.0(212)的自定义加密组件，其用于对在支付交易处理系统100内的传输文件进行加密。与供应商应用框架版本5.0(204)和自定义组件A(206)一样，自定义组件B(210)可驻留在其中实现第三JRE的第三程序地址空间440中。

因为供应商应用框架版本5.0(204)、自定义组件A(206)和自定义组件B(210)分别驻留在分离的程序地址空间400、420和440中，所以对库的依赖关系保持不同。也就是说，即使供应商要引入新的依赖关系或将依赖关系更改为自己的框架，也不会对自定义组件A(206)或自定义组件B(210)产生影响。事实上，如图4所示，由于驻留在程序地址空间中，所以可以发生和/或可以创建对库A版本2.0(308)的依赖关系和/或对库B版本2.0(312)的新依赖关系的改变，而不影响自定义组件A(206)或自定义组件B(210)。与导致一个或多个库之间的一个或多个不兼容性的图2的例子不同，自定义组件A(206)可以保持其对库A版本1.0(208)的依赖关系。同样，自定义组件B(210)可以保持其对库B版本3.0(212)的依赖关系。

此外，在不同的第一、第二和第三JRE之间实现了进程间通信。也就是说，供应商应用框架可以通过RMI调用使用自定义组件A(206)，在本例子中，自定义组件A(206)是自定义文件验证组件(其又可以加载库A版本1.0(208)以进行必要的调用)，而不存在库(库A版本1.0(208)和库A版本2.0(308))不兼容的问题。以类似的方式，供应商应用框架可以通过RMI调用使用自定义组件B(210)，在本例子中，自定义组件B(210)是自定义加密组件(其又可以加载库B版本3.0(212)而不存在与库B版本2.0(312)(其被供应商应用框架依赖)不兼容的问题。尽管在其自己的程序地址空间中隔离每个进程，但每个进程/应用组件可以作为在应用服务器200上运行的单体应用来一起操作/动作。

图5是示出为了执行根据本公开的各种实施例的分段架构中的一个或多个应用或应用组件而可以执行的示例过程的流程图。在操作500，驻留在第一程序地址空间中的操作上的单体应用调用驻留在第二程序地址空间中的应用组件。在操作502，应用至少加载其依赖的第一库以调用第一方法。第一库驻留在第一程序地址空间中。在操作504，应用组件加载其依赖的第二库以调用第二方法。第二库驻留在第二程序地址空间中。

封装一个或多个应用组件并在其自己的JVM下(例如，在应用服务器上)设置应用服务会产生使用与用于调用应用组件(使用RMI调用来访问应用组件)相同的暴露方法运行的API。也就是说，从供应商应用框架内部，RMI调出到一个或多个应用组件可以被执行，并且可以以与传统方式(当受相同的JRE约束时)几乎相同的方式调用应用组件。通过这种方式，可以将任何自定义功能内建到独立的RMI库中，并且供应商应用框架可以从供应商应用框架进行调用。每个自定义功能(应用组件)都可以依赖于它希望依赖的任何版本的库(从兼容性角度看彼此完全独立)。每个进程驻留(stand up)在其自身的程序地址空间中，但允许进程之间的进程间通信以形成一个衔接系统(每个组件负责特定服务，特定服务具有驻留在它们自己的各自程序地址空间中的其自己的库)，从而避免了库版本之间的任何潜在的不兼容性。

应该注意的是，尽管已经在支付卡交易文件/数据传输的情况下提出并描述了本公开的各种实施例，但是具有分段应用架构的单体应用的概念通常是可普遍适用的，并且可以设想其他实施例在任何其他情况下实施，以防止或解决对依赖于应用框架的应用的任何有害影响。各种实施例也可以用于隔离组件并构建基于服务的架构。例如，各种实施例可以应用于多媒体任务的情况下，其中不同的程序可能需要用于处理在安装的操作系统上运行的多媒体任务的不同版本的API集合。此外，尽管已经在基于Java的应用的情况下描述了各种实施例，但是根据其他实施例可以使用其他编程方案/语言。因为各种实施例考虑使用分段架构，其中应用/应用组件在其自己的地址空间中执行，架构的每段块都可以依赖于其自己版本的API集合。尽管对一个单体系统/实体进行了分段，但其仍然可以作为一个能够运行不同版本任务的逻辑实体来操作。

当在本文中使用时，术语组件可以描述可以根据本申请的一个或多个实施例执行的给定功能单元。当在本文中使用时，可以利用任何形式的硬件、软件或其组合来实现组件。例如，可以实现一个或多个处理器、控制器、ASIC、PLA、PAL、CPLD、FPGA、逻辑组件、软件例程或其他机制来构成组件。在实现中，本文描述的各种组件可以实现为分立组件，或者所描述的功能和特征可以部分地或全部地在一个或多个组件之间共享。换句话说，对于本领域的普通技术人员在阅读本说明之后将显而易见的是，本文中描述的各种特征和功能可以在任何给定的应用中实现，并且可以以各种组合和排列实现在一个或多个分离或共享的组件中。尽管可以将功能的各种特征或元件单独地描述或声明为分离组件，但本领域的普通技术人员将会理解，这些特征和功能可以在一个或多个共用软件和硬件元件之间共享，并且这样的描述不要求或暗示使用分离硬件或软件组件来实现这样的特征或功能。

在应用的组件全部或部分使用软件来实现的情况下，在一个实施例中，可以将这些软件元件实现为与能够执行有关其描述的功能的计算或处理组件一起操作。图6中示出了一个这样的示例性计算组件。根据该示例性计算组件600描述各种实施例。在阅读该描述之后，相关领域的技术人员将明白如何使用其他计算组件或架构来实现应用。

图6示出了示例性计算组件600，其的示例可以是用于执行商业生态系统工具的处理器，所述商业生态系统工具用于实现本公开中所公开的系统和方法的各种特征和/或功能。计算组件600可以表示例如在台式计算机、膝上型计算机、笔记本计算机和平板计算机；手持式计算设备(平板电脑、PDA、智能电话、蜂窝电话、掌上电脑等)；大型机、超级计算机、工作站或服务器；或对于给定应用或环境可能是合意的或适合的任何其他类型的专用或通用计算设备内发现的计算或处理能力。计算组件600也可以表示嵌入在给定设备内或以其他方式对于给定设备可用的计算能力。例如，计算组件可以在其他电子设备(举例来说，例如，数字照相机、导航系统、蜂窝电话、便携式计算设备、调制解调器、路由器、WAP、可以包括某种形式的处理能力的终端和其他电子设备)中发现。

例如，计算组件600可以包括一个或多个处理器、控制器、控制组件或其他处理设备(例如，处理器604)。处理器604可以使用通用或专用处理引擎(举例来说，例如，微处理器、控制器或其他控制逻辑)来实现。在所示出的示例中，处理器604连接到总线602，但是可以使用任何通信介质来促进与计算组件600的其他组件的交互或者进行外部通信。

计算组件600还可以包括一个或多个存储器组件，这里简称为主存储器608。例如，优选地，随机存取存储器(RAM)或其他动态存储器可以用于存储要由处理器604执行的信息和指令。主存储器608还可以用于在执行要由处理器604执行的指令期间存储临时变量或其他中间信息。计算组件600可以同样包括耦接到总线602的只读存储器(“ROM”)或其他静态存储设备以为处理器604存储静态信息和指令。

计算组件600还可以包括一个或多个不同形式的信息存储设备610，例如，其可以包括介质驱动器612和存储单元接口620。介质驱动器612可以包括驱动器或其他机构以支持固定或可移动的存储介质614。例如，可以提供硬盘驱动器、软盘驱动器、磁带驱动器、光盘驱动器、CD或DVD驱动器(R或RW)或其他可移动或固定介质驱动器。因此，存储介质614可以包括例如硬盘、软盘、磁带、盒、光盘、CD或DVD或者由介质驱动器612读取、访问或写入介质驱动器612的其他固定或可移动介质。如这些示例所示，存储介质614可以包括其中存储有计算机软件或数据的计算机可用存储介质。

在替代实施例中，信息存储设备610可以包括用于允许将计算机程序或其他指令或数据加载到计算组件600中的其他类似手段。这样的手段可以包括例如固定或可移动存储单元622和接口620。这样的存储单元622和接口620的示例可以包括程序盒和盒接口、可移动存储器(例如，闪存或其他可移动存储器组件)和存储器插槽、PCMCIA插槽和卡以及允许软件和数据从存储单元622传输到计算组件600的其他固定或可移动存储单元622和接口620。

计算组件600还可以包括通信接口624。通信接口624可以用于允许软件和数据在计算组件600和外部设备之间传输。通信接口624的示例可以包括调制解调器或软调制解调器、网络接口(例如，以太网、网络接口卡、WiMedia、IEEE 802.XX或其他接口)、通信端口(举例来说，例如，USB端口、IR端口、RS232端口、接口或其他端口)或其他通信接口。经由通信接口624传输的软件和数据通常可以承载在信号上，信号可以是电信号、电磁(包括光学)信号或能够由给定的通信接口624交换的其他信号。可以经由信道628将这些信号提供给通信接口624。该信道628可以承载信号并且可以使用有线或无线通信介质来实现。信道的一些示例可以包括电话线、蜂窝链路、RF链路、光链路、网络接口、局域或广域网以及其他有线或无线通信信道。

在本文档中，术语“计算机程序介质”和“计算机可用介质”用于一般地指暂时性或非暂时性介质，举例来说，例如存储器608、存储单元620、介质614和信道628。这些和其他各种形式的计算机程序介质或计算机可用介质可以参与将一个或多个指令的一个或多个序列承载到处理设备以供其执行。通常将实现在介质上的这样的指令称为“计算机程序代码”或“计算机程序产品”(其可以以计算机程序或其他分组的形式分组)。当被执行时，这样的指令可以使计算组件600能够执行本文所讨论的本申请的特征或功能。

已经参照其具体示例性特征描述了各种实施例。然而，显而易见的是，在不背离如所附的权利要求书所阐述的各种实施例的更宽泛的精神和范围的情况下，可以对其作出各种修改和改变。因此，认为说明书和附图是示例性的而不是限制性的。

尽管上文根据各种示例性实施例和实现方式进行了描述，但应该理解的是，不将在一个或多个单独实施例中描述的各种特征、方面和功能不限于用它们进行描述的特定实施例的适用性，而是可以单独地或以各种组合的方式将它们应用于本申请的一个或多个其他实施例，无论是否描述了这些实施例以及是否将这些特征呈现为描述的实施例的一部分。因此，本申请的宽度和范围不应该受到任何上述示例性实施例的限制。

除非另有明确说明，应该将在本申请中使用的术语和短语及其变体解释为开放式的而不是限制性的。作为前述示例：术语“包括”应理解为意指“包括但不限于”等；术语“示例”用于提供讨论中的项目的示例性实例，而不是其穷尽或限制性的列表；术语“一”或“一个”应理解为意指“至少一个”，“一个或多个”等；并且例如“常规”、“传统”、“正常”、“标准”、“已知”和类似含义的术语的形容词不应被解释为将所描述的项目限制为给定时间段或者在给定的时间可获得的项目，而是应该将其理解为涵盖现在或将来任何时候可用或已知的常规、传统、正常或标准技术。同样地，在本文件涉及本领域普通技术人员显而易见或已知的技术的情况下，这样的技术涵盖现在或将来任何时间对技术人员显而易见或已知的那些技术。

在某些情况下，不应将存在的扩充词汇和短语如“一个或多个”，“至少”，“但不限于”或其他类似短语解读为表示在这样的扩充短语可能不存在的情况下意指或要求较窄的情况。术语“组件”的使用并不意味着被描述或要求作为组件的一部分的组件或功能全部被配置在共同的包中。实际上，无论是控制逻辑还是其他组件，任何或所有的各种组件都可以组合在单个包中或可以对其进行单独维护，并且还可以将任何或所有的各种组件分布在多个分组或包中或分布在多个位置。

此外，本文阐述的各种实施例是根据示例性框图、流程图和其他图示来描述的。在阅读本文后，对于本领域的普通技术人员来说显而易见的是，所示出的实施例及其各种替代方案可以在不限制于所示示例的情况下实现。例如，不应将框图及其相应的描述解释为要求特定的架构或配置。

Claims (20)

1.一种方法，所述方法包括：

通过驻留在非暂时性计算机可读介质的应用服务器的第一程序地址空间中的操作上的单体应用调用驻留在所述非暂时性计算机可读介质的第二程序地址空间中的应用组件；

通过所述操作上的单体应用至少加载所述操作上的单体应用所依赖以用于调用第一方法的第一库；以及

通过所述应用组件至少加载所述应用组件所依赖以用于调用第二方法的第二库。

2.根据权利要求1所述的方法，还包括在所述第一地址空间中实现第一运行时环境。

3.根据权利要求2所述的方法，还包括在所述第二地址空间中实现第二运行时环境。

4.根据权利要求1所述的方法，其中，所述第一库是所述第二库的不同版本。

5.根据权利要求4所述的方法，其中，所述第一方法或所述第一库支持的第一类中的至少一个不被所述第二库支持。

6.根据权利要求4所述的方法，其中，所述第二方法或所述第二库支持的第二类中的至少一个不被所述第一库支持。

7.根据权利要求1所述的方法，其中，所述操作上的单体应用包括应用编程接口。

8.根据权利要求7所述的方法，还包括经由远程过程调用来调用所述应用组件。

9.根据权利要求8所述的方法，其中，经由远程过程调用来调用所述应用组件包括进程间通信。

10.一种其上实现有计算机可执行程序代码的非暂时性计算机可读介质，所述计算机可执行程序代码被配置为使计算机系统：

执行驻留在所述非暂时性计算机可读介质的第一程序地址空间中的操作上的单体应用，其中，执行所述操作上的单体应用包括：

调用驻留在所述非暂时性计算机可读介质的第二程序地址空间中的应用组件；

通过所述操作上的单体应用至少加载所述操作上的单体应用所依赖以用于调用第一方法的第一库；以及

通过所述应用组件至少加载所述应用组件所依赖以用于调用第二方法的第二库。

11.根据权利要求10所述的非暂时性计算机可读介质，其中，所述计算机可执行程序代码被配置为进一步使所述计算机系统在所述第一地址空间中实现第一运行时环境。

12.根据权利要求11所述的非暂时性计算机可读介质，其中，所述计算机可执行程序代码被配置为进一步使所述计算机系统在所述第二地址空间中实现第二运行时环境。

13.根据权利要求10所述的非暂时性计算机可读介质，其中，所述第一库是所述第二库的不同版本。

14.根据权利要求13所述的非暂时性计算机可读介质，其中，所述第一方法或所述第一库支持的第一类中的至少一个不被所述第二库支持，并且其中，所述第二方法或所述第二库支持的第二类中的至少一个不被所述第一库支持。

15.根据权利要求10所述的非暂时性计算机可读介质，其中，所述操作上的单体应用包括应用编程接口。

16.根据权利要求7所述的非暂时性计算机可读介质，其中，所述计算机可执行程序代码被配置为进一步使所述计算机系统经由远程过程调用来调用所述应用组件。

17.一种应用服务器，包括：

存储器单元，所述存储器单元至少包括第一程序地址空间和第二程序地址空间；

供应商应用，其中，所述供应商应用依赖于库的第一版本；

自定义应用组件，其中，所述自定义应用组件依赖于所述库的第二版本，并且其中，所述供应商应用在执行期间经由进程间通信调用所述自定义应用组件。

18.根据权利要求17所述的应用服务器，其中，所述供应商应用在第一运行时环境中执行，并且其中，所述自定义应用组件在第二运行时环境中执行，以使得所述库的所述第一版本和第二版本共存于所述应用服务器内。

19.根据权利要求17所述的应用服务器，其中，所述自定义应用组件构建在供应商应用框架上。

20.根据权利要求17所述的应用服务器，其中，经由远程过程调用来实现所述进程间通信。