Cortex项目：Web服务的可靠消息发送

技术白皮书　 2002年9月

目录

第1章 实施摘要

Cortex项目是是 TransCanada 管道公司（美洲最大能源公司之一）的 Web 服务开发工作的组成部分。该跨国公司拥有并使用38,000-公里(24,000-里)的自然煤气管道网络。作为独立能源产品的先锋， TransCanada拥有、控制并正在建设总共大约为2250兆瓦特的电能。TransCanada 和数百个能源厂商、商人、买方进行合作。在历史上，TransCanada和它的各个构成部门、单位的主要通过纸进行交互。为了形成一个自动化且流线型的核心商业过程，TransCanada正在创建一个Web服务基础结构。

该总项目—Service Provisioning Infrastructure for a Network Environment (服务提供商基础设施网络环境SPINE)—将成为一个建立在标准基础上的分布式、具有松散的基础且中央处理的Web服务系统。SPINE的目标是创建一个灵活的、可扩展的、开放的并且是可靠的Web服务基础结构，能够在整个公司内部使用该基础结构来降低成本并减少商业解决方案进入市场的响应时间。

SPINE由多个部分组成。Cortex项目为集成的煤气管理应用程序提供了消息发送功能，在代码中将其命名为Dovetail。Dovetail将为公司内外的用户提供单个集成的应用程序集，包括运行在分布环境中的多个独立开发的煤气管理服务。在这组服务中，Cortex提供了可靠的消息发送功能。

Cortex的目标是提供可交互的并且可靠的企业消息发送功能。交付后，这将是一个其他应用程序和服务也能够使用的工具服务。在TransCanada，许多应用程序将使用Cortex交付的产品提供一个一致且独立于平台的面向文档的消息发送。

Cortex使得不同应用程序之间能够通过传递XML文档进行通讯。它能够在同步和异步消息发送中及发布-预定消息环境中进行可靠消息传递。Cortex使用XML消息格式通过Simple Object Access Protocol (SOAP) over HTTP协议能够和其他应用程序及系统进行交互。

Cortex提供了一组丰富的功能。Sun™ 开放网络环境（Open Net Environment）(Sun™ ONE)平台为消息发送和工作流提供了基本的功能。使用Sun ONE消息队列软件产品，Cortex 提供了：

• 可靠的消息发送服务，它适用于来自不同客户端（如使用Java™技术开发的、Web应用程序和Microsoft .Net）的消息，使用Cortex桥使它们适应Java Message Service (JMS) API 。这样，不同的应用程序就能使用通用消息发送环境。
• 有保证的交付产品是用异步回叫或同步消息发送模式。该功能使得Cortex能够用于所有Dovetail 应用程序中。另外，它能够设法解决防火墙问题，能够在企业内部和外部使用Web服务。

Sun ONE集成服务器提供了集成和工作流功能。可以将它和Cortex结合使用，以便提供：

• 工作流功能。可以根据预先定义的一祖规则路由消息；例如，在将事务报告通过账目管理编入每月的报告中之前，先将它路由到信用部门进行查看。
• 通知和例外功能。如果一条消息满足一组特定的规则，那么就能够通知用户或进程，或重新路由该消息。

Cortex具有大量优点：

• 它提高了对TransCanada和它的厂商和合伙人的响应，并能快速集成新服务。它开发的体系结构提供了对TransCanada 系统直接的存取点。客户和合伙人能够集成它们的系统并设计新的应用程序，而不需要跟厂商同步。
• 一旦操作完整，Cortex就提供一个一致的基于标准的方案，能够降低成本。一个综合、集成、可靠的消息发送系统将最小化对“一次性”消息发送系统的使用。
• 能够扩展Cortex满足不断增长的商业需求。Cortex团队希望他们的项目远远超过Dovetail。
• 设计Cortex满足日益增长的可用性。在降低成本和提高响应响应中，TransCanada对它的客户和合伙人开放越来越多的系统和应用程序。这些用户希望24x7x365可用，而Cortex就是用于处理这类环境的。

Cortex是TransCanada 和Sun Microsystems的连接开发项目，它的集成服务由ThoughtWorks提供。该项目利用Sun ONE 体系结构的规则，这样就能利用现有的IT应用程序、数据和系统帮助商业创建Web服务。TransCanada的主要目标是交付消息发送服务的可作产品使用的实现。另外，Sun的目标是为它的iForce SM

Ready Centers交付一个参考实现和便捷的演示。

该技术白皮书包含Cortex可靠消息发送服务工作原理的技术描述，包括体系结构概述和每个Cortex子系统描述。

同时也概述了创建Cortex可靠消息发送服务的技术和设计原则，也从技术上讨论了该项目中的操作、产品和技术。

• 第一部分是Web服务中使用的标准的技术概述，同时也概述了Sun ONE平台。
• 第二部分介绍了Cortex消息服务将使用的各类方案，以及开发Cortex时的关键设计因素。
• 第三部分是Cortex的操作概述。包括每个主要子系统上的细节，并讨论了失败性能、交互性和管理功能。
• 附件包含给该项目提供资源的公司的其他信息，以及例子代码。

第2章 概述

基于Internet技术快速开发和可靠地部署可扩展的、具有高可用性的商业系统是IT产业的主要焦点。为了确保成功，这些系统必须和老应用程序及数据集成，保证组织的多个团体——雇员、合伙人、客户——以及多个设备都能访问它们。

         今天，Web已经成为交付高价值解决方案的的通用平台。实际上任何设备都能够访问服务，包括蜂窝电话、PDA和台式机。当前已经发展了许多技术和协议来集成现有的商业进程和资源，并且通过Web能够获得它们。

         商业使用大量分布式系统选择方案来运行它们的操作：

• 本地应用程序：这些应用程序专门运行在PC上，并且包含通用的office应用程序。其中有一些是基于局域网的。
• 客户端-服务器应用程序：这些应用程序位于大型服务器上，并且通常都是商业关键——财务处理、人力资源、制造——需要大型的后台数据库。客户端服务器应用程序使用这两个专用软件和基于Web的前端。
• Web应用程序：运行在Web上的专用单功能应用程序（如e-mail和日历）通常需要专用客户端软件或使用Java技术前端编写，这样使用任何浏览器都能访问它们。在家里、应用服务供应商（ASP）外部或这两者的结合都能使用Web应用程序。
• Web服务：这些服务运行在Web上并且能够和其他服务组合创造出更加有用更加强大的解决方案。Web服务提供模块化的、明确的并且封装了的函数，将这些函数用于应用程序或系统之间松散集成。
• 操作环境服务：这些服务为群集、动态重配置和高可用性能提供了扩展性和可靠性。它们主要是由Sun的Solaris操作环境（OE）这类操作系统提供的。

