用于网络中分布处理的编程接口

本发明涉及一个用于网络中分布处理的应用编程接口。更具体地说本发明涉及一个应用程序接口和相关的把面向流的协议转换成面向消息的协议并多路复用一个单独虚电路上的在客户和服务器平台之间的多个逻辑连接的中间件库。

当前使用的主要的通信网络结构利用了分层协议结构来完成网络通信。通常，各层被组成在一个层次结构中。较低的层的功能是在用户或进程之间提供一个连接如一个终端用户或一个数据应用程序。较高的层的功能是在用户或进程间提供准确的数据交换。通常各层使用不同的协议以完成其设计的功能。

图1说明了一个使用一七层体系结构的被称作开放系统互连参考模型(OSI)的通用分层体系结构。所示的体系结构表示一个在数据应用X和Y之间带有一个中间结点的逻辑连接。在端点处信息流过所有七个层而在中间结点处信息通过较低的三层。图1也说明了在对应层间的同层通信。

被称作物理层，数据链路层和网络层的低三层和用户间提供透明连接并主要是在逐段的基础上进行操作以控制在处于结点间的单独数据链路上的通信。被称作应用层，表示层和会话层的上面三层保证信息以适当的格式被传送。中间层，即传送层是一个上面各层和下面各层之间的接口并保证一个在数据应用间的透明的端到端逻辑连接。

图2说明了另一个称作DoD参考模型的分层体系结构的例子。DoD参考模型使用了一个四层体系结构并且是为用于各种不同种类的通过通信处理器接口到一个通信子网的主计算机而开发的。这样的通信处理器包括接口消息处理器(IMP)和通信子网处理器(CSNP)。DoD参考模型的四个层是网络存取层，网间层，主机—主机层和进程/数据应用层。

许多利用上面描述的体系结构的通信网络当前正在全世界使用。这样的网络包括从为独立建筑或校园提供服务的局域网到覆盖全球的广域网的网络。某些这样的网络被专用于特定应用而其它的则主要被用于访问象客户/服务器应用中的资源共享那样的位于远端的功能。在这样的网络中，存在使用比如UNIX，VAX/UMS和DOS/WINDOWS的不同操作系统和比如TCP/IP，DECnet和AP-PC/IU6.2的不同网络协议的混合平台。结果，在这样一个多厂商，多协议的环境中很难在数据应用间进行无缝的分布处理。象终端仿真，网关和批文件传送那样的方法已被用于在各厂商平台间提供互操作性。然而这样的方法无法在同层应用间提供无缝连接且依赖于具体用户。

接口也已被用来改进平台间的互操作性。例如，传送层接口(TLI)或套接字接口已被用于客户/服务器应用。这些接口是使网络应用能够被独立传送的功能集。然而，这样的接口使用了以面向字节的流模式传送数据的网络协议。结果，当与同样的远端数据应用通信时，本地数据应用创建单独的虚电路是必要的。另外，各数据应用需要管理潜在大量的虚电路从而增加了因各数据应用管理网络通信而分配的CPC周期时间。在大规模的客户/服务器应用中，这样的接口没有减少加在客户和服务器平台上的管理许多建立的虚电路的负担。另外，这样的接口通常不是对用户友好的而且需要有经验的网络程序员来实现平台互操作性。

为了在驻留在不同厂商平台上的数据应用之间提供分布应用互操作性并使用具有多种协议的各种分层网络组成部分，已开发出应用编程接口和相应的面向消息的中间件。面向消息的中间件是一个应用编程接口层驻留在数据应用和网络结构之间以在同级应用间提供无缝连接。

面向消息的中间件的一个例子是由Needham，Mass公司的水平策略生成的消息快递接口。消息快递接口驻留在一个标准厂商API和商业(或数据)应用之间并与标准厂商API相互配合解决标准厂商API要向商业应用报告的出错情况。而消息快递接口使用了对各应用需要专门虚电路和一个象传输控制协议(TCP)那样的面向字节流协议的网络拓扑。

