CN1997983A - 面向服务的架构 - Google Patents

Abstract

面向服务的架构。本发明不旨在作为本发明的完整说明或限定本发明的范围。可以通过查看说明书、附图和权利要求来获得本发明的其他特征、方面和目的。

Description

面向服务的架构

优先权要求

本申请要求下面的同时待审的申请的优先权，如下同时待审的申请在此被整体并入：

U.S.Provisional Application No.60/573,354 entitled SYSTEM ANDMETHOD FOR ENTERPRISE APPLICATION INTEGRATION BUS，byMatthew Mihic et al.，filed May 21，2004(Attorney Docket No.BEAS-01684US0)(2004年5月21日提交的题目为“用于企业应用集成总线的系统和方法”，Matthew Mihic等人的美国临时申请第60/573,354号(代理案号：BEAS-01684US0))；

U.S.Provisional Application No. 60/573,717 entitled LIQUIDCOMPUTING，by Alfred Chang et al.，filed May 21，2004(Attorney-Docket No.BEAS-01703US0)(2004年5月21日提交的题目为“液体计算”的Alfred Chang等人的美国临时申请第60/573,717号(代理案号：BEAS-01703US0))；

U.S.Patent Application No.___/__,_entitled SERVICE ORIENTEDARCHITECTURE WITH MESSAGE PROCESSING STAGES，by Paul B.Patrick et al.，filed May 19，2005(Attorney Docket No.BEAS-01683US0)(2005年5月19日提交的题目为“具有消息处理级的面向服务的架构”的Paul B.Patrick等人的美国专利申请第___/__,_号(代理案号：BEAS-01683US0))；

U.S.Patent Application No.___/__,_entitled SERVICE ORIENTEDARCHITECTURE WITH MESSAGE PROCESSING PIPELINES，by Paul B.Patrick et al.，filed May 19，2005(Attorney Docket No.BEAS-01684US1)(2005年5月19日提交的题目为“具有消息处理流水线的面向服务的架构”的Paul B.Patrick等人的美国专利申请第___/__,_号(代理案号：BEAS-01684US1))；

U.S.Patent Application No.___/__,_entitled SERVICE ORIENTEDARCHITECTURE，by Paul B.Patrick et al.，filed May 19，2005(Attorney DocketNo.BEAS-01684US2)(2005年5月19日提交的题目为“面向服务的架构”的PaulB.Patrick等人的美国专利申请第___/__,_号(代理案号：BEAS-01684US2))；

U.S.Patent Application No._______entitled FAILSAFE SERVICEORIENTED ARCHITECTURE，by Paul B.Patrick et al.，filed May 19，2005(Attorney Docket No.BEAS-01684US3)(2005年5月19日提交的题目为“面向安全服务的架构”的Paul B.Patrick等人的美国专利申请第___/__,_号(代理案号：BEAS-01684US3))；

U.S.Patent Application No.___/__,_entitled SCALEABLE SERVICEORIENTED ARCHITECTURE，by Paul B.Patrick et al.，filed May 19，2005(Attorney Docket No.BEAS-01684US4)(2005年5月19日提交的题目为“面向可伸缩服务的架构”的Paul B.Patrick等人的美国专利申请第___/__,_号(代理案号：BEAS-01684US4))；

U.S.Patent Application No.___/__,_entitled DYNAMICALLYCONFIGURABLE SERVICE ORIENTED ARCHITECTURE，by Paul B.Patricket al.，filed May 19，2005(Attorney Docket No.BEAS-01684US5)(2005年5月19日提交的题目为“面向动态可配置服务的架构”的Paul B.Patrick等人的美国专利申请第___/__,_号(代理案号：BEAS-01684US5))；

U.S.Patent Application No.___/__,_entitled SECURE SERVICEORIENTED ARCHITECTURE，by Paul B.Patrick et al.，filed May 19，2005(Attorney Docket No.BEAS-01684US6)(2005年5月19日提交的题目为“面向安全服务的架构”Paul B.Patrick等人的美国专利申请第___/__,_号(代理案号：BEAS-01684US6))；

U.S.Patent Application No.___/__,_entitled CO-LOCATED SERVICEORIENTED ARCHITECTURE，by Paul B.Patrick et al.，filed May 19，2005(Attorney Docket No.BEAS-01684US7)(2005年5月19日提交的题目为“面向相同位置的服务的架构”的Paul B.Patrick等人的美国专利申请第___/__，号(代理案号：BEAS-01684US7))；

U.S.Patent Application No.___/__,_entitled PROGRAMMABLESERVICE ORIENTED ARCHITECTURE，by Paul B.Patrick et al.，filed May 19，2005(Attorney Docket No.BEAS-01684US8)(2005年5月19日提交的题目为“面向可编程服务的架构”的Paul B.Patrick等人的美国专利申请第___/__，号(代理案号：BEAS-01684US8))；

U.S.Patent Application No.___/__,_entitled BATCH UPDATING FORA SERVICE ORIENTED ARCHITECTURE，by Paul B.Patrick et al.，filed May19，2005(Attorney Docket No.BEAS-01684US9)(2005年5月19日提交的题目为“用于面向服务的架构的批更新”的Paul B.Patrick等人的美国专利申请第/__,_号(代理案号：BEAS-01684US9))；

U.S.Patent Application No.___/__,_entitled RELIABLE UPDATINGFOR A SERVICE ORIENTED ARCHITECTURE，by Paul B.Patrick et al.，filedMay 19，2005(Attorney Docket No.BEAS-01684USA)(2005年5月19日提交的题目为“用于面向服务的架构的可靠更新”的Paul B.Patrick等人的美国专利申请第___/__,_号(代理案号：BEAS-01684USA))；

U.S.Patent Application No.___/__,_entitled SERVICE ORIENTEDARCHITECTURE WITH FILE TRANSPORT PROTOCOL by Paul B.Patrick etal.，filed May 19，2005(Attorney Docket No.BEAS-01684USB)(2005年5月19日提交的题目为“使用文件传输协议的面向服务的架构”的Paul B.Patrick等人的美国专利申请第___/__,_号(代理案号：BEAS-01684USB))；

U.S.Patent Application No.11/133,110 entitled SERVICE ORIENTEDARCHITECTURE WITH ELECTRONIC MAIL TRANSPORT PROTOCOL，byPaul B.Patrick et al.，filed May 19，2005(Attorney Docket No.BEAS-01684USC)(2005年5月19日提交的题目为“使用电子邮件传输协议的面向服务的架构”的Paul B.Patrick等人的美国专利申请第___/__,_号(代理案号：BEAS-01684USC))；

U.S.Patent Application No.___/__,_entitled DYNAMICALLYCONFIGURABLE SERVICE ORIENTED ARCHITECTURE，by Paul B.Patricket al.，filed May 19，2005(Attorney Docket No.BEAS-01684USD)(2005年5月19日提交的题目为“面向动态可配置服务的架构”的Paul B.Patrick等人的美国专利申请第___/__,_号(代理案号：BEAS-01684USD))；

U.S.Patent Application No.___/__,_entitled PROGRAMMABLEMESSAGE PROCESSING STAGE FOR A SERVICE ORIENTEDARCHITECTURE，by Paul B.Patrick et al.，fied May 19，2005(Attorney DocketNo.BEAS-01684USE)(2005年5月19日提交的题目为“用于面向服务的架构的可编程消息处理级”的Paul B.Patrick等人的美国专利申请第___/__,_号(代理案号：BEAS-01684USE))；

U.S.Patent Application No.___/__,_entitled SERVICE PROXYDEFINITION，by Paul B.Patrick et al.，filed May 19，2005(Attorney Docket No.BEAS-01684USF)(2005年5月19日提交的题目为“服务代理定义”的Paul B.Patrick等人的美国专利申请第11/131,839号(代理案号：BEAS-01684USF))；

U.S.Patent Application No.11/131,516 entitled DYNAMIC ROUTINGIN A SERVICE ORIENTED ARCHITECTURE RULES，by Paul B.Patrick et al.，fied May 19，2005(Attorney Docket No.BEAS-01684USG)(2005年5月19日提交的题目为“在面向服务的架构规则中的动态路由”的Paul B.Patrick等人的美国专利申请第___/__,_号(代理案号：BEAS-01684USG))；

U.S.Patent Application No.11/131,622 entitled DYNAMICPUBLISHING IN A SERVICE ORIENTED ARCHITECTURE，by Paul B.Patrick et al.，filed May 19，2005(Attorney Docket No.BEAS-01684USH)(2005年5月19日提交的题目为“在面向服务的架构中的动态发布”的Paul B.Patrick等人的美国专利申请第___/__,_号(代理案号：BEAS-01684USH))；

U.S.Patent Application No.___/__,_entitled SERVICE ORIENTEDARCHITECTURE WITH MONITORING RULES，by Paul B.Patrick et al.，filedMay 19，2005(Attorney Docket No.BEAS-01684USI)(2005年5月19日提交的题目为“使用监控规则的面向安全服务的架构”的Paul B.Patrick等人的美国专利申请第___/__,_号(代理案号：BEAS-01684USI))；

U.S.Patent Application No.___/__,_entitled SERVICE ORIENTEDARCHITECTURE WITH INTERCHANGEABLE TRANSPORT PROTOCOLS，by Paul B.Patrick et al.，filed May 19，2005(Attorney Docket No.BEAS-01684USJ)(2005年5月19日提交的题目为“使用可交换传输协议的面向服务的架构”的Paul B.Patrick等人的美国专利申请第___/__,_号(代理案号：BEAS-01684USJ))；

U.S.Patent Application No.___/__,_entitled SERVICE ORIENTEDARCHITECTURE WITH ALERTS RULES，by Paul B.Patrick et al.，filed May19，2005(Attorney Docket No.BEAS-01684USK)(2005年5月19日提交的题目为“使用警告规则的面向服务的架构”的Paul B.Patrick等人的美国专利申请第___/__,_号(代理案号：BEAS-01684USK))；

U.S.Patent Application No.___/__,_entitled SERVICE ORIENTEDARCHETECTURE WITH CREDENTIAL MANAGEMENT，by Paul B.Patricket al.，filed May 19，2005(Attorney Docket No.BEAS-01684USL)(2005年5月19日提交的题目为“使用证书管理的面向服务的架构”的Paul B.Patrick等人的美国专利申请第___/__,_号(代理案号：BEAS-01684USL))；

U.S.Patent Application No.___/__,_entitled SERVICE ORIENTEDARCHETECTURE WITH MESSAGE PROCESSING PIPELINES，by Paul B.Patrick et al.，filed May 19，2005(Attorney Docket No.BEAS-01684USM)(2005年5月19日提交的题目为“使用消息处理流水线的面向服务的架构”的Paul B.Patrick等人的美国专利申请第___/__,_号(代理案号：BEAS-01684USM))；

U.S.Patent Application No.___/__,_entitled ERROR HANDLINGFOR A SERVICE ORIENTED ARCHITECTURE，by Paul B.Patrick et al.，filedMay 19，2005(Attorney Docket No.BEAS-01684USN)(2005年5月19日提交的题目为“面向服务的架构的错误处理”的Paul B.Patrick等人的美国专利申请第___/__,_号(代理案号：BEAS-01684USN))；

U.S.Patent Application No.___/__,_entitled DYNAMIC PROGRAMMODIFICATION，by Paul B.Patrick et al.，filed May 19，2005(Attorney DocketNo.BEAS-01684USO)(2005年5月19日提交的题目为“动态程序修改”的Paul B.Patrick等人的美国专利申请第___/__,_号(代理案号：BEAS-01684USO))；

U.S.Patent Application No.___/__,_entitled DYNAMIC PROGRAMMODIFICATION，by Paul B.Patrick et al.，filed May 19，2005(Attorney DocketNo.BEAS-01684USP)(2005年5月19日提交的题目为“动态程序修改”的Paul B.Patrick等人的美国专利申请第___/__,_号(代理案号：BEAS-01684USP))。

技术领域

本公开一般来说涉及一种用于服务的中间件，具体涉及具有消息处理能力的转换结构(switching fabric)，客户和服务可以通过该转换结构通信。

背景技术

对于企业软件应用与基于网络(web)浏览器的前端一起工作的需要引发了应用服务器的开发。应用服务器提供了用于将前端web应用与后端企业应用集成的框架。除了从应用服务器简单地调用企业应用以外，还需要将不同的企业应用段(piece)组合成复合应用。可以这样做的一种方式是将企业应用显示(expose)为其他系统可以访问的一组可重新使用的服务。但是，企业应用通常被部署在多个应用平台和异构(heterogeneous)环境中。这些因素使得所述复合工作量专有并编程驱动，导致脆弱和昂贵的集成。需要的是一种灵活的基础设施，用于动态地组合服务和处理可能在它们之间产生的任何不兼容。

附图说明

图1a是在一个实施例中的系统的图解。

图1b是按照一个实施例的服务总线架构的图解。

图2是按照一个实施例的量度汇聚(metric aggregation)和配置传播的图解。

图3是按照一个实施例的消息处理流水线的图解。

图4是按照一个实施例的前后流水线消息处理的图解。

图5是按照一个实施例的组件架构的图解。

图6a图解了具有单个流水线对节点和单个路由节点的消息处理图。

图6b图解了按照一个实施例的具有分支节点的消息处理图。

图7是按照一个实施例的错误处理范围的图解。

图8是在一个实施例中的服务提供者的图解。

图9是按照一个实施例的监控组件的图解。

图10是按照一个实施例的规则触发机制的图解。

图11a图解了按照一个实施例的包含组件A、B和C的初始核心状态。

图11b图解了按照一个实施例的会话数据的更新。

图12a-c图解了按照一个实施例的附加的会话情况。

图13a-c图解了在会话视图和核心状态之间的不一致。

图14是按照一个实施例的更新计划执行的图解。

图15a是按照一个实施例的成功更新的图解。

图15b图解了由于应用异常(exception)而导致的更新失败。

图15c图解了由于服务器崩溃而导致的更新失败。

具体实施方式

通过示例而不是通过在附图中的图的限制来说明本发明，在所述附图中，类似的附图标号表示类似的项目。对于本公开中的实施例的引用不一定是针对同一实施例，这样的引用意指至少一个。虽然讨论了具体的实现，但是应当明白，如此做是出于说明的目的。本领域内的技术人员可以认识到，在不脱离本发明的范围和精神的情况下可以使用其他的组件和配置。在下面的说明中，给出了多个具体细节以提供对本发明的充分说明。但是，本领域内的技术人员明白，可以不使用这些具体细节而实践本发明。另外，为了不使本发明模糊不清，对公知的特征没有详细描述。

参见图1a并且利用图示，所述系统包括服务总线100，所述服务总线100表示将消息中介、web服务、商务对商务(B2B)服务网关和服务管理概念融合为以运行时配置信息目录/库(repository)106和控制台104为中心的组合。所述服务总线是一种容易使用的配置驱动的中介，其有效和以高度的可用性、可扩展性和可靠性来(无限制地)完成如下方面：

·桥接(bridge)在封装(envelop)协议、传输协议、安全方案(scheme)、有效载荷内容、单向和请求/响应范例、同步和异步通信、点对点和发布/预订领域中在发送方114发送的消息和接收方116期望的消息之间的差距(gap)。

·提供用于执行诸如(但是不限于)多目的地发布、基于内容的路由、鉴别和授权，以及证书映射之类的任务的附加计算能力。

·提供具有量度收集和显示、警告显示、跟踪事件收集和使用、消息归档和服务级协议(SLA)管理的监控能力。

图1b是按照一个实施例的系统的图解。在一个实施例中，所述系统包括服务总线100，其可以作为在客户和服务之间的中介。本领域的技术人员可以明白，本公开不限于或不依赖于任何具体类型的服务或服务技术。许多服务类型/技术——包括公知的那些和有待开发的那些——全部在本公开的范围和精神内。去往服务总线的消息到达传输108，并且可以被处理来确定例如要路由和/或发布所述消息去往的目的地、对于所述消息执行的变换和/或安全处理。所述消息接着在传输110上被发出到绑定于一个服务或另一个服务总线。在一个实施例中，对于所述消息的响应可以沿着通过所述服务总线的逆路径。

