SOA学习心得总结.doc

SOA学习心得总结一、SOA简介1SOA概念SOA是指为了解决在Internet环境下业务集成的需要，通过连接能完成特定任务的独立功能实体实现的一种软件系统架构。SOA不是一种语言，也不是一种具体的技术而是一种软件系统架构,它尝试给出在特定环境下推荐采用的一种架构,面向不同的应用场景，用来满足不同的特定需求SOA的使用范围：需求决定同时也限制功能.主要的应用场合在于解决在Internet环境下的不同商业应用之间的业务集成问题.SOA 架构具有一些典型特性，主要包括松耦合性，位置透明性以及协议无关性。松耦合性要求 SOA 架构中的不同服务之间应该保持一种松耦合的关系，也就是应该保持一种相对独立无依赖的关系;位置透明性要求 SOA 系统中的所有服务对于他们的调用者来说都是位置透明的，也就是说每个服务的调用者只需要知道他们调用的是哪一个服务，但并不需要知道所调用服务的物理位置在哪里;而协议无关性要求每一个服务都可以通过不同的协议来调用。soa 就是使用xml的描述语言来描述接口的技术，SOA架构体系正是软件工程发展一个有标志性里程碑也是开关原则的必然出现的架构.SOA其实体现的是:分离关注点他和J2EE(JavaEE5)的JDBC/JDNI思路是一样的，而WebService只是他的一种行业标准化的结果而已，而并不是SOA就是SOAP（只是SOAP只是SOA的一种体现），概括的说就是一个总线上用标准插件的方式去实现业务的脱耦。二、SOA三大基本特征1 独立的功能实体SOA架构中提供服务的功能实体的完全独立自主的能力,实体自我管理和恢复能力.常见自我恢复的技术：事务处理(Transaction)，消息队列(Message Queue)，冗余部署(Redundant Deployment)和集群系统(Cluster)理解：完全独立自主的能力，不同与传统的组件技术，如.NET Remoting，EJB，COM或者CORBA，都需要有一个宿主(Host或者Server)来存放和管理这些功能实体；当这些宿主运行结束时这些组件的寿命也随之结束。这样当宿主本身或者其它功能部分出现问题的时候，在该宿主上运行的其它应用服务就会受到影响。2 大数据量低频率访问SOA系统推荐采用大数据量的方式一次性进行信息交换。理解：传统的服务提供都是通过函数调用的方式进行的，一个功能的完成往往需要通过客户端和服务器来回很多次函数调用才能完成。在Intranet的环境下，这些调用给系统的响应速度和稳定性带来的影响都可以忽略不计，但是在Internet环境下这些因素往往是决定整个系统是否能正常工作的一个关键决定因素。3 基于文本的消息传递SOA采用基于文本的消息传递方式（由于基于文本的消息本身是不包含任何处理逻辑和数据类型的），数据处理端可以只选择性的处理自己理解的那部分数据，而忽略其它的数据，从而得到的非常理想的兼容性。理解：由于Internet中大量异构系统的存在决定了SOA系统必须采用基于文本而非二进制的消息传递方式，在COM、CORBA这些传统的组件模型中，从服务器端传往客户端的是一个二进制编码的对象，在客户端通过调用这个对象的方法来完成某些功能；但是在Internet环境下，不同语言，不同平台对数据、甚至是一些基本数据类型定义不同，给不同的服务之间传递对象带来的很大困难。三、一个典型的SOA实现一个典型的SOA实现：HTTP协议我们最熟悉的HTTP协议就是一个非常典型的SOA架构设计。HTTP协议的工作过程简单叙述如下：1) 客户端，通常是通过浏览器，向服务器端以文本的方式发送一个请求，索取一个Web页面； 2) 服务器端接收到这个请求之后，根据请求的内容进行处理并且返回一个符合HTML语法的文本； 3) 客户端接收到服务器端的响应文本后调用本地的程序，通常还是浏览器，把返回的HTML文本的内容展现出来。 SOA对于软件架构设计的影响* 使用基于文本方式的SOAP调用，摆脱远程调用中出现的函数参数类型等与数据无关的信息，保证所有SOAP传递的都是有意义的商业数据。依赖于Schema，而不是类定义对这些数据进行解释。 * 传统的三层Web应用将可能变成四层结构：传统意义上的商业逻辑层将被进一步划分为存放每个会话(Session)信息的客户逻辑层和与状态无关Sateless的SOA层四、SOA框架的不足缺憾之一 : 可靠性（Reliability）。缺憾之二 : 安全性（Security）缺憾之三 : 编排 （Orchestration）缺憾之四 :遗留系统处理（Legacy support）缺憾之五 : 语义 Semantics性能（performance）：SOA的第六个缺憾？松耦合和敏捷性要求之间的权衡难题跨系统集成难题五、面向服务的分析和设计概述面向服务的分析和设计分为服务发现、服务规约和服务实现。服务的实现包括服务、组件和服务组装的实现.为了开始面向服务的分析和设计，如下的输入需要被用在分析和设计的过程中（1）业务领域（Business Domain）和业务功能域（Business Function Area）。业务领域和业务功能域的划分勾勒了目标企业的业务结构，它一方面帮助我们从全局的角度来理解目标企业的业务，另一方面也是我们进行组织服务层次结构的重要依据。（2）业务流程（Business Process）。业务流程，尤其是第一级的业务流程，对企业经营全局至关重要。通常，通过第一级的业务流程可以追溯到企业中最为重要的业务活动，因此第一级业务流程是我们进行服务分析和设计的主要入口点。（3）业务目标（Business Goal）。组织和业务流程都是为业务目标服务的，为了完成业务目标，组织和业务流程都有可能进行适当的调整。分析业务目标在有些时候可以帮助我们发现一些通过业务流程分析遗漏的服务；与此同时，业务目标也是服务描述中一部分重要的内容。（4）现有系统（Existing System）。现有系统是目前业务活动和业务流程的写照，通过分析现有系统模块和功能，能够帮助发现服务。与此同时，对于现有系统的分析和理解是进行服务实现设计的重要前提。掌握了业务领域划分、业务流程、业务目标和现有系统后按照三个阶段来进行服务分析和设计发现服务、描述服务和服务实现,这三个阶段并不是一次性完成的，一般需要一个迭代的过程,分析和确定的服务模型也有一个演化的过程，并逐渐地精化，越来越贴近业务。软件工程的演变和面向服务体系结构SOA和当前软件工程过程的一个共同交叉点就是业务价值驱动（Business Centric），强调速度。SOA从软件的灵活性和重用能力入手，而敏捷过程则从软件交付效率出发,SOA的架构特性，使得敏捷过程非常适合SOA项目的实施。在SOA架构中，服务的独立性，使得每个服务可以被单独地开发、测试和集成,迭代的开发过程服务粒度的控制以及无状态服务的设计SOA系统中的服务的构建有两点需要注意的地方:首先是对于服务粒度的控制，另外就是对于无状态服务的设计。服务粒度的控制SOA系统中的服务粒度的控制是一项十分重要的设计任务。通常来说，对于将暴露在整个系统外部的服务推荐使用粗粒度的接口，而相对较细粒度的服务接口通常用于企业系统架构的内部。从技术上讲，粗粒度的服务接口可能是一个特定服务的完整执行，而细粒度的服务接口可能是实现这个粗粒度服务接口的具体的内部操作。举个例子来说，对于一个基于SOA架构的网上商店来说，粗粒度的服务可能就是暴露给外部用户使用的提交购买表单的操作，而系统内部的细粒度的服务可能就是实现这个提交购买表单服务的一系列的内部服务，比如说创建购买记录，设置客户地址，更新数据库等一系列的操作。虽然细粒度的接口能为服务请求者提供了更加细化和更多的灵活性，但同时也意味着引入较难控制的交互模式易变性,也就是说服务的交互模式可能随着不同的服务请求者而不同通常架构设计师可以使用BPEL来创建由细粒度操作组成的业务流程的粗粒度的服务接口。无状态服务的设计SOA系统架构中的具体服务应该都是独立的、自包含的请求，在实现这些服务的时候不