摘要：面向服务的架构（SOA）是一个组件模型，它将应用程序的不同功能单元（称为服务）进行拆分，并通过这些服务之间定义良好的接口和协议联系起来。通俗来说就是进行业务功能划分，之后再按照相应的准则进行相互之间调用，SOA旨在将单个的应用程序彼此分开，以便这些功能可以单独用作单个的应用程序功能，从而降低代码的复杂度。SOA所使用的技术标准有WSDL、UUDI、SOAP，使用SOA可以降低用户成本，使程序间关系服务简单，识别程序问题等。本文主要介绍了SOA的简介，SOA执行标准，SOA设计原则，及使用SOA的好处，以及自己对SOA的个人见解。
1.SOA简介
面向服务的架构（SOA）是一个组件模型，它将应用程序的不同功能单元（称为服务）进行拆分，并通过这些服务之间定义良好的接口和协议联系起来。接口是采用中立的方式进行定义的，它应该独立于实现服务的硬件平台、操作系统和编程语言。这使得构件在各种各样的系统中的服务可以以一种统一和通用的方式进行交互。SOA旨在将单个应用程序功能彼此分开，以便这些功能可以单独用作单个的应用程序功能或“组件”。这些组件可以用于在企业内部创建各种其他的应用程序，或者如有需要，对外向合作伙伴公开，以便用于合作伙伴的应用程序。
2.SOA执行标准
SOA 伴随着无处不在的标准，为企业的现有资产或投资带来了更好的复用性。SOA 能够在最新的和现有的系统之上创建应用，借助现有的应用产生新的服务，为企业提供更好的灵活性来构建系统和业务流程。SOA 是一种全新的架构，为了支持其各种特性，相关的技术规范不断推出。与 SOA 紧密相关的主要技术标准有WSDL、UUDI、SOAP等：
SOAP: 简单对象访问协议 (Simple Object Access Protocol)
简单对象访问协议是在分散或分布式的环境中交换信息的简单的协议，是一个基于XML的协议，它包括四个部分：SOAP封装(envelop)，封装定义了一个描述消息中的内容是什么，是谁发送的，谁应当接受并处理它以及如何处理它们的框架；SOAP编码规则（encoding rules），用于表示应用程序需要使用的数据类型的实例; SOAP RPC表示(RPC representation)，表示远程过程调用和应答的协定;SOAP绑定（binding），使用底层协议交换信息。
WSDL: Web服务描述语言 WSDL (Web Services Description Language)
WSDL是一个用于精确描述Web服务的文档，WSDL文档是一个遵循WSDL XML模式的XML文档。WSDL 文档将Web服务定义为服务访问点或端口的集合。在 WSDL 中，由于服务访问点和消息的抽象定义已从具体的服务部署或数据格式绑定中分离出来，因此可以对抽象定义进行再次使用：消息，指对交换数据的抽象描述；而端口类型，指操作的抽象集合。用于特定端口类型的具体协议和数据格式规范构成了可以再次使用的绑定。将Web访问地址与可再次使用的绑定相关联，可以定义一个端口，而端口的集合则定义为服务。
UUDI: 统一描述、发现和集成 (Universal Description, Discovery and Integration)
UDDI 是一种目录服务，企业可以使用它对 Web services 进行注册和搜索。UDDI实现了一组可公开访问的接 口，通过这些接口， 网络服务可以向服务信息库注册其服务信息、服务需求者可以找到分散在世界各地的网络服务。 程序开发人员通过UDDI机制查找分布在互联网上的 Web Service，在获取其WSDL文件后，就可以在自己的程序中以SOAP调用的格式请求相应的服务了。 UDDI 的目的是为电子商务建立标准；UDDI是一套基于Web的、分布式的、为Web Service提供的、信息注册中心的实现标准规范，同时也包含一组使企业能将自身提供的Web Service注册，以使别的企业能够发现的访问协议的实现标准。
WSDL用来描述服务；UDDI用来注册和查找服务；而SOAP，作为传输层，用来在消费者和服务提供者之间传送消息。一个消费者可以在UDDI注册表（registry）查找服务，取得服务的WSDL描述，然后通过SOAP来调用服务。
3. SOA设计原则
在 SOA 架构中，继承了来自对象和构件设计的各种原则，例如，封装和自我包含等。那些保证服务的灵活性、松散耦合和复用能力的设计原则，对 SOA 架构来说同样是非常重要的。关于服务，一些常见的设计原则如下：
（1）明确定义的接口。服务请求者依赖于服务规约来调用服务，因此，服务定义必须长时间稳定，一旦公布，不能随意更改；服务的定义应尽可能明确，减少请求者的不适当使用；不要让请求者看到服务内部的私有数据。
（2）自包含和模块化。服务封装了那些在业务上稳定、重复出现的活动和构件，实现服务的功能实体是完全独立自主的，独立进行部署、版本控制、自我管理和恢复。
（3）粗粒度。服务数量不应该太多，依靠消息交互而不是远程过程调用，通常消息量比较大，但是服务之间的交互频度较低。
（4）松耦合。服务请求者可见的是服务的接口，其位置、实现技术、当前状态和私有数据等，对服务请求者而言是不可见的。
（5）互操作性、兼容和策略声明。为了确保服务规约的全面和明确，策略成为一个越来越重要的方面。这可以是技术相关的内容，例如，一个服务对安全性方面的要求；也可以是与业务有关的语义方面的内容，例如，需要满足的费用或者服务级别方面的要求，这些策略对于服务在交互时是非常重要的。
4. SOA的好处
使用SOA能够将系统进行业务划分，通过相互调用，降低用户成本，用户不需要关心各服务之间是什么语言的、不需要知道如果调用他们，只要通过统一标准找数据总线就可以了。使程序之间关系服务更简单：
（1） 松耦合：由于服务自治，有一定封装边界，服务调用交互是通过发布接口。这意味着应用程序不感兴趣的服务如何被实现。
（2）位置透明：服务的消费者不必关系服务位于什么地方。
（3）可在异构平台间复用。可以将遗留系统包装成服务。
（4）便于测试，能并行开发，较高可靠性和良好可伸缩性。
5.SOA现存问题
SOA体系架构在项目中经常会出现一些问题，例如数据特种不统一，数据的结构、类型语义、格式等有时候存在偏差，导致无法继续进行；SOA架构的性能稍低，主要是因为SOA的分布性质和web服务协议的开销。任何分布式系统的执行速度都不如独立式系统，因为这里面有网络的制约因素；同时还有安全性问题，由于SOA架构的松散耦合性，使其不得不面临客户信息安全问题。
6.个人见解
对于SOA，查到的各种解释都非常抽象，我自己对SOA的理解为：把一个整体系统按照业务功能划分，拆分成独立的合适的模块。从而方便其他模块进行相互调用，降低代码的复杂度。服务提供者创建服务，将服务信息发布到服务目录并被分类，服务请求者将在服务目录中搜索满足必要条件的服务，找到服务后，通过使用服务目录中的可用信息，服务请求者能够以正确的方式直接联系服务提供者，从而满足业务需求。
参考资料：