另外，在数据应用开发期间，设计者经常需要解决网络错误，同层进程错误或其它非数据应用问题。为纠正这些问题，数据应用程序中充满了系统级服务从而难以开发，测试和维护数据应用。

因而，存在一种需要，即针对驻留在客户平台和服务器平台之间的客户/服务器应用编程接口增强多平台和多协议互操作性并在为驻留在客户平台和服务器平台之间的应用提供透明传输时有效减少客户平台和服务器平台所需的虚电路管理。

本发明提供了一种在客户服务器应用之间传送独立通信内容的应用编程接口。该应用编程接口包括用于在多个与一个服务器应用逻辑连接的客户应用之间建立一个单独的虚电路的装置。客户应用驻留在一个客户平台上而服务器应用驻留在一个远端服务器平台上。该接口也包括对在虚电路上的客户和服务器应用之间的数据通信进行多路复用和多路去复用的装置。常见的基于网络的数据通信采用面向字节流的协议，因此为多路复用的目的，用于多路复用和多路去复用数据通信的装置最好以字节流的形式把数据转换成面向消息的数据包。通过指配给各客户应用的标识码或号来提供客户应用向服务器应用请求数据或信息的标识。该标识码被包含在消息包中。

在一个最佳实施例中，用于建立一个单独虚电路的装置包括一个设置成提供一个基于进程间通信的虚电路的第一接口和一个设置成提供一个基于网间通信的虚电路的第二接口。

本发明也提供一个针对客户服务器应用的通信网络。该通信网络包括一个具有一个服务器应用和驻留其上的一个通信代理的服务器平台和至少一个与该服务器平台逻辑连接的客户平台。这里至少一个的客户平台具有至少一个客户应用和一个驻留其上的通信代理。

各通信代理最好驻留在客户和服务器应用之间以提供应用间的对该应用透明的网络通信。该通信也被提供用来通过在一个单独虚电路上对应用间的数据通信进行多路复用以减少虚电路管理。为完成这些功能，通信代理被设计成包括在至少一个客户应用和服务器应用之间建立单个虚电路的装置，和对在单独虚电路上应用之间的数据通信进行多路复用和多路去复用的装置。

一个旅行者信息服务网络被提供来允许客户(例如顾客)获取个人旅行信息，如点到点旅行路线，或公共旅行信息，如当地交通和天气状况。

旅行者信息网包括至少一个与数据采集平台逻辑相连并被设置在其间传输数据的信息提供器，一个被设置成接收来自数据采集平台的旅行者数据的服务器平台和至少一个与服务器平台逻辑相连的客户平台。服务器平台上驻留有一个服务器应用和通信代理。至少的一个客户平台上驻留有至少一个客户应用和一个通信代理。

本发明也提供了一种在客户应用和服务器应用之间提供数据通信接口的方法。该方法包括下述步骤：在多个客户应用和一个服务器应用之间建立一个单独的虚电路，把来自多个客户应用的字节流数据转换成消息包，并把消息包多路复用至单独的虚电路上以传输到服务器应用。一旦消息包被传输到服务器应用，服务器应用对消息包进行多路去复用并把消息包转换成字节流数据。

下面参照图示描述本发明的最佳实施例，其中：图1说明了当前技术领域中关于一个通信网的分层体系结构；图2说明了在当前技术领域中关于一个通信网的另一种体系结构；图3为一个根据本发明的关于结合通信代理的多平台通信网的模块图；图4说明了客户平台和服务器平台间的一个通信序列；图5为一个建立虚电路的连接表处理的流图；图6为一个关闭虚电路的连接表处理的流图；图7为一个根据本发明的多平台通信网的一个可选实施例的模块图；图8为一个关于说明交通天气客户服务器应用的一个类似于图3的通信网的模块图。