在一个实施例中，可以在诸如从BEA系统公司可获得的WebLogic^服务器之类的应用服务器102上部分地或全部地实现所述服务总线。通过配置信息106来驱动系统，可以通过配置/监控控制台104来指定所述配置信息106，所述配置/监控控制台104提供了一个用户界面，用于创建、修改和删除配置信息。所述系统的所有方面是可动态配置的。以非限定性的示例来举例，用户界面可包括下列的一个或多个：1)在显示装置上被呈现或被投影到用户的视网膜上的图形用户界面(GUI)；2)响应于声音和/或语音命令的能力；3)响应来自遥控装置(例如蜂窝电话，PDA或其他适当的遥控器)的输入的能力；4)响应姿态(例如面部及其它)的能力；5)响应来自在同一或另一个计算设备上的处理的命令的能力；以及6)响应来自计算机鼠标和/或键盘的输入的能力。本公开不限于任何特定的用户界面。本领域内的技术人员可以认识到，许多其他的用户界面是可能的，并且完全在本公开的范围和精神内。

在一个实施例中并且参见图2，管理服务器112在企业中将所述配置信息分布到一个或多个主管(hosting)服务总线的被管理的服务器。在这些实施例的多个方面，被管理的服务器可以被部署在本领域内公知的集群(cluster)中。配置信息可以自动地向被管理的服务器传播，以通过服务总线来进行快速的本地检索。可以自动地从所有的被管理的服务器收集监控量度以汇集和显示在控制台上。

在一个实施例中，由服务总线主管的服务(“服务代理”)和未由服务总线主管但是被服务代理调用的服务(“外部服务”)都被模型化为服务。服务代理作为服务的替身或外观(即外部服务和服务代理)。以非限定性的示例为例，服务可以包括：

·被称为端口(也称为端点(endpoit))的一组具体的接口，每个具有传输地址和相关联的配置。在一个实施例中，该组端口构成所述服务的负荷均衡和故障转移(failover)的选择，并且在特性上相同。

·可选用的抽象接口，其在一个实施例中是可能被操作破坏的接口中的消息部分的结构的定义。

·绑定，其定义了有关到具体的消息的所述抽象接口中的消息部分的封装和将该消息到传输的绑定。

·关于web服务安全(WSS)和web服务可靠消息传送(WS-RM)的策略、

授权策略和需要由绑定层透明地执行的动作(例如登录)。

在一个实施例中，对于基于超文本传输协议(安全)HTTP(S)的简单对象访问协议(SOAP)web服务或Java消息传送服务(JMS)传输来说，所述抽象接口、具体接口和绑定的web服务描述语言(WSDL)表示是可能的。在本实施例的各方面，WSDL资源或现有的服务可以被用作新的服务的接口的定义的模板。同样被支持的是电子邮件、文件、WS-RM和文件传输协议(FTP)传输。在一个实施例中，所述服务总线可以定期地轮询文件系统目录以确定文件是否在文件传送的情况下已准备好处理。所述服务总线可以支持HTTP和JMS异步传送的请求/响应和单向范型(one way paradigm)。如果下层的传输支持消息的有序传递，则所述服务总线也可选地支持它。在另一个实施例中，服务总线支持外部标记语言(XML)、非XML(使用MFL描述的结构)、二进制、具有附件的多用途的网际邮件扩充协议(MIME)(电子邮件)以及SOAP封装。

服务/服务代理过程可以具有用于同一绑定的多个端口。这些端口可以被用作负载均衡和故障转移(failover)的选择。服务/服务代理可以定义用于使用其端口的负载均衡策略。在一个实施例中，所述策略可以包括循环(roundrobin)和随机(加权或未加权)。所述端口作为负载均衡目的地，但是也可以作为有关故障的故障转移(failover)的选择。所述两个概念被耦合在一起，用于高可用性的负载均衡方案。

服务代理也可以定义关于故障的重试策略和(用于请求/响应的)应用于其接口中的消息的超时策略和安全策略。这可以在服务级(应用到所有的消息)或单独的消息被指定以用于服务的操作。

在一个实施例中，通过一个或多个分类方案来对服务分类。例如，分类可以是密钥名称，并且分类值可以是用于所述密钥名称的值。服务可以具有用于多个分类名称的多个值。对于发现的目的来说，分类是有用的。有多种定义密钥名称的公知的本体论(ontology)(或分类方案)和所允许的值的等级。在本实施例的各方面，在分类等级中的叶值(leaf value)用于分类服务。在一个实施例中，服务消费者可以被分类来用于搜索。服务消费者可以是组织或应用，并且可以发送消息(或接收同步响应)。在另一个实施例中，服务消费者与证书相关联，并且被绑定到用户，所以它可以属于用于授权的角色。

在一个实施例中，被称为服务提供者的组织或应用可以提供一组服务。为服务定义提供者是可选择的，并且可以具有独立的服务。例如，这些可以或者是在企业内的内部子组织或外部合伙组织或甚至单独的应用(语义由用户决定)。而且，服务提供者可以像服务那样被分类以用于搜索。服务提供者可以与证书相关联，并且可以被绑定到用户，所以它可以属于用于授权的角色。服务提供者可以发送和接收消息。

在一个实施例中，服务代理的实现包括至少一个消息处理流水线定义。例如，这可以包括请求流水线和响应流水线的定义。流水线是消息处理节点，用于指定在调用外部(或另一个代理)服务之前对于服务代理的请求消息执行什么动作、在服务代理向客户返回响应之前对于来自由服务代理调用的服务的响应执行什么处理。每个流水线可以包括一系列的级。一个级实现与所述流水线兼容的协议和/或程序接口(programmatic interface)。被馈入所述流水线的消息伴随可以被流水线级访问或修改的一组消息环境变量(包括包含消息内容的变量)。

举例来说，通常的流水线的各级包括：

·变换级允许控制要嵌套的流控制“if(如果)”结构以选择要执行的影响环境的变换。web服务呼出或数据库查找可以是用于设置输出环境变量的XML查询(XQuery)或可扩展样式表语言变换(XSLT)的替代。

·路由级允许“if”结构和“case”结构组合(和嵌套)，以定义用于路由消息的单个端点和操作。在向每个端点发布消息之前，可以定义影响环境变量的一组变换。web服务呼出或数据库查找可以是用于设置环境变量的XQuery或XSLT变换的替代。

·发布级允许“if”结构和”case”结构组合(和嵌套)，以定义用于向其发布消息的一组端点和操作。向每个端点发布消息之前，可以定义影响环境变量的一组变换。web服务呼出或数据库查找可以是用于设置环境变量的XQuery或XSLT变换的替代。对于环境的改变与每个被发布的端点隔离，并且不影响流水线的随后处理。

·在一个实施例中，可以在绑定层中执行WSS处理以及授权。

·跟踪级允许使用用户定义的信息来写入跟踪记录，因此跟踪系统可以用于按照用户定义的标准来搜索。

·归档级向档案写入所述消息，以用于历史和记录保存目的。

·记录级允许将所选择的环境记录到系统日志，以用于调试目的。

·验证级凭借MFL方案的XML来验证文档。

·定制级实现与流水线兼容的协议和/或程序接口。

图3是按照一个实施例的消息处理流水线的图解。操作流水线可以根据由所述消息的内容指示的操作来处理消息。在一个实施例中，通过用户选择的标准来执行操作的确定。每个流水线可以包括一个或多个级(例如302、304、308、310)。单个服务级请求流水线300可以分支为多个操作流水线306和312。响应处理以相关联的操作流水线(314，316)开始，所述相关联的操作流水线(314，316)然后加入单个服务级响应流水线318。在一个实施例中，在调用单向操作的情况下，使用空消息来执行所述响应流水线。这允许对于服务代理构造响应，因此在请求/响应和单向操作之间的桥接是可能的(例如，服务代理输入可以是单向的，而其输出是请求/响应，或反之亦然)。服务代理或者从被调用的服务吸收响应，或者为客户产生响应。

在一个实施例中，在请求流水线和响应流水线以及其他消息处理节点之间共享环境，并且其值包括单独的请求/响应消息。在本实施例的各方面，所述环境是一组预定的XML变量。可以动态地对环境增加和删除新变量。以非限定性示例为例。预定的环境变量具有关于所述消息的信息、传输报头、安全负责体(security principal)、当前服务代理的配置信息和用于由服务代理调用的主要路由和预订服务的配置信息。在一个实施例中，环境可以由各级按照XQuery/Xupdate表达来读取和修改。

进一步举例来说，环境可以包括：变量$header(报头)、$body(主体)和$attachments(附件)。这些是包装器(wrapper)变量，所述包装器变量分别包括SOAP报头、SOAP主体内容和MIME附件。该环境给出了所有消息是SOAP消息的表达，并且非SOAP消息被映射到此范型中。在二进制或MFL数据的情况下，用于表示在$attachments或$body中的文件的XML元素涉及具有唯一标识符的实际文件。在SOAP RPC的情况下，主体内容本身是包含被用类型表征的(typed)RPC的参数的包装器元素。

在一个实施例中，系统具有内置类型的系统，如果期望的话可用于在设计时使用。当在设计时的变换或在条件中创建XQuery表达式时，所述变量可以在编辑器中被声明为具有一个或多个类型，以帮助容易地创建XQuery。在另一个实施例中，可以在XML模式、MFL或WSDL资源中指定所述类型。此类型声明过程注意到要被类型表征(type)的变量的特性(是用于所述类型的元素或所述类型本身的包装器)。它还提供帮助来容易地访问在$body中的SOAP RPC参数或文档。

在一个实施例中，如果在一个级中发生了错误，则该级可以具有要执行的步骤序列。该步骤序列构成那个级的错误流水线或句柄(handler)。另外，可以对于整个流水线或整个服务代理定义错误句柄。在出现错误时调用所存在的最低范围的错误句柄。这种错误句柄允许消息向端点发布，编制要返回到服务代理的调用器的错误响应消息，记录所述消息，在修改环境后继续，或引发异常。引发异常可以将控制传送到下一个更高范围的错误流水线。

图4是按照一个实施例的前后流水线消息处理的图解。请求的处理包括入站的传送402处理、入站的绑定层404处理、流水线执行406、出站的绑定层408处理和出站的传送410处理。在这些实施例的多个方面，所述绑定层自动操作将要执行的一些处理，如向/从环境变量映射、封装和解除封装消息以及执行WSS安全和授权。初始路由目的地和发布目的地可以工作在此范型中。在一个实施例中，在调用了初始路由端点后，响应流水线处理遵循类似的模型。在另一个图解中，来自流水线级的web服务调用(callout)420通过绑定层416，然后通过传输层418。在一个实施例中，所述调用响应沿着逆向路径。

在一个实施例中，用户是安全负责方，它可以或者是人、组织或过程。用户可以或者调用用户界面(控制台用户)或消息传送接口(按服务消费者或提供者建模的用户)。服务消费者和提供者可以与用户相关联以鉴别来自该提供者或消费者的消息。用户可以属于一个组，并且一个组也可以属于一个组。组和用户可以属于角色(role)，它们是用来向其分配对资源的访问权的单位(unit)。在一个实施例中，在系统中的资源提供者、消费者和服务可以被组织为一组项目，每个项目具有文件夹的等级以避免名称冲突，但是也提供了用于组织属于一些部门的资源和服务并且搜索它们的方便方式。

在一个实施例中，控制台支持任务级授权。作为说明，服务总线控制台用户或过程可以以一个或多个下面的预定角色来操作：

·集成管理员是服务总线超级用户，并且可以做任何事。

·集成操作员可以使用控制台来监控服务总线动作(bus activity)，执行消息跟踪，并且可以中止/恢复服务并且改变它们的工作时间。

·集成监控器具有对于所有事情的完整读取访问，并且可以输出任何资源、服务、提供者、消费者或项目。

·集成部署器具有对于全部事情的完全读取访问，并且可以创建、编辑或输入/输出资源、服务、提供者、消费者或项目。

·集成安全管理员可以读取、创建、删除、编辑ACL、证书、密钥库、用户、组和角色。

在一个实施例中，资源是过程/实体的可以重新使用的公共定义和/或说明(例如那个实体的配置信息)。资源通常由多个服务使用，并且是跨越企业或部门的标准化定义或说明。资源的示例是分类模式(schema)、MFL模式、XSD模式、XQuery映射、XSLT映射、WSDL接口和WS策略文件。分类模式定义了单个类别名称和所述类别名称的分级的一组值。可以使用注册的方案(registered scheme)来分类服务、提供者和消费者。可以使用一个分类模式的多个叶值或来自多个分类模式的叶值将它们分类。在一个实施例中，可以通过名称来查找在系统中的所有资源。在另一个实施例中，可以通过向分类模式应用搜索滤波器来查找资源。

模式描述原语(primitive)或结构化的数据的类型。MFL模式描述非XML数据的类型。XML模式描述XML的类型。XML模式类型可以输入或包括其他的模式文件。变换映射描述了在两种类型之间的映射。XSLT映射描述了使用XSLT标准的对于XML数据的映射。XQuery映射使用XQuery标准而描述了XML和非XML(MFL)数据的映射。

WSDL接口是用于服务接口的模板，并且描述了包括该接口中的操作的服务的抽象接口以及操作签名中的消息部分的类型。它还可选择地描述所述消息部分向所述消息的绑定(封装)和所述消息向传输的绑定。它也可选择地描述服务的具体接口。

WS策略描述了安全和可靠的消息传送策略。它描述了使用什么算法来在消息中签字或加密什么。它也描述了当接收时应当对于所述消息使用什么鉴别机制。

图5是按照一个实施例的组件架构的图解。服务总线可以被部署在也作为管理服务器502的单个服务器上或服务器集群上(例如，一个集群包括一组聚集的被管理的服务器500)。配置框架组件504可以提供用于配置信息的CRUD(创建、读取、更新、删除)能力以及对象和文件完整性保护、高速缓冲存储和索引、引用完整性(referential integrity)和配置传播。所述管理服务器可以向被管理的服务器传播所述配置信息。

在一个实施例中，任务框架组件506可以提供对于任务或组合任务(多个任务的任务)的操作取消和系列化能力，它们是包括对于独立的配置对象的多个CRUD操作的配置操作。配置传播的单元是任务，任务可以包含执行特殊代码，并且可以包含在被管理的服务器中部署EAR或WAR(主要用于自动数据库(automatic database)或对于传输的轻加权的web应用的部署)，并且支持粗颗粒的并发性控制(系列化任务执行)。在一个实施例中，汇聚框架组件524可以提供用于收集量度并且将它们传播到管理服务器以用于集群宽汇集的能力。在一个实施例中，数据越旧，则被汇集的数据变得越粗(在持续时间方面)。例如对于最后的小时(last hour)，汇集间隔是5分钟。此前，对于最后一天，汇集间隔是1个小时。此前，对于最后一周，汇集间隔是1天，等等。

在一个实施例中，警告系统510分析被汇集的量度以确定是否违反了服务级协议(SLA)规则，并且如果肯定则发出(raise)警告。在一个实施例中，警告目的地可以是电子邮件、web服务、WLI记录器、队列等(在必要时可以增加更多)。

在一个实施例中，控制台用户界面(UI)组件512是与门户(portal)集成的基于JSP的小门户(portlet)。控制台UI提供对于在控制台上的监控和配置的支持。

在一个实施例中，外部和服务代理配置组件514定义了代理或外部服务接口的抽象的、具体的安全和访问策略和绑定信息。服务代理是由服务总线服务器主管的中介人，而外部服务是在一些其他的服务器中驻留的、消息要路由到的外部端点。对于服务代理，它定义了由服务代理根据流水线架构而对于输入和输出消息执行的顺序消息处理。它在存在大量的服务时也提供搜索能力。

按照一个实施例，用户和证书配置组件516可以定义UI(用户界面)和消息传送用户以及属性和与该用户相配的证书。在本实施例的各个方面，用户可以按等级分成多个组，并且组和用户可以属于一个角色，所述角色被许可访问资源。消息传送用户可以是可发送消息的服务消费者或提供发送或接收消息的服务的服务提供者。

