欢迎， Jim ， 您能向社区介绍一下自己吗？

我叫 Jim Rivera 。我是 BEA Systems 的一名技术总监。到现在为止，我在 BEA 公司工作了大约 6 年时间，尝试过各种职位，最近任 WebLogic Server 最新三个版本的产品经理。在我现在的职位上，我的主要工作是推动对我们平台的技术采用，从而帮助架构师和开发人员理解如何应用我们的技术，特别地，我还把一部分精力放在面向服务的架构上。 SOA 蓝图计划就是上述工作的一部分。

您能解释一下什么是 SOA 蓝图吗？

我们围绕 SOA 已经进行了许多营销工作，在什么是 SOA 方面不断获得突破性的消息，但是关于如何实现 SOA 的信息很少，而且思路很模糊。因此，作为一名专业人士，我认为在如何采用 SOA 作为开发应用程序的一种方式的问题上，开发人员需要更多的规范和惯例。这就是 SOA 蓝图计划的全部内容。它是一个行业范围内的计划，用于确切地定义如何实现 SOA ，以及当采用这种方法开发应用程序时，您想要使用的一些设计模式。该计划有三块主要的内容。首先是围绕 SOA 定义一组概念和术语，以及定义。如果您想能够就如何实现 SOA 进行更多有趣的谈话，这是一个先决条件。您有一个通用的核心概念，可以从它开始实现 SOA 。其次是为参考实现和参考应用程序定义一个规范。这样做是为了有一个基于 SOA 应用程序的非常具体的例子，并能够从这个应用程序引导出一些对于 SOA 来说很重要的模式。最后一件事情是能够提供规范的实现，而且这些实现将会在各个不同的平台上完成，因为显然需要在十分异构的环境中实现 SOA ，例如，无论是在 Java 还是 .NET 环境中，您都可以通过不同的方式来做到这一点。该规范目前还处于公众评论阶段，所以您可以立即从 www.middlewareresearch.com 下载它，并提供对它的反馈。目前，有多家厂商向我们做出了提供实现的承诺。

计划中都涉及到哪些厂商？

BEA 和 Middleware Company 都是这个计划的主要发起人，所以我们过去一直致力于制订他们的初始规范，而其后有很多其他的厂商也加入了这个计划。这其中包括其他的平台厂商，比如 IBM 和 Microsoft 、 Oracle 和 Sun ，以及许多其他的 SI 、 ISV 、行业分析家、咨询家和客户。专家评审委员会由大约 20 家公司组成，而且它是一个属于行业范围内的计划，所以任何人都可以参与进来，您可以下载规范，提供输入给委员会，还可以自愿为规范的开源实现提供帮助。任何厂商都可以加入这个计划，只要它们愿意在它们自己的平台上提供规范的实现。

为什么您认为 SOA 蓝图如此重要 ?

SOA 代表了用于构建应用程序的一种相对较新的方式。 SOA 的概念已经存在了很长时间；但是，因为过去您习惯的传统做法是，使用专门技术和消息总线来实现 SOA ，它实际上没有在很大的范围内得到采纳。所以对于大多数开发人员来说，它是一种新的方式，它是一种用于构建应用程序的新方法。当您开始为独立进行部署的应用程序构建依赖性时，您就开始了共享像这样的服务，而且您需要能够以一种非常松散耦合的方式定义交互模型中的这些接口，这样您才能独立地管理这些应用程序并控制它们的版本，同时不会降低整个系统的性能。这需要一套新的设计模式和技术，所以该蓝图就如何学习这些设计模式为您提供了一种非常具体的方式，而且当您考虑规范的实现时，您将能够明白如何在各种平台上完成它。

您如何在作为规范一部分的 实际例子中获得经验 ?

到现在为止， BEA 注重研究 SOA 已经有一段时间了。它是我们未来前景和产品战略的核心。自从发布了 WebLogic platform 8.1 以来，我们实际上已经拥有了实实在在专注于提供 SOA 功能的产品。这种状况已经持续了大约一年半的时间。所以，我们已经拥有相当一部分采用这种构建应用程序的方式的客户。通过我们的顾问，我们的专业服务和我们的合作伙伴，有关那些已经完成的实现，我们已经了解到了相当多的情况，而且从内部来说，我们自己的 IT 部门都是使用 SOA 来构建面向内部和外部的应用程序。所以，我们已经能够应用这些知识来帮助定义规范中需要有的内容，以及我们将如何在我们自己的实现中实现该规范。

蓝图中实际上规定了哪些内容？

