使用公共消息收发接口集成面向服务的体系结构应用程序

摘要

描述了一种用于在第一客户端应用程序和第二客户端应用程序之间进行通信的方法，客户端应用程序包含不同的消息收发接口。该方法包括输出来自第一客户端应用程序的消息(66，70)，该消息具有第一消息收发接口，使用接口适配器(432)将具有第一消息收发接口的消息转换到公共消息收发接口(CMI)(10)，接口适配器连接应用程序和CMI，使用中间件适配器(434)将公共消息收发接口中的消息转换到第二消息收发接口，并且将具有第二消息收发接口的消息转发到第二客户端应用程序。

说明书

技术领域

本公开一般涉及用于应用程序的消息收发接口，更具体地说，涉及使用公共消息收发接口将应用程序集成到面向服务的体系结构。

背景技术

面向服务的体系结构(SOA)是使松散耦合的服务或应用程序能够经由消息收发技术或协议互相交换数据或通信的体系结构。该体系结构不与具体的技术绑定。可以使用各种标准消息收发接口/协议来实现符合SOA的应用程序，所述标准消息收发接口/协议包括JMS(Java消息服务)、JBI(联合作战空间信息球)、DDS(分布式数据服务)、CORBA(公共对象请求代理体系结构)和网页服务(HTTP、WSDL、SOAP)，在此仅列举一些。有多种商业的、政府的和开源的面向消息中间件(MOM)应用程序可以实现这些接口/协议。这些应用程序的示例包括：JBOSS和ActiveMQ(JMS实现提供商)以及RTI-DDS(DDS实现提供商)。

MOM使应用程序能够经由应用程序编程接口(API)或消息收发接口连接和通信并且经由消息的有效载荷提供/消耗数据或信息，而不用预知服务/应用程序或服务如何执行其任务。然而，当集成来自在其中使用不同API的不同中间件平台的全异的应用程序时，互操作性问题发生。为了提供应用程序或服务的互操作性，在试图连接和集成来自使用不同中间件平台的组织的这些应用程序或服务的同时，共享来自多个不同组织的应用程序或服务的要求变得更明显。

对该问题的一个相当快的解决方案是开发代码以连接不同的MOM实现。然而，这个方案是不可缩放的并且针对一个或两个MOM实现，并且在两个以上MOM要被桥接的应用程序中是不可行的。这种类型的可缩放的解决方案是少见的并且可能需要额外的基础设施。

发明内容

一方面，提供了一种用于在第一客户端应用程序和第二客户端应用程序之间进行通信的方法，其中客户端应用程序包含不同的消息收发接口。该方法包括输出来自所述第一客户端应用程序的消息，该消息具有第一消息收发接口，使用接口适配器将具有第一消息收发接口的消息转换到公共消息收发接口(CMI)，接口适配器连接应用程序与CMI，使用中间件适配器将公共消息收发接口中的消息转换到第二消息收发接口，并且将具有第二消息收发接口的消息转发到第二客户端应用程序。

另一方面，提供了一种使用面向服务体系结构(SOA)与系统中的一个或更多个应用程序进行通信的方法。SOA实现第一中间件平台实现，并且所述应用程序中的至少一个被设计为与不同于第一中间件平台实现的第二中间件平台实现进行交互。该方法包括在SOA环境中执行公共消息收发接口(CMI)层，使得SOA环境中的一个或更多个应用程序中的每一个直接与CMI层相接，在CMI层自动截获来自所述一个或更多个应用程序的第一个的消息收发调用，截获的功能调用基于第二中间件平台实现，第二中间件平台实现与第一中间件平台实现不同，基于应用程序的中间件平台接口从预定义的公共消息接口确定用于截获的调用的等效中间消息协议，基于消息目的地确定中间消息协议的等效目标消息协议，并且通过执行所述确定的等效目标消息协议发送消息，其中目标消息协议在使用所述第一中间件平台实现的SOA环境中是可操作的。

又一方面，提供了一种实现面向服务体系结构(SOA)的系统，所述系统包括第一应用程序、第一中间件平台实现、第二应用程序和公共消息收发接口(CMI)层，所述第一应用程序被设计为与第一中间件平台实现相接，第二应用程序和与第一中间件平台实现关联的接口不兼容。CMI层被配置为截获来自第二应用程序的消息，基于与所述第二应用程序关联的中间件平台接口使用预定义的公共消息接口来确定用于所截获的消息的等效的中间消息协议，基于消息目的地为所述第一应用程序确定用于中间消息协议的等效目标消息协议，以及通过执行与第一中间件平台实现兼容的等效目标消息协议发送消息。