在一个实施例中，资源配置组件518可以用于定义共享资源，如(但是不限于)模板WSDL(web服务定义语言)、WS安全策略、模式、本体论(用于分类服务和服务提供者的分类方案)和可以被多个服务平衡(leverage)的变换映射。在有大量资源时它还提供搜索能力。

在一个实施例中，监控组件520提供监控UI用于服务总线系统显示警告和量度。

在一个实施例中，输入/输出组件522允许在服务总线安装之间的服务和其他资源的移动。设计(design)、筹备(stage)和制作(production)全部是独立的香草(vanilla)服务总线安装。如果输入的对象已经存在(替换或保持)，则输入允许指定环境特定配置参数和使用的方法。它还允许通过将被输入的对象链接到相同类型的现有对象而解决在所述被输入的对象中的未解决的参考。

在一个实施例中，传输和传输SPI 526组件提供了用于插入新传输的架构，并且也支持HTTP、JMS、电子邮件、FTP、文件、WS-RM(web服务可靠消息传送)和从框体(box)的定时器事件传输。每当可能时，支持流(streaming)、可靠性、消息排序和请求/响应以及单向消息。

在一个实施例中，流水线运行时和级SPI 528组件提供了用于由用户插入新定制级的框架，并且在服务代理中提供了环境管理和通过请求和响应流水线的消息流动。

在一个实施例中，服务代理流水线可以通过绑定层530而在任何端与传输接口连接，所述绑定层530可以根据对于服务代理(入站的)和被调用的(出站的)外部或服务代理定义的策略来处理消息封装、记录WSS处理和授权。

在一个实施例中，端点具有基于统一资源标识符(URI)的地址。例如，服务是向服务目录注册的入站或出站端点。例如，它可以具有相关联的WSDL、安全设置等。路由器是有名的流水线的集合。流水线是被命名的级的序列，用于表示非分支的单向处理路径。级是用户配置的处理步骤，诸如变换、路由等。流水线是可以作为消息处理图的一部分的消息处理节点。下面是消息如何从入站端点(服务代理)通过系统流向出站端点(通常是外部服务或另一个服务代理)的非常基本的概观(overview)。

传输层→绑定层→消息处理图→绑定层→传输层

在一个实施例中，所述消息处理图是会发生消息处理和操纵的地方。虽然绑定和传输层主要处理通信和消息封装/解除封装，但是消息处理和操纵也在这些层中发生。

在一个实施例中，传输层负责处理与客户和目的地端点的通信。它还支持诸如HTTP和JMS之类的多种通信协议，并且负责产生包含诸如端点URI和任何相关联的传输报头之类的东西的配置信息。对于消息内容，传输层主要处理以输入/输出流形式的原始字节(raw byte)和诸如JMS消息类的实例之类的传输特定消息对象。在另一个实施例中，传输层仅仅用于向系统中提供消息和从系统获得消息——它不执行对于消息内容的任何操纵。

在一个实施例中，绑定层主要负责组装和解除组装消息。它也可以作为在传输层和路由器之间的中介，所述传输层主要处理字节流，所述路由器可以使用更丰富的消息环境表示。由于性能上的原因，绑定层可以使用按需的(on demand)处理来避免解除封装消息和解除调度(unmarshal)数据，直到它必要时。

在另一个实施例中，绑定层还是执行安全处理的地方。在入站方，通过接收服务代理的配置来确定安全处理。在出站方，通过目的地服务的配置来确定处理。在另一个实施例中，绑定层是服务特定的，并且依赖于配置参数来执行其任务。

在一个实施例中，路由器负责实现服务代理的请求和响应逻辑。可以使用用于操纵消息内容的单向消息处理流水线节点来实现请求和响应路径。通过使用分支节点来确定要沿着几个流水线路径的哪个而使得条件执行可能。请求路径通常以发出对另一个服务或服务代理的请求的路由节点结束。来自那个服务的响应启动响应路径处理，其后，可以向服务代理客户发回响应。该响应反向通过所述消息处理图。

在一个实施例中，流水线节点可以按类型表征为三种类别之一：请求、响应和错误。请求流水线用于处理路由器的请求路径，而响应流水线用于处理响应路径。错误流水线被用作错误句柄，并且在下面的独立部分中详细讨论。除了指示流水线的目的之外，所述类型可以用于限制在流水线中可能出现哪些级。任何这样的限制委托给单独的级实现。

图6a和6b图解了按照一个实施例的消息处理图。如上所述，路由器可以使用消息处理流水线来实现服务代理的请求/响应逻辑。通过将请求和响应流水线级配对在一起(“流水线对节点”)，并且将它们组织为一个逻辑树结构或消息处理图来创建所述请求和响应路径。在一个实施例中，节点实现了程序接口和/或协议，它与所述消息处理图兼容。分支节点允许有条件的执行，并且在分支的端点处的路由节点执行任何请求/响应发送。在一个实施例中，消息处理图考虑了服务代理的动作的清楚的概观，使得路由动作和分支条件作为整体设计的清晰的一部分，而不是将它们深深隐藏在流水线级内部。请求消息跟随通过所述消息处理图的第一方向上的路径。相关联的响应可以沿着通过所述消息处理图的反向上的路径行进。

在一个实施例中，消息处理图可以包括三个顶级组件的一个或多个实例(图6a-6b)：

·流水线对节点(“PP”)。

·分支节点(“BR”)。

·路由节点(“RT”)。

图6a图解了具有单个流水线对节点600和单个路由节点602的消息处理图，所述单个路由节点602被配置来向服务603转发消息。所述流水线对节点将单个请求和单个响应流水线节点一起捆绑为一个顶极元素。在另一个实施例中，流水线对节点可以具有在消息处理图中的一个直接的子辈(descendant)。在请求消息处理期间，当请求流水线节点访问流水线对节点时，可以执行所述请求流水线节点。当为响应处理逆转路径时，可以执行响应流水线节点。

按照一个实施例，所述路由节点可以执行请求/响应与服务的通信。在本实施例的各方面，路由节点表示在服务代理的请求和响应处理之间的边界。当路由节点发送请求消息时，请求处理被认为结束。当路由节点接收响应消息时，响应处理开始。路由节点本身具有对于条件路由以及出站和响应变换的支持。是否条件出现在路由节点中或在消息处理图中作为分支节点由用户负责。在一个实施例中，路由节点在所述图中没有任何子辈。

图6b图解了按照一个实施例的具有分支节点的消息处理图。分支节点606允许处理以便精确地沿着几个可能的路径608之一来进行。在这些实施例的各方面，可以通过单个查找表来驱动分支，每个分支用简单但是唯一的串值(string value)作标签。在消息环境中的变量可以被指定用于该节点的查找变量，并且其值可以用于确定要沿着哪个分支。如果没有分支匹配查找变量的值，则沿着默认的分支。可以在到达分支节点之前完成设置查找变量的值。分支节点可以具有在所述图中的几个子辈；包括默认分支的每个分支一个。

在一个实施例中，当服务代理接收到请求时，请求处理在消息处理图的根部开始。在某个点，请求消息被传送到流水线对节点，在此，所述请求流水线节点被调用来执行处理。当请求消息被传送到分支节点时，请求沿着所选择的分支被进一步传送。当消息被传送到路由节点时，执行路由与任何出站/响应变换。当由服务代理接收到响应消息时，它可以沿着与由请求消息采用的路径相反的路径而被传送。对于简单结束而没有路由节点的任何请求路径发生相同的事情——服务总线启动响应处理并且返回所述图，但是不等待任何响应。在响应处理期间，当我们遇到流水线对节点时，我们执行响应流水线节点。当我们遇到分支节点时，它被当作空操作，并且响应被传送到在所述分支之前的元素。当响应最后达到图的根部时，响应被发回请求客户(它可以是另一个服务或服务代理)。

在一个实施例中，任何元素可以出现在消息处理图的根部。最简单的路由器设计之一是仅仅在顶部有一个路由节点，用于表示整个图。对于哪两个元素可以链接在一起也没有限制。例如，两个流水线对节点可以被链接在一起而在两者之间没有分支节点。对于分支，每个分支可以以不同的元素开始——一个分支可以用路由节点而立即终止，另一个可以由流水线对跟随，并且另一个可以无论如何也没有子辈。在后一种情况下，没有子辈的分支仅仅表示如果选择那个分支则响应处理立即开始。但是，一般来说，消息处理图有可能具有两种形式：用于非操作服务，所述图有可能包含由路由节点跟随的根部处的单个流水线对；用于操作服务，所述消息处理图有可能再次包括根部处的单个流水线对，其后跟随基于操作的分支节点，每个分支包括由路由节点跟随的流水线对。

在一个实施例中，路由器可以用于基于WSDL的服务，因此需要执行操作特定的处理。与要求用户手动地配置基于操作的分支节点不同，系统可以提供零配置分支节点，它基于操作自动地分支。可以对于在所述服务上定义的每个操作创建分支，并且分支变量当然可以是$operation。

由于各种原因而在消息处理期间会发生错误(例如在路由时的传送错误、在变换时的验证错误、在解除调度时的安全错误等)。通常，这些错误始发自特定级、路由节点或绑定层，因为那是可以实现多数路由器逻辑的地方。在一个实施例中，系统提供了一种机制，用于通过允许用户定义错误句柄来处理这些错误。在一个实施例中，错误句柄必须是另一个流水线节点，它允许用户执行各种动作，诸如登录、变换和发布，以适当地处理错误。

在一个实施例中，错误句柄可以被配置来用于整个服务代理以及用于每个流水线节点和其中的级。当发生错误时，它由最内部包含的错误句柄来处理。例如，如果在变换级发生变换错误，则它可以由那个级的错误句柄来处理。如果未配置这样的错误句柄，则它可以通过下一级的错误句柄来处理，所述下一级错误句柄是包含变换级的流水线的错误句柄。如果那个错误句柄不存在，则随后它被路由器级的错误句柄处理。如果失败，则默认的系统级错误句柄可以处理该错误。

图7是按照一个实施例的错误处理范围的图解。每个闭合的框体表示一个错误处理范围。可以在所述附图中看出，用于在路由节点704发生的未被捕获的错误的下一级错误句柄在路由器级的范围706。如果在此范围中没有句柄，则将调用在系统级范围708的句柄。对于未捕获到其本身的错误的流水线级700，错误可以被传播到流水线范围702。如果其中没有定义错误句柄，则错误可以传播到系统级范围708。每个组件——如果它是级——流水线或路由器可以具有错误句柄。在一个实施例中，因为入站的绑定层不与任何特定的级或流水线相关联，因此在绑定层中发生的错误可以由路由器级的句柄处理。出站的绑定层错误可依赖于什么实体正在执行通信而发生在几个位置。例如，在路由期间发生的绑定层错误可以被路由的节点的错误句柄捕获。类似地，在发布级中的发布操作期间发生的绑定层错误可以被级(stage)这一级别的错误句柄捕获。在一个实施例中，空的或未配置的错误句柄等同于根本没有错误句柄。在我们的前一个变换示例中，如果级这一级别的错误句柄被创建但是从未被配置，则所述错误会“沸腾”到下一级别的句柄。在一个实施例中，当错误句柄可以使用三种动作——重投、回答和继续——之一来结束错误句柄时。所述重投动作表示错误被重投，并且要被下一级别的错误句柄处理。除非被指定，否则错误句柄的默认动作是重投，这是为什么空错误句柄像不存在的错误句柄那样表现的原因。回答动作表示对于服务代理客户立即产生响应。所有的其他流水线处理被立即终止，并且根据与消息相关联的环境变量来发送响应消息。因此该由用户来配置错误句柄以在必要时变换这些变量以产生有意义的响应消息。

继续动作用于继续流水线处理，就好像根本没有发生错误。处理在成功地消耗(consume)错误的任何点继续。这可能要求用户配置错误句柄以安排环境变量，因为它们可能处在由路由器的其余部分不期望的状态中。当错误句柄消除错误时，处理恢复，就好像与所述错误句柄相关联的组件刚刚成功地结束执行。例如，如果在一个级中发生错误并且与那个级相关联的错误句柄消除了所述错误，则处理以在所述流水线中的下一个级继续，就好像所述级已经成功地结束。但是，如果没有被配置到所述级的错误句柄或如果所述错误句柄重投了错误，则通过流水线级的错误句柄来消除所述错误。如果如此的话，则处理恢复，就好像整个流水线已经成功地结束了执行。例如，如果那个流水线是服务请求流水线，则我们可以以操作请求流水线来进行。对于路由器级的错误句柄，继续等同于回答，因为在成功地执行了路由器后的下一个动作是向客户发送响应。

因为在一个实施例中错误句柄仅仅是另一个流水线，则可以将其配置为类似的任何其他的流水线。例如，发布级可以用于向其他服务发送错误通知，变换级可以用于通知环境变量等。但是，一些级不允许出现在错误句柄中。此时，被禁止的级是路由级。除了标准的环境变量之外，在更多的方面还有可以用于错误句柄的两个另外的环境变量。当错误句柄被调用时设置这些变量，并且如果经由继续而恢复了正常的流水线处理，则自动消除这些变量。所述两个变量是$fault和$faultAction。$fult变量保存关于错误和错误发生的位置的信息。这个变量可以与其他的环境变量一起使用来在诸如发布和变换之类的级中执行条件动作。错误句柄可以甚至在将错误重投到下一级的错误句柄之前修改$fault的内容。

$faultAction是用于确定一旦错误句柄已经结束了执行而可以执行什么动作的特殊变量。它是简单的串值变量，可以取下列三个值之一：“重投”、“回答”和“继续”。当错误句柄结束执行时，查看这个变量以确定是否服务代理应当重投错误，立即向客户回答或继续处理。这个变量被初始化为“重投”的值，因此如果用户希望改变错误句柄的默认重投动作，则需要变换以将所述值改变为或者“继续”或“回答”。

在一个实施例中，环境是属性包。每个属性(“变量”)具有名称和相关联的值。预定的环境变量用于表示在流水线中的多条消息，并且用于保存关于入站和出站的服务端点的信息。也可以在流水线处理期间引入另外的变量。在一个实施例中，可以使用XQuery表达来操纵环境变量。流水线级可以内部地操纵环境，作为它们的动作的一部分。

下面是在一个实施例中的系统定义的环境变量的列表以及按照一个实施例的简述。

·header(报头)-包含用于SOAP消息的SOAP报头。

·body(主体)-包含SOAP消息的SOAP主体。

·attachments(附件)-包含消息附件。

·inbound(入站)-包含关于接收到请求的服务代理的信息。

·outbound(出站)-包含关于要向其发送消息的目标服务的信息。

·operation(操作)-识别正在被调用的服务代理操作(如果适用的话)。

·fault(默认)-包含关于已经在处理期间发生的任何错误的信息。

·faultAction(默认动作)-指定应当在执行错误句柄后采取什么动作。

在一个实施例中，header、body和attachments表示当消息流过消息处理图时的消息的状态。可以通过修改这些变量来完成修改所述消息。这些变量使用由服务代理接收的消息内容来初始化，并且用于当向其他服务发送(例如经由路由)时构造出站的消息。所有消息相关联的变量可以被消息处理节点和级更新。所述变量整体是独立的，并且可以单独地被修改。

当通过服务代理来发送消息时，可以选择那个变量的内容要包括在所述消息中。在一个实施例中，该确定依赖于关于是否目标端点正期望SOAP或非SOAP消息。在SOAP的情况下，header和body被组合在SOAP封装(envelop)中以创建消息。在非SOAP的情况下，payload(有效负荷)是整个消息。在任何一种情况下，如果服务正期望附件，则可以从作为结果得到的消息和attachments变量产生MIME封装。header变量包含与消息相关联的任何SOAP报头。它指向<SOAP:Header>元素，并且以报头来作为子元素。如果是没有报头的SOAP消息或非SOAP消息的情况，则<SOAP:Header>元素可以是空的，没有子元素。

