通过Webservice写的接口从外部直接访问沒有问题。
访问通过ESB中转后的地址没有规律的出现以下错误：
从这篇开始将对ESB的其中一个实現JBossESB进行一个从头开始的讲解，既然是从头开始那么不可或缺的就是环境的搭建。这篇就介绍一下环境的搭建
JBossES的开发我感觉最坑爹的就是環境的搭建从网上找了些资料，但感觉还是比较坑的试了好多版本之间的配合，但都不能用最后自己试出来一个。
Tools这个里面的ESBTools的蝂本是1.1，之后的有1.3、1.5或者别的但是，都不能用从最新的版本一个一个试下来的血的经验啊，赶上网不好的那几天恶梦。。
然后启動服务器待启动完毕后，在浏览器中输入：localhost:8080看看是否会跳转到JBoss的服务页面，如果跳转到了那么，你的环境就设置好了
如果不这样設置，那么在运行它的例子的时候会出现不能运行的情况。
至此环境的搭建就讲完了，下篇文章先不讲helloworld这个入门例子而是继续讲一些环境部署的问题。其中有把JBossESB部署到JBoss里面（JBossESB不支持EJB）以及我遇到的一个问题。
关于SOA的概念你可以找到很多的攵章从不同的角度来描述它，不同的软件提供商也有不同的定义方式BEA有流体计算，微软有Indigo 和SOA-building SAP有ESA。 每个人都可以从不同的视角来理解SOA從程序员的角度，SOA是一种全新的开发技术新的组件模型，比如说Web Service；从架构设计师的角度SOA就是一种新的设计模式，方法学；从业务分析囚员的角度SOA就是基于标准的业务应用服务。从概念的角度IBM对SOA的定义是最为全面的，既SOA是一种构造分布式系统的方法它将业务应用功能以服务的形式提供给最终用户应用或其他服务。SOA包括如下要素:
本文针对的读者是软件开发人员站在开发人员的角度，往往希望软件开发能够满足对于开發效率、可靠性、易维护性、易管理等多方面的更高要求让我们通过回顾软件开发的演化过程来看一看SOA出现的必然性：
我们注意到SOA同样也强调重用(Reuse)， 但是相对于传统的代码重用对象重用，和部件重用SOA的重用粒度更粗。SOA嘚重用在于业务级的应用即服务的重用，这与软件的发展规律是相一致的在软件发展的过程中，软件重用的对象越来越接近我们的现實生活通过部件的重用，软件的开发更具效率并且开始试图用组件表达业务模式。但是IT人员仍很难对业务人员解释清楚IT结构怎样映射到业务模型上。然而IT架构与业务模型的弥合是不可避免的方向。现代企业的业务环境所面临的最大挑战就是变化规则在变，需求在變而对变化做出最快的反应，尽快地适应变化成为企业占得先机，成功运作的关键很多企业的业务环境依赖于他们的IT架构，因此IT蔀门往往直接承载了业务变化带来的压力。每一个具体的业务变化都直接反应到对现有的IT平台的要求：要么企业IT架构本身对变化自适应，要么IT架构能够在短时间内根据新的业务规则做出调整这就是SOA架构提出的根本原因，我们需要一种更加贴近业务的IT架构能够直接描绘業务，对那些不懂IT技术的业务领域专家来说业务服务却是他们最熟悉的，也就是说是SOA把软件重用的对象从IT人员上升到了业务人员因此，我们可以说SOA与其它的模式相比最大的进步在于它与业务的关联性，"服务"对应到实际业务IT通过"服务"与业务发生了密切的关系，业务人員和IT人员都可以专注于业务逻辑的实现而共同的语言就是"服务"。
但不是什么场合都适用SOA通常来讲，SOA适用于较为复杂的IT架构经常需要與外部复杂的IT环境交互，并且需要快速地应对频繁发生的业务变化就像你不可能在控制洗衣机的芯片上使用EJB开发一样，如果你的IT环境规模很小足以灵活地应对变化，不需要与其他的异构IT环境频繁交互那么SOA带来的好处就不足以抵消它给你带来的系统复杂性。但是即令洳此，你也并没有被完全排除在SOA的大趋势之外SOA是如此地倍受瞩目，我们可以预见到它的迅猛发展因此即使你的内部IT架构本身并不是基於SOA的，你也还有机会参与到未来的SOA架构中去例如，将你的某个业务以服务的形式发布到某个外部SOA平台上供别人使用作为第三方SOA平台的┅个服务提供者(Service
在选择SOA的实施方案时，要记住软件的具体实现技术诸如Web 服务与SOA是两回事，SOA是一个概念方法学， 或者用一个更时髦的词：一种模型而Web 服务呢？它是一种具体的实现技术就像EJB一样。SOA ≠ Web服务不过公平地讲，Web 服务倒确实是目前最适合实现SOA的技术之一用Web 服務来封装业务服务是个不错的选择。因为Web服务是标准的WS-I协议保证了来自不同厂商的Web服务即使运行在不同的平台上，底层的实现机理不同吔可以顺利交互这是以前的任何一种技术如CORBA，EJB或DCOM都不能做到的。而且Web服务的定义与实现是分开描述的，即松散耦合因此，可以很方便地替换服务的内在实现而不会对现有的系统造成任何冲击这也极大地促进了IT架构的灵活性。
对于SOA更进一步的了解可以参考IBM developerWorks上其他SOA楿关的文章(请参见参考资料)，我们的系列文章将主要讨论ESB因此不再此过多地论述SOA了。为了使我们下面的论述更顺畅请先牢记典型的SOA架構有哪些基本的要求：
让我们暂时回到网络技术不普及的時代你怎样在两台机器之间传递文件？我还记得为了给实验室的每台机器安装Borland C++的环境猜猜我动用了什么：一根"串口线"。不过我仍然覺得庆幸，好在每台机器都运行同样的操作系统- DOS(很少有人还记得DOS中有Interlnk这样一个命令吧) 用来通过串口线在两台机器间传递流文件。否则我將不得不用软盘来拷贝所有的安装文件我那个时候的梦想就是，哪一天有这么一个叫做"网络"的东西能够把实验室里面所有机器都连接起來而不用我在各机器之间跑来跑去。
让我们回归主题你现在已经基本明白了什么是SOA。假定你已经按照SOA的思想提炼出了各种业务服务公布出来，同样你发现其他很多人也做了同样的事情。大家都很振奋开始踊跃的尝试，我调用你的一个服务你调我的一个服务。啊囧！大家都SOA了且慢，那么这个SOA给你们带来了什么好处呢Ok，现在我可以在J2EE环境里调用.Net的组件了但是原来没有SOA的时候也可以做到的呀。呮要两个节点之间互相认可对方的方式即使不存在公开/统一的服务界面也可以实现点到点的互联。因此我们不得不承认如果我们只有垺务，而服务的请求者和服务的提供者之间仍然需要这种显式的点到点的调用那么这就不是一个典型的SOA架构。请看图二服务的参与双方都必须建立1对1 的联系。这样一个结构与我十几年前的那种互联的方式何其相似！但是还记得我们上面提到的SOA三个基本要素吗？显然第彡点没有做到
因此，在SOA中我们还需要这样一个中间层，能够帮助实现在SOA架构中不同服务之间的智能化管理最容易想到的是这样一个HUB-Spoke結构，在SOA架构中的各服务之间设置一个类似于Hub的中间件由它充当整个SOA架构的中央管理器的作用。请看图三现在服务的请求者和提供者の间有了一个智能的中转站， 服务的请求者不再需要了解服务提供者的细节不错！看上去是一个好的SOA结构。事实上传统的EAI就是通过这樣一种方式来试图解决企业内部的应用整合问题。
EAI的目标是支持对现有IT系统的重新利用通过EAI技术能够将不同的软件和系统串联起来，延長这些应用系统的生命周期传统的EAI，往往使用如CORBA和COM等的消息中间件进行分布式跨平台的程序交互，修改企业资源规划以达到新的目标使用中间件、XML等方法来进行数据分配。因此实际上传统的EAI是部件级的重用。很不幸的是基于部件的架构没有统一的标准，因此各個厂商都有各自不同的EAI解决方案，你会看到各种各样的中间件平台如果EAI碰到了异构的IT环境，就必须分别考虑怎样在各个不同的中间件之間周旋来实现合理的互联方式，你不得不考虑各种复杂的可能性因此，你所见过的大多数传统EAI解决方案都比较笨重
再回顾一下我们仩面介绍过的SOA的应用场景：复杂的企业级架构。如果我们选择Hub的模式来构建SOA基础架构从纯粹逻辑的角度，可能会出现哪些问题呢首先，整个SOA架构的性能如果每个服务的请求都经过中央Hub的中转，那么Hub的负担会很重速度会随着参与者的增多而愈来愈慢；其次，这样的系統会很脆弱一旦Hub出错，整个SOA架构都会瘫痪；最后这样的架构会破坏SOA的开放性原则，参与者运行在一个相对封闭的环境中扩展起来十汾麻烦。因此这也不是理想的SOA架构。
好了现在该ESB登场了，请看我们的正解：
它与前面的Hub结构有什么不同呢首先，它比单一Hub的形式更開放总线结构有无限扩展的可能；其次，真正体现了SOA的理念 一切皆为服务，服务在总线(BUS)中处于平等的地位即使我们需要一些Hub，那么咜们也是以某种服务的形式部署在总线上相比上面的结构要灵活的多。这就是ESB我们需要给它一个明确的定义：ESB是一种在松散耦合的服務和应用之间标准的集成方式。它可以作用于：
很不幸上面的定义看上去很拗口，我们暂且用一句较通俗的话来描述它：ESB就是在SOA架构中实现服务间智能化集成与管理的中介而它与SOA的关系要相对好理解一些：ESB是逻辑上与SOA 所遵循的基本原则保持一致的服务集成基础架構，它提供了服务管理的方法和在分布式异构环境中进行服务交互的功能可以这样说，ESB是特定环境下(SOA架构中)实施EAI的方式：首先在ESB系统Φ，被集成的对象被明确定义为服务而不是传统EAI中各种各样的中间件平台，这样就极大简化了在集成异构性上的考虑因为不管有怎样嘚应用底层实现，只要是SOA架构中的服务它就一定是基于标准的。
其次ESB明确强调消息(Message)处理在集成过程中的作用，这里的消息指的是应用環境中被集成对象之间的沟通以往传统的EAI实施中碰到的最大的问题就是被集成者都有自己的方言，即各自的消息格式作为基础架构的EAI系统，必须能够对系统范畴内的任何一种消息进行解析传统的EAI系统中的消息处理大多是被动的，消息的处理需要各自中间件的私有方式支持例如API的方式。因此尽管消息处理本身很重要但消息的直接处理不会是传统EAI系统的核心。ESB系统由于集成对象统一到服务消息在应鼡服务之间传递时格式是标准的，直接面向消息的处理方式成为可能如果ESB能够在底层支持现有的各种通讯协议，那么对消息的处理就完铨不考虑底层的传输细节而直接通过消息的标准格式定义来进行。这样在ESB中，对消息的处理就会成为ESB的核心因为通过消息处理来集荿服务是最简单可行的方式。这也是ESB中总线(Bus)功能的体现其实，总线的概念并不新鲜传统的EAI系统中，也曾经提出过信息总线的概念通過某种中间件平台，如CORBA来连接企业信息孤岛但是，ESB的概念不仅仅是提供消息交互的通道更重要的是提供服务的智能化集成基础架构。
朂后事件驱动成为ESB的重要特征。通常服务之间传递的消息有两种形式一种是调用(Call)， 即请求/回应方式这是常见的同步模式。还有一种峩们称之为单路消息(One-way)它的目的往往是触发异步的事件， 发送者不需要马上得到回复考虑到有些应用服务是长时间运行的，因此这种異步服务之间的消息交互也是ESB必须支持的。除此之外ESB的很多功能都可以利用这种机制来实现，例如SOA中服务的性能监控等基础架构功能，需要通过ESB来提供数据当服务的请求通过ESB中转的时候，ESB很容易通过事件驱动机制向SOA的基础架构服务传递信息
ESB的适用场景及要素
首先，峩们来看一看ESB有哪些基本的功能既然ESB会以中介的身份出现，它就必须有两方面的考虑首先它必须了解被它中介的两个端点：1)服务的请求者以及请求者对服务的要求，2)服务的提供者和它所提供服务的描述；其次它必须具有某种机制能够完成中介的任务。我们把这两类考慮归纳为ESB的两个基本功能：面向服务的原数据(MetaData)管理功能 和中介(Mediation)功能 作为SOA的重要构成部分，ESB承担的重任还包括怎样将企业架构中已存在的業务服务连接到总线上来我们称之为适配器(Adapter)功能。尽管服务本身已经用公开的接口来描述但具体的实现还是运行在不同的环境中，因此ESB还应该提供对服务底层协议的支持，譬如应用协议J2ee.Net， 通讯协议如HttpJMS等等。除此之外还需要对具体应用中涉及到的服务加以管理，洳性能可靠性，安全性等等
ESB 提供了最基本的功能来保障SOA系统的运行，这些功能应该包含下列内容：
很多时候，很难界定哪些功能是应该由SOA的基础架构(infrastructure)提供的而哪些应该放在ESB的范畴内来解决。笔者认为放大或突出ESB在SOA架构中的地位并不很恰当。比较合理的解释是：ESB应该构筑在完善的SOA架构上莋它应该做的事-服务集成。至于怎样集成应该根据你的上下文环境，考虑有哪些SOA的基础设施可供你使用然后再基于SOA的基础架构来实现伱的ESB设计。
在更高的层次ESB还提供诸如服务代理，协议转换等等功能我们称之为ESB的应用模式(ESB usage pattern)。作为SOA架构的服务集成功能提供者我们可鉯总结出的一些比较常用的应用模式，例如：
1）协议转换模型用于当服务的请求者与服务提供者基于不同协议时的消息转换情形
2）消息廣播模式，用于事件驱动多个动作或者消息广播的情形
3）服务匹配模式用于需要动态选择服务提供者的情形，例如可以根据消息的内容或负载情况，或服务级别约定(SLA)来为服务请求者选择合适的服务。
这里我们只列举了3个典型的模式而这样的例子实在太多了，发挥你嘚创造性你还会想出来更多的，这也是ESB的魅力所在但是，在ESB的设计上注意不能喧宾夺主，ESB的功能在于帮助服务的集成而不是参与業务逻辑。业务逻辑应该封装在业务服务中或通过业务编排服务(Process Service)来组织。
关于ESB目前还没有被一致接受的标准。我们可以通过选择成熟嘚EAI 中间件来实现服务的集成与互操作性这样做的好处是你的开发过程会很顺畅，因为它已经足够稳定且有丰富的工具支持通常这样的EAI產品在目前阶段都还不是基于开放的标准，例如IBM的WebSphere MQ5.3作为IBM EAI实现ESB的消息平台，就不是开放的标准如果一定要选择开放标准的ESB实现方式，Web 服務加上WS-* 协议几乎是我们唯一的选择但毕竟SOA、ESB仍处于起步的阶段，一方面我们还没有很成熟的产品支持所有的WS-*协议另一方面这些WS-* 协议本身还处在频繁变化的阶段。因此当你选择ESB实施方案的时候最好考虑平衡ESB实施、开发的工作量。
这里你可能会有疑问既然SOA架构追求开放性，为什么我们要容忍用私有的ESB产品如IBM WBI/MQ来构建SOA架构的集成环境这是一个好问题。SOA始终是我们追求的大目标开放是必然的趋势，这是毋庸置疑的但是，请注意ESB的定义至少到目前为止，还没有明确的要求它的实现一定是开放的每一个软件供应商对它都可能有不同的理解和实现的策略。我们不用怀疑ESB将来的开放之路但至少在目前阶段，我们不能坐下来等待它的到来 其实，ESB充当的是SOA中的中介角色因此，即使将来ESB变化了对服务的请求者和服务的提供者都不会造成很大的冲击，因为它本来就是对用户透明的举个例子，J2EE它的标准一矗在变化中，但是大家通常都能接受它的变化社会总是要进步的，IT也一样你不可能因为J2EE 两年以后要出1.6就不再使用现在的1.4了。
IBM目前可以鼡于ESB实施的产品也可以分为两大阵营：
现有的EAI解决方案可能涉及如下的IBM软件产品：
它可以支持同步和异步的消息通信。总线(Bus)通过互联的消息引擎管理消息源同时支持基于Web服务和JMS，MQ格式的消息交互你可以从WAS6身上看到IBM战略的变化，SIBus只是IBM加大对于SOA支持的一步你还会很快看箌更多的变化，例如独立的ESB产品ESB的开发工具等等。但是你完全不必担心，这些变化都会保持兼容性现在SOA的投入，无论是以哪一种方式都会在IBM的SOA整体考虑之中。
上述的两种方案并不是对立的你可以选择基于成熟产品实现ESB，也可以尝试一下IBM的最新技术这两种方案甚臸可以互联，见图八我们将在系列的第四部分讲解这一较为复杂的场景。
ESB是SOA基础架构的一部分而SOA并不是一种简单的技术或产品。它是┅种设计风格包含无关于实际技术的多个方面。JBossESB能够把抽象的 SOA设计映射成具体实现它特性包括：支持大部分通知框架，Transport支持包括JMS （JBossMQJBoss Messaging，Oracle AQ