本发明提供了一个应用程序接口(API)，它与一个从基于网络的数据应用中抽象出面向系统的服务以简化基于网络的数据应用开发的中间件库相互配合。

基于网络的数据应用的简化允许系统开发人员减少给市场提供高质量数据应用所必需的开发和测试时间。

图3说明了一个在服务器平台14和不同的客户平台16和18之间使用通信代理12的多平台客户服务器通信体系结构10。通信代理12包括API和一个相应的中间件库。API有两个部件，第一个部件为一个在图3中标识为接口“A”的客户或服务器应用接口的通信代理，而第二个部件为一个在图3中被标识为接口“B”的通信代理接口的通信代理。

接口部件A提供了一个在客户应用20和通信代理12之间的基于进程间通信(IPC)的虚电路。接口A被提供用来从应用中抽象出IPC通信服务并把其存贮在一个可重用中间件库模块(此后称作“IPC模块”)中。IPC模块驻留在通信代理12中。接口部件A的原语包括下述内容：

接口B提供了一个在通信代理12之间基于互连网的虚电路，如一个基于传输控制协议/网间协议(TCP/IP)的虚电路。接口B被提供用来从应用中抽象出网络通信服务并把其存贮在一个可重用中间件库模块(此后称作“网络模块”)中。网络模块12也驻留在通信代理12中。接口部件B的原语包括下述内容：

原语3和8为客户应用以发送请求到服务器应用和服务器应用以发送应答给客户应用的通信写函数。原语4和9为服务器用以从客户应用读取请求和客户应用用以从服务器应用读取应答的通信读函数。在原语(3)和(4)中缓冲区消息包含一个由具体应用协议定义的完整的数据单元。

原语5和10为撤消客户应用和服务器应用间的虚电路的虚电路关闭函数。使用这些API部件，网络传输和进程间通信对于需要这些传输的客户和服务器应用来说是透明的。图4说明了一个通过上述接口A和B，即本发明的API实现客户应用和服务器应用间的透明传输的网络通信模型。

与这些原语相关的中间件被存贮于在各通信代理中的中间件库中。附录A给出了执行期望的与各原语相关的函数的代码。

如上所述，现有技术领域的网络通常使用虚电路协议以面向字节的流模式来传输数据。正如上面提到的，这些协议需要客户应用在与同一个远端服务器应用通信时建立单独的虚电路。这样，对于大规模客户/服务器应用，基于各客户的虚电路管理覆盖了客户和服务器平台资源。

参照图3，本发明的通信代理被设置用来对在一个单独虚电路上多个客户应用20a—20x或20b—20y和服务器应用22之间的通信数据进行多路复用和多路去复用。如图所示，客户平台16和18均具有多个与之相应的客户应用，对平台16标识为应用20a—20x而对平台18标识为应用20b—20y。对应用间的数据通信进行多路复用减少了分配给客户和服务器平台管理客户平台和服务器平台之间的虚电路的时间。

为了复用各逻辑连接，通信代理把面向字节流的协议(例如TCP)转换成面向消息的格式。该功能是通过上述写和读原语以及相应的中间件库来完成的。下面要更详细地描述通信代理的操作。

下面参照图3描述一个对客户应用和服务器应用之间的通信进行多路复用的例子。为了开始与本地客户平台16相应的客户应用20a和在远端服务器平台14上的远端服务器应用22之间的通信，客户应用20a发出，比如一个包含针对目标远端服务器应用22的寻址信息的net—client—init()函数调用。该请求由客户平台通信代理12通过经接口A的进程间通信(IPC)来接管。通信代理12起初确定在客户应用和服务器应用之间是否存在一个虚电路。当通信代理在本地客户应用和一个远端服务器应用之间创建一个虚电路时，通信代理把该连接登录到一个连接表中。

