在这篇文章里，我们略过SOA的一些基础性介绍，主要关注SOA的应用场景。

SOA有哪些基本原则？

了解SOA是为了解决什么样的问题，我们先来了解一下SOA有哪些基本原则。

粗粒度

在SOA中服务粒度有两种相关的意思，即服务是如何实现的，服务使用和返回了多少数据或多少消息。细粒度服务执行了最小的功能，发送和接收少量的数据。粗粒度服务执行了较大的业务功能，并交换了更多的数据。

原则：细粒度服务是供粗粒度服务或组合服务使用的，而不是由终端应用直接使用的。如果应用是使用细粒度服务建立的，则应用将不得不调用网络上多个服务，并且发生在每个服务上的数据量较少，因而会对对系统整体性带来影响。所以，粗粒度服务的用户不能直接调用他所使用的细粒度服务。同时，由于粗粒度服务可能使用多个细粒度服务，因此它们不能提供粒度级的安全和访问控制。

松散耦合

松耦合的系统特点是灵活，而应用到SOA中的目的就是将服务使用者和服务提供者在服务实现和客户如何使用服务方面隔离开来。服务提供者和服务使用者间松散耦合背后的关键点是服务接口作为与服务实现分离的实体而存在。这是服务实现能够在完全不影响服务使用者的情况下进行修改。

大多数松散耦合方法都依靠基于服务接口的消息。基于消息的接口能够兼容多种传输方式（如HTTP、JMS、TCP/IP、MOM等）。基于消息的接口可以采用同步和异步协议实现。

可重用部件/服务

如果完全按照可重用的原则设计服务，SOA将可以使应用变得更为灵活。可重用服务采用通用格式提供重要的业务功能，为开发人员节约了大量时间。

设计可重用服务应该是与数据库设计或通用数据建模类似的最有价值的工作。

基于标准

Web Service是目前实现SOA应用的一项基本的，适用的技术，它为服务的访问提供了一个被广泛接受的开放标准。

JBI（JSR208）是SUN推出的基于Java的SOA标准，随着在JSR 208中被定义，它也成为了把服务容器组装为合成应用的标准。

Service Component Architecture (SCA)和Service Data Objects (SDOs)标准是IBM和BEA所推出的SOA标准，并在Apache Group建立了Apache Tuscany项目。

在我看来，标准之争并不是关键所在，但就JBI和SCA/SDO标准而言，JBI的应用范围更严格，可能最终会成为更大的标准中的一部分Java实现。

SOA面临什么样的问题？

﹡繁杂的应用和协议
　﹡繁变化的服务需求
　﹡管理
　﹡监控
　﹡网络瓶颈
　﹡标准的缺失
　﹡困难的跨团队变更管理
　﹡这些问题都比较好理解，也不是只有采用SOA才能解决问题的。但是作为典型的SOA应用，以上的情况都是必须面对的，也是SOA系统函待解决的。

SOA的应用场景是怎样的？

﹡适用场景
　﹡集成成本持续增长，而并未因为可提供真正投资回报 (ROI) 的新业务机会而得到缓解。
　﹡兼并和收购是企业扩大市场份额和获得新发展机会的业务模式的核心。
　﹡解决方案要求对来自异构系统和编程模型的业务功能进行集成。
　﹡业务的生存依赖于根据市场变化快速调整或即时响应竞争威胁的能力。
　﹡全球经济的影响要求企业事半功倍地开展业务，而且有必要依赖业务合作伙伴提供非核心业务功能。
　﹡就提高收益而言，与业务合作伙伴协作的效率对企业十分关键。
　﹡企业业务资产的价值在减少，因为不能对其进行评估，以在最初用途之外的其他地方使用。
　﹡企业员工的效率出现了问题，因为他们的大部分时间并没有花在提供公司业务模型的核心功能和服务上。
　﹡企业的业务充满了机会型的业务工作。
　﹡企业从头开始开发新应用程序。（SOA应当作为定位将来的新应用程序的缺省架构模式，当然，业务条件有其他限制时除外。）

不适用场景

﹡企业只将小部分 IT 预算用于集成项目。
　﹡企业的大部分流程都是手动的或以文档为中心的，自动化的机会几乎为零。
　﹡企业的大部分应用程序开发都使用相同的编程模型。
　﹡企业的操作由一个或两个客户关系管理 (CRM) 和企业资源规划 (ERP) 应用程序管理，几乎没有集成要求。
　﹡企业的现有技能库与实现支持 SOA 的基础结构所需的技能库之间存在重大差异。
　﹡未发现可从 SOA 提供的功能受益的业务需求或机会。
　﹡新业务服务的可用性将对现有的收益流带来负面影响。
　﹡企业依赖的业务合作伙伴对公司间流程的自动化采用了不同的优先级。
　﹡企业的主要业务的开展涉及到海量且同步性和实时性要求非常高的事务。