By

文章目录
  1. 1. SOA
  2. 2. SCA
    1. 2.1. 开发
    2. 2.2. 测试及跟踪
    3. 2.3. 部署
  3. 3. ESB
    1. 3.1. 开发
    2. 3.2. 测试及跟踪
    3. 3.3. 部署
  4. 4. Tuscany
    1. 4.1. 开发
    2. 4.2. 测试及跟踪
    3. 4.3. 部署
  5. 5. Mule
    1. 5.1. 开发
    2. 5.2. 测试及跟踪
    3. 5.3. 部署

当应用从集中式步入分布式， 随着系统功能的越来越丰富， 应用就逐步从一个由 10 个系统以下构成的应用逐步发展为 100 个， 甚至 1000 个系统构成的应用， 随着系统越来越多，如何管理和运维好一个如此庞大的系统就将成为一个大问题， 这其中包括了开发、 调试、 测试、 部署、 升级等众多的过程， 同时， 高可用性以及高性能也会一直伴随着这个发展过程，随着系统的越来越多， 数据的不断增加， 访问量的不断攀升， 要做到高可用性以及高性能的难度也会不断的提升， 最能体现这样发展过程的无疑是互联网网站， 多数成功的互联网网站都经历着如上的发展过程。

SOA

1、 统一系统间的交互方式
SOA 强调系统之间的交互都以 Service 的方式进行交互， 当系统需要对外提供功能时，通过 Service 的方式提供， 当系统需要访问其他系统提供的功能时， 也通过 Service 的方式访问， 开发人员无需关心是如何实现这个交互过程的， 交互过程中所采用的通信协议、 交互方
式（ 例如同步、 异步）、 如何找到提供 Service 的系统、 通信中的问题处理（ 例如超时） 等等所有交互的问题都由 SOA 框架来完成， 在解决了系统间的交互方式后， 大型分布式 Java 应用中的开发问题就没有那么突出了 。
2、 管理基于 SOA 构建的分布式系统
SOA 把这个管理称为服务治理， 在 SOA 中通过将所有的服务注册到统一的服务中心，例如通常可见的技术为 UDDI， 基于此得知目前系统中所有的 Service， 进而分析它们之间的依赖关系以及调用路径等。尽管 SOA 没有完全解决高度可管理的系统所需面对的问题， 但它指明了方向 ， 因此 SOA仍然是在大型分布式应用中比较好的选择， 即使不采用 SOA 框架来实现大型分布式的 Java应用， 其思想仍然是值得参考的， 实现 SOA 的技术有很多很多种， 在 Java 的 SOA 体系中，重要的有 SCA（ Service Component Architecture） 标准以及 ESB（ Enterprise Service Bus）， 下面就来看看 SCA 和 ESB 对构建高度可管理性应用的满足程度， 评判标准仍然是对于开发、测试以及部署三方面的支持程度， 由于性能主要取决于具体的实现， 因此性能方面则不在此
处进行判断。

SCA

在 SOA 思想推广了几年后， 业界对于 SOA 的评价均为思想不错， 但没有实际的实现方法指导， 于是业界领先的几家厂商： IBM、 Oracle（ 包括之前的 Bea、 Sun）、 RedHat、 SAP 以及 Siemens 等成立了一个组织， 负责制定 SOA 的具体实现规范， 在 2007 年 3 月左右完成了
此规范的大部分内容的制定， 规范的名字定为了 Service-Component Architecture， 简称 SCA，规范的版本为 1.0， 下面就具体来看看 SCA 标准对于构建高度可管理性系统的满足程度。

开发

