论面向服务架构设计及其应用
摘 要： 面向服务架构又称“面向服务的体系结构”，是Gartner于2O世纪9O年代中期提出的面向服务架构的概念。2002年的l2月，Gartner提出“面向服务的架构(SOA)”是“现代应用开发领域最重要的课题”之后。国内外计算机专家、学者掀起了对SOA的积极研究与探索。我们现在正在享受着SOA给软件带来的好处。如计算机网络符层的服务协议象http、ftp等就是基于SOA思想的设计和开发的。各层协议问提供透明的服务和接口，使各层协议问最大程度的降底藕合性。减小外界对各层的影响，SOA是未来软件开发与设计的标准，使我们未来开发的软件也象网络的各层协议一样提供给客户完美的服务接口，减小因企业服务的改变而引起软件的改写，降低开发成本与开发人员的劳动强度。顾名思义，SOA就是以“服务”为基本元素来组建企业IT架构。在技术层面上，SOA是一种“抽象的、松散耦合的粗粒度软件架构”；在业务层面上，SOA的核心概念是“重用”和“互操作”，它将企业的IT资源整合成可操作的、基于标准的服务，使其能被重新组合和应用。面向服务架构，从语义上说，它与面向过程、面向对象、面向组件一样，是一种软件组建及开发的方式。与以往的软件开发、架构模式一样，SOA只是一种体系、一种思想，而不是某种具体的软件产品。SOA要解决的主要问题是：快速构建与应用集成。SOA能够在实际应用中获得成功基于两个重要的因素：灵活性和业务相关性。这使得它成为解决企业业务发展需求与企业IT支持能力之间矛盾的最佳方案。
关键词：服务；架构；
随着互联网技术迅速发展和演变，不断改变的商业化应用系统越来越复杂，由单一的应用架构到垂直的应用架构，但还是面临的扩容的问题。流量分散在各个系统中，虽然体积可控，但对开发人员和维护人员带来极麻烦。此时，将核心的业务单独提炼出来作为单独的系统对外提供服务。达成业务之间复用，系统也将演变成分布式系统架构。分布式架构是各组件分布在网络计算机上、组件之间仅仅通过消息传递来通信并协调行动。
1.SOA的关键技术
SOA 伴随着无处不在的标准，为企业的现有资产或投资带来了更好的复用性。SOA 能够在最新的和现有的系统之上创建应用，借助现有的应用产生新的服务，为企业提供更好的灵活性来构建系统和业务流程。SOA 是一种全新的架构，为了支持其各种特性，相关的技术规范不断推出。与 SOA 紧密相关的技术主要有 UDDI、WSDL、SOAP 和 REST 等，而这些技术都是以 XML 为基础而发展起来的。
1.1 UDDI
UDDI（Universal DescriptionDiscovery and Integration，统一描述、发现和集成）提供了一种服务发布、查找和定位的方法，是服务的信息注册规范，以便被需要该服务的用户发现和使用它。UDDI 规范描述了服务的概念，同时也定义了一种编程接口。通过 UDDI 提供的标准接口，企业可以发布自己的服务供其他企业查询和调用，也可以查询特定服务的描述信息，并动态绑定到该服务上。
在 UDDI 技术规范中，主要包含以下三个部分的内容：
（1）数据模型。UDDI 数据模型是一个用于描述业务组织和服务的 XML Schema
（2）API。UDDI API 是一组用于查找或发布 UDDI 数据的方法，UDDI API 基于 SOAP。
（3）注册服务。UDDI 注册服务是 SOA 中的一种基础设施，对应着服务注册中心的角色
1.2 WSDL
WSDL（Web ServiceDescription Language，Web 服务描述语言）是对服务进行描述的语言，它有一套基于 XML 的语法定义。WSDL 描述的重点是服务，它包含服务实现定义和服务接口定义。
采用抽象接口定义对于提高系统的扩展性很有帮助。服务接口定义就是一种抽象的、可重用的定义，行业标准组织可以使用这种抽象的定义来规定一些标准的服务类型，服务实现者可以根据这些标准定义来实现具体的服务。
服务实现定义描述了给定服务提供者如何实现特定的服务接口。服务实现定义中包含服务和端口描述。一个服务往往会包含多个服务访问入口，而每个访问入口都会使用一个端口元素来描述，端口描述的是一个服务访问入口的部署细节，例如，通过哪个地址来访问，应当使用怎样的消息调用模式来访问等。
1.3 SOAP
SOAP（Simple ObjectAccess Protocol，简单对象访问协议）定义了服务请求者和服务提供者之间的消息传输规范。SOAP 用 XML 来格式化消息，用 HTTP 来承载消息。通过 SOAP，应用程序可以在网络中进行数据交换和远程过程调用（Remote Procedure Call， RPC）。SOAP 主要包括以下四个部分：
（1）封装。SOAP 封装定义了一个整体框架，用来表示消息中包含什么内容，谁来处理这些内容，以及这些内容是可选的还是必需的。
（2）编码规则。SOAP 编码规则定义了一种序列化的机制，用于交换系统所定义的数据类型的实例。
（3）RPC 表示。SOAP RPC 表示定义了一个用来表示远程过程调用和应答的协议。
（4）绑定。SOAP 绑定定义了一个使用底层传输协议来完成在节点之间交换 SOAP 封装的约定。
SOAP 消息基本上是从发送端到接收端的单向传输，但它们常常结合起来执行类似于请求/应答的模式。所有的 SOAP 消息都使用 XML 进行编码。SOAP 消息包括以下三个部分：
（1）封装（信封）。封装的元素名是 Envelope，在表示消息的 XML 文档中，封装是顶层元素，在 SOAP 消息中必须出现。
（2）SOAP 头。SOAP 头的元素名是 Header，提供了向 SOAP 消息中添加关于这条 SOAP 消息的某些要素的机制。SOAP 定义了少量的属性用来表明这项要素是否可选以及由谁来处理。SOAP 头在 SOAP 消息中可能出现，也可能不出现。如果出现的话，必须是 SOAP 封装元素的第一个直接子元素。
（3）SOAP 体。SOAP 体的元素名是 Body，是包含消息的最终接收者想要的信息的容器。SOAP 体在 SOAP 消息中必须出现且必须是 SOAP 封装元素的直接子元素。如果有头元素，则SOAP 体必须直接跟在 SOAP 头元素之后；如果没有头元素，则 SOAP 体必须是 SOAP 封装元素的第一个直接子元素。
1.3 REST
REST（RepresentationalState Transfer，表述性状态转移）是一种只使用 HTTP 和 XML 进行基于 Web 通信的技术，可以降低开发的复杂性，提高系统的可伸缩性。它的简单性和缺少严格配置文件的特性，使它与 SOAP 很好地隔离开来，REST 从根本上来说只支持几个操作（POST、GET、PUT 和 DELETE），这些操作适用于所有的消息。REST 提出了如下一些设计概念和准则：
（1）网络上的所有事物都被抽象为资源。
（2）每个资源对应一个唯一的资源标识。
（3）通过通用的连接件接口对资源进行操作。
（4）对资源的各种操作不会改变资源标识。
（5）所有的操作都是无状态的。
2 SOA设计原则
在 SOA 架构中，继承了来自对象和构件设计的各种原则，例如，封装和自我包含等。那些保证服务的灵活性、松散耦合和复用能力的设计原则，对 SOA 架构来说同样是非常重要的。关于服务，一些常见的设计原则如下：
（1）明确定义的接口。服务请求者依赖于服务规约来调用服务，因此，服务定义必须长时间稳定，一旦公布，不能随意更改；服务的定义应尽可能明确，减少请求者的不适当使用；不要让请求者看到服务内部的私有数据。
（2）自包含和模块化。服务封装了那些在业务上稳定、重复出现的活动和构件，实现服务的功能实体是完全独立自主的，独立进行部署、版本控制、自我管理和恢复
（3）粗粒度。服务数量不应该太多，依靠消息交互而不是远程过程调用，通常消息量比较大，但是服务之间的交互频度较低。
（4）松耦合。服务请求者可见的是服务的接口，其位置、实现技术、当前状态和私有数据等，对服务请求者而言是不可见的。
（5）互操作性、兼容和策略声明。为了确保服务规约的全面和明确，策略成为一个越来越重要的方面。这可以是技术相关的内容，例如，一个服务对安全性方面的要求；也可以是与业务有关的语义方面的内容，例如，需要满足的费用或者服务级别方面的要求，这些策略对于服务在交互时是非常重要的。
结语
目前技术条件下，SOA的具体实现方式是利用XML和Web服务。此外，它还需要安全性、策略管理、可靠消息传递以及审计系统等等的支持，从而有效地工作。
SOA服务和Web服务之间的区别在于设计[2]。SOA的概念中并没有明确定义服务具体如何交互，而仅仅定义了服务如何相互理解以及如何交互。这种区别也就是指导策略与具体方法之间的区别。而且，Web服务在需要交互的服务之间如何传递消息有具体的指导原则，具体实现Web服务的模型是通过HTTP传递的SOAP消息的模型。尽管目前Web服务是实现SOA的最好方式。但是SOA并不局限于Web服务。其他使用WSDL直接实现服务接口并且通过XML消息进行通信的协议也可以包括在SOA之中。
因此，从本质上说，Web服务只是实现SOA的具体方式之一。随着技术的发展，完全可能会出现替代Web服务的新技术新方法，利用它们能够更好的实现SOA。
参考文献
[1] SOA/软件架构设计---面向服务的架构（SOA详细解释）
[2] 面向服务的架构（SOA）
https://www.cnblogs.com/zyt-bg/p/10938094.html
[3] 面向服务架构（Service-Oriented Architecture，SOA）
https://wiki.mbalib.com/wiki/面向服务架构