（计算机软件与理论专业论文）基于wcf面向服务架构的研究与应用.pdf

摘要 在分布式应用软件开发领域，面向服务架构是新一代的软件架构思想，由于 它具有良好的松藕合、与平台无关等特性，很好的解决了系统的灵活性和互操作 性。面向服务架构具有很广泛的应用，目前它已成为企业应用集成以及企业新系 统架构的主要解决方案。 本文从软件体系结构的发展历史出发，分析了各个阶段软件体系结构模式的 特点及不足，阐述了面向服务的软件体系结构出现的必然性，结合面向服务方法 学以及w c f 技术，论述了如何基于w c f 技术设计并且实现一个企业级的面向 服务架构。该面向服务架构主要实现了对服务的发现、发布、订阅以及信息管理 等功能，使服务得到了统一的管理和统一的使用。最后本文以安全教育系统为例， 论述如何将该架构应用到实际的软件系统开发中。 关键字：面向服务架构w c f 软件体系结构分布式应用系统 a b s t r a c t s e r v i c e o r i e n t e da r c h i t e c t u r e ( s o a ) i sai l e wg e n e r a t i o no fa r c h i t e c t u r e i d e o l o g ya p p l y i n gf o rd i s t r i b u t e ds o f t w a r ed e v e l o p m e n t s o ah a ss o l v e dt h ep r o b l e m s o fa p p l i c a t i o n sf o rf l e x i b i l i t ya n di n t e r c o n n e c t i v i t yw o n d e r f u l l yb e c a u s eo fi t sf e a t u r e s o fl o o s ec o u p l i n g , i n d e p e n d e n to fp l a t f o r me t c s o aw i l lb ea p p l i e dw i d e l ya sa l l e f f i c i e n ts o l u t i o nt oe n t e r p r i s ea p p l i c a t i o ni n t e g r a t i o na n dn e ws y s t e ma r c h i t e c t u r e b e g i n n i n g w i t ht h ee v a l u a t i o nh i s t o r yo fs o f t w a r ea r c h i t e c t u r ea n dt h ef e a t u r e so f t h e s ea r c h i t e c t u r e s ，t h i s p a p e ra n a l y s e s t h e i n e v i t a b i l i t y o ft h e e m e r g e n c e o f s e r v i c e - o r i e n t e da r c h i t e c t u r e b a s e do nt h et h e o r yo fs o aa n dw c f t e c h n o l o g y , t h i s p a p e rd e s i g n sm o d e la r c h i t e c t u r ea d a p t i n gf o re n t e r p r i s ea p p l i c a t i o n t h i sa r c h i t e c t u r e i m p l e m e n t sf u n c t i o n s ，s u c ha s t h ed i s c o v e r yo fs e r v i c e ，t h er e l e a s eo fs e r v i c e ，t h e s u b s c r i p t i o no fs e r v i c ea n di n f o r m a t i o nm a n a g e m e n t b yt h i sw a ys e r v i c e sw i l lb e m a n a g e da n du s e du n i f e d l y f i n a l l yt a k i n gs a f ee d u c a t i o ns y s t e mf o re x a m p l e ，t h i s p a p e rs h o wt h ew a y o fi m p l e m e n t i n gt h i sm o d e la r c h i t e c t u r ei nr e a ls y s t e m k e yw o r d s ：s e r v i c e - o r i e n t e da r c h i t e c t u r ew c f s o f t w a r ea r c h i t e c t u r e d i s t r i b u t e da p p l i c a t i o ns y s t e m 长春理工大学硕士学位论文原创性声明 本人郑重声明：所呈交的硕士学位论文，基于w c f 面向服务架构的研 究与应用是本人在指导教师的指导下，独立进行研究工作所取得的成果。 除文中已经注明引用的内容外，本论文不包含任何其他个人或集体己经发表 或撰写过的作品成果。对本文的研究做出重要贡献的个人和集体，均已在文 中以明确方式标明。本人完全意识到本声明的法律结果由本人承担。 作者签名：丕爱亟望班上月丝日 长春理工大学学位论文版权使用授权书 本学位论文作者及指导教师完全了解“长春理工大学硕士、博士学位论 文版权使用规定 ，同意长春理工大学保留并向中国科学信息研究所、中国 优秀博硕士学位论文全文数据库和c n k i 系列数据库及其它国家有关部门或 机构送交学位论文的复印件和电子版，允许论文被查阅和借阅。本人授权长 春理工大学可以将本学位论文的全部或部分内容编入有关数据库进行检索， 也可采用影印、缩印或扫描等复制手段保存和汇编学位论文。 作者签名： 年三月竺同 指导刷隘名丘函弘年月上日 4 7 1 1 本文的研究背景 第一章绪论 企业信息化大大提高了企业的竞争力，缩短了业务执行的周期，提高了业务 交互的效率，为公司未来发展决策提供了强有力的数据分析。然而，实施信息化 后企业和软件开发商又面临着新的挑战：如何在多个孤立的系统之间实现有效的 信息共享，如何对业务的新需求做出快速的响应等等。传统的软件体系结构已经 无法满足软件复杂性迅速增长的需求。业界提出面向服务的体系结构作为软件体 系结构的下一个发展阶段，来帮助软件开发商解决新时期软件开发中存在的问 题。面向服务架构可以将其现有的资产带到未来同时又构建新的应用程序系统。 一般企业应用都是以应用为出发点去设计和开发的，也就是以公司部门为基 本单位设计和开发管理系统，各个系统之间相互独立，互不相扰。随着公司规模 的扩大，独立系统的功能和数量一直都在发生着变化。单独从公司一个部门或者 一个子系统的角度去考虑，可能不会发现任何漏洞。然而，人们很快就会意识到： 大多数的业务和服务不是在一个子系统内或者一个部门就可以完成的。i t 技术 正在迅猛的发展，子系统的开发时间不同，所采用的技术自然也很有可能不同。 一个业务请求很难在不同开发工具实现的子系统间实现有效的调用。面向服务架 构应运而生，它把子系统能够实现的功能划分为粒度不同的服务，子系统之间的 功能调用转换为服务的调用。 在各个子系统之间，功能重复的概率是很高的，人们提出各种软件复用来解 决重复开发的问题。面向服务架构的出现，给软件开发人员提供一个更行之有效 的、复用力度更大的方法，它将传统的技术层面的复用提升到商业逻辑层面的复 用，将企业的需求划分成服务，然后按照商业规则组合这些服务，以满足不同使 用者的需求。 1 2 国内外研究现状 1 2 1 国外研究现状 大型i t 组织构建和部署面向服务架构应用已有多年历史，i b mc i c s 和b e a t u x e d o 就是过去被用于构建面向服务架构应用的两种技术范例。面向服务架 构【1 】系统原型的一个典型例子是通用对象请求代理体系结构f c o m m o no b j e c t r e q u e s tb r o k e r a r c h i t e c t u r e ，c o r b a ) ，它已经出现很长时间了，其定义的概念与 面向服务架构相似。在分布式系统开发领域，已有的技术有n e tr e m o t i n g 远程 调用机制，m s m q 离线队列调用机制，w e b 服务等。w c f 服务是对已有的分布 式系统开发技术的整合，是下一代分布式系统开发的基础平台。 1 2 2 国内研究现状 s o a 2 的概念很早就被提出，不过由于中国企业客户的软件管理应用与国外 发达国家状况不同，这决定了中国s o a 路线图必然不同。通常来讲，当一个中 国企业实施s o a 策略时，往往需要解决好服务构造、服务管理、服务流程和服 务治理等四个方面的问题。这其中，服务治理是s o a 实施进入成熟阶段后，需 要解决的问题。服务管理和服务流程则可通过目前国外众多厂商所提供的企业服 务总线( e s b ) 、业务流程管理( b p m 、) 等方案得到较好解决。但对于中国企业实施 s o a t 3 j 最为基础也是最为关键的是“服务构造”这一环节，包括服务的规划、标准、 实现等，这才是中国客户必须马上面对却难以逾越的鸿沟。w c f 技术正是解决 服务构造，实现服务合理规划、规范标准以及统一实现的最佳解决方案。 1 3 本文的主要内容及结构 1 3 1 本文的主要内容 本文将从分析软件体系结构的发展历史入手，研究并总结各个阶段软件体系 结构模式的特点及不足，阐述面向服务的软件体系结构出现的必然性。在此基础 之上，将结合面向服务方法学以及w c f 技术，研究如何基于w c f 技术设计并 实现一个企业级的面向服务架构。主要工作内容包括： ( 1 ) 根据面向服务架构的需求分析，对面向服务架构进行总体的设计，并对 其两个子系统服务发布订阅子系统和服务管理子系统进行研究和设计。 ( 2 ) 重点研究如何通过面向服务架构实现服务的发现、发布、订阅以及服务 信息管理等功能。 ( 3 ) 以安全教育系统为例，研究如何将该面向服务架构应用到实际的软件系 统开发中。 从而实现对服务进行统一的管理和统一的使用，达到提高软件开发的效率， 增进系统管理的效率以及增强软件复用度的目标，最终实现在系统架构层面彻底 贯彻面向服务的思想。 1 3 2 本文的结构 第一章：介绍了本文的研究背景、国内外研究现状、本文的主要内容和论文 结构。 第二章：介绍了传统分布式应用系统体系结构的特点及不足，在此基础上引 出面向服务的软件体系结构，并阐述了面向服务架构的特点和原则。 第三章：介绍了w c f 的基本概念以及服务开发管理方面的高级技术。 第四章：研究如何基于w c f 技术设计并实现面向服务架构。 第五章：以安全教育系统为例，研究如何将面向服务架构应用到实际的软件 开发中。 第六章：对论文研究工作进行总结，提出不足以及展望下一步工作。 第二章面向服务架构 2 1 传统分布式应用系统体系结构 所谓分布式应用系统体系结构【4 】，是指以计算机网络为基础，将应用系统的 数据与功能分布在地理上的不同位置，通过透明的数据与功能连接而进行辅助决 策的信息系统。严格来讲，分布式应用系统最为适合分布式组织的企业和单位。 由于分布式应用系统是以计算机网络为基础组建的，所以它必然是一种分层结 构，它的发展经历了从两层到n 层的过程。 2 1 1 客户机f i s t 务器结构 两层客户机服务器( c l i c n t s e r v e r ，c s ) 1 5 1 - 6 】结构将整个系统分为两个功 能模块，第一层是应用系统的客户端，执行表示逻辑和业务逻辑，接收用户的指 示操作并显示反馈结果。第二层是服务器端，通常专用于运行一个关系型数据库 管理系统。应用软件在服务器端进行的操作主要是数据存储和检索，其他的业务 逻辑操作和界面操作都在客户端。在两层模式中会有部分逻辑以存储过程和触发 器的形式存储在服务器端，以优化服务器的性能，但绝大多数的应用逻辑放在了 客户端。如图2 1 所示。 图2 1 客户机服务器体系结构组成 客户机服务器结构是个开放的体系结构，不仅数据库要支持开放性，整个 系统也要具有开放性，这种开放性包括用户界面、软硬件平台以及网络协议。利 用这些开放性特点在客户机上提供应用程序接口以及网络接口，使用户仍可按照 他们熟悉的、流行的方式开发客户机的应用。 4 ( 1 ) 客户机i j 及务器结构的优点口兀阳 这种两层结构的客户机服务器系统是对以前单机系统的扩展，解决了执行 效率和多用户同时使用等问题。 1 ) 客户机l j 磺务器模式节省基础设施的投资，用户不但能够从自己桌面上的 p c 机访问和操作大型计算机上数据库的数据，同时使用p c 机和工作站还可以提 供过去只有大型机才具有的计算能力，且价格只有大型机的几分之一。 2 ) 客户机i j 及务器模式支持和倡导标准化和开放系统。客户机和服务器都可 以在不同的软硬件平台上运行，使用户从专有的体系结构中解放出来。是价格低 廉、易于组合的体系结构，解决了可根据应用需要而进行系统扩展的问题。 3 ) 客户机i j 及务器模式能使多个用户共享硬件资源，如打印机、扫描仪和传 真机等。显而易见，共享资源要比独占资源精简得多。 ( 2 ) 客户机i j 艮务器结构的缺点口r 阳3 分布式软件体系结构通常基于这种两层的客户机服务器模型，因而组成系 统的核心组件是客户程序和服务程序，其中客户程序提出信息或服务的请示，而 服务程序提供这些信息和服务。但是随着应用程序的规模不断扩大和应用程序的 复杂性越来越高，两层的客户机服务器模式逐渐显出了它的局限性。 1 ) 由于客户端和服务器直接连接，服务器将消耗部分系统资源用于处理与 客户端的连接工作。当客户端数目激增时，服务器端的性能会因为负载过重而大 大衰减，导致系统整体运行效率的大大降低甚至全面崩溃。 2 ) 在此结构中，唯一在线的数据库服务器成为系统可靠性的极大隐患。如 果数据库服务器因为某种原因停止工作，那么整个系统将瘫痪。 3 ) 客户端应用程序的分发维护工作繁琐。客户机上将业务逻辑和表示逻辑 混合在一起，这为维护带来难以想象的难度。系统开发过程完毕，随之而来的程 序分发除了要求为每台客户机安装客户端程序的执行文件以外，还要求安装程序 运行所必须的软件环境等许多要求。另外，还必须完成每台客户机与服务器的连 接配置工作。不仅如此，每台客户端的修改和升级，又意味着上述分发过程的又 一次重复。 2 1 2 三层多层架构 为了解决客户机月艮务器结构带来的问题，软件设计人员开始对原有的应用 系统体系结构进行改进，设计出了分布式多层应用程序结构阳3 。这种结构的最大 特点就是将用户外观层、业务逻辑层、数据层层次分明的彻底分离，使每一层独 立出来，因此也经常被称为三层结构。这种结构使得应用系统的可维护性和可扩 展性等大大提高，各层的修改对其他层的影响降到了最低，特别使用于一些大中 型系统的开发。 通常情况下，我们按照上述三层的概念认为应用系统包含了以下三个核心层 次，如图2 2 所示n 0 1 1 。 表示层：负责用户界面和外部接口逻辑。 应用层：负责核心的商业规则及业务逻辑。 数据层：负责读取和更新存储器中的数据。 图2 2 三层架构的组成 将整个系统的逻辑分解到不同层次来执行，更易于复用。事实上，用户需求 总是在不断地变化，但是通常情况不会对整个系统进行变动，变化的只是系统的 一部分功能或一部分逻辑。将表示逻辑，业务逻辑和数据逻辑分离，能够将变化 局限在某一部分，降低修改对系统整体的影响，从而有助于提高系统的可扩展性 和可维护性。 采用三层架构的优点如下n 2 n 1 4 3 ： ( 1 ) 可以对任务进行合理分配。 ( 2 ) 有利于提高系统的性能，使中间层的业务逻辑处理与数据层的业务数据 紧密结合在一起，而无需考虑客户的具体位置。 ( 3 ) 中间层服务器能够满足新客户机的需求，可以大大提高三层系统的可伸 缩性。 ( 4 ) 在客户机的应用程序和数据层的数据库之间增加中间层，可以使客户机 的应用程序独立于数据层的数据库。 ( 5 ) 可以将业务逻辑集中到一起，有利于系统的实施和部署。 对于三层c s 结构，当系统规模扩大后，只要增加中间构件中间层应用 6 服务器，便可不断地扩大系统规模。如果每个中间构件所管理的客户机保持在其 最大允许值以内，则系统性能几乎不会下降。 2 1 3 基于组件的分布式体系架构 ( 1 ) 多层体系结构存在的不足n 5 1 多层分布式应用体系结构己被广泛使用，因为程序员编程简单，无需从其他 源程序输入。但这种方式也存在问题。 1 ) 应用功能不能被重用。业务功能只适用某一特定的程序和平台，而不能 用于其他程序。 2 ) 当分布式系统扩展时很难调试和维护。不同目的的代码混在一起，改变 其中某一代码势必会影响到其他相关的代码。 3 ) 安全性也是一个问题。因为用户界面不能和其他程序分离，这就使当系 统自然扩展时在操作系统上应用安全机制很困难。例如，用户界面不能用防火墙 与业务逻辑分离。 4 ) 系统的可伸缩性几乎不可能，因为在几台计算机上扩展系统或在数据访 问量增大时添加计算机是很难实现的。 组件技术的发展在一定程度上解决了上面涉及到的局限性。组件是一个应用 程序及的独立的软件单元，它是为特定功能设计的，而不是为特定应用程序设计 的。在基于组件的方法中，特定领域的开发人员配合开发小组的工作，可以提高 开发效率从而缩短开发时间。尤其在大型应用程序中，开发所需的专业人员可能 分布在不同的组织内。 ( 2 ) 组件技术 使用任何编程语言都可以实现和构建组件，只要该编程语言支持特定组件标 准的接口规范。组件技术的基本思想是：将大而复杂的软件应用分解成一系列的 可先行实现、易于开发、理解和调试的软件单元，即组件。 使用组件的最基本的目的有两个：实现代码的可复用性和使用接口。正确使 用接口可以带来诸多好处，如功能完善的实体以及应用程序的并行开发。在应用 程序的“装配 中，使用组件最能体现组件的优点。一个软件组件是由预定义的 接口和上下文依赖关系组成的复合系统的一个单元。一个软件组件可以独立的进 行配置，并且可以由第三方进行组合。 组件的优点是多方面的，主要有以下几点： 1 ) 独立性。一个组件具有更好的通用性，它独立于应用程序。 2 ) 可重用性。组件是可重用的事物。与特定问题的特定解决方案相比，组 件具有更好的通用性，可以在不同的环境中重复使用。 3 ) 自定义。单个组件可被自定义，从而使其满足特定需求。而现有的组件 7 就可以被自定义来满足这些需求。 4 ) 可装配性。几个组件可以装配成新的系统或组件。 5 ) 便于升级和维护。对单个组件进行升级可以避免在对整个系统进行升级 时存在的大量的升级工作量的问题。 6 ) 位置的透明性。根据组件所提供的功能，组件可以在网络的任何位置工 作。 7 ) 可分布性。使用分布式计算机系统组件，例如c o r b a 、d c o w c o m 、 j a v a b c a n ，使组件可以分布在整个网络中。 ( 3 ) 组件技术的不足 在现代分布式应用软件环境中，基于组件的分布式应用体系结构的问题又出 现了，这就是编写共享的组件存在问题。因为不同的编程语言有时并不兼容，例 如使用c + + 编写在c + + 环境中运行的组件在v i s u a lb a s i c 语言环境中运行就有困 难。这是由于组件的加载和调用方式不同造成的。 即使上面提到的跨语言问题解决了，还有一个问题就是在不同平台上共享组 件是很困难的。例如，从j a v a 程序中调用c o m 对象，或从v i s u a lb a s i c 程序中 调用c o r b a 对象。过去我们使用的组件模式不能很简单的实现跨平台的内部操 作，更不用说在防火墙之外调用外部对象了。当新的基于组件的软件系统需要从 另一个不同平台上的基于组件的软件系统调用数据时，。过程是这样实现的：考虑 业务规则和数据都隐藏在用户界面之后的典型基于组件的软件系统，为了从一台 计算机中将信息调入另一个不兼容的系统中，用户需要人为地在一个屏幕上读取 数据，然后将其输入到另一个屏幕。如果没有用户界面，为了共享信息，一些整 合代码就必须在两个平台上都编写，这就造成了所谓紧耦合。以至于界面难以编 写、难以维护，并且不稳定，对任意程序进行改动就会容易导致所有程序失效。 2 2 面向服务架构 在软件工程发展的历程中，人们一直遵循这样一个模式：每个新的方法学和 技术都会融合前一代技术的优点，并致力于改善前一代技术的缺点。然而，每个 新产生的技术又会面临新的挑战。所谓的现代软件工程，就是对过去技术的去芜 存菁，降低耦合程度。但是，耦合虽然糟糕，它却是不可避免的。一个绝对解耦 的应用程序毫无用处，因为它不具有任何价值。开发者只能通过耦合其他内容， 才能为系统添加职责。编写代码的行为就是将两个内容关联起来。真正的问题是 耦合的范围有多宽。好的耦合是仅限于业务层的耦合。开发者通过实现系统用例 或特性，将软件的功能结合起来。坏的耦合则将所有的内容都集成在一起。 面向服务方法学h 们作为应对面向对象以及面向组件缺陷的解决方案呈现在 人们面前。在面向服务的应用程序中，开发者只需要关注于业务逻辑的编写，以 8 及通过可交换、可互操作的服务终结点暴露业务逻辑。客户端调用这些终结点， 而不是服务代码或者它的实现包。客户端与服务端的交互基于标准的消息交换， 服务发布各种标准元数据，描述服务的功能，以及客户端调用服务操作的方式。 服务的终结点是可重用的，在交互的约束下，服务是与客户端兼容的，而与客户 端的实现技术无关。 从多个角度来看，服务都是组件的一个本质上的飞跃。在软件行业中面向服 务是我们目前所知的构建可维护、健壮的以及安全的应用程序的最佳方案，也是 最可行的方案。 2 2 1 面向服务的价值 面i e j e 务包含了许多广受欢迎的价值n 7 1 ，例如跨技术的互操作性，就是核心 价值的体现。虽然不借助与服务，我们也能够实现互操作性，但是到面向服务的 诞生，才能都应用到实践中。两者的区别在于后者能够通过已有的公共基础功能 为开发者提供互操作性。编写服务时，通常不用考虑客户端执行在什么平台上， 因为面向服务完全实现了无缝的互操作性。面向服务应用程序所能提供的不仅仅 是互操作性，它还允许系统跨越边界。其中一种边界就是技术与平台的边界，跨 越这样的边界则完全体现了互操作性。但是，边界可能还存在于客户端与服务之 间，例如安全与信息边界、地域边界、组织边界、时区边界、事务边界，甚至是 业务模型边界。无缝地跨越这些边界是有可能的，原因是基于消息的交互标准。 例如，保障消息安全的标准，建立客户端与服务安全交互的标准，即使交互双方 存在于不具有直接信赖关系的域中。事务标准允许客户端的事务管理器将事务传 递到服务端的事务管理器，并让服务参与到事务中，即使两个事务管理器从来没 有直接登记彼此的事务。 2 2 2 面向服务应用程序 一个面向服务应用程序只是简单地将服务组合到单一逻辑的、整体的应用程 序中，这类似于聚合了对象的面向对象应用程序。如图2 3 所示n 钔。 9 图2 3 面向服务应用程序 应用程序自身可以将组合服务公开为新的服务，就好像一个对象可以由多个 小的对象组成一样。在服务内部，开发者仍然使用传统编程的概念，例如特定的 编程语言，版本，技术与框架，操作系统，a p i 等。但是，服务之间则必须使用 标准的消息与协议、契约以及元数据交换。应用程序中的不同服务完全可以放在 相同的位置上，或者分布到局域网或互联网上。它们也可以来自于多个开发商， 使用各种不同的技术与平台进行开发，版本独立，甚至执行在不同的时区。所有 的这些公共基础功能特性对于在应用程序中与服务交互的客户端而言，都是透明 的。客户端发送标准消息到服务，两端的公共基础功能通过消息以及与平台无关 的传输型表示形式进行转换，并对客户端与服务端之间存在的区别实现封送。 2 2 3 面向服务架构的特点 面向服务架构是一种粗粒度、松耦合的软件架构，其服务之间通过简单、精 确定义接口进行通信，不涉及底层编程接口和通讯模型，它的特点如下n 引： ( 1 ) 松散耦合 服务请求者到服务提供者的绑定与服务之间是松耦合的。松散耦合旨在将服 服使用者和服务提供者在服务实现和用户如何使用服务方面隔离开来。服务接e l 作为与服务实现分离的实体而存在，服务使用者不知道服务者实现的具体技术细 节，比如程序设计语言、部署平台，等等。服务使用者往往通过消息调用操作， 而不是通过使用a p i 和文件格式。服务实现的修改完全不会影响到服务使用者。 ( 2 ) 粗粒度服务 1 0 服务粒度是指服务所公开的功能的范围。一般分为细粒度和粗粒度。其中， 细粒度服务是那些能够提供少量商业流程的可用性服务。粗粒度服务是那些能够 提高高层商业逻辑的可用性服务。粗粒度服务可以灵活组合那些稳定性强、重用 性高的细粒度服务，而快速形成新的业务逻辑。 ( 3 ) 标准化的接口 服务描述的重点是：服务、调用操作的消息、构造这种消息的细节和关于向 何处发送用于构造这种消息的处理细节的消息的信息。面向服务架构通过服务接 口的标准化描述，从而使得该服务可以提供给在任何异构平台或者任何用户接口 使用。该接口隐藏了实现服务的细节，允许独立于实现服务基于的硬件或软件平 台和编写服务所用的编程语言来使用服务。 ( 4 ) 无状态服务 服务应该是独立的、自包含的请求，在实现时它不需要从一个请求到另一个 请求的信息和状态。服务不应该依赖于其他服务的上下文或者状态。当要求依赖 时，它们最好定义成通用业务流程、函数和数据模型，而不是实现构件( 比如会 话密钥) 。当然请求者应用程序需要服务调用之间的持久状态，但是这不应该与 服务提供者分开。 2 2 4 面向服务架构的原则 精心设计的面向服务架构应用程序应该力图坚持以下原则啪1 ： ( 1 ) 服务是安全的 服务与它的客户端必须使用安全通信。至少，从客户端传递到服务的消息必 须是安全的，客户端必须具备验证服务的方法。同时，客户端可能会在消息中提 供它们的安全证书，这样服务才能够对它们进行授权与认证。 ( 2 ) 服务在系统中保持一致的状态 执行客户端请求时，禁止进行部分替换的条件。服务访问的所有资源在客户 端调用之后必须是一致的。服务不能有任何剩余内容作为错误的结果，例如部分 地影响系统状态。服务不应寻求它的客户端的帮助，在发生错误后，服务会将系 统恢复为一致的状态。 ( 3 ) 服务是线程安全的 服务必须设计为线程安全，才能够维护多线程的并发访问。服务同样能够处 理因果关系或逻辑线程的重入。 ( 4 ) 服务是可靠的 如果客户端调用服务，客户端总是能够以确定的方式获知消息是否被服务接 收。消息应该按照发送的顺序处理，而不是接收的顺序。 ( 5 ) 服务是健壮的 服务与它的错误分离能够防止错误影响服务本身或其他服务。服务不能要求 客户端根据服务遇到的错误类型改变它们的行为。这能够有助于客户端与错误处 理层面上的服务解耦。 2 3 小结 本章主要研究了传统的分布式体系结构的发展历程和特点以及适用性，分析 了其存在的不足，引出面向服务方法学和面向服务架构是解决目前所面临问题的 最佳解决方案。后半部分重点研究了面向服务的架构的特点和面向服务架构要坚 持的原则。 1 2 3 1w o f 基本概念 第三章w c f 技术 w i n d o w s 通信基础( w i n d o w sc o m m u n i c a t i o nf o u n d a t i o n ，w c f ) 是基于 w i n d o w s 平台下开发和部署服务的软件开发包。w c f 为服务提供了运行时环境， 使得开发者能够将c l r 类型公开为服务，又能够以c l r 类型的方式使用服务i z 。 理论上讲，创建服务并不一定需要w c f ，但实际上，使用w c f 却可以使得创建 服务的任务事半功倍。w c f 是微软对一系列产业标准定义的实现，包括服务交 互、类型转换、封送以及各种协议的管理。正因为如此，w c f 才能够提供服务 之间的互操作性。w c f 还为开发者提供了大多数应用程序都需要的基础功能模 块，提高了开发者的效率。w c f 的第一个版本为服务开发提供了许多有用的功 能，包括托管、服务实例管理、异步调用、可靠性、事务管理、离线队列调用以 及安全性。同时，w c f 还提供了设计优雅的可扩展模型，使开发人员能够丰富 它的基础功能。事实上，w c f 自身的实现正是利用了这样一种可扩展模型。 3 1 1 服务 ( 1 ) 服务的概念蚴 服务是公开的一组功能的集合。服务可以是本地的，也可以是远程的，可以 由多个参与方使用任意技术进行开发。服务与版本无关，甚至可以在不同时区同 时执行。服务内部包括了诸如语言、技术、平台、版本与框架等诸多概念，而服 务之间的交互，则只允许指定的通信模式。服务的客户端只是使用服务功能的一 方。理论上讲，客户端可以是任意的w i n d o w s 窗体类，a s e n e t 页面或其他服 务。客户端与服务通过消息的发送与接受进行交互。消息可以直接在客户端与服 务之间进行传递，也可以通过中间方进行传递。w c f 的所有消息均为s o a p 消 息。w c f 的消息与传输协议无关。因此，w c f 服务可以在不同的协议之间传输， 而不仅限于h 1 曙。 ( 2 ) 服务的边界 w c f 不允许客户端直接与服务交互，即使它调用的是本地机器内存中的服 务。相反，客户端总是使用代理将调用转发给服务。代理公开的操作与服务相同， 同时还增加了一些管理代理的方法。 w c f 允许客户端跨越执行边界与服务通信1 2 3 1 。在同一台机器中，如图3 - 1 ， 客户端可以调用同一个应用程序域中的服务，也可以在同一进程中跨应用程序域 1 3 调用，甚至跨进程调用。 图3 1 使用w c f 实现相同机器通信 图3 2 则展示了跨机器边界的通信方式，客户端可以跨越i n t r a n e t 或i n t e m e t 的边界与服务交互【2 3 1 。 图3 2 使用w c f 实现不同机器通信 ( 3 ) w c f 与位置透明度 过去，诸如d c o m 或n e tr e m o t i n g 等分布式计算技术，不管对象是本地 还是远程，都期望为客户端提供相同的编程模型。本地调用时，客户端使用直接 引用；处理远程对象时，则使用代理。因为位置的不同而采用两种不同的编程模 型会导致一个问题，就是远程调用远比本地调用复杂。复杂度体现在生命周期管 理、可靠性、状态管理、可伸缩性以及安全性等诸多方面。由于远程对象并不具 1 4 各本地对象的特征，而编程模型却力图让它成为本地对象，反而使得远程编程模 型过于复杂。w c f 同样要求客户端保持一致的编程模型，而不用考虑服务的位 置。但它的实现途径却大相径庭：即使对象是本地的，w c f 仍然使用远程编程 模型的实例化方式，并使用代理。由于所有的交互操作都经由代理完成，要求相 同的配置与托管方式，因而对于本地和远程方式而言，w c f 都只需要维持相同 的编程模型。这就使得开发者不会因为服务位置的改变影响客户端，同时还大大 地简化了应用程序的编程模型。 3 1 2 地址 w c f 的每一个服务都具有一个唯一的地址【纠。地址包含两个重要元素：服 务位置与传输协议，或者是用于服务通信的传输样式。服务位置包括目标机器名、 站点或网络、通信端口、管道或队列，以及一个可选的特定路径或者u r i 。u r i 即统一资源标识，它可以是任意的唯一标识的字符串，例如服务名称或g u i d 。 w c f l 0 支持下列传输样式： ( 1 ) t c p 地址 ( 2 ) h t t p 地址 ( 3 ) 口c 地址 ( 4 ) m s m q 地址 ( 5 ) 对等网地址 3 1 3 契约 w c f 的所有服务都会公开为契约( c o n t r a c t ) 【2 5 1 。契约与平台无关，是描述 服务功能的标准方式。w c f 定义了四种类型的契约。 ( 1 ) 服务契约( s e r v i c ec o n t r a c t ) 服务契约描述了客户端能够执行的服务操作。服务契约特性可以将一个c l r 接口映射为与技术无关的服务契约。服务契约特性公开了c l r 接口( 或者类) 作为w c f 契约。w c f 契约与类型的访问限定无关，因为类型的访问限定属于 c l r 的概念。即使将服务契约特性应用在内部( i n t e r n a l ) 接口上，该接口同样 会公开为公有服务契约，以便于跨越服务边界实现服务的调用。如果接口没有标 记服务契约特性，w c f 客户端则无法访问它( 即使接口是公有的) 。这一特点遵 循了面向服务的一个原则，即明确的服务边界。为满足这一原则，所有契约必须 明确要求：只有接口( 或者类) 可以被标记为服务契约特性，从而被定义为w c f 服务，其他类型都不允许。 ( 2 ) 数据契约( d a t ac o n t r a c t ) 1 5 数据契约定义了与服务交互的数据类型。w c f 为内建类型如i n t 和s t r i n g 隐 式地定义了契约；我们也可以非常便捷地将定制类型定义为数据契约。 ( 3 ) 错误契约( f a u l tc o n t r a c t ) 错误契约定义了服务抛出的错误，以及服务处理错误和传递错误到客户端的 方式。 ( 4 ) 消息契约( m e s s a g ec o n t r a c t ) 消息契约允许服务直接与消息交互。消息契约可以是类型化的，也可以是非 类型化的。如果系统要求互操作性，或者遵循已有消息格式，那么消息契约会非 常有用。 3 1 4 绑定 服务之间的通信方式是多种多样的，有多种可能的通信模式瞄】。包括：同 步的请求应答消息，或者异步的“即发即弃”消息；双向消息；即时消息或队列 消息；以及持久队列或者可变队列。传递消息的传输协议包括：h t r p ( 或 h t i t s ) 、t c p 、p 2 p ( 对等网) 、i p c ( 命名管道) 以及m s m q 。消息编码格式 包括：保证互操作性的纯文本编码格式；优化性能的二进制编码格式；提供有效 负载的m t o m ( 消息传输优化机制，m e s s a g et r a n s p o r to p t i m i z a t i o nm e c h a n i s m ) 编码格式。消息的安全保障也有多种策略，包括：不实施任何安全策略；只提供 传输层的安全策略；消息层的隐私保护与安全策略。当然，w c f 还包括多种对 客户端认证与授权的安全策略。消息传递可能是不可靠的，也可能是可靠的端对 端跨越中间方，然后断开连接的方式。消息传递可能按照发送消息的顺序处理， 也可能按照接收消息的顺序处理。服务可能需要与其他服务或客户端交互，这些 服务或客户端或者只支持基本的w e b 服务协议，或者使用了流行的w s 簟协议， 例如w s s e c u r i t y 或者w s a t o m i ct r a n s a c t i o n 。服务可能会基于原来的m s m q 消息与旧的客户端交互，或者限制服务只能与其他的w c f 服务或客户端交互。 若要计算所有可能的通信模式与交互方式之间的组合，数量可能达到上千 万。在这些组合选项中，有的可能是互斥的，有的则彼此约束。显然，客户端与 服务必须合理地组合这些选项，才能保证通信的顺畅。对于大多数应用程序而言， 管理如此程度的复杂度并无业务价值。然而，一旦因此作出错误决定，就会影响 系统的效率与质量，造成严重的后果。 为了简化这些选项，使它们易于管理，w c f 引入了绑定( b i n d i n g ) 技术将 这些通信特征组合在一起。一个绑定封装了诸如传输协议、消息编码、通信模式、 可靠性、安全性、事务传播以及互操作性等相关选项的集合，使得它们保持一致。 理想状态下，我们希望将所有繁杂的基础功能模块从服务代码中解放出来，允许 服务只需要关注业务逻辑的实现。绑定使得开发者能够基于不同的基础功能模块 1 6 使用相同的服务逻辑。 在使用w c f 提供的绑定时，可以调整绑定的属性，也可以从零开始定制自 己的绑定。服务在元数据中发布绑定的选项，由于客户端使用的绑定必须与服务 的绑定完全相同，因此客户端能够查询绑定的类型与特定属性。单个服务能够支 持各个地址上的多个绑定。 w c f 定义了9 种标准绑定： ( 1 ) 基本绑定( b a s i cb i n d i n g ) ( 2 ) t c p 绑定 ( 3 ) 对等网绑定 ( 4 ) i p c 绑定 ( 5 ) w e b 服务( w s ) 绑定 ( 6 ) w s 联邦绑定( f e d e r a t e dw sb i n d i n g ) ( 7 ) w s 双向绑定( d u p l e xw sb i n d i n g ) ( 8 ) m s m q 绑定 ( 9 ) m s m q 集成绑定( m s m qi n t e g r a t i o nb i n d i n g ) 3 1 5 终结点 服务与地址、绑定以及契约有关。其中，地址定义了服务的位置，绑定定义 了服务通信的方式，契约则定义了服务的内容。w c f 用终结点表示这样一种组 成关系。终结点l 就是地址、契约与绑定的混成品，如图3 3 。 图3 3 终结点 每一个终结点都包含了三个元素，而宿主则负责公开终结点。从逻辑上讲， 终结点相当于服务的接口，就像c l r 或者c o m 接口一样。从概念上讲，不管 是c 撑还是v b ，一个接口就相当于一个终结点：地址就是类型虚拟表的内存地址， 绑定则是c l r 的j i t ( j u s t i n t i m e ) 编译，而契约则代表接口本身。由于经典 的n e t 编程模式不需要处理地址或绑定，你可能认为它们是理所当然存在的。 1 7 而w c f 并未规定地址与绑定，因而必须对它们进行配置。 每个服务至少必须公开一个业务终结点，每个终结点有且只能拥有一个契 约。服务上的所有终结点都包含了唯一的地址，而一个单独的服务则可以公开多 个终结点。这些终结点可以使用相同或不同的绑定，公开相同或不同的契约。每 个服务提供的不同终结点之间绝对没有任何关联。重要的一点是，服务代码并没 有包含它的终结点，它们通常放在服务代码之外。我们可以通过管理方式使用配 置文件或者通过编程方式配置终结点。 3 1 6w c f 体系架构 w c f 提供了对可靠性、事务性、并发管理、安全性以及实例激活等技术的 有力支持，它们均依赖于基于拦截机制的w c f 体系架构【2 6 1 。通过代理与客户端 的交互意味着w c f 总是处于服务与客户端之间，拦截所有的调用，执行调用前 和调用后的处理。当代理将调用栈帧序列化到消息中，并将消息通过通道链向下 传递时，w c f 就开始执行拦截。通道相当于一个拦截器，目的在于执行一个特 定的任务。每个客户端通道都会执行消息的调用前处理。链的组成与结构主要依 赖于绑定。例如，一个通道对消息编码( 二进制格式、文本格式或者m t o m ) ， 另一个通道传递安全的调用上下文；还有一个通道传播客户端的事务，一个通道 管理可靠会话，另一个通道对消息正文加密( 如果进行了配置) ，诸如此类。客 户端的最后一个通道是传输通道，根据配置的传输方式发送消息给宿主。 在宿主端，消息同样通过通道链进行传输，它会对消息执行宿主端的调用前 处理。宿主端的第一个通道是传输通道，接收传输过来的消息。随后的通道执行 不同的任务，例如消息正文的解密、消息的解码、参与传播事务、设置安全准则、 管理会话、激活服务实例。宿主端的最后一个通道负责将消息传递给分发器。分 发器将消息转换到一个栈帧，并调用服务实例。执行顺序如图3 4 所示。 1 8 图3 4w c f 体系架构 服务并不知道它是否被本地客户端调用。事实上，服务会被本地客户端，即 分发器调用。客户端与服务端的拦截器确保了它们能够获得运行时环境，以便于 它们执行正确的操作。服务实例会执行调用，然后将控制权返回给分发器。分发 器负责将返回值以及错误信息( 如果存在) 转换为一条返回消息。分发器获得控 制权，执行的过程则刚好相反：分发器通过宿主端通道传递消息，执行调用后的 处理，例如管理事务、停用实例、回复消息的编码与加密等。为了执行客户端调 用后的处理，包括解密、解码、提交或取消事务等任务，传输通道会将返回消息 发送到客户端通道。最后一个通道将消息传递给代理。代理将返回消息转化到栈 帧，然后将控制权返回给客户端。 3 1 7 宿主体系架构 如何将与技术无关的面向服务交互转换为c l r 接口与类，对这一技术的探 索无疑充满了趣味。宿主消除了两者之间的鸿沟，搭建了相互之间转换的桥梁。 每个n e t 宿主进程都包含了多个应用程序域。每个应用程序域则包含了零到多 个宿主实例。每个服务宿主实例专门对应于一个特殊的服务类型。创建一个宿主 实例，实际上就是为对应于基地址的宿主机器的类型，注册一个包含了所有的终 结点的服务宿主实例。每个服务宿主实例拥有零到多个上下文。上下文是服务实 例最核心的执行范围。一个上下文最多只能与一个服务实例关联，这意味着上下 文可能为空，不包含任何服务实例。体系架构如图3 5 所示。 1 9 图3 5w c f 宿主体系架构 w c f 上下文的概念与企业服务上下文或者n e t 上下文绑定对象的上下文 概念相似。w c f 上下文将服务宿主与公开本地c l r 类型为服务的上下文组合在 一起。当消息经由通道进行传递时，宿主会将消息映射到新的或者已有的上下文 ( 内部包含对象实例) ，然后通过上下文处理调用。 3 2 服务管理 3