由于 SOA 中系统间交互均为 service 方式进行， 同时 SOA 多数情况下应用于分布式场景，因此从开发角度而言， 需要关注的主要是如何发布Service， 如何调用 Service、 支持的通信协议以及交互方式这四个方面， 分别来看看。
发布 Service
Service 遵照 SOA， 以接口方式对外提供， 发布 Service 首先要求系统本身已经有相应的接口实现， 在 SCA 中， 为了减少对系统实现的侵入， 通过 XML 定义 Component 来映射到系统本身的接口实现上， SCA 支持了多种的映射方式， 并允许自行扩展， 因此系统可采用 java、spring bean 等多种方式来实现接口 ， 在定义了 Component 后， 即可将 Component 实现的接口以 Service 的方式发布， 以一个具体的例子来看看如何将系统中的接口实现发布为 SCAService。
系 统 中 有 一 个 名 为 chapter2.component.DefaultHelloWorld 的 类 ， 其 实 现 了chapter2.service.HelloWorld 接 口 ， 要 将 此 Java 类 发 布 为 SCA service ， 提 供chapter2.service.HelloWorld 接口定义的功能， 编写一个如下格式的XML 文件即可：

<composite xmlns="http://www.osoa.org/xmlns/sca/1.0" targetNamespace="http://foo.com" name="HelloWorldComposite">
  <component name="”HelloWorldComponent”">
    <implementation.java class="”">
      <service name="”HelloWorldService”" promote="”HelloWorldComponent”">
        <interface.java interface="”"></interface.java>
      </service>
    </implementation.java>
  </component>
</composite>

在以上 XML 文件中， composite 是 SCA 定义的最小部署单位， 每个 XML 文件其根元素必须为 composite， 在 composite 下可以有多个 component 以及多个 service 标签， 来具体看看omponent 标签和 service 标签。
component 标签
component 标签主要通过 implementation 子标签定义和已有系统的集成， SCA 提供了对多种实现集成的支持， 例如 Spring、 Java 或 C 等。
除了 implementation 子标签外， component 中还可定义 service、 reference 等子标签，service 子标签用于表明当前 component 对外提供了什么 service， reference 子标签用于表明当前 component 引用了什么 service。
service 标签
service 标签代表了对外提供服务的描述， 包含了 name、 promote、 requires 和 policySets四个属性， 其中 promote 属性指定了提供此服务的 Component， Component 可以多种方式实现， 如纯 Java 方式， 或 Spring 方式等。service 标签下增加 interface 子标签即可定义对外提供的接口 ， SCA 标准规定支持三种方式对外提供接口 ： Java 语言方式的接口 、 WSDL 1.1 以及 WSDL 2.0 方式， 可将 interface 标签写为 interface.java 或 interface.wsdl， java 方式的情况还支持callbackInterface 属性， 以满足双向的服务交互的需要。
对于发布的服务， 可通过配置 binding 标签来指定其发布的方式， SCA 默认支持的方式有 sca、 Webservice 以及 JMS 三种， 如不指定则以服务的实现方式来决定。从 service 标签来看， 在采用 SCA 的情况下， 可以很方便的将各种方式实现的功能以多
种方式对外提供， 对系统的侵入非常小， 从这方面来看， SCA 还是做的不错的。
调用 Service
调用 Service 的方式也同样为通过简单的定义 xml 即可实现， 例如需要在 spring 中调用上面的 HelloWorldService， 只需定义如下的 xml 文件即可：

<composite xmlns="http://www.osoa.org/xmlns/sca/1.0" targetNamespace="http://foo.com" name="HelloWorldComposite">
  <component name="”HelloWorldComponent”">
    <implementation.spring location="”beans.xml”" />
    <reference name="”HelloWorldService”" target="”HelloWorldService”" />
  </component>
  <reference name="”HelloWorldService”" promote="”HelloWorldComponent”">
    <interface.java interface="”">Spring 的 beans.xml 定义如下： 
    <beans>
      <sca:reference name="”HelloWorldService”" type="”"></sca:reference>
    </beans></interface.java>
  </reference>
</composite>