该蓝图是用于一家叫做 Generico 的虚构公司的规范，它定义了 3 个主要的用例。第一个用例是一个企业范围内的安全服务，所以它引入了一些有趣的内容，比如必须针对单点登录传递一个安全令牌，等等。第二个用例是一个企业范围内的数据服务，它实际上是一项非常常见的需求，而且几乎成为了面向服务架构的一项先决条件，因为当您考虑使用传统方式来构建应用程序时，在很大程度上就是孤立的方式，应用程序不会共享数据。这时您会开始转而使用共享服务式的基础架构。您需要找到一个对于需要上述数据的不同应用程序都适用的数据模型。这通常需要聚合来自各种不同数据源的数据，并对它们进行加工，使其从表面看起来是一个数据服务。最后一个用例是开发一个自助式的门户，这样它就可以使用您构建的现有服务，并开发和构建另外的服务，也就是在自助式门户中实现业务流程更高级的服务。

 蓝图实现中都给出了哪些模式？

最基本的模式是同步服务和异步服务。通常，当人们考虑 web services 时，就会想起同步服务。定义 SOAP 规范的方式正是一种请求－响应式的交互模型。当客户端需要即时获得响应时，假定是基于查询的服务便派上了用场。然而，它也是一种相对紧密耦合的交互方式，因为客户端发送其请求时会阻塞，直到它收到响应为止，而且在某些情况下，如果您的服务踢掉一个长期运行的进程，或者如果您需要说明吞吐量或停机时间方面的差别，您实际上是想引入一个异步模型，因为这样做的耦合程度要松散得多，您的客户端可以发送请求，而且它是一个发后不理（ fire-and-forget ）类型的模型，在这种模型中，应用程序可以接着处理其他的工作。执行服务之后，响应会在稍后某个时候通过像回叫这样的机制传送回来。这正是网络中出现停机时间或者调入调出一个应用程序的原因；这样应用程序之间的耦合程度便松散得多。还存在一些其他的模式，比如发布与订阅，包含横切关注点（ crosscutting concern ）的编排模式，以及用于补偿动作的模式。

 您能给我们谈谈一个使用发布与订阅（ pub sub ）模型的例子吗 ?

当您有多个订阅系统对一个特定的事件感兴趣时，发布与订阅模型十分有用。借助这个模型，您可以把一条消息插入队列，或者把它发送给一个主题，而任何已经订阅该主题的子系统都将收到该消息的一条通知。举一个例子，当企业雇佣了一个新员工时，您的 HR 应用程序会把有关该员工的一些信息添加给它自己的子系统。当该员工被添加给系统时，可能会有很多其他的子系统需要获取信息，或者需要收取通知。这些子系统包括，需要为新员工配备一台计算机的 IT 部门，需要添加新员工的信息给其子系统的工资发放部门，或者需要摆放好桌椅的设备协调部门。所以，这允许一个事件很容易地触发发送到其他系统的许多不同通知。

您能举出一个编排（ orchestration ）模式的例子吗？

 编排与复合服务有关。复合服务就是使用了其他服务的服务，是更加细粒度的服务，以便处理请求。编排定义了调用这些服务的流程或次序。您可以串行或并行地调用这些服务，编排中对此都有相应的定义。通常，它们编排服务或者实现一个业务流程。例如，您有一个接受开销报表的服务，而且一旦您接受了开销报表，它们必须进行许多步骤。这些步骤包括，更新开销报表应用程序的状态，把开销报表保存到数据库中，为批准管理程序建立一个工作任务，然后把这个工作任务指派给管理程序，并给该管理程序发送一封电子邮件。在一个经过编排的服务中，这些就是您可以进行自动化的流程的所有部分。此外，关于编排的一件有趣的事情是，我们有一些工具可供您使用，特别是在编排要实现一个业务流程时，您还可以使用另外的工具以一种非常直观的方式来定义该编排。例如， WebLogic Integration 中有一个 BPM 工具，它允许您可视化地使用流程构件，以一种非常直观而快速的方式定义您的流程，这个流程是一个可执行的业务流程，您可以把它公开为另一个服务。

 您刚刚提到了补偿动作，那么对其进行跟踪和测试很困难吗？

 当您要实现一个流程时，补偿动作相当重要，如果该流程自始至终没有完全执行，您的系统就可能处于一种不一致的状态中，因为流程中的一些步骤得到了执行，而您处于一个非常松散耦合的系统中，您没有一个可以自动回滚这些步骤的通用事务管理程序。所以，补偿动作允许您做的就是，定义撤销已完成步骤所必需的步骤，以及由于整个流程无法完成而现在需要撤销的步骤。只要您的流程框架赋予您对于运行在服务器上实例的可见性，对它们进行跟踪也不一定是很困难的事情。例如，在 WebLogic Integration 中，您可以使用 WebLogic 管理控制台，即 Integration 管理控制台，它可以为您提供对于所有运行实例的可见性，在一个给定的时刻您可以拥有数百个运行实例，而且您可以可视化地判断某个特定实例位于流程中的哪个地方，在您的业务流程中它采用哪条路径，以及出于回滚的原因是否要调用任何补偿动作。

