服务的特征

　　引言

　　96年Gartner提出SOA，目的是让企业业务更加敏捷，软件系统变得更有弹性，使企业能快速响应需求的变化，这样的目的是有当时背景的。经济全球化要求企业的业务具备更大的灵活性，比以往能更快地响应市场变化，业务快速变化则要求软件系统具备更大的弹性，而对于企业已经普遍存在的遗留系统来说，这无疑是办不到的，不但办不到，而且遗留系统本身还存在信息孤岛问题。从资源利用的角度，企业为实现利益最大化，遗留系统的问题需要解决，新建系统的弹性更需要解决，就在这样的环境下SOA被提出来，而且越炒越热，从最初基于SOA思想的实现原则、架构模型、参考模型等等一路走来，直到目前的编程模型。OSOA在今年2月份将SCA标准提交给OASIS，到2009年初，SCA将由现在的行业标准变成真正的国际标准。而企业对SOA寄予厚望，同样对SOA的投资也越来越庞大，如IBM现在每年在SOA上的投入多达10亿美元。SOA正由幕后真正的走到台前。

　　SOA曾经也默默无闻

　　SOA提出后，限于当时的环境与技术，仅停留在思想层面，直至2003年前后，WebServices异常火爆，SOA才在应用层面有了一片实验田，但SOA成了WebServices的上层模型，几乎等同于WebServices。2003年到2005年，SUNJCP也在酝酿着被称为SOA切入点的JBI，作为ESB构建的核心标准，但IBM与BEA却在历次投票中均弃权，理由是JBI不能真正实现SOA，结果JBI在日后也逐渐销声匿迹，虽然ESB仍然被认为是SOA的重要组成。而在2005底，业内四大巨头IBM、BEA、ORACLE、SAP共同发起成立了OSOA厂商联盟，致力于开发语言中立的SOA编程模型，并且随着SUN在2006年7月份的加入，OSOA厂商已达18家，SOA编程模型，SCA与SDO，成为实现SOA的行业事实标准。

　　到底该如何理解SOA

　　有人认为SOA并不是什么新概念，从RPC、IPC直至分布式计算的CORBA、DCOM等，几乎都带有SOA的影子，只是实现角度与方式的差别。那么SOA到底该如何理解？其本质究竟有何吸引人之处？从诞生到成长，SOA被赋予太多的使命与含义，以至长时间里SOA都不能准确定义，直到今天，才渐渐清晰。

　　开始的时候，SOA只是个方法，是个架构模型

　　开始的很长一段时间里，SOA只是个方法，是指导企业实现业务敏捷性及建设弹性软件系统的架构模型，引用Bloomberg的SOA实现原则：

　　1、业务驱动服务，服务驱动技术。

　　2、业务敏捷是基本的业务需求。

　　3、一个成功的SOA总在变化之中。

　　可以看出，SOA的核心围绕着业务敏捷性展开。业务敏捷性是指企业对变更快速而有效地响应、并且利用变更来得到竞争优势的能力。在当下越来越激烈的市场竞争中，企业为了生存决不会放弃任何能够提高自身竞争实力的机会，业务敏捷性也是如此。实现业务敏捷性首先要求业务本身就具备敏捷性，业务本身就能够对变更快速而有效的响应，这其实是企业管理建设上考虑的事情，涉及到如何使企业信息流通通畅、业务流程重组优化、资源合理配置等等一系列问题，最本质的作法是企业从自身来发现问题所在并改正。

　　业务具备敏捷性后，接下来考虑的才是通过弹性软件系统来更好的表达业务敏捷性，这应该属于软件方法论的范畴，而这当中的探索可以说历经了软件的整个发展过程，一直探寻的本质其实是信息世界与现实世界间映射关系的建设，也就是如何用软件系统更好的表达现实当中的业务，即现在大家经常说的业务建模。

　　那么到底如何能够用软件系统来更好的表达现实当中的业务呢？我相信这将会是业内永久的话题。从结构化方法，面向对象方法，直到现在的面向服务方法，随着计算机硬件及网络的发展，世界经济环境的发展，软件系统本身也在不断的发展变化，但其目标却一直没有变化过，那就是更好的描述现实世界并且提升。

　　SOA秉承的也是这一目标，只是更多了一个考虑：如何应对出现的各种变化，而这些变化主要集中在两个方面：现实世界的发展变化、软件系统本身的发展变化。现实世界的不断变化，要求软件系统能够适应这种变化，软件系统本身也在不断地发展变化，要求新建软件系统能够兼顾遗留软件系统，而只有建设自身就在不断变化的软件系统，才能应对现实世界的不断变化，只有建设技术实现无关的软件系统，才能实现新建软件系统与遗留软件系统的兼顾。引用一句很有哲理的话就是：世界上唯一不变的就是变化。这就是SOA要解决的问题。变化是软件系统建设决不可回避的问题。

　　SOA的本质还是业务建模，服务只是业务模型的形式

　　从上面可以看出，SOA架构模型的本质其实还是业务建模，侧重于为应对变化而需要敏捷性的业务建模，至于服务只是业务模型暴露出来的形式，以统一的服务形式描述业务模型。业务的变化是在模型内部的变化，业务敏捷性反映在业务建模的敏捷性上，而服务则解决敏捷业务间的互操作问题。由此可以看出服务只是业务的包装形式，这种形式只要可以解决互操作问题，而可以不问形式到底是什么。这就是为什么有人说：从RPC、IPC直至分布式计算的CORBA、DCOM等，几乎都带有SOA的影子。从SOA架构模型来理解，它们只是服务的形式，服务形式发展历史上经历的技术成熟阶段的产物。目前阶段的SOA肯定也不会是终极形式，只能说是到目前为止最为成熟的形式而已。

　　话题说到这里，其实应该是分为两个话题了，那就是：具有业务敏捷性的业务建模与技术形式最为成熟的服务。

　　第一个话题在目前其实也是有成熟的国际标准化组织在推动的，这就是OMG下的MDA，ModelDriverArchitecture，面向服务架构，这也是目前的热门话题，并且已经出现了研究分支，如DSM，DomainSpecificModeling，领域特定建模。这里涉及到一个软件生产力的问题，从汇编语言到Basic语言，软件生产力提高了400%，而从Basic往后，如C++、Java，软件生产力提高不足20%，究其原因何在：抽象程度不够，而业务建模被认为是提高抽象程度的有效手段。业务建模从另外的角度看仍然具备绝对的重要性。鉴于这篇文章的主题是关于SOA的话题，这个话题我们暂且不表。

　　但在这里，笔者认为需要提到一点的是：为实现业务敏捷性，业务建模与服务形式存在交叉，即当业务模型以统一的服务形式暴露出来后，便可以通过组装模型组装具有统一服务形式的业务模型，以期实现更大范围的业务敏捷性，这也是目前SOA研究范畴中非常重要的部分，即以统一的服务形式为基础，通过组装模型，实现更大范围的业务敏捷性。SOA架构模型包含以统一的服务形式为基础通过组装模型实现更大范围的业务建模。

　　在这里还需要提到一点的是，2005年前后出现的针对遗留系统的整合技术，笔者认为只是一种过渡技术，是SOA服务形式探索道路上的阶段性产物。整合解决的是软件系统间的互联互通问题，而SOA的组装模型并不局限于此，所以两种技术针对遗留系统的解决方案也不尽相同：组装必须首先以遗留系统的服务化改造为基础，然后以统一的服务形式进行组装，而整合则无此必要步骤。在这里笔者也不展开来讨论了。

[1] [2] [3] 下一页