通过这样的方式就可以直接在 Spring 获取 HelloWorldService bean 来调用 SCA Service 了 ，来具体看看 reference 标签。
reference 标签
reference 标签代表了调用其他服务的描述， 包含了 name、 promote、 requires、 policySets、multiplicity、 target 和 wiredByImpl 等属性， 通过设置 promote 和 name 来指定此引用到的服务需要注入的 Component 以及其属性名 ， multiplicity 可用于指定需要引用的服务的数量：0..1、 1..1、 0..n 或 1..n。
和 service 标签一样， reference 标签通过 interface 标签来指定需要引用的服务的接口 ，通过 bindings 标签来指定引用服务的方式， 例如 sca、 Webservice 或 JMS 方式。从 reference 标签来看， 和 service 标签一样， SCA 可以在不侵入系统的状况下以多种方式引用 SCA 服务， 并将其注入到需要引用服务的系统中， 这些系统同样可以以各种方式实
现： Java、 Spring 或 C++等。
支持的通信方式
从之前对于发布 Service 和调用 Service 的描述中可看到， SCA 标准默认提供的通信方式为 sca、 Webservice 和 JMS 三种， 其中Webservice 的实现为 http 方式， JMS 则可以以多种方式来实现， 例如 tcp/ip、 http 等， 这点取决于具体的 SCA 框架了 。
除了以上三种外， 在 SCA 中也可非常方便的扩展其他的通信方式。
支持的交互方式
在交互方式上， SCA 标准中没有明确的定义。
除了以上主要的四点外， 对于分系统之后带来的跨系统之间的事务问题， SCA 也提供了跨系统之间的事务保证的编程规范 ， 在编程规范中 SCA 将跨子系统的操作的事务分为globalTransaction 、 localTransaction 、 noManagedTransaction 、 propagatesTransaction 、suspendsTransaction、 transactedOneWay 以及 immediateOneway 几种类型， 当开始调用操作时， 如操作位于 globalTransaction 范围， 则可以做到整个调用都处于同一个事务。结合以上内容综合来看， 在遵循 SCA 标准的情况下， 可以非常容易的将不同实现方式的系统中的功能以多种通信方式对外提供， 同样， 也可以非常容易的实现对 SCA Service 的调用， 并且具备了很好的扩展性， 例如通信方式的扩展等， 尽管在交互方式上未提供明确的
支持， 但从开发角度衡量而言， SCA 标准是可以满足要求的。

测试及跟踪

在测试以及跟踪方面 SCA 未定义相关的支持， 需要自行实现。

部署

SCA 规范中定义了 SCA 组件的部署方式， 可以 zip 等方式进行打包， 但 SCA 中并未提供
分析服务依赖关系的方法， 因此要解决上面列出的部署方面的问题会比较复杂。
从以上三方面来看， SCA 标准对于构建具备高度可管理性的应用而言能有很大的帮助，但同时也有其不足的地方。

ESB

ESB 和 SCA 不同， 它并不是由多个厂家联合制定的 SOA 实现的标准， 并且也不能把 ESB称为 SOA 的实现思想， 这在业界争论了非常多年， 和 SOA 一样， 它也是没有标准的定义的，因此可以认为 ESB 只是个概念， 其核心思想为基于消息中间件来实现系统间的交互， 基于消
息中间件所构建的此系统交互的中间场所称为总线， 系统间交互的数据格式采用统一的消息格式， 由总线完成消息的转化、 路由， 发送到相应的目标应用， 图示如下：




来看看业界公认的 ESB 框架最基本的要具备以下五个要素：
标准的消息通信格式；
消息的路由功能；
支持多种的消息交互类型（ 例如请求/响应、 发布/订阅等）；
支持多种传输协议（例如 tcp/ip、 udp/ip 等）；
支持多种数据格式并能够进行相互转换。
仍然从开发、 测试和部署三个角度来衡量基于 ESB 构建高度可管理的应用的满足程度。

开发

开发角度考察的仍然为发布 Service、 调用 Service、 支持的通信方式和支持的交互方式四个方面。
发布 Service
ESB 概念中未明确的定义如何发布 Service， 只是提及到要求所有的 Service 都发布到总线上， 从而构成服务仓库。
调用 Service
对于如何调用 Service， ESB 也只是规定了所有的调用都通过总线来完成， 但未定义更多的细节。
支持的通信方式
按照业界公认的 ESB 框架而言， ESB 会提供多种通信方式的支持， 包括 tcp/ip、 udp/ip等。
支持的交互方式这点上 ESB 没有明确的定义。
根据上面的分析来看， 可以认为 ESB 只是定义了发布 Service 和调用 Service 的方式， 但没有具体到细节， 这也是由于 ESB 只是个概念的原因。