body变量表示核心消息有效负荷，并且指向<SOAP:Body>元素。在SOAP消息的情况下，SOAP主体被从封装提取，并且被分配到主体变量。如果消息是非SOAP或非XML，则全部消息内容被布置在新创建的<SOAP:Body>元素中。因此，可以经由同一变量并且使用同一封装来获得SOAP和非SOAP消息的核心有效负荷(例如在<SOAP:Body>元素中被包装)。

attachments变量保存与消息相关联的任何附件。在另一个实施例中，attachments变量是一条单根的XML，它对于每个独立的附件具有一个子元素。这些子元素包含关于(从MIME报头得到的)附件的信息以及附件内容。在本实施例的各方面，attachment元素可以包括下列元素：

·Content-ID(内容标识符)-用于识别附件的全局唯一的参考。

·Content-Type(内容类型)-用于指定附件的介质类型和子类型。

·Content-Transfer-Encoding(内容传送编码)-指定如何编码所述附件。

·Content-Description(内容说明)-内容的文本说明。

·Content-Location(内容位置)-用于识别附件的基于局部唯一的URI的参考。

·Content-Disposition(内容处置)-用于指定接收方如何处理附件。

·Body(主体)-保存附件数据。

在一个实施例中，入站和出站管理包含关于入站和出站端点的信息。入站变量包含关于接收到请求消息的服务代理的信息，而出站变量包含关于可以发送消息的目的地服务(例如路由)的信息。所述变量具有相同的XML模式，并且包含“服务”、“传输”和“客户”子元素以及单个“名称”属性，所述单个“名称”属性用于当端点被注册在服务目录中时标识端点的名称。

在一个实施例中，service(服务)变量包含关于服务的一般信息，并可以包括下面的元素：

providerName-保存服务提供者的名称

versionGroup-用于识别服务的版本类型

version-用于识别与版本组相关联的服务的版本号。

operation-用于识别在外部服务上正在被调用的操作的名称。

在一个实施例中，transport(传输)元素包含关于服务的传输细节，并且可以包括下面的元素：

·uri-用于识别端点的URI。对于入站，这是URI，消息按照它来到达。对应出站，这是当发送消息时要使用的URI，它覆盖服务目录中注册的任何URI值。

·request-关于包括传输报头的请求的传输特定配置信息。每个传送可以具有其本身的RequestConfiguration信息的特殊化，因此这个元素的结构最终依赖于正在被使用的传输。

·response-关于包括传输报头的响应的传输特定配置信息。与所述RequestConfiguration信息相同，这个元素的结构最终依赖于正在被使用的传输。

·mode-用于指示是否通信形式是请求(单向)或请求-响应(双向)。

·security Type-用于指示传输的安全类型。在一个实施例中，可能值是“非”、“基本”、“单向SSL”和“双向SSL”。

·accountAlias-这个元素标识向对于证书管理器注册的外部服务帐户的别名。传输层可以使用这个值来作为在证书管理器查找中的密钥以获得要用在出站的HTTP/S连接上的用户名/密码。

·qualityOfService-指定当发送消息时期望的服务质量。在一个实施例中，可能值是“最佳-效果”和“精确地-一次”。

·retryCount-当发送消息时使用的重试次数。

·retryInternal-在试图重发消息之前要等待的用秒表示的间隔。

在一个实施例中，消息处理级可以使用XQuery和/或XUpgate来操纵环境。在环境中的每个变量可以被表示为同一名称的XQuery变量。例如，header变量在XQuery中作为$header可被访问。

在一个实施例中，环境变量值可以根据要求被产生，并且尽可能多地成流(stream)。例如，可以通过传送层返回作为Java^InputStream(输入流)的输入的请求和响应消息。在穿通(pass-thru)处理的情况下，不接触所述流，直到服务代理将其发送到另一个服务或服务代理。对于SOAP消息，headers(报头)变量可以是未调度的，而不必将body(主体)具体化。同样，如果访问attachments(附件)变量，则可以解除封装附件。在operation(操作)的情况下，如果特别地访问所述变量，则它也应当触发有关请求消息的检查以确定正在被调用的操作。

除了路由、变换和监控，服务总线还包括使得有可能保证在客户、服务代理和服务之间的安全消息交换的各种特征。在一个实施例中，服务总线提供：在TLS/SSL上的消息机密性、消息完整性、服务器鉴别和客户鉴别；SOAP消息的消息级机密性、完整性和发送方鉴别；在传输和消息级的访问控制；证书管理；以及安全审计。

在一个实施例中，在服务总线中的安全特征使用可插入的安全提供者架构和安全服务，诸如：鉴别、身份声明、授权、角色映射、审计、证书映射和证明书查找和确认。服务总线可以使用作为构建块的所有这些提供者，用于提供较高级的安全服务。用户可以将这些框体提供者中的任何一个替代为第三方提供者或它们自己的定制提供者。在一个实施例中，可以由从BEA系统公司可用的BEA WebLogic Enterprise Security^TM提供服务总线安全。

图8是在一个实施例中的服务提供者的图示。由外部服务提供者804提供一个或多个外部服务808。中介服务总线服务被称为可以由代理(或本地)提供者802提供的服务代理806。服务提供者是具有安全身份的应用、组织或部门。调用服务代理并且具有安全身份的客户被称为服务消费者800。外部服务提供者本来也是服务消费者，因为它们可以同步或异步地响应请求。

通过在各个实施例中举例来说，服务总线和外部服务可以在同一网络中、在防火墙后或具有在服务消费者和服务总线和/或服务总线和外部服务之间的防火墙的不同网络上。在一个实施例中，服务代理和目标服务共存在同一域中。此特殊情况可以是服务处理管理(BPM)。在频谱的另一端，服务总线代理从在组织外部的交易伙伴接收消息或将消息路由到在组织外部的交易伙伴。在一个实施例中，用户管理处理在给定的鉴别提供者中的用户、组和角色的创建、更新和删除操作。这些提供者是安全框架的一部分。另外，用户管理也允许创建一些用户特性。用户、组和角色可以利用控制台配置，用于鉴别控制台用户和消息提供者。

在一个实施例中，用户是在鉴别提供者中的实体。多个鉴别提供者被支持。一个组是其成员身份静止并且由该组的管理员分配成员身份的用户的逻辑分组。角色是用户的逻辑分组和其成员身份根据角色条件或策略而被动态计算的多个组。管理员可以在所支持的任何一个鉴别提供者中创建、读取、更新和删除用户、组和角色。访问控制策略通常基于角色。

在一个实施例中，服务总线支持在HTTPS上的传输级机密性、消息完整性和对于单向请求或请求/响应(从客户到服务总线)的客户鉴别。服务总线可以执行基于策略的访问控制，并且可以审计鉴别和授权事件。当鉴别或授权失败时触发警告。在一个实施例中，当激活服务代理时，服务总线可以迅速地产生和部署薄web应用。应用服务器(例如WebLogic服务器)可以提供服务器方的SSL支持，包括会话管理、客户证明书确认和鉴别、信任管理和服务器SSL密钥/证明书操纵。

在一个实施例中，所述应用服务器可以以SSL协议向客户发送其证明书。换句话说，客户鉴别服务器，除此之外，在SSL握手期间，服务器可以请求客户向服务器发送其证明书，以便服务器鉴别客户。这通常被称为双向SSL。当未请求客户发送其证明书时，被称为单向SSL。在SSL顶部的较高级的协议可以自由定义它们自己的鉴别机制。对于例如HTTPS，一旦完成了SSL握手，客户可以通过在万维网鉴别HTTP报头中发送他们的用户名和密码来向服务器鉴别。这被称为BASIC(基本)鉴别。

在一个实施例中，如果服务代理已经被配置为获取客户鉴别，则所述服务器可以向服务代理端点鉴别所有的请求。对于BASIC鉴别，服务器可以凭借相对于在领域中配置的鉴别提供者——诸如LDAP、有效目录等——而鉴别客户。对于CLIENT-CERT(客户证明书)鉴别，SSL引擎可以验证客户证明书。一旦已经建立了对于证明书的信任，则将证明书传送到身份声明提供者以提取客户身份。在本实施例的各方面中，身份声明提供者是服务器安全框架的另一个组件。身份声明者被配置来提取证明书的某些字段来用做客户身份，通常是在证明书中的SubjectDistinguishedName(主体识别名称)的CN(公共名称)或E(电子邮件)。最后，鉴别提供者被调用来收集用户所属的所有组。结尾的结果是签字的Java鉴别和授权服务(JAAS)主题，一个负责体保存客户身份，一个负责体用于用户所属的每个组。

在一个实施例中，服务总线也支持在HTTP代理上的基本客户鉴别。当首先部署HTTP/HTTPS代理时，在授权提供者中存储服务代理URI的访问控制策略。在一个实施例中，服务总线支持XACML。

在一个实施例中，如果服务代理不要求客户鉴别，则初始访问控制策略许可对所有请求的访问。如果服务代理需要客户鉴别(基本或CLIENT-CERT)，则初始策略向所有的被鉴别的客户许可访问(但是拒绝匿名请求)。安全管理员可以在服务总线控制台上改变访问控制策略。在服务总线中，用户可以在下面的策略之间选择：不检查的(所有的请求被许可访问)；排除的(拒绝所有的请求)；被鉴别的用户(拒绝匿名的请求)；和一组角色。

在一个实施例中，成功鉴别导致产生JAAS主题，它包装客户身份负责体和用于用户所属的每个组的一个负责体。可以向各组分配用户。可以以组(或其他标准，诸如一日中的时间)来定义角色。在运行时动态确定用户所属的一组角色。如果访问控制策略是一组角色，则属于一个或多个那些角色的用户可以被许可访问。如果鉴别成功，则web容器调用服务总线HTTP/HTTPS传输提供者。从此，消息进行到服务总线绑定层。绑定层存储来自在消息环境中的被鉴别的JAAS主题的客户负责体，并且调用请求流水线。流水线级可以在商务规则中利用所述客户负责体。例如，可以应用客户特定变换，或者路由表条件可以考虑到所述客户负责体。

在请求流水线节点的末端，代理通常将消息路由到目标服务。可以通过在流水线中的路由级来确定目标服务。路由级可以路由到同一目标服务，或者可以动态地根据一些条件来选择目标服务。不论哪种方式，目标服务都被指定为对于在服务总线服务目录中注册的外部服务(或服务代理)的参考。管理员使用服务总线控制台来注册外部服务。

在一个实施例中，当注册外部服务时，输入服务传输和所述服务的一个或多个URL。这是服务代理可以使用来将请求路由到那个特定外部服务的传输和URL。如果所述传输是HTTPS，则可以指定下面的鉴别方法之一：基本、CLIENT-CERT或没有客户鉴别。如果传输是HTTP，则支持基本或没有客户鉴别。如果鉴别方法是基本，则可以指定可选用的ServiceAccount(服务帐户)。可以在以后覆盖出站(客户，例如代理)鉴别。

在一个实施例中，服务总线支持在服务总线代理和外部服务之间的、单向的在HTTP(S)上发送的请求-响应消息的传输级安全。HTTPS提供机密性和完整性。它也允许服务总线鉴别目标服务器。另外，如果需要的话，则服务总线代理可以向外部服务鉴别。这类似于入站传输安全，但是在这种情况下，服务总线启动HTTPS连接。注意，在出站的情况下，从SSL协议的角度来看，服务代理当作为客户，并且运行目标服务的服务器作为所述服务器。服务总线HTTPS传输提供者通过HTTPS连接向目标服务器发送HTTP请求，并且接受HTTP响应。目标服务器可以向服务器发送其SSL证书。

在一个实施例中，可以对于HTTP/S使用两种客户鉴别方法：CLIENT-CERT和基本。如果使用CLIENT-CERT鉴别来配置外部服务，则在SSL握手期间，服务代理可以向目标服务器发送其SSL客户证明书。在一个实施例中，服务代理可选地与本地服务提供者相关联。证书管理器将证书绑定到本地服务提供者。本地服务提供者可以具有用于SSL客户鉴别的私有密钥和证明书。这是服务代理在SSL握手期间可以使用的密钥/证明书。许多服务代理可以通过引用同一本地服务提供者在来共享同一SSL客户密钥/证明书。在一个实施例中，外部服务可以要求服务代理通过发送用户名和密码来鉴别。这通常是在HTTPS上进行的，但是服务总线也支持在HTTP上的基本鉴别。HTTPS提供加密的通道；因此，在HTTPS上发送密码是安全的。另一方面，非常不推荐具有基本鉴别的HTTP，因为密码在导线上以明文(base64编码的)来传送。

在一个实施例上，当使用基本鉴别来配置HTTP或HTTPS外部服务时，可以可选用地指定另外的服务帐户。如果不指定服务帐户，则服务代理可以以类似于如何检索服务代理SSL客户密钥的方式从证书管理器来确定要使用的用户名和密码：服务代理与本地服务提供者相关联，并且用户名/密码与本地服务提供者相关联。如果外部的服务指定服务帐户，则在证书管理器中存储那个服务帐户的用户名和密码。在这种情况下，服务代理不从本地服务提供者获得用户名和密码；相反，服务代理发送服务帐户的用户名/密码。

在一个实施例中，消息环境具有允许流水线节点设计者指定要用于检索用户名/密码证书的服务帐户的名称的元素。在请求流水线中的变换级可以设置消息内容中的这个元素。如果被指定，则这个服务帐户覆盖本地服务提供者证书

在一个实施例中，服务总线支持OASIS Web服务安全(WSS或简述为WSS)。WSS定义用于SOAP消息的消息机密性、完整性和发送方鉴别的框架。WSS适用于单独的SOAP封装(envelop)。WSS使用XML加密和XML-DSIG来作为创建块。在客户上的WSS运行时加密和/或数字地签字一个或多个独立的消息部分。在一个实施例中，向所述封装(envelop)增加新的SOAP报头。WSS报头包括XML-DSIG数字签字、安全令牌和其他构造。这些安全令牌可以用于发送方鉴别、密钥包装(一般承载(carry)使用接收方的公共密钥而加密的随机产生的对称加密密钥)、承载签字验证证明书或用于包括具有发送方的加密公共密钥的证明书(以便接收方可以加密所述响应)。结果是新的SOAP封装(envelop)。当接收方消除了被保护的封装(envelop)时，按相反次序执行加密操作，并且去除安全报头。接收方然后验证消息与其策略一致(例如所要求的消息部分被签字和/或加密，使用所请求的权利保护来提供所要求的令牌，等等)。

在一个实施例中，可以数字地签字和/或加密SOAP封装(envelop)的各个部分。结果产生的消息仍然是有效的SOAP封装(envelop)。例如，可以加密主体，可以签字WS寻址报头，并且可以既不签字也不加密另一个报头。WSS不依赖于安全信道。相反，保护单个的SOAP封装(envelop)的一个或多个部分。不论使用什么下层协议/传输——诸如HTTP或JMS，都发送这个SOAP封装(envelop)。安全措施被内置在消息本身中，在传输协议之外、在去往应用层的全程上保护消息。而且，中介可以在保护机密性、完整性和鉴别的安全属性的同时中继消息。因此，可以实现端到端机密性、消息完整性和发送方鉴别。举例来说，入站WSS被保护的消息可以是：

·从服务消费者向代理的请求。服务消费者向请求应用WSS，并且服务代理过程安全报头，且强制执行安全策略。

·从服务消费者到代理的请求。服务消费者向请求应用WSS，但是服务代理不处理安全报头并且不强制执行安全策略。服务代理将请求路由到外部的服务。外部服务处理安全报头，并且强制执行所述策略。这是请求穿通(pass-through)的情形。

·从目标服务到代理的响应。目标服务将WSS应用于响应，并且服务代理过程安全报头和强制执行安全策略。

·从目标服务到代理的响应。目标服务将WSS应用于响应，但是服务代理不处理安全报头，并且不强制执行安全策略。服务代理将响应转发到服务消费者。服务消费者处理安全报头，并且强制执行所述策略。这是响应穿通(pass-through)情况。

举例而言，出站的WSS被保护的消息可以是：

