交换基础设施系统和方法 技术领域
以下对于本发明的说明涉及企业系统和相关体系架构，以及用于协作业务流程的技术。
背景技术
公司面临在其信息及企业软件系统中进行集成和协作的增长需求。在多数当前系统景观展现中，很多组件(component)与其它组件以一对一的关系直接连接起来，其中各种集成性能靠硬件链接到各个应用程序组件和各个单一映射程序。在这些条件下，协作共享信息或过程控制就很困难甚至是不可能的。升级、改变或扩展成直接连接组件的基础设施是具有挑战性并且是资源密集型的。
但是，新的电子业务协作一般地要求在公司范围内外的所有应用程序的可连接性。象因特网这样的网络为各个系统提供与其它系统和个人之间即时通信的机会。曾经被限制于各个企业内部网及它们的用户的业务流程如今已转到了因特网上，并变成Web服务的有效组成部分。Web服务是可编程、自主型、自述型的模块化应用程序功能，能够通过开放的因特网标准被发布、发现或调用。
诸如提供链路计划、资源寻求和需求预测等的流程在跨企业和区域范围内已经自动化了，并且仅以少量的通信成本就可以跨系统实现。为达到该目的，来自不同卖方的组件在理想情况下应该被集成到一致的基础设施中。但是，现有企业软件地全面系统升级或在异类系统景观中大规模地替换策略趋于过高的成本，或者以时间和资本资源成本来看不是简单易行的。
尽管使用公开的协议和标准，如超文本传输协议(HTTP)和可扩展标记语言(XML)提供技术上的可连接性，仍然有映射不同商业语义的挑战。为获得未来多循环的效率增长，不断要求企业开拓新型的跨企业的使用业务流程或企业内部的多种功能。另外，企业会不断地需要处理实时计划说明来代替执行批量处理。这些协作处理比传统处理具有明显地更为复杂的集成需求。
发明内容
本文公开了有助于集成业务流程工具和应用程序的交换系统和方法。一方面，提供了用于集成软件组件的异类集合的系统。该系统包括知识库，用于保存多个软件组件的设计时间协作描述。该系统还包括目录，用于保存描述运行时间系统景观(landscape)的具体构成协作描述。运行时间系统景观包括在知识库中描述的软件组件的至少一部分。具体构成描述可以至少部分地基于知识库的设计时间描述，并加上执行基于消息的信息交换所需要的具体构成信息。
设计时间协作描述包括业务场景(scenario)、业务流程、路由对象、消息转换映射和软件组件的消息界面。具体构成协作描述包括用于在运行时间系统景观中的每个软件组件的业务场景、业务流程、路由对象、消息转换映射以及消息界面的运行时间描述。还公开了系统景观目录。系统景观目录包括软件组件的设计时间描述，还有运行时间系统景观的具体构成描述。
还公开了集成软件组件的异类集合的方法。在该方法中，多个软件组件的设计时间协作描述被保存在知识库中。然后，根据设计时间描述来产生运行时间系统景观的具体构成协作描述。具体构成协作描述被保存在一个目录中。依据由企业建立的一个或多个业务流程，运行时间引擎可以访问目录以执行基于消息的信息交换。在该方法中，每个消息的接受者不需要具体化，但是，至少部分地依据每个消息的内容和由目录提供的参数来执行业务流程。
一种用于集成软件组件的异类集合的方法，包括在经交换基础设施(XI)连接的运行时间系统景观中的软件组件之间交换消息。该方法包括从发送应用程序中接收消息，并根据路由规则确定消息的逻辑接收应用程序，其中路由规则是依据保存在目录中的具体构成协作描述而定义的。该方法还包括将消息从与发送应用程序相关的出口界面描述映射到与接收应用程序相关的入口界面描述。因此，至少部分地根据消息的内容和由该目录提供的参数，揭示了用于解析与接收应用程序相关物理地址的方法。
在以下的附图和描述中提出了一种或多种实施方式的详细描述，从发明说明书和附图以及从权利要求中，其它的特点和优点会很明显。
附图说明
将参考以下的附图对这些和其它方面进行描述。
图1是用于集成的、基于消息协作的交换系统的简化框图。
图2是交换基础设施的详细框图。
图3是包括交换基础设施的系统景观的详细框图。
图4是集成知识库、集成目录和系统景观目录的详细框图。
图5是运行时间引擎的运行时间环境和集成目录的信息源的详细框图。
图6是描述在两个应用程序之间进行单个消息通信处理的框图。
图7是通过交换基础设施集成软件组件的异类集合的方法的流程图。
图8是通过交换基础设施的运行时间引擎所执行的交换消息的方法的流程图。
具体实施方式
在此描述的系统和技术是与各种处理组件之间协作处理的交换基础设施相关的。
图1基于交换的集成的系统100简化框图。系统100包括交换基础设施(XI)110，用于在企业的内部组件(IC)102之间，以及在通过防火墙105与一个或多个IC 102通信的外部组件(EC)104之间协作处理。IC 102和EC 104代表多个流程或服务以及它们的软件和硬件中的任意一个，如Web入口，购买或销售程序、电子邮件、业务管理程序、目标计划程序等，最好是基于Web的应用程序。每个IC 102/EC 104依据多个通信协议或标准中的至少一个与一个或多个其它组件通信。
XI 110是自主型、模块化的交易平台，用于驱动组件102、104之间的协作。交换基础设施110包括保存共享协作知识的中央集成知识库和目录。XI 110支持开放标准，如各种标准标记语言，象可扩展标记语言(XML)，Web服务描述语言(WSDL)，以及简单对象访问协议(SOAP)，以提供用于组件102、104，以及在异类组件界面之间基于消息的通信的技术界面的抽象。XI 110的自主型、模块化功能可以被提供作为基于标准因特网技术的一个或多个Web服务，并因此能在使用开放标准的组件102、104的网络内部被发布、发现和访问。
图2是XI 110的框图。总体上，XI 110包括集成知识库202、集成目录204、系统景观目录203和集成服务器206。集成知识库202捕捉关于使用XI 110相互之间协作的软件组件的设计时间协作信息。集成目录204捕捉运行时间协作描述，它包括保存和访问外部组件的实际组件安装加上连接描述，所有这些代表运行时间系统景观的共享商业语义。软件组件的设计时间和运行时间描述被保存在系统景观目录203中。在运行时，集成服务器206使用来自集成目录204的共享商业语义，以在运行时间系统景观中的有效软件组件之间执行协作处理和消息交换。
集成服务器206包括在运行时间提供消息和业务过程控制的运行时间引擎214，用于连接服务和管理价值链的处理流程。集成服务器206还包括一般要求具体应用程序实现的其它交换服务216。交换服务216包括分析学和主文件数据服务。交换服务器216可以在系统景观内访问所有的业务文档。对于每个企业，专有以及第三方组件包括基于Web的应用程序，通过多个适配器209之一与集成服务器通信。
如集成知识库202和集成目录204那样，集成服务器206被配置成在任何现有系统基础设施内部使用。集成服务器206可以是专用服务器，在运行时间协作环境中，在所支持系统景观的集成目录204中应用共享的协作描述。运行时间工作台208包括监视应用程序，以使组织或用户可靠而有效地管理XI 110的操作。
图3是包括XI 110的系统景观200的框图。XI 110包括被配置成用来在集成服务器206和专有应用程序211、基于Web的服务213，以及第三方应用程序215之间提供连接的各种适配器209。例如，XI 110还可以包括Web应用服务器210，以提供基于Web的应用程序，该基于Web的应用程序是使用特定的Web编程语言，如Java和先进的商业应用编程(ABAP)语言，并依据标准的计算平台来编程的。Web应用服务器210还包括运行时间引擎214，用来在基于Web的应用程序如Java应用程序220、ABAP应用程序222和/或其它软件组件之间，提供消息通知和业务过程控制。
利用XI 110，可以为使用代理程序(proxy)的任何应用程序定义新的界面。代理程序隐藏了应用程序中的通信技术堆栈，并为该应用程序提供依赖于编程语言的界面。从而，可以在本地利用XI 110实现应用程序的界面，并且代理程序可以实现所有通信步骤，并消除从XI 110到新的界面实现低级通信的需要。
根据保存在集成知识库202中信息的代理程序产生器218可以按需要产生代理程序。代理程序产生器218利用经标准的基于Web的语言，如WSDL或XML模式所描述的界面信息在应用程序开发系统中创建平台和创建依赖于编程语言的代码。根据代表基于web应用程序213的相应开发平台，如Java、ABAP和.NET，的界面描述的代理程序，可实现通信逻辑。这些代理程序将具体平台数据类型转换成出口侧的XML，或者反之为入口侧的XML，并提供对具体组件本地运行时间引擎214的访问。在出口侧，代理程序被完全产生。通过由应用程序开发者提供的服务调用，可以调用出口代理程序。在入口侧，只有代理程序框架需要产生，象通过接收应用程序来实现那样。入口代理程序要求应用程序的服务实现，该应用程序是必须由应用程序开发者提供的。
以下将进一步详细描述集成知识库202、系统景观目录203和集成目录204的结构和操作。参考图4，集成知识库202包括业务流程232、路由对象234、映射236和界面238的描述，所有这些是依据一个或多个业务场景230来定义的。集成知识库202的业务场景230描述并构成了应用程序组件之间或商业实体之间基于消息的互相作用。用户可以选择在集成知识库202中描述的一个或多个业务场景230，作为快速构成XI 110的最好实践。
业务流程232是利用业务流程引擎(未示出)执行的可扩展的复合Web服务。每个业务流程232可以在集成知识库202中央做成模型。公司或用户根据其业务需要设计每个业务流程232，并且独立于技术实现。例如，可能有几种类型的业务流程232模板：即普通的业务流程、具体工业流程，以及具体公司流程。每个业务流程232识别需要的并且必须被互连的Web服务。在一种具体的实现方式中，例如，业务流程232是利用图形界面来定义的，然后保存成标准化的格式，如业务流程建模语言(BPML)。然后，业务流程引擎可以解释并执行这些模型以驱动与业务流程232相关的软件组件之中的协作。
路由对象234是预先定义的标准，用来确定在协作处理过程中必须在软件组件和商业伙伴之间分配的消息的潜在接收者。关于路由对象234的信息被用于在处理用于分配的完全消息之前确定接收应用程序，能够重复使用不同界面之间的特定标准，并提供关于这些界面的更抽象的观点。映射236定义在集成知识库202中可能被请求的消息界面238、消息类型或数据类型之间的变换。这些变换包括结构转换和值映射。结构转换被用于句法上或结构上不同的语义等同类型，而值映射可以用在由多个系统中不同密钥来定义对象的时候。在具体实现中，为用户提供图像映射工具以辅助映射，而变换数据是根据可扩展样式语言转换(Extensible Stylesheet Language Transformation，XSLT)，Java代码，或任何可以由图形映射工具产生的其它代码进行的。
集成知识库202是用于界面开发、存储和检索的入口的中心点。为此，界面知识库202包括一个或多个界面238，界面238代表该环境中所有软件组件的所有消息界面的界面描述。界面知识库202甚至提供可以潜在用于特定环境中的界面，而不管它们是否被实际用在那个环境中。因此，界面238可以利用任何技术在任何组件上实现。在一种实施方式中，界面238是基于WSDL的，而很多其它的实施方式也是可能的。消息界面由消息类型组成，而消息类型依次由数据类型组成。数据类型可以使用XML架构定义语言(XSDL)来描述。数据类型的一个示例是“address”，“address”被用在消息类型“Create PO”中，并可以被再使用做消息类型“Create Invoice”中。界面238可以依据任何分类，如入口和出口，或者同步和异步来设置。
集成目录204包含详细的协作知识，描述象安装在系统中的每个组件的配置，即与在集成知识库202中独立于景观的描述相对，集成目录204依赖于具体的系统景观。集成目录204详细描述来自具体于那种配置的集成知识库202的信息，并且可以利用从集成知识库202产生的内容自动地或利用图形工具手动填写。在一种示例性实施方式中，集成目录204是建立在Java平台上的，并且其内容是使用开放的因特网标准并通过XML表示的。象集成知识库202一样，集成目录204对第三方和伙伴协作知识是开放的。集成知识库202可被升级，而不影响集成目录204或任何有效的运行时间协作处理。然后，用户决定哪个改变应该被传递给集成目录204，或者象预先确定的自动升级或者通过图形工具的手动升级。
集成目录204包括业务场景250、业务流程252、构成路由规则254和可执行映射256的描述。集成目录204还包括有效Web服务258和有效商业伙伴260的描述。在集成目录204中的业务场景250代表在界面之间交互的全部观点，以及在与具体实施方式相关的实际配置的上下文中的映射256。业务流程252代表所有有效业务流程的可执行描述。
路由规则254在业务级别上决定消息接收者。在一种具体的实施方式中，消息的内容被用作路由规则254。也可以用其它的参数。相关输入参数包括发送者、发送者消息类型、识别接收者的消息以及接收者消息类型。路由规则254可以利用XML路径语言(Xpath，即通过利用图形工具)公布说明，或可以用Java进行编码。在运行时间，关于路由规则254的信息可以通过运行时间引擎214访问(参看图5)。
路由规则254可以利用逻辑词语来描述发送者和接收者，以将它们从在集成目录204中描述的Web服务258所提供的物理地址中分开。因此，物理地址可被改变而不用改变业务定向内容。与包含所有支持映射的集成知识库映射236相对比，在集成目录204中的映射256代表在运行时间系统景观中要求的映射。但是，例如一些新的入口，如新的映射序列，仅可以做在集成目录204中，以寻址例如另外的用于映射的Web服务。运行时间引擎214在运行时间访问集成目录映射256。
Web服务258描述当前系统景观实现的界面，以及由商业伙伴支持的Web服务。这样，Web服务信息用可与UDDI兼容目录相交换，或者手工添加。每个Web服务描述也提供物理寻址细节、访问信息，以及其它特殊的属性，如统一资源定位符(URL)、协议和安全信息。在一种实施方式中，Web服务258被以WSDL描述，而SOAP和ebXML可用作消息通知协议。运行时间引擎214也在运行时间访问有关Web服务258的信息。
商业伙伴262定义公司的商业伙伴的通常信息，如名称、地址和URL，但是也可以包含更详细和更复杂的信息。例如，商业伙伴262可包括公司伙伴可以直接接收和处理的消息格式的描述，或用于安全通信的安全协议的描述，或甚至交易条款项。保存在商业伙伴262中的这种信息可通过公司的公司具体决策利用XI 110来管理。
集成知识库202和集成目录204使用保存在系统景观目录203中的软件组件描述。系统景观目录203包括用于集成知识库202的组件240的设计时间描述，以及用于集成目录204的在运行时间的系统景观262的具体构成协作描述。组件240代表组件描述，组件描述包括有关应用程序组件的信息，以及与它们相互依赖性相关的信息。在一种具体实施方式中，组件描述是依据分布式管任务组(DMTF)的标准公共信息模型(CIM)。由于集成知识库202包括设计时间信息，所以，只有独立于实际安装的组件类型的信息被保存为组件240。利用API或交互地使用图形用户接口可以添加组件描述。
系统景观262使用XI 110有效地描述运行时间系统景观。系统景观262描述在系统内在特定机器上安装并可用哪些组件，选择哪种情况或客户，关于安装组件的进一步信息以及其它系统景观等等。系统景观260还基于开放的体系架构，并且能遵守广为接受的标准，如CIM。这样，许多专有的和第三方组件就可被配置成在安装时自动将它们注册在集成目录系统景观260中。对系统景观260的访问界面也可以是基于开放标准的，如基于Web的企业管理(WBEM)和SOAP标准。
下面将参考图5中的集成目录204、系统景观目录203和运行时间引擎214的具体视图来描述执行协作业务流程的协作运行时间环境270。协作运行时间环境270在连接的软件组件和商业伙伴中，集成了与交换消息相关的所有运行时间组件。依据由集成目录204和系统景观目录203提供的信息资源，集成服务器206或Web应用服务器210执行协作运行时间环境270，所述集成服务器206或Web应用服务器210的每个可以包括运行时间引擎214的实例。
在各种互联组件之间交换所有消息的运行时间引擎214包括两层：集成层272和消息通知与传输层280。集成层272包括用于执行中央建模业务流程的业务流程引擎274、逻辑路由服务276和映射服务278。消息通知和传输层280最好通过HTTP提供物理地址解析服务282、消息通知和排队服务284和传输服务286。在集成服务器206中的其它交换服务216可以补充运行时间引擎214。
在运行时间中，业务流程252依据业务流程模型，与它们的位置无关地由业务流程引擎274例证和执行，其中业务流程引擎274执行在Web服务258中描述的各个Web服务。这样，公司可以以几种方法来监视和控制全部的业务流程：通过跟踪已经成功完成的给定流程实例和Web服务的实际步骤；通过对事件的反应；以及通过集成工作组和入口基础设施的警报管理。业务流程引擎274独立于执行业务流程的语义，并且被配置为与技术组件相互作用的业务流程252的仲裁者和促进者。
图6是描述在应用程序之间交换消息的处理中运行事件引擎214的几个功能的框图。发送应用程序303驻留在发送组件系统302中，代表发送应用程序303的硬件和软件平台。一个或多个接收应用程序305的每个都驻留在接收组件系统304中。用于消息310的通信路径可以包括在出口界面上从发送组件系统302通过运行时间引擎214和适配器309到接收组件系统304的输出代理程序307。接收组件系统304还可以采用入口代理程序311而不是适配器。所示的接收组件系统304的结构和连接关系只是示例性的，应该注意到这样的结构和连接关系可能采用任何数量的形式。图中所示的示例例举了异步和同步通信。在同步通信中，由于响应被传递到已经知道的发送者，所以对于该请求只需要路由和物理地址解析。
还参考图5，对于所给消息，逻辑路由服务276利用有关发送应用程序和消息界面的信息，来确定接收者，并通过评价框312所示的相应路由规则来确定被请求的界面。路由规则是由集成目录204提供的运行时间系统景观的具体构成描述的一部分，并且能实现为Xpath表达式或Java代码。在框314，映射服务278根据消息、发送者和发送者界面，以及接收者和接收者界面来确定所请求的变换。在异步通信的情况下，甚至确定了消息方向，以适当地转换输入、输出和错误消息。
在从集成目录204检索所请求映射之后，映射服务278可以对发送消息的内容执行XSLT映射或者执行Java编码(或者在给定序列中的任何组合)。在集成层以下，消息通知、列队和传输服务284将消息移动给想要的或被请求的接收者。在框316中，在消息被转换成每个接收者所期望的格式之后，从集成目录204中检索所请求接收者服务的物理地址和其它相关的属性，并将它们映射到消息。
在消息通知和列队服务284中的列队引擎持续地保存进入、输出、错误和在流程工作中的消息。运行时间引擎214的消息通知层为应用程序组件的物理去耦提供列队功能，并且依据协议(即“EO协议”)保证消息被精确传递一次。传输服务286可以使运行时间引擎214同时充当客户机或服务器，传输服务286实施为能够进行出口通信的客户机和通过接收到来文档来处理入口通信的服务器。附加的服务功能可以是其中通过支持轮询所使用的传输协议而使用服务器的情况。最好使用HTTP，但是也可以使用其它的传输协议。
图7描述利用XI集成软件组件的异类集合的方法。在步骤402中，软件组件的设计时间协作描述被捕获到知识库中。设计时间协作描述包括业务场景、业务流程、路由对象、映射和以及将被软件组件用于基于消息的信息交换界面的描述。软件组件本身的设计时间描述被保存在由知识库访问的系统景观目录中。
在步骤404，具体构成协作描述是根据设计时间协作描述来产生的。具体构成协作描述包括构成业务流程、构成路由规则、有效Web服务、可执行映射和有效商业伙伴的描述。具体构成协作描述与运行时间的具体系统景观相关，并且在步骤406被保存在目录中。一旦保存在目录中，在步骤408，具体构成协作描述可访问运行时间引擎，并且如步骤410中所示，用作在运行时间系统景观中软件组件之间的基于消息的信息交换。
图8进一步提供消息交换处理步骤410的细节，象利用来自目录的信息由运行时间引擎执行的那样。在步骤420，在XI中接收来自发送应用程序的消息。该消息可以指定也可以不指定接收者；当然，消息的内容可被用来确定是哪些软件组件以及这些组件内的应用程序应当接收消息以完成具体的业务流程。如果接收者的物理地址还没有由该消息所包括时，那么，在步骤422，根据来自目录的具体构成协作描述，XI通过运行时间引擎确定一个或多个逻辑接收应用程序。具体构成协作描述包括消息界面描述，消息界面描述包括了接收应用程序的入口界面描述和发送应用程序的出口界面描述。
在步骤424，运行时间引擎将消息映射到与一个或多个逻辑接收应用程序相关的一个或多个入口界面描述。因此，在步骤426中解析一个或多个逻辑接收应用程序的物理地址。然后，如在步骤428中所示，运行时间引擎将该物理地址追加到该消息中，并将该消息发送给与接收应用程序相关的每个所解析的物理地址。按照该方法，任何格式的消息、协议或标准都可以在与XI连接的软件组件之间交换，不管软件组件是否共享相同的通信协议或标准。
虽然以上已经详细描述了几个实施例，也可以做其它修改。其它的实施方式都应当在权利要求书的范围之内。