本文作者为IBM SOA设计中心主管、IBM高级技术主管毛新生
《程序员》杂志邀请我写一篇短文探讨SOA的本质，也就是它究竟是什么。这个题目不好写，易起纷争，所以我预先说，这篇文章是用来分享我个人的理解，提供探讨用的材料，不是答案。
让我们开门见山。SOA的首要目的是让业务能够快速地响应或领导变化，即“业务敏捷性”(Business Agility)。而SOA自身，首先是设计原则和风格;其次它是来自实践、应用这些原则和风格的架构范式;再次，SOA是支持和实现这些原则和风格的技术、标准和产品;最后，它是保证企业各方有规可循、透过在“服务”的生命周期中相互协作来达成业务敏捷的管控策略(Governance)。
既然SOA是IT正在发生的一个大的变化和范式转移，这对我们意味着什么呢?本文也将简单讨论。
业务敏捷性
“敏捷性”(Agility)，包括几个重要因素：变化，变化的速度，和变化的质量。“业务敏捷性”让一个企(事)业能够适时、快速地响应变化，采取恰当、明智的应变措施。这是今天竞争激烈、变化越来越快的全球化商业环境所决定的，传统的企业观受到挑战，如何灵活快速适应变化甚至是创新求变，成为企(事)业生存和发展的头等大事。很多耳熟能详的名词和讨论都跟它有关，比如“随需应变”(On Demand)、“实时企业”(Realtime Enterprise)、“Adaptive Enterprise”、“Liquity Computing”等等。
业务敏捷性怎么跟SOA有这样密切的关系?我们需要讨论几个子问题来回答。首先，业务敏捷性要求什么?这里我们会谈到IT在其中充当什么角色。其次，为什么传统的IT不能解决问题，非要引入SOA?这里会谈到传统IT所缺，而SOA承诺提供的东西。最后，SOA如何实现它的承诺?我们会讨论SOA包括哪些主要的东西，还会谈到各种相关概念同SOA的关系，澄清一些常见的关于SOA的误解。
业务敏捷性要求些什么
业务敏捷性意味着快速决定和行动，这受很多因素的影响。比如掌握的信息不够、分析论证还不充分、组织条块分割和政治气候的改变等等，但其中最复杂难办的莫过于协调和优化依赖于一大群人和一大堆信息系统来完成的各种业务活动。如果这群人各自行动，而这些计算机系统相互隔离，不能协同工作，整体上就会处于一种混乱的状态，很难达成“业务敏捷性”。当业务面临挑战，如果能够通过调整人员的活动来应对，通常业务管理阶层能够果断决策，建立新计划，改变人员的职责，快速行动。但是，当这些变化需要信息系统来配合，业务管理阶层往往无能为力，无法快速行动，一方面信息系统是由IT部门负责的，另外一方面IT系统的相应改动所需要的时间、所花费的人力物力常常超出业务方的期望值，要么时机已逝，要么得不偿失。这往往造成我们经常观察到的业务与IT之间的冲突现象：业务方作为利润中心，总是抱怨IT每年都要花很多钱，投资回报不好，也不能帮助建立战略性的竞争优势。当企业面对变化，难以快速应变，更不要说帮助业务方创新来改变业务模式，主导竞争格局。而IT方作为成本中心，往往怨恨自己没有得到应有的重视，资金不够、加班加点，可是业务人员却不懂得如何珍惜和利用IT来的快速应变，甚至是创新求变，从而进一步主导市场。
这里牵涉到业务和IT之间的关系，这需要从几个层面上来看。首先，业务活动是由业务人员和信息系统共同完成的，业务人员执行人工活动，比如拜访客户、输入订单和客户资料、做出商务决策等等，而信息系统执行各种自动化活动，包括商业逻辑、业务规则、管理业务数据，提供界面连接人员和信息系统。所以IT是业务的一个重要组成部分。其次，业务方决定人工活动和自动化活动的需求，管理人工活动，但是他们往往不具备必要的技术能力来建立、维护和运营那些支持自动化活动的信息系统，这些工作被委托给自己的IT部门，和(或)外包。所以我们说，IT要服务于企业战略，为业务建立竞争优势，帮助业务快速应变和创新求变。
通过这些讨论我们了解到，业务敏捷性首先需要的是一个灵活的业务模式(Business Model)，业务自身不灵活，想改变却心有余而力不足，IT 再能干也是干着急。其次，需要IT的敏捷性，也就是说一个当业务改变的时候，那些自动化活动说变就变，随业务的变化而变化，花的时间少，花的人力物力也少。这种IT的灵活性，对IT的所有方面都提出了挑战，从架构、方法论、技术、产品，到过程、成熟度和管控。最后，还需要这对“冤家”之间的有效沟通与亲密合作。这很不容易，业务与IT来自两个不同的世界，看世界的方式不同，所使用的“语言”也不同。大多数时候，业务不愿意花足够的时间在 IT 上，反过来，IT也不愿意花足够的时间去理解业务。他们把更多的心思放在技术上，有时候甚至为技术而技术，忘了IT是为业务和战略服务的。
所以业务敏捷性在挑战业务和IT两者，他们还需要更好的协作和对齐(Business – IT alignment)。
从传统的 IT 向支持业务敏捷性的 IT 演进
《程序员》杂志的编辑朋友，特别提醒我谈谈为什么传统的IT不能支持业务敏捷性。这个问题提得很好，要从几个方面来讨论。
首先，传统的做法缺乏一个方法让业务和IT真正地“亲密接触”，有效地沟通、协作，让IT很好地服务业务，而IT和业务又很好地跟企业战略对齐。这里牵涉到一个重要的概念和实践，那就是企业架构(Enterprise Architecture)。互联网大百科(Wikipedia)的解释如下：
Enterprise Architecture is the practice of applying a comprehensive and rigorous method for describing a current and/or future structure and behavior for an organization's processes, information systems, personnel and organizational sub-units, so that they align with the organization's core goals and strategic direction.
这段话的意思大致可以理解成这样：
企业架构是这样一种实践，它采用周密的方法来描述一个企(事)业现在和/或未来的流程、信息系统、人员、组织，以使得它们跟这个企(事)业的核心目标和战略方向对齐。
这个定义没有明确提到架构管控(Architecture Governance)，它也应该是企业架构实践的一部分。企业架构跟信息系统紧密相关，但它同时也跟业务的各种实践，如业务绩效管理(Business Performance Management)紧密相关。企业架构包含的东西比较多，横跨业务和 IT，包括若干子架构：业务架构(Business Architecture)，IT架构(Application Architecture、Information Architecture、、Integration Architecture、Security Architecture、Infrastructure Architecture、Operation Architecture)和架构管控(Architecture Governance)。业务架构描述业务世界，从业务领域、业务组件、业务对象，到业务服务、业务流程、业务规则等等。IT架构描述IT世界，从应用、数据、集成、安全、基础设施(包括服务器、存储、网络)，到IT运营，全面覆盖，即概念性地讨论各种架构设计原则和目标，也清晰地描述和追踪各种架构的现状，同时还定义技术、产品和提供商的选择依据，要遵循的标准等等。架构管控定义了从角色、活动、职责，到协作、审批和监管的框架，保证有一个游戏规则来让这些东西真正地服务于企业的战略和目标。这种实践很有用，但还不大普遍。在SOA实践中，通常会考虑企业架构实践，通过建立企业自己的“竞争力中心”(Center of Excellence，CoE)来将企业中的各方组织在一起，有来自IT和各业务战线的高管组成的团队，他们看方向，做高层决策和把关，也有由架构师和业务经理等构成的团队，他们负责更细节的层面，确保业务驱动的技术战略和设计决策。
其次，传统的做法需要加强业务建模。有些企业，在业务优化和创新的各种实践中，逐渐建立起了业务流程模型。但是大多数企业对自己的业务模型仍停留在自发状态，缺乏业务方面的严谨企业架构实践。这种缺乏，带来几个问题：一是业务优化、应变和创新缺乏形式化的基础，缺乏数字化的基础，很容易靠感觉办事。这种“拍脑袋”应变策略，往往带来很多问题，有些时候，这些问题的原因被强加到IT的头上。二是业务和IT之间缺乏“可追溯性”(Tracability)，在将业务的需求映射到IT的时候，使用模糊的自然语言，在操作的细粒度上交流(用例，use case)，这种模糊性带来了翻译后的失真和变形。同时，细粒度的操作层次所定义的需求，受到变化的冲击大而快，应该在业务流程相关的更粗粒度、更稳定的层次上进行。这些问题最终会导致业务和IT在进行需求映射，尤其是在需求发生变化时，很难或者无法保证好的可追溯性，从而导致业务的需求无法准确地映射到IT，业务需求的变化很难被快速地定位到IT受它影响的地方，反之亦然。所以我们说，在传统实践中，业务建模这一环需要加强。没有好的业务建模和业务架构实践，业务敏捷性难以保证。
最后，传统模式需要引入新的IT架构范式和抽象层次。企业的业务活动/流程需要多个系统相互协作来支持，这些系统包括企业自己的，也可能来自合作伙伴和客户，甚至是互联网。如何集成它们?如何在集成的基础上，重用已有系统的能力和数据，协调它们来增值，也就是响应业务的新需求?如何让这种集成和增值发生得多快好省，说变就变?
首先，增加了一个新的抽象层次，就是“业务层次上的契约”，用来描述不同的业务组件(或者业务对象)之间交互的接口。在SOA环境下，也就是通常所说的“服务”，包括功能接口、服务质量约定(Service Level Agreement)和业务策略等。它们是用于组件化地对业务建模，通常其粒度比技术层次上的对象或者组件接口要粗，而业务流程就是通过将这些服务编排在一起得到的。当业务流程发生变化时，有些变化通过改变服务的配置(如业务策略)来完成，有些变化通过重新组装已有服务来完成，有些变化要用到现有服务之外的业务功能，则需要外购或者开发少量新服务，然后重新组装。
业务组件化建模所得到的服务模型，解耦了业务架构和IT架构，提供了业务架构和IT架构之间良好的映射能力和变化的可追溯性，即在服务定义不变的情况下，业务和IT可以独立地演变，带来很好的灵活性。这种粗粒度的服务契约，将分解为人工活动和自动化活动，并进一步递次分解、影射到IT世界的组件和接口。所以SOA跟OO、CBD等过去的技术是包容和利用的关系，而不是取代的关系。
过去，服务和业务流程表现为一行行代码，隐于其中;新的抽象层次将服务和流程显式化，通过基于标准的声明式方式，来形式化地描述业务模型。这不仅仅为业务和IT的沟通奠定了一个好的基础，也为企业架构实践提供了一个好的基础;解耦业务和IT得到的灵活性，还为业务优化、应变和创新带来形式化、数量化、可模拟的基础。如“业务绩效管理”(Business Performance Management)以及“业务活动监控”(Business Activity Monitoring)。这里的重点是标准化，业务模型元素的显式化声明以及业务和IT的解耦与变化时的可追溯性。另外，一个很重要的事情是建立高质量的业务模型，它确保服务的稳定性、可组装能力、安全、服务质量、策略的保证、同企业目标和战略的对齐，而这些牵涉到管控问题，也就是“SOA Governance”。
这个抽象层次需要具体技术实现形式的支持，它需要最大程度的标准化和接受程度来跨越异构技术环境的边界，有赖于互联网的发展和普遍接受。Web服务成为理想选择，因为它能够真正地做到“平台无关”。过去，CORBA 等技术拥有类似的设计原则，但无法真正地做到异构兼容，从而失败。
这个新的抽象层次，同时带来了方法论上的改变。在SOA中，当我们启动一个项目，我们将首先从业务建模入手，通过对业务进行分析，来得到服务模型、流程定义等。通常，采用领域模型分析方法，对业务组件化，标识服务，定义服务的描述细节，检测服务是否符合业务人员的期望值，是否服务于企业的战略和目标。经过这个业务层次的建模过程之后，我们转向技术层次，也就是服务和流程的实现。如果我们没有什么遗留系统，一切是从头开始的一个应用，事情将很简单，我们会采用已有的方法论和技术来设计这些服务。比如一种可能的做法是，我们为每个服务建立它的用例，通过分析所有服务的用例，进入子系统和组件设计，然后是类和对象级别的分析与设计。但如果我们已经有了很多应用，这个时候，就可能需要多做一些事情。如果一个系统包含了业务建模中出现的某个(些)服务所需要的功能或者数据，我们怎么办?当然不能扔掉或者视而不见，我们需要重用它们，也就是要集成它们，所以我们开始面临一个企业整合的问题(应用、数据、安全等)。这就引出了集成架构的问题，请看下面关于集成架构的讨论。
一个新的集成架构负责将遗留系统和(或)新建的系统连通起来，让不同技术世界的服务组件可以相互以Web服务接口为中介来松散耦合地交互，这牵涉到各种协议、API、消息格式的转换、服务端点的发现和绑定、消息的路由、服务质量的保证、服务策略的实施等等。SOA继承了过去EAI (Enterprise Application Integration)和MOM(Message Oriented Middleware)的最佳实践，比如“企业服务总线”(Enterprise Service Bus，ESB)作为一种架构风格元素，用于在分布式环境下提供松散耦合的集成基础，但是SOA使用了Web服务，建立在标准和开放技术的基础上，而不是私有的技术、标准和方式。新的集成架构还引入Service Registry，ESB与之合作提供服务的动态发现和绑定。ESB的实现通常会利用已有的消息中间件。
另外，在SOA的实践中，通常会创建一个数据服务层。而这通常会集成EII(Enterprise Information Integration)的技术和最佳实践，不过也会建立在Web服务等标准和开放技术的基础上。
这个集成架构，要确保所有服务和应用在开发之时，能够跟其他的应用和服务，不管它们今天是否存在，互联互通、相互集成，也就是“开发即集成”。
我们这里继续前面关于方法论的讨论。由于SOA架构范式提供了ESB这样一种架构元素来支持一个基于服务的分布式集成架构，我们需要以这个它为基础来设计一些集成用的IT组件，来将我们需要重用的数据和能力从已有的系统中“引”出来，你可以采用任何你所熟悉的技术和方式，不过大多数情况下存在标准的做法，也就是Connector和Adapter。值得提醒的是，这里有一个很重要的设计原则就是ESB是基于“服务”的分布式集成，我观察到很多基于“细粒度”的接口和消息集成，这是不符合SOA的设计原则的，也将导致可能的性能问题。实现时，通过购买支持ESB和Service Registry的产品，奠定基于服务集成的架构基础，然后，购买或者开发自己的Connector/Adapter来将各种应用连通起来，将功能和处理能力引出来。到此为止，我们有了：(1)业务建模而来的服务模型(2)对需要从头实现的服务，我们有了IT层次上的子系统、组件和对象模型(注意：这是一种可能的IT模型而已)(3)对于那些要重用已有系统功能或者数据的服务，我们有了Connector/Adapter来将需要的能力引出，如果它们并非恰好是我们所需要的，我们还需要进行IT组件的设计，这跟从头实现新服务是类似的(4)有了将分布的系统联通起来，基于服务来整合的集成架构。所以，我们需要开始转向实现。这就引出了应用平台的问题。
而在应用架构方面，新的SOA技术和标准，比如SCA/SDO允许你采用平台和语言相关的方式实现，但是组件实现的服务接口则是标准化的。复合应用(Composite Application)建立在其他应用的基础上，通过将来自Portal应用的人工活动、B2B的合作伙伴应用、数据服务和本地业务服务来快速形成新应用。基于BPEL等标准的流程引擎，使用“声明式”的方式来将服务编排在一起，在复合应用中起着重要的作用。这些都是在已有的应用平台上增加而来，比如IBM的WebSphere Process Server支持SCA/SDO和BPEL，它是在IBM的J2EE服务器WebSphere Application Server的基础上实现的。
我们前面所设计的服务，实现它们的IT组件就表现为一些SCA组件，或者EJB、POJO组件，而业务流程则在IT层次上实现为BPEL或者一些SCA组件。这些服务和流程都有自己基于标准的形式化描述，保存在服务注册库(Service Registry)中。
最后，SOA Governance被用来在整个服务的生命中期中，将来自业务和IT的人协调起来，让他们各司其职，有规可循，相互协作来分析和定义服务，创建、组装和部署服务，运行和管理服务，监控和优化服务等。
在实现层面，这通常需要借助于Service Registry来管理服务的生命周期，同时，我们需要扩展现有的管理产品，从基础设施、应用和组件的管理，延伸到服务、流程和业务活动和业务绩效的管理。在这个基础上，建立数字化的服务和流程优化策略，从而使得IT可以主动地向业务提供业务优化和调整的支持。
SOA小结和概念澄清
谈到这里，相信读者对SOA的目的和它相关的一些概念更清楚了，简单总结一下。业务敏捷性需要一个灵活的业务模型，这需要一个灵活的IT来支持。同时，良好的业务建模，IT与业务之间的对齐和互动变得很重要，所以基于企业架构的实践，横贯业务和技术的SOA管控被用来保证SOA转型的成功。一个灵活的IT需要遵循必要的设计原则，比如关注点分离、松散耦合，而这些设计原则结合具体技术形式体现在IT架构中，将会形成自己的架构风格，这当然也由一些架构元素支撑，比如ESB，服务注册库等。这些架构元素多多少少都能够从过去的IT当中找到些影子，但是，它们使用新技术，建构在开放标准和技术的基础上，融合和继承了过去的实践成果。
下面简单地谈谈一些常见的误解。
SOA = ESB
ESB只是SOA架构中的一个元素，负责转换、路由和服务质量等。看待SOA，应该从业务、技术、管控等不同的角度来看待。
SOA = Web Service
Web Service通常指基于SOAP/HTTP的Web服务，这些服务是实现SOA中所定义服务的一种技术形式。Web Service提供了分布式环境下卓越的互操作能力。
我的系统都是新系统，SOA没有用武之地
答案应该是“有”，如果你希望得到业务敏捷性的话。SOA通过更好地让IT和业务融合在一起，借助于企业架构、业务建模、SOA监管和一些新的设计原则，架构风格，支持这些原则和风格的最新技术来达成IT的灵活性，以支持业务敏捷性。
SOA与BPM是一回事
BPM与SOA关系紧密，但并非一件事。BPM 的目的是业务优化，这种优化需要IT的支持，SOA提供很好的支持。另外，BPM在业务建模和业务规则方面为SOA提供很好的支持，为SOA达成业务敏捷性带来良好的基础。
SOA对您意味着什么
SOA作为IT的一个大的变化，业务驱动的价值诉求，非常清晰。通过总结和继承过去IT实践的成败得失，SOA将其首要目标定位为业务敏捷性，即通过建设一个灵活的IT来帮助业务快速应变，引领创新。
所以SOA对业务人员、管理阶层是一个值得注意并且很有吸引力的事，但如何获得?这需要业务和IT共舞，也需要认真建立业务模型，实践企业架构，这种转变是文化上的，对于企业来说，开始之时，并不容易。
对IT主管而言，SOA是一个好机会。建立IT的战略地位，通过IT帮助企业建立战略性竞争优势是IT人员马上就可以去做的，但是如何实践企业架构，如何建立SOA管控，如何通过SOA Center of Excellence来组织人员，培养种子力量将是IT主管要面临的挑战。
对于架构师，需要了解SOA的设计原则、架构风格、架构元素和相关技术和产品。他们需要配合IT主管，推动企业架构实践和SOA管控，跟业务人员共同合作，推动SOA项目。
对于开发人员，学习和使用SOA，是趋势使然，即需要学习新技术，也需要增加一点架构的意识，还需要培养自己的业务建模能力。
SOA对ISV可能意味着一个好机会，就是如何将自己对一个行业的理解转化为一个比较通用的业务模型和服务模型，通过可重用的软件资产，建立面向行业的解决方案模板与复合应用。当然，他们也可以进一步通过 SaaS (Software as a Service)来提供服务和复合应用，从而拓展业务流程外包的机会。
SOA是一个很大的题目，这里挂一漏万，如果需要系统性地了解SOA，我推荐IBM developerWorks的架构专区和SOA/Web Service专区，非常详尽和系统，而且很多人来自IBM之外。
参考文献
http://www-306.ibm.com/software/solutions/soa/
http://www-306.ibm.com/software/sw-bycategory/subcategory/SW920.html
http://www.ibmpressbooks.com/soa_specialoffer
http://www-128.ibm.com/developerworks/webservices
http://www-128.ibm.com/developerworks/architecture/library/ar-eaoverview/
http://www-128.ibm.com/developerworks/architecture/library/ar-baoverview/index.html
http://www-128.ibm.com/developerworks/architecture/library/ar-iaoverview/
http://www.proxyhub.co.uk/index.php?q=uggc%3A%2F%2Fra.jvxvcrqvn.bet%2Fjvxv%2FVG_Nepuvgrpgher_Pbasreraprf
http://www.proxyhub.co.uk/index.php?hl=0011110001&q=uggc%3A%2F%2Fra.jvxvcrqvn.bet%2Fjvxv%2FRagrecevfr_nepuvgrpgher
Enterprise Application Integration, William A. Ruh
Enterprise Interation, Beth Gold-Bernstein, William Ruh, ISBN 0-321-22390-X
Next Generation Application Integration, David S. Linthicum, ISBN 0-201-84456-7
Achieving Agility: BPM Delivers Business Agility Through New Management Practices 11 April 2006 Janelle B. Hill Michael James Melenovsky
Achieving Business Agility with SOA: Governance & SLA Management of Shared Service Ecosystems，Annie W. Shum & Jeffrey P. Buzen
Jean Faget, W4, France; Mike Marin, FileNET, USA; Patrick Mégard, ILOG, France; Vincent J. Owens, Cap Gemini Ernst & Young, United Kingdom; Laurent Tarin, ILOG, France, Business Processes and Business Rules: Business Agility Becomes Real