又一方面，提供了一种用于将应用程序集成在面向服务体系结构中的公共消息收发接口系统。公共消息收发接口系统包括接口适配器和中间件适配器，接口适配器被编码为基于与第一应用程序关联的第一中间件平台实现将截获的消息调用转换到预定义的公共消息接口，中间件适配器被编码为将与预定义的公共消息接口关联的消息调用转换到与不同于第一中间件平台实现的中间件平台实现兼容的消息收发接口。

可以在本公开的各种实施例中独立地实现讨论的特征、功能和优势，或可以在其他实施例中组合讨论的特征、功能和优势，所述其他实施例的进一步细节可以参照下述描述和附图看出。

附图说明

图1示出了与公共消息收发接口关联的功能。

图2示出了在给定的数据域或面向服务体系结构(SOA)环境中消息发布/订阅客户端和中间件的正常控制流。

图3示出了在SOA环境内的消息发布/订阅应用程序中公共消息收发接口的结构和控制流。

图4是用于将公共消息收发接口合并到不同的SOA环境的示例应用程序。

图5示出了SOA的各层中公共消息收发接口的结构。

图6是当前用于多中间件环境的普通桥接或转换解决方案的示例。

图7示出了第一客户端应用程序使用面向服务体系结构框架与第二客户端通信，该框架允许单个中间件实现用于两个客户端应用程序。

具体实施方式

所描述的实施例通过提供软件解决方案来解决使用上述面向服务体系结构(SOA)的信息系统的互操作性问题，所述软件解决方案允许具有标准应用程序编程接口(API)的服务插入到任何SOA环境中而无需任何额外的代码。因此，这类实施例被构造为使得集成无缝地、可缩放地适用于额外的消息收发接口和中间件，对于使用不同中间件的客户端应用程序无需额外的代码，并且无需额外的基础设施，例如服务器。换句话说，所描述的实施例在仍然使集成的付出最少的同时，使使用基于不同中间件平台实现的SOA的多个系统能够使用单个中间件平台实现进行互操作。

由以下描述显而易见的是，提供这样的功能，其使客户端应用程序能够与不同中间件平台实现进行通信并且共享来自不同数据域或SOA实现的服务。图1是包括消息收发接口适配器12和中间件适配器14的公共消息收发接口(CMI)10的简化说明。如在此进一步描述的，CMI 10在各种消息收发接口20和中间件平台实现22之间提供接口。

消息收发接口适配器12将消息收发接口或应用程序编程接口(API)调用映射到公共消息收发接口(CMI)10或API调用。CMI 10处理基本消息收发功能，例如发布/订阅或对等连接、建立会话、记录主题、消息投递等。CMI 10包括允许每个接口能够以公共格式表示其消息内容的消息格式。

消息收发中间件适配器14使用目标中间件平台来执行CMI 10的消息收发功能。换句话说，中间件适配器14使用目标中间件平台来用于消息传输。在具体的应用程序中，在消息收发接口和中间件平台之间可能不存在一对一的功能映射，例如，JMS接口和RTI-DDS中间件，如图1中所示。在这种应用程序中，中间件适配器14模拟底层中间件平台实现22不支持的消息收发接口20指定的功能。

图2示出了在给定的数据域中，发布者客户端50和订阅者客户端52以及中间件A实现54之间的消息的正常控制流。发布者客户端50和订阅者客户端52两者都是中间件A实现54的客户端。因此，客户端50和52被配置为分别采用中间件A实现54的运行库/运行时库56和58运行。在下述段落中描述了与在发布者客户端50和订阅者客户端52之间传递的消息有关的事件的正常顺序。

发布者客户端50产生与中间件A运行库56的一个或更多中间件A API连接60。分离地，订阅者客户端52产生到其相应中间件A运行库58的一个或更多中间件A API连接62。当例如使用中间件A运行库56产生‘发布/发送/写入消息’连接64时，中间件A实现54获得从发布者客户端50接收到的消息并且存储该消息。接着，发布者客户端50将一个或更多消息66发布/发送/写入到中间件A实现54。

当产生‘订阅/接收/读取消息’连接68时，中间件A实现54将满足订阅准则(例如主题)的消息投递到订阅者客户端52。接着，中间件A实现54将(一个或多个)消息70分发到订阅者客户端52。

图2所示的实施例是发布者和订阅者客户端两者被实现为使用单个中间件平台实现的情况的代表。图3示出了当其涉及没有被实现为使用单个中间件平台实现的发布者和订阅者客户端时的结构和控制流。更具体地说，图3示出了将图2中的相同发布者客户端50和订阅者客户端52集成的数据域100。如将进一步解释的，由于数据域100使用不同的中间件平台实现(在此称为中间件B实现102)，因此对于此类客户端，集成到数据域100将引起问题。此外，针对数据域100将实施例说明并描述为提供与不同数据域使用的不同中间件实现进行互操作的解决方案。

