1.1 SOA的基本概念
SOA是英文词语"Service Oriented Architecture"的缩写，中文有多种翻译，如"面向服务的体系结构"、"以服务为中心的体系结构"和"面向服务的架构"，其中"面向服务的架构"比较常见。SOA有很多定义，但基本上可以分为两类：一类认为SOA主要是一种架构风格；另一类认为SOA是包含运行环境、编程模型、架构风格和相关方法论等在内的一整套新的分布式软件系统构造方法和环境，涵盖服务的整个生命周期：建模-开发-整合-部署-运行-管理。后者概括的范围更大，着眼于未来的发展，我们更倾向于后者，认为SOA是分布式软件系统构造方法和环境的新发展阶段。
在SOA架构风格中，服务是最核心的抽象手段，业务被划分（组件化）为一系列粗粒度的业务服务和业务流程。业务服务相对独立、自包含、可重用，由一个或者多个分布的系统所实现，而业务流程由服务组装而来。一个"服务"定义了一个与业务功能或业务数据相关的接口，以及约束这个接口的契约，如服务质量要求、业务规则、安全性要求、法律法规的遵循、关键业绩指标（Key Performance Indicator，KPI）等。接口和契约采用中立、基于标准的方式进行定义，它独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在不同系统中的服务可以以一种统一的和通用的方式进行交互、相互理解。除了这种不依赖于特定技术的中立特性，通过服务注册库（Service Registry）加上企业服务总线（Enterprise Service Bus）来支持动态查询、定位、路由和中介（Mediation）的能力，使得服务之间的交互是动态的，位置是透明的。技术和位置的透明性，使得服务的请求者和提供者之间高度解耦。这种松耦合系统的好处有两点：一点是它适应变化的灵活性；另一点是当某个服务的内部结构和实现逐渐发生改变时，不影响其他服务。而紧耦合则是指应用程序的不同组件之间的接口与其功能和结构是紧密相连的，因而当发生变化时，某一部分的调整会随着各种紧耦合的关系引起其他部分甚至整个应用程序的更改，这样的系统架构就很脆弱了。
SOA架构带来的另一个重要观点是业务驱动IT，即IT和业务更加紧密地对齐。以粗粒度的业务服务为基础来对业务建模，会产生更加简洁的业务和系统视图；以服务为基础来实现的IT系统更灵活、更易于重用、更好（也更快）地应对变化；以服务为基础，通过显式地定义、描述、实现和管理业务层次的粗粒度服务（包括业务流程），提供了业务模型和相关IT实现之间更好的"可追溯性"，减小了它们之间的差距，使得业务的变化更容易传递到IT。
因此，可以将SOA的主要优点概括为：IT能够更好更快地提供业务价值（Business Centric）、快速应变能力（Flexibility）、重用（Reusability）。
从演变的历程来看，SOA在很多年前就被提出来了，现在SOA的再现和流行是若干因素的结合。一方面是多年的软件工程发展和实践所积累的经验、方法和各种设计/架构模式，包括OO/CBD/MDD/MDA、EAI和中间件；另一方面是互联网的多年发展带来前所未有的分布式系统的交互能力和标准化基础。与此同时，企业越来越重视业务模型本身的组件化，以支持高度灵活的业务战略。但是现有的企业软件架构不够灵活，难以适应日益复杂的企业整合，难以满足随需应变商务的需要，因此与业务对齐、以业务的敏捷应变能力为首要目标、松散耦合、支持重用的SOA架构方法得到青睐。更多的细节请参见"以服务为中心的企业整合"（
http://www-128.ibm.com/developerworks/cn/ webservices/ws-soi1/）。
基于我们同客户打交道的经验，有必要在这里澄清大家经常混淆的几个基本问题。
第一，SOA是架构风格，是方法；而不是具体架构具体实现技术（如Web Service）、具体架构元素（如企业服务总线，Enterprise Service Bus，ESB）。
经常有人认为只要用了Web Service，就是SOA了。这是不对的，Web Service只是实现服务的一种具体技术表现形式。同样，认为搞SOA，就是买点软件，建个ESB，这也是不对的，ESB只是SOA架构风格中的一部分。首先，ESB是一种从实践中总结出来的架构风格元素，即BUS（总线模式）；其次，ESB的主要功能是负责连通性和服务中介（Service Mediation），解耦服务的请求者和服务的提供者。
第二，SOA的首要目标是IT与业务对齐，支持业务的快速变化；其次是IT架构的灵活性和IT资产的重用。
业务对敏捷性的需要，是SOA最大的驱动力。一方面是业务在这方面的要求越来越高；另一方面是今天的IT很不灵活，很难适应业务快速变化的需求，不仅仅是因为IT架构不灵活，更重要的是业务模型中的元素和IT系统的元素之间存在很大的差距。这种不对齐，导致业务人员和IT人员之间的沟通不够有效，业务的变化需要花费很大的代价传递到IT系统。很难想像，业务人员对一个Java对象，一个EJB或者一个JSP页面感兴趣，这离业务世界太远了。这种业务和IT的对齐，需要在IT系统中实现更高阶的抽象元素，就是业务模型中的元素（服务、流程、业绩管理），并且满足业务需要的水平整合（将人、信息、应用和流程端到端地动态整合起来）。这样一个以服务为中心的、端到端整合的环境，首先使得业务变化可以在业务元素这个层面上沟通，更容易、更准确地从业务传递到IT。其次，这种变化被隔离在需要变化的局部，而不扩散到系统的其他部分。这就需要整个IT架构本身是松散耦合的，一个服务的变化（功能、数据、过程、技术环境等）不影响其他服务。最后，我们希望这些反映业务元素的服务，是相对稳定、可以重用的，这对快速适应变化、减少成本是非常重要的。
第三，在工程上，SOA的重点是服务建模和基于SOA的设计原则进行架构决策和设计。
经常碰到客户提出这样的问题：SOA挺好，为什么好？怎么做才是SOA的方法？跟过去的方法，比如OO/CBD有什么不同？有时候一个J2EE服务器就好了，为什么那么复杂？
从建模和设计的角度来说，SOA更多地侧重在业务层次上，也就是通过服务建模将业务组件化为服务模型，它是业务架构的底层，是技术架构的顶层，承上启下，是灵活的业务模型和IT之间的桥梁，保证二者之间的"可追溯性"。从这里往下，是基于已有的方法，比如OO/CBD来进行的。从架构的层次上，SOA更多地侧重于如何将企业范围内多个分布的系统（包括已有系统/遗留系统）连接起来（ESB，Adapter/Connector），如何将它们的功能、数据转化为服务，如何通过服务中介机制（ESB，Service Registry）保证服务之间以松散耦合的方式交互，如何组装（集成）服务为流程，如何管理服务和流程等。从这往下，对于实现服务的一个具体应用，它的架构、设计和实现是可以基于已有的实践和方法的，比如J2EE或.NET。
有些时候，由于业务需求比较简单，所有这些东西都在一个J2EE的应用服务器上，有些要素不是那么突出，不过随着系统规模的扩大，要解决的业务问题更复杂、范围更大的时候，SOA的各种架构要素就会变得越来越重要。
在下面的小节里就概括地讨论一下SOA的若干个重要方面，包括：面向服务的计算环境，编程模型，架构风格，工程方法，以及相关的技术。
【责任编辑：
雪花 TEL：（010）68476606-8007】