Sun使用术语“按需服务”来描述企业如何在任何时间、任何地点及任何设备上利用IT环境来办理事务、汇报商业操作以及同其他人员进行通讯。按需服务这个概念是对数字信息包括计算资源的模块化、灵活、可集成的自动存取。

按需服务理念是一个综合框架，既包含了安全、认证和目录这类传统的基于网络的服务，也包含了更加高级的性能，包括虚拟化存储和合成服务(将单个服务组合起来创建的服务)。

这个理念代表了演化，而不是革命—这些新的服务不会取代其他网络和开发方案。为了使得按需服务模型更加具有吸引力，商业必须能够利用现有的应用资源并将它们作为服务展示。按需服务并没有连接这些资源，而是利用并扩展它们。

Sun为在Sun ONE平台上交付应用程序和服务提供了一个综合产品。并且Sun为那些需要稳定、集成且全球支持的解决方案的公司提供了一套完整的产品和服务。

Sun ONE平台的一个重要的特征就是它是可集成的。由于Sun ONE体系结构基于开放的标准，各家公司能够和已有系统进行交互操作，并且将来有新的附加内容。各家公司也能自己选择他们想要使用的组件和系统，充分利用开放Sun ONE体系结构的优势。开发者可以集成优化解决方案集合的部署所需的技术。现在，开发者提供了一些工具和技术来减少采用新模型的成本、风险和复杂度。

图 1. Sun ONE平台的功能图

现在，Sun ONE平台是可扩展、可靠的基于开放标准的Web应用程序的基础，将来它也会成为按需服务的基础。该体系结构包含（如图1所示，从下向上）：

• OS、硬件、存储器和网络平台：包括定义用户、组织和策略所必需的目录技术。
• 表示、商业逻辑和数据存取：
  • 服务交付在表示层。在该体系结构中，门户服务器给任何设备交付服务，集成内容并提供安全、个性化及知识管理。
  • 服务容器提供了商业逻辑—在运行Web服务的地方—利用应用程序服务器构建Java 2平台、Enterprise Edition (J2EE™) 技术。服务容器包含预先建立的Web服务，企业有可能构建或购买这些服务，这些服务经常存在于现有的商业或通讯应用程序中。
  • 服务集成位于数据存取层。它集成企业中有用的应用程序，如企业到企业（B2B）和EAI应用程序、老应用程序和数据知识库。
• 创建、装配、部署并测试服务。

Sun ONE体系结构为按需服务提供了技术、产品和标准，同时也提供了跨平台的更高级的集成，并定义了跟第三方供应商提供的软件和系统的交互性。Sun ONE体系结构提供了如下功能：

• Web应用程序中间件，包括今天可用的标准的消息发送和Web服务功能。
• Web服务中间件，为基本的XML Web服务提供了新功能。
• 标识和上下文(用户表现、意向和目标) 服务。
• Web客户端模型，它定义了如何在使用Java 2平台、Micro Edition(J2ME™)和台式机Java技术的便携式设备和台式机上使用利用Java技术构建的应用程序。
• 当前，其他中间件接口和核心Web服务是产品接口：目录服务、门户服务、安全和策略、e-commerce服务和通讯能力。
• Java和Web开发工具，包括为Web服务封装老语言的能力。
• Web应用程序和Web服务的系统和应用程序管理。
• 与Web应用程序和Web服务容器相关的平台服务。

Sun ONE体系结构是基于API和协议开放标准的可集成堆栈。它和标准的Web接口紧密结合，并且在此基础上构建交互性策略。如上所示，最佳组合产品能够集成到所有的Web服务解决方案中。

技术

除了HTTP、HTML和SSL这类成熟的Web协议之外，大量新兴技术都支持新的Web服务模型。但是，并不是所有的技术都满足定义完整的标准，但是，在广泛的工业支持下它们快速成长。关键技术如下：

• 可扩展标记语言(XML)介绍了存储在计算机上的XML文档这个数据对象类，并且特别介绍了处理这些对象的程序性能。XML的目标是按照现在HTML的方式在Web上服务、接收和处理标准数据。
• 简单对象访问协议(SOAP) 提供了一种简单的轻量级机制，该机制通过XML在分散的发布环境中交换同等体之间的结构化分类信息。SOAP本身没有定义任何应用语法，如编程模型或特定实现语法；而是定义了一个简单机制，该机制通过模块化打包模型和在该模型内进行数据编码来表示应用程序的语法。这就能够将SOAP应用于各类系统和软件应用环境中。

SOAP由三部分组成：

–The SOAP 信封结构定义了一个总的框架，包括消息的内容有什么、谁能处理它并且是可选的还是强制的。

–SOAP 编码规则定义了用于交换应用程序定义的数据类型实例的串行机制。

–SOAP RPC表示法定义了用于表示远程过程调用和响应的转换。

• Web服务描述语言(WSDL) 是用于把网络服务描述为一组对消息（这些消息或者包含源于文档的信息，或者包含源于过程的信息）的终端操作的XML格式的语言。抽象描述操作和消息，然后将它们绑定到具体的网络协议，格式化消息以对终端进行定义。将相关的具体终端结合在一起形成抽象终端（服务）。WSDL是可扩展，这样便于对终端和消息进行描述，而不管通讯时使用了什么样的消息格式和网络协议。
• 统一描述、发现和集成(UDDI) 是Web服务的基于Web的分布式信息注册的规范。UDDI也是一组公开的规范的实现，商家利用它来注册他们提供的Web服务的信息，这样其他商家能够找到这些信息。UDDI项目的核心组件是UDDI商业注册，它使用XML文件来描述商业实体和它的Web服务。

从理论上来讲，UDDI商业注册提供的信息包含三个组成部分：

–白皮书，包括地址、联系人和已知标识。

– 黄皮书，包含标准分类基础上的工业类别。

– 绿皮书，商家展示的服务的技术信息。
  绿皮书包括到Web服务规范的参考，在需要的时候，它还包括到各类文件和基于URL的发现机制的指针的支持。