现在具体地对照图3，除了发布者客户端50和订阅者客户端52之外，在数据域100中包括了发布者客户端110和订阅者客户端112。

类似于图2中所描述的实现，发布者客户端110产生到中间件B运行库116的一个或更多中间件B API连接114。分离地，订阅者客户端112产生到其相应中间件B运行库120的一个或更多中间件B API连接118。例如，当使用中间件B运行库116产生‘发布/发送/写入消息’连接130时，中间件B实现102获得从发布者客户端110接收到的消息并且存储该消息。接着，发布者客户端110将一个或更多消息132发布/发送/写入到中间件B实现102。

当产生‘订阅/接收/读取消息’连接140时，中间件B实现102将满足订阅准则(例如主题)的(一个或多个)消息投递到订阅者客户端112。接着，中间件B实现102将(一个或多个)消息142分发给订阅者客户端112。

发布者客户端50和订阅者客户端52被配置为基于图2中所示的中间件A运行库的使用来与中间件A实现相接。在使用中间件B实现102的数据域100中，合并了允许使用发布者客户端50和订阅者客户端52的实施例，下面进行进一步描述。

为了集成到数据域100，客户端50和52分别与中间件B运行库150和152兼容。然而，客户端50和52使用与中间件B实现102使用的消息接口不同的中间件A实现的消息接口(图2中所示)。

为了解决这些矛盾，数据域100合并接口A适配器运行库160和162以及中间件B适配器运行库164和166。这些运行库160、162、164和166分别地被插入到客户端应用程序(发布者客户端50和订阅者客户端52)和相应的中间件B运行库150和152之间。运行库160、162、164和166有时被统称为桥接解决方案。下面是发布者客户端50和订阅者客户端52使用桥接解决方案进行例如消息发布和订阅的事件的顺序。

更具体地，发布者客户端50产生中间件A API连接180。由接口A适配器运行库160接收该API连接180，接口A适配器运行库160被编码为产生到中间件B适配器运行库164中的对应的公共消息收发接口(CMI)API的连接182。更一般地，该过程被描述为中间件A应用程序编程接口(API)产生到对应的公共消息收发接口(CMI)API的连接182。

从中间件B适配器运行库164，CMI API(例如中间件B适配器运行库164)产生到(一个或多个)对应的中间件B API(例如中间件B运行库150)的(一个或多个)连接184以执行消息收发功能。

现在考虑订阅者客户端52，它也产生中间件A API连接190。由接口A适配器运行库162接收该API连接190，接口A适配器运行库162被编码为产生到中间件B适配器运行库166中的对应的公共消息收发接口(CMI)API的连接192。如上所述，该过程有时被描述为中间件A应用程序编程接口(API)产生到对应的公共消息收发接口(CMI)API的连接192。

从中间件B适配器运行库166，CMI API(例如中间件B适配器运行库166)产生到(一个或多个)对应的中间件B API(例如中间件B运行库152)的(一个或多个)连接194以执行消息收发功能。

对于每个接口A API(或功能)，接口A适配器运行库160和162被编码(或编程)为基于接口A规范和CMI规范调用对应的公共消息收发接口(CMI)API(或功能)(即将指定的消息功能从接口A转换或映射到公共消息接口的过程)。

对于每个公共消息接口(CMI)API(或功能)，中间件B适配器运行库164和166被编码(或编程)为基于CMI规范和与中间件B关联的接口B的规范调用一个或更多个对应的中间件B API(或功能)(即将指定的消息功能从公共消息接口转换或映射到中间件B的过程)。

仍然对照图3，例如，当产生‘发布/发送/写入消息’API连接200时，中间件B 102获得从发布者客户端50产生的消息并且存储该消息。接着，发布者客户端50将消息发布/发送/写入202到中间件B 102。

当产生‘订阅/接收/读取消息’API连接210时，中间件B 102将满足订阅准则(例如主题)的消息通过上述库和适配器投递到订阅者客户端52。针对图3，中间件B 102将消息分发到订阅者客户端52。

虽然图3所示的实施例是稍微一般的，但是图4示出了包含公共消息收发接口的具体实施例。在图4中，例如，连接220和222示出了遗留系统客户端230是基于ActiveMQ中间件232，该ActiveMQ中间件基于JMS接口。对于遗留系统客户端230的实现是基于JMS接口的并且利用ActiveMQ运行库240。类似地，连接250和252示出了高级系统客户端260是基于RTI-DDS中间件实现262的并且可利用RTI-DDS运行库264来操作，所述RTI-DDS中间件实现262是基于DDS接口的。因此，任何一个高级系统客户端260是基于DDS接口的。