测试及跟踪

在此方面 ESB 未做明确的定义。

部署

尽管 ESB 未对此方面做明确的定义， 但由于 ESB 构建了服务仓库， 因此很容易基于此做到服务的依赖关系分析等， 进而做到部署的管理。
SOA 思想中并未限定 Service 发布和调用的方式， 但 ESB 对此做了限定， 个人觉得可以认为 ESB 是 SOA 中的一个子集， 仅从上面的评判而言， 很难判断 ESB 是否是构建高度可管理系统的合理选择； 而尽管 SCA 是一个成文的标准， 但其对于通信方式、 交互方式、 测试以及部署等并没有明确的规定， 也很难完全判断 SCA 是否就是合理的选择； 为了更好的做出判断， 还是需要分别从 SCA 和 ESB 的实现框架来加深对于 SCA 以及 ESB 的理解和掌握，并更加准确的判断此两类框架对于构建高度可管理性框架的满足程度， 以根据不同的场景做出相应的选择。

Tuscany

在 SCA 实现框架中， 本书选择了 Tuscany 1.5 来进行分析， Tuscany 是 IBM 和 Bea 捐献给Apache 的产品， 目前在众多的 SCA 实现框架中也可以算得上是数一数二的， 先看一个例子：在这个例子中将提供一个 HelloWorld 接口的实现， 配置为 Spring Bean， 并基于 Tuscany
将其发布为 WebService 方式的 SCA Service，， 先来看看这部分是如何实现的：
HelloWorld 的接口定义如下：

@Remotable
public interface HelloWorld
{
    public String sayHello(String name);
}

HelloWorld 接口实现的代码如下：

public class DefaultHelloWorld implements HelloWorld
{
    public String sayHello(String name)
    {
        System. out.println("Server receive: " + name);
        return "Server response: Hello " + name;
    }
}

Spring Bean xml 的配置如下：

<beans xmlns="http://www.springframework.org/schema/beans" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:sca="http://www.springframework.org/schema/sca" xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd http://www. springframework.org/schema/sca http://www.osoa.org/xmlns/sca/1.0/spring-sca.xsd">
  <sca:service name="HelloWorldService" type="chapter2. sca. tuscany.demo.HelloWorld" target="HelloWorldServiceBean" />
  <bean id="HelloWorldServiceBean" class="chapter2. sca. tuscany.demo. impl.DefaultHelloWorld"></bean>
</beans>

将以上文件保存至 resources/spring 目录下， 命名为 beans.xml。
基于 Tuscany 将其发布为 Webservice 的配置如下：

<composite name="HelloWorld" targetNamespace="http://tuscany.apache.org/xmlns/sca/1.0" xmlns="http://www.osoa.org/xmlns/sca/1.0" xmlns:ns1="http://www.osoa.org/xmlns/sca/1.0">
  <service name="HelloWorldService" promote="HelloWorldComponent">
    <interface.java interface="chapter2.sca.tuscany.demo.HelloWorld" />
    <binding.ws uri="http://localhost:8080/services/HelloWorldService" />
  </service>
  <component name="HelloWorldComponent">
    <implementation.spring location="resources/spring/beans.xml" />
  </component>
</composite>

将以上文件保存至 src 目录下， 命名为 publishservice.composite。
完成了上面的步骤后， 编写一个启动类来完成服务的发布， 代码示例如下：

public static void main(String[] args) throws Exception
{
    SCADomain. newInstance("publishservice.composite");
    System. out.println("Server Started");
    while(true)
    {
        Thread. sleep(1000000);
    }
}

执 行 此 代 码 后 在 console 中 可 看 到 Server Started 的 信 息 ， 通 过 浏 览 器 访 问http://localhost:8080/services/HelloWorldService?wsdl 即 可 看 到 HelloWorldService 的Webservice 描述信息。
接着来完成调用 HelloWorld Service 的代码， 同样在 Spring Bean 中来调用此 Service， 首先编写一个需要注入 HelloWorld Service 的测试用的 spring bean， 代码如下：

private HelloWorld service = null;
public void setService(HelloWorld service)
{
    this. service = service;
}
public String execute(String name)
{
    return service.sayHello(name);
}