开发人员如何在 SOA 中使用横切 （ cross cutting ）模式？

横切模式是一种有趣的方式，它能够在给系统增加功能的同时不改变现有的组件。客户端或服务不必变化，您就可以增加另外的功能。在 SOA 中，您做到这一点的方法是使用拦截（ interception ）模型。所以，您要使用一个拦截器，它将在到达后端服务或实现服务之前接受请求，而您可以对该请求进行任意的处理。您可以进行管理工作，或者应用安全约束，或者进行日志记录和审计。您可以通过各种方式来实现这一点。一种常用的方式是使用企业服务总线或 web 服务管理工具作为逻辑中心位置，所有消息都由此经过或传入，您也可以在这个位置拦截消息，并应用这些横切关注点。在 Java 中，您还可以使用 JAXRPC 这样的标准来定义拦截器或处理程序，以便在上述位置拦截消息和应用横切关注点。

对于 SOA 所持的态度如何？ 您为开发人员提供了哪些解决方案？

我们事实上关注的第一件事情是开放式标准。这不仅包括应用像 web services 和各种 API 标准这样的开放式标准，还涉及到帮助推动对于这些标准的标准体的改进，以便确实有助于添加企业级消息收发给 web services 。这实际上就是我们认为 web services 应该发挥作用的地方。事实上，我们还关注易用性，以及以下这种能力，那就是使开发人员能够更加高效，并从作为 SOA 固有部分的集成的复杂性中抽离出来，把主要精力放在业务逻辑和构建应用程序本身上。第三，我们还关注以端到端的方式集成我们的平台。这意味着，您可以在 WebLogic 服务器上进行定制开发，您还拥有 WebLogic Integration 上的集成功能，然后您就可以在一个门户中公开所有这些内容。我们已经确认，整个平台的集成性良好，这样整个平台就可以共同工作，而且特别地，您拥有一个跨整个平台的、非常一致的开发模型。这对于 SOA 来说很重要，因为开发和集成开始融为一体。您无法做到在 SOA 中进行开发的同时，不进行某种程度的集成，而且在这些平台上，拥有一种非常通用且一致的交互和开发方式确实相当重要。

Apache Beehive 如何适应这些内容？

对于 SOA 来说， Beehive 实际上是核心部分。 Apache Beehive 基于的技术最初是作为 WebLogic workshop 的一部分而分发的。它是 WebLogic Workshop 的一个运行时层。它为 J2EE 编程提供高度的抽象。事实上， Apache Beehive 的目标是 SOA 和在 J2EE 体系中支持 SOA 功能。它基于非常轻量级的简单编程模型 plain Java object (POJO) ，使用元数据来声明性地配置这些不同的组件，使其一起工作，并定义了像 web services 和服务质量这样的标准。在 Apache Beehive 中，各种组件都是 Java 控件——这为访问企业资源提供了一种非常一致的方式。控件的客户端模型十分简单；它抽象出了很多细节，例如调用 EJB ，发送消息给 JMS 队列。它允许您公开一个十分简单的接口，这对于 SOA 很重要，对于这种耦合能够抽象出上述技术细节很重要。 Java web services 是 Apache Beehive 的另一个组件，这个组件对于在异构环境中向支持 SOAP 或支持 web services 的平台公开服务是很重要的。最后一个组件是 NetUI 页面流，这个组件允许您在您的环境和企业中利用现有的服务，让您能够基于 struts 轻松构建 web 应用程序。它是 Struts 之上的一个易用层。 Apache Beehive 适合于平台的余下部分，并与其很好地集成在一起。所以显然，您可以使用 Workshop 开发 Beehive 应用程序。集成产品 WebLogic Integration 基于 Beehive ，而且它的很多部分都是基于 Beehive 构建的。所以， Integration 产品中包含的编排工具允许您编排控件和控件允许您访问的一切内容，然后您就可以采用这些流程，然后在我们的 WebLogic 门户中公开它们。所以，我们实际上已经关注如何贯穿整个平台来提供 SOA 功能。

 您的方法与竞争对手相比较如何？