• 电子商业XML (ebXML)是一个用于标准化电子商业数据交换的世界范围内的项目。EbXML的基本目标是创建一个全球电子市场。要实现它必须要开发一组全球统一的规范。EbXML是一个完整的B2B框架，基于该框架能够通过共享基于Web的服务进行合作。该框架支持表示成服务更改设计序列的B2B进程的定义和实现。企业之间的XML消息传递可能使用ebXML提供的SOAP (或扩展到SOAP)。EbXML消息传递使得能够安全并可靠地发送，不受到程序员的干涉。
• 许多年以来，无论是从后端服务器还是到客户设备，Java技术(基于Java编程语言)一直都是Web开发的核心技术。Enterprise JavaBeans™ (EJB™)、J2EE、Java Servlet和JavaServer Pages™ (JSP™)技术使得许多按需服务成为可能。利用出现的Java规范Java APIs for XML能够使用熟悉的JSP和EJB组件为Java平台创建按需服务。这包括使用XML、目录、服务仓库和消息的技术和协议，也包括现有服务的传递。

另外，Cortex项目采用了下列关键Java技术：

– J2EE 平台是开发和部署企业应用的环境。J2EE平台包括一组服务、应用程序、API和协议，它们提供了开发基于Web的多层应用的函数。J2EE技术主要用于主机范围内的计算，特别是大型企业。这样，它创建了标准的可重用模块化组件，并使得J2EE容器能够自动处理编程的各个方面，从而简化了应用程序的开发并减少了编程需求和对程序员的培训。

– Java API的XML消息发送机制(JAXM)提供了一个从Java平台到整个Internet发送消息的标准方法。基于SOAP 1.1 和带有附件规范的SOAP，可以扩展它来处理高层消息协议如ebXML。

一条JAXM消息由两部分组成—必需的SOAP部分和可选的附件部分。SOAP部分，由一个SOAPEnvelope对象组成，包含一个SOAPHeader对象和一个SOAPBody对象，可以将XML数据保存为要发送的消息的内容。要发送一个或多个完整的XML文档或非XML数据内容，该消息就必须包含一个附件部分。对附件部分的内容没有任何限制，可以是图像或任何其他要发送的Internet多用途邮件扩展（MIME）编码内容。

– Java命名和目录接口 (JNDI) API提供了对一个命名环境的存取。它也提供了处理目录操作的方法，如将属性和对象结合起来，并使用它们的属性查找对象。

– Java消息服务 (JMS)是消息发送的标准API，它支持可靠的点到点消息发送和发布-预定模型。JMS API为Java程序创建、发送、接收和读取企业消息系统的消息提供了一个通用方法。企业消息发送产品（或有的时候称为面向消息的中间件MOM产品）成为集成公司内部操作的必要组件。它们允许将单个商业组件组合成一个可靠的但是灵活的系统。Sun ONE体系结构的非同步可靠消息组件是建立在JMS API规范之上的。

Web服务

现在，术语Web服务 具有特殊的含义，并且该含义已经被工业供应商和分析家所接受。Web服务是自描述组件，能够在整个Internet上发现并采用其他Web服务来完成复杂的任务。不同于硬接线应用程序—例如，台式机或客户端服务器应用程序—Web服务的耦合非常松散，并且能够动态定位并和Internet上的其他组件进行交互从而提供服务。

Web服务主要传递XML消息。这种传递在远程过程调用风格中能够同步发生，而在可靠的消息发送风格中则能够异步发生。RPC的主要标准是SOAP。在可靠的消息发送风格中可以使用消息总线如JMS或出现的ebXML消息发送服务。

在图2中，一个开发工具正在访问UDDI注册表来查看可以获得哪些服务。该注册表可以是公有或私有企业注册表。该工具通过发送SOAP协议的XML消息浏览注册表。在注册表内是可用服务的描述，以及用WSDL描述的服务和接口项。该模型叫做静态查找，因为在开发的时候执行服务查找。

图 2. Web服务功能图

Sun推荐采用Web服务的时候使用阶段方法，如Sun ONE体系结构指南所记载的。可以看到越来越多的企业采用各类Web服务技术。通常，企业首先采用XML，然后使用SOAP和WSDL技术创建静态Web服务。以后，实现UDDI，激活更多的动态服务。TranCanada在他们的基于Web服务技术的系统演变过程中采用了该方案。

消息发送概述

消息发送是软件组件或应用程序之间的通讯方法。消息发送系统是一个peer-to-peer设备。消息客户端能够发送消息到任何其他客户端，也能从任何其他客户端接收消息。每个客户端连接到一个消息系统，该系统提供创建、发送、接收和读取消息的功能。

消息发送启动了松散耦合的通讯。组件将消息发送给目标，接收方能够从目标处浏览或接收消息。然而，该通讯并不要求接收方和发送方同时可达。实际上，发送方不需要了解接收方；反过来，接收方也不需要了解发送方。发送方和接收方只需要知道消息的格式是什么以及使用的目标是什么。

注意，消息发送不同于紧密耦合的技术，如远程方法调用(RMI)。紧密耦合的技术要求应用程序知道远程应用程序的方法。消息也不同于e-mail，e-mail是人与人之间通讯的方法（或软件应用程序和人），而消息则是软件应用程序和组件之间的通讯。

Cortex模型支持传统的点到点操作模式，也支持发布预定消息发送。

在Cortex模型中，客户端将消息交付授权给消息代理。Web服务客户端只对由代理保证的消息交付产品感兴趣。通过在消息出现问题的时候接收到肯定的确认信息来保证这一点。

如果客户端对目标Web服务接收的请求的最终完成状态感兴趣，那么脱离上下文的消息必须响应客户端。目标服务初始化返回的消息。客户端负责解释消息并在必要的时候将它联系到它原来的上下文环境中。

第3章 方案

Cortex项目的目标是交付一个可互用的并且是可靠的消息发送服务，包括一个可重用的企业消息发送解决方案，该方案主要用于进行异步数据交换。通过将简单、一致的方案升级为应用交互，开发团队希望能够简化企业开发并在应用程序之间进行松散耦合的、可靠异步交互。

Cortex项目正在开发一个能够形成产品的系统，该系统交付企业消息发送平台，从而：

• 创建替换多个和所有消息发送服务的能力。
• 降低许可成本。
• 降低实现和维护成本。

企业消息发送系统采用Web服务的形式，能够完整灵活地处理企业的消息发送需求。服务层必须至少等于使用系统的企业应用。

交付产品

Cortex消息发送服务包括大量本文档中介绍的组件，包括一个JMS代理实现、LDAP数据存储、JAXM 提供器、 HTTP桥和一个API，以及配置和支持创建的消息发送服务的管理工具。

能够从Sun的iForce Ready Centers获取一个源代码和目标应用程序的演示程序，该演示程序显示了Cortex消息发送服务的性能。

操作方案

Cortex团队和TransCanada的IT Business Solution delivery（IT 商业解决方案传递） 团队合作找出不同类型的消息方案。这些方案介绍了TransCanada部署中遇到的所需要的消息发送需求。