通常，连接表入口包括虚电路远端网络地址，一个用于写入和读取虚电路的套接字描述符和一个指示有多少逻辑连接正使用该虚电路的逻辑连接(或链路)计数器。这样，在通信代理在A和B接口上创建一个虚电路之前，该通信代理把被请求的逻辑连接与登录在连接表中的连接相比较以确定在本地应用和目标远端应用间是否存在一个虚电路。若存在一个虚电路，则通信代理使用表中的套接字描述符进行通信并增加链路计数。若不存在一个虚电路，则创建一个虚电路且把该连接登录在连接表中。在该实例中链路计数被初始化为1。图5说明了上述进行建立虚电路的连接表处理的流程。

一旦通信代理确定在应用间存在虚电路或在应用间建立了虚电路，则本地客户平台16上的通信代理12把下一个可用逻辑通道ID赋予本地客户应用的A接口。从A接口出的消息被赋以逻辑通道ID而来自B接口的入消息根据逻辑通道ID被分派到相应的本地应用20a。在虚电路两边的通信代理中保持一张逻辑通道ID表以允许进行多路复用和多路去复用操作。

当本地客户应用20a不再需要到远端服务器应用22的虚电路连接时，本地客户应用20a发出一个由客户平台通信代理12接管的net—close()函数调用。这导致在两边针对使用的虚电路的逻辑连接表中释放所用的逻辑连接ID。另外，通信代理减少链路计数器。若没有其它的使用虚电路的逻辑电路，即链路计数器被减到零，则该虚电路会被关闭并从各通信代理的连接表中被去掉。图6说明了上述关闭虚电路的连接表处理的流程。

写控制流程为了向远端服务器应用22传输信息，本地客户应用22创建包含一个消息(信息)和该消息长度的网络包。该消息包含一个基于应用协议的数据单元。本地客户应用接着调用例如一个net—write()函数使得网络包通过进程间通信(例如，一个面向字节流的协议)沿A接口被发送出去。驻留在客户平台16的通信代理接受网络包并把字节流数据转换成面向消息的数据格式。若要发送的消息大于传输机制，即接口B支持的最大段长度。则通信代理把消息分成最大段长度减2(以字节为单位)的分段。各分段被前置一个单字节逻辑通道ID和一个单字节后读期望顺序号。序列中最后的包被赋予一个为零的后续期望顺序号，指示后面没有想要的段。放入一个传输段中的消息不用分段且后续期望顺序号被设成零。通过为逻辑通道ID和后续期望顺序号分配更多的空间，任意数量的同时连接可支持任意长度的消息。

读控制流程为从远端服务器应用22读取信息，本地客户平台16中的通信代理12读取单个虚电路，即接口B上的网络包并根据逻辑通道ID对这些包排序。通信代理12去掉逻辑通道ID和顺序号并把分段存在一个缓冲内存中直至收到后续期望顺序号为零的包。当最后的包被收到并存在缓冲内存时，一块消息内存被分配以支持在缓冲内存中的分段。接着缓冲区中完整的消息通过A接口被传送到由逻辑通道ID标识的本地客户应用(例如应用20a—20x或20b—20y)。通过比如一个由本地客户应用初始化的net—read函数来检索该消息。

除了本发明的ADI中的A和B接口部件，可以使用其它已知的接口来构成网络。如图3所示，一个被标识为接口“C”的数据采集接口的信息提供者和一个被标识为接口“D”的服务器应用接口的数据采集接口被提供作为主接口。

C接口把来自象旅行和天气信息提供者那样的不同信息提供者28和30的数据输入到驻留在数据采集平台26上的数据采集应用24。C接口可以使用已知的文件传输协议，如一个通过传输非结构化数据文件的拨号连接的1K—XModem纠错文件传输协议。一个适用的协议的例子是WINDOWS的PROCOMM PLUS，它是建立在数据采集平台26上的商业软件包。

再次参照图3，D接口把来自数据采集应用24的信息提供者数据传送给服务器应用22。最好是D接口包括一个在传输数据文件的TCP/IP协议栈上的网络文件服务(NFS)。一个适用的接口的例子是WINDOWS的Chameleon NFS，它也是建立在数据采集平台26上的一个商业软件包。