·从代理到外部服务的消息。服务代理将WSS应用于消息，并且目标服务处理安全报头，并且强制执行所述策略。

·从代理到服务消费者的响应。所述服务代理将WSS应用应用于消息，并且服务消费者处理安全报头和强制执行所述策略。

进一步地举例来说，服务消费者可以向服务代理发送加密的WSS SOAP消息以用于路由，服务代理或许根据一些明文报头——例如WS寻址报头或定制报头——的值来路由消息，后端(back-end)服务接收加密的消息，对它解密，并且处理所述请求。服务然后发送使用客户的公共密钥加密的响应。服务代理将所述响应交付给客户。服务代理不必解密所述消息。服务消费者和后端服务可以被保证服务代理不能读取敏感的数据(因为服务代理没有解密密钥)。类似地，服务消费者可以包括用于鉴别目的的安全令牌，并且服务代理可以将令牌中继到目标服务。

在一个实施例中举例来说，服务代理可以被配置来例如当服务总线被用作用于来自外部商务伙伴的输入请求的网关时处理在来自服务消费者的输入请求上的WSS报头。当服务代理和目标服务处于同一位置以强制执行在网关的访问控制时、并且当目标服务不支持WSS时，这可能有益于从计算密集的解密、签字验证和鉴别操作卸载(offload)后端服务。在一个实施例中，服务消费者加密和/或签字消息的一个或多个部分，和/或者包括鉴别令牌。服务代理鉴别所述令牌，解密消息，并且验证数字签字。基于WSS鉴别令牌和消息内容的访问控制可以在这里发生。明文消息然后通过请求流水线。在流水线的结尾，将消息路由到目标服务。

举例来说，服务代理可以代表服务消费者将WSS应用于消息。在这种情况下，服务代理从服务消费者接收明文消息。消息像通常那样流过请求流水线。在流水线的结尾，一旦已经确定了目标服务并且在实际发送消息之前，服务代理加密和/或签字消息并且/或者向消息增加鉴别令牌。这个新的安全SOAP封装(envelop)被交付给目标服务。

在一个实施例中，系统支持OASIS Web服务安全标准以及用户名令牌简档(profile)和X.509令牌简档。后端服务、客户和服务代理可以被配置在由BEA、IBM、微软、SAP、Sonic软件和VeriSign开发的web服务策略框架(WS-策略)规范后建模的可选的WS策略。这种框架定义了用于指定和配置web服务要求和能力的可扩展架构。

在给定的请求/响应往返行程中，可以单独地保护所有4个消息。在整个消息路径中的四个消息的每个潜在地遭受在WS策略中指定的要求。发送方可以例如通过下述方式来应用所述必要的步骤以产生符合所述策略的消息：通过签字和/或加密一个或多个消息部分，并且/或者包括所需要的鉴别令牌。接收方可以执行所述必要的步骤来消费所述消息，即解密、签字确认和令牌确认/鉴别。另外，接收方可以验证所述消息事实上符合所述策略。

在一个实施例中，服务总线可以被配置它需要来安全地与服务消费者和外部服务交互的证书。具体来说，在入站的消息上，服务总线可以被配置来：

·发送其(服务器)证书，以便客户可以鉴别服务总线服务器(例如在SSL握手期间)。

·在传输级或消息级鉴别消息发送方。

·使用服务总线的私有解密密钥来解密加密的消息。

·验证在输入的消息上的数字签字。

在出站的消息上，服务总线可以被配置来：

·在连接的另一端鉴别服务器(例如在SSL握手期间)。

·在传输级或消息级向接收方鉴别其本身。

·使用预想的接收方的公共密钥来加密消息。

·签字消息以用于鉴别或数据完整性目的。

服务总线证书管理器组件可以提供一个操作、管理和维护API和一个用于管理证书和检索证书的运行时API。证书可以分为两个种类：外部证书(属于与服务代理交互的外部服务或服务消费者的证书)；本地证书(属于服务代理或作为整体的服务总线系统的证书)。

在另一个实施例中，可以按照类型来分类证书。服务总线可以支持用户名/密码、私有密钥/X.509证明书链和被信任的X.509证明书。可以扩展CredentialManager(证书管理器)以支持其他的证书类型。在一个实施例中，证书——不论它是外部的或本地的——可以被绑定到服务总线资源。例如，如果代理的web服务安全策略要求使用RSA来加密入站的消息的SOAP主体，则可以有被绑定到服务代理的私有密钥和X.509证明书链。所述CredentialManager管理在服务总线资源和证书之间的这些绑定。

在一个实施例中，CredentialManager管理这些证书：

·对于本地服务提供者：加密证明书和对应的私有密钥；数字签名私有密钥和证明书；用户名/密码；本地服务提供者的SSL私有密钥和证明书，用于SSL客户鉴别；WSS鉴别(X.509令牌)的证明书和私有密钥。

·对于外部服务提供者：加密证明书；数字签字验证证明书；用户名/密码；SSL客户证明书；SSL服务器证明书；X.509鉴别证明书(用于WSS X.509令牌鉴别)

·对于服务消费者：加密证明书；数字签字验证证明书；用户名/密码；

SSL客户证明书；WSS鉴别(X.509令牌)的X.509鉴别证明书

在一个实施例中，规则基本上是用于评价表达和(通常)获得布尔结果的声明。如果所述规则评价为“真”，则规则可以包括被执行的相关联的动作的列表。在规则中包括的条件的范围可以从一日的当前时间(例如商务日历)到运行时环境数据、用户简档等。通过非限定性示例，规则可以用于根据系统健康(health)和响应时间来触发SLA警告，基于特定条件来动态地调整服务总线服务的“成本/健康”，在安全侵害的情况下发出通知，并且检测服务攻击的拒绝。例如：

规则1：如果服务OrderRouter的平均响应时间“大于”350毫秒，则通知

规则2：如果在上午9点和下午5点之间服务CreditCheck的响应时间“大于”10秒，则调用Web服务“记录故障单(trouble ticket)”

在一个实施例中，可以经由控制台创建并且以XML来表示规则。XML配置方案可以定义规则格式。服务总线规则引擎可以根据规则的位置而支持几种不同种类的规则。随后在该文件中进一步详细地说明了各种规则类型。在一个实施例中，服务总线规则具有下面的格式：

if<set of conditions>then<perform a set of Actions>(如果<一组条件>则<执行一组动作>)

举例来说，条件可以基于时间(日历)和由监控框架汇集的监控数据。这可以容易地被扩展来包括许多条件类型，如用户简档属性、流水线环境运行时数据等。在一个实施例中，每个条件类型将其本身注册到规则框架，并且提供配置和评价接口。这可以允许在未来插入所需要的那么多的条件类型。

在一个实施例中，规则可以广义地被划分为下面两个类别：SLA规则和联机(inline)规则。SLA规则主要用于评价SLA和触发警告以提前捕获潜在的系统故障。这可以通过下述方式完成：通过以规则的间隔来汇集来自所有的服务代理的监控信息，并且检查产生的状态以保证所有的性能约束被满足。联机规则是有用的，因为需要支持要求在流水线执行时触发(大多来自错误流水线)规则联机而没有监控数据汇集的延迟的使用情形。例如，“通知客户从大致安全证书不匹配而始发的消息”。在这种情况下，需要从用户管理模块来查找客户的联系信息。这需要一种机制，用于在流水线中嵌入规则“触发点”，并且允许商务用户在运行时将规则与这些触发器相关联。这样的规则还需要将某个最小数量的运行时环境数据传递到动作(当前的用户简档、当前的消息等)。

可以经由管理控制台来构造规则。每个规则与单个具体“实体”(服务、级、J2EE资源等)相关联。规则模式可以定义每个规则的格式。在一个实施例中，规则构建器为用户提供前端以通过将构造规则所需要的所有元素捆绑在一起来构造规则。这包含指定规则名和绑定——所述规则被绑定所至的实体(服务、级、JMS资源等)。选择服务意味着可以使用在流水线、路由器和传输中可用的监控元素来构造规则。在一个实施例中，绑定通过清楚地标识什么运行时数据-如果有的话-对所述规则可用来提供规则的“环境”。

在一个实施例中，可以指定规则的触发器：规则可以一次触发动作，并且等待手动复位或条件自动复位；每次时间规则评价为真时规则触发动作；并且，如果规则评价为真，则每“x”分钟，规则触发动作，等等。

在一个实施例中，规则可以包括零或更多的条件。条件可以具有不同的类型：商务日历、监控数据、运行时环境变量等。规则框架被设计为从运行时上看容易插入新的条件类型。

根据规则被绑定所至的实体，规则构建器用户界面可以允许在所述规则中包括指定的条件类型。例如，SLA规则可以被定义在那个具体绑定处可用的监控数据上。与JMS资源相关联的规则可以包括基于由服务器定义的JMS资源量度的条件。但是，可以有特定的条件类型，如可以与被部署到所有的绑定点的规则相关联的商务日历。这是因为日历不依赖于任何具体的环境/绑定相关联数据。每个条件包括一个或多个表达，可以使用OR(或)和AND(与)操作符将其任意结合和嵌套。例如，考虑下面的规则：

如果“在上午9点和下午5点之间”“服务ABC的平均响应时间超过2秒OR(或)安全侵害计数超过25”，则通过电子邮件向我通知“一次，直到手动复位或条件自动清除”。

在上面的规则中，有两个条件类型——商务日期和监控数据。基于监控数据的条件被逻辑或(OR)。对于为真的上述规则，当前的系统时间具有在上午9点和下午5点之间AND(与)平均响应时间可以超过2秒OR(或)安全侵害可以超过25两者中的任一个。条件在顶级全部被AND(与)。独立的条件包括可以任意地被组合和嵌套的表达式(使用OR(或)和AND(与))。在一个实施例中，动作的列表可以伴随一个规则，所述规则指定当所述规则评价为真时需要执行的动作。用户可以选择在规则中不包括任何动作。在一个实施例中，规则具有至少一个条件OR(或)一个动作。可以请求用户指定执行所述动作所需要的所有必要的配置参数。在一个实施例中，动作的改变可以从诸如发出通知电子邮件之类的简单任务到调用远程web服务以记录被路由到具体工作列表的故障单。下面是可以在服务总线警告框架中可用的一些动作：经由电子邮件来通知；调用web服务；并且设置服务成本——在服务目录中设置服务的“成本”。服务的成本可以用于进行路由决定。

在一个实施例中，规则评价器当被事件触发时评价规则。这可以是经由直接的API调用——规则评价器提供可以用于触发规则评价的API方法。所述方法调用参数可以包含用于标识需要被评价的一个或多个规则的信息。例如，当新的监控数据变得对于那个服务可以可用时，监控数据汇集器可以调用规则评价器API以评价与服务相关联的SLA规则。也可以通过事件预订来触发规则评价——评价器可以向事件机制预订，并且当出现事件时触发规则评价。事件环境可以包含可以在规则评价和动作执行中使用的所有运行时信息。出现安全侵害事件的安全级可以触发规则评价以通知管理员。在这个示例中，事件环境可以包含消息ID和发送方的地址，它们可以帮助管理员清楚地标识问题的来源。可以按照预定的时间表经由商务日历触发基于定时器的规则。在一个实施例中，调度服务可以产生规则评价器所预订的定时器事件，并且当出现所述事件时启用(kick off)规则评价过程。在一个实施例中，一个框架汇集可以用于监控系统的健康的数据。该框架的重要特征包括：允许用户容易地经由配置向服务总线服务中嵌入性能监控应用；提供一种机制，用于禁止/使能在运行时的监控；汇集数据并且计算警告以向用户通知潜在的系统故障；并且，提供关于所汇集的数据的基本量度(例如，最小、最大、平均等)。

在一个实施例中，监控框架可以定义监控元素的列表。监控元素是监控量度的特定类别。监控元素足够一般化，因此它们可以被大量的组件使用。监控元素的列表可以是可扩展的，并且可以按照需要增加更多的这样的元素。在一个实施例中，所述框架可以同时定义下面的监控元素：

·计数器：提供一种机制，供用户在他们的代码中定义和使用计数器，以跟踪诸如所处理的请求数量、错误数量、所处理的消息数量等之类的事项。计数器可以提供用于增加、减少和复位计数器的当前值的方法。

·定时器：应用可以使用定时器来定时特定的操作。定时器可以提供用于开始、停止、复位和检查自从定时器被启动起所流逝的时间量。

图9是按照一个实施例的监控组件的图示。在管理服务器900上的配置管理器914捕获监控框架所需要的配置信息。例如，这可以包括用于每个应用的监控属性、每个属性的数据类型、是否使能了监控、需要对于每个应用汇集监控数据的频率等的列表。如果外部应用对于监控数据感兴趣，则它们也可以向配置管理器注册。在一个实施例中，监控管理器906运行在被管理的服务器902上。在一个实施例中，监控管理器可以通过MBeans 916而在外部或通过工厂而在内部被暴露。它们的主要功能是管理在每个被管理的服务器上的被监控的信息。也可以提供API，以便应用可以调用用于它们的数据属性的监控功能。

在一个实施例中，数据汇集器910以规则的间隔(可配置)运行在管理服务器上，并且汇集来自在给定的域中的被管理的服务器的所有的信息的数据。所汇集的数据被处理和被分为在每个应用的配置中指定的具体时间间隔。控制台可以显示监控信息使用所汇集的数据。在规则的间隔，监控数据发布器(未示出)向被注册的外部应用发布数据，用于归档或外部计算的目的。规则管理器918负责存储规则，并且使用所汇集的数据评价规则。在一个实施例中，当规则被评价为真时，它调用警告管理器912。当一个规则被评价为真时，警告管理器通知其他处理。例如，它可以按照与规则相关联的动作来发送电子邮件和/或在队列上布置消息。

在一个实施例，举例来说，数据汇集器910在数据变得越旧时在存储器中保存越来越少的数据。可以定义窗口以便在不同时段使用不同精度观看数据。例如，我们定义下面的窗口：5分钟、1小时、24小时。对于计数器，它意味着我们在最后5分钟将存储所有的改变(可以改变它并且决定按照例如秒或按照10秒来获得改变)。对于最后的小时，按照5分钟来获得改变。对于最后24小时，按照小时来获得改变。对于任何更长的时段，按照天(隐含的)来获得改变。使用这种配置，意味着我们需要在最后5分钟在存储器中存储不定数量的值、对于最后的小时+12个值、对于最后一天+24个值、并且按天+1个值。因此，对于365天：～＝400个值。被汇集的数据可以被显示在控制台上的图形中，并且/或者用于触发规则。

在一个实施例中，用户可以在控制台中交互地指定规则。例如，控制台可以显示由服务的服务/级/传输/服务质量组织的被监控变量的树，该服务的服务/级/传输/服务质量可以在所述规则的XQuery表达式中被拖放。

在一个实施例中，要使用监控框架来捕获监控数据的应用可以指定需要被监控的属性的列表，并且可选地在那个窗口中指定有关更新时间和频率的滑动窗口以捕获数据。当指定在那个窗口中的滑动窗口和间隔时，系统也可以被配置来保存“近来的活动窗口”，它是在被配置的最近时间间隔中制作的所有监控条目的列表。在一个实施例中，系统支持使用计数器和定时器的监控。

在一个实施例中，配置信息定义了每个应用正在监控的属性的列表。每个应用(或应用实例，像在传输的情况下那样)可以像监控框架注册其本身。注册可以包含：提供可以被监控的唯一名称和属性的列表(和对应数据类型)和时间窗口规范。框架可以发布所述配置的模式。

在一个实施例中，管理服务器包括由所述框架提供的所有运行时功能。在一个管理服务器上，这可以包括：汇集来自所有被管理的服务器的数据；将所述数据分类到各自的时间间隔窗口中；计算关于被汇集的数据的统计；定义MBean接口以提供对于被汇集的数据的访问。向警告管理器通知在数据中的改变，因此可以触发规则(或者在规则的间隔评价规则)；并且，提供一种机制来向外部归档系统发布监控数据。在一个被管理的服务器上，监控管理器可以：定义供应用记录监控数据的API；提供数据的运行时库；并且通过MBeans曝光其数据。