在每个方案中，同步关系是客户端到消息服务层的核心。当客户端讨论Cortex桥时，希望能够马上获得确认(ACK)。该回应来自于消息服务层，并且由于交互是异步的，这在应用层没有任何用处。

在下面的介绍中，根据习惯排列注释顺序。按事件发生的年月顺序进行编号，字母代表了不同的执行线程。

点到点异步无响应—方案 1

在图 3中，客户端给Cortex发送一条消息，这条消息将交付给目标Web服务。该方案是异步“雇佣和遗忘”（ “fire and forget”），客户端发出消息之后，就会将它遗忘。 Web服务客户端唯一接收到的响应是来自于Cortex的同步ACK响应。

如果消息服务确认客户端的请求，那么客户端就能保证消息将被交付到目标Web服务。换句话说，如果客户端发送请求的时候，目标Web服务没有启动，那么它就不会对客户端进行任何响应。注意，如果需要的话，能够对目标Web服务进行间歇性连接。

图 3. 消息发送方案 1

点到点异步响应——方案2

图4中，该方案处理来自或去往客户端和目标Web服务的完整的异步通讯。通过Cortex发送消息，并且Web服务客户端稍后接收响应。

当目标Web服务需要很长时间响应请求（可能需要几个小时）时可以使用该方案。例如，在发送响应之前可能需要人为干涉或大的事务。消息服务负责保证由目标Web服务接收请求，目标Web服务发送请求并由Web服务客户端接收响应。

图4. 消息发送方案2

发布和预定异步无响应—方案 3

在图5的方案中，将SOAP消息发布给客户端预定的多个Web服务，它发送单条消息，该消息马上传递给所有的服务。注意，通常将发布和预定方案应用于没有响应的时候。

图5 消息发送方案5

安全

应用层

Cortex并没有在应用层介绍安全问题，因为由中央策略服务器处理所有的安全。另外，多个基础安全层位于：

• 操作系统：受到用户账号的保护。
• Sun ONE消息队列：本地MQ认证和授权
• LDAP：受到用户账号的保护。

希望TransCanada以后发布的Web服务交付的管理工具能够处理特定Web服务的安全问题。

服务层需求

Cortex服务层将成为商业关键，因此将具有24x7的运营保障。消息发送服务的可用性至少等于企业应用和服务的当前需求。

关键的设计决策

在项目开发阶段，Cortex开发团队做出了大量关键结构决策。下面将具体介绍。

目标对URL

Cortex引入了目标（target）这个概念，在SOAP消息头中进行声明，呼入桥使用它来解析每个消息的JMS目标名。在默认情况下，呼入桥识别的每个JMS目标名解析成一个同等的目标名。另外，目标也能是JMS目标名的别名。通过这种方法， 目标在客户端和Cortex是及JMS目标配置中放置了一个间接层，将客户端和目标的目标地址更改隔离开来。

呼出桥的客户能从JMS目标中取出里面的消息，并将它放置在目标Web服务的URL后。然而，看起来目标这个概念增加了层的复杂度—为什么不在SOAP消息头中直接声明目标Web服务的URL？—有很多原因可以解释为什么不在SOAP消息中直接指定目标Web服务的URL。主要有：

• 支持所有的URL，Cortex必须支持动态创建JMS目标，以便提供有序可靠消息。 由于JMS规范没有介绍JMS目标的动态创建或配置，Cortex必须使用供应商指定的API调用，这跟独立于供应商的设计目标相违背。
• 直接指定URL就避免了呼出桥查找想要的目标Web服务的URL的可能性。
• 和纯JMS客户端交互是可以妥协的，因为对于JMS客户端来说URL没有任何意义。

SOAP头元素

在SPINE初始化的开始阶段，开发了一个服务代理来支持异步可靠消息发送。服务代理希望嵌入在出去的SOAP消息中的到达目标Web服务的SOAP消息能够到达服务代理。另一方面，Cortex将头元素放置在消息中，这和工业的使用单个SOAP消息的方向更加一致。所以，Cortex是到目标Web服务的透明的代理。

当前，Cortex能识别两个SOAP头元素。

• Target：呼入桥所需要的SOAP头元素是目标。
• Message ID：能够识别的另一个SOAP头元素是唯一的消息ID。这个头元素非常有用，它在响应和请求的连接中起到了关键的作用，确保了“仅有一次”的消息传递，并使得在传递过程中能够记录日志和跟踪消息。但是，目前Cortex中的消息ID的唯一用处就是联系响应消息和请求消息。

按序交付

Cortex不仅按可靠的方式将消息交付到目标Web服务，而且交付的顺序和接收的顺序相同。然而，由于缺少商业需求，该设计决策是一个逻辑决策。

JNDI

Cortex的呼入桥和呼出桥从JNDI兼容目录服务器上获取它们的配置。这样做能够确保独立配置桥的Web档案 (WAR文件)。换句话说，当桥的配置更改后，没有必要重新建立WAR文件。

另外，Cortex使用JNDI支持推荐的从JNDI中检索JMS连接库和JAXM提供器的连接库的规则。

消息确认

由于在SOAP规范中缺少标准的机制来应答收到的SOAP消息，Cortex项目团队采用了一个规则，那就是确认所有没有包含SOAP失败的SOAP消息。使用该规则有一个好处，那就是以前老的Web服务能够确认应答来自Cortex的请求，并且不需要修改其代码。

主题

为了支持上面介绍的消息方案，Cortex仅仅依赖于JMS主题。

方案2和方案3都需要JMS主题，因为不止一个客户将从JMS目标获取消息。然而，要实现方案1也需要JMS队列或主题。

项目团队认为根据商业需求Cortex将支持JMS队列和主题。

配置文件

可以将呼入桥和呼出桥物理部署在不同的机器上，也可以将Cortex的配置分在两个不同的配置文件中：inbound和outbound。当配置仅影响到呼入或呼出桥的时候，该方法特别有用，因为这不需要完全中断系统。其他设计因素

下面是构建过程中会遇到的其他重要设计因素。

消息仅传递一次

由于HTTP的本质，在不同客户端和目标Web服务合作的情况下，任何基于HTTP的消息发送服务都不能确保仅传递一次消息。

仅传递消息一次意味着目标Web服务接收消息一次并且仅一次。至少传递消息一次意味着目标Web服务接收消息一次或多次。

目前，Cortex支持从盒子中至少传递消息一次。前面已经提到，在客户端和目标Web服务参与的情况下，可以实现仅仅传递消息一次。实现仅仅传递消息一次的关键是使用唯一的消息ID。概括地说，就是要客户端确保所有出去的消息必须具有唯一的ID。另一方面，目标Web服务每次接收到消息的时候都进行检查，如果接收到的消息以前早就接收过了，就对该消息进行适当的处理。如果处理成功的话，目标Web服务就缓存消息的ID一次，并且也能缓存响应。