为了便于在 Tuscany 启动后在代码中获取到 Spring 的 ApplicationContext， 从而获取相应的 Spring bean 进行测试， 编写一个实现 ApplicationContextAware 接口的类， 代码如下：

public static ApplicationContext context = null;
@Override
public void setApplicationContext(ApplicationContext context)
throws BeansException
{
    SpringApplicationContextHolder. context = context;
}

按照 Tuscany 与 Spring 集成的实现， Spring 配置文件如下：

<beans xmlns="http://www.springframework.org/schema/beans" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:sca="http://www.springframework.org/schema/sca" xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd http://www.springframework.org/schema/sca http://www.osoa.org/xmlns/sca/1.0/spring-sca.xsd">
  <sca:reference name="HelloWorldService" type="chapter2. sca. tuscany.demo.HelloWorld" />
  <bean id="HelloWorldConsumer" class="chapter2. sca. tuscany.demo. impl.HelloWorldConsumer">
    <property name="service">
      <ref bean="HelloWorldService" />
    </property>
  </bean>
  <bean id="SpringBeanFactoryHolder" class="chapter2. sca. tuscany.demo.SpringApplicationContextHolder" />
</beans>

绑定 SCA Service 的配置文件编写如下：

<composite name="HelloWorld" targetNamespace="http://tuscany.apache.org/xmlns/sca/1.0" xmlns="http://www.osoa.org/xmlns/sca/1.0" xmlns:ns1="http://www.osoa.org/xmlns/sca/1.0">
  <component name="HelloWorldComponent">
    <implementation.spring location="resources/spring/consumebeans.xml" />
    <reference name="HelloWorldService">
      <binding.ws uri="http://localhost:8080/services/HelloWorldService" />
    </reference>
  </component>
</composite>

用于测试 SCA Service 调用的类编写如下：

public static void main(String[] args) throws Exception
{
    SCADomain. newInstance("consumeservice.composite");
    System. out.println("Client Started");
    HelloWorldConsumer consumer = (HelloWorldConsumer)
                                  SpringApplicationContextHolder. context.getBean("HelloWorldConsumer");
    System. out.println(consumer.execute("BlueDavy"));
}

在启动了发布 SCA Service 的代码后， 再启动上面调用 SCA Service 的代码， 即可看到console 上看到相应的执行信息 ， 基于上面这些步骤就很容易的实现了在 Spring 中以Webservice 的方式发布和调用 SCA Service， 但以上例子只是粗略的展示了 Tuscany， 下面更加详细的从开发、 测试和部署三个角度来评估下 Tuscany。

开发

仍然从发布 Service、 调用 Service、 支持的通信方式以及交互方式四个方面来进行介绍。
发布 Service
Tuscany 遵守 SCA 标准而编写， 因此其发布 Service 的方式和上面 SCA 标准中发布 Service的方式是一样的， 这个从上面的例子中可看出， 但它支持了将更多种实现方式的系统中的功能发布为 SCA Service， 这包括了 java、 xquery、 script、 spring、 resource、 bpel 和 OSGi。在发布的方式， 也支持了更多种的发布方式， 包括发布为 webservice、 ajax、 corba、 erlang、jms、 jsonrpc、 rmi、 ejb、 http 以及 rss 方式。
从提供了这么多的扩展可以看出， SCA 标准在扩展的支持上做的确实不错。
调用 Service
在调用 Service 的方式， 和 SCA 标准中调用 Service 的方式是一样， 但就如发布 Service一样， 它支持了更多种和应用集成的方式以及更多种的调用方式， 并且包括了更多种语言的支持， 例如对于 ruby 的支持等。
支持的通信方式
在上面发布 Service 中可以看到， Tuscany 支持的通信方式比 SCA 标准中多出了很多， 例如流行的 ajax、 jsonrpc、 rmi 等都提供了支持。
支持的交互方式
在 Tuscany 中可通过设置 CallbackEndpoint 来实现异步调用， 但这需要对代码有一些改动， 因此 Tuscany 仍然没有做到透明的支持多种交互方式的需求。根据上面四方面的介绍， 仅从开发角度而言， 如基于 Tuscany 来实现大型的分布式 Java系统， 只需在支持的交互方式上提供更好的支持即可， 性能方面则需要根据 Tuscany 对于各种通信方式的实现进行判断， 在本书中就不进行分析了 。