在一个实施例中，为了记录监控值，应用(例如传输、流水线级)需要通过传送唯一的应用名称来首先检索各自应用的监控环境。监控环境提供被命名的计数器和计时器的访问，用于提供记录数据的方法。例如，采样的源代码可以看起来如下：

ctx.getMonitoringService().getTimer(“execution_time”).start()；

ctx.getMonitoringService().getCounter(“nb_messages”).increment()；

ctx.getMonitoringService().getTimer(“execution_time”).stop()；

管理服务器包括数据汇集器910，它在特定的轮询间隔上轮询每个被管理的服务器，并且汇集数据。被汇集的数据被分类和被装入在按照应用名称和所配置的各个时间窗口来组织的存储器存储仓中。然后对所更新的数据计算统计。监控运行时Bean 916可以允许应用访问这个被汇集的数据。另外，管理服务器可以通知规则管理器918，因此可以凭借被更新的数据和/或发布数据来运行规则。

如果规则的条件为真，则可以执行相关联的动作。在一个实施例中，可以将动作实现为服务。在一个实施例中，可以在用户指定的间隔定期评价规则。在一个实施例中，警告被实现为在服务总线上部署的服务。框架提供一种配置机制，外部应用可以从该配置机制选择具有将有关特定的JMS题目的被汇集的监控数据发布给它们。

在一个实施例中，规则是用于评价一个或多个表达式和获得布尔结果的声明。在另一个实施例中，如果评价在规则中包括的所有条件的结果导致“真”值，则规则也具有被执行的相关联动作的列表。可以在规则中包括的条件的示例是：一日(商务日历)的当前时间；当前的用户简档；应用响应时间(或其他监控数据)；以及由应用遇到的安全侵害。可以在规则中包括的动作的示例是：通告电子邮件地址；发送消息；创建新的任务输入项；调用服务；以及使能/禁止服务。

规则示例：

·简单动作-当特定服务的平均响应时间超过某个门限值时，向管理员发送通知。

·每天，在上午9点和下午5点之间，如果在5分钟间隔中遇到多于10个安全侵害，则产生警告。

·如果在最后10分钟中超过10次检测到类型X的消息，则记录输入项。

·如果类型P的过程实例已经“运行”了超过12小时，则创建管理列表任务条目。

在一个实施例中，可以几种不同的方式——自然语言、XQuery声明等——来表达规则。控制台可以允许用户管理规则。可以将下层的规则持续为XML文档，并且可以发布该XML的模式。在一个实施例中，规则框架运行时可以消耗该XML文档并且在运行时评价规则。当评价这些规则时，XML文档可以被转换为适当的运行时格式。基于例如条件的监控量度可以被评价为XQuery。以非限定性示例为例并且参照图10，规则触发器可以具有各种种类：被更新的监控量度1010的可用性；事件1012；从一个状态向另一个状态过渡的过程；服务的平均响应时间的改变；特定类型的消息的到达1012；以及定期触发规则的调度服务1018。

在一个实施例中，规则环境在评价在规则中包括的条件和动作时封装由规则消耗的运行时数据。规则环境与规则触发器紧密相关联。在规则环境中包含的运行时数据依赖于触发器的类型。例如，由与服务的平均响应时间的改变相关联的触发器产生的规则环境可以包含服务的名称和平均响应时间的新值。基于事件触发器的规则环境可以包含事件的特性和与那个特定事件相关联的数据。

规则可以被定义并与各种实体相关联。在一个实施例中，规则绑定捕获关于一个规则所相关联的实体的信息。规则绑定以下述方式来影响规则环境：清楚地定义什么运行时数据——如果有的话——对所述规则可用。规则所相关联的每个这样的实体可以向所述规则提供可以用于构建条件和动作的一组数据。例如，被绑定到服务代理的SLA规则可以包括基于对那个服务可用的监控量度的条件。如上所述，规则可以包括条件的列表和动作的列表。每个规则可以具有下列结构：

if<set of conditions>then<perform a set of Actions>(如果<一组条件>则<执行一组动作>)

规则可以包括0个或多个条件。在一个实施例中，不包括的规则和条件总是为真，并且每次触发规则时执行动作。条件可以具有不同的类型：商务日历、监控数据、用户简档和其他适当的类型。所述框架被设计使得可以容易地在运行时插入新的条件类型以容纳由客户期望的新的条件类型。

在一个实施例中，可以在规则中包括的条件的类型由规则绑定控制(dictate)。这个声明的一个例外是诸如商务日历之类的条件，所述商务日历可以与所有的规则相关联，因为商务日历定义是“全局的”，而不捆绑到任何具体的绑定点。每个条件由可以使用逻辑或和逻辑与运算符来任意组合和嵌套的一个或多个表达式组成。在一个实施例中，条件在顶级全部被与(AND)运算。在规则中包括的所有条件需要评价为“真”以使得规则评价为真。就像新条件类型可以在运行时被增加到规则框架那样，也可以在运行时注册新的动作类型。在一个实施例中，警告框架可以定义允许增加新动作和条件的SPI。

规则触发器负责启动(kick off)规则的评价的过程。如上所述，可以通过几个不同的机制来触发规则评价过程。在一个实施例中，举例来说，这些机制可以包括：更新的监控量度的可用性；事件预订——规则评价器在出现事件时可以预订事件框架和触发规则评价；以及基于定时器的规则——调度服务可以产生规则评价器预订的定时器事件，并且在固定的间隔启动规则评价。

在一个实施例中，评价规则包含评价在规则中包括的每个条件，并且如果所有的条件评价为真，则调用被包括的动作。举例来说，规则评价器通过在规则中包括的每个条件，并且调用与每个条件类型相关联的对应的评价器以评价所述条件。在另一个实施例中，每个条件类型注册可以评价那个类型的条件的评价器。注册条件评价器包含实现由警告框架发布的Java^接口。

在一个实施例中，规则框架提供了一种服务提供者接口(SPI)，通过它可以注册另外的条件和动作类型。在一个实施例中，每个动作和条件类型被实现为独立的web应用。当部署所述应用时，收听者类(listener class)注册这些条件和动作类型。

在一个实施例中，规则绑定标识可以将规则与其相关联的位置。每个服务(外部和代理的)可以定义可以向其部署规则的一个或多个绑定点。绑定点可以捕获由在那个服务代理中的所有流水线、级和传输注册的监控量度。规则可以被绑定到这个绑定点，并且在这个绑定点可用的监控量度可以用于构造条件。在一个实施例中，每次创建/更新/删除服务代理时，通知向配置管理器注册的收听者。这个收听者可以提取在服务中的绑定点，并且将它们注册到警告绑定管理器。

在一个实施例中，当实体进入“存在(existence)”时，包含规则绑定点的每个“实体”(服务或处理)可以向警告管理器注册这些绑定点。对于服务总线服务，这意味着当创建服务时注册绑定点。对于BPM处理，当部署所述处理时这个注册发生。在一个实施例中，绑定点的这个库可以被保持，并且可以对经由控制台和其他工具可以使用的JMX接口浏览可用。

在一个实施例中，警告管理器可以提供用于获得服务/处理名称的API和包含新的监控量度的规则环境。警告管理器可以随后查找对于那个服务或处理注册的所有绑定点，并且评价被绑定到每个绑定点的所有规则。

在一个实施例中，除了在配置时提供的所有信息之外，规则环境可以包括由规则绑定产生的所有运行时数据。条件和动作评价器可以提取这个运行时数据，并且在所产生的警告中嵌入对应的值。下面的表列出了可以在规则环境中可用的字段：

字段名称	说明	数据类型
			规则名称	当前执行的规则的名称	字符串
绑定点名称	规则被绑定到的绑定点的名称	字符串
			被绑定到的实体	绑定点相关联的实体的名称	字符串
实体类型	“被绑定到的实体”的类型	枚举
			实体URL	实体的显示URL	URI
数据元素	在相关联的绑定点的监控数据元素和所述元素的运行时值的列表	列表(例如被表示为XML文档)

表1：按照一个实施例的运行时规则数据

在一个实施例中，规则框架可以暴露一组JMX API以配置规则。这些API可以向管理规则提供插入、检索、确认和保持功能。这可以允许第三方工具直接与JMX层交互以管理规则和完全地绕过WLI 9.0管理控制台。

多个规则可以与单个绑定点相关联。可以以部署规则的顺序来执行规则。用户可以在任何时间改变这个顺序。在一个实施例中，创建规则包含将一个规则与绑定点相关联。例如，这么做的两种方式：

1.浏览绑定点——管理员首先浏览来自绑定库的所有绑定点，选择一个，并且创建与那个绑定点相关联的规则。

2.浏览实体——在这种情况下，管理员通过首先标识他/她要将规则相关联的实体(服务总线服务目录或BPM处理查看器)开始。然后向用户提供在服务/处理中可用的规则绑定点的列表，选择一个绑定点，并且创建与那个绑定点相关联的规则。

在一个实施例中，每个规则条件和动作类型可以定义其本身的模式以表示动作或条件配置数据。这个条件或动作配置被返回到警告管理器来作为系列化的XML，并且警告管理器可以将这个数据保持为规则定义的一部分。当配置条件或动作时，规则环境被传送到每个条件和动作类型。这允许条件配置机制执行确认以保证在绑定点可用的监控数据被包括在所述条件配置中。

在一个实施例中，被部署到特定绑定点的规则可以包括监控在具体绑定点可用的数据元素。对于使用WLI控制台来管理规则的用户，可以通过控制台来自动执行该确认。所述控制台可以容易地保证在相关联的绑定可用的数据元素用于构造在规则中包括的条件和动作。在一个实施例中，监控管理器汇集监控数据的集群范围(cluster wide)的量度，并且对于已经更新了可用的监控量度的每个服务/处理触发与每个绑定点相关联的规则的评价。警告管理器可以首先构造所述特定绑定点的规则环境。然后，可获得被部署到那个绑定点的所有规则，并且可以以配置规则的顺序来评价每个规则。规则环境被传递给每个条件H动作评价器。如果在规则中的所有条件评价为真，则执行在规则中包括的动作。规则运行时状态对象跟踪激发每个条件和动作的结果。这个信息用于保证不对于用户已经被通知的预先存在的条件重复激发警告。

在一个实施例中，规则运行时状态对象也被传送到每个动作和条件。这个对象也可以定义每个条件和动作的占位符(placeholder)以布置可以用于产生每个被评价的规则的跟踪记录的记录数据。警告记录条目被产生为可以在任何一个数据集中包含的跟踪数据元素。可以在控制台上显示跟踪记录。在一个实施例中，路由节点提供了消息处理图的请求/响应通信。它用于向所选择的服务分派消息，并且如果适用的话则等待响应。因为在一个实施例中将路由当作服务代理的主要消息路径的一部分，因此任何所接收的响应可以被用作在响应处理中的响应消息。在一个实施例中，路由节点包括一组路由。路由识别目标服务(例如服务代理或外部代理)，并且包括用于确定如何可以将消息封装和发送到那个服务的一些另外的配置选择。出站的变换是允许在将消息和环境发送到目标服务之前修改所述消息和环境的一组变换动作。响应变换类似地是被应用到所接收的响应的一组变换动作。在这些实施例的多个方面，通过if-then-else(如果-则-否则)块和路由表的任何组合来使得路由选择是有条件的。

当配置一个路由时，也有被称为跳跃(skip)的用于指定特殊路由的选择。它仅仅是不做任何事情的路由——有效的一个非路由。跳跃在下述方面上表现得像一个路由：它可以被选择并且可以防止任何随后的路由被考虑或选择。但是，不可以使用跳跃路由来发送任何消息，并且不可以期望任何响应。跳跃路由没有进一步的配置。跳跃的目的是允许用户执行清楚地定义当用户不要路由时的情况的选项。

在一个实施例中，出站的变换用于定制可以被发送到目标服务的消息的形状。这潜在包含修改消息本身(例如有效负荷、SOAP报头)以及传输特定细节，诸如传输报头、重试计数、替代的URI等。这可以使用当前在变换级中曝光的所述一组标准的变换动作完成。除了分配、更新和删除之外，出站和响应变换也可以使用条件、WS呼出和提供错误。在一个实施例中，响应变换用于在将消息交给响应路径处理的流水线之前定制响应消息的形状。在此的意图是出站和响应变换可以一起用于有效地在由服务代理使用的请求/响应格式和由目标服务使用的请求/响应格式之间的解译。响应变换也可以用于查看消息级的故障，诸如SOAP或商务故障。如果检测到消息故障，则它可以提供错误条件，就像正规的变换级那样。

在一个实施例中，为了执行条件路由，可以在if-then-else(如果-则-否则)块中包装路由。条件可以是布尔值的XQuery表达式，并且可以任意地嵌套块。在另一个实施例中，最终的动作是路由表的路由。在一个实施例中，路由表包括在转换形式的条件表中包装的一组路由。它是短手(short hand)的构造，该短手的构造允许根据单个XQuery表达式的结果来选择不同的路由。

在一个实施例中，路由表包括单个where(哪里)子句和一组一个或多个case(情况)。所述where子句包含XQuery表达式，并且可以引用消息环境的任何部分。每个情况由比较运算符、值表达式和作为case-action(情况-动作)的至少一个路由构成。因为整个路由节点会导致选择一个路由，因此不支持每个情况多个路由。如果未满足任何在前的情况，则在其所选择的路由的结尾增加一个默认情况。

下面示出了示例路由表，虽然它不必然表示如何在配置控制台中提供所述表。为了清楚，也省略路由细节。

where(哪里)：    数据($message/order-amount)

比较器            值             路由

＞＝             100000        GoldService(金服务)路由

＞＝             10000         SilverService(银服务)路由

否则                           StandardService(标准服务)路由

路由表除了等式之外还支持几个不同的比较运算符。而且，在路由表中的值表达式是XQuey表达式，并且不是简单的恒定值。在这些实施例的多个方面中，通过首先评价在where子句中的XQuery表达式来评价路由表。然后，以通过下述方式而列出的顺序来检验每种情况：通过使用所选择的比较运算符来将where子句与所述情况的值表达式相比较。如果满足所述比较，则可以选择对应的路由。

在一个实施例中，作为路由节点的运行时的一部分而执行消息分派。基本执行流是首先评价条件和路由表以查看是否选择了一个路由。如果未选择路由，则将所述路由节点考虑为完整，并且响应处理立即以消息环境的当前状态开始。如果选择了路由，则向环境应用任何对应的出站变换。所述消息然后通过绑定和传输层而被发送到服务。如果不预期任何响应消息，则认为所述路由节点结束，并且响应处理开始。否则，路由注册仍然被当作活动的，直到响应到达。一旦出现这种情况，则应用响应变换，并且路由节点被认为结束。在一个实施例中，批更新特征允许在服务总线组件被累积和可以被一起应用的“会话”中对它们进行改变。举例来说，用户(经由控制台)或处理创建特殊的“批会话”，其中要累积所述改变。在所述批会话中进行的改变不被存储到“核心状态”，而是它们被保存在会话中。可以在“提交”它们改变之前查看改变。在一个实施例中，不可能立即提交改变。例如，如果提交将导致无效的“核心状态”(例如如果它产生循环，引起未解决的引用等)，则不允许提交。假定可以承诺批会话，则所累积的改变被反映到核心状态。

在一个实施例中，批会话跟踪在会话数据中什么组件被删除、创建或更新。这个数据被保持，以便它在服务总线重启和崩溃时继续存在。核心状态是服务器总线正在运行的主配置。当提交会话时，在会话中进行的改变被反映到核心状态。核心状态最终定义了服务总线的行为。会话视图是由某人在会话中观察的配置的状态。会话视图不是物理数据条目。其通过获取核心状态并且向其应用会话数据获得。批更新是有关在会话中修改服务总线配置，然后提交这些更新之类的活动。