位置独立

虽然现在没有实现目标Web服务位置独立，但是Cortex支持该功能。通过使用目标，提取目标Web服务的URL，呼出桥能够自由地执行任何类型的查找（例如，使用UDDI注册表）。注意，从Web服务客户端来说， Cortex提供了目标Web服务的应用层位置独立。

消息的翻译和转变

在消息发送环境中，经常会出现SOAP消息的翻译和转变。包括：

• 客户端发送消息之前。
• 目标Web服务处理消息之前。
• 目标Web服务的运行容器处理目标Web服务接收到的消息之前。
• 在工作流管理或集成服务器产品（例如，Sun ONE集成服务器）这类中间件产品中。
• Cortex内。注意，当前Cortex仅仅支持JMS消息和SOAP消息格式之间的转换。当有其他选择的时候，它并不解释消息的内容（通过XSLT），如上所示。

第4章 体系结构

Cortex主要是为使用Sun ONE消息队列和Sun ONE 目录服务产品提供可靠的SOAP消息发送服务。然而Sun ONE 集成服务器不是必需的，但是使用它可以提供其他功能。Cortex是用servlet构建的，并使用了JMS和JNDI API。JAXM 协议启动了SOAP功能。

操作概述和模型

从逻辑上来说，可以将Cortex组合成两个组件，呼入桥和呼出桥。

呼入桥负责通过HTTP接收SOAP消息，将它们转换成JMS消息，并将它们传输到JMS目标。呼入桥的配置存储在JNDI兼容目录服务器内。

呼出桥负责从JMS目标接收JMS消息，将它们转换成SOAP消息，并通过HTTP将它们发送给目标Web服务。呼出桥的配置存储在JNDI兼容目录服务器内。

呼入桥和呼出桥之间的唯一集成是通过JMS实现的。使用JMS兼容消息代理是因为它提供了可靠的消息输出。创建Cortex组件通过HTTP网关提供进入JMS或者从JMS出来的SOAP。

图6提供了Cortex体系结构的功能图，从左上角开始：

1.来自客户端的SOAP格式的消息通过HTTP进入呼入桥，这是一个JAXM servlet。使用inbound配置文件配置该servlet，该配置文件是XML格式并是从JNDI兼容目录服务器接收的。

2.JAXM servlet接收该消息，将它转变为JMS字节消息，并传递给JMS消息代理。JMS字节消息放置在JMS主题上。

3.呼入桥将接收到的消息确认返回给原来的客户端。

4.呼出桥内的客户接收JMS字节消息，配置了该客户来监听来自任何数目的JMS主题的消息。

5.呼出桥从JMS封装器取出消息并将它转换成SOAP消息。

6.呼出桥将消息发布给合适的目标，该目标是由outbound配置文件设置的（也是XML格式，并且从JNDI兼容目录服务器检索来的）。

7. 目标响应接收到的消息。

图6. Cortex消息发送功能图

图6底部的连接工厂提取了开发者使用JMS API的一些细节，使得发送SOAP消息的时候能够使用JNDI。通过使用JAXM Provider规范，在必要的时候，Cortex就能实现ebXML。

该体系结构具有两个明显的优势。第一，客户端（或其他产品应用程序）不需要知道任何用户的物理地址。第二，所有客户端的目标地址是消息生产者，由呼出桥集中管理。

图7给出了呼入桥和呼出桥的更加详细的细节。

图 7.  Cortex的逻辑图

呼入桥

• 呼入桥是由HTTP servlet、消息逻辑和JMS生产者构成的。

JMS生产者是一个JMS客户端，它生产出到JMS目标的消息。呼入桥仅仅使用一个多线程的JMS生产者。

• 消息逻辑使用配置文件分析SOAP目标。
• JMS生产者将消息发布到JMS主题。

呼出桥

• 呼出桥是由一个或多个JMS客户、消息逻辑和HTTP客户端组成的。JMS客户是消耗JMS目标消息的JMS客户端。
• JMS客户(客户端)选取一条消息，并将它从JMS消息转变为SOAP消息。
• 将消息传递给目标Web服务。
• 如果希望能够获得该条消息有意义的响应，outbound servlet能够在消息上加上正确的ID。这样做是为了避免失败—能够弄明白是否消耗了该条消息。

有一点必须要提的是呼入和呼出桥之间唯一的集成是通过JMS实现的。这就允许呼入和呼出桥无状态，并在出现灾难性故障后能够迅速恢复。

HTTP消息

呼入桥是一个HTTP POST，并将接收满足SOAP 1.1消息规范或带有附件规范的SOAP 1.1消息。

SOAP消息唯一的先决条件是消息的SOAP头中包含目标。下面的代码例子高亮度显示了目标代码：

<soap-env:Envelope xmlns:soap-env=“http://schemas.xmlsoap.org/
soap/envelope/”
xmlns:spine=“http://www.tcpl.ca/spine”>
<soap-env:Header>
<spine:Target>sampleTarget</spine:Target>
</soap-env:Header>
<soap-env:Body>
…
</soap-env:Body>
</soap-env:Envelope>

JMS 消息

呼入桥一旦接收到SOAP 1.1 消息或带有附件的SOAP 1.1消息，它就会创建一个等价的JMS字节消息。通过将SOAP消息的内容直接作为流输出到JMS字节消息的字节中，就能够非常容易地将SOAP1.1消息转换成JMS字节消息。

带有附件的SOAP 1.1消息的复杂度更高，因为SOAP消息不再是简单的XML内容，而是多部分组成的MIME消息。为了分析该消息，必须要特定的MIME头。当将SOAP消息传递到呼出桥的时候，这些都出现在HTTP头中。因此，必须将这些MIME头作为JMS属性存储在JMS消息中。

Cortex提供了工具类JMSUtils，该功能能够帮助将SOAP消息转变为JMS字节消息，或将JMS字节消息转换为SOAP消息。

互操作性

虽然存在呼入桥和呼出桥，但是应用程序仍然和JMS直接交互或和其他桥组合。这就给提供Web服务的消息基础提供了极大的方便。

操作

消息发送方案1

图8是点到点异步无响应模式：

• 客户端和消息发送服务同步
• 消息发送服务和目标同步

图8. 消息发送方案1

1. 通过HTTP将SOAP消息传递给呼入桥。

2. 呼入桥从SOAP消息中检索目标。

3. 呼入桥查询它的配置，并将目标映射到配置的JMS主题。

