CN100353315C - 应用集成方法以及应用集成系统 - Google Patents

应用集成方法以及应用集成系统 Download PDF

Info

Publication number
CN100353315C
CN100353315C CNB2004800053624A CN200480005362A CN100353315C CN 100353315 C CN100353315 C CN 100353315C CN B2004800053624 A CNB2004800053624 A CN B2004800053624A CN 200480005362 A CN200480005362 A CN 200480005362A CN 100353315 C CN100353315 C CN 100353315C
Authority
CN
China
Prior art keywords
adapter
message
receiver
data
abridged table
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Lifetime
Application number
CNB2004800053624A
Other languages
English (en)
Other versions
CN1754148A (zh
Inventor
迈克尔·吉尔福克斯
杰丽·沃尔特·马尔科姆
福尔尤索·奥莱雅·奥昆赛恩德
蒂龙·杰罗德·斯德丁
保罗·斯图尔特·威廉森
斯科特·李·温特斯
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Google LLC
Original Assignee
International Business Machines Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by International Business Machines Corp filed Critical International Business Machines Corp
Publication of CN1754148A publication Critical patent/CN1754148A/zh
Application granted granted Critical
Publication of CN100353315C publication Critical patent/CN100353315C/zh
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/54—Interprogram communication
    • G06F9/546—Message passing systems or structures, e.g. queues
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/54—Interprogram communication
    • G06F9/541—Interprogram communication via adapters, e.g. between incompatible applications
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/34—Network arrangements or protocols for supporting network services or applications involving the movement of software or configuration parameters 
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/56—Provisioning of proxy services
    • H04L67/565—Conversion or adaptation of application format or content
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/56—Provisioning of proxy services
    • H04L67/567—Integrating service provisioning from a plurality of service providers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/60—Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources
    • H04L67/63—Routing a service request depending on the request content or context
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/40—Network security protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/08—Protocols for interworking; Protocol conversion
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • H04L69/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
    • H04L69/329—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the application layer [OSI layer 7]

Abstract

应用集成的系统和方法，包括根据包括描述适配器的数据的简表，构成应用集成适配器，接收变更所述适配器的指令，和根据所述指令变更所述适配器。本发明的实施例包括通过变更后的适配器在应用之间传递集成消息。在典型的实施例中，接收变更适配器的指令包括检测适配器简表中的变化。在这样的实施例中，检测适配器简表中的变化包括创建简表的副本，和定期比较所述简表和所述副本。在其它例证实施例中，接收变更适配器的指令包括从应用接收承载变更适配器的指令的管理集成消息。在这样的实施例中，根据指令变更适配器包括更新所述简表。

Description

应用集成方法以及应用集成系统
技术领域
本发明涉及数据处理，更具体地说，涉及软件应用集成的方法、系统和产品。
背景技术
软件应用集成在提高生产率和降低成本方面至关重要。通过使商业过程流水线化并集成商业过程，公司能够大大降低运行开销。通过连接商业支持系统和运行支持系统，应用程序能够协调地工作，而不需要高成本的干预。通过脱离点对点消息接发，公司受益于集中消息接发基础结构：对商业过程的控制更大，并且运行效率提高。
过去，只有在高成本下实现软件应用集成。商业支持系统和运行支持系统的组件通常由不同的制造商或开发商开始和生产，并且利用根本不同的数据通信模式。来自一个开发商的库存管理应用程序可通过例如TCP/IP向由完全不同的公司开发的总分类帐公布库存变化。相同的库存管理应用程序可通过HTTP以HTML向源于利用第三组数据结构的第三个厂商的购买系统公布库存变化。利用数据结构的第三种组合，购买系统可向总分类帐公告。诸如此类。组合是无尽的。并且过去，通过雇用系统分析员，软件开发项目管理人员，软件系统设计人员，高级程序员，低级程序员等来建立转换数据结构，并管理所有这些根本不同的软件应用系统间的数据通信的应用集成适配器，来实现每个这样的集成。
通常以所谓的“点对点”方式实现这样的应用集成适配器。即，开发一种适配器，以便通过利用特定数据通信协议的特定数据通信耦接，使特定的库存应用程序与特定的总分类帐耦接。向该混合物中加入新的应用程序需要和待集成的前两个应用完全相同的新的开发成本。由于这些原因，具有改进的应用集成设备和方法理应是有利的。
发明内容
本发明的第一方面提供一种应用集成方法，所述方法包括：根据包含描述适配器的数据的简表(profile)，构成应用集成适配器；接收变更所述适配器的指令；和根据所述指令变更所述适配器。
更可取地，本发明提供一种方法，其中应用集成适配器包括：数据通信传送器和可选的数据传送管理器，所述数据通信传送器包括发送器和接收器。
更可取地，本发明提供一种方法，其中描述适配器的数据包括：识别通信协议的数据，和识别应用程序的数据。
更可取地，本发明提供一种还包括通过变更后的适配器，在应用之间传递集成消息的方法。
更可取地，本发明提供一种方法，其中接收变更适配器的指令还包括检测适配器简表中的变化。
更可取地，本发明提供一种方法，其中检测适配器简表中的变化还包括：创建简表的副本；和定期比较所述简表和所述副本。
更可取地，本发明提供一种方法，其中接收变更适配器的指令还包括从应用程序接收承载变更适配器的指令的管理集成消息。
更可取地，本发明提供一种方法，其中根据指令变更适配器还包括更新所述简表。
本发明的第二方面提供一种应用集成系统，所述系统包括：根据包含描述适配器的数据的简表，构成应用集成适配器的装置；接收变更所述适配器的指令的装置；和根据所述指令变更所述适配器的装置。
更可取地，本发明提供一种系统，其中应用集成适配器包括：数据通信传送器和可选的数据传送管理器，所述数据通信传送器包括发送器和接收器。
更可取地，本发明提供一种系统，其中描述适配器的数据包括：识别通信协议的数据，和识别应用程序的数据。
更可取地，本发明提供一种还包括通过变更后的适配器，在应用之间传递集成消息的装置的方法。
更可取地，本发明提供一种系统，其中接收变更适配器的指令的装置还包括检测适配器简表中的变化的装置。
更可取地，本发明提供一种系统，其中检测适配器简表中的变化的装置还包括：创建简表的副本的装置；和定期比较所述简表和所述副本的装置。
更可取地，本发明提供一种系统，其中接收变更适配器的指令的装置还包括从应用接收承载变更适配器的指令的管理集成消息的装置。
更可取地，本发明提供一种系统，其中根据指令变更适配器的装置还包括更新所述简表的装置。
本发明的第三方面提供一种可直接载入数字计算机的内部存储器中的计算机程序产品，包含当所述产品在计算机上运行时，实现权利要求1-8的发明的软件代码部分。
更可取地，本发明提供一种应用集成计算机程序产品，所述计算机程序产品包括：记录介质；记录在所述记录介质上的根据包含描述适配器的数据的简表，构成应用集成适配器的装置；记录在所述记录介质上的接收变更所述适配器的指令的装置；和记录在所述记录介质上的根据所述指令变更所述适配器的装置。
更可取地，本发明提供一种计算机程序产品，其中应用集成适配器包括：数据通信传送器和可选的数据传送管理器，所述数据通信传送器包括发送器和接收器。
更可取地，本发明提供一种计算机程序产品，其中描述适配器的数据包括：识别通信协议的数据，和识别应用程序的数据。
更可取地，本发明提供一种还包括记录在所述记录介质上的，通过变更后的适配器，在应用之间传递集成消息的装置的计算机程序产品。
更可取地，本发明提供一种计算机程序产品，其中记录在所述记录介质上的，接收变更适配器的指令的装置还包括记录在所述记录介质上的，检测适配器简表中的变化的装置。
更可取地，本发明提供一种计算机程序产品，其中记录在所述记录介质上的，检测适配器简表中的变化的装置还包括：记录在所述记录介质上的创建简表的副本的装置；和记录在所述记录介质上的定期比较所述简表和所述副本的装置。
更可取地，本发明提供一种计算机程序产品，其中记录在所述记录介质上的，接收变更适配器的指令的装置还包括记录在所述记录介质上的，从应用接收承载变更适配器的指令的管理集成消息的装置。
更可取地，本发明提供一种计算机程序产品，其中记录在所述记录介质上的根据指令变更适配器的装置还包括记录在所述记录介质上的更新所述简表的装置。
本发明的实施例实现应用集成的方法。本发明的实施例包括根据包括描述适配器的数据的简表，构成应用集成适配器，接收变更所述适配器的指令，和根据所述指令变更所述适配器。在这样的实施例中，应用集成适配器包括数据通信传送器和可选的数据传送管理器，所述数据通信传送器包括发送器和接收器。在典型的实施例中，描述适配器的数据包括识别通信协议的数据和识别应用程序的数据。
本发明的实施例包括通过变更后的适配器在应用之间传递集成消息。在典型的实施例中，接收变更适配器的指令包括检测适配器简表中的变化。在这样的实施例中，检测适配器简表中的变化包括创建简表的副本，和定期比较所述简表和所述副本。在其它实施例中，接收变更适配器的指令包括从应用接收承载变更适配器的指令的管理集成消息。在这样的实施例中，根据指令变更适配器包括更新所述简表。
附图说明
下面参考附图，详细说明本发明的实施例：
图1是图解说明根据本发明的各个实施例的应用集成适配器的体系结构的方框图；
图1a表示提供三个应用的集成的适配器的更详细的体系结构例子；
图1b表示提供应用程序的集成的适配器的另一体系结构例子；
图2是图解说明利用应用集成适配器的应用集成方法的数据流程图；
图3是图解说明根据本发明的创建传送应用集成适配器的接收器和发送器的方法的流程图；
图4是图解说明创建传输管理器的方法的数据流程图；
图5图解说明根据本发明的实施例，构成适配器的类别间的关系；
图5a-5h图解说明可用在本发明的各个实施例中的类别结构的例子；
图6是图解说明构成应用集成适配器的方法的调用序列图；
图7是描述通过适配器在应用程序之间交流集成消息的方法的数据流程图；
图8是描述通过适配器在应用程序之间交流集成消息的另一例证方法的数据流程图；
图9是图解说明通过适配器在应用程序之间交流集成消息的方法的调用序列图；
图10是图解说明包括变更适配器的应用集成的另一方法的数据流程图；
图11是图解说明包括从应用程序接收管理集成消息承载指令，从而变更适配器的应用集成的另一方法的数据流程图。
具体实施方式
在本说明书中，在很大程度上根据软件应用集成的方法描述了本发明。但是，本领域的技术人员会认识到包括根据所公开的方式工作的适当编程装置的任何计算机系统也落入本发明的范围之内。
适当的编程装置包括指令计算机系统执行本发明的方法的步骤的任何装置，例如包括由与计算机存储器耦接的处理单元和算术-逻辑电路组成的系统，所述系统具有把本发明的方法的编程步骤保存在计算机存储器中，以便由处理单元执行的能力，所述计算机存储器包括保存数据和程序指令的电子电路。本发明也可被具体化为供任何适当的数据处理系统之用的计算机程序产品，例如磁盘或者其它记录介质。
使用机器可读信息的任何记录介质，包括磁介质，光介质或者其它适当介质，可实现计算机程序产品的实施例。本领域的技术人员会立即认识到具有适当编程装置的任何计算机系统将能够执行具体化为程序产品的本发明的方法的步骤。
定义
在本说明书中，除非上下文另有说明，否则术语“字段”、“数据元素”和“属性”一般被用作同义词，指的是数字数据的各个元素。数据元素的集合体被称为“记录”或“数据结构”。记录的集合体被称为“表”或“文件”。表或文件的集合体被称为“数据库”。包括成员方法，函数或软件例程以及数据元素的复式数据结构被称为“类别”。类别的实例被称为“对象”或者“类别对象”。
“802.11”指的是IEEE为无线LAN技术提出的一系列规范。802.11规定无线客户机和基站之间以及两个无线客户机之间的空中接口。
“API”是“应用编程接口”的缩写。API是用于建立软件应用的一组例程、协议和工具。
“蓝牙”指的是用于客户机设备之间和客户机设备与LAN或其它网络上的资源之间的RF耦接的短程无线电技术的工业规范。称为蓝牙特别兴趣小组的管理团体测试并证明设备符合蓝牙标准。蓝牙规范由提供设计规范的‘Foundation Core’和提供互用性准则的‘Foundation Profile’组成。
“CORBA”表示公用对象请求代理体系结构，由对象管理组(OMG)首先于1991年公布的远程过程调用的标准。CORBA可被看作一种实现“RPC”或者远程过程调用的面向对象的方式，不过CORBA支持并不如此存在于RPC中的许多特征。通过使用CORBA技术，用面向对象的编程语言，例如Java和C++实现的远程方法调用好象是本地对象中本地成员方法。
CORBA数据通信由称为对象请求代理或者‘ORB’的中间件应用管理。ORB与“GIOP”(通用ORB间协议)通信，GIOP是定义在不同种类的计算机及它们的各种体系结构之中传递消息的结构和格式的CORBA协议。GIOP并不基于任何特定的网络协议，例如IPX或者TCP/IP。定义为在其最广泛使用的通信传送平台TCP/IP内发挥作用的GIOP被称为“IIOP”(因特网ORB间协议)。由于TCP/IP的通用性，在描述例证实施例方面，本公开趋向于或多或少地交替使用术语GIOP和IIOP，不过术语IIOP的使用并不意图把本发明的实施例的应用限制于单一的传输协议组TCP/IP。
“CGI”表示“公共网关接口”，一种web服务器和web客户机之间的资源的数据通信的标准技术。更具体地说，CGI提供服务器和服务器方‘网关’程序之间的标准接口，服务器方‘网关’程序管理相对于文件系统和数据库的实际读取和写入。CGI接口一般通过环境变量或者以将通过它们的标准输入由网关程序读取的数据的形式，把数据发送给网关程序。网关程序一般通过标准输出返回数据。
“数据通信的耦接”表示任何形式的数据通信，无线、802.11b、蓝牙、红外、无线电、网际协议、HTTP协议、电子邮件协议、连网、直接连接、专用电话线、拨号、EIA232(RS-232)串行连接、IEEE1394(常称为‘火线’连接，苹果计算机公司的商标)、通用串行总线(“USB”)、硬连线并行端口连接、和本领域的技术人员易于想到的其它形式的数据通信。数据通信的耦接包括文件的共享，包括从应用到应用，从适配器到应用程序，或者从应用程序到适配器的传送文件，包括平面文件、二进制文件、文本文件、数据库文件、HTML文件、XML文档等。
“DCOM”表示“分布式组件对象模型”，一种支持分布在网络间的对象的微软的组件对象模型(“COM”)的扩展。DCOM是某些微软操作系统(包括Windows NT)的一部分，并且适用于其它操作系统。DCOM起和IBM的DSOM协议相同的用途，IBM的DSOM是CORBA的普及实现。和在许多操作系统上运行的CORBA不同，目前只为Windows实现了DCOM。
“格式”或“数据格式”指的是用于数据处理和数据通信的数据编码的全部形式。数据格式的例子包括编码成HTML文档，XML文档，Java数据结构，C++数据结构，C数据结构等形式的数据。除了格式之外，计算机数据具有包括数据元素名称，数据元素类型和数据元素值的结构。在本公开中，改变或转换数据的结构被称为“数据变换”或“变换”(transformation)。
“HTML”代表‘超文本置标语言’，一种在浏览器上显示web页的标准置标语言。
“HTTP”代表‘超文本传送协议’，万维网的标准数据通信协议。
“JMS”表示“Java消息服务”，专门为应用集成消息接发设计的Java API。JMS提供一种支持消息业务的异步管理的Java enterprisebean。JMS发送和接收能够参与通过Java事务API(“JTA”)控制的事务。JTA配合Java事务服务(“JTS”)工作。JTA允许应用和应用服务器访问事务。JTS规定支持JTA的事务管理器的实现，并在低于API的层次实现OMG对象事务服务(“OTS”)的Java映射。JTS利用IIOP扩展事务。
“IMAP”表示‘因特网消息存取协议’。IMAP是一种用于从因特网电子邮件服务器取回电子邮件消息的协议。在“离线”操作中，电子邮件客户机把消息从电子邮件服务器提取到正在运行电子邮件客户程序的客户机。在“在线”操作中，消息可被留在电子邮件服务器上，由电子邮件客户程序远程处理。POP支持离线电子邮件操作。IMAP(更新的协议)既支持离线电子邮件操作又支持在线电子邮件操作。
“LAN”表示‘局域网’。
在本说明书中，“网络”用于表示用于计算机或计算机系统之中的数据通信的任何连网耦接。可与本发明一起使用的网络的例子包括企业内部网，外联网，局域网，广域网和本领域的技术人员易于想到的其它网络结构。
“POP”表示‘邮局协议’。POP是一种由电子邮件客户机用于从邮件服务器取回电子邮件的协议。存在两种形式的POP。POP2要求SMTP从客户机或者其它服务器接收电子邮件消息。更新的版本POP3能够在有或没有SMTP的情况下使用。
“伪代码”是在本公开中用于解释的编程语言的例证源代码或者置标语言的置标的例子。伪代码未被表示成严格遵守任何特定的编程语言或置标语言的要求，从而不存在出自本公开内容的伪代码例子将编译或执行的任何表示。但是，伪代码例子将有助于说明，以使本领域的技术人员能够根据本发明的实施例，产生和使用应用集成适配器。
“RMI”指的是“远程方法调用”，由太阳微系统公司开发的协议组，使Java对象能够远程与其它Java对象通信。RMI是一种相当简单的协议，但是不同于诸如CORBA和DCOM之类更复杂的协议，它只对Java对象起作用。CORBA和DCOM支持用任何语言创建的对象之间的连网通信和远程过程调用。
本说明书中的“服务器”指的是包含网络上的管理资源和对资源的访问请求的自动化计算机器的计算机或设备。“安全服务器”可以是通过使用根据本发明的安全对象，管理对资源的访问的任何服务器。“web服务器”或者特别是“HTTP服务器”是借助HTTP与浏览器通信，以便管理和使连网计算机能够得到用置标语言，比如HTML编写的文档，数字对象和其它资源的服务器。
“小服务程序”(servlet)，比如小应用程序(applet)是用来从另一程序，而不是直接从操作系统运行的程序。“小服务程序”尤其被设计成从小服务程序的常规Java接口在服务器上运行。小服务程序是扩展面向请求/响应的服务器，例如允许Java的web服务器的模块。Java小服务程序是CGI程序的替换物。两者之间的最大差别在于Java小服务程序是持久的。一旦小服务程序被启动，它就停留在存储器中，并且能够实现多个请求。相反，CGI程序在其被执行一次之后就消失，每次加载和运行只能实现一个请求。Java小服务程序的持久性使得它们一般快于CGI，因为在首次之后，不花费时间来加载供调用的小服务程序。
“SMTP”表示“简单消息传送协议”。SMTP是在服务器之间发送电子邮件消息的协议。因特网电子邮件通信量主要通过SMTP从一个服务器到达另一服务器。在电子邮件到达目标服务器之后，电子邮件客户机随后使用POP或者IMAP从所述服务器取回电子邮件消息。SMTP还被用于把消息从邮件客户机发送给邮件服务器。
“SOAP”是简单对象访问协议，一种与平台无关的用于因特网上的应用通信的协议。SOAP包括用于表示远程过程调用和响应的协定。SOAP可能可以和各种传送协议一起使用，不过到目前为止，它主要和HTTP一起使用。SOAP一般使用XML来定义消息格式，随后增加用于数据通信的HTTP报头。
“TCP/IP”指的是实现数据通信协议的标准ISO协议组的网络层和传输层的两种数据通信协议。严格地说，“TCP”(传输控制协议)是驻留在“IP”(网际协议)之上的独立一层。不过，这两者通常被一起表示成“TCP/IP协议组”。
“URI”或者“统一资源标识符”是可通过网络访问的任何名称空间中的命名对象。URI适用于任何访问方案，例如包括文件传送协议或者说“FTP”，Gopher和the web。本发明的典型实施例中使用的URI一般包括网际协议地址，或者解析为网际协议地址的域名，识别资源，特别是网页、CGI脚本或者小服务程序在网络(通常是因特网，一种在其ISO网络层中使用网际协议的网络)上所处的位置。指向特定资源，比如特定的HTML文件，CGI脚本或者小服务程序的URI一般包括定位并识别通过服务器与网络耦接的文件系统中的特定资源的路径名或者文件名。在特定资源，例如CGI文件或者小服务程序是可执行的，例如保存或取回数据的情况下，URI通常包括查询参数，或者要保存的数据，以编码到URI中的数据的形式。这样的参数或者要保存的数据被称为“URI编码数据”。
“URL”或者说“统一资源定位符”包含一种URI的子集，其中每个URL解析成某一网络地址。即，URI和URL是有区别的，因为URI识别名称空间中的命名对象，所述名称可以也可不解析为地址，而URL确实解析为地址。虽然目前基于URI编写标准，不过仍然常见用于使web数据位置与数据通信的网络地址相联系的这种称为“URL”的与web相关的标识符。本说明书把这样的标识符统称为URI。
“WAN”意味着“广域网”，WAN的一个例子是因特网。
“万维网”或者更简单地“the web”指的是支持特别格式化的文档(以置标语言，例如HTML，XML(可扩展的置标语言)，WML(无线置标语言)，或者HDML(手持设备置标语言)格式化的文档)的网际协议(“IP”)服务器的体系。本说明书中使用的术语“Web”还表示实现超链接协议，比如HTTP或者WAP(“无线访问协议”)，支持URI和用置标语言编写的文档的任何服务器或者连接的一组或者互连的多组服务器，与这样的服务器或者多组服务器本身是否与万维网耦接无关。
“XML”指的是“可扩展置标语言”，一种使数据结构化的已知标准。XML被用于提供灵活并且可修改的信息格式化和标识。XML被称为是可扩展的，因为它不像HTML(超文本置标语言，它是一组预定的置标)那样具有任何固定的格式。相反，XML实际上是一种“元语言”-一种描述其它语言的语言-它允许用户为许多不同类型的文档设计定制的置标语言。但是，XML本身不是编程语言；它是一种使数据结构化的置标标准。但是，在本公开中，由于XML具有对计算机数据编码或者使之结构化的效果，因此XML文档和XSL规范的准备(尽管它们本身可能不由计算机程序员执行)仍然被看作计算机编程或者软件开发。
类似于HTML，XML利用元素，标记和属性。元素是由标记识别的内容段。元素可能具有空值，元素的实例的值是所述元素的实例的起始标记和终止标记之间的字符串。“标记”是由“<”和“>”括起来的单词，属性是元素的定义的特性，例如具有下述形式：AttributeName＝“Value”。虽然HTML规定每个标记和属性意味什么，并且通常规定它们之间的文本在浏览器中看起来如何，不过XML只使用标记来划定各段数据的界限，把数据的解释完全留给读取数据的应用程序。换句话说，虽然在HTML的预定语法中，“<p>”表示“段落”，不过在XML文件中，“<p>”表示读取应用程序表达它意味的不论什么。根据上下文，它可以是价格，参数，人，或者在许多情况下，它代表与Ps无关的某一实体。
“XSL”指的是“可扩展样式语言”，一种当创建HTML或者XML页时，把样式与内容分开的规范。XSL规范非常类似于模板，允许用户和设计人员对多页应用单一的样式文档。XSL是由万维网联盟提供的第二种样式规范。称为级联样式表的第一种样式规范类似于XSL，但是不包括两种主要的XSL的革新-允许开发人员规定打印网页的方式，和一种在本发明的许多实施例中特别有用的革新，允许用户或开发人员跨越不同的应用转移XML文档的规范。即，XSL具有规定用XML表述的数据结构的变换的能力。
“XSLT”指的是“可扩展样式语言变换”，在XSL样式表中用于把XML文档变换成其它XML文档的语言。XSL处理器读取XML文档并遵循XSL样式表中的指令；随后它输出新的XML文档或者XML文档片段。这在本发明的需要把相同的数据格式转换成用XML表示的不同结构的各个实施例中特别有用。
应用集成
本发明的实施例提供能够在各种计算机体系结构中实现数据变换，数据转译(translation)和数据通信的应用集成适配器。图1、1a和1b图解说明由根据本发明的各个实施例的应用集成适配器(“适配器”)支持或者与之一起使用的几种结构布置。这些图还表示根据本发明的各个实施例的适配器本身的一些结构形态。
图1表示了适配器之间的数据通信体系结构。根据图1的一种体系结构，适配器(102)把在安全防火墙(128)内的应用(106)的功能与在防火墙(128)的另一侧的应用(116)结合起来。适配器通过WAN(126)与在防火墙(128)之外的应用(116)耦接(118)以便进行数据通信。适配器与在防火墙(128)之内，事实上与适配器(102)一起安装在相同的应用服务器(104)上的应用(116)耦接(106)以便进行数据通信。
用于数据通信的耦接包括数据通信的任何方法，设备或者协议，光学耦接，电耦接，机械耦接或者其它耦接。用于数据通信的耦接必定包括所有数据通信协议和远程过程协议，比如HTTP、CORBA、DCOM、IIOP、GIOP、RMI、SOAP等。
用于数据通信的耦接包括通过简单网络寻呼协议或者说“SNPP”，对由电话号码识别的无线寻呼机客户机的消息接发，简单网络寻呼协议的第3版是如同在RFC1861中定义的增强的双向协议。RFC1861是由因特网工程任务组中的网络工作组公布的因特网协议组规范文档。
用于数据通信的耦接包括对无线寻呼机客户机WCTP(“无线通信传送协议”)的消息接发。WCTP是另一种双向消息接发协议。在抱着使用HTTP作为其传送机制的特殊目的的情况下设计了WCTP。WCTP是由PCIA(个人通信工作协会)的成员发布的一种开放的非专有行业标准。
用于数据通信的耦接包括通过许多专有瞬时消息接发协议中的任意一种，经HTTP传送的消息接发，所有这些协议都具有只适合于这种用途，即，供诸如PVR之类消息接发应用程序之用的应用编程接口(“API”)。具有API的这种瞬时消息接发协议的例子包括可从美国在线(“AOL”)，微软网络(“MSN”)，雅虎、Imici公司和ICQ公司获得的那些瞬时消息接发协议。
用于数据通信的耦接包括在任意类型的设备、个人计算机、膝上型计算机、手持式设备、蜂窝电话机、服务器等上的适配器和应用之间，通过SMTP、POP、IMAP或者其它电子邮件协议，以电子邮件的形式传送消息。
用于数据通信的耦接包括由任何电信公司支持的短消息业务(“SMS”)或者电话业务。SMS提供一种相对于无线设备传送短消息的机制。SMS支持以类似于字母-数字寻呼的方式，从适配器到应用程序的短文本消息的传输。SMS利用短消息服务中心(“SMSC”)，短消息服务中心充当短消息的存储转发系统。与诸如字母数字寻呼之类的其它现有文本消息传输业务相反，SMS是一种可靠的系统，提供保证到目的地的文本消息的传送的机制。另外，SMS支持允许与不同消息源和目的地的互连的数个输入机构。例如，适配器，或者其发送器或接收器能够起所谓的“外部短消息实体”(“ESME”)的作用，并以HTTP表格或者电子邮件消息的形式传送SMS消息。适配器能够起移动始发者(“MO”)，即允许SMS的客户机设备或者实际上蜂窝电话机的作用。SMS是一个显著特征在于允许SMS的客户机能够在任何时候接收或者提交短消息，与是否正在进行语音或者数据呼叫无关。
用于数据通信的耦接包括除了数据通信协议之外的数据耦接方法，例如包括共享存储器区段，它可能是在其中适配器(102)与所述适配器集成的应用(106)一起被安装在相同服务器(104)上的体系结构中利用的非常好的方法。应用(106)内的通信模块和具有适配器(102)的通信模块，例如本公开中下面更详细讨论的接收器和发送器可被实现成在使用信号标志管理互斥的情况下，通过共享存储器区段，传递消息的同步Java方法或者C或C++线程。
如上所述，用于数据通信的耦接包括有线网络协议以及无线网络协议和消息接发系统。但是，用于数据通信的耦接另外还包括非连网耦接，包括符合RS-232(EIA232)，IEEE 1394(通常称为“火线”连接，苹果计算机公司的商标)的有线串行耦接，硬连线并行端口连接和本领域的技术人员易于想到的其它直接的有线耦接。
根据图1的另一例证体系结构，在客户机工作站(132)上的适配器(136)把安装在同一工作站上的应用(134)的功能与通过LAN(130)与所述工作站耦接(136)以便进行数据通信的服务器上的应用(116)结合起来。由于适配器(136)和应用(134)在相同的计算机上，因此甚至通过共享存储器区段或者通过本领域的技术人员易于想到的在相同计算机上执行程序或线程以便相互通信的其它方法，适配器(136)和应用(134)之间的用于数据通信的耦接(108)可被实现成对工作站上的软件程序或模块的本地调用。虽然利用耦接在服务器(114)和工作站(132)之间的LAN(130)表示该特定的体系结构例子，不过读者如今明白工作站可以是笔记本计算机，用于数据通信的耦接(136)可以是直接通过服务器(114)和工作站(132)之间的导线的RS232或USB连接。
根据图1的另一例证体系结构，适配器(102)集成三个应用(106、112、116)的功能。适配器(102)通过WAN(126)与一个应用(116)耦接(116)以便进行数据通信。适配器(102)与和所述适配器一起安装在相同服务器(104)上的另一应用(106)耦接(108)以便进行数据通信。适配器(102)通过LAN(124)与和适配器(102)一起在相同防火墙(128)之后的第二服务器(110)上的第三应用(112)耦接(126)以便进行数据通信。在这种体系结构中，如果应用(116)是精炼厂中的库存管理程序，应用(106)是公司总部中的服务器上的总分类帐，应用(112)是在和所述总部位于相同公司场地的另一建筑物中的采购系统，那么采购系统可通过HTTP把关于库存变化的公布消息传送给适配器(102)，适配器(102)可通过共享存储器区段把所述公布消息转发给总分类帐，并通过SOAP、IIOP或者RMI把所述公布消息转发给采购系统。采购系统和总分类帐可对库存管理程序报以确认消息。采购系统可以只把关于新采购的公布消息传送给总分类帐，而不抄送给库存管理系统。总分类帐可以只向采购系统发送确认，而不抄送给库存管理程序。所有这三个应用都能够在它们的消息中利用由三个不同的软件开发公司毫无协调地开发的完全不同的数据结构。
图1a表示提供三个应用(106、112、116)的集成的适配器(102)的更详细体系结构例子。图1a的例子包括称为“传送器”(transport)的三个软件模块(140、142、144)，它们在根据本发明的实施例的许多适配器中被用于执行数据通信和消息格式转译。图1a的例证适配器包括图(105)，一种绘制传送器之间的消息路线的图的数据结构。即，根据本发明的实施例的许多适配器根据路由图(route map)在传送器之间，于是在应用之间路由消息。继续库存管理程序，总分类账和采购系统的例子，图1a的适配器(102)通过利用路由图(105)能够了解：
来自采购系统的公布消息只被发送给总分类帐，不被发送给库存控制程序；
来自总分类账的采购公布确认消息只被发送给采购系统，不被发送给库存管理程序；
来自库存管理程序的公布消息既被发送给总分类帐，又被发送给采购系统；
来自总分类帐的库存公布确认消息只被发送给库存管理程序；和
来自采购系统的库存公布确认消息只被发送给库存管理程序。
有利的是，只具有两个传送器，并且只集成两个应用的简单适配器可在无路由图的情况下工作，把来自任何一个应用的所有消息发送给另一应用，而不管消息的类型。图1a的例子图解说明适配器中路由图的实用性，但是在该例子中，依据消息类型，消息源和消息目的地索引路由图。图1a的例子只图解说明了只利用三个适配器集成的三个应用，并且本公开只讨论了少数消息类型。鉴于在根据本发明的实施例中，对适配器中的传送器的数目或者能够被有效集成的应用的数目没有任何限制的事实，路由图的实用性是明显的。
图1b表示了提供应用(112、116)的集成的适配器(102)的另一体系结构例子。在图1b的例子中，传送器(142、144)包括称为“接收器”(312)和“发送器”(316)的附加软件模块，它们在根据本发明的实施例的许多适配器中被用于执行适配器和软件应用之间的数据通信。在图1b中举例说明的这种实施例中，接收器和发送器均管理它们自己的用于数据通信的耦接(118、119、126、127)。另外，本发明对耦接的类型没有任何限制。即，在根据本发明的实施例的特定的例证适配器中，传送器(142)中的接收器(312)能够以按照SOAP的消息通信量的形式实现其用于与应用的数据通信的耦接，而相同传送器(142)中的发送器(316)能够以明文HTTP“公布”消息的形式发送其消息通信量。
图2是图解说明利用应用集成适配器的应用集成方法的数据流程图。具体地说，图2的方法包括构成(204)应用集成适配器，其中根据包含描述所述适配器的数据的简表(202)进行所述构成。图2的方法还包括提供(210)包含至少两个通信传送器的标识(214)的适配器简表，包括数据通信传送器的配置参数(218)。在根据本发明的适配器的许多实施例中，提供(210)简表由通过字处理器或者文本编辑器，键入指定用作简表的文本文件(描述适配器的组件的数据结构的表现)的用户或开发人员完成。所述表现可以是数据结构的任何编码，例如包括XML。事实上，本公开主要讨论用XML表示的简表，不过这是为了便于说明，而不是对本发明的限制。简表可利用数据结构的任何表示法，C、C++、Java、SGML(标准通用置标语言)，以及本领域的技术人员易于想到的其它表示法来编码。
图2的方法还包括通过适配器(102)在应用(105、112)之间传递(206)集成消息(208)。在图2的方法的许多实施例中，提供(210)适配器简表还包括提供包含适配器内的传送器(212)之间的数据路线的路由图(216)的适配器简表，根据路由图(216)完成应用程序之间的传递(206)集成消息。在根据图2的方法中，构成(214)集成适配器还包括创建在适配器简表(202)中识别的传送器(212)，和根据配置参数(218)配置(222)传送器(212)。
简表是表示适配器结构，并且具有识别和描述适配器的组件的数据元素的数据结构。根据本发明的适配器使用所述简表，根据在所述简表中陈述的其组件的描述，有效地构成自身。由于简表是数据结构，因此可按照任何数据结构可被实现的任何方式，用任何编程语言，用任意类型的编码，用任意类型的文件格式或者数据库记录结构，实现简表。本公开用XML表示简表，这不是本发明的限制，而是因为XML便于读者理解，简表的许多实现，例如呈二进制机器可读格式的实现不是那么便于供说明之用。另外，在本公开中，倾向于以面向对象的术语，尤其是利用Java和C++来呈现例子。不过同样地，本发明并不局限于任何特定编程范例或者任何特定编程语言。考虑到这些注意事项，下面是简表的一个XML例子：
<adapter>
<transportmodules>
<transport class＝″InventoryControl.java″id＝″inventoryControl″>
<receiver>
   <configParm>parmValue</configParm>
</receiver>
<sender>
 <configParm>parmValue</configParm>
</sender>
</transport>
<transport class＝″GeneralLedger.java″id＝″generalLedger″>
<receiver>
<configParm>parmValue</configParm>
</receiver>
<sender>
<configParm>parmValue</configParm>
</sender>
</transport>
  </transportmodules>
<transfermodules>
 <transferManager class＝″xfrMgr1.java″order＝″1″>
  <configParm>parmValue</configParm>
</transferManager>
<transferManager class＝″xfrMgr2.java″order＝″2″>
<configParm>parmValue</configParm>
</transferManager>
<transferManager class＝″xfrMgr2.java″order＝″3″>
<configParm>parmValue</configParm>
</transferManager>
</transfermodules>
</adapter>
该例证的XML简表识别两个传送器，一个名为“inventoryControl”，一个名为“generalLedger”。每个传送器具有一个接收器和一个发送器。每个接收器和发送器具有一个配置参数。简表的许多实现将识别和定义两个以上的传送器，发送器和接收器的许多实现将具有一个以上的配置参数。本例中的数字是为了说明的清楚简洁而挑选的，而不是对本发明的限制。
例如，就拨号电话通信协议的发送器和接收器来说，配置参数可包括电话号码，调制解调器速度，注册识别码，口令等。就HTTP通信协议的发送器和接收器来说，配置参数包括一个或多个URI。就实现与JMS的数据通信的发送器和接收器来说，配置参数可包括JMS队列的标识，队列连接，队列发送者，队列连接工厂对象或工厂方法，命名目录上下文等。就通过明文TCP/IP实现数据通信的发送器和接收器来说，配置参数包括网际协议地址和端口号。对于通过文件系统中的平面文件实现数据通信的发送器和接收器来说，配置参数包括路径名和文件名。
该例证的XML简表识别并提供三个传送管理器的配置参数。一个传送管理器本质上是被允许处理适配器接收或发送的消息的自含式程序代码。传送管理器便于对消息的任意处理，以便支持高级路由，转译，安全，登录，或者本领域的技术人员易于想到的消息处理的任意其它功能。传送管理器和运行它们的顺序在适配器简表中定义。根据本发明的适配器一般支持任意数目的传送管理器。不存在应用于传送管理器的任何处理限制。任何传送管理器可以按照任何方式随意处理传送给它的任何消息的消息内容，包括消息主体和任何报头参数的处理。
更特别地，该例证XML简表识别和提供三个传送管理器的配置参数，但是不包含任何明确的路由图。根据该例证简表建立的适配器把在inventoryControl传送器中接收的所有消息发送给所有传送管理器，随后发送给generalLedger传送器中的发送器。在这样的适配器中，在generalLedger传送器中接收的所有消息被发送给所有传送管理器，随后被发送给在inventoryControl传送器中的发送器。<transferManager>标记中的“class”属性识别每个传送管理器可从中被实例化的Java类别。<transferManager>标记中的“order”属性识别消息事件将被传递给传送管理器的顺序，以致根据需要，传送管理器可被设计和编程为相互依赖或者并不相互干扰。
不是所有的传送管理器都将处理所有消息，尽管在该特定的模型中，所有的消息被传送给所有的传送管理器。即，编程为变换公布消息中的记帐项目的数据结构的传送管理器将不对ACK(确认消息)进行无论什么处理。在该模型中，根据消息事件中的参数推断哪些消息将由特定的传送管理器处理是传送管理器它们自己的编程的一部分。在已知与图5h中附图标记(602)图解说明的类似的消息事件对象的情况下，传送管理器被编程为根据目的地ID码(604)，可能还结合源ID码(606)或者消息类型代码(607)推断从库存管理程序行进到总分类帐的公布消息是将由特定的传送管理器处理或者忽略的消息。如果路由结构简单，并且只有一种消息行进到特定目的地，那么仅仅目的地ID(604)就足够了。如果特定适配器中的路由备选方案复杂，并且许多消息类型行进到相同目的地，那么传送管理器可能需要更多的信息来确定特定的消息是否是它要处理的消息。
简表中的路由图有助于解决这种复杂性。例如，考虑下述的例证XML简表：
<adapter>
<transportmodules>
<transport class＝″InventoryControl.java″id＝″inventoryControl″>
<receiver>
<configParm>parmValue</configParm>
</receiver>
<sender>
<configParm>parmValue</configParm>
</sender>
</transport>
<transport class＝″GeneralLedger.java″id＝″generalLedger″>
<receiver>
<configParm>parmValue</configParm>
</receiver>
<sender>
<configParm>parmValue</configParm>
</sender>
</transport>
<transport class＝″Purchasing.java″id＝″purchasingSystem″>
<receiver>
<configParm>parmValue</configParm>
</receiver>
<sender>
<configParm>parmValue</configParm>
</sender>
</transport>
</transportmodules>
<transfermodules>
<transferManager class＝″xfrMgr1.java″mapID＝″route1″order＝″1″>
<configParm>parmValue</configParm>
</transferManager>
<transferManager class＝″xfrMgr2.java″mapID＝″route3″order＝″2″>
<configParm>parmValue</configParm>
</transferManager>
<transferManager class＝″xfrMgr3.java″mapID＝″route3″order＝″3″>
<configParm>parmValue</configParm>
</transferManager>
             <transferManager class＝″xfrMgr4.java″  mapID＝″route2，route4，
        route5″order＝″4″>
<configParm>parmValue</configParm>
</transferManager>
</transfermodules>
<routemaps>
<map id＝″route1″>
<msgType>post</msgType>
<from>purchasingSystem</from>
<to>generalLedger</to>
</map>
<map id＝″route2″>
<msgType>ACK</msgType>
<from>generalLedger</from>
<to>purchasingSystem</to>
</map>
<map id＝″route3″>
<msgType>post</msgType>
<from>inventoryControl</from>
<to>generalLedger</to>
<to>purchasingSystem</to>
</map>
<map id＝″route4″>
<msgType>ACK</msgType>
<from>generalLedger</from>
<to>inventoryControl</to>
</map>
            <map id＝″route5″>
<msgType>ACK</msgType>
<from>purchasingSystem</from>
<to>inventoryControl</to>
</map>
</routemaps>
</adapter>
该例证XML简表识别和描述分别名为“inventoryControl”、“generalLedger”和“purchasingSystem”的三个传送器。该例证的XML简表描述由唯一的序号1、2、3和4识别的四个传送管理器。传送管理器元件现有在<transferManager>标记中具有新的属性“mapID”，用于联系传送管理器和路由图。“mapID”取路由图识别码作为其值。
该例证XML简表还描述由识别码“route1”、“route2”、“route3”、“route4”和“route5”识别的五个路由图。路由图“route1”描述从采购系统到总分类帐的类型“post”的消息的消息路线。路由图“route2”定义从总分类帐到采购系统的确认消息的消息路线。路由图“route3”定义从库存管理程序到总分类帐以及到采购系统的公布消息的消息路线。路由图“route4”定义从总分类帐到库存管理程序的库存公布确认消息的消息路线。路由图“route5”定义从采购系统到库存管理程序的库存公布确认消息的消息路线。
根据类似于该XML例子的简表建立的例证适配器仅仅通过传送管理器之一，即由属性“order＝1”识别的传送管理器，把公布消息从采购系统发送给总分类帐。在本例中，必须检查消息事件参数，比如目的地ID、源ID、消息类型等，以便确定将使用哪条路线，从而确定哪个传送管理器将处理哪些消息的正是所述适配器。即，在本例中，只有一种消息类型被发送给具有<transferManager>属性“order＝1”的传送管理器，从而不需要传送管理器分析它是否要处理它所接收的消息：它仅仅处理它收到的所有消息。
类似地在本例中，所有确认消息或者说“ACK”被发送给具有<transferManager>属性“order＝4”的传送管理器。在这种传送管理器的一些例证实施例中，传送管理器将按照类似的方式处理所有ACK消息。就ACK消息处理随目的地或源而不同来说，传送管理器要通过参考传送给它的每个消息事件中的目的地ID(图5h上的604)或源ID(606)完成该确定。同样在本例中，根据出自适配器简表的路由图，是否处理某一消息的确定被从传送管理器移出，并被放入适配器自己的程序设计中。
在该例证的XML简表中，从库存管理程序到总分类帐以及到采购系统的公布消息的处理也是指导性的。路由图“route3”定义从库存管理程序到总分类帐以及到采购系统的消息路线。在该简表中，两个传送管理器被描述成在“route3”上，即具有<transferManager>属性“order＝2”的传送管理器和具有<transferManager>属性“order＝3”的传送管理器。在本例中，总分类帐和采购系统出自不同的软件开发人员，并对帐户公布使用完全不同的数据结构。假定具有<transferManager>属性“order＝2”的传送管理器把来自库存管理结构的输入消息的数据结构变换成总分类帐结构，具有<transferManager>属性“order＝3”的传送管理器把来自库存管理结构的输入消息的数据结构变换成采购系统结构。本例中的适配器产生来自库存管理传送器的输入公布消息事件的副本，把原件发送给具有<transferManager>属性“order＝2”的传送管理器，并把副本发送给具有<transferManager>属性“order＝3”的传送管理器。根据对具有<transferManager>属性“order＝2”的传送管理器的调用的返回，适配器把现在为供总分类帐之用而构成的原始消息事件转发给用于总分类帐的传送器中的发送器。根据对具有<transferManager>属性“order＝3”的传送管理器的调用的返回，适配器把现在为供采购系统之用而构成的消息事件的副本转发给用于采购系统的传送器中的发送器。在本例的所有情况中，接收消息的传送管理器仅仅处理所述消息，而不决定是否处理消息。根据消息事件本身中的目的地、源和类型信息(例如图5h上的附图标记604、606、607)，决定哪个传送管理器将处理哪些消息的处理负担被有效地转移给适配器对象本身。
在一些实施例中，传送管理器在通过适配器的一条以上的路线上被调用。不是通过在传送模块元件中使用传送管理器的多个项目(entry)来实现多个路由(就我们的XML例子来说)，在备选的例证实施例中，有利的是直接在路由图描述中列举传送管理器，如下面的例子所示：
<adapter>
<transportmodules>
<transport class＝″InventoryControl.java″id＝″inventoryControl″>
<receiver>
<configParm>parmValue</configParm>
</receiver>
<sender>
<configParm>parmValue</configParm>
</sender>
</transport>
<transport class＝″GeneralLedger.java″id＝″generalLedger″>
<receiver>
<configParm>parmValue</configParm>
</receiver>
<sender>
<configParm>parmValue</configParm>
</sender>
</transport>
<transport class＝″Purchasing.java″id＝″purchasingSystem″>
<receiver>
<configParm>parmValue</configParm>
</receiver>
<sender>
<configParm>parmValue</configParm>
</sender>
</transport>
</transportmodules>
<transfermodules>
<transferManager class＝″xfrMgr1.java″id＝″xfrMgrName1″order＝″1″>
<configParm>parmValue</configParm>
</transferManager>
<trausferManager class＝″xfrMgr2.java″id＝″xfrMgrName2″order＝″2″>
<configParm>parmValue</configParm>
</transferManager>
<transferManager class＝″xfrMgr3.java″id＝″xfrMgrName3″order＝″3″>
<configParm>parmValue</configParm>
</transferManager>
<transferManager class＝″xfrMgr4.java″id＝″xfrMgrName4″order＝″4″>
<configParm>parmValue</eonfigParm>
</transferManager>
</transfermodules>
<routemaps>
<map id＝″route1″>
<msgType>post</msgType>
<from>purchasingSystem</from>
<to>generalLedger</to>
<transferManager>xfrMgrName1</transferManager>
</map>
<map id＝″route2″>
<msgType>ACK</msgType>
<from>generalLedger</from>
<to>purchasingSystem</to>
<transferManager>xfrMgrName4</transferManager>
</map>
<map id＝″route3″>
<msgType>post</msgType>
<from>inventoryControl</from>
<to>generalLedger</to>
<to>purchasingSystem</to>
<transferManager>xfrMgrName2</transferManager>
<transferManager>xfrMgrName3</transferManager>
</map>
<map id＝″route4″>
<msgType>ACK</msgType>
<from>generalLedger</from>
<to>inventoryControl</to>
<transferManager>xfrMgrName4</transferManager>
</map>
<map id＝″route5″>
<msgType>ACK</msgType>
<from>purchasingSystem</from>
<to>inventoryControl</to>
<transferManager>xfrMgrName4</transferManager>
</map>
</routemaps>
</adapter>
该例证简表实现发送器和接收器之间与前面的例证简表所实现的完全相同的路线。即，路由图“route1”描述从采购系统到总分类帐的类型“post”的消息的消息路线，包括通过第一个列举的传送管理器(这里用其识别名“xfrMgr1”识别)的路由。路由图“route2”定义从总分类帐到采购系统的确认消息的消息路线，包括通过第二个列举的传送管理器(这里用其识别名“xfrMgr2”识别)的路由。对于剩余的三个路由图依次类推。但是和第一例子不同，在本例中，传送管理器中的路线标识符，mapID＝“route1”、mapID＝“route2”等被除去，通过以<transferManager>xfrMgrName1</transferManager>、<transferManager>xfrMgrName2</transferManager>等的形式，直接把传送管理器的名称放入图目的地中，使传送管理器与图路线相联系。第四个传送管理器(名为“xfrMgr4”的传送管理器)在经过适配器的三条路线上被调用，所述三条路线被识别为“route2”、“route4”和“route5”。
创建(220)在适配器简表(202)中识别的传送器(212)和根据配置参数(218)配置(222)传送器(212)在根据本发明的实施例的许多适配器中进行，如图5和5a-5h中陈述的例证类别结构所示。图5图解说明根据本发明的实施例，由其构成适配器的例证类别之间的关系。
如同当适配器被描述成“包含”或“包括”传送器、发送器、接收器或者传送管理器时一样，在本公开中，软件模块常被描述成“包含”其它软件模块。有益的是注意在本公开中经常用于描述本发明的各个例证实施例的面向对象的范例中，一个模块包含或包括另一模块通常意味着第一模块拥有对第二模块的引用(reference)或者指针，如同传送器“具有一个”接收器，意味着所述传送器在其成员数据元素中保持有对接收器对象的引用一样。在C++中，更常见的是把引用管理为对象的指针，不过在本公开中，为了清楚和简洁起见，通过用引用来描述这样的关系。图5中的箭头一般指示面向对象的“has a”关系，即，哪一类别一般拥有对其它类别的引用。
根据图5的例子的适配器(102)具有对简表(202)的引用，不过实际上，简表(202)常常根本不是一个类别对象，而是文件系统中的一个文件。当然，文件系统中的数据的管理大大慢于计算机存储器中的数据的管理，从而根据本发明的实施例的多数适配器(102)于是把简表(102)解析成更便于在运行的软件系统内引用的内部类别对象，这里图解表示成解析的简表类别(502)。适配器(102)例示在简表(202)中识别的传送器(212)和传送管理器(406)。在本例中，传送器(212)例示接收器(312)和发送器(316)，并把对它们的引用返回给适配器，以致适配器也拥有对接收器类别(312)和发送器类别(316)的引用。适配器使用它自己的对接收器的引用来向接收器(312)登记事件监听器(536)在图5中，事件监听器(536)被表示成独立的类别，不过实际上，许多适配器将把适配器自身登记为事件监听器。当接收器(312)收到消息时，接收器把该消息封装在消息事件(504)中，并通过事件监听器把对所述消息事件的引用传回适配器(102)，或者直接传回适配器(如果适配器是事件监听器的话)。适配器把消息事件对象，或者实际上对消息事件对象的引用传递给传送管理器(406)，随后传送给发送器(504)，以便处理所述消息，随后把所述消息发送给其目的地。从而，传送管理器类别(406)，接收器(312)，发送器(316)和适配器(102)都获得对消息事件类别(504)的引用。
再次参考图2，并就图5和5a-5h的类别图表来说，在许多例子中，构成(204)应用集成适配器(这里根据包含描述适配器的数据的简表(202)进行所述构成)由具有与下述例子类似的形式的命令行接口输入启动：
Java com.adapters.Adapter<ProfileName>
该例证的命令指令Java虚拟机装入并例示适配器名称Adapter，并运行其名为“main()”(图5a上的附图标记520)的成员方法。在本公开中，除非另有说明，适配器对象执行的动作或处理步骤的描述一般是在图5a的附图标记(102)图解说明的那种适配器对象中的main()成员方法的操作的描述。在本例中，main()，或者适配器可选地，不过一般通过打开名为“ProfileName”的文件中的简表，并将其以和在图5b的附图标记(502)图解说明的类似的数据结构解析到内部存储器中来继续进行。图5b的解析的简表类别提供传送管理器的列表(542)，包括其配置参数的传送器的列表(544)，和路由图的列表(555)的解析存储。除了所述列表提供的结构化存储器之外，图5b的解析的简表类别还提供用于增加所述列表的成员方法(546、544、555)，和当其它协作对象需要列表时，取回列表的成员方法(550、552、553)。
图5b中，传送管理器的列表(542)，包括其配置参数的传送器的列表(544)，和路由图的列表(555)都被描述成具有数据类型“List”。数据类型的这种描述不是限制性的。本领域的技术人员易于想到，各种数据类型可被用于这样的数据结构，用于在本公开中讨论的所有数据结构，例如包括向量、数组表、集合、容器等。
在根据图2的方法中，构成(214)集成适配器还包括创建(220)在适配器简表(202)中识别的传送器(212)，并根据配置参数(218)配置(222)所述传送器(212)。在本例中，Adapter.main()通过例示在解析的简表(502)中的传送器列表(544)中列举的每个传送器，创建传送器。根据配置参数(218)配置(222)传送器(212)一般包含创建每个传送器的接收器和发送器，并用配置参数配置所述接收器和发送器。
图3是图解说明创建根据本发明的应用集成适配器的传送器的接收器和发送器的方法的数据流程图。在根据图3的方法实现的许多适配器中，每个传送器包含用于创建接收器的参数化工厂方法(图5c上的556)。在这样的实施例中，配置(222)所述传送器包括创建(306)每个传送器的一个接收器，由对利用至少一些配置参数创建接收器的参数化工厂方法(图5c上的556)的调用来实现。在根据图3的方法中，每个传送器一般包括创建一个发送器的工厂方法(图5c上的558)，配置(222)传送器(212)还包括创建(318)每个传送器(212)的一个发送器(316)。
下面是工厂方法的一个说明性伪代码例子：
    //
    //Transport Class
    //
    //Illustrating a parameterized factory method for creating
receiver objects
    //
    class TransportClass
    {
    public static Receiver createReceiver(ConfigParm1，ConfigParm2，
and so on...)
    {
    if(ConfigParm1＝＝HTTP                                       &&
ConfigParm2＝＝INVENTORYCONTROL)
     receiverID＝″receiver1″；
    else                  if(ConfigParm1＝＝IIOP                 &&
ConfigParm2＝＝INVENTORYCONTROL)
       receiverID＝″receiver2″；
    else                if(ConfigParm1＝＝HTTP    &&
ConfigParm2＝＝GENERALLEDGER)
    receiverID＝″receiver3″；
    else                if(ConfigParm1＝＝JMS     &&
ConfigParm2＝＝GENERALLEDGER)
    receiverID＝″receiver4″；
    else                if(ConfigParm1＝＝HTTP    &&
ConfigParm2＝＝PURCHASINGSYSTEM)
    receiverID＝″receiver5″；
    else                if(ConfigParm1＝＝IIOP    &&
ConfigParm2＝＝PURCHASINGSYSTEM)
    receiverID＝″receiver6″；
    Receiver  aReceiver＝null；//empty  reference  for  new  receiver
object
    switch(receiverID)
    {
    case″receiver1″:aReceiver＝new receiver1.class；break；
    case″receiver2″:aReceiver＝new receiver2.class；break；
    ……
    case″receiverN-1″:aReceiver＝new receiver5.class；break；
    case″receiverN″:aReceiver＝new receiver6.class；break；
    }//eud switch()
    return aReceiver；
    }//end createReceiver()
    public static Sender createSender(ConfigParm1，ConfigParm2，
and so on...)
     {
    //Exemplary Transport classes also support factory methodsfor senders
  //similar to the one for receivers set forth just above，
createReceiver().
 }
}//end class TransportClass
在该伪代码例子中，creatReceiver()是参数化工厂方法。creatReceiver()由例如Adapter.main()调用，一组配置参数和为所述调用的参数。creatReceiver()可被过载并利用由工厂方法creatReceiver()中支持的任何接收器类别所支持的配置参数的任意组合调用。creatReceiver()可支持任意数目的具体接收器类别。creatReceiver()通过根据配置参数，经过一系列的IF语句选择接收器标识起作用。creatReceiver()随后根据接收器标识运行switch()语句，以便选择具体的接收器类别，并根据其例示新的接收器对象。
在本例中，名为“Receiver”的类别是所有其它接收器类别可继承的抽象类别，从而使creatReceiver()能够返回类型“Receiver”的引用，该引用事实上是对任何接收器类别对象的引用。于是，从适配器中的协作对象对接收器对象的调用可以是多形态的。这样，传送器，适配器本身，以及包含在适配器内的任何协作对象或软件模块既不知道或关心哪些应用程序正被集成，又不知道或关心哪些通信协议被用于集成这些应用程序。适配器内的对象之中的所有协作相对于应用实体和通信协议，被完全中立、透明和模块化地实施。
图3中图解说明的方法包括向每个接收器登记(310)一个传送器事件监听器。在根据图3的方法创建接收器的一些适配器中，集成适配器(102)本身包含传送器事件监听器(314)。即，在一些实施例中，通过把适配器本身登记为事件监听器完成向每个接收器登记(310)传送器事件监听器。在这样的实施例中，适配器本身将包含用于接收器的要求转交(hand off)输入消息的成员方法，例如在图5a的例证适配器类别(102)中的附图标记(532)所示的transportEvent()方法。在事件监听器(314)是与适配器本身分离的对象的实施例中，构造器首先通过例示事件监听器类别的独立对象，例如在图5a的附图标记(536)图解说明的独立对象，创建(308)传送器事件监听器(314)。
图4是图解说明创建传送管理器的例证方法的数据流程图。在图4的方法中，提供(210)适配器简表(202)包括提供包含一个或多个数据传送管理器(406)的标识(402)，包括数据传送管理器的配置参数(404)的适配器简表。图4的方法包括构成(204)应用集成适配器(102)，构成(204)应用集成适配器(102)又包括创建(408)在简表(202)中识别(402)的传送管理器(406)，和根据配置参数(404)配置(410)传送管理器(406)。
就图5a的例证数据结构来说，适配器(102)包含用于创建传送管理器的名为createTransferManagers()(530)的工厂方法。在本例中，解析的简表类别(502)中的传送管理器列表(542)包含在所述简表中定义的所有传送管理器的定义，以及每个传送管理器的配置参数。构成这样的例证适配器包括利用传送管理器的配置参数为传送管理器列表(542)中的每个传送管理器调用一次用于传送管理器的工厂方法，作为响应接收对新的传送管理器的引用。对新的传送管理器的引用连同它们的属性，比如路由图标识符和调用序号随后被保存在适配器(102)的传送管理器列表(514)中，供适配器在路由消息中使用。
图6是图解说明构成应用集成适配器的方法的调用序列图。更具体地说，图6描述了构成根据本发明的例证实施例的适配器的协作对象中的成员方法之间的例证调用序列。当以类似于下述的命令行输入例示适配器时，开始图6的序列：
Java com.adapter.Adapter<ProfileName>
适配器中的成员方法，或者其构造器或者其main()方法通过调用(622)解析的简表(图5b上的502)中的增加方法(图5b：546、548、549)，解析识别为<ProfileName>的简表。增加方法把传送管理器(542)，传送器(544)和任意路由图(555)的描述插入解析的简表的成员数据元素中。
适配器(102)构成(624)在解析的传送器列表(图5b上的544)中描述的每个传送器。适配器调用构成的每个传送器中的creatReceiver()(626)，每个creatReceiver()调用导致传送器的接收器的构成(628)。每个creatReceiver()调用(626)向适配器返回对创建的接收器的引用。适配器把对每个接收器的引用保存在适配器中的接收器列表(图5a中的516)中，特别供配置接收器和登记事件监听器之用。适配器调用构成的每个传送器中的creatSender()(630)，每个creatSender()调用导致传送器的发送器的构成(632)。每个creatSender()调用(630)向适配器返回创建的发送器的引用。适配器把对每个发送器的引用保存在适配器中的发送器列表(图5a上的518)中，供配置发送器之用和在路由消息中使用。
适配器调用(634)每个接收器(312)中的configure()方法(图5d上的566)，传递接收器配置参数作为调用参数，从而每个接收器能够自我配置。借助对诸如addEventListener()(图5d上的570)之类方法的调用(636)，在其接收器列表中的每个接收器中，适配器把它自己或者另一对象登记为事件监听器。适配器调用(638)每个发送器(316)中的configure()方法(图5e上的584)，传递发送器配置参数作为调用参数，从而每个发送器能够自我配置。
适配器构成(640)在简表中识别的或者在解析的简表(图5b上的502)中的传送器管理器列表(图5b上的542)中识别的每个传送管理器(120)。为了在路由消息中使用，适配器把对每个传送管理器的引用保持在适配器(102)中的传送管理器列表(图5a上的514)中。
适配器调用(641)每个接收器中的run()方法(图5d上的574)，建议每个接收器根据接收器使用的协议开始数据通信操作。在本发明的典型实施例中，一个以上的接收器必须同时运行，从而有利的是，对run()方法(574)的调用是触发执行的新的并行进程或线程，并把控制迅速返回给调用者的非分块调用。更特别地，例如就Java来说，有利的是，在这样的例证实施例中的接收器类别被定义为从“线程”类别继承其start()接口方法。从而在这样的实施例中，对run()方法的调用被实现成对SomeReceiverClass.start()的调用，SomeReceiverClass.start()再在独立的执行线程中执行run()方法，并迅速返回给调用者。下面是一个例子：
class HTTPReceiver extends Thread{
 private Port ListenPort＝80；
 public void run(){
//control code to operate
//a receiver over the HTTP protocol
//for data communication from
//a particular software application
}
}
该例子宣布HTTPReceiver为线程的子类别，并超越出自线程类别的run()方法，在目前的Java中众所周知。下面的例证Java代码从而能够创建一个独立的执行线程并开始其运行：
HTTPReceiver aReceiver＝new HTTPReceiver()；
aReceiver.start()；
这举例说明了把接收器的run()方法实现成一个独立的执行线程的一种特定方法，这只是用于举例说明，而不是对本发明的限制。本领域的技术人员易于想到，为接收器启动独立的执行线程的方式有多种，所有这些方式都在本发明的范围之内。不过一般来说，适配器例示并激活通过使用例如事件监听器，与适配器异步工作(如本公开中下面更详细所述)的任意数目的接收器的方式都是这样。
但是，把接收器的run()方法异步地实现成并行的独立执行线程不是对本发明的所有实施例的一般限制。根据本发明的实施例的一些适配器事实上并不把接收器的run()方法异步地实现成并行的独立执行线程。根据本发明的实施例的一些适配器利用分块调用顺序轮询接收器的run()方法。在这样的实施例中，例如，适配器的main()方法通过对接收器的run()方法的分块调用，依次轮询每个接收器。调用方法的执行暂停，直到对run()方法的调用返回为止。一般在这样的实施例中，接收器的run()方法检查输入消息，根据需要转译任何输入消息的编码格式，把输入消息封装在消息事件对象中，并把对这样创建的任何消息事件对象的引用返回给调用适配器。随后，适配器调用其中接收器列表上的下一接收器。在这样的实施例中，可选并且有利的是，事件监听器可不被使用-或者可和在异步实施例中相比，不太频繁地被使用。
在这一处理时刻，例证的适配器中的已用其配置参数配置自己，并且按照它们的协议开始数据通信操作的接收器正在根据它们的协议工作，准备接收消息，把消息放入消息事件中，并把消息事件转移给事件监听器以便通过适配器处理。即，此时，适配器被构成并且正在运行。
图7是描述通过适配器(102)在应用程序(106、116)中传递(图2上的206)集成消息(208)的例证方法的数据流程图。图7的方法包括从源应用(106)接收(702)具有源消息格式(712)和源数据结构(714)的集成消息(208)。就图5a-5h的例证类别结构来说，出于说明的目的，假定适配器的每个接收器中的run()方法正在根据在每个接收器的配置参数中识别的数据通信协议进行数据通信。
图7的方法包括把集成消息(208)从源消息格式(712)转换(708)成对目的应用(116)有用的目的地消息格式(720)。就图5d的例证类别结构来说，通过从run()方法(574)对接收器类别(560)中的转译方法(575)的调用，执行转译(708)。转译方法(575)的工作是转换消息的格式，而不是转换消息的数据结构。即，转译方法转换消息的整体形式，保留内部数据结构、数据元素名称、类型和值不变。如果需要，转换内部数据结构是传送管理器中的变换方法的工作，而不是接收器或其转译方法的工作。格式转译的例子包括从字符串化的(stringified)Java转换到XML，从二进制C++数据格式转换到XML等等。格式转译的一个特定例子是编程为把下述C结构
struct address
{
 char*name＝″John Smith″；
 char*address＝″100 Main Street″
 char*city＝″Smallville″；
 char*state＝″Iowa″；
 char*zip＝″10101″；
}
转换成下述XML结构的接收器：
<address>
<name>John Smith</name>
<address>100 Main Street</address>
<city>Smallville</city>
<state>Iowa</state>
<zip>10101</zip>
</address>.
这样的接收器通过读取每个C数据元素和创建具有相同名称、类型和值的对应XML元素继续进行。该C结构可以编译的形式，即编码的二进制形式被传送，或者以正如上面所示的未编译文本的形式被传送。到XML的变换保留数据中的所有结构，数据元素的名称、类型和值，只把格式从C变成XML。
实际上，为了支持适配器内的异步操作，实现图7的方法的适配器一般还包括把集成消息封装(704)在消息事件(716)中，并把该消息事件(716)，或者对所述消息事件的引用传送(706)给至少一个事件监听器。在图5h的附图标记(602)图解说明了消息事件的一个例证结构。消息事件类别(602)只包含一个成员方法，一个其唯一的作用是把消息参数记录在消息事件对象中，并把对消息事件的引用返回给调用接收器的构造器(616)。消息事件参数包括这里表示为数据类型“字符串化”(不过本领域的技术人员易于想到任何有用的数据类型)的其目的地(604)，其源(606)，其消息类型(607)，消息识别码(608)，安全标记(610)，状态码(612)，和有用地，消息本身的主体(614)。
在例证的类别结构中，通过从接收器到事件监听器(536)中的transportEvent()方法(图5a上的532)，进行把消息事件(706)传递给事件监听器。transportEvent()方法(532)被表示在图5a上的适配器类别(102)中，另外提示一下，可选的是，适配器把自身登记为事件监听器。从而，使消息事件在任何传送管理器中被传播，并且最终被传播到发送器对象中的send()方法的一般正是事件监听器(或者它自己，或者通过其它协作对象)。在典型的实施例中，发送(710)包括从消息事件中取出集成消息，并重新将其封装到目的地传送器(144)的send()方法(图5e上的592)所使用的数据通信协议所需的消息结构中。
图7的方法还包括把集成消息发送(710)给目的应用(116)，在例证的类别结构中，通过对发送器对象(576)中的send()方法(图5e上的592)的调用来实现。更具体地说，图7的方法不包括任何数据结构变换和到目的格式的任何转译。这意味着在源应用程序和目的应用程序能够利用相同的数据结构工作，但是源应用程序输出呈二进制形式，字符串化Java，C++结构，或者除XML之外的任何形式的数据结构，并且目的应用程序要求以XML形式输入它们的情况下，图7的方法是有用的。
图8是描述通过适配器(102)在应用(106、116)之间传递(图2上的206)集成消息(208)的另一例证方法的数据流程图。图8的方法包括从源应用(106)接收具有源消息格式(712)和源数据结构(714)的集成消息(208)。图8的方法还包括把集成消息(208)从源消息格式(712)转译(802)成可用于适配器内的内部处理的中间消息格式(804)，所述内部处理包括数据变换和安全处理，还包括本领域的技术人员易于想到的其它处理方式。
图8的方法还包括把集成消息(208)从源数据格式(714)变换成目的地数据结构(808)。在数据变换中，与数据转译不同，数据结构被变更，象当来自源应用程序的下述结构
<address>
<lastName>Smith</lastName>
<firstName>John</firstName>
<addressLine1>100 Main Street</addressLine1>
<addressLine2>Suite 5</addressLine2>
<city>Smallville</city>
<state>Iowa</state>
<mailCode>10101</mailCode>
</address>
被转译成目的应用程序所需的下述结构时：
<address>
<name>John Smith</name>
<address>100 Main Street，Suite 5</address>
<city>Smallville</city>
<state>Iowa</state>
<zip>10101</zip>
</address>
对于这两种结构来说，数据格式是相同的，即用于转译的中间格式(在本例中为XML)。但是，在其数据元素名称和值方面，数据结构本身被改变。
在图8的方法的许多例证实施例中，通过传送管理器执行变换(806)。继续以XML作为用于数据转译的中间数据格式的说明性例子：就例证的类别结构来说，通过经由对成员方法，比如process()(图5g上的609)的调用，把messageEvent对象，比如在图5h的附图标记(602)图解说明的携带消息结构(614)以及传送管理器执行转译所需的处理参数的messageEvent对象传递给传送管理器(图5g上的619)，把集成消息(208)从源数据结构(714)变换(806)成目的地数据结构(808)。
在本例中，process(messageEvent)方法(609)使用出自消息事件(602)的源标识(606)和目的地标识(604)根据为此目的保存在传送管理器(619)中的数组表(615)推断XSLT样式表的文件名。process()方法609通过调用XSL处理器(未示出)，传送样式表的名称和输入的XML作为调用参数，继续进行处理。XSL处理器读取输入的XML，并遵循XSL样式表中的指令；随后它把转译的XML作为其回答输出给process()方法。许多XML处理器易于从各个制造商现货获得，例如包括可从Apache Software Foundation获得的公知的“Xalan”XSLT处理器。
图8的方法包括把集成消息发送(710)给目的应用(116)。图8图解说明了发送集成消息的两种例证执行路径。图8公开了直接发送(710)消息，而不存在附加的转译的备选方案(806、208、710)。特别是，当用于变换消息的数据结构的中间消息格式(804)与目的应用程序预期的格式相同时，所述备选方案有用。即，例如，当中间格式(804)是XML，并且目的应用能够接收和使用XML的集成消息时，无附加转译的发送是有用的。
图8还公开了把集成消息(208)从中间消息格式(804)转译(810)成目的应用(116)可用的目的消息格式(812)的备选方案。即，作为一个备选实施例，图8的方法包括在把消息发送(710)给目的应用程序之前，把集成消息(208)从中间消息格式(804)转译(810)成目的应用(116)可用的目的消息格式(812)。这种备选方案可用在目的应用程序预期的消息格式不同于用于适配器内的数据结构变换(806)的中间格式(804)的许多实施例中。这种实施例的例子包括其中中间格式为XML，目的格式为HTML、字符串化Java、二进制C++结构或者除XML之外的任何其它消息格式的那些实施例。
图9是图解说明通过适配器，在应用之间传送(图2上的206)集成消息的方法的调用序列图。更具体地说，图9描述了通过根据本发明的实施例的例证适配器，在应用之间传递集成消息的协作对象中的成员方法之间的例证调用序列。当适配器如上详细所述被例示、构成和运行时，开始图6的序列。适配器的接收器(312)接收消息，并调用(902)它自己的translation()方法(图5d上的575)。translation()方法把消息的主体的格式转译成中间格式。
接收器(312)构成(904)消息事件对象(536，在图5b上的602的类别结构)，当消息在适配器内的对象之间传递时，用作消息的容器，以便进一步处理和传送给其目的地。消息事件对象的构造器接收消息的描述参数作为调用参数以及消息本身的主体，向接收器返回对消息事件对象的引用。
接收器(312)通过对transportEvent()方法(图5a上的532)的调用(906)传递消息事件对象，确切地说，把对消息事件对象的引用传递给在接收器中的事件监听列表(图5d上的564)中列举的事件监听器对象。
事件监听器中的transportEvent()方法通过每个传送管理器中的process()方法(图5f上的618，图5g上的609)，调用(906)在适配器中的传送管理器列表(图5a上的514)中列举的每个传送管理器，传送对消息事件对象的引用作为调用参数。另一方面，transportEvent()方法根据路由图列表推断路由图标识，随后调用推断的路由图标识所识别的每个传送管理器中的process()方法。总之，调用的每个传送管理器依次对消息事件对象中的消息的主体进行每个传送管理器被设计成执行的无论什么处理，例如包括数据结构变换，安全检查，源验证，加密，解密，数字签名的核实，和本领域的技术人员易于想到的其它功能。图5g是为利用XSLT的数据转译优化的具体传送管理器类别的一个例子。图5f是只提供可从其承袭许多具体的传送管理器类别的一个接口的抽象传送管理器类别。利用具体的传送管理器来实现用于各种处理目的的类别(每个所述类别承袭自抽象的传送管理器类别)支持适配器的诸如createTransferManager()(图5a上的532)之类的工厂方法的使用。工厂类别的使用和对照传送管理器列表(514)的transportEvent()(图5a上的532)处理意味着适配器对象本身不必知道也不必关心哪个特定的传送管理器负责任何消息的主体，从而支持适配器内的对象之间相对于消息内容的处理，被中立、透明和模块化地实施的协作。
图9的序列中的transportEvent()方法从适配器中的发送器列表(图5a上的518)中识别出用于消息的目的地的传送器中的发送器，并调用(908)目的发送器(在图5a上的附图标记575图解说明的类别结构)中的send()方法(592)。send()方法根据需要调用(910)发送器中的translate()方法(图5e上的593)，从而使消息主体变成其目的应用所需的形式。随后，send()利用发送器被配置成使用的数据通信协议，把所述消息传送给目的应用。
应用集成适配器的动态变更
图10是图解说明包括根据包含描述适配器(150)的数据的简表(202)，构成(204)应用集成适配器(102)的另一应用集成方法的数据流程图。图10的方法还包括接收(152)改变适配器的指令(156)，和根据指令(156)改变(154)适配器。
根据图10的方法的应用集成适配器类似于本公开中前面描述的其它例证适配器，一般包括数据通信传送器，发送器，接收器，数据传送管理器(可选)等等。但是，根据图10的适配器还包括接收和执行变更它们自己的指令的能力，在它们运行时，作为它们的标准操作的一部分，这样的适配器能够动态地实现这样的变更，而不需要停止、暂停、重新安装或重新启动任何事物。
事实上，图10的方法还包括通过变更后的适配器(103)，在应用(112、106)之间传递(206)集成消息(208)。即，在适配器根据图10的方法被改变之后，适配器正常地继续工作，除了它们现在包括所述变更之外。正常的适配器操作包括接收来自应用的集成消息，根据需要转译消息的格式，由适配器把消息封装在消息事件对象中，通过传送管理器，把消息事件对象发送给发送器，根据需要再次转译格式，和把消息发送给目的地，本公开中前面已详细说明了所有这些操作。
变更会影响所有适配器元件，传送器，接收器，发送器，传送管理器等等。变更会影响受配置参数，电话号码，端口号，网络地址，URI等影响的所有适配器操作。配置参数的一些变化如此显著，以致实际上要求某一组件的整个替换，例如从一种通信协议到另一种通信协议的完全变化。变更可包括这样的变化：向正在运行的适配器增加一个新的传送器，新的接收器，新的发送器，零个或者更多的新的传送管理器，以便支持全新的应用的集成。变更可包括删除或停止现有接收器、发送器或者传送管理器的操作，而适配器的剩余部分继续工作，而不暂停、停止或重新启动。但是，排除暂停、停止或重新启动并不是对本发明的限制。实施例可包括暂停、停止或重新启动，事实上，管理集成消息本身可包括实现适配器的组件或者整个适配器的暂停、停止或重新启动的变更指令。
在图10的方法中，描述适配器的数据(150)包含识别通信协议的数据和识别应用程序的数据。“描述适配器的数据”(150)一般是在简表(202)中陈述的传送器、发送器、接收器、传送管理器、图路线的标识，以及它们的配置参数，这些在本公开中前面已详细说明。在数据通信模块和它们的配置参数都特定于协议的意义上，数据通信模块，发送器和接收器的配置参数是“识别通信协议的数据”。使用HTTP的接收器具有用于配置参数的IP地址和端口号。通过电话线传送文件的发送器具有用于配置参数的文件名和电话号码。诸如此类。类似地，传送器、发送器和接收器的身份和配置参数一般是“识别应用程序的数据”，因为它们也是特定于应用程序的。接收器一般期望接收特定数据格式(具有特定的数据结构)的消息，并且通常这样的特殊性与特定的应用程序相联系。一个传送器、接收器或发送器和一个以上的应用程序一起使用在本发明的范围之内，不过尽管那样，其实现仍然一般应该是特定于应用的，因为需要在简表中规定这种模块的独立实例，并且专用于与应用的特定实例通信。出于所有这些原因，即使在简表中并不出现特定应用或协议本身的名称，然而一般来说，描述适配器的数据(150)一般确实直接或间接地，明确或含蓄地识别通信协议和应用程序。
在根据图10的方法实现的许多适配器中，接收(152)变更适配器(102)的指令(156)包括检测(164)适配器简表(202)中的变化。在许多这样的实施例中，适配器简表是驻留在文件系统的某一路径位置的可编辑文件。在许多实施例中，适配器简表是易于编辑的文本文件，比如XML文件。被授权编辑适配器简表的用户可在任何时候利用文本编辑器或者字处理器编辑这样的文件。事实上，被授权编辑适配器简表的用户可在适配器正在运行时编辑简表，从而创建不再准确描述其适配器的简表。
在这样的实施例中，检测(164)适配器简表(202)中的变化常常还包括创建(158)简表的副本(203)，并定期(162)比较(160)简表(202)和所述副本(162)。即，接收变更适配器的指令的一种方式是适配器自己保持其简表的副本，并定期比较简表的副本与简表本身。如果比较之间，简表发生变化，那么简表中的变化被解释成变更指令。即，在这样的实施例中，简表的变化包含变更指令。
例如，如果在这样的实施例中，简表的副本(203)是：
<adapter>
<transportmodules>
<transport class＝″InventoryControl.java″id＝″inventoryControl″>
<receiver configParms＝″abc″></receiver>
<sender configParms＝″xyz″></sender>
</transport>
<transport class＝″GeneralLedger.java″id＝″generalLedger″>
<receiver configParms＝″def″></receiver>
<sender configParms＝″uvw″></sender>
</transport>
       </transportmodules>
  <transfermodules>
      <transferManager class＝″xfrMgr1.java″
      order＝″1″></transferManager>
      <transferManager class＝″xfrMgr2.java″
      order＝″2″></transferManager>
</transfermodules>
</adapter>
改变后的简表(202)为：
<adapter>
<transportmodules>
<transport class＝″InventoryControl.java″id＝″inventoryControl″>
<receiver configParms＝″abc″></receiver>
<sender configParms＝″xyz″></sender>
</transport>
<transport class＝″GeneralLedger.java″id＝″generalLedger″>
<receiver configParms＝″def″></receiver>
<sender configParms＝″uvw″></sender>
</transport>
<transport class＝″Purchasing.java″id＝″purchasingSystem″>
<receiver configParms＝″ghi″></receiver>
<sender configParms＝″rst″></sender>
</transport>
</transportmodules>
<transfermodules>
<transferManager class＝″xfrMgr1.java″
order＝″1″></transferManager>
<transferManager class＝″xfrMgr2.java″
order＝″2″></transferManager>
<transferManager class＝″xfrMgr2.java″
order＝″3″></transferManager>
</transfermodules>
</adapter>
从而比较之后的检测变化，于是变更适配器的指令(156)是：
<add>
<transportmodules>
<transport class＝″Purchasing.java″id＝″purchasingSystem″>
<receiver configParms＝″ghi″></receiver>
<sender configParms＝″rst″></sender>
</transport>
</transportmodules>
<transfermodules>
<transferManager class＝″xfrMgr2.java″
order＝″3″></transferManager>
</transfermodules>
</add>
对于另一例子来说，如果简表的副本(203)是：
<adapter>
<transportmodules>
<transport class＝″InventoryControl.java″id＝″inventoryControl″>
<receiver configParms＝″abc″></receiver>
<sender configParms＝″xyz″></sender>
</transport>
<transportclass＝″GeneralLedger.java″id＝″generalLedger″>
<receiver configParms＝″def″></receiver>
<sender configParms＝″uvw″></sender>
</transport>
<transport class＝″Purchasing.java″id＝″purchasingSystem″>
<receiverconfigParms＝″ghi″></receiver>
<sender configParms＝″rst″></sender>
</transport>
</transportmodules>
<transfermodules>
<transferManager class＝″xfrMgr1.java″
order＝″1″></transferManager>
<transferManager class＝″xfrMgr2.java″
order＝″2″></transferManager>
<transferManager class＝″xfrMgr2.java″
order＝″3″></transferManager>
</transfermodules>
</adapter>
变化后的简表(202)是：
<adapter>
<transportmodules>
<transport class＝″InventoryControl.java″id＝″inventoryControl″>
<receiver configParms＝″abc″></receiver>
<sender configParms＝″xyz″></sender>
</transport>
<transport class＝″GeneralLedger.java″id＝″generalLedger″>
<receiver configParms＝″def″></receiver>
<sender configParms＝″uvw″></sender>
</transport>
</transportmodules>
<transfermodules>
<transferManager class＝″xfrMgr1.java″
order＝″1″></transferManager>
<transferManager class＝″xfrMgr2.java″
order＝″2″></transferManager>
</transfermodules>
</adapter>
从而比较之后检测到的变化，于是用于变更适配器的指令(156)是：
<delete>
<transportmodules>
<transport class＝″Purchasing.java″id＝″purchasingSystem″>
<receiver configParms＝″ghi″></receiver>
<sender configParms＝″rst″></sender>
</transport>
</transportmodules>
<transfermodules>
<transferManager class＝″xfrMgr2.java″
order＝″3″></transferManager>
</transfermodules>
</delete>
对于另一例子来说，如果简表的副本(203)是：
<adapter>
<transportmodules>
<transport class＝″InventoryControl. java″  id＝″inventoryControl″>
<receiver configParms＝″abc″></receiver>
<sender configParms＝″xyz″></sender>
</transport>
<transport class＝″GeneralLedger.java″id＝″generalLedger″>
<receiver configParms＝“def”></receiver>
<sender configParms＝″uvw″></sender>
</transport>
</transportmodules>
<transfermodules>
<transferManager class＝″xfrMgr1.java″
order＝″1″></transferManager>
<transferManager class＝″xfrMgr2.j ava″
order＝″2″></transferManager>
</transfermodules>
</adapter>
变化后的简表(202)是：
<adapter>
<transportmodules>
<transport class＝″InventoryControl.java″id＝″inventoryControl″>
<receiver configParms＝“jkl”></receiver>
<sender configParms＝“mno”></sender>
</transport>
<transport class＝″GeneralLedger.java″id＝″generalLedger″>
<receiver configParms＝″def″></receiver>
<sender configParms＝″uvw″></sender>
</transport>
</transportmodules>
<transfermodules>
<transferManager class＝″xfrMgr1.java″
order＝″1″></transferManager>
<transferManager class＝″xfrMgr3.java″
order＝″2″></transferManager>
</transfermodules>
</adapter>
从而比较之后检测到的变化，于是用于变更适配器的指令(156)是：
<changeParms>
<transportmodules>
<transport class＝″InventoryControl.java″id＝″inventoryControl″>
<receiver configParms＝″jkl″></receiver>
<sender configParms＝″mno″></sender>
</transport>
</transportmodules>
</changeParms>
<delete>
<transfermodules>
<transferManager class＝″xfrMgr2.java″order＝″2″></transferManager>
</transfermodules>
</delete>
<add>
<transfermodules>
<transferManager class＝″xfrMgr3.java″order＝″2″></transferManager>
</transfermodules>
</add>
变更适配器的指令的该例子包括改变用于库存管理应用程序的发送器和接收器的操作参数的指令。可通过对配置方法，例如在图5d的附图标记(566)所示的用于接收器的配置方法，在图5e的附图标记(584)所示的用于发送器的配置方法，和在图5f和5g的附图标记(621)所示的用于传送管理器的配置方法的额外调用，完成参数的改变。从而例如对于通过HTTP实现数据通信的发送器和接收器，参数改变可包括端口号和IP地址的改变。
另外，本公开中刚刚在上面的例证变更指令包括删除具体化为Java类别xfrMgr2.java的传送管理器，并用具体化为Java类别xfrMgr3.java的传送管理器来代替。通过使用和用下述伪代码描述的类似的变化检测器类别，实现这样的删除：
Class ChangeDetector extends Thread{
private StringaProfile，aCopy；
private String instructionsForAlterations；
         private AdaptermyAdapter；
    public void setAProfile()；
         public void setMyAdapter()；
         public void run(){
         while(1){//run forever
     aCopy＝createCopy(aProfile)；
     sleep(60,000)；//wait a minute:60,000 milliseconds
     instructionsForAlterations＝compare(aProfile，aCopy)；
     alter(Adapter myAdapter，String instructionsForAlterations)；
}
     }
}
该例证伪代码宣布ChangeDetector为线程的子类别，并超越出自线程类别的run()方法，从而变化检测器能够在适配器内异步工作，当变化出现时检测变化，或者在本例中，至少在变化出现后的一分钟内检测变化。一般从适配器对象(图5a上的520)中的main()方法或者甚至从适配器的构造器调用的下述例证Java伪代码随后能够创建变化检测器的独立的执行线程，并开始其运行：
ChangeDetector aChangeDetector＝newChangeDetector()；
aChangeDetector.start()；
这样的变化检测器对象能够通过其构造器或者通过诸如setAProfile()之类的存取器方法，获得对简表的文件名的引用。变化检测器对象的这个例子同样从其构造器或者通过诸如setMyAdapter()之类的存取器方法，获得对其适配器的引用。借助下述例证伪代码，可从Adapter.main()调用存取器方法：
aChangeDetector.setAProfile(String profileFilename)；
aChangeDetector.setMyAdapter(Adapter myAdapter)；
图10的方法包括根据指令(156)变更(154)适配器。可如上面陈述的包含对下述例证方法的调用的伪代码变化检测器类别中所示，实现适配器的变更：
alter(Adapter myAdapter，String instructionForAlteration)；
该alter()方法接受对适配器的引用以及包含变更适配器的指令的字符串作为调用参数。本例中的alter()方法被编程为根据变更适配器，以便创建新的适配器组件，删除现有的适配器组件，或者改变现有适配器组件的操作参数的指令工作。
在一些实施例中，类似于alter()例子的方法按照本公开中上面所述的构成适配器的类似方式，创建新的适配器组件。即，在根据下述变更指令变更适配器的过程中：
<add>
<transportmodules>
<transport class＝″Purchasing.java″id＝″purchasingSystem″>
<receiver configParms＝″ghi″></receiver>
<sender configParms＝″rst″></sender>
</transport>
</transportmodules>
<transfermodules>
<transferManager class＝″xfrMgr2.java″
order＝″3″></transferManager>
</transfermodules>
</add>
类似于alter()例子的方法例示类别Purchasing.java的传送器对象，例示接收器，用配置参数“ghi”配置接收器，在适配器的接收器列表中列举该接收器，通过对传送器中的工厂方法的调用，例示发送器，用配置参数“rst”配置该发送器，在适配器的发送器列表中列举该发送器，例示类别xfrMgr2.java的传送管理器，在适配器的传送管理器列表中列举该传送管理器等等。
在一些实施例中，类似于alter()例子的方法通过调用组件自身中的成员方法，删除现有的适配器组件。即，在根据下述变更指令变更适配器的过程中：
<delete>
<transportmodules>
<transport class＝″Purchasing.java″id＝″purchasingSystem″>
<receiver configParms＝″ghi″  id＝″revl″></receiver>
<sender configParms＝″rst″  id＝″sndl″></sender>
</transport>
</transportmodules>
<transfermodules>
<transferManager class＝″xfrMgr2.java″id＝′xfrMgr2″
order＝″3″></transferManager>
</transfermodules>
</delete>
类似于alter()例子的方法一般调用适配器自身中的存取器方法。记住在根据本发明的许多例证适配器中，Adapter.main()通过利用保存在适配器自身内的列表(图5a上的514、516、518)识别接收器、发送器和传送管理器，来完成其处理。如果某一传送管理器，接收器或者发送器从列表中被除去，那么适配器不再知道该传送管理器、接收器或者发送器存在。是Java中，无用单元收集将除去不使用的对象。在C++中，删除方法理应还需要调用破坏器来除去不使用的对象。在独立的执行线程中工作的异步接收器还需要使它们的线程被停止。
更具体地说，在本例中，alter()方法被编程为调用Adapter.deletesender(String″snd1″)(图5a上的256)来删除发送器。deletesender()方法被编程为在其发送器列表(图5a上的518)中查找名为“snd1”的发送器，并从所述列表中除去该发送器。在Java中，that is all there is to it。Java无用单元收集将清除不使用的发送器对象。在C++中，deletesender()会从发送器列表获得对发送器的引用，调用该发送器的构造器，并从发送器列表中除去该发送器。在这样的例证实施例中，按照相同的方式删除传送管理器：alter()调用deleteTransferManager(String“xfrMgr2”)(图5a上的252)，deleteTransferManager()又通过调用传送管理器的破坏器(如果需要)，从传送管理器列表(514)中除去该传送管理器。
被轮询的接收器按照相同的方式被删除，但是在独立的执行线程中工作的异步接收器最好还使它们的线程也被停止。承袭自Java的“Thread”类别的Java对象包括突然中断Java线程的操作的stop()方法。也可通过在Java线程中包括通过设置某一成员标记，用信号通知需要停止，从而这样的对象中的run()方法能够定期检查所述标记，检测需要停止，并有序地从run()方法返回的独立方法，来停止Java线程。
在本发明的范围中，有一种以上的接收变更适配器的指令的方法。图11是图解说明应用集成的另一例证方法的数据流程图，其中接收(152)变更适配器(102)的指令(156)包含从应用程序(107)接收承载变更适配器的指令(156)的管理集成消息(170)。
发送管理消息的应用程序可以是编程为支持管理消息的任何应用程序，例如当它自己启动时，通过HTTP传送包括路线绘制指令的XML消息的新应用程序，所述XML消息请求把一个或多个传送器，一个或多个接收器，一个或多个发送器，以及零个或更多的传送管理器加入适配器中，以便支持所述新应用程序与一个或多个其它应用程序的集成。由于这样的新应用程序还不具有它自己的发送消息的接收器，因此一些实施例提供专用于监听管理消息的接收器的网络地址并使之公用。在新的应用程序已与它自己的接收器耦接之后，新的应用程序随后能够把它自己的管理消息直接发送给适配器中它自己的接收器。
为了进一步说明图11的方法，接收例程(152)被认为被实现成与在图5a的附图标记(560)所示的类似的接收器类别的接收器对象中的run()方法(图5d上的574)，承袭自Java的“Thread”类别，同时所述run()方法在它自己的执行线程中异步工作。该例证的接收器非常类似于任何其它消息地管理管理集成消息(170)。即，该例证接收器如同本公开中上面更详细描述的异步接收器那样工作，接收消息，根据需要转换消息的格式，把消息封装到消息事件中，把消息事件传送给事件监听器等等。但是，管理集成消息在接收器对它们的处理方面是不同的，因为接收器在消息事件对象的messageType字段(图5h上的607)中写入把它们识别成管理集成消息的代码值，例如诸如“admin”之类的值。另外，接收器在这样的消息的消息事件对象的destintionID字段(图5h上的604)中写入消息的目的地是适配器本身，而不是目的应用程序的指示。接收器把变更适配器的指令保存为消息事件对象中的消息的主体(614)。如同对于其它消息类型那样，接收器通过调用在接收器中登记的事件监听器(图5d上的564)中的transportEvent(meaasgeEvent)方法(图5a上的532)，传送对消息事件对象的引用。
在本例中，已获得消息事件中的管理消息的源、目的地和类型的transportEvent()方法根据源、目的地和消息类型值，能够识别消息事件的路由图，并把携带变更适配器的指令的消息事件发送给一个或多个传送管理器，如同对于任何其它消息所做的那样。传送管理器可被编程并组织到某一路线中，以便执行变更适配器，创建新组件，删除或改变现有组件的参数等的细节。
作为对使用传送管理来实现适配器的变更的一种备选方案，在一些实施例中，transportEvent()方法被编程为注意传送给它的消息事件的消息类型代码，并把管理消息转给用于执行变更适配器的指令的成员方法，例如按照和上面关于类别ChangeDetector中的alter()所述类似的方式工作的成员方法alter()(图5a上的258)。即，如下所示，Adaper.alter()可被transportEvent()调用：
Adapter.alter(MessageEvent aMessageEvent)；
Adapter.alter()的操作稍微不同于ChangeDetector.alter()。ChangeDetector.alter()接受对适配器的引用和包含变更适配器的指令的字符串作为调用参数。但是，Adapter.alter()是要被变更的适配器的适配器对象内的成员方法，因此不需要接受对适配器的引用作为调用参数。另外，事件监听器中的transportEvent()方法只被编程为转移管理消息事件，而不进一步处理管理消息事件。于是在本例中，transportEvent()方法不抽取消息主体，即变更适配器的指令，和将其传送给Adapter.alter()作为String。相反，transportEvent()方法把整个消息事件传送给Adapter.alter()，保留整个消息事件一直到Adapter.alter()从消息事件对象中抽取消息的主体作为包含变更适配器的指令的String为止。但是，除了这些例外，Adapter.alter()的操作与本公开中前面详细描述的ChangeDetector.alter()的操作类似。即，Adapter.alter()方法被编程为根据变更适配器的指令操作，以便创建新的适配器组件，删除现有的适配器组件，或者改变现有适配器组件的操作参数，如同本公开中前面关于ChangeDetector.alter()详细说明的那样。
管理消息的接收器可被轮询，另外是异步的。在典型的轮询实施例中，不存在事件监听器，也可不存在transportEvent()方法。相反，接收器中的run()方法会直接把消息事件返回给轮询例程，在本例中，适配器中的main()方法(图5a上的520)。轮询例程会注意messageEvent.messageType＝″admin″，并把消息事件传送给alter()方法(图5a上的258)，以便根据封装在消息事件的主体String(图5h上的614)中的指令，进行对适配器的变更。
在根据图11的适配器中，根据指令(156)变更(154)适配器一般还包括更新(172)简表(202)以反映所述指令，从而简表保持变更后的适配器的当前的正确描述。在使用XML文档作为简表中的实施例中，可通过文本编辑器或者字处理器手动进行更新。另一方面，对于这样的实施例来说，常常通过编程为把变更简表的指令，以及旧简表结合成一个更新后的简表，一个新的XML文档的update()方法，使更新自动化。在把解析的简表(图5b上的502)保存在工作存储器中的实施例中，变更(154)适配器常常包括把更新后的简表解析(图5a上的522)解析成工作存储器中的解析简表，从而解析简表也和描述根据指令(156)变更后的适配器组件的当前正确的内容一起被保存。

Claims (12)

1、一种应用集成方法，所述方法包括：
根据包含描述应用集成适配器的数据的简表，构成所述适配器；
接收变更所述适配器的指令，其中接收变更所述适配器的指令还包括检测所述适配器简表中的变化；和
根据所述指令变更所述适配器。
2、按照权利要求1所述的方法，其中应用集成适配器包括：
数据通信传送器，所述数据通信传送器包括发送器和接收器，和
可选的数据传送管理器。
3、按照权利要求1所述的方法，其中描述所述适配器的数据包括：
识别通信协议的数据，和
识别应用程序的数据。
4、按照权利要求1所述的方法，还包括通过变更后的适配器，在应用之间传递集成消息。
5、按照权利要求1所述的方法，其中检测所述适配器简表中的变化还包括：
创建所述简表的副本；和
定期比较所述简表和所述副本。
6、按照权利要求1所述的方法，其中接收变更所述适配器的指令还包括从应用接收承载变更所述适配器的指令的管理集成消息。
7、按照权利要求6所述的方法，其中根据指令变更所述适配器还包括更新所述简表。
8、一种应用集成系统，所述系统包括：
根据包含描述应用集成适配器的数据的简表，构成所述适配器的装置；
接收变更所述适配器的指令的装置，其中接收变更适配器的指令的装置还包括检测适配器简表中的变化的装置；和
根据所述指令变更所述适配器的装置。
9、按照权利要求8所述的系统，其中所述应用集成适配器包括：
数据通信传送器，所述数据通信传送器包括发送器和接收器，和可选的数据传送管理器。
10、按照权利要求8所述的系统，其中描述适配器的数据包括：
识别通信协议的数据，和
识别应用程序的数据。
11、按照权利要求8所述的系统，还包括通过变更后的适配器，在应用之间传递集成消息的装置。
12、按照权利要求8所述的系统，其中检测适配器简表中的变化的装置还包括：
创建简表的副本的装置；和
定期比较所述简表和所述副本的装置。
CNB2004800053624A 2003-02-26 2004-02-13 应用集成方法以及应用集成系统 Expired - Lifetime CN100353315C (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US10/375,815 2003-02-26
US10/375,815 US7895589B2 (en) 2003-02-26 2003-02-26 Dynamic data-driven application integration adapters

Publications (2)

Publication Number Publication Date
CN1754148A CN1754148A (zh) 2006-03-29
CN100353315C true CN100353315C (zh) 2007-12-05

Family

ID=32869042

Family Applications (1)

Application Number Title Priority Date Filing Date
CNB2004800053624A Expired - Lifetime CN100353315C (zh) 2003-02-26 2004-02-13 应用集成方法以及应用集成系统

Country Status (7)

Country Link
US (1) US7895589B2 (zh)
EP (1) EP1597669A2 (zh)
KR (1) KR100877942B1 (zh)
CN (1) CN100353315C (zh)
CA (1) CA2512432C (zh)
TW (1) TWI312469B (zh)
WO (1) WO2004077201A2 (zh)

Families Citing this family (40)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7310659B1 (en) * 2003-06-27 2007-12-18 Sprint Communications Company L.P. Interface and method for extending a target application over an instant message link of a communication network
US7716675B2 (en) * 2003-08-28 2010-05-11 Siebel Systems, Inc. Cross-reference service
US7685603B2 (en) * 2003-09-08 2010-03-23 Sap Ag Selecting client adapters
EP1678606A2 (en) * 2003-09-17 2006-07-12 Research In Motion Limited System and method for management of mutating applications
US8453196B2 (en) * 2003-10-14 2013-05-28 Salesforce.Com, Inc. Policy management in an interoperability network
US8775654B2 (en) * 2003-12-19 2014-07-08 Salesforce.Com, Inc. Apparatus and methods for mediating messages
US7739351B2 (en) * 2004-03-23 2010-06-15 Salesforce.Com, Inc. Synchronous interface to asynchronous processes
US7422152B2 (en) 2004-05-13 2008-09-09 Cisco Technology, Inc. Methods and devices for providing scalable RFID networks
US7802007B2 (en) 2004-05-19 2010-09-21 Salesforce.Com, Inc. Techniques for providing connections to services in a network environment
US7676791B2 (en) * 2004-07-09 2010-03-09 Microsoft Corporation Implementation of concurrent programs in object-oriented languages
US7725605B2 (en) 2004-08-06 2010-05-25 Salesforce.Com, Inc. Providing on-demand access to services in a wide area network
US7509431B2 (en) * 2004-11-17 2009-03-24 Cisco Technology, Inc. Performing message and transformation adapter functions in a network element on behalf of an application
US8458467B2 (en) * 2005-06-21 2013-06-04 Cisco Technology, Inc. Method and apparatus for adaptive application message payload content transformation in a network infrastructure element
US7664879B2 (en) * 2004-11-23 2010-02-16 Cisco Technology, Inc. Caching content and state data at a network element
US7987272B2 (en) 2004-12-06 2011-07-26 Cisco Technology, Inc. Performing message payload processing functions in a network element on behalf of an application
US7725934B2 (en) * 2004-12-07 2010-05-25 Cisco Technology, Inc. Network and application attack protection based on application layer message inspection
US7496750B2 (en) * 2004-12-07 2009-02-24 Cisco Technology, Inc. Performing security functions on a message payload in a network element
US8082304B2 (en) 2004-12-10 2011-12-20 Cisco Technology, Inc. Guaranteed delivery of application layer messages by a network element
US7606267B2 (en) * 2004-12-10 2009-10-20 Cisco Technology, Inc. Reducing the sizes of application layer messages in a network element
US7551567B2 (en) * 2005-01-05 2009-06-23 Cisco Technology, Inc. Interpreting an application message at a network element using sampling and heuristics
US20060155862A1 (en) * 2005-01-06 2006-07-13 Hari Kathi Data traffic load balancing based on application layer messages
US7698416B2 (en) * 2005-01-25 2010-04-13 Cisco Technology, Inc. Application layer message-based server failover management by a network element
US20060187849A1 (en) * 2005-02-22 2006-08-24 Mohamed Hamedi Interpreter engine
US20060209884A1 (en) * 2005-03-15 2006-09-21 Macmullan Samuel J System, method and apparatus for automatic detection and automatic connection between a generalized content source and a generalized content sink
US20060209892A1 (en) * 2005-03-15 2006-09-21 Radiospire Networks, Inc. System, method and apparatus for wirelessly providing a display data channel between a generalized content source and a generalized content sink
US20060212911A1 (en) * 2005-03-15 2006-09-21 Radiospire Networks, Inc. System, method and apparatus for wireless delivery of analog media from a media source to a media sink
US20060209890A1 (en) * 2005-03-15 2006-09-21 Radiospire Networks, Inc. System, method and apparatus for placing training information within a digital media frame for wireless transmission
US8266327B2 (en) * 2005-06-21 2012-09-11 Cisco Technology, Inc. Identity brokering in a network element
CN101243319B (zh) * 2005-06-22 2016-01-06 约翰·霍普金斯大学 卵巢癌的生物标记：ctap3-相关蛋白质
US7345585B2 (en) 2005-08-01 2008-03-18 Cisco Technology, Inc. Network based device for providing RFID middleware functionality
US7797406B2 (en) * 2006-07-27 2010-09-14 Cisco Technology, Inc. Applying quality of service to application messages in network elements based on roles and status
US8250524B2 (en) * 2007-12-21 2012-08-21 Microsoft Corporation Contract programming for code error reduction
US7817636B2 (en) 2008-01-30 2010-10-19 Cisco Technology, Inc. Obtaining information on forwarding decisions for a packet flow
US8539468B2 (en) * 2008-02-18 2013-09-17 International Business Machines Corporation System and methods for replacing software application classes using transparent object adapters
US20130073977A1 (en) * 2010-04-01 2013-03-21 Evan Foote Bulk udta control gui
CN102346685B (zh) 2010-07-29 2016-09-28 甲骨文国际公司 集成适配器管理系统和方法
JP5942446B2 (ja) * 2012-02-01 2016-06-29 オムロン株式会社 サポート装置およびサポートプログラム
US10262377B2 (en) * 2013-09-13 2019-04-16 Mace Engineering Group Pty Ltd. Sales order data collection and management system
US10324772B2 (en) 2016-11-02 2019-06-18 Oracle International Corporation Method and system for data instance-based automatic message map construction
US20220279047A1 (en) * 2020-01-16 2022-09-01 Padi, Inc. Methods of connecting client/server application instances in distributed networks using connection profiles, related systems and articles of manufacture

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1294710A (zh) * 1998-11-18 2001-05-09 Saga软件有限公司 可扩充的分布企业应用集成系统
US6256676B1 (en) * 1998-11-18 2001-07-03 Saga Software, Inc. Agent-adapter architecture for use in enterprise application integration systems

Family Cites Families (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CA2240194C (en) 1995-12-15 2003-06-03 Object Dynamics Corp. Method and system for constructing software components and systems as assemblies of independent parts
US5923879A (en) 1997-07-02 1999-07-13 Ncr Corporation Conversion system and method between corba and c/c++ architectures for corba data pairs/couples
US6499036B1 (en) 1998-08-12 2002-12-24 Bank Of America Corporation Method and apparatus for data item movement between disparate sources and hierarchical, object-oriented representation
US6467088B1 (en) * 1999-06-30 2002-10-15 Koninklijke Philips Electronics N.V. Reconfiguration manager for controlling upgrades of electronic devices
EP1428142A2 (en) 2000-03-22 2004-06-16 Sidestep, Inc. Method and apparatus for dynamic information connection engine
US20020116454A1 (en) 2000-12-21 2002-08-22 William Dyla System and method for providing communication among legacy systems using web objects for legacy functions
US6792431B2 (en) 2001-05-07 2004-09-14 Anadarko Petroleum Corporation Method, system, and product for data integration through a dynamic common model
US6745208B2 (en) 2001-05-31 2004-06-01 International Business Machines Corporation Method and apparatus for synchronizing an XML document with its object model
FI114581B (fi) * 2003-02-17 2004-11-15 Nokia Corp Ohjelmistokehitysympäristö

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1294710A (zh) * 1998-11-18 2001-05-09 Saga软件有限公司 可扩充的分布企业应用集成系统
US6256676B1 (en) * 1998-11-18 2001-07-03 Saga Software, Inc. Agent-adapter architecture for use in enterprise application integration systems

Also Published As

Publication number Publication date
CA2512432C (en) 2013-02-05
KR100877942B1 (ko) 2009-01-12
US7895589B2 (en) 2011-02-22
WO2004077201A3 (en) 2005-06-23
CA2512432A1 (en) 2004-09-10
CN1754148A (zh) 2006-03-29
WO2004077201A2 (en) 2004-09-10
US20040167986A1 (en) 2004-08-26
KR20060012260A (ko) 2006-02-07
TWI312469B (en) 2009-07-21
TW200504523A (en) 2005-02-01
EP1597669A2 (en) 2005-11-23

Similar Documents

Publication Publication Date Title
CN100353315C (zh) 应用集成方法以及应用集成系统
US7188345B2 (en) Installation of data-driven business integration adapters
US7191450B2 (en) Data-driven application integration adapters
KR100795765B1 (ko) 사용자 인터페이스와 데이터 컴포넌트 간의 지능형 맵핑을이용한 무선 애플리케이션 구축 시스템 및 방법
US6985939B2 (en) Building distributed software services as aggregations of other services
US8589594B2 (en) Programmatic management of software resources in a content framework environment
US8219970B2 (en) XML push and remote execution of a wireless applications
US20030037181A1 (en) Method and apparatus for providing process-container platforms
US20050182768A1 (en) Web browser as web service server in interaction with business process engine
US7343554B2 (en) Mechanisms for supporting back button function of web browser as web service server in interaction with business process engine
US20020147745A1 (en) Method and apparatus for document markup language driven server
EP1914631A1 (en) Method and apparatus for interacting with a web service
CN101883084A (zh) 用于对网络服务通信进行适配的方法、适配器和适配器系统
KR100818296B1 (ko) 무선 인식을 이용한 우편기기 관리 시스템 및 방법
CN113157523B (zh) 服务监控方法、装置、计算机设备及存储介质
US20050198394A1 (en) Data conversion from HTML to XML in a tree structure
Nurmilaakso et al. XML‐based supply chain integration: a case study
Spiess et al. Going beyond auto‐ID: a service‐oriented smart items infrastructure
Oladosu et al. ON THE USE OF WEB SERVICES TECHNOLOGY IN E-HEALTH APPLICATIONS.
Mintchell OPC integrates the factory floor
JP5211417B2 (ja) 携帯端末装置及びそれらに用いるＷｅｂコンテンツ間変数引継ぎ方法並びにそのプログラム
EP1673701A2 (en) Web browser as web service server
Utomo et al. Databases Integration through a Web Services Orchestration with BPEL using Java Business Integration.
JP2006318042A (ja) カスタマイズされたウェブサービスの構造

Legal Events

Date Code Title Description
C06 Publication
PB01 Publication
C10 Entry into substantive examination
SE01 Entry into force of request for substantive examination
C14 Grant of patent or utility model
GR01 Patent grant
ASS Succession or assignment of patent right

Owner name: GOOGLE INC.

Free format text: FORMER OWNER: INTERNATIONAL BUSINESS MACHINES CORP.

Effective date: 20120503

C41 Transfer of patent application or patent right or utility model
TR01 Transfer of patent right

Effective date of registration: 20120503

Address after: American California

Patentee after: GOOGLE Inc.

Address before: American New York

Patentee before: International Business Machines Corp.

CP01 Change in the name or title of a patent holder
CP01 Change in the name or title of a patent holder

Address after: American California

Patentee after: Google Inc.

Address before: American California

Patentee before: Google Inc.

CX01 Expiry of patent term

Granted publication date: 20071205

CX01 Expiry of patent term