构建SOA架构(笔记)

1.         什么是SOA架构设计师与设计和开发人员之间的差别呢？

相信这些都是使大家最容易产生迷惑的问题。举个实际的例子来说，当构建一个基于SOA架构的系统的时候，针对一个具体的 service，系统设计人员主要应该关注的是这个service能够为外部用户提供什么样的服务，也就是说系统设计人员关注的是这个service所提供的功能。而对于SOA架构设计师来说，他们更关心的可能是当有一千个用户同时调用这个 service的时候，什么会发生？也就是说架构设计师关注的应该是一些商业需求和服务级别（service-level）需求。

2.         分析原有系统中的集成需求

l         应用程序集成的需求

l         终端用户界面集成的需求

l         流程集成的需求

l         系统信息集成的需求

3.         服务粒度的控制以及无状态服务的设计

l         粗粒度的外系统接口

粗粒度服务接口保证了服务请求者将以一致的方式使用系统中所暴露出的服务

l         较细粒度的服务接口通常用于企业系统架构的内部

从技术上讲，粗粒度的服务接口可能是一个特定服务的完整执行，而细粒度的服务接口可能是实现这个粗粒度服务接口的具体的内部操作。 举个例子来说，对于一个基于SOA架构的网上商店来说，粗粒度的服务可能就是暴露给外部用户使用的提交购买表单的操作，而系统内部的细粒度的服务可能就是实现这个提交购买表单服务的一系列的内部服务，比如说创建购买记录，设置客户地址，更新数据库等一系列的操作。

通常架构设计师可以使用BPEL来创建由细粒度操作组成的业务流程的粗粒度的服务接口

4.         无状态服务的设计

 

SOA系统架构中的具体服务应该都是独立的、自包含的请求，在实现这些服务的时候不需要前一个请求的状态，也就是说服务不应该依赖于其他服务的上下文和状态，即SOA架构中的服务应该是无状态的服务。在服务的具体实现机制上，我们可以通过使用 EJB 组件来实现粗粒度的服务

 

5.         SOA 为企业级架构设计带来的影响

 

l         SOA 的特点及其使用范围

 

SOA 既不是一种语言，也不是一种具体的技术，它是一种新的软件系统架构模型。 SOA 最主要的应用场合在于解决在Internet环境下的不同商业应用之间的业务集成问题。Internet环境区别于Intranet环境的几个特点主要是：

 (a)大量异构系统并存，不同计算机硬件工作方式不同，操作系统不同、编程语言也不同；

(b)大量、频繁的数据传输的速度仍然相对较缓慢并且不稳定；

(c)无法完成服务（service）的版本升级，甚至根本就无法知道互联网上有哪些机器直接或者间接的使用某个服务。

SOA 架构具有一些典型特性，主要包括松耦合性，位置透明性以及协议无关性。

松耦合性要求 SOA 架构中的不同服务之间应该保持一种松耦合的关系，也就是应该保持一种相对独立无依赖的关系；

位置透明性要求 SOA 系统中的所有服务对于他们的调用者来说都是位置透明的，也就是说每个服务的调用者只需要知道他们调用的是哪一个服务，但并不需要知道所调用服务的物理位置在哪里；

协议无关性要求每一个服务都可以通过不同的协议来调用。

通过这些 SOA 架构所具有的特性我们可以看到，SOA 架构的出现为企业系统架构提供了更加灵活的构建方式，如果企业架构设计师基于 SOA 来构建系统架构，就可以从底层架构的级别来保证整个系统的松耦合性以及灵活性，这都为未来企业业务逻辑的扩展打好了基础。

 

1．2 SOA 架构的分层模型

 

接下来简要介绍一下 SOA 系统中的分层模型，整个 SOA 架构的分层模型如图2所示。

在 SOA 系统中不同的功能模块可以被分为7层：

第一层就是系统已经存在的程序资源，例如ERP或者CRM系统等。

第2层就是组件层，在这一层中我们用不同的组件把底层系统的功能封装起来。

第3层就是 SOA 系统中最重要的服务层，在这层中我们要用底层功能组件来构建我们所需要的不同功能的服务。总的来说，SOA 中的服务可以被映射成具体系统中的任何功能模块，但是从功能性方面可以大致划分为以下三种类型：