测试及跟踪

在测试方面， Tuscany 可通过例子中的方式进行测试， 当调用的服务端抛出异常时， 此异常信息会提供给调用端， 因此调用端可基于此判断服务器端出现异常的原因。在跟踪方面， Tuscany 并没有定义跟踪服务错误信息的方法。

部署

Tuscany 没有把服务注册到统一的中心， 并且调用时也是直接调用， 因此很难明确的知道系统中有哪些服务， 发布一个服务时会影响到哪些服务， 在采用 Tuscany 时这个方面仍需自行实现进行加强。
经过上面的分析， 可以看出， Tuscany 是个严格遵照 SCA 实现的框架， 其只是在和应用的集成方式以及通信方式上做了 扩展， 但其他方面并没有做出更多的扩展， 因此基于 Tuscany来实现大型分布式的 Java 应用仍然需要自行实现一些功能。在看完了 Tuscany 后来看看 ESB 中著名的实现框架： Mule。

Mule

首先来看看基于 Mule 2.2.1 如何实现 Tuscany 章节中的例子， 先仍然是以 Webservice 的方式对外提供 HelloWorldService， 和 Tuscany 中不同的地方在于配置文件和启动代码两方面，配置文件上去掉 publishservice.composite， 改为遵循 Mule 编写如下配置文件：

<?xml version="1.0" encoding="utf-8"?>
<mule xmlns="http://www.mulesource.org/schema/mule/core/2.2" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:spring="http://www.springframework.org/schema/beans" xmlns:soap="http://www.mulesource.org/schema/mule/soap/2.2" xmlns:axis="http://www.mulesource.org/schema/mule/axis/2.2" xmlns:vm="http://www.mulesource.org/schema/mule/vm/2.2" xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.5.xsd http://www.mulesource.org/schema/mule/core/2.2 http://www.mulesource.org/schema/mule/core/2.2/mule.xsd http://www.mulesource.org/schema/mule/soap/2.2 http://www.mulesource.org/schema/mule/soap/2.2/mule-soap.xsd http://www.mulesource.org/schema/mule/axis/2.2 http://www.mulesource.org/schema/mule/axis/2.2/mule-axis.xsd http://www.mulesource.org/schema/mule/vm/2.2 http://www.mulesource.org/schema/mule/vm/2.2/mule-vm.xsd">
  <spring:beans>
    <spring:import resource="resources/spring/mulepublisherbeans. xml" />
  </spring:beans>
  <model name="HelloWorld">
    <service name="HelloWorldService">
      <inbound>
        <axis:inbound-endpoint address="http://localhost:12345/services">
          <soap:http-to-soap-request-transformer />
        </axis:inbound-endpoint>
      </inbound>
      <component>
        <spring-object bean="HelloWorldBean" />
      </component>
    </service>
  </model>
</mule>

将上面文件保存为 publishservice.xml。
发布服务的启动代码遵循 Mule 改为如下方式：

