本文共 3181 字，大约阅读时间需要 10 分钟。

    这么久，一直在关注SOA，看了许多关于SOA的文章，从概念，到实现，现在想以自己的语言来总结一下所学到的。

   看 了这么多文章，我觉得我最喜欢的一句就是：SOA是一场架构革命，其实质就实将系统模型与系统实现分离出来。一个大型的系统不可能仅仅由一个功能模块组成，而恰恰相反，企业级系统正是由多个具有独立功能的子系统组成，而各个子系统之间需要保持良好的封装性，各个系统只通过提供向外部的统一的接口来交互。这就是所谓的松耦性。 同时，SOA架构要求各个子系统（组件模块）的交互需要时独立于平台的（不管时J2EE，.NET,CORBA）。所以SOA的架构是一个组件模型，它将应用程序的不同功能单元－－服务(Service)，通过服务间定义良好的接口和契约（contract）联系体来。

       而且接口需要采取中立的方式定义，独立于具体的实现服务和硬件平台，操作系统和编程语言，使得构建这样得系统得服务可以使用统一和标准得方式进行通信。这种具有中立接口得定义得特征也被成为服务之间得松耦合。

  所以SOA架构具备了以下特征

       1，服务得封装性(encapsulaiton)。将服务封装成用于业务流程得可重用得组件得应用程序函数。它提供信息或简化业务数据从一个有效得，一致得状态向另一个状态的转变。封装隐藏了复杂性。服务API保持保持不变，使得用户远离具体实施上的变更。

      2，服务的重用（reuse）。

       3，服务的互操作（interoperability）。

        4，服务是自治的（Autonomous）功能实体。

       5，服务之间的松散耦合度（Loosly Coupled）。

      6，服务是位置透明的（location transparency）。

   所以SOA架构的基本单元是服务（service）。它的三个参与具体是：服务提供者者（service provider），

   服务代理者（service broker） 和服务消费者（service consumer）。

         SOA有三个抽象级别

          1 ，操作  2，服务 3，业务流程

      实现SOA的主要技术包括

 1。XML

        xml （extensible markup language） 是一个基于文本的W3C 规范的标记语言，与HTML使用标签来描述外观和数据不同，xml严格定义了可移植化的结构数据（structured data）。它可以作为数据描述语言的语言（metadata 元数据），如标记语法或词汇，交换格式和通信协议。

2。SOAP

  简单对象访问协议（Simple Object Access Protocol）是一个基于XML的，用于在分布式环境下交换信息的轻量级协议。SOAP在请求者和提供者对象之间定义了一个通信协议，这样，请求对象可以执行远程提供对象的方法调用。

3。WSDL

 Web 服务描叙语言WSDL（Web Service Description Language） 是一个提供描述服务IDL（Interface Description Language）标准方法的XML词汇。Web 服务描述语言（WSDL）规范定义了一个 XML词汇表，该词汇表依照请求和响应消息，在服务请求者和服务提供者之间定义了一种契约。我们能够将Web服务定义为软件，这个软件通过描述SOAP消息接口的 WSDL文档来提供可重用的应用程序功能，并使用标准的传输协议来进行传递。

WSDL描述包含必要的细节,以便服务请求者能够使用特定服务：

● 请求消息格式

● 响应消息格式

● 向何处发送消息。

4.UDDI

 统一描述，发现和继承（Universal Description ，Description  and VIntegration）规范提供了一组公用的SOAP API，使得服务代理得以实现。UDDI为发布服务的可用性和发布所需服务定义了一个标准接口（基于SOAP消息）。UDDI实现将发布和发现服务的SOAP 请求解释为用于基本数据存储的数据管理功能调用。

为了发布和发现其他SOA服务，UDDI 通过定义标准的 SOAP 消息来实现服务注册（Service Registry）。注册是一种服务代理，它是在 UDDI 上需要发现服务的请求者和发布服务的提供者之间的中介。一旦请求者决定使用特定的服务，开发者通常借助于开发工具（如Microsoft Visual Studio .NET）并通过创建以发送请求并处理响应的方式访问服务的代码来绑定服务。

SOA不需要使用UDDI，但由于 UDDI 是建立在SOA上来完成自身工作的，所以UDDI是服务发现的一个好的解决方案

5．ESB

 企业服务总线ESB（Enterprise Service Bus）是SOA架构的一个支柱技术。 作为一种消息代理架构它提供消息队列系统，使用诸如SOAP或JMS (Java Message Service)等标准技术来实现。

  SOA架构是很吸引目光的，但是SOA也具有一些自身的不足

缺憾之一 : 可靠性(Reliability）

SOA还没有完全为事务的最高可靠性——不可否认性(nonrepudiation)、消息一定会被传送且仅传送一次（once-and-only-once delivery）以及事务撤回（rollback）——做好准备，不过等标准和实施技术成熟到可以满足这一需求的程度并不遥远。

缺憾之二 : 安全性（Security）

在过去，访问控制只需要登录和验证；而在SOA环境中，由于一个应用软件的组件很容易去与属于不同域的其他组件进行对话，所以确保迥然不同又相互连接的系统之间的安全性就复杂得多了。

缺憾之三:编排 (Orchestration

缺憾之四:遗留系统处理（Legacy support）

SOA中提供集成遗留系统的适配器， 遗留应用适配器屏蔽了许多专用性API的复杂性和晦涩性。一个设计良好的适配器的作用好比是一个设计良好的SOA服务：它提供了一个抽象层，把应用基础设施的其余部分与各种棘手问题隔离开来。一些厂商就专门把遗留应用软件“语义集成”到基于XML的集成构架中。 但是集成遗留系统的工作始终是一种挑战。

缺憾之五 : 语义 Semantics

性能（performance）：SOA的第六个缺憾

批评SOA的人士经常会提到性能是阻碍其采用的一个障碍，但技术的标准化总需要在速度方面有一些牺牲。这种怀疑观点通常针对两个方面：SOA的分布性质和Web服务协议的开销。

不可否认，任何分布式系统的执行速度都不如独立式系统，这完全是因为网络的制约作用造成的。当然，有些应用软件无法容忍网络引起的延迟，例如那些对实时性要求很高的应用软件。所以在应用SOA架构之前，搞清楚它的适用范围就显得很重要了。

除了上述几点之外，我认为还有两点也颇值得关注：

松耦合和敏捷性要求之间的权衡难题:

服务松耦合设计其实是一把双刃剑，在带来应变敏捷性的同时，也给业务建模和服务划分带来难题。这就是为什么在SOA讨论中，业务建模的争论总是最多的原因。

跨系统集成难题：

面向服务的体系结构设计将跨越计算机系统，并且还可能跨越企业边界。我们不得不考虑在使用 Internet 时安全性功能和需求，以及如何链接伙伴的安全域。Internet 协议并不是为可靠性（有保证的提交和提交的顺序）而设计的，但是我们需要确保消息被提交并被处理一次。当这不可能时，请求者必须知道请求并没有被处理。

 最后我希望用一句 IBM 的一位权威级的人物（女性－－伟大！ ^_^） 的一句话来结尾

Five SOA Entry Points

转载地址：https://blog.csdn.net/jesse8013/article/details/1475127 如侵犯您的版权，请留言回复原文章的地址，我们会给您删除此文章，给您带来不便请您谅解！