搜索
引言一切都在流动，没有什么是持久的。一切都在融化，没有什么是固定不变的-赫拉克利特(Heracleitus)大约在2003年中的时候，SOA的概念逐渐进入人们的视野，一时间众人乐此不疲的发表各自对SOA的见解。SOA已经成为IT业，尤其是软件开发及系统集成领域从业者的热门话题。很多的权威机构也纷纷预测SOA的美妙前景，例如，Gartner预言，到了2008年，至少60%的企业将使用SOA作为其IT架构。抛开喧嚣躁动以及随声附和，对于软件开发者而言，经过了一年多的概念灌输，伴随着不断增长的困惑，更多的人希望能静下心来看一看：究竟怎样的系统架构是符合SOA设计的，而又有哪些技术可以用来实现SOA呢？特别是企业服务总线(EnterpriseServiceBus,ESB)，看起来更是SOA中一个玄虚的概念，本系列文章将通过实际的案例分析来详细讲解在SOA系统中是怎样实施ESB的。本系列文章将直接面向广大的软件开发人员，首先以直观的方式介绍什么是ESB，然后引入一个实际案例，以此为基础，详细介绍怎样一步一步实现ESB。现在我们谈论SOA和ESB的时候都不再是空中楼阁，IBM作为SOA的倡导者，已经提供了很好的产品来实现我们的设想。我们会在本系列中的第二、第三部分中分别介绍基于WebSphere6和IBMEAI产品的两种实现方式，然后在第四部分中介绍在复杂的企业应用场景中总线(Bus)怎样互联，怎样扩展。希望通过本系列文章，能让广大读者朋友快速掌握ESB的实际开发技巧。关于SOA关于SOA的概念，你可以找到很多的文章从不同的角度来描述它，不同的软件提供商也有不同的定义方式。BEA有流体计算，微软有Indigo和SOA-building，SAP有ESA。每个人都可以从不同的视角来理解SOA，从程序员的角度，SOA是一种全新的开发技术，新的组件模型，比如说WebService；从架构设计师的角度，SOA就是一种新的设计模式，方法学；从业务分析人员的角度，SOA就是基于标准的业务应用服务。从概念的角度，IBM对SOA的定义是最为全面的，既SOA是一种构造分布式系统的方法，它将业务应用功能以服务的形式提供给最终用户应用或其他服务。SOA包括如下要素:回页首一个体系架构，用开放的标准将软件资产(Asset)化为服务提供标准的方法来表示软件资产及其交互单独的软件资产作为构造单元，被重复使用来开发其他应用将关注点从细节实现转移到应用(application)组装整合企业外部的应用（B2B）的方式开发（现在）和整合（未来）的统一本文针对的读者是软件开发人员，站在开发人员的角度，往往希望软件开发能够满足对于开发效率、可靠性、易维护性、易管理等多方面的更高要求。让我们通过回顾软件开发的演化过程来看一看SOA出现的必然性：面向机器语言(Monolithic)的开发模式：需要根据不同平台的机器语言来开发代码。面向过程(Procedure)的开发模式：独立于机器的程序语言(C,Pascal等)使开发过程变得简单了，用过程来代表一个抽象的代码集合，包装重用现成的代码。面向对象(Object)的开发模式：用更接近现实的对象来表述一个相对完整的事物。面向对象的语言(Smalltalk，Java等)，提供了更抽象的封装和重用模式。面向对象的开发强调从现实世界问题域到软件程序的直接映射，更接近人类的自然思维方式。面向组件(Component)的模式：随着软件开发规模的扩大，在涉及分布式、异构等复杂特征的环境中，代码级别的重用性差，可维护性差，效率低的弱点是不可逾越的，因此人们以架构运行环境(如.Net，J2ee等)来提供完善的支撑平台，从而把开发者解放出来，更专注于业务核心的开发。而这些业务功能(BusinessFunction)以组件的形式(DCOM，EJB等)发布运行在架构运行环境中。软件开发的重用模式也上升到业务组件的级别。面向服务(SOA)的模式：当软件的使用范围扩展到更广阔的范围，往往会面对更加复杂的IT环境和更加灵活多变的需求。服务(Service)的概念出现了，人们将应用(Application)以业务服务(BusinessService)的形式公布出来供别人使用，而完全不需要去考虑这些业务服务运行在哪一个架构体系上，因为所有的服务都讲着同样的语言。SOA考虑了业务发展的长期性，体现了变化就是永恒的思想。SOA的核心体现在企业应用或者业务功能上的重用和互操作，而不再把IT与业务对立起来，这可以被视为在IT驱动业务的方向上迈出的重要一步。我们注意到，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平台的一个服务提供者(ServiceProvider)存在。在选择SOA的实施方案时，要记住，软件的具体实现技术诸如Web服务与SOA是两回事，SOA是一个概念，方法学，或者用一个更时髦的词：一种模型。而Web服务呢？它是一种具体的实现技术，就像EJB一样。SOA≠Web服务。不过公平地讲，Web服务倒确实是目前最适合实现SOA的技术之一，用Web服务来封装业务服务是个不错的选择。因为Web服务是标准的，WS-I协议保证了来自不同厂商的Web服务即使运行在不同的平台上，底层的实现机理不同也可以顺利交互，这是以前的任何一种技术如CORBA，EJB，或DCOM都不能做到的。而且，Web服务的定义与实现是分开描述的，即松散耦合，因此，可以很方便地替换服务的内在实现而不会对现有的系统造成任何冲击，这也极大地促进了IT架构的灵活性。对于SOA更进一步的了解，可以参考IBMdeveloperWorks上其他SOA相关的文章(请参见参考资料)，我们的系列文章将主要讨论ESB，因此不再此过多地论述SOA了。为了使我们下面的论述更顺畅，请先牢记典型的SOA架构有哪些基本的要求：1.SOA在相对较粗的粒度上对应用服务或业务模块进行封装与重用；2.服务间保持松散耦合，基于开放的标准，服务的接口描述与具体实现无关；3.灵活的架构-服务的实现细节，服务的位置乃至服务请求的底层协议都应该透明；ESB让我们暂时回到网络技术不普及的时代，你怎样在两台机器之间传递文件？我还记得为了给实验室的每台机器安装BorlandC++的环境，猜猜我动用了什么：一根串口线。不过，我仍然觉得庆幸，好在每台机器都运行同样的操作系统-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是一种在松散耦合的服务和应用之间标准的集成方式