C和D接口间的联系是由数据采集应用提供且最好是一个包含在PROCOMM PLUS环境中的10线WINDOWS AspectScript。在文件传输期间Aspect Script在数据采集平台上缓冲输入的数据文件并在文件传输完成时，该文件被拷贝到一个由对应于一个服务器平台14上的文件系统的网络文件服务支持的虚拟驱动器上。

在一个如图7所示的可选的实施例中，D接口可由A和B接口以及相应的通信代理12代替。A和B接口以及通信代理12以上述方式进行操作对在一单个虚电路上的通信进行多路复用和多路去复用并在客户和服务器应用间提供透明网络通信。

图8给出一个结合本发明的通信代理的示例客户—服务器应用。所示的客户—服务器应用是一个包含交通和天气数据的服务器29和31，多用户客户平台16和18以及象接口A和B那样的多个实时数据源旅行者信息服务(TIS)。旅行者信息服务能够为用户提供个人的(例如住所到工作地旅行信息)和/或供公用的旅行报告(例如本地交通和天气)。TIS的网络体系结构类似于图3所示且在前面描述过的网络体系结构。

在操作上，交通和天气数据由信息提供者32和34通过接口C传输到对应的数据采集平台26和27。在接口D上交通和天气数据被传输到驻留在服务器平台14上的TIS服务器应用22。使用已知的加值处理技术，交通和天气数据被分段和重新组合并且接着被存在TIS服务器平台数据库36中。值相加处理在客户请求时进行从服务器平台到客户的个人旅行者报告或信息传输。

参照图4和8，根据由前述原语1和6初始化并侦听客户请求的服务平台14来描述TIS网络的操作。为查询一个旅行者报告，客户通过已知的拨入或T1/ISDN访问技术访问TIS客户应用20a并发出一个对旅行和/或天气数据的请求。TIS客户应用20a通过发出例如一个把目标远端应用的寻址信息插入网络包(例如字节流数据)中并使数据通过进程间通信在A接口上被发送出去的ipc—client—init()函数调用来发出一个网络请求。在本地客户平台16中的通信代理12在本地客户平台16接受本地应用网络请求并检查虚电路连接表以确定在本地客户应用20a和远端服务器应用22之间是否存在一条虚电路。若不存在一条虚电路，则通过在B接口上发出int net—ref＝net—client—init((long)network—address)原语来创建一个虚电路。

一旦建立了虚电路，平地平台16中的通信代理12发出把面向字节的流数据转换成面向消息的数据包并通过B接口传送数据请求的数据写原语(即，int net—ref＝net—write((char*)buf，(int)buf—length，(int)net—ref)原语)。驻留在服务器平台14上的通信代理72接受数据请求并发出通过接口A发送数据给服务器应用22的数据写原语(即，int status＝ipc—write((char*)buf，(int)buf—length，(int)ipc—rer)原语)。

服务器应用22响应于数据请求并使用标准的面向字节流的协议把被请求的数据发到A接口上。服务器平台14上的通信代理12接受发送数据请求并发出数据写原语(例如，int net—ref＝net—write((char*)buf，(int)buf—length，(int)net—ref)原语)。如上所述，发出数据写原语把面向字节的数据流转换成面向消息的数据流并通过B接口把信息传送到本地客户平台16。

本地平台16中的通信代理12通过发出一个数据读原语(即，int status＝net—read((char**)buf，(int*)buf—length，(int)net＝ref)原语)来读取服务器响应，把面向消息的数据流再转换成面向字节的数据流并通过A接口把信号传送到合适的TIS客户应用20。TIS客户应用20接着处理接收的数据并通过已知的拨入或T1/ISDN访问技术以期望的格式把数据传到客户。

这里所描述的仅仅是为了说明本发明原理的应用。本技术领域的技术人员可以实现其它方案和方法而并不偏离本发明的原则和范围。