4. 呼入桥将SOAP消息转换成JMS字节消息。

5. 将JMS字节消息放置在JMS主题中。

6. 呼入桥确认原始调用，响应没有包含SOAP失败的SOAP消息。

7. JMS字节消息是由呼出桥中的客户（持久客户）接收的，在JMS主题中进行配置让它监听消息。

8.呼出桥中的客户将JMS字节消息转换为SOAP消息。

9. 呼出桥的客户将SOAP消息放置在它的配置的目标Web服务的URL上。

10. 目标Web服务接收请求并执行完成它必要的商业逻辑。

11.完成时，目标Web服务使用不包含SOAP失败的SOAP消息进行响应。

12. 接收和确认时，呼出桥的客户执行原来接收到的JMS字节消息。

消息方案2

图9是点到点异步响应：

• 客户端和消息服务异步
• 消息服务和目标异步

图9. 消息方案2

1.通过HTTP将一条SOAP消息传递到呼入桥。

2.呼入桥从SOAP消息中接收目标。

3.呼入桥查询自己的配置并将它映射到配置的JMS主题。

4.呼入桥将SOAP消息转变为JMS字节消息。

5.将JMS字节消息放置在JMS主题上。

6.呼入桥确认原始调用，响应没有包含SOAP失败的SOAP消息。

7.JMS字节消息是由呼出桥中的客户（持久客户）接收的，在JMS主题中进行配置让它监听消息。同时，也将客户配置成现有响应的响应主题，称作blocking 客户。

8.呼出桥的客户将JMS字节消息转换为SOAP消息。

9.呼出桥的客户将SOAP消息的目标设置对应于响应目标，这是目标Web服务响应所需的前两条消息。

10.另外，呼出桥的客户确保SOAP消息具有唯一的消息ID，这样就能将响应和请求联系起来。消息ID是目标Web服务进行响应所需的第二条信息。注意，如果接收到的SOAP消息中没有包含消息ID，那么，就将JMS 消息ID作为SOAP消息的唯一ID。这样做后，回滚的时候，将使用相同的ID。

11.呼出桥的客户将SOAP消息放置在它的配置的目标Web服务的URL上。

12.目标Web服务(异步处理的)接收请求并马上使用不包含SOAP失败的SOAP消息进行响应。

13. 当监听到达的响应主题的响应时，呼出桥的客户阻塞指定的一段时间。不但一个消息必须到达，而且响应消息必须和请求的SOAP消息具有相同的消息ID。这样，就能将阻塞的客户和请求联系起来。抛弃任何没有关联起来的响应消息。

14.目标Web服务执行任何完成请求所需要的商业逻辑。

15.完成时，目标Web服务形成了给呼出桥使用的响应SOAP消息。

16.在发送之前，目标Web服务从原来的请求中提取目标和消息ID，并在响应消息中设置它们。

17.目标Web服务通过HTTP将响应SOAP消息传递给呼出桥。

18.呼入桥从响应SOAP消息中检索目标。

19.呼入桥查询它的配置并将目标映射到配置的JMS主题。

20.呼入桥将响应SOAP消息转换成JMS字节消息。

21.将JMS字节消息放置在JMS主题上。

22.呼入桥确认目标Web服务，使用没有包含SOAP失败的SOAP消息进行响应。

23.接收到确认的时候，目标Web服务的任务就完成了。

24.由于现在将响应消息放置在一个主题上，并且将它和请求联系起来了，阻塞的客户就不再阻塞了。

25.所以，阻塞的客户能够提交原来接收到的JMS字节消息。

26.同时，配置其他回调客户，让它们发送响应给客户端。回调客户发送并递交接收到的JMS字节消息。

(如方案1所示)。

消息方案3

图10 是发布预定异步无响应：

• 客户端和消息服务同步。
• 消息服务和目标同步

图10. 消息发送方案3

1. 通过HTTP将SOAP消息传递给呼入桥。

2. 呼入桥从SOAP消息中检索目标。.

3. 呼入桥查询自己的配置并将它映射到配置的JMS主题。

4. 呼入桥将SOAP消息转变为JMS字节消息。

5. 将JMS字节消息放置在JMS主题上。

6. 呼入桥确认原始调用，响应没有包含SOAP失败的SOAP消息。

7. JMS字节消息是由一个或多个呼出桥中的客户（持久客户）接收的，在JMS主题中进行配置让它监听消息。

8. 呼出桥的客户将JMS字节消息转换为SOAP消息。

9. 呼出桥的客户将SOAP消息传递给配置的目标Web服务URL。

10. 每个目标Web服务接收请求。

11. 每个目标Web服务执行任何必须的商业逻辑来完成请求。

12. 完成时，每个目标Web服务使用不包含SOAP失败的SOAP消息进行响应。

13. 接收到确认时，呼出桥的客户提交原来接收到的JMS字节消息。

互操作性

如图11所示，实际上，Cortex为Web应用程序、Java技术应用和.NET应用程序这类应用环境的任何客户端应用或Web服务接口提供可靠的消息发送能力。呼入桥的主要设计目标是让它能够接收任何标准的SOAP1.1消息或带有附件的SOAP1.1。理论上，这意味着和呼入桥进行通讯的时候，客户端可以使用任何SOAP 1.1-兼容消息产生API。应用程序和服务能够使用SOAP到HTTP进行通讯，也能使用JMS API直接和JMS代理进行通讯。

图11. 企业应用和服务的Cortex Provides消息发送

JAXM消息发送包

对于Java技术服务，javax.xml.soap 包(JAXM的一部分)包含创建和显示SOAP消息的API。另外，该包中还包括发送同步请求-响应消息的必要的API。

JAXM javax.xml.messaging 包中包含使用消息提供器所必须的API，具有发送单向消息的能力。Cortex开发了JAXM提供者连接的两种实现方法：

• JAXM HTTP提供器连接：简化了创建和通过HTTP将SOAP消息发送到呼入桥的工作。客户端不需要指定呼入桥的URL，因为这是在运行提供者连接实现的时候配置的。
• JAXM JMS 提供者连接：允许客户端旁路呼入桥并直接将SOAP消息发送到JMS目标。类似于HTTP提供器连接实现，客户端唯一需要关心的是指定目标。

失败和恢复

可靠消息发送系统的标记是保证消息发送的能力。如果某条消息没有发送，可靠的消息系统必须能够检测出该失败，再次传递该消息，并在必要的时候进行提示。

本部分详细介绍常见的失败点。根据可靠消息发送的本质，如果没有接收到确认，Cortex假设没有消耗该消息，并努力再发送一次。五个常见的失败点影响端到端的消息发送：

