基于SCA的SOA架构研究与应用(本科毕业设计/论文)

chuang

贡献于2012-02-16

字数:0 关键词: WEB服务/RPC/SOA

本科生毕业设计(论文) 题 目: 基于 SCA 的 SOA 架构研究与应用 姓 名: chenwq 学 号: 2200700312 学 院: 软件学院 专 业: 软件工程 年 级: 2007 级 指导教师: (签名) 2011 年 6 月 9 日 I 基于 SCA 的 SOA 架构研究与应用 摘要 信息孤岛和遗留系统是现代 IT 业界面临的问题。解决这两个现象是企业走向大软 件过程中必须的一步。从上个世界七八十年代开始,随着信息化建设的深入,许多企业 开始建立计算机信息系统由于各个信息系统都是独立开发的,并且大多数是从单项业务 系统开始的,所采用的开发方式和平台各不相同,因此系统之间独立性很强而沟通性严 重缺乏,而以此系统为基础的企业职能部门,相互之间无法进行有效的通信,从而形成 一个一个孤立的信息系统,俗称“信息孤岛”。同时,随着企业职能部门、企业之间的 合并,所服务的流程和对象发生变化,旧的信息系统之间无法满足新的业务需求,而且 需要进行的修改又远远超出维护范畴,这种系统就已经成为了遗留系统。现代企业为了 降低成本,提高资源利用率;适应不断增长的客户、客户需求的不断变更以及激烈的市 场竞争,迫切需求各个部门以及商业伙伴之间能够及时获取实时信息,解决信息孤岛和 遗留系统问题。 在这样的环境下,一种软件架构模型:SOA 应运而生,SOA 正视 IT 系统的异构现 实,尊重不同 IT 技术存在的合理性,不为替代现有技术而生,而是致力于克服技术之 间互操作的困难。 本文的研究工作主要围绕以下方面进行:首先对 SOA 架构的理论体系进行分析研 究,其次,重点分析 Tuscany SCA 编程模型的技术规范,提出构建基于 SCA(服务组件 架构)的 SOA 架构的方法,再次,整合 Tuscany SCA、Spring Framework、Hibernate Framework 等相关技术搭建基于 SCA 的组件化开发平台,最后在此平台上开发一个基 于 JBoss jBPM 的工作流组件并以 Web Service 形式发布。 关键词:面向服务架构,服务,SCA 编程模型 II Research and Implementation of the Service Oriented Architecture Based OilSCA Abstract Information silos and legacy systems are the problems the modern IT industry facing. To solve these two phenomena is a significative breakthrough for software companies. Since the last seven eighties, with the construction of in-depth information, many companies have started to build computer information systems which were independent development of various information systems, and most of the individual business systems were from the single business based on different ways and platforms.So the communication between the systems are severe lack of communication,while this systems based on corporate functions could not communicate effectively.this problem leads to forming isolated information systems commonly known as "islands of information". Meanwhile, with the merger of corporate functions, business combination, the services for processes and objects have changed. The old information systems can not meet new business’s needs, and the need for modifications and maintenance are far beyond the scope of such systems,these systems are become legacy systems. In order to reduce costs, improve resource utilization; meet the growing amount of customers, constant changes of customer’s demands and fierce market competition, modern enterprises face with the urgent needs of various departments and business partners accessing real-time information in a timely manner, to solve the problem of information silos and legacy systems. In such an environment, a software architecture model: SOA comes into being.SOA faces the reality of heterogeneous IT systems, respects for different IT Technology rationality of the existence, not to replace the existing technology was born, but commit to overcome the difficulties of interoperability between different technologies. This research work focus on the following aspects: First, analysis for the theoretical framework of the SOA system ,secondly, focus on the Tuscany SCA programming model specifications,and a proposal of a methodology for SOA based on SCA (Service Component Architecture) ,then Integrate Tuscany SCA with Spring Framework, Hibernate Framework and other related technologies to build a development platform based on SCA components.Finally,design a workflow component based on Jboss jBPM on this development platform,and release the component in the way of web service. Keywords: Service-Oriented Architecture ,Service , SCA Programming Model III 目 录 第 1 章绪论 ........................................................................................................................ 1 1.1 课题背景及意义 ................................................................................................... 1 1.2 国内外研究现状 .................................................................................................. 2 1.3 本文作者的工作 .................................................................................................. 3 1.4 本文的组织结构 .................................................................................................. 4 第 2 章 面向服务的体系结构概述 .................................................................................. 5 2.1 SOA 概述 .............................................................................................................. 5 2.1.1 SOA 的概念 ................................................................................................ 5 2.1.2 SOA 体系结构 ........................................................................................... 5 2.2 SOA 基础技术概况 .............................................................................................. 8 2.2.1 Web Services 体系结构 .............................................................................. 8 2.2.5 ESB 企业服务总线概述 ........................................................................... 15 2.3 SOA 与 Web Services 的关系 ............................................................................ 16 2.4 SOA 服务设计原则 ............................................................................................ 16 2.5 本章小结 ............................................................................................................. 17 第 3 章 SOA 编程模型——SCA ................................................................................... 18 3.1 SCA 的起源 ........................................................................................................ 18 3.1.1 Web 服务的兴起 ...................................................................................... 18 3.1.2 Web 服务调用框架的任务 ...................................................................... 19 3.1.3 SCA 的提出 .............................................................................................. 19 3.2 本章小结 ............................................................................................................. 19 第 4 章 基于 SCA 的 SOA 架构设计 ............................................................................ 20 4.1 Apache Tuscany SCA 简介 ................................................................................ 20 4.2 使用 SCA 开发 SOA 应用 ................................................................................. 22 4.2.1 设计服务组件接口 ................................................................................... 22 4.2.2 实现组件的业务逻辑 .............................................................................. 23 4.2.3 装配 SCA 复合集 ..................................................................................... 24 4.3 Tuscany SCA 与 Spring 的互访能力 ................................................................. 27 4.3.1 Spring Framework 简介 ............................................................................ 27 4.3.2 SCA 与 Spring 两者相结合的优势 ....................................................... 27 4.3.3 将 Spring 应用程序定义为 SCA 组件 ................................................. 28 IV 4.3.4 基于 Spring 的 SCA 组件 ..................................................................... 28 4.4 SCA 的调用方式 ................................................................................................ 32 4.5 设计开发 jBPM 工作流组件 ............................................................................ 32 4.5.1 scawsp 架构分层描述 .............................................................................. 32 4.5.1.2 集成层 ................................................................................................... 33 4.5.1.3 服务层 ................................................................................................... 34 4.5.2 jBPM SCA 服务组件配置........................................................................ 34 4.5.2 组件部署文件 .......................................................................................... 36 4.5.3 Spring 实现 jBPM 服务组件复合集 ........................................................ 37 4.5.4 程序和配置实例 ...................................................................................... 41 4.5.5 数据访问层 Hibernate 配置 .................................................................... 43 4.5.6 工程配置 .................................................................................................. 47 4.5.6 组件运行效果 .......................................................................................... 48 4.6 本章小结 ............................................................................................................. 57 第 5 章基于 SOA 的企业应用系统设计方法 ................................................................ 58 5.1 基于 SOA 的分析设计方法 ............................................................................... 58 5.1.1 SOA 分层架构模型 .................................................................................. 58 5.1.2 基于服务的建模和架构方法 ................................................................... 59 5.1.3 SOA 的治理 .............................................................................................. 63 5.2 本章小结 ............................................................................................................. 65 第 6 章 总结与展望 ........................................................................................................ 66 致 谢 .............................................................................................................................. 67 参考文献 .......................................................................................................................... 68 基于 SCA 的 SOA 架构研究与应用 1 第 1 章绪论 1.1 课题背景及意义 信息孤岛和遗留系统是现代 IT 业界面临的问题。解决这两个现象是企业走向大软件过 程中必须的一步。从上个世界七八十年代开始,随着信息化建设的深入,许多企业开始建 立计算机信息系统由于各个信息系统都是独立开发的,并且大多数是从单项业务系统开始 的,所采用的开发方式和平台各不相同,因此系统之间独立性很强而沟通性严重缺乏,而 以此系统为基础的企业职能部门,相互之间无法进行有效的通信,从而形成一个一个孤立 的信息系统,俗称“信息孤岛”。同时,随着企业职能部门、企业之间的合并,所服务的 流程和对象发生变化,旧的信息系统之间无法满足新的业务需求,而且需要进行的修改又 远远超出维护范畴,这种系统就已经成为了遗留系统。现代企业为了降低成本,提高资源 利用率;适应不断增长的客户、客户需求的不断变更以及激烈的市场竞争,迫切需求各个 部门以及商业伙伴之间能够及时获取实时信息,解决信息孤岛和遗留系统问题。 业务模式的变迁和技术趋势的发展,使得企业的 IT 部门必须认真思考,选择一个符合 公司规划发展的 IT 战略,并落实到一个能够和业务真正对齐的技术策略和模型[1]。IT 世界 是一个异构的世界,技术种类繁多。每种技术背后都有一个或者几个该技术所擅长解决的 问题。这个现状是客观存在的,而全球化的大潮使得世界又不得不是平的,因此异构的 IT 系统之间的互操作需求日益迫切。在这样的环境下,一种软件架构模型:SOA 应运而生, SOA 正视 IT 系统的异构现实,尊重不同 IT 技术存在的合理性,不为替代现有技术而生, 而是致力于克服技术之间互操作的困难。 SOA 将应用程序的各个功能单元间通过定义良好的接口和契约联系起来,而这种不同 功能单元被称作为服务。服务间接口是采用中立的方式进行定义的,它独立于实现服务的 硬件平台、操作系统和编程语言等环境。这样,服务间将采用通用的、统一的和与系统平 台无关的方式进行交互。在基于 SOA 的企业集成应用的体系结构中包括了一个 Web 服务 的三个组件:服务提供者、服务请求者和服务中介者。客户端通过 Internet 或者企业 portal 访问应用服务器,应用服务器作为客户端代理,作为 Web 服务的请求者,向注册中心查找 所需的服务。可用的 Web 服务时用平台无关的 Web 服务描述语言 WSDL 描述,从而支持 平台无关的通信。从而满足企业信息系统的集成需求,解决了信息孤岛和遗留应用系统的 问题。 目前商业企业只能通过不断开发新应用、扩展现有应用来支撑其现有的业务需求。 本课题拟开发一个组件化开发平台,其意义在于: 1. 企业级软件架构,今后新建系统可直接套用,不会因新增系统或系统架构的差异 本科生毕业设计 ( 论文 ) 2 产生影响 2. 业务功能和业务流程重用(不仅仅代码重用) 3. 支持业务功能标准化和模块化的推进,使重用达到最大化 4. 灵活、快速应对业务流程的优化和改善(变更),而系统运行影响减小 简化系统间接口(数量及复杂度均得到简化) 因此,可以良好的解决信息孤岛和遗留系统问题,实现 IT 和企业业务之间的“业务驱 动服务,服务驱动技术”。 1.2 国内外研究现状 目前两大关键技术服务构架架构(Service Component Architecture,SCA)和服务数据 对象(Service Data Objects,SDO)的草案已经宣布完成,并正式提交给结构信息标准化组 织[6]。SCA 简化了服务的创建和组合;SDO 制定了对不同地方和格式的数据的统一存取 标准。这两个标准无疑会推动原有应用系统向 SOA 进化,增强服务的重用能力,提高企 业应用系统对业务需求变化的快速应对能力。 随着各种标准的完善,国外许多大型公司都推出了自己的 SOA 产品。SAP 公司于 2006 年发布了第一个面向服务架构的企业应用 SAP ERP2005。Oracle 公司也正式推出了一套完 整的用于创建、部署和管理 SOA 服务的服务基础设施组件——SOA 套件,此套件支持服 务的创建和管理,并可将服务组合为复合应用和业务流程。与此同时,许多公司在实现各 种 Web 服务和将已有应用转换成面向服务架构上也取得了重大的进展。已经有一些将 SOA 设计思想应用到医疗、电信、金融等行业的案例。如德国邮政系统和金融行业,IBM 公司 在企业信息集成方面进行 SOA 应用,也取得了显著成效。 国内对 SOA 及 Web 服务相关技术的研究工作开展的要晚些,目前尚未取得突出的研 究成果。在 SOA 方面,软件公司推出的产品也比较少,但很多公司已经开始积极投入到 这方面的研究中,新中大发布了国内首款基于 SOA 的管理软件,国内 ERP 巨头用友集团 从 2003 年开始研发的下一代产品 U9 也是基于 SOA 架构的。大多数企业已经意识到部署 SOA 的作用和价值,并对 SOA 的发展前景抱有信心。在发展 SOA 的过程中,中国和国外 信息化发达国家(如美国)有着不同的发展基于和条件。在大多数美国企业中已经具备完 善的应用系统,SOA 的实施只需要对已有系统中的功能进行提取和包装,形成标准的服务, 而非用高成本的标准方法全新构造服务。而在中国企业,信息化建设正由生产系统转向营 销服务系统,因此中国 SOA 的首要任务是全新构造大量的服务。 下图为易观国际考察了中国中间件市场后发布的《2007 年第 3 季度中国中间件软件市 场数据监测》数据: 基于 SCA 的 SOA 架构研究与应用 3 图 1-1 2007 年第 3 季度中国中间件软件市场数据监测示意图 1.3 本文作者的工作 本课题将先从理论上提出平台模型,再从搭建过程中不断验证修正模型最后构建出一 个初步的开发平台。立足于企业级信息系统集成的应用,致力于构建一个基于 SCA 的 SOA 架构开发平台,并实现一个基于 jBPM 的工作流组件作为基础设施。 基于 Tuscany SCA 的服务构件架构,以 Spring 拓展实现 POJO 作为 SCA 组件实现, 并用 Hibernate 屏蔽底层 JDBC,给上层业务逻辑提供统一调用接口,以此分层结构,构建 一组件化开发平台,并在此平台上开发一工作流组件作为平台基础设施。具体如下: 1. 搭建组件化开发平台 a) 搭建 Eclipse SOA Platform b) 添加 Tuscany SCA Tools c) 集成 JBoss Server d) 创建 Eclipse 下的 Tuscany SCA User Library e) 创建 Eclipse 下的 Spring Framework User Library f) 创建 Eclipse 下的 Hibernate Framework User Library g) 支持 Tuscany SCA 和 Spring 的互访功能 2. 开发基于 jBPM 的工作流组件 a) 创建 Jboss jBPM Suite b) 设计 jBPM 工作流组件 c) 发布 jBPM 工作流服务 本科生毕业设计 ( 论文 ) 4 1.4 本文的组织结构 本文将主要从以下几个部分进行阐述: 第一章为绪论。概要介绍了课题的研究背景和目前的国内外现状。 第二章中主要介绍面向对象服务架构,包含 SOA 相关技术的概念、其中主要是 Web Services 与 SOA 的关系。 第三章主要介绍 SCA 编程模型的起源和基本概念。 第四章是本文的重点之一,研究了如何基于 SCA 开发 SOA 应用,包括设计服务组件 接口、实现组件业务逻辑代码以及装配模型,接着研究了 Tuscany SCA 与 Spring 互访 的实现方式,最后介绍了 SCA 客户端的调用方式。 第五章介绍了如何基于 SOA 开发企业应用系统,呈现了如何利用 SOA 的架构体系方 法对系统进行相关的系统分析,并在此基础上,提出了一套适合中小型企业进行 SOA 架构建设实现的方法和步骤。 最后是总结和展望,总结本文的工作,并提出进一步深入研究、改进的一些构想。 基于 SCA 的 SOA 架构研究与应用 5 第 2 章 面向服务的体系结构概述 2.1 SOA 概述 2.1.1 SOA 的概念 SOA 本身就是一种面向企业级服务的系统架构,简单来说,SOA 就是一种进行系统 开发的新的体系架构,在基于 SOA 架构的系统中,具体应用程序的功能是由一些松耦合 并且具有统一接口定义方式的组件(也就是 service)组合构建起来的。因此,基于 SOA 的架构也一定是从企业的具体需求开始构建的。但是,SOA 和其它企业架构的不同之处就 在于 SOA 提供的业务灵活性。业务灵活性是指企业能对业务变更快速和有效地进行响应、 并且利用业务变更来得到竞争优势的能力。对企业级架构设计师来说,创建一个业务灵活 的架构意味着创建一个可以满足当前还未知的业务需求的 IT 架构。 利用基于 SOA 的系统构建方法,如图 2-1 中所示的一样,一个基于 SOA 架构的系统 中的所有的程序功能都被封装在一些功能模块中,我们就是利用这些已经封装好的功能模 块组装构建我们所需要的程序或者系统,而这些功能模块就是 SOA 架构中的不同的服务 (services)。 图 2-1 乐高积木 因此,SOA 架构本质上来说体现了一种复合的概念:它不仅为一个企业中商业流程的 组织和实现提供了一种指导模式,同时也为具体的底层 service 开发提供了指导[8]。 2.1.2 SOA 体系结构 2.1.2.1 SOA 体系结构堆栈 面向服务的体系结构提供了一种方法,通过这种方法,可以构建分布式系统来将应用 本科生毕业设计 ( 论文 ) 6 程序功能作为服务提供给终端用户应用程序或其他服务。其组成元素可以分成功能元素和 服务质量元素。图 2-2 展示了体系结构堆栈以及在一个面向服务的体系结构可能观察到的 元素。 图 2-1 面向服务的体系结构的元素 体系结构堆栈分成两半,左边的一半集中于体系结构的功能性方面,而右边的一半集 中于体系结构的服务质量方面。这些元素详细描述如下[8]: 功能性方面包括:  传输是一种机制,用于将来自服务使用者的服务请求传送给服务提供者,并且将 来自服务提供者的响应传送给服务使用者。  服务通信协议是一种经过协商的机制,通过这种机制,服务提供者和服务使用者 可以就将要请求的内容和将要返回的内容进行沟通。  服务描述是一种经过协商的模式,用于描述服务是什么、应该如何调用服务以及 成功地调用服务需要什么数据。  服务描述实际可供使用的服务。  业务流程是一个服务的集合,可以按照特定的顺序并使用一组特定的规则进行调 用,以满足业务要求。注意,可以将业务流程本身看作是服务,这样就产生了业 务流程可以由不同粒度的服务组成的观念。  服务注册中心是一个服务和数据描述的存储库,服务提供者可以通过服务注册中 心发布它们的服务,而服务使用者可以通过服务注册中心发现或查找可用的服务。 服务注册中心可以给需要集中式存储库的服务提供其他的功能。 服务质量方面包括:  策略是一组条件和规则,在这些条件和规则之下,服务提供者可以使服务可用于 使用者。策略既有功能性方面,也有与服务质量有关的方面;因此,我们在功能 基于 SCA 的 SOA 架构研究与应用 7 和服务质量两个区中都有策略功能。  安全性是规则集,可以应用于调用服务的服务使用者的身份验证、授权和访问控 制。  传输是属性集,可以应用于一组服务,以提供一致的结果。例如,如果要使用一 组服务来完成一项业务功能,则所有的服务必须都完成,或者没有一个完成。  管理是属性集,可以应用于管理提供的服务或使用的服务。 2.1.2.2 SOA 参考架构 SOA 参考架构是一种组织 SOA 的构建元素--服务的方式,IBM 希望通过这种参考架 构为企业架构提供一种指导和参考,使得新的需求能够更快的得到响应。参考架构如图 2-3 所示。 图 2-3 SOA 参考架构 其中左侧的绿色部分表示建模和组装,中间的蓝色部分表示部署,右边的深蓝色部门 表示管理。中枢部分是企业服务总线(Enterprise Service Bus),在服务之间提供连通性支 持。 参考架构描述了企业范围内 SOA 方案所需要的关键能力。 工具是集成架构的基本组件,SOA 参考架构则提供了开发服务和业务创新优化服务。 开发服务用于实现新开发的组件以及重用基础架构的能力;业务创新优化服务用于从 IT 和业务两个层面来监控和管理运行情况。 企业服务总线是 SOA 参考架构的核心。它为整个架构范围内所有服务提供相互通讯 的能力。其中传输服务、事件服务以及中介服务都是通过 ESB 来提供的。 交互服务将 IT 的功能和数据传递给最终用户,并满足用户特定的使用习惯。 流程服务提供服务控制能力,将多个服务串起来实现一个业务流程。 信息服务通过联合、复制和转换来解决基于不同实现方式的不同数据源之间的数据共 本科生毕业设计 ( 论文 ) 8 享难题。 SOA 解决方案中的很多服务都是有已有应用提供的,访问服务提供已有应用、打包应 用程序与 ESB 之间的桥接能力,使得已有应用的功能以服务的形式对外暴露出来。 在业务流程需要与外部的合作伙伴、供应商交互的情况下,伙伴服务提供一组文档、 协议以及伙伴管理的能力。 应用服务为新的应用组件提供运行时服务。 作为所有能力的基础,基础服务用于优化通过率、性能和可靠性。 IT 服务管理服务包括对服务、应用和资源的管理和保护能力,如通过负载均衡来有效 的分配系统计算资源。 SOA 参考架构是一个完整的企业架构,可以覆盖整个企业范围内集成的需求。参考架 构中的服务通过模块化的方式进行集成,因此 SOA 的实现可以从一个小的项目来启动, 在新的项目实施的时候,新的功能能够轻松的加到架构中,通过渐进的方式在企业范围内 扩大集成的范围[9]。 2.2 SOA 基础技术概况 2.2.1 Web Services 体系结构 Web Services 可以从多个角度来定义。从技术方面讲,一个 Web Service 是可以被 URI 识别的应用软件,其接口和绑定由 XML 描述和发现,并可与其他基于 XML 消息的应用程 序交互。从功能角度讲,Web Services 是一种新型的 Web 应用程序,具有自包含、自描述 以及模块化的特点,可以通过 Web 发布、查找和调用。其实现的功能可以是响应客户一个 简单的请求,也可以是完成一个复杂的商务流程。一个 Web Service 配置好后,其他应用 程序和 Web Service 就可以直接发现和调用该服务。具体而言 Web Service 应具有如下特性: (1)可描述,可以通过一种服务描述语言来描述; (2)可发布,可以在注册中心注册其描述信息并发布; (3)可查找,通过向注册服务器发送查询请求可以找到满足查询条件的服务,获取服务 的绑定信息; (4)可绑定,通过服务的描述信息可以生成可调用的服务实例或服务代理; (5)可调用,使用服务描述信息中的绑定细节可以实现服务的远程调用; (6)可组合,可以与其他服务组合在一起形成新的服务。 Web Service 采用了面向服务(Service-Oriented Architec-ture,SOA)的体系结构,通过服 务提供者、请求者和注册中心等实体之间的交互实现服务调用,如图 2-4 所示。 基于 SCA 的 SOA 架构研究与应用 9 图 2-4 Web Services 体系结构 Web Services 采用的体系结构中包含三种角色。服务是提供给需求者,按一定规则使 用的应用程序,其描述信息和访问规则被发布到服务注册库。服务提供者是服务的所有者, 从体系结构上看它是提供服务访问的平台。服务请求者是需要特定功能的企业或组织,从 体系结构上看是查找和调用服务的客户端应用程序。服务注册库是存储服务描述信息的信 息库,服务提供方在此发布他们的服务,服务请求方在此查找服务,获取服务的绑定信息。 上述三种实体之间主要通过发布、查找和绑定操作进行交互。服务提供者在通过身份 验证后,对服务描述信息进行发布或修改。为了使服务能够被发现,注册中心要提供规范 的查询接果。查找一般包含两种模式:浏览和直接获取。前者是请求方根据一定分类标准来 浏览,逐步缩小查找的范围,直到找到满足需要的服务,查找结果一般是服务集合;后者则 根据关键字直接得到特定服务的描述信息,其查找结果是唯一的。请求方分析得到的服务 信息,可以知道调用该服务的具体细节,如访问路径、服务调用的参数、返回结果、传输 协议等,请求方据此进行绑定,实现对服务的远程调用。 2.2.1.1 XML 概述 XML 是自描述的、半结构化的和可扩展的标记语言。作为一种标记语言,它将数据 和对数据的描述(元数据)结合在一起,因而具有比关系模型更灵活、更强的描述能力—— 不仅能表示结构化数据,还能表示半结构化数据。XML 基于文本,与特定支撑环境无关, 具有广泛的通用性。XML 灵活的可扩展机制,使得各行各业都可定义自己的 XML 词汇, 并形成标准。 XML 具有以下重要特征: 本科生毕业设计 ( 论文 ) 10 (1) XML 允许各个组织、个人建立适合自己需要的标记(tag)集合,并且这些标记可以 迅速地投入使用。这一特征使得 XML 可以在电子商务、政府文档、司法、出版、CAD/CAM、 保险机构、厂商和中介组织信息交换等领域中一展身手。 (2) XML 的数据存储格式不受显示格式的制约。XML 把文档的三个要素:数据、结 构以及显示方式独立开来,分别处理。首先把显示格式从数据内容中独立出来,保存在样 式表文件中;这样,如果需要改变文档的显示方式,只要修改样式表文件就可以了。XML 的自描述性能很好的表现许多复杂的数据关系,使得基于 XML 的应用程序可以在 XML 文件中准确高效地搜索相关的数据内容,忽略其它不相关部分。 (3) XML 是一种跨平台的语言。XML 可以作为公共的信息载体,在不同系统和平台 之间进行信息交流。 由于 XML 具有这些特征,自其发布以来,很快就成为一种数据表示和交换的标准格 式。在新一代 Web(Semantic Web)、文档处理以及内容管理系统(Content Management System)等应用中,XML 被越来越多地用作数据表示和存储的数据模型[11]。 2.2.1.2 SOAP 概述 SOAP(Simple Object Access Protocol )简单对象访问协议是在分散或分布式的环境 中交换信息的简单的协议,是一个基于 XML 的协议,它包括四个部分:SOAP 封装 (envelop),封装定义了一个描述消息中的内容是什么,是谁发送的,谁应当接受并处理它 以及如何处理它们的框架;SOAP 编码规则(encoding rules),用于表示应用程序需要使 用的数据类型的实例; SOAP RPC 表示(RPC representation),表示远程过程调用和应答的协 定;SOAP 绑定(binding),使用底层协议交换信息。 虽然这四个部分都作为 SOAP 的一部分,作为一个整体定义的,但他们在功能上是相 交的、彼此独立的。特别的,信封和编码规则是被定义在不同的 XML 命名空间(namespace) 中,这样使得定义更加简单。 SOAP 的两个主要设计目标是简单性和可扩展性。这就意味着有一些传统消息系统或 分布式对象系统中的某些性质将不是 SOAP 规范的一部分。比如:分布式垃圾收集 (Distributed garbage collection)、成批传送消息(Boxcarring or batching of messages)、对象引 用 (Objects-by-reference ( which requires distributed garbage collection ))、 对 象 激 活 (Activation(which requires objects-by-reference))。 W3C 联盟第一次召开的 Web 服务专题研讨会,探索了 W3C 应向哪个方向发展才能 实现新兴的 Web 服务架构的标准化,期间提出了一个"Web 服务堆栈"的构想,如下图, 从图中可以看出,SOAP 在 WEB 服务堆栈中作为用于 XML 消息传递的一种非常普遍的 协议,发挥着十分重要的作用。 基于 SCA 的 SOA 架构研究与应用 11 图 2-5 SOAP 在 WEB 服务堆栈中的作用 2.2.1.3 WSDL 概述 WSDL 是一种用 XML 语言来描述网络服务的语言。它对以下问题进行了明确的定 义:  数据交换模型(响应/请求、请求/响应、单向、多点广播等)  输入信息和输出信息的类型(面向文档/面向过程)  信息的大纲  错误信息 为了使 Web 服务的应用能够不断增长,非常重要的一点是,我们需要有一种结构化 可 理解的方法来描述 Web 服务,使得 Web 服务的描述信息能够被程序自动处理,这 是 Web 服务即时装配的基本保证。而 WSDL(Web Services Description Language)正是这 样的一种工具,它是一种类似 IDL 技术的服务描述语言。WSDL 定义了一套基于 XML 的 语法,将 Web 服务描述为能够进行消息交换的服务访问点的集合,从而满足了这种需 求。WSDL 文档将 Web 服务定义为服务访问点或端口的集合。在 WSDL 中,由于服务 访问点和消息的抽象定义已从具体的服务部署或数据格式绑定中分离出来,因此可以对抽 象定义进行重用。 WSDL Version 1.1 版详细规定了 WSDL 文档都有那些含义,以及如何编写出这类文 档。 Web 服务描述语言(WSDL)是 W3C 的一个 Note,WSDL 用 XML 格式将网络服 务定义为一组端点,这组端点是对包含面向文档或面向过程信息的消息进行操作的。这些 操作和消息的描述是抽象的,然后将它们绑定到具体的网络协议和消息格式以定义端点。 相关的具体端点都组合为抽象的端点服务。WSDL 可扩展来允许描述端点及其消息,而不 必考虑使用什么样的消息格式或网络协议来进行通信。这意味着使用 XML 模式来简要地 定义接口而后将这些接口绑定到适用于该协议的具体表示法。目前,在该文档中仅描述了 如何将 WSDL 和 SOAP1.1, HTTP GET/POST 以及 MIME 进行联合使用。 本科生毕业设计 ( 论文 ) 12 WSDL 是一种 XML Application,他将 Web 服务描述定义为一组服务访问点,客户 端可以通过这些服务访问点对包含面向文档信息或面向过程调用的服务进行访问(类似远 程过程调用)。WSDL 首先对访问的操作和访问时使用的请求/响应消息进行抽象描述,然 后将其绑定到具体的传输协议和消息格式上以最终定义具体部署的服务访问点。相关的具 体部署的服务访问点通过组合就成为抽象的 Web 服务。 在具体使用中,我们可以对 WSDL 进行扩展(类似 SOAP 的可扩展性),这样无论通 信时使用何种消息格式或网络协议,都可以对服务访问点及其使用的消息格式进行描述。 在 WSDL 的框架中,可以使用任意的消息格式和网络协议,如同 SOAP 中可以使用任意 的网络协议一样。在 WSDL 规范中,定义了如何使用 SOAP 消息格式、HTTP GET/POST 消息格式以及 MIME 格式来完成 Web 服务交互的规范。 2.2.1.3.1 WSDL Elements ·types: 描述将会使用的数据类型 ·message: 定义传入传出的消息格式 ·portType: 定义了一个入口的类型 (使用了怎样的 request/response 消息对) ·binding: 确定 portType 将会使用何种传输协议 (SOAP/HTTP-POST/…) ·port: 定义了一个关联某个 binding 的服务入口 ·service: 一组 port 组成的 Web Service 由于通信协议和消息格式在 Web 技术圈子里已经达到了标准化,我们知道在通常的 开发过程中,对于对象的 Interface 一定具备相应的 SDK 描述文档,Web 服务也是一种 对象,只不过它是被部署在 Web 上而已。很自然的,我们也完全需要有对 Web 服务这 个对象的界面的 SDK 描述文档。然而这两者又不尽相同,一来目前在 Web 上的应用已 经完全接受了 XML 这个基本的标准,基本上所有新出台的技术都是基于 XML 标准的, 二来 Web 服务目标是即时装配,松散耦合以及自动集成的,这意味着 SDK 描述文档应 当是具备被机器识别的能力的。 基于 SCA 的 SOA 架构研究与应用 13 图 2-6 WSDL 模型 也就是说,对于使用标准化的消息格式/通信协议的 Web 服务,它需要以某种结构化 的方式(即 XML)对 Web 服务的调用/通信加以描述,而且实现这一点也显得非常重要, 这是 Web 服务即时装配的基本保证。WSDL 正是这样一种描述语言,WSDL 定义了一套 基于 XML 的语法,将 Web 服务描述为能够进行消息交换的服务访问点的集合,从而满 足了这种需求。WSDL 服务定义为分布式系统提供了可机器识别的 SDK 文档,并且可用 于描述自动执行应用程序通信中所涉及的细节。 WSDL 模型,一个 WSDL 主要包括三部分(见上图):  抽象接口  协议绑定  具体服务访问端口 WSDL 文档将 Web 服务定义为服务访问点或端口的集合。在 WSDL 中,由于服务 访 问点和消息的抽象定义已从具体的服务部署或数据格式绑定中分离出来,因此可以对 抽象定 义进行再次使用:消息,指对交换数据的抽象描述;而端口类型,指操作的抽象集合。 用于 特定端口类型的具体协议和数据格式规范构成了可以再次使用的绑定。将 Web 访问 地址与 本科生毕业设计 ( 论文 ) 14 可再次使用的绑定相关联,可以定义一个端口,而端口的集合则定义为服务。因此, WSDL 文档在 Web 服务的定义中使用下列元素: Types - 数据类型定义的容器,它使用某种类型系统(一般地使用 XML Schema 中的类 型系统)。 Message - 通信消息的数据结构的抽象类型化定义。使用 Types 所定义的类型来定义 整个消息的数据结构。 Operation - 对服务中所支持的操作的抽象描述,一般单个 Operation 描述了一个访 问入口的请求/响应消息对。 PortType - 对于某个访问入口点类型所支持的操作的抽象集合,这些操作可以由一个 或多个服务访问点来支持。 Binding - 特定端口类型的具体协议和数据格式规范的绑定。 Port - 定义为协议/数据格式绑定与具体 Web 访问地址组合的单个服务访问点。 Service - 相关服务访问点的集合。 下图给出了 WSDL 文档的结构组织图: 图 2-7 WSDL 文档的结构组织图 代码说明: 基于 SCA 的 SOA 架构研究与应用 15 2.2.5 ESB 企业服务总线概述 企业服务总线( Enterprise Service Bus, ESB) 是面向服务构架( Service Oriented Architecture, SOA) 的基础设施。目的是集成异构平台的应用( 不同硬件、不同操作系统、 不同数据库、不同编程语言实现的软件等) , 为 SOA 提供服务的交互通信、协作和组合的 基于网络的分布式总线。 ESB 是一个松散耦合的、分布式的、事件驱动的企业级 SOA, 一个 ESB 是预先组装 的 SOA 实现, 包含实现 SOA 分层目标所必需的基础功能部件。ESB 是传统中间件技术 与 XML、Web 服务等相结合的产物。ESB 提供了开放的、基于标准的消息机制, 通过标 准适配器和接口, 提供应用服务与其他组件之间的互操作, 能满足大型企业异构环境的集 成需求。 本科生毕业设计 ( 论文 ) 16 ESB 的基本原理是: 通过标准的整合技术, 将 SOA、WebServices 和 XML 等技术融 合到统一的分布式架构中, 搭建易于部署、可管理的整合基础设施。它既可集成新的应用 服务, 也可通过分解、包装遗留系统, 使其提供服务接口, 从而集成已有的应用。ESB 还 提供了连接企业内部和跨企业间的新的和现有软件应用系统的功能, 通过集成松散耦合 的、平台独立的服务接口, ESB 充当了服务使用者和服务提供者之间的中介, 实现服务组 合和业务流程自动化管理。 2.3 SOA 与 Web Services 的关系 SOA 把一个应用程序的业务逻辑(business logic),或某些单独的功能模块化,并封 装为服务呈现给消费者或客户端。它提倡松耦合 loosely-coupling。 SOA 是一种分布式系 统的设计模式,是一种体系架构的设计风格。而 Web service 是一种实现分布式系统的技术, 它是一个技术,规范的集合。SOA 不一定用 Web service 来实现 Web 服务是技术规范,而 SOA 是设计原则。特别是 Web 服务中的 WSDL,是一个 SOA 配套的接口定义标准:这是 Web Services 与 SOA 的根本联系。从本质上来说,SOA 是一 种架构模式,而 Web Services 是利用一组标准实现的服务。Web Services 是实现 SOA 的方 式之一。用 Web 服务实现 SOA 的优势在于可以实现一个独立平台,来获得服务,而且随 着 Web Services 规范得到更多的支持,平台也会更具有通用性。 2.4 SOA 服务设计原则 通常,一种体系结构范式,包括设计原则,来自实践的结构式样、组成要素和关系, 以及在整个开发生命周期中它们是如何被识别、描述和控制的。体系结构从过去单个应用 包罗一切的客户/服务器的模式,逐渐演变到三层和多层结构的各种分布式计算模式。 SOA 架构中,继承了来自对象和组件设计的各种原则,如封装、自我包含等。保证服 务的灵活性、松散耦合和重用能力的设计原则,对 SOA 架构来说同样重要。 结构上,服务总线是 SOA 的架构模式之一。 关于服务,一些常见和讨论的设计原则如下: 1. 无状态。以避免服务请求者依赖于服务提供者的状态。 2. 单一实例。避免功能冗余。 3. 明确定义的接口。服务的接口由 WSDL 定义,用于指明服务的公共接口与其内部 专用实现之间的界线。WS-Policy 用于描述服务规约,XML 模式(Schema)用于定 义所交换的消息格式(即服务的公共数据)。使用者依赖服务规约来调用服务,所以 服务定义必须长时间稳定,一旦公布,不随意更改;服务的定义应尽可能明确,减 少使用者的不适当使用;不要让使用者看到服务内部的私有数据。 基于 SCA 的 SOA 架构研究与应用 17 4. 自包含和模块化。服务封装了那些在业务上稳定、重复出现的活动和组件,实现 服务的功能实体是完全独立自主的,独立进行部署、版本控制、自我管理和恢复。 5. 粗粒度。服务数量不应该太大,依靠消息交互而不是远程过程调用(RPC),通常消 息量比较大,但是服务之间的交互频度较低。 6. 服务之间的松耦合性。服务使用者看到的是服务的接口,其位置、实现技术、当 前状态等对使用者是不可见的,服务私有数据对服务使用者是不可见的。 7. 重用能力。服务应该是可以重用的。 8. 互操作性、兼容和策略声明。为了确保服务规约的全面和明确,策略成为一个越 来越重要的方面。这可以是技术相关的内容,比如一个服务对安全性方面的要求; 也可以是跟业务有关的语义方面的内容,比如需要满足的费用或者服务级别方面 的要求,这些策略对于服务在交互时是非常重要的。WS- Policy 用于定义可配置 的互操作语义,来描述特定服务的期望、控制其行为。在设计时,应该利用策略 声明确保服务期望和语义兼容性方面的完整和明确。 图 2-8 IBM SOA 架构概念模式 2.5 本章小结 在本章中,主要介绍了 SOA 的相关概念,体系结构,同时论述了 SOA 体系结构中重 要的基础技术,如 Web Services,XML,SOAP,WSDL,ESB。最后阐述了 SOA 与 Web Services 的关系以及指出了 SOA 设计中要注意的原则。 本科生毕业设计 ( 论文 ) 18 第 3 章 SOA 编程模型——SCA 3.1 SCA 的起源 SCA 作为服务整合的技术,其出现并不唐突。为了更好地理解这一点,需要理清服务 整合技术的渊源,或者说技术的背景。理清服务整合技术的背景,不仅可以增加饭后的谈 资,还可以由此看清技术将来的发展方向。 从 Web 服务的兴起,到 Web 服务调用框架(Web Service Invocation Framework,WSIF) 昙花一现,再到 SCA 的提出,可以很清晰地看出服务整合技术发展大致趋势:强调粗粒度、 松耦合,正视异构的 IT 现状,贯彻实现与业务分离的原则[1]。 3.1.1 Web 服务的兴起 在 2000 年,简单对象访问协议(Simple Object Access Protocol,SOAP)被提出,用 来实现分布式计算中数据的统一。其基本思想是将输入输出参数序列化为 XML 进行传输, 再反序列化成本地数据类型进行操作。SOAP 基于 XML,而 XML 是语言无关的。这使不 同操作系统、不同语言的数据交互成为可能。Web 服务正是使用 SOAP 作为标准化通讯协 议,从而做到能在分布式运算的环境里,发布与语言无关,操作系统无关的服务。 Web 服务接口描述规范(Web Service Definition Language,WSDL)也是基于 XML 的。 WSDL 描述服务交互需要的全部信息,包括消息描述(服务操作、输入、输出、异常), 位置和传输协议,同时隐藏了服务实现的细节。由此 Web 服务拥有了松耦合、分布式和跨 平台的特性。 Web 服务提供者(Service Provider)使用 WSDL 定义 Web 服务描述,然后发布到 Web 服务中介(Service Broker),Web 服务使用者(Service Requester)通过 Web 服务中介获 得服务描述,进一步使用它来访问 Web 服务。 一般 Web 服务中介使用通用描述和发现接口规范(Universal Description and Discovery Interface,UDDI)。UDDI 是一个跨产业、跨平台的开放性架构,可以帮助 Web 服务提供 者在网上发布 Web 服务信息,同时也供 Web 服务使用者发现服务。 尽管 Web 服务使用 WSDL 统一了服务接口的描述,使用 SOAP 统一了数据传输和 交换的格式,但其缺少一个数据的模型——这成为 SDO 提出的契机。另外 Web 服务缺少 一个统一的调用模型,统一调用包括统一调用 Web 服务和其他类型的服务,比如 RMI 和 CORBA 服务——这是 Web 服务调用框架(Web Service Invocation Framework,WSIF)致 力解决的问题。另外 Web 服务没有设计如何去构建 Web 服务以及如何构建其他类型服务 基于 SCA 的 SOA 架构研究与应用 19 的问题,解决这些问题恰恰是 SCA 的使命之一[1]。 3.1.2 Web 服务调用框架的任务 Web 服务调用框架(Web Service Invocation Framework,WSIF)提出的目的是解决 Web 服务的调用问题。Web 服务的描述是一个 WSDL 定义的 XML 文件,描述接口服务的 操作、输入、输出、异常、位置和传输协议。WSIF 认为,服务接口描述属于业务逻辑的 范畴,是服务使用者应该关心的,而 Web 服务的位置和具体的传输协议应属于技术范畴。 WSIF 将服务接口描述和服务传输协议解耦,统一服务调用为 Web 服务调用,重用现 有服务。这些比 Web 服务更进了一步,但 WSIF 仍然没有一个好的数据模型,也不提供服 务的构建支持。在这些经验教训的基础之上,SCA 最终被提出了[1]。 3.1.3 SCA 的提出 服务组件架构(Service Component Architecture,SCA)是一个用于服务调用和构建的、 与实现语言无关的组件编程构架。SCA 提供了统一的调用方式,可以把不同类型的服务, 比如 POJO、EJB、BPEL、JMS、Web 服务等都通过统一的方式调用。这一点来自 WSIF 的理念。SCA 还提供了一个基于组件的构建模型,可以使其他不同种类的服务,比如 EJB、 JMS、Web 服务等使用统一的方式来构建。这一点弥补了 WSIF 与 Web 服务的不足。SCA 没有提出自己的数据模型。但与 SCA 相伴而生的伙伴,服务数据对象(Service Data Objects, SDO)提出了一个用于服务的数据模型。在此之上,SCA 还提供了许多面向企业业务运算 所要求的服务质量保障(Qualify of Service,QoS)能力。 前面提到的 SCA 特性,使得企业应用具有良好的分层架构,能够很好地分离业务逻辑 和技术逻辑,使应用易于构建、易于部署、易于变更。这些特性,恰恰是 SOA 的需求。 SCA 最早由 IBM 提出并实现在其旗舰产品 WPS(Webshpere Process Server)中。在获得 客户的好评之后,IBM 与 BEA 等将 SCA 提交为一个规范,并将 SCA 的实现代码,命名 为 Tuscany 捐献给 Apache 开源社区[1]。 3.2 本章小结 Web 服务使异构系统的交互成为可能。Web 服务调用框架使其他类型服务的调用方式 统一为 Web 服务调用。SCA 继承并发扬了 WSIF 的思想,推出服务组件架构,将其他类型 服务的构建也统一在服务组件架构下。可见其技术思想是一脉相承的。SCA 主要特性在 SCA 的 WPS 实现里已经显现。从 SCA 正式推出这段历史还可以看出,SCA 是包容性的技 术而非侵略性的技术。SCA 不是为了代替别的技术而生,而是致力于克服技术之间交互操 作的困难。SCA 不是新造轮子,而是使现有的轮子转运得更流畅。 本科生毕业设计 ( 论文 ) 20 第 4 章 基于 SCA 的 SOA 架构设计 4.1 Apache Tuscany SCA 简介 Tuscany 是 Apache 的开源项目,它是 IBM、Oracle、SAP 等厂商联合成立的 SOA 标 准化组织 -OSOA 支持下开发出的 SCA 框架,它既是开源界 SCA 的试金石,也是当前 开源界最成熟的 SCA 框架之一。 图 4-1 为 Tuscany 的基本架构图,从图中可以看出,作为一个轻量级 SCA 框架, Tuscany 提供了非常松散耦合的框架结构。主要有以下几个特点: 1. Tuscany 是平台无关的可嵌入框架,可以在各种 Hosting Platform 上运行,如 Tomcat,JBoss,WAS 等 Web 容器上运行,也可以在 J2SE 环境下运行。 2. Tuscany 的核心模块提供了 SCA 规范的 API 实现,Tuscany 系统的 SPI 接口, 一些系统基本实现(如事件,工厂类,存储等),以及一整套扩展机制,这些扩 展机制为 Tuscany 整合各个平台的服务提供了基础。 3. Tuscany 的扩展是完全松散耦合的,框架本身提供了大量的扩展实现,用户也可 以在自己的系统中扩展 Tuscany 的实现,只需要遵循 Tuscany 的扩展规范以及 API 接口。 基于 SCA 的 SOA 架构研究与应用 21 图 4-1 Tuscany 基本架构图 Tuscany 主要有以下几个方面的扩展: 1. Implementation:SCA 组件(Component)的实现方式,一个 SCA 组件可以由各 种语言或技术平台实现,如:POJO,EJB,Spring Bean,bpel 流程,各种脚本语 言等等。 2. Binding:是 SCA 的绑定(Binding)规范的实现,SCA 服务(Service)和引用 (Reference)的绑定方式,即一个 SCA 服务可以暴露为 Web Service,Java RMI 服务,http 资源,jms 消息等等,一个 SCA 引用也可以通过 Web Service,RMI 调用,http 调用,jms 调用等方式调用远端服务。 3. Databinding:数据绑定方式,这是 Tuscany 提出的概念,一般用与在 Binding 中 定义参数的传输格式,比如 Web Service 的 Binding 一般用 XML 格式,SCA 的 Binding 一般用 SDO 格式,Jsonrpc 的 Binding 一般用 Json 格式等等。 4. Interface:是 SCA 的接口(Interface)规范的实现,SCA 服务(Service)和引用 (Reference)的接口暴露方式,一般有 Java,WSDL 等类型。 本科生毕业设计 ( 论文 ) 22 4.2 使用 SCA 开发 SOA 应用 使用 SCA 构建 SOA 应用系统分为四个步骤: 1. 设计服务组件接口 2. 实现组件的业务逻辑 3. 组装 SCA 复合集 4. 客户端调用 4.2.1 设计服务组件接口 SCA(Service Component Architecture)是一种规范, 它的核心概念是服务及其相关实 现。开发人员不必再考虑使用何种语言或者何种技术,目前,SCA 映射已经存在于 Java, C++,Ruby,Spring,和 BPEL 及其他语言中。 以 Java POJO 为例,服务的接口与 Java POJO 的接口完全一致,如果该接口是远程接 口,则添加@Remotable 注解。SCA 基于接口的编程模型提供了系统以及业务流程的松散 耦合结构。如下代码所示: import org.osoa.sca.annotations.Remotable; /** * The Calculator service interface. */ @Remotable public interface CalculatorService { double add(double n1, double n2); double subtract(double n1, double n2); double multiply(double n1, double n2); double divide(double n1, double n2); } 基于 SCA 的 SOA 架构研究与应用 23 4.2.2 实现组件的业务逻辑 SCA 的 Java 实现规范中,实现服务组件的业务逻辑代码跟 Java POJO 接口的实现是一 致的。组件实现中需要引用其他组件或者服务时,使用@Reference 注解制定,如下代码所 示: import org.osoa.sca.annotations.Reference; /** * An implementation of the Calculator service. */ public class CalculatorServiceImpl implements CalculatorService { private AddService addService; private SubtractService subtractService; private MultiplyService multiplyService; private DivideService divideService; @Reference public void setAddService(AddService addService) { this.addService = addService; } @Reference public void setSubtractService(SubtractService subtractService) { this.subtractService = subtractService; } @Reference public void setDivideService(DivideService divideService) { this.divideService = divideService; } @Reference public void setMultiplyService(MultiplyService multiplyService) { this.multiplyService = multiplyService; 本科生毕业设计 ( 论文 ) 24 } } 4.2.3 装配 SCA 复合集 装配一个组合业务应用程序的过程,在此过程中配置并连接提供服务实现的组件。SCA 装配在两个层次进行: 1. 模块内松散连接的组件的组装 SCA 模块 是一起开发和部署到 SCA 系统 的最大紧密耦合组件。它是 SCA 系 统内的松散耦合组合的基本单元。SCA 模块包含一系列组件、外部服务、入口点,以 及用于衔接这些部分的机制。模块向 SCA 系统提供服务实现。 入口点 定义模块提供的公共服务,此服务可以由同一模块内的其他组件使用,也 可以在模块外使用。入口点用于使用特定的绑定 发布模块提供的服务。 模块内的外部服务 表示其他模块提供的远程服务。它们位于使用此服务的 SCA 模块之外。组件可以像访问 SCA 组件提供的任何服务一样访问这些外部服务。外部 服务使用绑定来描述对外部服务的访问。 外部服务的接口必须为可远程访问的。 2. 系统内松散连接的组件的组装 在 SCA 系统 中,SCA 系统 用于聚合那些提供了相关业务功能的模块。这是通 过配置和管理模块组件、外部服务、入口点,以及连接机制来完成的。SCA 系统的配 置由所有部署到其中的子系统的组合加以表示。图 4-2 是系统组装的一个示例;它说 明了如何使用服务和引用连接各个子系统和模块。 图 4-2 SCA 系统装配 基于 SCA 的 SOA 架构研究与应用 25 如上图可以分析得到: 1. 子系统配置中的模块组件表示 SCA 模块的一个已配置实例,模块组件可以在其 中为模块的外部服务设置值,并能够为模块公开的属性设置值。 2. 外部服务是位于使用服务的 SCA 系统外部的远程服务。模块级别的外部服务与 系统级别的外部服务的不同之处包括: a) 子系统中没有与模块组件具有相同名称的外部服务,因为它们都可能成为连 接机制的目标。 b) 子系统中没有与模块组件具有相同名称的外部服务,因为它们都可能成为连 接机制的目标。 3. 入口点用于声明可外部访问的子系统服务。它们由其他组装或客户作为 Web 服 务使用。模块级别的入口点和系统级别的入口点的不同之处包括: a) 名称必须在子系统内定义的所有入口点中保持唯一性。子系统内不能存在与 模块组件同名的入口点。 b) 引用子元素的指定是可选的,因为可以通过另一个子系统提供的连接机制进 行连接。 SCA 组件之间的调用关系在一个相关的配置文件中描述,这个配置文件的后缀名 为.composite。该文件为 XML 格式,配置语言称为 SCDL(全称:Service Component Definition Language――服务组件定义语言)。SCDL 来描述构件所包含的组件,同时指定他们彼此 之间的相关性。上述代码示例所表示的组件的 SCDL 文件如下: 本科生毕业设计 ( 论文 ) 26 图 4-3 组件视图 该 SCDL 设置组件的名称为 CalculatorServiceComponent ,指出其实现类为 CalculatorServiceImpl。通过 reference 标记设置 CalculatorServiceComponent 组件需要引用 的服务组件 AddServiceComponent、SubtractServiceComponent、MultiplyServiceComponent、 DivideServiceComponent。可见,在 Java POJO 接口的实现中,通过@Reference 标记指出 基于 SCA 的 SOA 架构研究与应用 27 的引用类,在组件装配文件中,对应 reference 标签指明其具体实现类的位置。运行时,SCA Running Time 会通过依赖注入的方式,把@Reference 标签所引用的组件,用 reference 标 签所指向的组件或服务进行赋值。 4.3 Tuscany SCA 与 Spring 的互访能力 4.3.1 Spring Framework 简介 通常称作 Spring,它是一个尝试通过解决企业应用程序开发的复杂性来提高 J2EE 环 境适用性的开源项目。Spring 的一个优势在于它的分层架构。它允许开发人员选择所使用 的组件,同时为 J2EE 应用程序开发提供了一个紧密结合的框架。Spring 为简单的 Java 对象提供了一个框架,从而使它们能够通过包装器类和 XML 配置来使用 J2EE 容器。 Spring 的目标是,通过提高开发生产力和运行时性能,让项目从中获得巨大的好处,并改 善测试范围和应用程序质量。 4.3.2 SCA 与 Spring 两者相结合的优势 Spring Framework 与 SCA 采用许多相同的设计原则。SCA 将 Spring 视为其组件的 一种实现技术。SCA Spring Component Implementation Specification 定义了如何采用这种方 式来使用 Spring。 与 Spring bean 类似,SCA 组件可以包含到其他组件所提供的服务的引用,并且有一 些属性可供配置。与 Spring 形成对比的是,SCA 是一种跨语言的分布式组件架构,它支 持多种组件通信机制。通过将 Spring beans 发布为可由其他组件访问的服务并为 Spring beans 提供关联到其他(可能为远程)组件的服务的引用,SCA 可以扩展 Spring 组件的 功能。 SCA 与 Spring 相结合的一种有效的方法是使用 Spring 来构建 “粗粒度” 的服务 组件实现,并引入到 SCA 中以便公开服务、关联服务组件以及处理异构和分布式系统。 SCA 可以在使用 Spring 实现的应用程序中添加一些有用的功能,如: 1. 对远程组件以及多种协议的扩展支持 2. 支持使用不受 JVM 支持的各种编程语言来编写组件 3. 支持 WS-Policy 针对安全性和事务等活动指定的策略 此外,易于测试组件是 Spring 的一项优异的特性。缺少 API 和注入技术导致您只能 使用简单的模拟对象进行测试。SCA 在服务方面对此进行了补充,因为关于服务组件的 SCA 复合集可以方便地切换到模拟配置以进行测试。 本科生毕业设计 ( 论文 ) 28 4.3.3 将 Spring 应用程序定义为 SCA 组件 在 Apache Tuscany SCA 实现中,SCA 使用 Spring 作为其组件在 SCA 复合集中的 实现技术。可以将 Spring 应用程序定义为 SCA 复合集中的 SCA 组件,即 SCDL,其 格式如下所示。 其中 元素的位置属性可以指定目标 URI 指向某个存档文件 (.jar) 或 目标,或者 直接指向 Spring 应用程序上下文。 4.3.4 基于 Spring 的 SCA 组件 组件实现的业务功能将由其他组件作为服务 提供。实现可以依赖其他组件提供的服 务;这些依赖关系被称作引用。实现可以有可设置的属性,即影响业务功能运转的数据值。 下面的例子展示了如何将 Spring beans 提供为 SCA 服务,以及如何在您的 Spring 应用 程序上下文中配置 SCA 引用和 SCA 属性。 以图 4-3 中的 CalculatorComponent 为例。它需要依赖其他组件(AddComponent、 SubtractComponent、MultiplyComponent 和 DivideComponent)来实现所需的功能。其中, CalculatorComponent 的业务功能是使用 Spring beans 实现的,AddComponent 是使用 JavaScript 实现的,SubtractComponent 和 MultiplyComponent 是使用简单 POJO 实现的, 而 DivideComponent 是使用 Groovy 脚本实现的。 基于 SCA 的 SOA 架构研究与应用 29 图 4-4 基于 Spring 的 CalculatorComponent 对应的 SCDL 如下: 本科生毕业设计 ( 论文 ) 30 CalculatorComponent 是一个 Spring 应用程序,它使用 Spring beans 定义了业务逻辑。 需要在 Spring 应用程序上下文定义文件中声明所需的 SCA 依赖关系。通过创建 Spring 应用程序上下文定义文件。通过声明实现所需功能需要的 beans 以及它们的依赖关系,来 提供 CalculatorComponent 的业务逻辑。如下代码所示: 元素声明此应用程序上下文对由复合集中其他可用的 SCA 组件提供 的服务的依赖关系。在上例中,calculator bean 依赖于 SCA 服务,比如 AddComponent、 SubtractComponent 、 MultiplyComponent 和 DivideComponent 。这些依赖关系使 用 元素进行声明。此元素的必需 name 属 性 拥 有 的 值 应 该 与 在 calculator.composite 中为 CalculatorComponent 定义的 元素的名称相同。必需 本科生毕业设计 ( 论文 ) 32 的 type 属性应该将服务的类型声明为一个 Java 类 的 完 全 限 定 名 。 对 于 calculator.composite 的 CalculatorComponent 中的每个 元素,会在 Spring 应用 程序上下文中声明一个等效的 元素。 4.4 SCA 的调用方式 在 SCA 中,调用方式分为同步调用方式和异步调用方式。同步调用方式指 的是客户端发起请求后,一直等待服务端服务返回结果,在此期间客户端一直 处于等待状态,不能进行其他的操作,因此耗费的时间较长,效率较低。异步 调用的方式指的是客户端发送请求后,在等待服务端返回结果的同时,可以继 续进行其他操作,当服务端完成操作后,可以通过回调等方式告知客户端。在 SCA 中的异步调用有三种方式。 单向调用 单向调用指的是客户端发出请求之后就不再关心服务端的情况,包括是否 执行成功,返回值是什么,继续按照客户端原本的执行顺序进行操作。在 Tuscany SCA 中,要标注某个方法为单向调用,可以在该方法前加入注释标记@OneWay, 并且该方法规定不能有任何的返回值,包括不能抛出异常。 延迟响应 延迟响应方式是指客户端在发出调用请求之后,获得一个票据,然后继续 执行,经过一段时间之后,客户端再调用相应的方法去检索服务端服务所返回 的结果根据调用的结果而执行进一步动作。 请求回调 请求回调方式指的是客户端在发出请求后,可以继续原有的工作流程,当 服务端的服务完成后,通过回调机制,由服务端主动调用客户端的方法以告知 返回的结果。这与普通编程语言中的请求回调机制有相似之处。 4.5 设计开发 jBPM 工作流组件 4.5.1 scawsp 架构分层描述 4.5.1.1 基础中间件平台 4.5.1.1.1 jBoss JBoss 是目前业界第一的最成熟完整的开源 J2EE 应用服务器,完全支持 J2EE 5 规范 基于 SCA 的 SOA 架构研究与应用 33 的所有特性,同时具备如下优秀特质: 1. 它将具有革命性的 JMX 微内核服务作为其总线结构;这使得我们可为其定制化; 2. 它自身提供了完整的事务支持能力,这是保障业务系统正确运行的关键技术; 3. 它本身就是面向服务的架构(Service-Oriented Architecture,SOA); 同时 JBoss 扩展了 J2EE 规范,提供了大量扩展特性,如下: 1. BPM 支持,内嵌了 jBPM,提供了 BPM 工作流引擎,其 PVM 支持 jPDL 和 WS-BPEL; 2. RuleEngine 支持,内嵌了 JBossRule(Drools),当前开源最成熟的规则引擎; 3. ESB 支持,内嵌了 JBossESB,提供企业服务总线支持; 4. CXF 支持,内嵌了 CXF,提供 Web 服务; 此外,JBoss 包括其扩展特性还提供了同 Spring 的集成支持。本平台采用 jBoss5.0.0GA。 4.5.1.1.2 Spring Framework Spring 的依赖注入特性决定了几乎所有的开发工具与产品都能与之实现代码级、组件 级别的集成。由于 Spring 的强大的功能以及开放性,业已成为 J2EE 开发的事实标准,大 量的第三方都提供同 Spring 的集成,这大大提高了开发能力和效率,几乎所有的 J2EE 开 源框架都提供了与 Spring 的集成能力,例如:JBoss、CXF 官方就提供了同 Spring 集成能 力。同时 Spring 作为 SCA 规范中重要的服务实现模型。 4.5.1.2 集成层 4.5.1.2.1 Web Services Apache Axis2 是一套崭新的 WebService 引擎,该版本是对 Axis1.x 重新设计的产物。 Axis2 是广泛使用 Apache Axis 栈的成功典范,不仅支持 SOAP1.1 和 SOAP1.2,还集成了 非常流行的 REST WebService,同时还支持 Spring、JSON 等技术。 4.5.1.2.2 RMI RMI 是 Java 本身提供的一种远程通信协议,稳定高效,性能高。但它只用于 Java 程 序之间的通讯。 RMI 是基于 Tuscany 实现的 SCA 组件的一种默认 binding 方式,在编程时无需额外关 注,只需要配置 binding.rmi 即可。 Tuscany 在运行时自动为所有 binding.rmi 的接口及实现,通过 cglib 的方式动态生成 本科生毕业设计 ( 论文 ) 34 Remote 对象。 4.5.1.3 服务层 4.5.1.3.1 数据访问层 数据库访问,采用 Hibernate 作为统一的持久框架。 采用 Hibernate 作为平台持久层框架的原因有: 1. ORM 特性 Hibernate 是一个开放源代码的对象关系映射框架,它对 JDBC 进行了非常轻量级的对 象封装,使得进行领域驱动设计和开发成为可能,大大提高了开发效率。Hibernate 屏蔽了 底层数据库的差异,通过 Hibernate 可以容易在不同数据库间进行迁移,而不改程序。 Hibernate 同时也是 EJB3 的 JPA 规范的开源实现。ORM 特性使得程序员不必象以往过度 的去关注 SQL 脚本。 2. 应用的普遍性 Hibernate 得到大多数开源厂商的支持,在传统开源工具的数据访问上很多都使用 Hibernate 做为数据持久化工具。例如,JBPM(工作流产品)。另外,Hibernate 的社区非 常繁荣,而同属于 ORM 框架的 IBATIS 则相对平静。对于开源世界的“大鳄”—JBoss,因 为 Hibernate 是其旗下产品,所以 Jboss 的所有项目的持久层都采用的 hibernate。 3. Jboss 的 EJB3 实现中 JPA 的底层就采用了 Hibernate。 4.5.1.3.2 与 Spring 集成 采用了 Spring 提供 Hibernate 集成,优点: 1. 简化 Hibernate 配置,通过 spring ioc 方式简化 hiberante 配置,方便多种环境切换; 2. 集成事务管理,spring 提供了同其事务管理相配套的 Hibernate 实现;并一定程度 上支持同其它事务实现机制混合使用; 3. 提供了简化的 API,hibernate 原生的 API 操作复杂,重复代码多且容易出错,采 用 spring 提供的 API 操作简便,不会出错; 4.5.2 jBPM SCA 服务组件配置 4.5.2.1 服务组件粒度划分原则 jBPM 即 java Business Process Management,是 基于 JBoss+EJB 的工作流引擎。 jBPM 是 tom baeyens 编写的一个灵活可扩展的工作流管理系统。jBPM 引擎底层基于 Active 基于 SCA 的 SOA 架构研究与应用 35 Diagram 模型,作为 jBoss 的一个子项目,它使用了 hibernate,因此可以很好的支持主流数 据库。jBPM 将工作流应用开发的便利性和杰出的企业应用集成(EAI)能力结合了起来。 jBPM 包括一个 Web 应用程序和一个日程安排程序。jBPM 是一组 J2SE 组件,可以作为 J2EE 应用集群部署。 因此将 jBPM 整个子系统作为一个服务组件。配置组件复合集的时候,根据流程中的 任务类型再进行细粒度划分,如部署流程定义,开始流程,下一个流程,驳回流程,结束 流程等,代码如下: 本科生毕业设计 ( 论文 ) 36 将 jBPM 工作流引擎定义为一个服务组件 jBPMComponent,jBPMComponent 依赖于 发 布 流 程 实 例 服 务 组 件 AddProcessInstanceComponent 、删除流程定义服务组件 DelProcessDefinitionComponent、删除流程实例服务组件 DelProcessInstanceComponent、执 行到下一个流程节点服务组件 NextStepComponent、查找下一可执行流程节点服务组件 SearchNextTransitionsComponent 等,其中 jBPMComponent 使用 元素明确发布为 Web Service。 4.5.2 组件部署文件 组件部署文件 META-INF/sca-contribution.xml 代码如下: 基于 SCA 的 SOA 架构研究与应用 37 命名空间要同组件定义文件(jBPM.composite)所采用的命名空间一致,见红色字体。 Web 服务器启动时自动加载该组件部署文件。 4.5.3 Spring 实现 jBPM 服务组件复合集 4.5.3.1 jBPM 与 Spring 集成 集成 Spring 与 jBPM 需要用到第三方的类库:spring-modules-0.8.zip。集成的方法是:将 JbpmConfiguration 对象交给 Spring 创建,因此需要在 Spring 配置文件里面配置 JbpmConfiguration 对象 的创建: 此时,需要拷贝 jbpm.cfg.xml 到类路径下。 4.5.3.2 jBPM 实现业务逻辑类 当实现业务逻辑时,使用 jbpmConfiguration 对象的时候,由 Spring 注入,此时为使 jBPM 的数据 库操作与 Hibernate 的 session 同处于一个事务当中,需要将 JbpmContext 内部的 Hibernate session 对象 设置成 Spring 管理的 hibernate session 对象: private JbpmContext getJbpmContext(){ JbpmContext context = jbpmConfiguration.createJbpmContext(); context.setSession(getSession()); return context; } 4.5.3.3 Spring 完整配置文件 Spring 应用程序上下文配置 applicationContext.xml 代码如下: 本科生毕业设计 ( 论文 ) 38 classpath:hibernate.cfg.xml 基于 SCA 的 SOA 架构研究与应用 39 本科生毕业设计 ( 论文 ) 40 基于 SCA 的 SOA 架构研究与应用 41 元素声明提供 jBPMService 作为来自目标 JbpmServiceBean bean 的 SCA 服务。必需的 name 属性拥有的值应该与在 jBPM.composite 中为 jBPMComponent 定义的 元素的名称相同。必需的 type 属性应该将服务类型声明为一个 Java 类的完全限定名。必需的 target 属性应该拥有应用程序上下文中的一个 元素 的名称,该元素提供由此 元素声明的服务。 元素声明此应用程序上下文对由复合集中其他可用的 SCA 组件提 供的服务的依赖关系。在本示例中,JbpmServiceBean bean 依赖于 SCA 服务,比如 发布 流 程 实 例 服 务 组 件 AddProcessInstanceComponent 、删除流程定义服务组件 DelProcessDefinitionComponent、删除流程实例服务组件 DelProcessInstanceComponent、执 行到下一个流程节点服务组件 NextStepComponent、查找下一可执行流程节点服务组件 SearchNextTransitionsComponent 等。这些依赖关系使用 元素进行声明。 此元素的必需 name 属性拥有的值应该与在 jBPM.composite 中为 jBPMComponent 定义 的 元素的名称相同。必需的 type 属性应该将服务的类型声明为一个 Java 类的完全限定名。对于 jBPM.composite 的 jBPMComponent 中的每个 元素, 会在 Spring 应用程序上下文中声明一个等效的 元素。 4.5.4 程序和配置实例 以删除流程定义服务组件为例。DelProcessDefinitionService 首先是一个面向接口的 Java 应用,包 含一个普通接口及其实现。 接口定义如下: package com.osoa.component.jbpm.component; import org.jbpm.JbpmContext; import org.osoa.sca.annotations.Remotable; @Remotable public interface DelProcessDefinitionService { 本科生毕业设计 ( 论文 ) 42 /** * delete process definition * @param processName */ public void delProcessDefinition(String processName); } 接口实现类如下: package com.osoa.component.jbpm.component; import java.util.Iterator; import java.util.List; import org.jbpm.JbpmConfiguration; import org.jbpm.JbpmContext; import org.jbpm.graph.def.ProcessDefinition; import org.osoa.sca.annotations.Service; import org.springframework.orm.hibernate3.support.HibernateDaoSupport; @Service(DelProcessDefinitionService.class) public class DelProcessDefinitionServiceImpl extends HibernateDaoSupport implements DelProcessDefinitionService { private JbpmConfiguration jbpmConfiguration; private JbpmContext getJbpmContext(){ JbpmContext context = jbpmConfiguration.createJbpmContext(); context.setSession(getSession()); return context; } public void setJbpmConfiguration(JbpmConfiguration jbpmConfiguration) { this.jbpmConfiguration = jbpmConfiguration; } 基于 SCA 的 SOA 架构研究与应用 43 public void delProcessDefinition(String processName) { JbpmContext context = getJbpmContext(); List defs = context.getGraphSession().findAllProcessDefinitionVersions(processName) ; for (Iterator iterator = defs.iterator(); iterator.hasNext();) { ProcessDefinition def = (ProcessDefinition) iterator.next(); context.getGraphSession().deleteProcessDefinition(def); } } } 4.5.5 数据访问层 Hibernate 配置 hibernate.xml 配置如下: com.mysql.jdbc.Driver root org.hibernate.dialect.MySQLDialect true update org.hibernate.cache.HashtableCach eProvider 基于 SCA 的 SOA 架构研究与应用 45 本科生毕业设计 ( 论文 ) 46 基于 SCA 的 SOA 架构研究与应用 47 4.5.6 工程配置 web.xml 代码如下: jBPMServices contextConfigLocation classpath:applicationContext.xml tuscany org.apache.tuscany.sca.host.webapp.TuscanyServletFilter< /filter-class> tuscany /* org.springframework.web.context.ContextLoaderListener< /listener-class> web.xml 需配置 TuscanyServletFilter 过滤器,客户端访问 jBPMService 的时候,服务 器端此处的配置 TuscanyServletFilter 过滤器。 4.5.6 组件运行效果 WSDL: 基于 SCA 的 SOA 架构研究与应用 49 本科生毕业设计 ( 论文 ) 50 基于 SCA 的 SOA 架构研究与应用 51 本科生毕业设计 ( 论文 ) 52 基于 SCA 的 SOA 架构研究与应用 53 本科生毕业设计 ( 论文 ) 54 基于 SCA 的 SOA 架构研究与应用 55 本科生毕业设计 ( 论文 ) 56 SoapUI 测试结果: 基于 SCA 的 SOA 架构研究与应用 57 图 4-5 soapui 测试结果 系统处理流程如下: HTTP SOAP  Axis WebService  Tuscany  Spring  jBPMServices 4.6 本章小结 本章首先介绍了 SCA 开源实现 Apache Tuscany SCA 的相关情况,接着分别介绍了如 何使用 SCA 开发 SOA 应用程序的一般步骤,以及 SCA 对 Spring 的支持和 SCA 的调用方 式。 SCA 和 Spring 能够构成一个强大的组合。Spring 提供了基础设施来开发具有更高效 率和运行时性能的组件,还改进了测试覆盖率和应用程序质量。SCA 提供了必要的基础设 施来组装和建模基于 SOA 的组件,支持组件公开服务,将服务组件连接在一起,以及处 理异构的分布式系统。 本科生毕业设计 ( 论文 ) 58 第 5 章基于 SOA 的企业应用系统设计方法 在本文的前几部分,系统论述了 SOA 的基础理论和体系架构,分别介绍了目前 SOA 技术体系中重要组成部分 SEA 编程模型的相关理论及技术细节。本章提出一套适合中小企 业应用系统进行 SOA 架构建设与实现的方法。 5.1 基于 SOA 的分析设计方法 5.1.1 SOA 分层架构模型 SOA 的一个抽象观点将它描述为与业务过程结合在一起的合成服务的部分分层架 构。 图 5-1 呈现了这种类型的架构。 服务和组建之间的关系是,企业级的组件(大粒度的企业或者业务线组件)实现该服务并 且负责提供它们的功能和维持它们的服务质量。通过组合这些公开的服务到合成的应用程 序,就可以支持业务过程流。综合的架构通过使用 Enterprise Service Bus(ESB)支持这 些服务、组件和流程的路由、中介和转化。为了服务质量和非功能性的需求,必须监视和 管理已经部署的服务。 层 1:操作系统层。本层包含现有的自定义构建的应用程序,也叫做 遗留系统,包 含现有的 CRM 和 ERP 打包应用程序,以及 较旧的基于对象的系统实现,还有业务智 能应用程序。SOA 的复合层架构可以利用现有的系统并且用基于服务的集成技术来集成 它们。 层 2:企业组件层。本层由那些负责实现功能和保持公开服务 QoS 的企业组件组成。这 些特殊的组件是企业和业务单元级支持的企业资产的受管理和控制的集合。 同企业范围 资产一样,他们通过架构最佳实践应用程序来负责确保 SLAs 的一致。大多数情况下,本 层使用基于容器的技术,比如实现组件、负载均衡、高可用性和工作量管理的应用服务器。 层 3:服务层。业务选择来支持和公开的服务处在这一层。它们可以被 发现或者直接静 态绑定,接下来被调用,或者可能的话,编排到合成服务中。这个服务公开层同样提供了 获取企业范围组件,业务单元特定组件,以及有些情况下,特定项目组建的机制,并且以 服务描述的形式具体化了他们的接口子集。因此,企业组件使用它们接口提供的功能在运 基于 SCA 的 SOA 架构研究与应用 59 行时提供服务实现。在这一层的接口公开为一个服务描述,在这层中他们被公开以提供使 用。他们可以独立存在或者作为合成服务。 层 4:业务过程合成或编排层。第三层中公开的服务的合成和编排在这一层中被定义。通 过配合、编排,服务被绑定成一个流程,并且从而作为单独的应用程序而共同作用。这些 应用程序支持特殊的用例和业务过程。这里,可视的流程合成工具,比如 IBM® WebSphere® Business Integration Modeler 或者 Websphere Application Developer Integration Edition,都可以用来设计应用程序流程。 层 5:访问或表现层。尽管这一层经常超出了围绕 SOA 讨论的范围,但是它却变得越来 越有意义。在这里我描述它因为标准越来越集中,比如用于 Remote Portlets Version 2.0 的 Web 服务和其他技术,这些技术追求在应用程序接口或者表现层来利用 Web 服务。你可 以把它作为将来的层用来满足将来的解决方案的需求。注意到以下这两点是非常重要的: SOA 将用户接口从组件中分离出来;最终你需要提供从访问路线到服务或者合成服务的 端到端解决方案。 层 6:集成(ESB)。这一层使服务可以集成,通过引入一系列可靠的性能的集合,比如 智能路由,协议中介和其他转化机制,经常被描述为 ESB。Web Services Description Language(WSDL)制定了绑定,其包含提供服务的地址。另一方面,ESB 为集成提供了 位置独立机制。 层 7:QoS。这一层提供了监视,管理和维持诸如安全,性能和可用性等 QoS 的能力。 这是一个通过 sense-and-respond 机制和监测 SOA 应用程序健康的工具来进行的后台处 理过程,包括 WS-Management 和其他相关协议的所有的重要的标准实现以及为 SOA 实 现服务质量的标准。 5.1.2 基于服务的建模和架构方法 基于服务的建模和架构过程包含三个主要的步骤:服务,组件和流程(典型地,服务 的编排)的鉴别,指定和实现。以 IBM 的 SOMA 为例。 本科生毕业设计 ( 论文 ) 60 图 5-1 面向服务的建模和架构(SOMA)概貌图 5.1.2.1 服务发现 服务发现是 SOMA 进行服务分析和设计的第一步。服务发现的主要任务,是确定在一 定范围内(通常是企业范围,或若干关键业务流程范围内)可能成为服务的候选者列表。 目前有三种方式发现服务的候选者,它们分别是自上而下的领域分解、自下而上的现 有系统分析和中间对齐的业务目标建模。  自上而下(领域分解)方式 自上而下的领域分解方式从业务着手进行分析,选择端到端的业务流程进行逐层 分解至业务活动,并对其间涉及的业务活动和业务对象进行变化分析。 业务组件模型是业务领域分解的输入之一。业务组件模型是一种业务咨询和转型 的工具,它根据业务职责、职责间的关系等因素,将业务细分为业务领域、业务执行 层次和业务组件。由于企业内部和外部环境的不同,每个业务组件在成本、投资、竞 争力等方面不尽相同,因此,每个业务组件在企业发展的过程中战略职责和演化的路 径也是不同的,于是由于角度的不同,就形成了所谓的业务组件的"热点视图"。SOA 是一种特别强调业务和 IT 互动的技术。对于面向服务的分析和设计,业务组件模型提 供了进行服务划分的依据,而且这种划分的方法可以平滑地从业务视图细化到服务视 图。 端到端的业务流程是业务领域分解的另一个输入。将业务流程分解成子流程或者 基于 SCA 的 SOA 架构研究与应用 61 业务活动,逐级进行,直到每个业务活动都是具备业务含义的最小单元。流程分解得 到的业务活动树上的每一个节点,都是服务的候选者,构成了服务候选者组合。业务 领域分解可以帮助发现主要的服务候选者,加上自下而上和中间对齐方式发现的新服 务候选者,最终会构成一个服务候选者列表。在 SOA 的方法中,服务是业务组件间的 契约,因此将服务候选者划分到业务组件,是服务分析中不可或缺的一步。服务候选 者列表经过业务组件的划分,会最终形成层次化的服务目录。 变化分析的目的是将业务领域中易变的部分和稳定的部分区分开来,通过将易变 的业务逻辑及相关的业务规则剥离出来,来保证未来的变化不会破坏现有设计,从而 提升架构应对变化的能力。变化分析可能会从在未来需求的分析中发现一些新的服务 候选者,这些服务候选者需要加入到服务候选者目录中。  自下而上(已有资产分析)方式 自下而上的已有资产分析方式的目的是利用已有资产来实现服务,已有资产包括: 已有系统、套装或定制应用、行业规范或业务模型等。 通过对已有资产的业务功能、技术平台、架构及实现方式的分析,除了能够验证 服务候选者或者发现新的服务候选者,还能够通过分析已有系统、套装或定制应用的 技术局限性,尽早验证服务实现决策的可行性,为服务实现决策提供重要的依据。  中间对齐(业务目标建模)方式 中间对齐的业务目标建模方式的目的是帮助发现与业务对齐的服务,并确保关键 的服务在流程分解和已有资产分析的过程中没有被遗漏。 业务目标建模将业务目标分解成子目标,然后分析哪些服务是用来实现这些子目 标的。在这个过程中,为了可以度量这些服务的执行情况并进而评估业务目标,我们 会发现关键业务指标、度量值和相关的业务事件。 结合这三种方式的分析,我们发现服务候选者组合,并按照业务范围划分为服务 目录。同时为服务规约做好其他准备,如通过对已有资产分析进行的技术可行性评估, 通过业务目标建模发现的业务事件等。 5.1.2.2 服务规约 经过服务发现阶段,服务目录基本形成,但是对于每个服务本身的属性信息依然零散。 为了能够将服务作为业务和 IT 层面互动的契约,服务规约阶段是必不可少的。服务规约阶 段的主要任务是规范性地描述服务各个方面的属性,其中既包括输入/输出消息等功能性属 性,服务安全约束和响应时间等服务质量约束,以及服务在业务层面的诸多属性,如涉及 的业务规则、业务事件、时间/人员消耗等。与此同时,规范描述服务相关方面的关系也很 重要,如服务间依赖关系,服务和业务组件间关系,服务和 IT 组件间关系和服务消息间关 系等。 本科生毕业设计 ( 论文 ) 62 进行服务暴露决策是服务规约的第一步。理论上所有的服务候选者都可以暴露为服 务,但是一旦暴露为服务,该服务候选者就必须满足附加的安全性、性能等方面的要求。 企业还必须为服务的规划、设计、开发、维护、监管支付额外的开支,因此,我们会根据 一定的规则来决定将哪些服务候选者暴露为服务。 这些规则包含以下几个方面: 业务对齐。该服务候选者可以支持相关的业务流程和业务目标。 可组装。该服务候选者满足技术中立、自包含及无状态等特点,同时还满足复合应用 的相关非功能性需求。 可重用。该服务候选者可以在不同的应用、流程中重用,从而减少重复的功能实现, 降低开发和维护的成本。 基于企业应用开发的经验,我们还可以有其他一些方面的考虑。 经过服务暴露决策后,层次化的服务目录基本形成。下一步是结合传统的方法学对服 务各方面属性进行描述。这里说的传统的方法学是指企业架构,面向对象的分析和设计等。 在企业架构方法学的产物中,企业数据模型有助于服务消息的定义,IT 组件模型有助于服 务和 IT 组件间关系的描述,企业安全架构有助于服务安全约束规约,企业基础设施架构有 助于服务质量的描述。在面向对象分析和设计的产物中,业务用例和系统用例有助于服务 消息、服务相关业务规则和业务事件等描述,组件静态模型和动态模型有助于描述服务间 关系。 经过服务规约,服务组件(企业组件)和服务的各个方面的属性被规范下来,它会成为 业务和 IT 层面互动的基础。以后,业务对 IT 的新需求会体现为服务层面的变更,IT 层面 的变化会尽量遵循服务规约。在 SOA 监管的配合下,任何对服务规约的变更都是可管理 和可控制的。 5.1.2.2 服务实现 经过服务规约阶段,作为业务和 IT 互动的服务契约已经形成。但是服务契约和 IT 的 现状还是有很大差距的,如和某个服务对应的业务逻辑分散于不同的应用中,分散在不同 的地域,某些服务目前主要依靠人工完成,还没有 IT 层面的实现。 为了将服务契约落在实地,服务实现阶段通过差距分析,并结合传统方法学完成每个 服务实现决策。这其中包括的内容甚多,其主要内容如下: 1. 现有系统分析:调研现有系统架构,了解架构风格、主要架构元素和能力和架构 元素的基本特征;调研现有应用,了解应用主要功能和对外接口,技术实现特征等; 如果应用构建已经遵循基于组件开发规范,编制应用已有组件目录;如果应用并没 基于 SCA 的 SOA 架构研究与应用 63 有组件化,将应用覆盖的业务功能和服务规约确定的企业组件进行映射,确定应 用现有"组件"目录。 2. 确定服务分配:通过服务组件和现有系统分析确定的 IT 组件间差距分析,确定服 务组件和 IT 组件间映射关系。例如,一个服务组件对应一个或多个 IT 组件,没 有 IT 组件和服务组件对应,没有服务组件和 IT 组件对应,服务组件和 IT 组件对 应时有能力缺失或不匹配等。经过差距分析,一些服务中介被确定下来去实现服 务路由,或消息格式等不匹配现象,一些新的 IT 组件被确定下来,如实现某业务 流程的组件或实现人工服务的组件等。最终,服务组件都被映射到 IT 组件上,从 而完成服务分配。 3. 服务实现决策:服务分配仅仅确定了需要哪些组件来实现服务,但是并没有实现 的策略和技术层面的决策。服务实现决策首先帮助确定服务实现策略,是在现有 基础上进行服务包装,还是重新构建,如果重新构建,是采用已经包装好的应用, 还是外包,或者自己构建;如果是服务包装的话,有哪些候选方案等。通常服务实 现决策和传统的架构决策是关联在一起的。 4. 服务基础设施设计:服务的功能实现,非功能需求的满足都需要服务基础设施的 支持。在进行服务实现决策后,需要根据具体的需求确定服务基础设施的能力, 如用于支撑人工服务的人工服务容器,用于支撑服务编排的流程引擎等。 将服务实现阶段的各种产物和传统设计方法结合起来,就可以开始指导实际服务实现 的实施。 5.1.3 SOA 的治理 面向服务的体系结构 (SOA) 是一项引人注目的技术,用于开发与业务模型保持最佳 一致性的软件应用程序。不过,SOA 会提高业务和信息技术(Information Technology,IT) 以及 IT 部门和各个团队间所需的合作和协调级别。这个合作和协调是通过 SOA 治理提 供的,涵盖了用于指定和管理如何支持服务和 SOA 应用程序的各个任务和流程。 5.1.3.1 什么是 SOA 治理 通常来说,治理意味着建立和执行工作组为了一起工作而一致同意的工作指南。具体 来说,治理包括以下方面  建立授权的责任链  度量评估的有效性  指导组织建立满足其目标的策略  控制机制以确保遵从性  进行沟通以使所有相关方都获得通知 治理不同于管理。治理规划需要制定什么决策,而管理是制定和实施决策的过程。治 本科生毕业设计 ( 论文 ) 64 理重在建立决策,而管理重在贯彻执行决策。 IT 治理是指针对 IT 的治理;即:针对 IT 组织及其人员、流程和信息应用治理,以 提供指导,使这些资产支持业务需求。SOA 治理是 IT 治理的一种特殊化,其将关键 IT 治 理决策置于服务组件、服务和业务流程的生命周期上下文中。SOA 治理对生命周期进行 有效管理,生命周期是其关键目标。 IT 治理比 SOA 治理更广泛。IT 治理涉及 IT 的所有方面,包括影响 SOA 的问题 (如数据模型和安全性)以及 SOA 之外的问题(如数据存储和桌面支持)。SOA 治理 重点关注服务生命周期的一些方面,例如:计划、发布、发现、版本治理、管理和安全性。 治理在 SOA 中比在普通 IT 中更为重要。在 SOA 中,服务使用者和服务提供者运 行于不同的进程中,由不同的部门开发和管理,为了成功地一起工作,需要进行大量的协 调工作。为了 SOA 能成功,多个应用程序需要能共享相同的服务,这意味着它们需要进 行协调,以便共享和重用这些服务。这些就是治理问题,比采用独立应用程序时(甚至包 括使用可重用代码和组件时)要复杂得多。 5.1.3.2 SOA 开发生命周期中的治理场景 图 5-3 IBM SOA 治理生命周期 IBM 鼓励使用 SOA Foundation 生命周期。SOA Foundation 生命周期从业务建模开 始,将模型转换为信息系统,部署该信息系统,然后管理该部署。由于 SOA 开发生命周 期紧密遵循 IBM 的 SOA Foundation 生命周期,典型的服务开发将经历建模、组装、部 署和管理阶段。详细分析如下: 1. 建模: 建模阶段以业务需求为基础,在此阶段中将设计业务流程模型,确定业务服务,使用 假设业务条件对流程进行模拟,并根据业务目标对随后的结果进行分析。如果目标未得到 满足,则使用修改后的业务服务重新定义流程。从这些建模方面看,业务服务的标识是非 基于 SCA 的 SOA 架构研究与应用 65 常重要的活动,此活动是到 IT 服务实现的一对一映射。 2. 组装: 定义 IT 服务以后,您将到达设计、规范、创建和测试的组装阶段。使用业务流程的 组合对所构造的服务进行独立的测试。测试合格的服务将进入运行时存储库,并针对服务 使用者进行发布。由于不同的服务客户端使用的这些服务在功能方面稍有更改,因此将在 更改流程获得批准后构建相同服务的具有不同功能的不同版本。 3. 部署: 在部署阶段,不同版本的服务将在存储库中进行发布,并在带有集成业务流程的服务 容器中进行部署。还可以在运行时动态选择已部署的服务,以基于来自服务请求者的某些 选择条件构建组合应用程序。 4. 管理: 在管理阶段中,将监视这些服务对不同服务请求的及时响应能力,检测不满足服务水 平的情况,并恢复系统的可操作状态。在此阶段中,将优化服务和总体操作环境以满足业 务目标。通过适当的服务水平安全性设计和实现对服务进行标识和遵从性管理。 5.2 本章小结 本章介绍了如何利用 SOA 的架构体系方法对系统进行相关的系统分析,在 此基础上,提出了一套适合中小型企业进行 SOA 架构建设实现的方法和步骤。 在该套方法中,以 IBM 的 SOMA 模型为例,从服务发现、服务规约、服务实现三个主要 阶段以及 SOA 的治理四个方面探讨了在设计一个基于 SOA 的企业应用系统时的具 体步骤和要注意的问题。 本科生毕业设计 ( 论文 ) 66 第 6 章 总结与展望 本文主要研究了基于 SCA 编程模型下,如何运用 SOA 的相关的架构理论搭建符合 SOA 规范架构的企业应用系统。 本文的主要工作成果有如下: 1. 研究了面向对象服务架构的基础理论,技术体系结构及相关特征。 2. 研究了 SOA 体系结构中重要的编程模型 SCA 的相关技术规范,分析了 SCA 在 服务的应用集成方面的优势,论述了如何应用 SCA 进行服务集成的相关方法 步骤。 3. 结合 SCA 编程模型的特点,提出了在构造基于 SOA 的应用系统时架构的分层 模型,详细论述了如何使用 SCA 编程模型构建系统的服务层的方法。 4. 结合当前企业在实施 SOA 战略时遇到的问题,提出了一套适合中小企业进行 SOA 业务分析、架构分析、SOA 策略分析的方法。 SOA 体系结构这潭水深且发展迅速,由于个人水平有限,所做的研究比较粗糙。目前 看到的资料只是冰山一角,目前了解的内容更是九牛一毛。无法对其进行完整深刻的研究, 可改善的部分还很多,比如在实践中,可以进一步考虑研究将服务组件架构(Service Component Architecture,SCA)与服务数据对象(Service Data Object,SDO)以及业务流 程执行语言(Business Process Execution Language,BPEL)整合。有了更深一层的沉淀, 对服务划分、粒度把握会更加精准。 当前,面向服务组件架构被誉为继面向组件的体系结构后的又一个里程碑,发展相当 迅速,各大 IT 厂商和国际组织都投入了大量的人力物力进行相关研究。其中,基于 SOA 的体系结构下,有不少的相关标准、开发模式、编程模型及开发工具,而目前最被广泛认 可的就是 SCA,ESB 以及 BPEL,它们三者是当前 SOA 体系中的重要组成部分。在 SCA 编程模型的标准方面,今后随着各大 IT 厂商及组织的大力推广,以及相关更多标准规范文 件的出台,SCA 的发展将会变得更趋成熟,相信今后将会能成为开发 SOA 应用中的首选 编程模型。 基于 SCA 的 SOA 架构研究与应用 67 致 谢 完成最后一个章节,写到致谢的时候,也意味着四年的大学生涯步入尾声,不禁感慨 良多:这是一个终点,也是另一个人生的开始。 完成本论文,首先要感谢我的导师陈昱,陈老师严谨的治学态度和一丝不苟的精神, 鼓励了我的学习。从开题、撰写到最终的评审,陈老师都给了我很大的指导和支持,使我 得以顺利地完成论文的写作。 其次,我要感谢软件学院的所有任课老师,他们兢兢业业地教学,提高了我的理论知 识水平和实践能力,使我有开阔的视野完成论文的写作。 由于 SCA 的发展和研究还处于初级阶段,相关的资源比较少,在论文的写作过程中, 我得到了不少同事的帮助和指导,我要感谢福建星网锐捷网络有限公司福州研究院十三部 的高恺、张娟燊工程师,八部的冯驰工程师、魏少冬学长,他们给予我很多 SOA 方面的 理论和技术上的指导。 另外,我还要感谢我的家人,是他们的关怀、理解和鼓励,使得我顺利完成了论文的 写作。 最后,衷心感谢在百忙之中评阅论文和参与答辩的各位专家、教授。 本科生毕业设计 ( 论文 ) 68 参考文献 [1]王紫瑶, 南俊杰, 段紫辉, 钱海春等.SOA 核心技术及应用.北京:电子工业出版社,2008. [2]Michael Beisiegel, IBM; Nickolas Kavantzas, Oracle; Ashok Malhotra,Oracle; Greg Pavlik, Oracle; Chris Sharp, IBM SCA Policy Association Framework. [3]Apache Software Found: Tuscany home page, WEB (2008),http://tuscany.apache.org/. [4]Marco Aldinucci, Hinde Lilia Bouziane, Marco Danelutto,and Christian Pérez STKM on SCA: A Unified Framework with Components,Workflows and Algorithmic Skeletons 2009. [5]凌晓东.计算机应用与软件.弟 24 卷第 10 期,2007. [6]焦美.SOA 在 B2B 电子商务中的应用[硕士学位论文].辽宁:大连海事大学.2007. [7]张凯.基于面向服务体系结构的安全代理系统的研究 [硕士学位论文].北京:北京工业大学.2007. [8]Mark Endrei,Jenny Ang,Ali Arsanjani,Sook Chua,Philippe Comte,Pal Krogdahl,Min Luo,Tony Newling 2004. [9]姚辉,金戈,赵勇 SOA 快速指南——服务实现及架构设计 2007. [10]罗海驰 基于 Web Services 的电子政务体系结构及其应用 2006. [11]王行哲 XML 模式到概念模型的转换方法与工具研究 2008. [12]方伟 在 Apache Tuscany 上开发基于 SCA 的 Web 2.0 应用 2009. [13]涂航 SOA 技术白皮书——武汉大学计算机学院 2008. [14] Ramkumar Ramalingam Design and develop SCA components using the Spring Framework 2009. [15] Ali Arsanjani, Ph.D Service-oriented modeling and architecture 2004. [16]毛新生. SOA 方法学与面向服务的分析和设计 2007. [17]SOA Foundation: An architectural introduction and overview. IBM: developerWorks, 2005. [18]Boris Lublinsky, Didier Le Ti. 在 SOA 中实现业务规则和业务流程 2007. [19]Peggy: SOA 重在把业务变成组件和流程化模块 2009. [20]Thomas Erl[美]. SOA 服务设计原则[M]. 人民邮电出版社. 2009. [21]IBM RUP for Service-Oriented Modeling and Architecture V2.4 2006. [22]Ueli Wahli,Lee Ackerman,Alessandro Di Bari,regory Hodgkinson,Anthony Kesterton,Laura Olson,Bertrand Portier Building SOA Solutions Using the Rational SDP 2007.

下载文档,方便阅读与编辑

文档的实际排版效果,会与网站的显示效果略有不同!!

需要 15 金币 [ 分享文档获得金币 ] 7 人已下载

下载文档

相关文档