在一个实施例中，批会话(或仅仅是会话)是在服务总线中的批更新支持的中心(centerpiece)。由用户和/或处理创建会话。可以同时创建任何数量的会话。每个会话可以具有由在那个会话中执行的修改确定的系统的不同视图。会话数据是永久的，并且可以在崩溃或重启的情况下继续存在。会话跟踪用户更新、创建和删除了什么组件。这被称为会话数据。会话数据与核心状态一起定义了在那个会话中的会话视图，例如什么组件是可视的以及它们包含什么值。

在一个实施例中，通过经由SessionMBean而调用在会话管理器上的方法来创建会话。可以使用SessionMBean的任何处理来创建会话，或者可以在控制台上创建它。可以在会话中执行配置改变(更新、删除、创建)。可以修改更新配置的服务总线MBean方法以接受会话名称，例如：

public void createService(String session，Ref serviceref，ServiceDefdefinition)；

使用MBeans的外部客户仅仅需要提供会话名称，并且可以在那个会话中累积由那个方法执行的更新。有可能客户在不同的会话中执行所有的多个更新。在下面的示例中，Java代码更新在会话1中的服务，并且删除在会话2中的服务提供者。这两个会话可以具有关于配置看起来像什么的不同思路。会话1可以认为服务提供者仍然存在，并且会话2可以认为服务具有旧配置。

servicembean.updateService(“session1”，service1，newServiceData)；

sericeprovidermbean.deleteProvider(“session2”，serviceprovider2)；

在一个实施例中，控制台用户当它创建新的会话时、或当选择要进去工作的一个现有的会话时进入会话。同一用户可以在不同的会话之间切换，并且不同的用户可以同时工作在不同的会话上。由会话看见的配置的视图与其他的视图以及核心状态不同。如果用户创建了服务A、删除了服务B并且随后请求服务列表，则他应当看见A在列表中而B不在。但是，实际配置(核心状态)不可具有A，而是可以具有B，直到提交了所述会话。在一个实施例中，MBean读取方法(诸如获取器(getter)、列表方法、搜索方法)可以接受可选用的会话参数。如果会话参数是空的，则可以从核心状态获得所述数据。如果会话参数不是空的，则返回由所述会话看见的配置的视图。例如，假定核心状态包含服务B和C。进一步假设用户创建会话S1，并且在这个会话中创建服务A，然后删除服务B，但是不就在此刻提交这些改变。listService(串会话)方法可以返回取决于会话的不同结果：

listServices(null)return B and C

listServices(“S1”)return A and C

控制台用户如果不在任何会话中则看见核心状态。一旦用户满意他的改变，则他可以提交所述改变、进行确认。提交将他已经进行的改变应用到核心状态。一旦提交了一个会话，则将其删除，因为它不再可用。用户也可以丢弃会话，这仅仅删除了会话数据状态，并不对于核心状态有任何影响。用户可以离开他当前所在的会话，而不同提交或丢弃它。这么做允许他看见核心状态，或切换到另一个会话。

图11a-11b图解了按照一个实施例的、在会话中和在核心中执行了各种修改后的核心状态、会话数据和会话视图。使用不同的几何形状来加亮由所述组件采用的不同值。在会话视图中具有粗线的形状指示，所述会话修改了那个组件，因此其存在和值与在核心状态中的同一组件不同。在会话视图中的具有正规线条的形状指示在会话中从未修改过那个组件，因此从核心状态获得其存在和值。

图11a图解了包含组件A、B和C的初始核心状态。在会话中没有任何更新，因此会话视图精确地反映在核心状态中包含什么。图11b图解了在会话数据中的更新。在所述会话中更新组件B。这个事实被记录在所述会话数据中，并且所述会话数据继而与核心状态一起用于计算会话视图。

图12a-c图解了按照一个实施例的另外的会话情况。在图12a中，在会话中创建组件D。注意虽然D在会话视图中是可视的，但是它在核心状态中是不可视的。在图12b中，在会话中删除组件A，因此所述会话视图不再包含组件A。但是，不在任何会话中的用户看见核心状态，并且观察到在核心状态中存在组件A。最后，图12c图解了在核心状态中进行了两个修改(可能由于提交另一个会话)——删除组件B并且更新C——后的核心状态和会话视图。这两个改变在会话视图中不同地表明它们本身。对于C的更新在会话视图中是可视的，因为C从不被所述会话修改。但是，B的删除在会话中是不可视的，因为B被所述会话修改，因此其值是从所述会话数据直接地获得的。这个情况是在会话的数据/视图和核心状态之间的“冲突”的示例。如果由两个会话不兼容地修改了同一项目，则出现这样的情况。除了会话之一被丢弃，否则当提交第二会话时可以解决冲突。

在一个实施例中，会话数据实质上是对于在那个会话中修改(创建、更新或删除)的所有组件的记录(信息)的列表。每个这样的组件精确地具有一个记录，即使它在那个会话中被修改多次(例如它被创建、然后删除，然后再次被创建)。当第一次由会话更新一个组件时创建这个记录。当对于同一组件执行进一步的修改时将所述记录更新。如果取消由会话对于那个组件执行的所有更新，则所述记录被去除。会话数据被保存在文件系统上。还要注意到，会话数据不是自从创建会话时起的配置数据的快照(服务器使用基于快照的数据)

在一个实施例中，下面提供用于创建、更新和删除操作的逻辑。

1)在会话S中创建A：

a)如果在会话中删除A，则创建(更新A的现有会话数据)

b)否则，如果在会话数据中存在A，则错误(不能创建)

c)否则，如果A存在于核心状态中，则错误(不能重建)

d)否则，创建(在会话数据中创建A的新记录)

2)在会话S中更新A

a)如果在会话中删除A，则错误(A不存在于会话中)

b)否则，如果A存在于会话数据中，则更新(更新A的现有会话数据)

c)否则，如果A存在于核心中，则更新(在会话数据中创建A的新记录)

d)否则，错误(A不存在于核心状态中)

3)在会话S中删除A：

a)如果在会话中删除A，则错误(A不存在于会话中)

b)否则，如果A存在于会话数据中，则在正确的引用完整性检查后删除。

c)否则，如果A存在于核心状态中，则在正确的参考完整性查看后删除。

d)否则，错误(不存在于核心状态中)

在一个实施例中，读取操作给出用户正看见会话视图(而不是核心状态)的错觉(illusion)。他们通过使用会话数据和核心状态做这些。下面的逻辑描述了在一个实施例中的读取(获得)操作的实现：

1)在会话S中读取A

a)如果在会话中删除A，则返回空

b)否则，如果A存在于会话中，则返回在其这个会话中的值

c)否则，如果A存在于核心状态中，则返回其在核心状态中的值

d)否则返回空

在一个实施例中，批会话允许用户以严格的逆时间顺序来取消它们已经在那个会话中进行的操作。

在一个实施例中，当正在提交会话时，系统可以适当地反映对于核心状态的改变。所述提交实质上导致对于由所述会话修改的各种组件进行的更新、删除或创建。在一个实施例中，会话的提交可以是原子的(atomic)。换句话说，如果它在中途失败或如果服务总线崩溃，则至此所做的改变可以被退回(rollback)。

在一个实施例中，如果会话的提交不导致不一致的核心状态，则可以提交所述会话。在一个实施例中，如果下面的任何一个为真，则不允许提交：

1)在核心状态中删除在会话中由一个组件引用的一些组件。这被图解在图13a中。组件被创建和引用已经在核心状态中的组件B。然后，从核心状态删除B。虽然核心状态是有效的，但是所述会话包含从A到B的无效引用。

2)对于核心状态的改变可以产生在会话视图中的引用循环。这被图解在图13b中。提交这样的会话将向核心状态引入所述循环，因此不允许提交。通过首先更新A在下面的附图中引入A循环，使得它引用B。然后在核心状态中修改B以引用A。虽然正在观看核心状态的某人会看见从B到A的引用，但是在会话中的用户可以看见引用A的B和引用B的A。

3)图13c图解了由于可以被删除的组件而导致的参考完整性侵害。当在会话中删除组件时，会话管理器检查以保证没有对于那个组件的任何引用。在所述删除后，所述组件不再位于会话视图中。但是，因为由于还没有提交所述会话而导致这个组件是在会话之外的用户可视的，因此有可能在核心状态中的组件被修改以指向由所述会话删除的组件。这样的情况意味着，不能进行所述提交，因为这么做将导致无效的引用。

4)在会话和核心状态中的冲突修改。有可能同一组件在会话中被修改，并且也在核心状态中被修改(由于另一个会话的提交)。例如，会话可以删除组件，而可以使用新值来更新同一组件。用户可以明确地解决这样的冲突更新。在本文中随后更详细地探究这个问题。

5)与在进行中的服务器改变列表冲突。在会话中执行的特定操作导致对于服务器的修改。例如，创建服务通常部署小服务程序(servlet)或Mdatabase。但是。这些改变需要服务器锁定，并且需要在改变列表中被提交(服务器调用它们的会话改变列表)。不幸的是，服务器不允许多个改变列表。如果已经有在进行中的服务器改变列表，则服务总线不能向服务器提交其自己的改变。

表2列出了按照一个实施例的冲突情况和系统如何可以自动地解决这样的冲突。注意到，所述表还列出了不导致冲突的三种并发修改的情况，因为在会话和核心状态中进行了精确地相同的修改。所述表具有四列。第一列表示在修改一个组件之前所述组件的原始值。在此列中的空值表示所述组件原始不存在。第二和第三列分别表示在核心状态和会话中的组件的值。在这些列中的空值指示删除(或根本未创建)所述组件。第四列说明了冲突，并且描述了可以如何解决冲突。在一个实施例中并且参照表2，存在可以由系统解决的三种方式的冲突，它们被定义为ACCEPT SESSION(接受会话)、ACCEPTCORE(接受核心)，以及在冲突更新的情况下的MERGE(合并)。

原始值	在核心状态中的值	在会话中的值	冲突说明和解决选项
				冲突的并发修改情况

V	Vc	Vs	两种冲突更新：用户可以通过进行下列之一来解决这个冲突：a)ACCEPT SESSION：提交使用在会话中的值而重写在核心中的值b)ACCEPT CORE：提交保留在核心状态中的值(有效地丢弃他的改变)c)MERGE：合并在它们两者中的更新。这要求来自控制台的支持1。
				V	空	Vs	在会话中的更新，在核心状态中的删除：解决的方式：a)ACCEPT SESSION：提交使用在会话中的值来重建在核心状态中的组件。b)ACCEPT CORE：提交将组件保持删除(除非这样做导致RI侵害)
V	Vs	空	在会话中的删除，在核心状态中的更新：解决的方式：a)ACCEPT SESSION：提交删除在核心状态中的组件b)ACCEPT CORE：提交使得在核心状态中的组件保持不动
				空	Vc	Vs	两种冲突创建：解决的方式：a)ACCEPT SESSION：提交使用在会话中的值b)ACCEPT CORE：提交使用在核心中的值
空	Vc	空2	冲突创建和创建+删除：在这种情况下，在会话和核心状态中并发地创建组件。但是，在会话中接着删除组件。解决的方式是：a)ACCEPT SESSION：提交删除了在核心中的组件b)ACCEPT CORE：提交将在核心状态中的值保持不动

非冲突的并发的修改情况
				V	Vx	Vx	使用相同值的两个更新
空	Vx	Vx	使用所述相同值的两个创建
				V	空	空	两个删除从不冲突

表2：按照一个实施例的冲突解决方法

¹我不知道是否我们可以如此。

²在这种情况下，所述组件还在会话中创建，但是接着将其删除。

在一个实施例中，更新计划是用于描述要由服务器执行什么动作的对象。在每个服务器上存在的改变管理器负责执行在更新计划中描述的动作。在管理服务器上执行的更新计划可以与在被管理的服务器上执行的不同。

这个部分给出了如何执行更新的很高级的概观。这不意味着是更新和恢复的完整画面。

在一个实施例中，在下面的情况下启动更新：

·用户更新：用户提交批更新。在管理和被管理的服务器上产生和执行更新计划。这些更新通常发生在管理服务器和被管理的服务器上。

·被管理的服务器的恢复：被管理的服务器在长时间的与管理服务断开后发现其配置数据不在数据中。它因此从管理服务器请求更新计划，所述更新计划可以在被管理的服务器上被执行并且可以使被管理的服务器配置成为最新。所述更新大致上是“增量(delta)”。

在用户更新的情况下，首先在管理服务器上执行更新计划，并且如果它成功，则将其同时(或异步地)发送到被管理的服务器，以在那里执行。在被管理的服务器恢复的情况下，被管理的服务器首先发送它所知道的所有资源和它们的版本号的摘要。管理服务器然后将此与其自己的数据相比较，并且如果存在任何差异，则它准备和更新可以在被管理的服务器上执行的计划。

在一个实施例中，使用对于服务总线特殊配置的公知JMS主题来向被管理的服务器发送所述更新计划。每个服务器(包括管理)具有改变管理器组件，它负责接收计划，执行它，并且将结果报告回管理服务器。每个服务器负责执行它接收的更新计划。如果计划执行由于应用失败而失败(例如异常，而不是服务器崩溃)，则服务器负责将由更新计划执行的所有改变退回到在执行更新计划之前存在的配置的状态。换句话说，在服务器上的计划的执行是原子的。它或者成功或者失败。在任何一种情况下，将结果报告到管理服务器。

有可能更新在一些服务器上成功，而在其他的服务器上失败。当此发生时，在成功的服务器上的更新可以被退回或取消。服务器可能在更新的执行期间崩溃。当此发生时，它需要在启动期间执行恢复。在一个实施例中并且举例来说，恢复包含下面的步骤：

1)退回已经执行但是未提交的任何本地工作。因为存在服务器崩溃，因此需要恢复被保持的数据(文件)并且将其退回到它们的先前图像。

2)而且，如果在被管理的服务器上：

a)则向管理服务器发送配置的当前内容的摘要，并且接收增量(delta)。

b)本地应用这些增量以使得被管理的服务器的配置相对于管理服务器保持最新。

在一个实施例中，更新计划描述了需要被应用到服务总线配置的改变。在管理服务器和被管理的服务器上执行更新计划，并且所述更新计划包含用于描述独立的改变的“任务”的列表。在一个实施例中，存在5种任务：创建组件任务；更新组件任务；删除组件任务；创建文件夹或项目任务；并且删除文件夹或项目任务。一般来说，所述更新计划首先执行用于创建文件夹或项目的任务，随后是任何数量的组件任务，并且以删除文件夹和项目的任务结束。

在一个实施例中，在更新计划中的每个任务提供的下面的功能：

·确认：确认被影响而不在系统中进行任何修改的数据。

·执行：一旦确认完成，则仅仅进行执行配置改变。即，它创建、更新和删除填充(stuff)。

图14是按照一个实施例的更新计划执行的图示。此图描述了如何执行更新计划1402和影响什么模块/子系统。此图示出了可以在更新中参与的三种主播放器：专用于特定事物的配置框架中的各种管理器(1400，1404，1406，1408)；数据结构，诸如更新计划、任务等；以及各种全状态(stateful)实体(1410，1414，1416，1418)：这些是保持某个状态的各种片段(piece)。这些是运行时高速缓冲存储器、被保持的数据和在系统中由其他模块保持的其他数据(诸如用于保持被编译的XQuery计划的XQuery管理器)。

在一个实施例中，更新在改变管理器1400获得更新计划1402并且执行它时开始。在本实施例的各方面，更新计划仅仅是可以依序被执行的任务1412的列表。这些任务调用项目管理器1404或组件管理器1406的方法以便更新/创建/删除/重新命名组件1420、文件夹或项目1418。项目管理器和组件管理器继而更新相关联的全状态实体，诸如运行时高速缓冲存储器1414、引用图和文件1416。在另一个实施例中，经由文件管理器来处理文件更新。

在一个实施例中，收听的各种模块对组件(例如服务管理器)1410更新。这些模块注册在特定组件类型上发生的改变，并且当创建、删除、更新或重新命名组件类型的实例时通知这些模块。收听者一般响应于这些通知而更新它们自己的内部状态。例如，传输管理器根据对于服务的定义所做的改变来部署/解除部署/中止/恢复传输端点。这些收听者保存当发生错误时可以被退回的状态。