1. 呼入桥崩溃

2. 呼出桥崩溃

3. JMS 消息代理崩溃

4. 目标Web服务崩溃

5. JNDI 兼容目录服务器崩溃

呼入桥崩溃

如果呼入桥没有运行，客户端不能通过HTTP连接到Cortex。客户端将接收到一个例外，表明它们不能连接到servlet，或接收到一个SOAP失败表明呼入桥没有运行。

呼出桥崩溃

如果呼出桥失败，客户端将消息发送到呼入桥或直接发送到JMS，这将不会受到影响。JMS消息代理内能够收集消息，直到呼出桥恢复在线或重新启动。

JMS消息代理崩溃

JMS消息代理失败将会导致呼入桥和呼出桥都不能建立到代理的连接。从客户端来说，呼入桥将返回一个SOAP失败。本质上，在JMS消息代理恢复在线之前，不能通过呼出桥发送任何消息。当出现该情况时，呼出桥将自动重新连接并传递任何没有完成的消息。

目标Web服务崩溃

如果目标Web服务崩溃，呼出桥就不能将消息传递给目标Web服务。所以，呼出桥将发送给该服务的消息挂起指定的一段时间。呼出桥本身不会处于睡眠状态，但是目标Web服务中的JMS客户会进入睡眠状态。多个JMS客户被呼出桥包围，所以其他JMS客户仍然处于活动状态。

间隔了一段特定的时间后，呼出桥将尝试重新发送消息。只要消息发送不成功并且JMS字节消息本身没有过期，该循环就会继续。为了保持有序发送，到目标Web服务的所有其他消息将排列在JMS消息代理中，直到Web服务恢复在线。

JNDI兼容目录服务器崩溃

根据事件的顺序，由于JNDI兼容目录服务器崩溃引起的例外将通过多种形式显示。可能呼入桥和呼出桥都不能启动，因为它们对连接工厂的查找将失败，它们不能接收它们的配置，且客户端将接收JNDI命名例外。

管理

概述

本节详细介绍了Cortex管理，这是通过管理这些逻辑组件实现的：

• 呼入桥
• 呼出桥
• JNDI
• JMS

管理员和开发者能够使用命令将对象绑定到JNDI库或解绑。

注意，呼入桥和呼出桥的所有配置都放置在LDAP中的Cortex JNDI库中。通过修改inboundconfig.xml

或 outboundconfig.xml 能够更新这些配置，然后将它们重新绑定到LDAP库。

呼入桥

通过使用XML文件实现呼入桥的配置。呼出桥也提供了简单的管理GUI，用来启动并终止呼入桥，并显示当前的呼入配置（图14）。在管理servlet中能够获得呼入桥管理界面（图12）并位于部署的URL的

/inbound/bridge 处。

图12. 呼入桥管理界面

呼出桥

类似于呼入桥，也使用XML文件实现对呼出桥的配置。同样，呼出桥提供了一个简单的管理GUI（图13），用来启动并终止呼出桥，也用来显示当前呼出配置。在位于部署的URL下的/outbound/bridge 的管理servlet中能够获得呼出桥管理界面。

图 13. 呼出桥管理配置

JNDI

JNDI用于存储所有的Cortex的配置和部署属性。另外，Cortex使得通过JNDI能够获得JAXM provider connection factories。

提供了独立的呼入和呼出管理应用程序，用来帮助将所需要的属性和JNDI兼容目录服务器绑定、重绑定和解绑。

图14.呼入桥管理配置

图15.呼出桥管理配置

JMS

最后，Cortex要求将合适的JMS目标(主题和队列)配置成桥的配置里的参考。

由于JMS规范中没有提到这一点，就需要JMS消息代理的特定供应商管理。

协调工具

使用蚂蚁目标test.load 能够获得消息服务的性能提示。该测试运行在一组基准之上，将2000条消息发送给服务并定时输出。将每秒发送的消息数打印在屏幕上。通过该测试能够评价任何协调方法。

第5章 结束语

Cortex是SPINE Web服务初始的关键构成模块。对于创建广泛可用的Web服务来说，基于开放标准的可靠消息非常关键。最终目标是提供按需服务—实际上将Web服务传送到任何设备。

Sun交付按需服务的体系结构是Sun ONE 平台。使用创建、装配、部署、集成和测试的市场主导工具，Sun 交付了一个综合的环境。它认为TransCanada非常强大，因为Web服务是使用开放技术构建的，并且构建在一个可以包含并扩展现有IT资产的可集成框架。该项目体现了Sun开放API的承诺： 积分器、第三方产品和工业标准技术都对它的成功作出了很大的贡献。

今天，TransCanada使用Sun ONE体系结构提高他们对“更好、更快、更便宜”的看法，来达到他们减少成本、减少市场响应时间、通过几乎无缝的IT环境中的技术提高交互性、维护并比以前更快更简单地更新。

Sun具有发送按需服务的理念、体系结构、产品和专家。使用创建、装配、部署、集成和测试的市场主导工具，Sun为Sun ONE体系结构提供了综合的环境。该项目体现了Sun开放API的承诺： 积分器、第三方产品和工业标准技术都对它的成功作出了很大的贡献。TransCanada正要实现他们减少成本、减少市场响应时间、通过几乎无缝的IT环境中的技术提高交互性、维护并比以前更快更简单地更新的目标。

更多信息

Sun Open Net Environment (Sun ONE)

www.sun.com/sunone

Sun ONE Architecture Guide

www.sun.com/software/sunone/docs/arch/index.html

Sun ONE Messaging Queue

www.sun.com/software/products/message_queue/home_message_queue.html

Sun ONE Integration Server

www.sun.com/software/products/integration_srvr_eai/home_int_eai.html

Sun ONE Directory Server

www.sun.com/software/products/directory_srvr/home_directory.html

Sun ONE Web Server

www.sun.com/software/products/web_srvr/home_web_srvr.html

Java API for XML Messaging (JAXM)

java.sun.com/xml/downloads/jaxm.html

JAXM Tutorial

java.sun.com/webservices/docs/1.0/tutorial/doc/JAXM.html

附录A 公司信息

关于Sun

Sun提供了端到端的体系结构，使得客户为将来的Web服务构建坚固的基础时能够支持现有的应用程序。Sun开放网络环境(Sun ONE) 平台是一个开放的可集成栈，用来创建和部署按需服务和出现的Web服务。

图16 Sun ONE平台

Sun提供了许多资源，这些资源能够帮助组织接受按需服务。它们包括：

