基于SOA架构的人才门户网站服务设计与应用软件工程专业论文.docx 75页VIP

Abstract With the increasing number and complexity of software system, enterprises must strengthen competitive ability. While creates IT system, new system architecture should be taking into account for business to substitute former distributed and exclusive application platforms. Service oriented architecture (SOA) is becoming the system structure of today’s enterprise IT system. SOA is an architecture model or assembly of services in essence, which connect different functions of application programmers through interface and contract. The appearance of SOA has brought tremendous competitiveness for enterprises with its characteristics of HYPERLINK /dvbbs/dispbbs.asp?boardid=58amp;id=4821amp;star=1amp;page=26 criterion、Loose coupling and agility. The core of IT system construction based on SOA is service discovery and service design. This paper is based on an example of the practice project of GDHRSOFT Portal. First, it introduces the technology foundation of SOA, including the relation of SOA and Web service, the core protocol of Web service, etc.; and then it discusses the reference principle of service analysis and design—service design principle and methods, inclusive of 3 mains principles: Alignment principle of Business Functions wit IT Systems, Keep agility principle 、 Loose coupling principle. This paper also use two services example of “full text search engine” and “ad service” to demonstrate basis of methods for service discovery, HYPERLINK /dict_result.aspx?r=1amp;t=%E8%BF%87%E7%A8%8B%E5%BB%BA%E6%A8%A1%E6%96%B9%E6%B3%95amp;searchword=process%2Bmodeling%2Bapproach modeling process, designing service component and to discuss the whole procedure of service analysis and design. Base on SOA architecture, Develops the project of GdHrSoft Portal is the main work of this paper. From importing requirements, then creating system architecture, and then base on requirements and SOA architecture, modeling services and finding all possible services, finally using “full text search engine” and “ad service” as samples to picture the service realization and describe the service interface. In conclusion, the paper summarizes the shortcoming and future research trend. Keywords Service Oriented Architecture (SOA) Service Discovery principles Service design Full text search engine service 目录 摘要I HYPERLINK \l _bookmark0 Abstract II HYPERLINK \l _bookmark1 第 1 章 绪论 1 HYPERLINK \l _bookmark1 1.1 课题背景 1 HYPERLINK \l _bookmark2 1.2 国内外研究状况 2 HYPERLINK \l _bookmark3 1.3 课题来源 3 HYPERLINK \l _bookmark4 1.4 主要研究内容及方案 4 HYPERLINK \l _bookmark5 1.5 本论文的主要工作 5 HYPERLINK \l _bookmark6 第 2 章 人才门户网站核心技术研究 7 HYPERLINK \l _bookmark6 2.1 面向服务的架构(SOA) 7 HYPERLINK \l _bookmark6 SOA 概述 7 HYPERLINK \l _bookmark6 SOA 与 Web 服务的关系 7 HYPERLINK \l _bookmark7 什么是 Web 服务 8 HYPERLINK \l _bookmark7 Web 服务体系架构 8 HYPERLINK \l _bookmark8 2.1.5 Web 服务核心协议 10 HYPERLINK \l _bookmark9 2.2 基于 Spring 框架的拟服务总线 12 HYPERLINK \l _bookmark9 Spring 框架概述 12 HYPERLINK \l _bookmark10 Spring 与 Web 服务结合实现服务总线 13 HYPERLINK \l _bookmark11 2.3 本章小结 14 HYPERLINK \l _bookmark12 第 3 章 人才门户网站系统总体架构 15 HYPERLINK \l _bookmark12 3.1 系统需求 15 HYPERLINK \l _bookmark13 3.2 确定候选服务 17 HYPERLINK \l _bookmark14 3.3 系统体系结构 18 HYPERLINK \l _bookmark14 3.3.1 架构的设计原则 18 HYPERLINK \l _bookmark15 3.3.2 人才门户的体系架构 19 HYPERLINK \l _bookmark16 3.4 系统架构的优越性 20 HYPERLINK \l _bookmark17 3.5 本章小结 21 HYPERLINK \l _bookmark18 第 4 章 人才门网户站面向服务的建模过程 22 HYPERLINK \l _bookmark18 4.1 服务发现及建模过程概述 22 HYPERLINK \l _bookmark19 4.2 服务设计原则及依据的应用 23 HYPERLINK \l _bookmark19 4.2.1 业务功能与 IT 系统对齐 23 HYPERLINK \l _bookmark20 4.2.2 保持灵活性 25 HYPERLINK \l _bookmark20 4.2.3 服务设计的依据及流程 25 HYPERLINK \l _bookmark21 4.3 建立服务模型 26 HYPERLINK \l _bookmark22 4.4 全文搜索引擎服务建模 28 HYPERLINK \l _bookmark23 4.4.1 业务流程分析 29 HYPERLINK \l _bookmark24 4.4.2 建立服务模型 31 HYPERLINK \l _bookmark24 4.5 广告服务建模 31 HYPERLINK \l _bookmark24 4.5.1 业务流程分析 31 HYPERLINK \l _bookmark25 4.5.2 建立服务模型 33 HYPERLINK \l _bookmark26 4.6 本章小结 34 HYPERLINK \l _bookmark27 第 5 章 服务组件设计与实现 35 HYPERLINK \l _bookmark27 5.1 服务设计过程概述 35 HYPERLINK \l _bookmark28 5.2 全文搜索引擎服务设计 36 HYPERLINK \l _bookmark29 5.2.1 服务规约 38 HYPERLINK \l _bookmark30 5.2.2 服务接口设计及实现 39 HYPERLINK \l _bookmark31 5.2.3 设计服务组件逻辑 43 HYPERLINK \l _bookmark32 5.2.4 服务与系统的集成方式 45 HYPERLINK \l _bookmark33 5.3 广告服务设计 46 HYPERLINK \l _bookmark34 5.3.1 服务规约 47 HYPERLINK \l _bookmark35 5.3.2 服务接口设计及实现 48 HYPERLINK \l _bookmark36 5.3.3 设计服务组件逻辑 49 HYPERLINK \l _bookmark37 5.3.4 服务与系统的集成方式 50 HYPERLINK \l _bookmark37 5.4 本章小结 50 HYPERLINK \l _bookmark38 结论 51 HYPERLINK \l _bookmark39 参考文献 52 HYPERLINK \l _bookmark40 哈尔滨工业大学硕士学位论文原创性声明 55 HYPERLINK \l _bookmark40 哈尔滨工业大学硕士学位论文使用授权书 55 HYPERLINK \l _bookmark41 致谢 56 HYPERLINK \l _bookmark42 个人简历 57 第1章 绪论 1.1 课题背景 随着软件开发方法研究的发展和分布式应用技术的深入，基于多种开发平 台的软件系统得到大量应用，使得软件系统变得日益庞大和复杂。传统的 IT 环 境是由一个个项目组成的，每个项目围绕着一个业务应用并致力模拟当时的业 务流程，业务流程的发展变化，而 IT 项目企图以一个固化的应用来适应变化的 项目，经常会修修补补，发展到后来，系统变得越来越复杂，系统各功能组件 之间紧密耦合，交错复杂。出现流程无法互通，信息不能共享，系统与系统之 间连接脆弱，无法整合，与以前开发的软件系统无法重用，缺乏动态敏捷性[1]等 等问题。 传统的面向过程的结构化设计的开发方法集中于以功能来划分软件的结 构，首先考虑整个软件的功能，按照模块划分的一些基本原则来进行功能分 解，把整个系统分解成多个模块，每个功能模块实现特定的子功能。其次以自 顶向下,逐步细化的设计方式，程序的主体是函数，函数是最小的功能模块。在 这个以过程为中心进行功能组合的开发方法，很难创建通用的可重用的函数， 软件的扩充修改及重用能力很差[2]。 面向对象是把问题以对象化进行抽象设计，类用来描述具有相同的属性和 方法的对象的集合，建立对象的目的不是为了完成一个步骤，而是为了描叙某 个事物在整个解决问题的步骤中的行为。对象能够提供细粒度的“复用”的机 制，软件开发过程中的重用度比较低。 面向组件的开发把商业逻辑或者说一组相关的对象抽象成一个组件对外提 供服务，组件间的交互通过接口进行，抽象和封装度明显提高，可以实现粗粒 度的代码重用。组件在构建系统的时候需要容器的帮助，容器为组件提供了运 行环境，使组件能在容器中完成自己的工作而不用考虑底层细节。企业选择不 同的平台开发出了自己的系统，应用之间不能有效地进行实现信息共享与交 换，也阻碍了组件的复用。 为了变得更加有竞争力，企业必须创建一个面向业务的可靠的面向服务的 企业架构，用来替代过去分散、专用的应用平台。因此，SOA 逐渐成为适于设 计现代企业应用程序的体系结构形式，其核心思想就是把业务功能包装成标准 的服务，之后把这些服务组装成企业应用。利用面向服务的企业架构，企业可 以有效的重用那些现有的系统，实现软件复用[3]，提高软件的可维护性[4]，并及 时开发出新的功能。这实乃一种思想、一种方法[5]，本质上说，就是将需求分配 到服务中的设计方法论，保证面向未来的兼容性[6]。 1.2 国内外研究状况 从 2000 年前后起，第二代电子商务的崛起，以 Web 服务为核心的技术发展 方向成为炙手可热的技术，经过几年的发展，基于 Web Service 的公共技术标准 WSDL/SOAP/UDDI/WSFL 已成事实行业标准，Web 服务已成为动态商务 Web 的主流技术。Web 服务由于其松散耦合、自描述与自适性、分布式与地理位置 无关性、动态性、扩充性等技术特点[7]。广泛用于企业应用系统建设、集成、异 构环境的系统之间的通讯，特别适于需要与自主开发的应用互操作的资源外包 业务、管理业务。另外把传统的系统功能改造为可重用的业务服务，不需要重 写代码。Web 服务的出现，为系统集成、异构系统之间的通信等疑难问题提供 了技术解决方案和制定了统一的行业标准。 随着核心 Web 服务标准逐渐被广泛采纳与应用，高度异构的软件系统之间 的互操作已经取得了前所未有的成功。Web 服务从技术的角度来实现业务流程 的整合，对 IT 企业的快速应变提供了技术基础[8]。 面对灵活多变的业务应用，仅从技术角度来设计，这是远远不够的。如何 更灵活的实现企业 IT 系统建设和业务流程的快速应变，给企业带来更大的经济 效益，一直备受国内外企业管理者、软件工程学者的密切关注与探索。一种被 誉为下一代 Web 服务的技术架构，再一次引起了国内外关注。这就是 SOA(Service Oriented Architecture,面向服务的架构)，是 Gartner 在 1996 年提 出，到了 2002 年 12 月，Gartner 又提出 SOA 是“现代应用开发领域最重要的课 题”，并预计到 2008 年，SOA 将成为占有绝对优势的软件实现方法, 80%的用户 使用 SOA 开发新产品[9]。它将结束传统的整体软件体系架构长达 40 年的统治地 位（可能性：70%）。Gartner 建议，主流企业现在就应该在理解和应用 SOA 开 发技能方面进行投资[9]。 SOA 给 IT 产业带来的不仅仅是一场技术的革命，它对未来产业链的形成和 软件开发模式的影响将是更加深远的。SOA 作为新一代的软件架构，在未来的 5－10 年里将给软件产业带来革命性的变化[10]。 “SOA 将改变整个 IT 产业的格局”[11]， 并非是 IBM 软件集团总经理 Steve Mills 的耸人听闻之言。目前，SOA 大潮正在引发软件产业新一轮抢滩战，从国 外的 IBM、微软、BEA、HP、Oracle、SAP,还有国内用友，都无一例外地加入 到 SOA 战场中来，都竭力从各自的角度诠释 SOA,却又不得不达成一个共识： SOA 是一种设计方式，它指导着业务服务在其生命周期中包括创建和使用的方 方面面。SOA 也是一种定义和提供 IT 基础设施的方式，它允许不同应用相互交 换数据、参与业务流程，无论它们各自背后使用的是何种操作系统或采用何种 编程语言[12]。 SOA 本质上是服务的集合。服务间彼此通信，这种通信可能是简单的数据 传送，也可能是两个或更多的服务协调进行某些活动。服务间需要某些方法进 行连接。SOA 的目的是以服务定义和重用为中心，将流程创新，有效管理和技 术策略结合起来，帮助机构实现业务和技术优势[13]。目前 IBM,BEA,ORACLE 等跨国软件企业相继推出了基于 SOA 架构的应用平台和产品簇。对基于 SOA 架构软件系统提供了业务建模、开发、服务管理、服务集成的开发平台，分别 提出了各自的 SOA 实施方法论[14]。 网上人才招聘，已经是非常普遍的人才招聘方式，但把人才培养、就业、 继续教育容为一个整体的交易平台，用户群主要针对在校即将毕业的学生的招 聘网站，在国内尚是一种新的尝试，将引导人才培养、就业模式进入一个新的 历史时期。 国内已知的招聘网站，是基于传统架构开发的 Web 网站，本课题项目实质 上是一个综合性的 Web 信息系统，采用基于面向服务架构进行设计。与传统架 构的人才招聘系统相比，具有更好的灵活性、灵捷性，最重要的是以服务为导 向，对企业、院校提供人才相关业务服务，是人才招聘方式新的业务增长点， 对传统方式的突破。 1.3 课题来源 本文是以“广东软件行业协会人才门户网站”项目为实际应用背景，从中进 行业务抽象与服务提取，按面向服务的方法进行设计与应用实践。 “广东软件行业协会人才门户网站”是广东软件行业协会的一个项目，该项 目以下简称“人才门户”。广东软件行业协会有几十所高等院校、软件企业和培 训机构等会员单位，该项目的目的，是为加强省内高等院校和软件行业企业、 培训机构之间的人才合作、联系和交流，为软件企业与高等院校之间的人才需 求与人才培养营造一个双向沟通、合作的环境，架构国内软件人才供、需之间 的桥梁，成为省内高等院校人才培养、就业的依托，更成为软件企业软件人才 获取的源泉，为此着手研发的网上人才培养、交易的一个平台。 1.4 主要研究内容及方案 本课题在人才招聘类网站系统中首次引入基于 SOA 架构的设计方式，以服 务为导向设计业务功能点，实现系统内多个门户间业务流程快速集成，对外提 供搜索服务、人才推荐/分析等服务给企业、院校使用，实现人才招聘与企业内 部的人力资源系统的集成提供一个基础服务平台，主要研究内容如图 1-1 所示。 人才门户网站需求调研 体系架构设计 应用程序前端 服务抽象及建 模  服务总线设计 服务合约服务组件设计 服 服务合约 服务类设计 课题重点 涉及 图 1-1 课题研究路线 (1) 在学习总结 SOA 设计原则及方法的基础，在系统的设计过程中，应用 这些原则，突破面向过程及面向对象/组件设计方法的束缚，以服务为导向设计 系统的服务架构,分析业务系统的服务需求、服务组件到服务类的设与应用实现, 并应用研究相关建模方法。 (2) 通过对课题项目的实践应用，研究 SOA 框架模型[15]、面向服务分析与 设计原理及原则，从扩充性、重用性等角度划分服务，应用到人才门户网站系 统建设中，也为基于 SOA 架构的服务设计提供设计过程指导及方法论，探索对 于某些问题在特定环境的解决方案――SOA 设计模式[8]。 (3) 在人才门户网站中，服务交互的参与并不是直接交互[16]，本课题通过对 面向服务的集成，研究服务的集成方式，为系统各门户版块及外部用户提供基 于插拨式的、可扩充的、可管理的服务总线[17]，研究信息系统架构设计中以服 务为导向的服务划分及服务集成模式。 通过以上工作路线，对基于服务设计为导向的人才门户网站设建进行新的 尝试和探索，同时也为 SOA 的服务设计、服务集成拓展新的应用领域。 1.5 本论文的主要工作 本文在研究 SOA 体系架构、技术基础、业务建模过程、设计方法、设计原 则及模式的基础上，在实践中应用到实际项目上解决具体问题，着重，本论文 的组织结构如图 1-2。 第 1 章介绍了课题的研究背景及研究意义，国内外对 SOA 研究的现状和发 展前景，阐明本课题的研究方案及策略。 第 2 章在介绍什么是 SOA 的及 SOA 与 Web 服务的关系的基础上，重点介 绍 Web 服务的整体框架及协议规范，及 Web 服务的实现方式。 第 3 章是本课题研究系统的整体架构，在业务需求分析的基础，给出基于 SOA 架构，阐述人才门户网站是如何搭建起来的。 第 4 章基于 SOA 架构，阐述面向服务的建模过程，详述服务抽象的一些方 法及应用。 SOA研究现状、应用背景 第１章 人才门户网站核心技术 第２章 人才门户网站系统总体架构 第3章 服务建模过程 第4章 服务组件的设计与实现 第5章 全文搜索引擎服务及广告服务 的案例分析 第4、5章 图 1-2 论文结构示意图 第 5 章在前一章建模的基础上，详述服务组件的设计的层次性，及服务组 件的设计过程，引入搜索引擎服务及广告服务为实际案例阐述服务组件的设计 过程。 最后，给出结论，总结存在的问题及对进一步研究的展望。 第2章 人才门户网站核心技术研究 本章在着重介绍人才门户网站相关的核心技术，先介绍 SOA 与 Web 服务的 关系，再侧重介绍 Web 服务的基本概念、体系架构和标准协议，再介绍 Web 服 务的实现方式及在 SOA 中的应用。 2.1 面向服务的架构(SOA) SOA 概述 面向服务的体系架构（service-oriented architecture，SOA）是一种架构模 型，本质上是服务的集合[18]，它将应用程序的不同功能单元（称为服务）通过 这些服务之间定义良好的接口和契约联系起来。接口是采用中立的方式进行定 义的,基于开放标准的基础之的，它独立于实现服务的硬件平台、操作系统和编 程语言。这使得构建在各种这样的系统中的服务可以以一种统一和通用的方式 进行交互。 尝试给出特定环境下推荐采用的一种企业软件系统架构[19]，是人们构建面 向应用服务的解决方案。利用基于 SOA 的系统构建方法中，一个基于 SOA 架 构系统中所有的功能需求都被封装成在应用功能模块中[20]，然后利用这些已经 封装好的功能模块组装构建我们所需要的程序或者系统，而这些功能模块就是 SOA 架构的核心－服务(services) [21]。 SOA 与 Web 服务的关系 如前所述，SOA 服务是构建在一系列基于开放标准的基础之的，Web 服务 定义了如何在异构系统之间实现通信的标准化，使得 SOA 的服务可以跨越运行 平台和实现语言。Web 服务是就现阶段而言最适合实现 SOA 的一些技术的集 合，事实上最近 SOA 的快速发展在很大程度上归功于 Web 服务标准的成熟和应 用的普及为广泛的实现 SOA 架构提供了基础。Web 服务是 SOA 的技术基础， SOA 的 IT 系统实现依赖于 Web 服务，Web 服务作为实现 SOA 中服务的最主要 技术手段。 SOA 本身是应该如何将软件组织在一起的抽象概念。它依赖于用 XML 和 Web 服务实现并以软件的形式存在的更加具体的观念和技术。此外，它还需要 安全性、策略管理、可靠消息传递以及会计系统的支持，从而有效地工作。 什么是 Web 服务 Web 服务是一种部署在 Web 上的对象/组件，以及能够通过 Web 存取的一 个商业逻辑组件或者系统的功能，可以使得传统的系统功能改造为可重用的业 务服务，并且不需要重写代码[22]; Web 服务可用于系统集成、企业集成，特别适合于需要与自主开发的应用 互操作的资源外包业务、管理业务。 Web 服务具有以下技术特点： 1) 松散耦合 由松散耦合的组件（如消息与数据传输分开）构成的，易与其他平台和其 他标准技术进行集成。当一个 Web 服务的实现发生变更的时候，调用者是不会 感到这一点的，对于调用者来说，只要 Web 服务的调用接口不变，Web 服务的 实现任何变更对他们来说都是不透明的，甚至是当 Web 服务的实现平台从 J2EE 迁移到了.NET 或者是相反的迁移流程，用户都可以对此一无所知。 2) 自描述与自适应 用 XML 描述交换的信息内容，可以保证信息的自描述性和自适应性，不需 要关于应用和接口的知识，处理的数据与处理逻辑分开，使集成更容易、更清 晰。 3) 分布式和与位置无关性 采用 UDDI 和 ebXML 注册机制，使得的业务服务变成与地理位置无关的分 布的，功能利用 WSDL 描述，使得服务可以被发现，也可与 Web 服务的注册表 进行绑定和解绑定。 4) 动态性和扩充性 由于交换的信息用 XML 进行封装，信息可以动态汇聚、动态转换以及实时 处理。 5) 基于开发标准 基于开放标准技术，使得组件的集成更容易，解决方案的选择面更广，对 以后采用新技术，移植将更为有利[23]。 Web 服务体系架构 在 Web 服务的体系架构中，厂商将其业务服务封装成一个个相对独立的 Web 服务，每个服务提供特定的业务功能。客户或其它厂商可以通过绑定到 HTTP 的 SOAP 协议来访问这些服务。如图 2-1 为 Web 服务的宏观体系架构， 三大角色之间的关系如下. 1) 服务提供者 负责创建服务描述，将服务描述发布到一个或多个服务注册处。业务逻辑 组件，系统能提供的业务功能封装，通过 Web service 提供者发布到 Internet 上 提供服务[24]。 2) 服务请求者 图 2-1 Web 服务体系结构 查找发布在一个或多个服务注册处的服务描述，并负责利用服务描述，绑 定或调用提供者服务。 3) 服务注册 是一个 Web Service 的注册环境，服务提供者注册服务，服务请求者搜索服 务。 Web 服务是建立在一些通用协议规范基础上的，如 HTTP、SOAP、XML、 WSDL、UDDI 等。这些协议是与平台无关的，在涉及到操作系统、对象模型和 编程语言的选择时，没有任何倾向，因此有很强的生命力。图 2-2 为 Web 服务 中更细化的执行示意图，执行过程如下： ? 服务实现，服务提供实现具体业务逻辑，基于 JAVA 开发语言，可以 JavaBean 或 EJB 等形式封装。 ? 服务描述，让外界知晓，服务组件能提供什么服务，如何找到并调 用，以 wsdl 描述进行描述。 ? 服务注册，在统一的注册中心注册服务，以便外界能找到所提供的服 务(可选)。 ? 服务查找，服务请求者，通过 UDDI，在注册中心查找目标服务 ? 服务代理，找到目标服务后，建立服务调用代理 ? 服务调用，服务请求者，通过服务代理，远程调用服务提供者提供的 服务 ? 服务整合，请求者与 web 服务整合成一个客户应用程序或新的 web 服务 Web 服务核心协议 图 2-2 Web 服务执行示意图 Web 服务由基于 XML 基础协议之上的三大核心协议组成，分别为 WSDL,SOAP 及 UDDI，下面分别予以介绍。 WSDL 规范 WSDL (Web Services Description Language) Web 服务描述语言，是一种 XML 应用,将一个 Web Services 描述为一组服务访问点。描述的内容包括：服 务名称、服务地点、如何与服务通信。众多 WSDL 可以存放于 UDDI 注册表， 并在 Web 上公布[7]。 各平台提供工具为通过远程通信方式与客户端取得联系的 Web 服务制作 WSDL。对象的 Interface 具备相应的 SDK 描述文档,让开发人员阅读，Web 服务 也是一种对象，只不过它是被部署在 Web 上而已 ,也有对 Web 服务这个对象的 界面的 SDK 描述文档 ,只不是让机器来自动阅读和翻译。Web 服务的目标是即 时装配，松散耦合以及自动集成的，意味着 SDK 描述文档应当是具备被机器识 别的能力的。 以 XML 结构化的方式对 Web 服务的调用/通信加以描述, 实现了对 Web 服 务即时装配的基本保证 ，WSDL 正是这样的一种语言。WSDL 协议由二大组成 部份，七小部份组成。文档结构如图 2-3。 SOAP 协议 图 2-3 WSDL 协议的文档结构 SOAP（Simple Object Access Protocol ）简单对象访问协议是在分散或分布 式的环境中交换信息的简单的协议，是一个基于 XML 的协议。 SOAP 以 XML 形式提供了一个简单、轻量的用于在分布环境中交换结构和 类型息信的机制，是 Web 服务的基础. 可在 HTTP 上传输，运行于不同平台和地点的客户端与 Web 服务之间建立 完全的互操作。HTTP 是在互联网上发送消息时常用的请求与响应标准协议，而 SOAP 是一种基于 XML 的协议，仍然继承 HTTP 请求和响应模式。 如图 2-4,SOAP 负责以下内容的消息传输： (1)定义一个基于 XML 的封装，描述消息包含什么，以及如何处理本消 息。 (2)包含基于 XML 的编码规则，用以在消息内表达应用定义的数据类型实 例。 (3)定义一个基于 XML 的协定，用以表示向远程服务所做的申请，以及响 应的结果。 UDDI 协议 WSDL 是用来描述 Web Services 的相关信息,Web Services 开发商需要一个 方法将自己开发的 Web Services 进行发布，广而告之。 UDDI(Universal Description，Discovery and Integration)即统一描述、发现和 图 2-4 SOAP 协议体系 集成协议应运而生。UDDI 是一个跨产业、跨平台的开放性架构。其可以帮助 Web Services 开发商在 Internet 上公布自己推出的 Web Services。 UDDI 基于 XML 的标准，使企业可以将有关其产品和 Web 服务的信息发 布在互联网上，并使这些信息可以被全球任何一个客户端访问到。可以将 UDDI 想象成一个 Web 服务的黄页或类似注册企业的工商行政机关。UDDI 就是 Web 服务的服务,是 Web 服务的服务中介。 2.2 基于 Spring 框架的拟服务总线 Spring 框架概述 Spring 是一个开源框架，是为了解决企业应用程序开发复杂性而创建的， Spring 专注于典型的 J2EE 应用系统所有架构层面的架构，是能够替代 EJB 技术 的强大框架[25]，并且，它不依赖于任何的组件，是一种轻量级的容器。而今， 架构级的 Spring 已成为主流，它主导着整个 J2EE 开发 WEB 应用的方向。 Spring 是一个轻量级的 IoC(Inversion oft Control,控制反转)和 AOP(Aspect- Oriented Programming,面向方面编程)容器框架[26]，主要包括以下重要特点： ? 轻量级 从大小和系统开支上说 Spring 都算是轻量级的。完整的 Spring 框架可以在 一个大小只 1MB 多的 JAR 文件里发布。并且所需的处理开销也是微不足道的， Spring 的设计哲学是提供一种无侵入式的高度可扩展框架，基于 Spring 开发的 系统中的对象不依赖于 Spring 的类，即无需代码中涉及 Spring 专有类，就可将 其纳入容器进行管理[26]。 IoC 即反转控制，Spring 提倡使用 IoC 来实现松耦合，由容器控制对象之间的 依赖关系，这样就减轻了组件之间的依赖关系，提高了组件的可移植性。IoC 是 Spring 框架的基础和精髓。目前正成为框架发展的主流技术[27]。 AOP 即面向方面编程，Spring 对面向方面编程提供了强大支持，通过将业务逻 辑从系统服务(如监控和事务管理)中分离出来，实现了内聚开发。 ? 容器 Spring 是一个容器，它包含并且管理系统对象的生命周期和配置。Spring 容器使用 IoC EJB 容器。 ? 框架 管理所有组成应用系统的组件，这使得它有别于传统的重量组 Spring 实现了使用简单的组件配置组合成一个复杂的系统，在 Spring 中， 系统中的对象是通过 XML 文件配置组合起来的。并且 Spring 提供了很多基础 功能(事务管理、持久层集成等)，这使得开发人员能够专注于开发应用逻辑。 Spring 与 Web 服务结合实现服务总线 在基于 SOA 架构的系统中，不同服务之间基于插拨式的、可扩充的、可管 理的服务总线实现,以支持企业间面向服务的交互，就像 PC 中硬件的总线[28],通 过系统预先规约好的接口“插”到软件总线上[29]。在人才门户网站系统，众多服 务之间，采用 Spring 与 Web 服务结合的拟服务总线来实现集成应用及交互。 简单的 WEB 服务体系结构是一种“请求－响应”型的调用模式[30]，如图 2-5 所示。 WEB服务客户端1 WEB服务组件1 WEB服务客户端2 WEB服务组件2 WEB服务客户端3 WEB服务组件3 图 2-5 简单的 WEB 服务体系结构 在人才门户系统中，把服务的后台逻辑发布成了 Web 服务组件，基于简单 的 Web 服务调用模式，设计上比较僵化，非可扩充式的、可管理的集成方式。 采用如图 2-6 方式，实现了拟服务总线方式。 服务集成点1 Spring FrameWork 服务代理 服务接口  WEB服务组件1 服务集成点2 WEB服务组件2 远程Web服务配置文档 服务集成点2  (拟服务总线) WEB服务组件3 图 2-6 基于 Spring 的拟服务总线示意图 通过以上图所示集成模式，使服务与服务之间具有更好的扩展性、可管理 性，主要解决如下问题： (1) 可以提供对客户端请求的统一认证体制，安全措施加强,以保证服务响 应的可靠性及服务组件的协同工作[31]。 (2) Web 服务提供者与 Web 服务请求者之间松散耦合，通过配置实现可扩展 管理。 (3) 多个用户请求相同的业务逻辑操作，那么在这种结构中将对同样的业务 逻辑进行有效的重用。 (4) 可同时实现多个 Web 服务的访问，协调多个 Web 服务的调用关系及事 务控制。 综上所述，基于 Spring 的拟服务总线，相对于简单的 Web 服务体系结构， 增强了安全性和统一认证问题、业务逻辑和数据逻辑分离、业务逻辑的有效重 用[32]、同时实现多个 Web 服务的单独使用和组合使用。 2.3 本章小结 本章在介绍什么是面向服务架构基础上，重点介绍了实现基于 SOA 架构的 人才门户网站所用到的核心技术――Web 服务，及 Web 服务与 SOA 的关系， Web 服务的平台无关性，使得 SOA 的服务夸平台集成成为可能。并深入介绍了 Web 服务的三大核心协议：SOAP、WSDL、UDDI,及它们之间的关系。之后讨 论了基于 Spring 框架与 Web 服务实现拟服务总线的原理，通过 Spring 框架简易 实现不同服务之间的动态集成方式。 第3章 人才门户网站系统总体架构 前面对系统实现的核心技术进了概要介绍，本章在分析系统需求的基础 上，结合服务设计的三大原则[8]，即业务功能与 IT 系统对齐、保持灵活性及松 散耦合原则。设计出了系统的候选服务，并给出系统的总体架构，在些基础上 讨论基于 SOA 架构的优越性。 3.1 系统需求 整体业务可划分为三大门户：个人门户、院校门户、软件企业\培训机构门 户。各部份的业务需求及用例图分别如下。 1) 个人门户 系统为 4 大类用户：系统管理用户、求职用户、院校用户、企业用户，为 每个求职用户，提供一个信息发布及管理门户。 个人门户用例图，如图 3-1。 简历定制/维护 ?include?  ?include?  我的帐户信息 个人门户框架 ?include? ?include?  适合我职位 ?include? 我的关注 求职用户 ?include?  通迅信函 职位推荐 ?include? 搜索 申请职位 2) 院校门户 图 3-1 个人门户用例图 为高等院校提供宣传版块，展示院校特色、师资介绍、专业推介、人才培 养、人才库、人才推荐等内容，用例图参见图 3-2。 院校门户主页  院校宣传版块 院校门户模板风格设 置 ?include?  ?include? ?include? ?include? 院校门户框架  ?include?  院校特色 ?include? ?include?  专业推介 院校资源设置 院校用户 ?extend? 门户页面浏览  ?include?  ?include?  ?include? ?include? ?include?  人才推荐  外部系统接口 通迅信函  我的关注 人才库 培训服务 师资介绍 图 3-2 院校门户用例图 3) 软件企业、培训机构门户 为国内软件企业提供宣传版块，展示各企业特色、产品介绍、发展规划、 职位规划、职位发布、人才继续培养、资质认证等内容，用例图参见图 3-3。 企业门户模板风格设 置 企业门户主页 企业介绍 ?include? ?include?  产品介绍  职位规划 ?include? ?include? ?extend?  企业门户框架 ?include? ?include? ?include?  ?include? ?include?  资质认证 发展规划 企业用户  门户页面浏览 简历模板 ?include? 通迅信函  我的关注 ?include? 培训服务 企业外部资源定制 外部系统接口 简历智能筛选定制 ?extend? 求职简历管理  ?extend? 面试管理 图 3-3 企业/培训机构门户用例图 4) 院校与企业的人才供需交易平台 以供需交易平台为核心，提供多方位的附加功能，为各院校、企业提供便 利服务，大致包括以下功能： 供需交易平台：建立多层、多角度的关联交易平台，如：企业可与关注的 院校、院校的专业、院校的人才简历建立关联；同样建立院校与企业/培训机构/ 具有培训资质的企业、行业岗位、培训项目等关联。建立院校与企业之间双向 供需选择机制，院校选择意向的企业，向学生推荐；企业又可向意向的院校， 意向的专业人才发出邀请，也向院校提出特色人才培养申请，如图 3-4。 人才交易平台 高等院校 IT企业 培训机构 图 3-4 人才交易平台 简历定制：提供多种简历样式，各类简历可以存放在门户系统中，也可 为企业特色提供数据接口或调用企业自身的简历模板； 简历智能筛选：软件企业面对大量简历，如何才能在小范围内挖掘到所 需要的人才，系统将通过配置各企业人才要求的指标权值，提供自动筛选功 能； 搜索引擎：提供多角度的搜索方式，如院校、专业、软件企业、简历 等，提供信息展示平台，也可提供数据引擎接口，为会员单位提供特色服务； 语音视频面试室：为企业人才选拔提供便利环境，通过预约，以网络语 音视频进行初步交流、面试，从而节省双方时间及成本。 5) 行业动态、热点新闻版块 展示行业最新动态、热点新闻，及会员单位的通告、邀请等信息； 6) 行业培训/认证、咨询 列示各会员单位提供的最新行业培训、资质认证等信息，并建立相关交 易意向信息； 3.2 确定候选服务 以上节所列的业务需求及用例分析为基础，结合服务设计原则及方法，进 行服务抽象及建模，主要包括服务、服务组件、服务流程的鉴别、业务功能分 配等。 根据用例分析及业务用例规范，以自顶向下的过程来分解业务领域，鉴别 服务、服务分层及服务组件的指定。 人才门户网站，从上到下，可以划分为前台、表现层服务库、基础服务 库、数据存取层等层次。 前台主要是指服务消费者，是服务的调用及服务流程的编排层； 表现层服务库，从用例分析的结果，首先找出各门户中通用的业务功能， 可以划分出：我的关注服务、通信信函、培训、搜索引擎等服务组件； 基础服务库，从表现层服务库的服务组件设计着手，进行服务(组件)建模， 抽取出各服务组件中公共部份，进行归类，建构基础服务组件。 3.3 系统体系结构 3.3.1 架构的设计原则 在确定系统架构之时，系统中各服务组件间要保持必要的灵活性及松散耦 合性[31]，以下对架构设计的主要参考原则－松散耦合原则进行概述。 在 SOA 架构中，松散耦合指的是服务消费者到服务提供者间的松散耦合 性，体现在服务契约的约定上、抽象的层次上、技术的实现上等方式，实现 IT 系统各功能组件间的松散耦合性，主要如下： 1) 服务契约层面的抽象性 设计良好的服务应该有一定的抽象性，应该独立于具体的技术实现、接口 封装等，保持技术与业务两个方面的抽象性。 首先，要保证服务消费者与提供者之间实现上依赖性最小。 其次，要保证服务实现上的变化，对相关组装应用的变更最小，服务接口 设计要具有高度的抽象。 最后，服务的替换性，如提供方的替换、版本更新，对于服务消费者来说 可不必担心，是透明的。 2) 通过 Web 服务等技术实现服务调用上的平台无关性 服务应该建立在与平台无关的技术之上，Web 服务是首选，但不是唯一的 选择，比如消息机制、CORBA 也可以在一定程度上实现平台无关性，但 Web 服务是应用简单、广泛的技术。 首先，采用 Web 服务相关的协议，如 WSDL 和 SOAP，能够隔离协议和消 息等技术层面的关注，实现方与调用方可以屏蔽应用层面的技术异构性。 其次，技术实现上的平台无关性，可以通过一个平台进行统一管理及调 度，如为 ESB 实现提供了可能。 3) 采用隔离关注的方法保持业务架构和技术架构的清晰性[8] 业务系统和 IT 系统都涉及方面众多的系统。业务系统涉组织结构、业务流 程和监控、业务功能、业务对象、业务监控等；IT 系统又会涉及设计表示、资 源管理和安全架构等[8]。如图 3-5,如何使这些方面的依赖性尽量小，将使系统的 灵活性影响很大。 技术边界 业务边界  业务A Web 服务  Web 服务 技术1 技术2 业务B 业务C Web 服务  应用边界 应用１ 应用２ 图 3-5 采用隔离关注的方法保持业务架构和技术架构的清晰性 4) 面向对象与组件化设计方法保持更细粒度的实现上的松耦合性 应用前面 OO 设计 5 大原则及组件设计原则，在更细粒度上保持业务及 IT 实现上松耦合性，从而提高服务的内部实现上的灵活性、可扩展、可重用性。 3.3.2 人才门户的体系架构 如图 3-6 所示，整个人才门户网站以企业服务总线为交通枢纽，通过服务 总线把各项服务衔接起来。 系统前台主要包括：个人门户、企业户、院校门户、用户管理、及其他信 息发布功能，通过服务总线与表现层服务库、基础服务库中的服务关互或服务 编排。 表现层服务库为主要为业务抽象服务，如培训、我的关注、通信信函、搜 图 3-6 人才门户体系结构 索、人才推荐/分析等服务，这些服务可供多个门户共用，也可为外部系统提供 服务。 基础服务库主要为系统内的公共服务组件，为表现服务、和前台提供服 务，一般不对外公开的服务。 3.4 系统架构的优越性 传统人才门户网站的建设过程中，先开发一个个应用模块，每个应用系统 都有自己的功能模块、数据存放架构、安全保障等自成一体，开发平台、数据 库都各不一致。但随着业务模式的成熟，系统应用的不断深入，会发现不同系 统之间存在着业务关系，存在着共享关系，此时需在应用系统间进行整合，包 括表示层整合、数据整合和流程整合。 基于 SOA 架构的人才门户网站，不是以单个应用为中心，而是以服务为中 心来设计的，其涉及的界面、业务流程、组件、数据结构、具体对象抽象等是 从服务的提供者和消费调用者角度来进行层次化的。同时将应用中的公用部份 抽取出来，如集成架构、服务质量管理、系统安全、事务管理等，为所有的服 务进行共享。如表 3-1 为以传统方式开发的系统与 SOA 实现的比较。 表 3-1 以传统方式开发的系统与 SOA 实现的比较[35] 特征 传统方式 SOA 设计和实现 ? 面向功能 ? 面向协作 ? 一次性构建 ? 按变更构建 ? 长开发周期 ? 渐进地构建和部署 最终系统 ? 应用程序竖井 ? 企业解决方案 ? 紧密耦合 ? 松散耦合 ? 面向对象的交互 ? 面向语义消息的交互 如图 3-7 从宏观比较了传统的设计架构与 SOA 架构的优越性，采用 SOA 架 构后实现大量复杂、不同技术实现、多厂商服务跨时期异构系统的并存；对瞬 时变化的业务流程，经多产品组合集成能快速应变；使得服务提供商更关注于 关键业务流程域而非底层 IT 基础架构；减少冗余架构，实现跨系统架构集成； 提供更标准、及时、全面的企业服务。 3.5 本章小结 图 3-7 传统的设计架构与 SOA 架构的比较 本章先介绍了实践项目的业务需求及用例图，在此基础上给出了系统的体 系架构。基于人才门户的体系架构，讨论了传统架构与 SOA 架构的特点及后者 的优越性。 第4章 人才门网户站面向服务的建模过程 在上一章中，讨论了系统的业务需求，在分析业务基础上给出了初步的服 务组件划分及基于 SOA 的系统体系架构。 面向服务的发现及建模遵循一定的方法论及原则，下面深入讨论服务的建 模及服务的发现方法及过程，标识出系统中的服务的划分，并以全文搜索引擎 为例阐述服务建模的过程。 4.1 服务发现及建模过程概述 在人才门户分析过程中，引入面向服务的建模及设计过程，实现系统基于 业务逻辑层的最大复用，引入服务的理念，以此增强此种逻辑的表达、观察、 模型化以及共享的方式，服务建立了一个夹在传统的业务与应用层之间的高级 抽象形态。通过本项目的实践研究，总结出以下面向服务建模过程，如图 4-1 所 示。 服务将业务领域模块化，面向服务的设计的任务就是将业务逻辑进行模块 化划分，形成独立的解决方案，各服务组件实现完成独立的功能实体，各服务 之间又不是独立存在，相互组合或流程编排[34]，实现企业的业务逻辑。 现实业务 业务领域 服务架构 服务实现 服务组合 业务建 模规范 业务领域 模型  服务建 模规范  服务架构 模型  服务设 计规范 服务设计 模型  服务编 排规范 服务编排 模型 图 4-1 面向服务的建模过程 对领域模型及服务模型的描述，业界一般是以模型图及内容描述方式来表 达的，用于加强业务人员与设计人员，设计人员与开发人员之间的沟通交流， 不同的业务领域，模型图表达了业务结构的特定部分或者特定的业务状态，表 达了现实模型中的重要方面或机制。本文通过基于 SOA 架构的服务设计学习研 究及项目实践，总结出以下形式化定义： 业务领域模型 Bussiness_Domain_Model(简称 BDM), BDM={SCS,SR,ESB},其中： (1) SCS={SSM} SCS 表示服务模型框架中服务组件的集合； (2) SR 表示服务之间的业务逻辑关系及编排方式； (3) ESB 表示服务组件以某种形式部署在总线上，实现服务间智能化集成与 管理的中介； 服务模型 Single_Service_Model(简称 SSM),SM={SC,STA},其中： (1) SC 表示具体业务对应的服务组件； (2) STA 表示服务模型框架中服务规约； 从以上形式化定义，结合服务的开发过程，遵循图 4-2 流程所示，首先在需 求分析与设计阶段，引入面向服务的理念，在系统原型设计的基础上，进行公 共业务抽象设计成服务，通过对分别完成系统特有功能开发、服务组件开发 后，把服务组件进编排、组合到网站平台。 面向 服务的 分析  服务的开发  服务 的部署 面向服务 的 设计  服务的测试  服务 的管理 图 4-2 面向服务的开发过程 4.2 服务设计原则及依据的应用 4.2.1 业务功能与 IT 系统对齐 SOA 服务设计是对传统软件设计技术的继承和发展，在服务的发现与设计 阶段主参考了业务功能与 IT 系统对齐及保持灵活性设计原则。 传统的 IT 系统的生命周期中，不同的阶段关注的重点不同，如图 4-3 所 示。以上传统的过程概念的分割在很大程度上使得 IT 系统生命周期的各个阶段 彼此不一致，导致从业务到 IT 系统，从 IT 系统到业务的循环中，IT 系统处在 被动的位置。主要表现在系统对业务需求和业务变化响应慢，被构建的系统难 以表达客户及业务人员的期望值。 分析阶段 设计阶段 以用例为重点 以组件和类为 重点 编码阶段  测试阶段 以类和流程为 重点  发布运营阶段 以测试用例为 重点 以系统和业务 流程为重点 图 4-3 传统 IT 系统的生命周期与关注重点 为解决这种业务与 IT 系统的不一致性，SOA 设计方法中，将业务功能与 IT 系统对齐视为最高优先级设计原则[8]。为达到对齐的目的，各种方法被引入 到以服务为中心的 IT 系统生命周期中，这些方法主要有： 1) 把服务放在首位的设计方式转变 服务会跨越多个用例功能，服务对于需求分析、设计、部署运营及管理各 个阶段都统一的。不论对于业务服务还是软件服务，服务表现为一种功能接口 首先，为提高业务与 IT 系统的对齐程度，能够提供相对于功能接口更多的 业务到 IT 系统中的映射，如各种业务指标和业务策略也是服务定义的重要部 份。在 IT 系统中，对于服务的实现需要帮助落实这些业务要求，也要提供监控 业务目标实现的功能。 其次，帮助体现服务在 IT 系统生命周期中的各种抽象视角－－业务功能映 射视角，资源管理视角，资源配置管理视角等。每个服务都有相应的职责定义 和拥有者定义。 2) 服务有针对性的对应业务 服务必须有适当的粒度和抽象度，服务的粒度和抽象度与对技术的依赖性 是相关的，越小或越低则依赖性越强，当业务发生变化时，服务本身要求变化 的压力就越大。为了能够让 IT 系统通过尽量小的代价适应业务需求变化，要求 服务具有一定的粒度和抽象度，多数业务的变更只需通过组装服务或变更对应 的服务来实现，而不需大范围的变更或变更服务的定义。 3) 通过契约设计规范服务参与各方职责 在设计是，把服务视为首要的地位，为使围绕服务的各种参与方能够很好 的理解其职责，需要以契约设计方式描述服务在个方面的规约，实现 SOA 的开 放框架[36]。这些契约以机器能解读的方式表达，以便于服务使用的自动化，服 务质量的监控，服务契约遵守监控等。通常涉及以下契约： 功能逻辑契约：定义服务的业务描述，服务的前件和后件。 运营管理契约：定义服务的 SLA 和 QoS。 商业契约：定义服务在商业层面的术语和条件。 4.2.2 保持灵活性 为实现系统快速灵活地适应业务需求变化，除上一原则中通过服务统一系 统生命周期中的各个概念，并且通过服务契约等保持业务与系统的对应关系。 还需在各个阶段的设计和建设过程中保持灵活性。 首先，服务的抽象粒度要适合较广泛的需求。有许多业务模式，从服务的 消费者到提供者的技术路线形态或业务型态看，貌似迥异，而实质上核心业务 逻辑却基本相似。如后面研究要讨论的搜索引擎服务，在不同的应用系统中， 数据存储方式不同，有的以文本存储，有的以关系数据库存储等，数据库提供 商不同，更不说具体的表名或逻辑结构。此时对全数据库搜索看起业务搜索逻 辑完全不同，但从后面的实现讨论上可以看到，核心业务逻辑、表现逻辑基本 可做到实现上的一致性，关键看抽象的粒度是否适合需求。 抽象的层次，也可将决定业务需求与系统对齐的层次，也将可实现服务的 可替换性控制在合理的范围内，业务发生变更时，只需对系统中对应的服务作 替换变可以实现，从而提高了对业务变化的响应速度。 其次，服务的设计粒度要使服务适合组装。也有些业务核心逻辑不同，但 建立在一组公共的业务逻辑之上的。如实习系统中“关注服务”、“培训服务”等 等，业务逻辑不同，但后面的数据存取层、认证服务、事务服务等，实现都是 相同的。设计粒度的适当性可以实现细粒度服务的可复用性及扩展性。 最后，适当的技术可减少服务消费者和提供者之间对技术依赖性。比如采 用 web 服务、JMS 等，都可实现消费者和提供之间对技术依赖性降到最底。 4.2.3 服务设计的依据及流程 面向服务设计，首先是要抽取出候选服务，为什么要这个服务，服务发现 的依据是什么，在什么样的业务需求下才产生这个服务。 除了遵循服务设计的原则，在服务发现及建模过程中综合了三方面的因 素： 首先，是自顶向下的系统分析过程中抽取出可以业务独立体的业务，如本 项目中的“我的关注”、“通信信函”等，就是基于本系统的业务需求而产生的； 其次，对本公司已有系统自底向上的分析产生服务需求，抽取出应该可以 共用的业务，而在旧系统中没有独立实现的共用的业务，如“全文搜索引擎”， 旧系统中都采用数据级别的查找方式实现的； 另外，由于公司同时有几个项目在并行开发，有些很相似的业务，如“广告 服务”，几个系统中都要使用，为此抽取出独立的解决方案，并且形成独立的解 决方案。 服务的抽取过程中遵循了下面三点过程： 1)从业务领域、业务需求的业务流程逐步分解，找出各个层次的服务候选 者。 2)分析关键业务指标，验证已有服务候选者以及发现遗漏的服务候选者。 3)分析现有的系统时，也要兼顾已有的老系统，分析是否有可重用的服务存 在。 4.3 建立服务模型 在服务划分时，把服务按粒度划分为三种服务：基本服务、组合服务、合 成服务，三者的关系如表 4-1。 表 4-1 服务粒度划分 服务类型 类型描述 粒度 基本服务 是基本服务简单的组合，只是为了把具有相同功能但操 作不同的业务对象的基本服务组合到一起，形成一个对 外提供相同功能的服务。 小 组合服务 是系统提供的最小粒度的服务，或者说是原子服务。这 类服务考虑的是利用它们的可重用性，它们是组成一些 较大粒度的服务的基础。 中 合成服务 是系统里面最复杂的部分，它不是基本服务的简单堆积 到一块，它是最大粒度的服务，里面各个基本服务的关 系受到工作流程的控制。它是基本服务与工作流程的结 合。 大 通过以上对服务的分析过程及服务粒度划分，人才门户中抽取出如表 4-2 所示的“服务组件”列表，在服务粒度一栏中，划分为项目内及共享二类。项目 内指是仅在本系统可以使用的服务;共享指的是除了本项目中可以用，通过服务 契约，可以在其它项目中复用。 表 4-2 项目“服务组件”列表 候选服务名称 功能 服务粒度 业务服务组件 用户管理服务 个人、企业用户、院校用户的注 册，管理、登入管理等，用户的统 一管理服务 组合服务，共享 我的关注服务 管理个人、企业、院校等相互感兴 组合服务，项目 趣的对象 内 通信信函服务 管理个人、企业、院校等间的相互 组合服务，项目 通信 内 培训服务 管理培训信息的发布、申请、刊登 合成服务，项目 内 主动推荐服务 向企业推荐人才、向求职人推荐企 合成服务，项目 业 内 人才智能筛选服 基于人才简历及招聘信息的智能筛 合成服务，项目 务 选 内 银行收费接口服 务 与银行及相关中介的收费接口 组合服务，共享 全文搜索引擎服 提供任何基于数据库、外部文件的 合成服务，共享 务 全文搜索引擎服务 广告服务 任何网站的广告发布、刊登、管 理、计费服务 合成服务，共享 基础服务组件 数据存取服务 封装基于数据库的操作，针对 Hibernate 持久层框架上的操作封 装，通过对象化操作数据，屏蔽数 据库的差异性 基本服务，共享 续表 4-1 项目“服务组件”列表 事务服务 利用 spring 框架的事务管理机制， 基本服务，配置 通过配置来实现事务管理 应用服务组件 安全服务 利用 acegi 安全管理机制，结合 基本服务，配置 Spring 框架的配置管理，实现安全 应用服务组件 机制的动态加载 日志服务 利用 web 容器日志，与 webtrands 基本服务，配置 结合，分析网站的访问日志、页面 应用服务组件 频率、瓶颈。 在建立了服务清单后，需要根据它来建立服务模型，部份服务及调用关系 参见图 4-4。 1.1我关注的院校 1.2. 我关注的企业 2.1查询接口 2.2. 查询设置 我的关注 1.3.我关注 调用 的培训  搜索服务  2.3.资源 接口设置 调用 调用 调用 3.1.广告发布 3.2.广告订阅 3.3.广告管理 调用 3.4.广告计费 广告服务 4.1 院校用户 4.2. 企业用户 4.3. 求职用户 4.4.用户管理 用户管理服务 图 4-4 服务模型及关系图 下面以“全文搜索引擎服务”及“广告服务”二个服务为例进行详细分析 及建模。 4.4 全文搜索引擎服务建模 在项目中涉及从多个门户中查找结果，如从个人门户中查划个人基本资 料，从院校门户查划院校的招生信息，从企业门户查找招聘等信息，每个门户 中又涉及数个表，字段类型各异，有的数值类型，有的是字符类型。 基于数据库 SQL 语句的查找，面对众多的表结构及大量数据量，查询 SQL 语句的设计是非常复杂的过程，与各个项目紧密结合，扩充困难，查找性能也 难得到保证。 不同的系统中都需要查询搜索功能，是否可以设计成一个较通用服务组件 呢？ 4.4.1 业务流程分析 决定了业务领域及内容后，要进一步分析该业务流程，下面以用例来描述 业务流程。 表 4-2 搜索引擎业务流程 用例名称 搜索服务 编写 主要参与者 网站用户 其他参与者 业务事件 访问者需搜索站内资料 用例概述 该用例是用来描述站内资料搜索的业务过程 约束条件 业务规则 用户输入要查询资料的关键字 在用户可承受的范围返回查询结果 业务过程 1）用户选择查询范围并输入查询关键字 2）系统过滤用户查询条件，存在“敏感”关键字则转到７步。 3）根据查询范围的组织查询语句，可能多个语句 4）执行查询语句，返回结果，出现异常转到第７步 5）组织查询结并按关键字的出现频率进行排序 6）返回查结果 7）异常处理 对于以上基于常规的 SQL 语句的搜索过程，从业务的角度看，存在以下不 如意的地方。 1) 扩展困难性，当有新的查询范围增加时，要更改 3－5 步的处理过程，成 本及代码的复杂度随着增加。 2) 可重用性差，每个系统开发者要独立实现搜索过程代码，重用性差。 3) 性能难以保证，随着数据量的增加，基于数据库的查询，性能难以保 证。 对于搜索业务,可建立一个高效、快捷的检索单元[37]，对于所有系统来说， 都应该是一个黑盒子，用户订制输入查询条件及操作界面，查询服务返回结 果，示意图如图 4-5。 查询操作界面 查询结果 搜索服务 DB文本文件 DB 图 4-5 搜索业务流程示意图 针对图 4-4 的业务流程，把搜索功能扩充抽象为全文搜索引擎服务，业务流 程图如表 4-3。 表 4-3 全文搜索引擎服务流程 用例名称 全文搜索引擎服务 编写 主要参与者 网站用户 其他参与者 服务调用者 业务事件 访问者需搜索站内资料 用例概述 该用例是用来描述站内资料搜索的业务过程 约束条件 基于 Compass 框架实现服务功能 业务规则 用户输入要查询资料的关键字 在用户可承受的范围返回查询结果 业务过程 1) 服务初始化 – 设置搜索数据范围，包括数据库中指定的表或文本存放目录 等 – 生成基于文本的搜索树 2) 搜索过程 – 用户选择查询范围并输入查询关键字 – 系统过滤用户查询条件，存在“敏感”关键字则转到异常处理 – 调用搜索服务返回搜索结果 3) 对查询结果进行封装 – 返回查询结果 – 异常处理 通过以上业务流程的重新设计，实现了业务功能与 IT 组件的对齐，任何用 户需使用该搜索服务，可以通过装配使用该服务，该服务具有了良好的扩展 性、可重用性及性能保障性[38]（基于 Compass 架构的搜索算法来保证）。 4.4.2 建立服务模型 我们为全文搜索引擎服务职责的原则是“功能逻辑上独立于其它服务，与具 体应用系统独立的业务逻辑”。因此搜索服务对外只需提供三个主要接接口，如 图 4-6 所示。接口功能如下： 1）查询接口，传入要查询的关键字及过滤范围，比如要搜索“SOA 培训”， 可以在全系统范围内搜索，也可以限定更小的范围，如仅在企业门户中搜索。 全文搜索引擎接口 1.查询接口 2.设置表现层规则 全文搜索引擎服务 3.设置资源层规则 图 4-6 搜索服务的接口 2）设置表现层规则，主要处理以下业务问题：表现层查询范围的设置， 查询结果跳转的 URL。通常对基于数据库的查询情况，不同的表不同的字段 要跳转到不同的页面来处理。通常以 XML 配置文件方式传入。 3）设置资源层规则，主要包括二个方面，与资源层的接口、资源层具体 的表、字段等与检索目标的对象，搜索服务据此来生成查询找树。 4.5 广告服务建模 网站靠什么来赢利,不外乎是靠收取会员费、服务费、广告费，其中绝大 部份网站的收益来自广告收费。广告的解决方案是本项目的一部份，经过全 面分析，把广告的发布、刊登、计费等业务抽取出来，用独立的解决方案来 实现。 4.5.1 业务流程分析 网站广告传统模式是跟广告提供商签订广告后，在网页上手工放上相关资 料，比如图片、文字、flash 等，当广告到期或想更换新的广告时，都要手工 进行网页修改，再重新发布及重启服务器。 本项目针对广告的发布、交费管理、广告投放方式，抽取出一个广告服务 组件，通过规范的契约，可以在任何页面上进行动态集成。参见图 4-7 为广 告发布模式，图 4-8 为广告订阅模式，从整体上描述了广告的运行模式。 图 4-7 广告发布模式 图 4-8 广告订阅模式 图 4-9 为广告信息流示意图，描述了广告发布及展示的关系，广告提供商 只管广告发布，广告消费者只管广告的订阅，把二者责职从业务上进行分 割。 图 4-9 广告信息流示意图 图 4-10 为广告服务资金流示意图，描述了广告发布及展示的关系，广告 提供商发布广告时，要进行付费，广告消费者在消费广告时，可能获取收 益。 4.5.2 建立服务模型 图 4-10 广告服务资金流示意图 我们确定广告服务职责的原则是:功能逻辑上独立于其它服务，与具体应 用系统相互独立的业务逻辑封装，业务上通过约定的契约进行交互。参见图 4- 4 的服务模型，进一步细分，划分出二个服务，如图 4-11 所示。 广告服务接口 1.广告获取接口 2.广告计费接口 广告消费服务 3.广告资源接口设置 1.广告发布接口 2.广告审批接口 广告提供服务 3.广告计费统计接口 1) 广告消费服务 图 4-11 广告服务接口 任何广告消费者，只需调用该服务，就可从广告库中动态获取服务。先设 置广告资料类型，然后就可直接调用广告获取接口，在展示广告的同时，产 生计费点数。 2) 广告提供服务 任何广告提供商需要刊登广告，只需调用提供服务，提交相关资源及计费 方式，之后管理员进行广告审批，此时广告发布通过，消费者可以根据需要 消费所提供的广告。同时，广告提供者可以随时查询统计广告费的计费情 况。 4.6 本章小结 本章结合服务的设计原则与方法进行服务分析与发现，确定了系统的候选服 务模型，并以全文搜索及广告服务为例，展开讨论了面向服务的服务分析及建 过程。接下来的章节，将展开讨论服务的具体实现过程。 第5章 服务组件设计与实现 从业务领域找出业务服务组件是一项重要的工作，业务服务划分的范围及 大小，直接影响着系统的整体架构的扩展性及稳定性。在找出服务组件之后， 怎样进行具体服务的设计及开发，也是一项重要的工作，服务组件承担着具体 业务逻辑的实现，服务组件的质量，直接影响系统的质量，更决定着的服务的 可用性、复用性及一致性，对服务组件设计过程的研究也是本文的重点及难 点。 5.1 服务设计过程概述 服务组件的设计过程[35]，如图 5-1 所示，大致 4 种层次的服务层次的设计 过程： 意图： 与业务及流程无关的、公共的、底层的服务 基础应用 基础应用服务设计 基础业务服务设计 实体业务服务设计 设计业务服务流程 日志服务、事务管理、数据持久操作层服务、 系统安全服务等 意图： 较原子化的业务服务，与针对单一业务的独立 解决方案与业务流程无关，会集成、调用基础应 用服务 实例： 用户管理，搜索引擎、银行收费服务等 意图： 真实、具体的业务服务的虚拟，反映现实业 务的业务逻辑，会调用上面二层的服务设计结果 实例： 广告服务、我的关注、主动推荐等 意图： 收集业务流程，组合实体业务服务，模拟真 实业务流程 实例： 广告服务、人才推荐、人才分析等 图 5-1 服务设计层次划分 上面的层次划分是一个大致的过程及原则，实际设计中服务的划分并不总 是很清晰，如广告服务，对一个项目而言，是独立的解决方案，就广告服务自 身而言又是许多服务＋流程编排的结果。 针对每个层次服务都需遵循一定的服务设计过程，如图 5-2。由于篇幅问 题，下面以全文搜索引擎服务及广告服务的实现为例，深入讨论服务的设计过 程。 面向服务的 分析  审查现存服务 服务的框架设计服务规约设计面向服务的 设计基 服务的框架设计 服务规约设计 面向服务的 设计 基础应用服 务设计 服务的开发 基础业务服 务 务设计 ， 组 服务接 服务接口设计 或 实体业务服 实体业务服 务设计 服务的 服务的测试 新 设计服 设计服务组件逻 辑 务 服务的部署设计业务服 务流 服务的部署  应用/组合基础 服务 服务的管理  扩展服务设计 图 5-2 基础业务服务设计流程 5.2 全文搜索引擎服务设计 对全文搜索服务的实现，本文结合 Compass 框架，实现全文搜索引擎服 务，通过简单的配置，实现搜索引擎服务于不同的项目中，无需重复开发。。 搜索引擎服务内部实现，等同于一个构件，找分为多个层次，如表现层、 接口层、逻辑层、数据集成层，不同层之间以 Spring 的 IoC 实现动态集成，层 与层之间的示意图，概述如下，参见图 5-3 所示。 1）搜索服务表现层 作为搜索引擎的条件输入、搜索结果的展示，主要是一些 html 页面，当然 也可以是其它展示方式。为体现表现的性能及操作的友好性，表现层通过 Ajax 方式异步调用搜索服务接口层。 2）搜索服务接口层 约定正式接口规范，把业务逻辑封装成 Web 服务方式，以 WSDL 描述服 务，通过 SOAP 协议与搜索服务表现层通讯。这一层的接口方式，提供了与其 它服务的集成的通用性。 搜索服务表现层搜索页面 搜索服务 表现层  搜索条件 搜索页面 Spring Spring FrameWork(ESB) 搜索服务 接口层 搜索服务 搜索服务 业务逻辑层 搜索对象 组件 compass 接口封装 COMAPSS 搜索引擎 Compass 接口配置文件 资源层持久对象 外部静 资源层 DB 图 5-3 面向全文搜索引擎服务框架 3）搜索服务业务逻辑层 Compass 是建立在 Lucene 搜索引擎之上的抽象搜索引擎[39]，利用 Compass 框架，从数据库或文件中读取数据，通过分词算法，建立文本索引结构，这样 屏蔽资源层的差异性。 定义搜索逻辑业务组件，调用 compass 接口，完成查询条件向查询结果的 转换与封装，并增加分页处理机制，及一些敏感信息的过滤处理。 4）资源层 查询的外部资源可以是各类数据库，也可是静态文件，资源层是多种多样 的。 5）服务内部集成 为现实组件内部的可扩展性及可维护性，遵循 OO 设计的原则，如“开－闭” 原则[40]，层与层之间采用 Spring 为代表的轻量级开发框架，通过 Spring 的 IoC 机制，实现服务组件内部不同层的松耦合绑定，动态加载及替换。 5.2.1 服务规约 服务规约见表 5-1 描述了“全文搜索引擎服务”的功能特性、接口规范、部署 服务的环境要求，作为服务共享调用时的参考规范。 表 5-1“全文搜索引擎”服务规约 服务描述 全文搜索引 擎 服务名称 Search Service 服务组件类型 业务服务 设计人 温尊荣 设计日期 2007-3-1 功能特性 基于数据库及外部文本文件的全文搜索引擎，只需配置数 据层接口就可完成全文搜索功能，也可扩充自定分词算 法。通过 Web 层页面嵌入搜索条件输入页面；通过页面 url 及传入参数，可以返回查询结果的页面；通过 web service 接口，可直接调用后台逻辑层接口 非功能特性 支持浏览器模式，查询响应时间不得超过 6 秒，每页返 20 条符合搜索条件的记录 部署要求 基于 Java 开发环境，需 jdk1.5 以上，要引入 spring.jar, hibernate.jar, compass-1.1.jar,lucence.jar 等一系列 jar 包 服务提供的接口 接口名称 接口描述 接口类型 Search/index.jsp 通过 web 页面嵌入搜索条件输入页面, 返回结果页面是：Search/result.jsp 页面接口 Search/index.jsp？ q=SOAlang=zh_C Ntype=1 传入参数的 URL， 返回结果页面是：Search/result.jsp 页面接口 HYPERLINK http://./ http://../ SearchQ /services/SearchQ?ws dl Web Service WSDL 接口描述 Web service 接 口 续表 5-1“全文搜索引擎”服务规约 commService.js 通过 js 封装了 Web Service 调接口，js 函数调用搜索引擎接口 Js 接口 服务依赖 Compass 搜索服务 5.2.2 服务接口设计及实现 搜索引擎服务是对基础数据源的搜索实现，包括二个方面的接口： 1）资源层接口 》 持久层与检索目标的对应关系 基于 compass 的配置要求，配置与持久层（Hibernate 的持久对象）的对 应关系，主要配置*.cmd.xml 文件，为 compass 与对象的属性对应接口,内容如 下： compass-core-mapping package=com.SearchQ.datamodel.hbm class name=CorpInfo alias=${SearchQ.corpInfo} id name=corpInfoId / property name=corpIntro meta-datacorpIntro/meta-data /property property name=surroundings meta-datasurroundings/meta-data /property property name=dishType meta-datadishType/meta-data /property property name=corpType meta-datacorpType/meta-data /property component name=corpReg