我猜想，这实际上应该取决于您把我们与谁进行比较。我们现在关注的有很多事情。首先是开放标准，就像我开始说过的那样，也就是 web services 协议以及确保我们能够获得跨平台的互操作性。这相当重要。但是还有 API 标准，以及帮助确保投资保护，这对于已经转而使用 J2EE 并希望从 J2EE 获得预期效果的人们来说甚为重要。举一个例子，我们积极投身于 JCP 中，以确保我们的革新不会退回 Java 或者合并到 J2EE 中，而且 Apache Beehive 项目正是我们采用的另一种方法的一个例子，通过采用这种方法，我们能够提供投资保护，这意味着当人们构建 Beehive 应用程序时，他们可以选择的部署平台现在不会被锁定在一种平台。我们在另一方面也与我们的竞争对手有一点不同之处，即我们实际上集中精力放把整个平台集成到集成产品、应用服务器或门户产品中，客户不必经历集成各个部分并使其协同工作的过程。这些产品可以直接一起工作，并通过一张 CD 进行安装，这减轻了客户的很多经济负担。至于拥有一个跨整个平台的、非常一致的开发模型，这对于 SOA 确实很重要。

 您一开始就提到，围绕 SOA 存在这很多营销手段，但是为什么您认为开发人员应该关心 SOA 呢？

 开发人员应该关心 SOA ，是因为不管所有的这些营销手段， SOA 都具有实际意义上的优点。 SOA 承诺使开发变得更加廉价和轻松。当您采用 SOA 时，开发周期将会缩短，而且使用它构建的信息系统更加灵活，对于不断变化的业务需求适应性更强。许多行业分析家预测，在 4 年时间内，绝大部分企业应用程序都会使用 SOA 原则进行构建。所以开发人员不仅应该关心它，而且应该自学相关知识。

对于刚开始从事 SOA 的团队来说，一般都存在哪些陷阱？

 我认为开发人员非常善于应用新技术。所以这实际上根本不是问题。我认为转向 SOA 时存在的最大问题，是转而使用这种方法所需要的组织变化。开发应用程序的传统方式允许开发人员只专注于他们的项目。开发人员以一种非常孤立的方式工作。他们不必与开发另一个项目的开发人员交流，因为他们没有共享数据，他们没有共享服务。使用 SOA 时，您实际上必须稍微修改管理模型，而且您必须有讨论小组或者一些人，这些人能够对企业内的所有项目进行总体规划，并决定哪些服务可以跨企业使用，准备跨企业共享什么数据模型，等等。从很多企业现今的工作方式来看，这是一个巨大的变化。我认为这通常会是人们面临的最大挑战。

 在一些社区中 宠物商店（ pet store ） 遭到了嘲笑，这很可能是因为它试图把所有的设计模式都 塞进 一个应用程序中，而这通常是不现实的做法。这对于 SOA 蓝图来说是不是 一处隐忧 呢？

我认为这的确是值得担心的地方。开发任何参考应用程序时，您总是会担心在其中放入过多内容，就像过去人们对 pet store 的批评那样。我认为， pet store 和 SOA 蓝图之间存在一处重要差别，即 pet store 是一个相对较简单的应用程序，一个电子商务 web 应用程序而已，而他们在这个相当简单的小型应用程序中塞入了所有这些非常复杂而且有用的设计模式。 SOA 蓝图采用了稍微不同的方法。由于 SOA 的本质，实际上，它更多考虑的是这家虚构公司的整个 IT 系统。因为与您打交道的是整个系统，您就不会受限于一个应用程序中，所以引入新的场景也就容易得多。所以我认为，对于 SOA 蓝图来说，这个问题的影响不大。

 您如何看待 web services 和 SOA 之间的关联？

我认为有一点很重要，即注意 web services 和 SOA 并非同义语。您有时候会发现和营销有关的这样一个问题，人们感到困惑，到底是因为采用 SOA 而不得不使用 web services 呢，还是实际上在实现 SOA 时而碰巧使用了 web services 。二者并非一项技术，而且也不相同。 Web services 是 SOA 的一项非常重要的支持技术，因为它基于开放标准，所以它承诺降低采用 SOA 的成本。但是它只是一种可能的实现，而您可以使用各种不同的消息收发协议来实现 SOA 。

对于未来构建 SOA 应用程序的工作， 您还有什么要总结的吗？

我认为开发人员应该自学 SOA 的各种设计原则和设计模式，这一点很重要。因为它是一种新的方法，需要使用一些新技术，所以使用这种新方法就带来了新的挑战。我认为 SOA 蓝图是一个着手迎接挑战的良好起点，而且因为许多领域，尤其是 web services 领域，无时无刻都在高速发展，所以我认为开发人员应该及时地掌握最新技术，尤其要掌握那些对于构建 SOA 十分重要的可用协议和工具。

本文地址：http://dev2dev.bea.com.cn/bbs/BEA_dev2dev_Live/man/jimrivera.jsp