• Sun专业服务：在近40多个国家中有几千了服务专家为商业帮助、设计、开发、部署和管理按需服务。 使用该领域内证实的方法和技术， Sun顾问能够设计并实现满足各类商业目标的策略和最佳实践。
• SunToneSM 程序：给客户提供用于识别基于Web服务的高质量资源的方法，Sun证实了SunTone认证和Branding 程序。这些归档的标准能够指导设计和操作所需的服务。SunTone认证能够用于Web服务的各个方面，包括基础结构、服务提供者、安全和管理实践。SunTone体系结构方法基于多年来工业各个领域几千个客户基于Internet的商业解决方案的设计和交付的扩展经验。SunTone 程序加快进入WebTone的进程—可用、可靠的按需服务。
• iForce Initiative：Sun的iForce initiative将Sun和它的全球工业合作伙伴结合起来，共同交付用来帮助客户的证实的解决方案—从刚刚启动的公司到大型企业—利用了强大的Internet并驱动了商业优势。IForce解决方案区别于具有竞争性的单个公司提供的解决方案，因为iForce 社区提供了一组丰富的产品、程序和服务。
• iForce Ready Centers：定位于全世界，iForce Ready Centers帮助Sun客户处理各类事务，从创建的集体自由讨论技术观点到证明概念演示的IT基础结构到实际的试验性程序。IForce解决方案是最佳应用程序的预先测试聚集，它既是可扩展的也是可定制的，并且严格遵守了开放标准。

几年来，Sun一直都是Internet产品和技术的领先者。Sun ONE 平台利用现有的Web服务功能，并将它扩展到按需服务。

这些软件产品在创建Cortex证明概念中起到了重要的作用：

Sun ONE集成服务器，EAI版本

Sun ONE集成服务器，EAI版本，主要用在需要集成打包的、定制的、老的和新的Java技术应用程序的企业。该产品使得公司能够将核心商业处理和企业内部多个运行在操作系统上的满足多个通讯协议的核心商业处理集成起来。通过自动化各类分布式信息系统上的商业处理，公司能够提高生产率。

Sun ONE集成服务器，EAI版本提供了下列功能：

• 集中星型（Hub-and-spoke）体系结构使得能够使用结构化EAI解决方案。
• 企业服务使用的工作流管理。
• 记录并处理历史。

Sun ONE消息队列

Sun ONE消息队列是Java消息服务规范的实现，是处理Java应用程序之间异步消息发送的标准化API。它结合了开放标准、高可靠性和高性能，提高了开发者的生产率满足了商业集成需求。Sun ONE消息队列软件使得企业中的单个应用程序之间能够高效地通讯及工作。面向消息的中间件产品(MOM)，Sun ONE消息队列软件能够集成老程序、企业资源计划（ERP）和组织内外部的新应用程序。这样，开发这就不需要关系网络细节，能够集中于Java应用程序的商业逻辑。所以，各家组织降低开发成本和产品进入市场的时间。Sun ONE消息队列软件主要有两个版本，平台版本和企业版本。它展示了JMS提供者的功能并通过消息代理提供了程序间的消息发送。

Sun ONE目录服务5.1

作为Sun ONE平台的一个完整的组成部分，Sun ONE 目录服务器5.1为新一代的E-business应用和服务提供了基础。基于高度先进性，运营商级的体系结构，Sun ONE目录服务器产品交付了一个高性能的、高扩展性的用户管理基础结构，帮助组织管理标识、关系和风险。由于商业关系不断复杂，e-business基础结构必须包括雇员、客户、供应商和合伙人信息联合的中央目录。通过集中用户、组和多个应用程序的存取控制， Sun ONE目录服务动态简化管理并帮助降低所有权的总成本。Sun ONE目录服务器提供了e-business基础，能够改变组织z通过多个边界给雇员、客户、供应商和合伙人交付服务的方式。

在Cortex项目中，将Sun ONE目录服务软件用作用户和配置信息的LDAP库。

Sun ONE Web 服务器6

Sun ONE Web 服务器是从事为e-commerce站点构建动态Web应用程序的开发者的软件产品。由于它支持多平台，开发者能够根据自己的喜好选择工作的操作系统环境。加速开发的时候，产品使用Java Servlet和JavaServer Pages技术产生个性化的内容。组合集中的服务器管理、内容管理和快速应用程序开发功能，为企业将它们的商业移到Internet提供一个强大的方法。

Solaris操作系统环境

Solaris OE是Sun ONE 体系结构的基础。它结合了传统的OS功能、应用服务和标识管理讲操作系统改进为一个服务平台。对于Sun ONE平台创建的安全、管理合按需服务质量来说它的功能是必须的。Solaris OE 让IT组织在大范围、持续的实时计算和安全系统上交付产品——同时提供服务层次、减少风险并降低成本。并且由于Solaris OE和Java 2平台紧密结合，它将保留在操作系统环境产品的最前线。

关于ThoughtWorks

ThoughtWorks, Inc.是全球1000家企业的定制的e-business应用开发和高级系统集成服务的领先产品。在SPINE项目中，ThoughtWorks充当软件集成者，交付能够将高级商业功能和公司现有核心I.T资产集成起来的复杂的软件解决方案。ThoughtWorks的总部在芝加哥，在纽约、旧金山、纳什维尔、卡尔加里、伦敦、墨尔本和班加罗尔都有办公地点。它成立于1993年，该公司是由私人开设的。

附录 B 例子代码: Cortex的 JAXM Provider Connection API

import ca.tcpl.spine.messaging.SpineMessage;
import javax.naming.InitialContext;
import javax.xml.messaging.ProviderConnection;
import javax.xml.messaging.ProviderConnectionFactory;
import javax.xml.soap.MessageFactory;

public class JAXMProviderConnectionSample {
　public static final String PROVIDER_CONNECTION_NAME = “spine-provider”;
　public static void main(String[] args) throws Exception {
　String providerConnectionName = PROVIDER_CONNECTION_NAME;

　// 获取JNDI初始环境
　InitialContext context = new InitialContext();

　// 获取一个Provider Connection Factory进行使用
　ProviderConnectionFactory factory =
　　(ProviderConnectionFactory) context.lookup(providerConnectionName);

　// 要求factory创建一个Provider connection.
　ProviderConnection provider = factory.createConnection();

　//创建一条消息，适合于和该提供器一起使用
　MessageFactory msgFactory =
　　provider.createMessageFactory(“spine-message”);
　SpineMessage message = (SpineMessage) msgFactory.createMessage();

　// 在SPINE消息内设置目标
　message.setTarget(...);

　// 显示消息体
　...
　// 发送消息
　provider.send(message);

　//关闭连接
　provider.close();
　}
}