在一个实施例中，为了便利正确的恢复，改变管理器可以永久地记录关于计划执行的下面的事实：

1)在计划执行的开始，在盘上写入记录，所述记录用于指示已经开始了执行。诸如“STARTED(已经开始)”之类的简单字符串值就足够。

2)在成功执行后，在盘上写入记录，所述记录用于指示所述执行已经成功地结束。诸如“SUCCESS(成功)”之类的简单字符串值就足够。

3)在应用失败后，在盘上写入记录，所述记录用于指示所述执行已经失败，并且正在进行恢复。诸如“FAILED(已经失败)”之类的简单字符串值就足够。

在一个实施例中，在应用失败或服务器崩溃后启动恢复。在第一种情况下，在应用失败后停止更新，并且立即开始恢复。在第二种情况下，当服务器在崩溃后重启时执行所述恢复。退回意味着对(一组)操作没有影响。但是，恢复暗示更一般的活动，其可能包含许多退回，并且潜在地包括许多其他种类的活动，诸如在分布环境中的不同实体之间的数据的交换，或者潜在地包括重新进行操作。尽管如此，这两个术语可以可交换地被使用。

假定一些操作OP将数据的片段(piece)的值(例如状态)从V₁改变到V₂。这个操作可以以两种方式来退回：1)基于值的方法(物理退回)；将V1保存为这个操作的先前图像，然后当退回时回复到那个值；以及2)操作方法(逻辑退回)：在当前值V₂上应用操作OP的逆(称为OP_R)以获得V₁。

在一个实施例中，可以根据那哪个全状态实体正在被退回来使用两种方法。例如，使用用于文件更新的先前图像(基于值的方法)有意义。这允许崩溃恢复以仅仅将所有被影响的文件替换为它们的先前图像。另一方面，为了响应通知而退回由各种管理器执行的状态改变，我们使用操作方法。

图15a是按照一个实施例的成功更新的图示。一般，有可能服务器可能在应用异常后的退回期间崩溃，或者，服务器可能在服务器启动后的恢复期间崩溃。被填充的圆圈表示系统可能崩溃的位置。

在图15b中，由于应用异常而导致执行失败，并且在一个实施例，恢复立即开始。退回计划的执行主要依赖于操作退回方法。

在一个实施例中，当执行一个计划时，它仅仅执行在一个序列中的其每个任务。在执行一个任务之前，对于那个任务创建取消任务。注意这个取消任务基本上是可以用于退回任务的影响的逆操作。在这些实施例的各方面，这些取消任务被保存在存储器中。当一个任务失败时，计划执行停止，并且以逆序来执行所保存的取消任务。例如，假定所述计划具有三个任务、即更新策略P、创建服务S和删除XQuery X，并且XQuery的删除失败。下面的列表枚举了所执行的内容：

1)获得更新策略P的取消任务。将其称为取消任务1。

2)执行“更新策略P”。这成功了。

3)获得创建服务S的取消任务。将此称为取消任务2。

4)执行“创建服务S”。这成功了。

5)获得删除XQuery X的取消任务。将此称为取消任务3。

6)执行“删除XQueryX”。这失败了。

7)开始退回。

8)执行取消任务3。

9)执行取消任务2。

10)执行取消任务1。

在一个实施例中，创建和删除的取消任务是删除和创建任务。对于更新任务，取消任务可以是用于以其原始值来更新组件的另一个更新任务。类似地，对于重新命名任务，取消任务可以是将所述组件重新命名为其原始名称的另一个重新命名任务。所述任务框架也允许程序员定制取消任务。

在一个实施例中，文件的更新不像任务的执行那样以执行/取消形式进行。任务被执行，并且在退回的情况下，其取消任务被执行。对于文件，首先“准备”文件更新，在整个计划执行的结尾，根据是否计划执行已经成功，“提交”或者“退回”更新。例如，假定作为对于组件C1和C2的一些配置改变的结果，要更新/创建/删除配置文件F1和F2。下列情况会发生：

1)改变组件C1。这使得使用相关联的数据来准备文件F1。

2)改变组件C2。这使得使用相关联的数据来准备文件F2。

3)如果整个计划执行成功(例如提交)，则作为最后的步骤，我们进行：

a)提交对于文件F1的更新

b)提交对于文件F2的更新

4)...否则作为退回的一部分，我们进行

a)退回对于F1的更新

b)退回对于F2的更新

下面的表格给出了在一个实施例中如何进行文件的创建、更新和删除。被命名为准备、提交和退回的列描述在那些阶段发生了什么。(这些动作也应用到文件夹的创建或删除)

操作	准备	提交	退回
				CreateFile(X)	声明X不存在创建文件X.new	将X.new重新命名为X	删除X.new
UpdateFile(X)	将X重新命名为X.old，创建文件X.new	删除X.old将X.new重新命名为X	删除X.new将X.old重新命名为X
				DeleteFile(X)	将X重新命名为X.old	删除X.old	将X.old重新命名为X
RenameFile(X，Y)	就好像创建Y和删除X那样来准备	就好像创建Y和删除X那样来提交	就好像创建Y和删除X那样来退回

表3：按照实施例的文件操作

在成功或失败的记录被保持到LAST_TRANSACTION_INFO文件中后执行文件的提交和退回操作。这是允许在正常执行或退回执行期间在服务器崩溃后的恢复的设计决定(当你研究下一个部分的细节时，这可能或可能不对你是显然的)。

图15c图解了由于服务器的崩溃而导致的执行故障以及在服务器重启后的恢复开始。在服务器崩溃后，需要恢复对于被保持的数据(例如文件)的改变。在一个实施例中，这可以由系统按如下来完成：

1)使用LAST_TRANSACTION_INFO文件来确定是否最后的更新是成功的。

2)如果最后的更新失败或在进行(LAST_TRANSACTION_INFO包含故障或开始)，则我们需要退回文件更新，如在前一个部分中所述。基本上，我们搜索被命名为“X.new”的任何文件，并且删除它们，并且将所有被命名为“X.old”的文件重新命名为“X”。

3)如果最后的更新是成功的，则我们可能仍然需要进行一些工作。有可能在写入“成功”记录后更新失败，同时仍然提交文件更新。因此，我们仅仅搜索名称为“X.old”的任何文件，并且删除它们，并且将所有的文件名称“X.new”重新命名为“X”。这类似于“重新进行”操作。

4)一旦恢复了所有的文件，则仅仅去除LAST_TRANSACTION_INFO文件(或将一些空字符串置入其中)。

这种机制允许所述系统恢复文件，即使服务器在恢复期间崩溃多次。

在一个实施例中，以下面的方式来处理被管理的服务器的恢复：

1)在启动期间，被管理的服务器执行本地恢复，如在前一个部分中所述。

2)然后，它联系管理服务器，并且发送关于它知道的配置信息的摘要信息。这个摘要包含它知道的所有组件的ID和它们的版本号。

3)管理服务器将这个摘要与它具有的配置相比较，并且确定被管理的服务器丢失了、已经过期了或仅仅不应当具有什么组件。然后，管理服务器准备仅仅用于那个被管理的服务器的更新计划，所述更新计划当被执行时可以使得所述被管理的服务器相对于在管理服务器上的主配置最新。

在一个实施例中并且举例来说，在松散联合的系统中的执行操作需要两个阶段的提交(2PC)：

1)每个参与者(资源管理器)准备操作，但是还不提交。如果所述准备成功，则它向所述2PC协调者发送OK消息。

2)如果2PC协调者从所有的参与者获得OK，则它发送提交信号。否则，它发送取消(退回)信号。

3)每个参与者从协调者获得决定：是提交所准备的改变，还是将它们退回。

虽然一个图可以将组件描述为逻辑上分离，但是这样的描述仅仅是用于说明性目的。本领域内的技术人员可以显然明白，所描述的组件可以被组合或划分为独立的软件、固件和/或硬件组件。而且，本领域内的技术人员还会显然明白，这样的组件——不论它们如何被组合或划分——可以对于同一计算器件执行，或者可以被分布在通过一个或多个网络而连接的不同的计算器件上或其他适当的通信组件上。

可以使用按照本公开的教导而编程的传统的通用或专用数字计算机和/或处理器来实现各种实施例，这对于在计算机领域内的技术人员会是显然的。熟练的程序员可以根据本公开的教导来容易地准备适当的软件编码，这对于在软件领域的技术人员会是显然的。也可以通过准备集成电路并且/或者通过互连传统的组件电路的适当网络来实现本发明，这对于本领域内的技术人员是显然的。各种实施例包括计算机程序产品，它是其中/其上存储了指令的存储介质(媒体)，所述指令可以用于编程通用或专用计算处理器/器件以执行在此给出的任何特征。所述存储介质可以包括，但是不限于下列的一个或多个：任何类型的物理媒体，包括软盘、光盘、DVD、CD-ROM、微驱动器、磁光盘、全息照相存储器、ROM、RAM、PRAM、EPROM、EEPROM、DRAM、VRAM、快闪存储器、磁卡或光卡、纳米系统(包括分子存储器IC)；纸张或基于纸张的介质；以及适合于存储指令和/或信息的任何类型的介质或器件。各种实施例包括可以整体或部分地在一个或多个公共和/或私用网络上传输的计算机程序产品，其中，所述传输包括可以由一个或多个处理器使用来执行在此给出的任何特征的指令。在各种实施例中，所述传输可以包括多个独立的传输。

本公开包括被存储在一个或多个计算机可读介质(媒体)中的软件，用于控制通用/专用计算机和/或处理器的硬件，并且用于使得计算机和/或处理器能够使用本发明的结果来与用户或其他机制交互。这样的软件可以包括但是不限于器件驱动器、操作系统、执行环境/容器、用户界面和应用。

本发明的优选实施例的上述说明已经被提供来用于解释和说明的目的。它不意欲是穷尽性的或将本发明限定到所公开的精确形式。许多修改和改变对于本领域内的熟练实践者是显然的。实施例被选择和描述以便最佳地说明本发明的原理及其实际应用，由此使得本领域内的其他技术人员能够明白本发明。旨在通过权利要求及其等效来限定本发明的范围。

Claims (32)

1.一种处理服务代理的消息的方法，包括：

沿着在消息处理图中的第一路径的第一方向来传送消息，其中，第一路径包括至少一个消息处理节点；

向所述至少一个消息处理节点的每个提供处理所述消息的机会，其中，所述至少一个消息处理节点之一根据所述消息的至少一部分来执行安全功能；以及

其中，所述至少一个消息处理节点实现与服务代理兼容的接口和/或协议。

2.按照权利要求1的方法，其中：

所述安全功能能够进行下面的至少之一：加密、解密、数字签字、数字签名验证、鉴别、评价策略并且确定访问权。

3.一种用于向过程传送消息的方法，包括：

暴露第二接口，其中，第二接口是第一接口的外观；

经由第二接口来接受消息；

选择处理；

经由第一接口来向所述过程提供消息；并且

其中，对于第一接口的改变不需要对第二接口的改变。

4.按照权利要求3的方法，其中：

接口包括下面的至少之一：消息格式、传输协议、地址、服务定义和安全方案。

5.一种用于处理服务代理的消息的方法，包括：

沿着消息处理图中的第一路径来传送消息，其中，所述第一路径包括至少一个消息处理节点；

选择到目的地的路由，其中，所述目的地是另一个服务代理和服务之一；并且

向所述目的地传送所述消息。

6.按照权利要求5的方法，其中：

所述选择是基于在所述消息中的内容。

7.按照权利要求5的方法，其中：

在所述至少一个消息处理节点中的一个消息处理节点可以引用在所述至少一个消息处理节点中的一个或多个其他的消息处理节点。

8.一种用于监控多个服务代理的方法，包括：

从下面的至少之一收集数据：服务代理、服务代理组件、能够监控服务代理的过程；

随着时间来汇集数据；并且

触发规则的评价。

9.按照权利要求8的方法，其中，所述汇集的步骤包括：保留比较不近期地收集的数据而更近期地收集的数据。

10.按照权利要求8的方法，其中：

所述触发基于以指定粒度在被汇集的数据中的改变。

11.按照权利要求8的方法，其中：

所述触发基于事件的发生。

12.一种用于处理服务代理的消息的方法，包括：

沿着在消息处理图中的第一路径来传送消息，其中，所述第一路径包括至少一个消息处理节点；

向至少一个接收方发布所述消息；并且

向目的地传送所述消息，其中，所述目的地是另一个服务代理或服务中的一个。

13.按照权利要求12的方法，还包括：

根据在所述消息中的内容来选择至少一个接收方。

14.一种用于监控服务代理的方法，包括：

通过下面之一来触发规则评价：服务代理、服务代理组件和能够监控服务代理的过程；

产生被使用来评价规则的环境；

根据环境并响应于触发来评价规则；以及

响应于评价而执行动作。

15.按照权利要求14的方法，其中：

规则包括评价为真或假的一个或多个表达式；并且

其中，表达式可以包括嵌套的表达式。

16.按照权利要求14的方法，其中：

所述环境包括至少一个值，其中，所述至少一个值被用于所述评价中。

17.按照权利要求14的方法，其中：

服务代理是在客户和下面之一之间的中介：服务和另一个服务代理。

18.一种用于处理在服务代理中的消息的方法，包括：

在沿着多个消息处理节点的网络中的第一路径的第一方向上传送消息，其中，所述第一路径包括至少一个所述消息处理节点；

向在第一路径中的每个节点提供处理所述消息的机会；获取与由所述消息识别的资源和/或服务相关的证书；并且

其中，消息处理节点实现与服务代理兼容的协议和/或接口。

19.按照权利要求18的方法，还包括：

向下面之一提供所述消息：服务和服务代理。

20.一种用于动态地重新规划具有第一接口的应用的方法，包括：

暴露第二接口，其中，所述第二接口是第一接口的外观；

从所述第二接口接受请求；

向第一接口提供所述请求；并且

其中，对第一接口的改变不要求对第二接口的改变。

21.按照权利要求20的方法，其中：

接口包括至少下面之一：消息格式、传输协议、地址、服务定义和安全方案。

22.按照权利要求20的方法，其中：

第二接口是万维网服务接口。

23.按照权利要求20的方法，其中，所述提供包括：

动态地向第一接口映射所述请求。

24.按照权利要求20的方法，其中，所述提供包括：

执行下面的至少一个：将所述消息格式转换为与第一接口兼容的格式，使用与第一接口兼容的安全方案、使用与第一接口兼容的传输协议来向所述应用发送所述请求。

25.一种经由具有第一接口的应用来访问信息的方法，包括：

暴露第二接口，其中，第二接口是第一接口的外观；

从第二接口接受请求；

向第一接口提供所述请求；

从第一接口获得信息；

向第二接口提供所述信息；并且

其中，对于第一接口的改变不需要对第二接口的改变。

26.按照权利要求25的方法，其中：

接口包括至少下面之一：消息格式、传输协议、地址、服务定义和安全方案。

27.按照权利要求25的方法，其中：

第二接口是万维网服务接口。

28.按照权利要求25的方法，其中，所述向第一接口提供所述请求包括：

执行下面的至少之一：将所述请求格式转换为与第一接口兼容的格式，使用与第一接口兼容的安全方案、使用与第一接口兼容的传输协议来向所述应用发送所述请求。

29.一种处理服务代理的消息的方法，包括：

在沿着在消息处理图中的第一路径的第一方向上传送消息，其中，第一路径包括至少一个消息处理节点；

允许至少一个消息处理节点的每个来处理消息；

其中，所述至少一个消息处理节点实现与所述服务代理兼容的协议和/或接口。

30.按照权利要求29的方法，其中：

根据消息内容来动态地确定第一路径。

31.按照权利要求29的方法，其中：

所述至少一个消息处理节点中的消息处理节点可以动态地被增加到所述消息处理图或从所述消息处理图去除。

32.按照权利要求29的方法，其中：

在所述至少一个消息处理节点中的一个消息处理节点能够执行下面的至少之一：消息鉴别、消息授权、消息确认、消息变换、消息路由、性能监控、消息跟踪、消息归档、消息记录、消息发布、错误报告和用户定义的过程。

Images