JBI学习笔记

我们注意到，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 Provider)存在。

在选择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架构有哪些基本的要求：

1.         SOA在相对较粗的粒度上对应用服务或业务模块进行封装与重用；

2.         服务间保持松散耦合，基于开放的标准， 服务的接口描述与具体实现无关；

3.         灵活的架构 -服务的实现细节，服务的位置乃至服务请求的底层协议都应该透明；