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

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

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

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

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

　　2、SOA建立了一个新的集成架构，负责将遗留系统和新建的系统连通起来，让不同技术世界的服务组件可以相互以Web服务接口为中介来松散耦合地交互。

　　这牵涉到各种协议、API、消息格式的转换、服务端点的发现和绑定、消息的路由、服务质量的保证、服务策略的实施等等。SOA继承了过去EAI（Enterprise Application Integration）和MOM（Message Oriented middleware）的最佳实践，比如“企业服务总线”（Enterprise Service Bus，ESB）作为一种架构风格元素，用于在分布式环境下提供松散耦合的集成基础，但是SOA使用了Web服务，建立在标准和开放技术的基础上，而不是私有的技术、标准和方式。新的集成架构还引入Service Registry，ESB与之合作提供服务的动态发现和绑定。ESB的实现通常会利用已有的消息中间件。

　　3、SOA通常会创建一个数据服务层，集成EII（Enterprise Information Integration）的技术和最佳实践。

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

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

　　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）中。

　　5、SOA Governance被用来在整个服务的生命中期中，将来自业务和IT的人协调起来，让他们各司其职，有章可循，相互协作。

　　在实现层面，这通常需要借助于Service Registry来管理服务的生命周期，同时，我们需要扩展现有的管理产品，从基础设施、应用和组件的管理，延伸到服务、流程和业务活动和业务绩效的管理。在这个基础上，建立数字化的服务和流程优化策略，从而使得IT可以主动地向业务提供业务优化和调整的支持。