SOA是一种思想？一种软件产品？还是一种软件服务？尽管越来越流行的SOA已经充斥到几乎所有的IT经理脑中，但SOA究竟是什么？仍然让人迷茫。面向服务的IT架构到底在业务与IT两个世界中扮演了怎样的角色？你眼中的SOA到底是什么？

　　在今天，竞争激烈、变化越来越快的全球化商业环境中，传统企业观受到严重挑战，如何灵活快速适应变化、创新求变，成为企业生存和发展的头等大事。在业务敏捷性的实践中，SOA正成长为IT促进业务提高的转移范式，从设计原则、架构范式以及技术、标准和产品中实践着它面向服务架构的伟大使命。

　　业务敏捷性向业务与IT两个世界发起挑战

　　事实上，许多企业都无法实现“业务敏捷”。他们的工作人员各自行动，计算机系统又相互隔离，不能协同工作：一方面是由IT部门负责的信息系统，另外一方面则是调整IT系统所需要必要时间和成本。受这二者的制约，企业变化要么时机已逝，要么得不偿失。因此，业务方作为利润中心，总是抱怨IT每年都要花很多钱，不仅不能获得良好的投资回报，也不能帮助建立战略性的竞争优势。而IT方作为成本中心，往往怨恨自己没有得到应有的重视，资金不够、加班加点。这种现象的出现也就不足为奇。

　　到底应如何看待IT与业务之间的关系？

　　首先，业务活动是由业务人员和信息系统共同完成的，业务人员执行人工活动，比如拜访客户、输入订单和客户资料、做出商务决策等等，而信息系统执行各种自动化活动，包括商业逻辑、业务规则、管理业务数据，提供界面连接人员和信息系统。所以IT是业务的一个重要组成部分。

　　其次，业务方决定人工活动和自动化活动的需求，管理人工活动，但是他们往往不具备必要的技术能力来建立、维护和运营那些支持自动化活动的信息系统，这些工作被委托给自己的IT部门或者外包。所以IT要服务于企业战略，为业务建立竞争优势，帮助业务快速应变和创新求变。

　　可见，业务敏捷性首先需要的是一个灵活的业务模式（Business Model），业务自身不灵活，想改变却心有余而力不足，IT再能干也是干着急。其次，需要IT的敏捷性，也就是说一个当业务改变的时候，那些自动化活动说变就变，随业务的变化而变化，花的时间少，花的人力物力也少。这种IT的灵活性，对IT的所有方面都提出了挑战，从架构、方法论、技术、产品，到过程、成熟度和管控。最后，还需要IT与业务这对“冤家”之间的有效沟通与亲密合作。

　　这很不容易，业务与IT来自两个不同的世界，看世界的方式不同，所使用的“语言”也不同。大多数时候，业务不愿意花足够的时间在IT上，反过来，IT也不愿意花足够的时间去理解业务。他们把更多的心思放在技术上，有时候甚至为技术而技术，忘了IT是为业务和战略服务的。 因此，业务敏捷性同时向业务和IT两个世界发起挑战，沟通和协调成为必然。

　　SOA畅行业务与IT两个世界业务架构描述业务世界：从业务领域、业务组件、业务对象，到业务服务、业务流程、业务规则……IT架构描述IT世界：从应用、数据、集成、安全、基础设施（包括服务器、存储、网络），到IT运营，全面覆盖……两个“世界”共同服务于企业，而如何实现两个世界协作则成为企业战略目标实现的关键！

　　SOA正是沟通两个“世界”使命的承担者，它提出了架构管控的概念，从角色、活动、职责，到协作、审批和监管的框架，保证有一个游戏规则来让这些东西真正地服务于企业的战略和目标。

　　然而，大多数企业对自己的业务模型仍停留在自发状态，缺乏业务方面的严谨企业架构实践，更谈不上业务与IT的沟通，这直接带来两个问题：

　　一是业务优化、应变和创新缺乏形式化和数字化的基础，很容易靠感觉办事。这种“拍脑袋”应变策略，往往带来很多问题，有些时候，这些问题的原因被强加到IT的头上，而使IT承担了不应承担的责任。

　　二是业务和IT之间缺乏“可追溯性”（Tracability）。在将业务的需求映射到IT的时候，使用模糊的自然语言，容易造成翻译后的失真和变形。同时，细粒度的操作层次所定义的需求，受到变化的冲击大而快。这最终导致业务和IT在进行需求映射，尤其是在需求发生变化时，很难保证好的可追溯性，从而导致业务的需求无法准确地映射到IT，业务需求的变化很难被快速地定位到IT。

　　传统模式需要引入新的IT架构范式和抽象层次，从而为企业的业务活动和流程提供多系统相互协作的IT支持，SOA则恰好扮演了这个角色。

　　SOA为业务与IT两个世界带来什么？

　　SOA究竟在实现业务和IT两个世界的沟通中体现了怎样的价值？笔者认为：

　　① SOA在业务与IT之间增加了一个新的抽象层次，就是“业务层次上的契约”，用来描述不同的业务组件（或者业务对象）之间交互的接口。这就是SOA通常所说的“服务”。

　　其中包括功能接口、服务质量约定（Service Level Agreement）和业务策略等。它们是用于组件化地对业务建模，通常其粒度比技术层次上的对象或者组件接口要粗，而业务流程就是通过将这些服务编排在一起得到的。当业务流程发生变化时，有些变化通过改变服务的配置（如业务策略）来完成，有些变化通过重新组装已有服务来完成，有些变化要用到现有服务之外的业务功能，则需要外购或者开发少量新服务，然后重新组装。

　　业务组件化建模所得到的服务模型，解耦了业务架构和IT架构，提供了业务架构和IT架构之间良好的映射能力和变化的可追溯性，即在服务定义不变的情况下，业务和IT可以独立地演变，带来很好的灵活性。

　　② 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）的技术和最佳实践。

　　这个集成架构，要确保所有服务和应用在开发之时，能够跟其他的应用和服务集成，不管它们今天是否存在，互联互通、相互集成、“开发即集成”是SOA对技术层面的基本要求。

　　值得提醒的是，SOA一个很重要的设计原则ESB是基于“服务”的分布式集成，很多基于“细粒度”的接口和消息集成，并不符合SOA的设计原则，也将导致可能的性能问题。

　　④ 在应用架构方面，新的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实践的成败得失，SOA将其首要目标定位为业务敏捷性，即通过建设一个灵活的IT来帮助业务快速应变，引领创新。因此SOA对业务人员、管理阶层是一个值得注意并且很有吸引力的事，但SOA对不同角色的人意义也自然不同。

　　① 对于IT主管

　　SOA是一个好机会，建立IT的战略地位，通过IT帮助企业建立战略性竞争优势是IT人员马上就可以去做的，但是如何实践企业架构，如何建立SOA管控，如何通过SOA Center of Excellence来组织人员，培养种子力量将是IT主管要面临的挑战。

　　② 对于架构师

　　需要了解SOA的设计原则、架构风格、架构元素和相关技术和产品。他们需要配合IT主管，推动企业架构实践和SOA管控，跟业务人员共同合作，推动SOA项目。

　　③ 对于开发人员

　　学习和使用SOA，是趋势使然，即需要学习新技术，也需要增加一点架构的意识，还需要培养自己的业务建模能力。

　　④ 对于ISV

　　SOA可能意味着一个好机会，就是如何将自己对一个行业的理解转化为一个比较通用的业务模型和服务模型，通过可重用的软件资产，建立面向行业的解决方案模板与复合应用。