与当前公开更相关的是，连接270和272示出了遗留系统客户端230(其在示例中是基于JMS接口的)经由JMS接口适配器运行库280和DDS中间件适配器运行库282与RTI-DDS中间件262进行互操作。适配器运行库280和282使基于JMS接口的遗留系统客户端230能够利用RTI-DDS运行库284来与RTI-DDS中间件262进行互操作。在此重申，连接270和272示出了基于JMS接口的遗留系统230的客户端从JMS接口被桥接到RTI-DDS中间件262。

类似地，连接290和292示出了高级系统客户端260经由DDS接口适配器运行库300和JMS中间件适配器运行库302与ActiveMQ中间件232进行互操作。适配器运行库300和302使基于DDS接口的高级系统客户端260能够利用ActiveMQ运行库304来与ActiveMQ中间件232进行互操作。在此重申，连接290和292示出了基于DDS接口的高级系统的客户端从DDS接口被桥接到ActiveMQ中间件232。

图5示出了利用CMI方案的上述实施例。具体地，参照SOA环境300，CMI方案提供消息收发接口适配器302和消息收发中间件适配器304，它们有时统称为公共消息收发接口。具体地，消息收发接口适配器302将客户端应用程序305的消息收发接口转换到公共消息收发接口(CMI)，消息收发中间件适配器304将CMI接口转换到底层消息收发协议的中间件平台306，提供例如到操作系统310的消息收发接口。

图6是当前使用的用于多中间件环境350的普通桥接或转换方案的另一示例。在环境350中，两个不同的中间件平台实现352和354如消息服务362一样被合并到环境360中。第一中间件平台实现352处理客户端应用程序366的API连接和其他消息收发需求，因为它们使用公共消息收发接口。消息服务362被实现为提供来自第一中间件平台实现352的消息和调用的转换，使得它们与第二中间件平台应用程序354兼容，从而环境360和370可以经由网络380通信或交换消息(或数据)。在该解决方案中，环境360需要将被桥接或转换的中间件平台实现352和354。

在此重申，如在此描述的实施例中发现的，消息服务362被定制编程为仅在第一中间件平台实现352和第二中间件平台实现354之间转换，并且不包含公共消息收发接口。

图7的环境400提供了由环境410和420所示的与环境350(图6中所示)相同的功能，不同之处在于客户端应用程序366能够通过利用CMI层430，在每个环境410和420中仅使用第二中间件平台实现354，经由网络380，与客户端应用程序368进行通信。由于通过将客户端应用程序366的消息转换到公共消息收发接口(CMI)实现的从客户端应用程序366接收到的消息收发转换与中间件平台实现354的消息收发兼容，因此该解决方案是可能的。到CMI的转换发生在接口适配器432内，随后的CMI接口与中间件平台实现354的接口兼容的转换发生在中间件适配器434内。因此，单个中间件平台实现354的分开的实例用于在SOA环境410和420之间路由消息。

总的来说，中间件适配器434使用中间件平台实现上述公共消息收发接口。换句话说，中间件适配器434使用可用的中间件平台354用于传输。在消息收发接口(用于客户端366)和中间件平台实现354之间可能不存在一对一功能映射。中间件平台的示例是ActiveMQ和RTI-DDS。在这种情况下，如图7所示，中间件适配器434模拟中间件平台不支持的消息收发接口指定的功能。

上述实施例在至少两个方面与当前使用的解决方案不同。一方面，上述实施例将消息收发接口而不是具体的客户端应用程序与中间件平台桥接。结果，这类实施例是可缩放的、模块化的，并且在客户端应用程序(消息收发接口)和中间件平台实现之间提供无缝集成。因此，上述实施例是解决各种表面上相冲突的消息收发接口的整体可缩放的解决方案和中间件解决方案。实施例提供基本的消息收发功能，例如发布/订阅、对等连接、建立会话、记录主题、消息投递。

上述实施例不仅仅是转换工具。此外，这些实施例产生一种方法，该方法能够在具有中间件平台的SOA环境中托管(host)应用程序而不需要修改应用程序的软件，该应用程序并不是为该SOA环境的中间件平台而设计的。该解决方案是框架，其将应用程序与来SOA环境的底层中间件实现隔离开并且自动地截获应用程序的原始中间件中的消息收发API，并且确定消息的目的地所需的合适的消息格式和消息收发的协议/顺序。通过配置应用程序的运行库而不是开发新的转换器来在框架内托管应用程序。

虽然根据各种具体的实施例描述了本公开，但是本领域技术人员应认识到，可以在权利要求的精神和范围内实施有修改的本公开。