(1)商业服务（business service） 或者是商业过程（business process）。这一类的服务是一个企业可以暴露给外部用户或者合作伙伴使用的服务。比如说提交贷款申请，用户信用检查，贷款信用查询。

(2)商业功能服务（business function service）， 这类服务会完成一些具体的商业操作，也会被更上层的商业服务调用，不过大多数情况下这类服务不会暴露给外部用户直接调用，比如说检索用户帐户信息，存储用户信息等。

(3)技术功能服务（technical function service），这类服务主要完成一些底层的技术功能，比如说日志服务以及安全服务等。

第4层就是商业流程层，在这一层中我们利用已经封装好的各种服务来构建商业系统中的商业流程。

第5层表示层了，我们利用表示层来向用户提供用户接口服务，这一层可以用基于portal的系统来构建。以上这5层都需要有一个集成的环境来支持它们的运行，

第6层中的企业服务总线（ESB）提供了这个功能。

第7层主要为整个 SOA 系统提供一些辅助的功能，例如服务质量管理，安全管理这一类的辅助功能。

 

6.         非功能性服务级别（service-level）需求

1) 性能

推荐采用大数据量低频率访问模式，也就是以大数据量的方式一次性进行信息交换。这样做可以在一定程度上提高系统的整体性能。

2) 可升级性

可升级性是指当系统负荷加大时，仍能够确保所需的服务质量，而不需要更改整个系统的架构。不管是对已有系统的水平升级还是垂直升级，都不会影响到系统整体的架构

3) 可靠性

可靠性是指确保各应用及其相关的所有交易的完整性和一致性的能力。当系统负荷增加时，你的系统必须能够持续处理需求访问，并确保系统能够象负荷未增加以前一样正确地处理各个进程。可靠性可能会在一定程度上限制系统的可升级性。

4) 可用性

可用性是指一个系统应确保一项服务或者资源应该总是可被访问到的。

在基于 SOA 来构建系统架构的时候，对于关键性的服务需要更多地考虑其可用性需求，这可以由两个层次的技术实现来支持，第一种是利用不同服务的具体内部实现内部所基于的框架的容错或者冗余机制来实现对服务可用性的支持；第二种是通过UDDI等动态查找匹配方式来支持系统整体的高可用性。

5) 可扩展性

可扩展性是指在不影响现有系统功能的基础上，为系统添加新的功能或修改现有功能的能力。为了确保架构设计的可扩展性，都应该考虑下面几个要素：低耦合，界面(interfaces)以及封装。当架构设计师基于 SOA 来构建企业系统架构时，就已经隐含地解决了这几个可扩展性方面的要素。

6) 可维护性

可维护性是指在不影响系统其他部分的情况下修改现有系统功能中问题或缺陷的能力。

要想提高系统的可维护性，你必须考虑下面几个要素：低耦合、模块性以及系统文档记录。在企业系统可扩展性中我们已经提到了 SOA 架构能为系统中暴露出来的各个子功能模块也就是服务带来低耦合性和很好的模块性。关于系统文档纪录，除了底层子系统的相关文档外，基于 SOA 的系统还会引用到许多系统外部的由第三方提供的服务，因此如果人力资源准许的话，应该增加专职的文档管理员来专门负责有关整个企业系统所涉及的所有外部服务相关文档的收集、归类和整理，这些相关的文档可能涉及到第三方服务的接口（可以是WSDL）、服务的质量和级别、具体性能测试结果等各种相关文档。基于这些文档，就可以为 SOA 架构设计师构建企业 SOA 架构提供很好的文档参考和支持。

7) 可管理性

可管理性是指管理系统以确保整个系统的可升级性、可靠性、可用性、性能和安全性的能力。具有可管理性的系统，应具备对服务质量需求（QoS）的系统监控能力，通过改变系统的配置从而可以动态地改善服务质量，而不用改变整体系统架构。

8) 安全性

安全性是指确保系统安全不会被危及的能力。目前，安全性应该说是最困难的系统质量控制点。应该把整体系统架构尽可能地分割成各个子功能模块，在将一些子功能模块暴露为外部用户可见的服务的时候，要围绕各个如果企业 SOA 架构中的一些服务是由Web Service实现的，在考虑这些服务安全性的时候也要同时考虑效率的问题，因为WS-Security会为Web Service带来一定的执行效率损耗。子模块构建各自的安全区。