MuleContext muleContext = new
DefaultMuleContextFactory().createMuleContext("publishservice.xml
        ");
muleContext.start();
System. out.println("Server Started");

执行以上代码后， 通过http://localhost:12345/services/HelloWorldService?wsdl 可看到
HelloWorldService 的 Webservice 描述符， 表明已发布成功。
继续来看看怎么按照 Mule Service 的方式来调用这个 Webservice， Mule 要求所有的component 被触发执行的条件为 inbound 中的信息， 而除了上面通过 webservice 的触发方法外， 其他就只能通过消息机制去触发了 ， 支持的有 vm 内的， 或 jms 方式等， 在这里选择用vm 内的方式去实现例子， 首先对 HelloWorldConsumer 的 execute 稍做了修改：

public String execute(String name)
{
    String response = service.sayHello(name);
    System. out.println(response);
    return response;
}

由于必须通过消息才能触发， 在例子中就直接用 MuleClient 来发送消息触发了 ， 因此去掉了 Spring bean 的配置文件 ApplicationContextAware 接口实现类的配置， Mule 方式的 Service
配置文件内容如下：

<spring:beans>
  <spring:import resource="resources/spring/muleconsumebeans. xml" />
</spring:beans>
<model name="HelloWorld">
  <service name="HelloWorldService">
    <inbound>
      <vm:inbound-endpoint path="helloworld.queue" />
    </inbound>
    <component>
      <spring-object bean="HelloWorldConsumer"></spring-object>
      <binding interface="chapter2. esb.mule.demo.HelloWorld" method="sayHello">
        <axis:outbound-endpoint address="http://localhost:12345/services/HelloWorldService?method=say Hello" synchronous="true" />
      </binding>
    </component>
  </service>
</model>

根 据 上 面 的 配 置 ， 必 须 先 发 送 消 息 至 vm://helloworld.queue 才 能 触 发HelloWorldConsumer 的执行， 代码如下：

MuleContext muleContext = new
DefaultMuleContextFactory().createMuleContext("consumeservice.xml
        ");
muleContext.start();
MuleClient client = new MuleClient();
client.send("vm://helloworld.queue", "BlueDavy", null);

执行以上代码即实现了以 Mule Service 的方式调用远端通过 Mule Service 发布为Webservice 的功能。
例子只简单的反应了一个使用的状况， 下面就从开发、 测试及跟踪、 部署三个方面再来详细的看看。

开发

仍然从发布 Service、 调用 Service、 支持的通信方式以及交互方式四个方面来进行介绍。
发布 Service
在发布 Service 上 Mule 支持以 webservice、 jms 等方式将 spring 或普通的 java 对象发布为 Mule Service， 配置上较为简单， 但和 Tuscany 比显得还是相对弱了点。
调用 Service
在调用 Service 上 Mule 的用法相对比较麻烦， 但这也是由于 Mule 遵循 ESB 而造成的，如要做到更好的使用， 需自行进行扩展。
支持的通信方式
通信方式上支持 webservice 以及 jms 两种。
支持的交互方式
在交互方式上， Mule 有明确的指定 synchronous 的参数， 因此这点上 Mule 较 Tuscany强一些。
从开发角度来看， Mule 比 Tuscany 总体更弱一些， 需要自行扩展的地方会更多一些。

测试及跟踪

当服务器端抛出异常时， 带回客户端的异常信息会不完整， 可能会影响到查错， 在跟踪方面 Mule 未提供明确的支持。

部署

在部署方面的支持上， Mule 本身未提供直接的支持， 但 Mule 所在的 MuleSoft 同时还提供了一个开源的服务治理框架 ： MuleGalaxy1， 开发人员可将服务元数据信息注册到MuleGalaxy， MuleGalaxy 提供了服务信息查询、 依赖分析等功能， 而依赖分析将对部署提供
很大的支持， 在这点上 Mule 赢过 Tuscany。
根据上面的分析， 无论是 SCA 标准， 还是 ESB 概念， 或 SCA 标准的实现框架： Tuscany，还是 ESB 概念的实现框架： Mule， 它们都能够对构建高度可管理的应用提供一些支持， 但同时也会有一些不足， 因此在实际的实现中， 必须根据需求来进行相应的选择， 从而进行扩
展来满足需求， 并且在上面的分析中未从高可用性以及高性能角度来进行分析， 这两个角度也会很大程度影响您的选择， 在学习了构建高度可管理的应用可选的技术后， 接着来学习高性能所需的相关技术了 。

Java
文章目录
  1. 1. SOA
  2. 2. SCA
    1. 2.1. 开发
    2. 2.2. 测试及跟踪
    3. 2.3. 部署
  3. 3. ESB
    1. 3.1. 开发
    2. 3.2. 测试及跟踪
    3. 3.3. 部署
  4. 4. Tuscany
    1. 4.1. 开发
    2. 4.2. 测试及跟踪
    3. 4.3. 部署
  5. 5. Mule
    1. 5.1. 开发
    2. 5.2. 测试及跟踪
    3. 5.3. 部署