面向服务的软件工程-期末复习

选择题整理

以下内容整理自：服务计算与服务生态系统_中国大学 MOOC(慕课) (icourse163.org)

单选 3 分 * 10 个，散步在各个 PPT，没有多选，重在理解，各凭本领。

服务、服务系统与面向服务的泛型

题目	判断
IT 服务和非 IT 服务都满足服务的基本要求，但他们也有区别。他们的区别包括：KPIs（关键绩效指标）不同、服务雇员不同【应为需求管理不同】、变化的步调不同。	×
铁三角发布 MSR7 限量版耳机。在普通 MSR7 耳机的基础上，限量版耳机听取了消费者的建议和需求，对模具和发声单元进行了大幅改进。4 月 1 日上市贩售，限量 10000 只，每只耳机均附带唯一编号的收藏证明。这个模式偏服务模式【为制造模式】。	×
服务模式（Service Mode）和制造模式（Manufacturing Mode）的最大差异在于：服务模式的产物是服务（Service），而制造模式的产物是货物（Goods）。服务是无形的、挥发的，并可能以消费者参与的方式定制化生产；而货物是有型的、可存储的，消费者不直接参与货物的生产过程。	√
服务也可以以实物作为载体。如采用定制化的方式设计、裁剪和制作衣服。虽然衣服是有型的，但是满足了消费者的个性化定制需求，可以被认为是一个以服务为主的过程。	√
可口可乐公司中的企业资源管理（ERP）偏服务模式。ERP 系统是一个服务系统。	√
很多行业兼具制造模式和服务模式的特点，但随着时代的发展和竞争的要求，单纯的制造模式变得越来越少、服务模式的特点变得越来越显著。	√
用来支持服务模式的 IT 系统被称为服务系统（Services System）。由于服务模式变的越来越普及，所有的软件系统【不是所有的软件系统都是服务系统，也不是所有的服务系统都需要使用面向服务的方式进行分析和设计】均可以使用服务系统的概念进行抽象，进一步的，可以使用面向服务的方式进行分析和设计。	×
只要满足自治、开放、自描述、与实现无关的特点，无论是本地构件还是网络构件【服务必须是网络构件】，都能够被认为是服务。	×
在面向对象的分析设计过程中间，如果我们将系统模块化，并采用统一的方式定义模块和模块之间的接口。如果这些接口是标准的，我们就可以把它们抽象为构件【构件不是接口，是模块化的、可部署、可替换的软件系统组成部分】。与对象相比，构件的粒度较大，利于复用。	×
引入面向服务的泛型后，一方面，复用的范围从单个服务系统扩大到了多个服务系统；另一方面，软件的开发任务被分为服务的生产和应用的开发。这使得各个服务系统的开发工作能够有效利用现有的 IT 资源和人力资源。	√

服务生态系统与面向服务的计算

题目	判断
服务组合由多个装配在一起服务所构成，用以提供对业务任务或过程进行实现的功能。如果服务组合能够进一步的被封装为服务，可以认为服务组合是服务的一种实现方式。	√
只要在服务库存中存在，无论是应用服务、业务服务还是编排服务，都可以作为子服务被服务组合装配。	√
根据是否直接满足服务消费者的需求，可以将服务生态系统（Services ecosystem）中的服务分为垂直（Vertical）服务和水平（Horizontal）服务。因此，在进行服务系统构建的时候，可以事先将服务分划为这两种类型【分划不是排他性的，如果一个服务既能够被消费者直接调用，也能为其他服务所调用，那么该服务可以同时是垂直服务和水平服务】，并按照其特点，应用不同的设计原则，分别进行分析和设计。	×
由于缺乏统一的标准化组织和标准体系，目前尚没有出现成熟的面向服务编程语言，但是随着面向服务的泛型和 Web Service 标准的发展，面向服务编程语言有望在将来出现【面向服务着眼于对服务系统进行平台/技术/语言无关的分析和设计，不需要提供面向服务的编程语言来提供面向服务的实现】，并提供面向服务实现的完全支持。	×
面向服务的目标主要包括技术上的：灵活性、扩展性、鲁棒性、重用性和效率、业务需求的满足。商业上的：组织灵活性、固有的互操作性、供应商多样化选择、联盟、业务和技术一致性、削减 IT 投入、提高投资回报率。	√
从作用域角度出发，面向服务的计算中的服务作用域往往基于一个服务生态系统；在面向对象的计算中，对象的作用域往往基于一个软件系统。	√
从耦合的角度出发，在面向对象的计算中，如果我们按照功能仔细划分，达成模块和模块之间的“相对无关性”，我们可以达成与面向服务计算中类似的松耦合特性【在面向服务计算中，松耦合还体现在运行时态动态绑定。即，设计与实现分离、一个设计可以由多个实现者加以提供】。	×
服务组合提供了复用性和灵活性。但是由于特定子服务可以同时参与到多个业务流程，“瓶颈效应”和“单点失效”的问题使得以服务组合方式实现的业务功能的可靠性差于采用面向对象实现的类似功能【“瓶颈效应”和“单点失效”问题可以通过提供服务的多个备选实现加以解决】。	×
在面向对象的计算中，代码复用通过类成员的继承和库函数加以实现。面向服务的计算中，代码在服务层次复用。	√
由于服务是一个网络构件，采用面向服务的计算所构造出的服务系统，天然的是一个网络应用。	√

面向服务的架构和 Web Service

题目	判断
服务系统中的三要素包括：服务提供者、服务消费者和服务注册（Service Registry）【服务系统中没有关于服务注册的要求】。其中，服务注册通过支持服务的发布和查找，实现服务提供者和服务消费者之间的松耦合，从而实现服务系统灵活、可动态配置的特点。	×
由是否拥有中心协调者作为判断，服务组合（Composition）的方法可以分为编排（Orchestration）和编导（Choreograph）。从能力上来说，它们各有不同【从能力上来说他们是等价的】，在实际使用时需要根据业务场景进行选择。	×
对应服务生态系统，SOA-RA（SOA 参考架构）中，我们使用垂直层来分层设计并实现直接满足消费者需求的垂直服务；我们使用水平层来分层设计并实现用以实现灵活、复用的水平服务【SOA-RA 中，水平层用以实现功能，垂直层用于提供支持和 QoS。他们和服务生态系统中的垂直服务和水平服务的分划方式没有关系】。	×
服务簇由服务层进行定义，它是一类从概念上服务于同一个业务功能的服务集合。他们可以由不同的服务提供者所发布，并在功能上可以相互替代。而业务过程层中，无论采用组合还是分解的方式，实质上都是面向服务簇来进行的。	√
面向服务的架构并没有限定实现技术，常见的实现技术包括但不限于：Web Service、分布式对象、构件、RESTful Services、ESB 等。	√

XML 及相关协议

题目	判断
信息交换的范围可以分为应用内部（Intra-Application）、应用之间（Inter-Application）、系统之间（Inter-System）和公司之间（Inter-Company）。XML 可以用以进行上述任意类型的信息交换。	√
XML 是一种以树结构交换文本信息的信息交换标准，无法被用以交换二进制数据【XML 可以用来交换二进制数据。 】。	×
XML 既可以面向数据，也可以面向展现。在面向展现时，XML 可以使用预定好的元素和属性表达 Web 页面，在 Web 浏览器打开该页面时，如果发生结束标签缺失或标签大小写不匹配等问题时，与 HTML 类似，Web 浏览器可以自动纠正这些错误【XML 是面向数据的，他的语义和展现无关，亦没有任何面向页面的预定义标签，任何 XML 均应满足格式良好的限定条件 】。	×
名称空间（Namespace），采用前缀（Prefix）+本地部分（Local part）表达元素和属性名称，从而解决命名冲突和全球化的问题。 通过 import 机制【无需额外机制，即可通过 QName 在单一 XML 文档中融合来源于不同 Namespace 的元素或者属性 】可以把隶属在不同名称空间（前缀对应不同 URI）中的元素（属性）组装为一个 XML 文档。	×
只要满足 5+1 条基本原则（单根原则、元素（Element）标签原则、元素嵌套原则、元素原则、属性（Attribute）原则和 XML 声明原则），XML 文档就可以被称为良好格式化（Well-formed）。在此基础上，如有需要，还可以使用 Schema 脚本等对 XML 文档进行数据类型检查，这个过程称为验证（Validation）。	√

Web Service 核心

题目	判断
SOAP 定义了在分布式异构环境中进行信息交换的消息框架和单向、无状态的通信范例。它不是一个网络传输协议，因此，必须通过绑定（binding）机制将 SOAP 消息与实际的网络消息格式进行关联。	√
在我们使用 SOAP 来传递 XML 信息时，由上层的应用来解释 SOAP 所携带 XML 消息的语义语法。虽不是必须，一般来说，必选的核心的相关信息被放置在消息体（Body），可选的辅助性的相关信息被放置在消息头（Header）	√
WSDL 以 XML 的方式描述了一个服务的功能、调用地点和调用方式。WSDL 中所定义的操作（Operation）按照风格可以分为面向文档（Document-Oriented）和面向过程（Procedure-Oriented）。其主要区别在于所使用的 SOAP 绑定风格不同：前者使用 Message-exchange 风格的 SOAP 消息，而后者使用 RPC 风格的 SOAP 消息【主要区别在于：是接受一个 XML schema 约定的 XML 文档作为输入输出，还是采用远端的过程接口加上映射方式决定输入输出】。	×
WSDL 模型被分为抽象部分（Abstract Section）和具体部分（Concrete Section）。抽象部分包括 types、interface 元素；具体部分包括 binding、service 元素。抽象部分和具体部分可以由不同的设计人员/团队加以定义，并加以组装。拥有相同抽象部分的服务被称为服务簇（Services Cluster），它们拥有相同/相似的服务能力，在满足其他条件（如非功能性需求）的前提下，可以相互替代。	√
WSDL 中的 binding 元素和 SOAP 中的绑定机制是类似的。因此，在使用 WSDL+SOAP 对服务进行描述时，binding 元素可以省去【WSDL 中的 binding 元素和 SOAP 中的绑定机制解决不同的问题。即使是使用 WSDL+SOAP，binding 元素也是必须的】。只有采用 WSDL+HTTP 对服务进行描述时，binding 元素才是必须的。	×

Web Service 扩展

题目	判断
UDDI 存放的信息可以分为白页，黄页和绿页。在使用 UDDI 发布 web service 时， 使用白页记录 WSDL 的抽象部分；使用绿页记录 WSDL 的具体部分；使用黄页记录服务合约中的其他信息【白页存放基本信息，黄页存放分类信息，绿页存放技术信息】。	×
BPEL 是一种使用编排风格实现服务组合的规范。一方面 BPEL 要求组合成员在 WSDL 中以 partnerLinkType 元素说明它在组合中的作用和地位；另一方面使用 BPEL 文档描述该组合的逻辑流程。BPEL 公布了服务实现的细节。	√
WS-addressing 被用以完成服务实现中的寻址和消息路由。WS-security 被用以实现 web service 安全相关的非功能性需求。 补充：WS-Addressing 是用于消息分发和区分实例的；WS-Security 用于满足安全方面的非功能性需求，WS-Policy 提供策略的切换	√
WSRF 被用以完成服务相关资源的定义和管理。 无论是有状态服务（Stateful）还是无状态服务（Stateless）【一般认为，携有资源的服务为有状态服务】都可以使用它来定义和管理资源。	×
WS-Coordination 被用以支持服务之间的复杂动作，它定义了协议服务和协作上下文，可以使用原子事务和业务活动，两种协议分别完成短时间协作和长时间协作【亦可自己扩展相关的协议】。	×

服务生态系统的构建

题目	判断
面向服务分析的主要过程包括：定义流程自动化需求，识别现有的自动化服务，服务候选建模。其中，服务候选建模是面向服务分析的主要步骤，以建立服务操作候选，并将合理分组到服务候选为目的。	√
在服务建模的过程中，需要避免服务候选之间的业务逻辑相互重叠。这一原则要求在任何情况下同一个业务逻辑单元仅能用一个服务操作候选进行封装【大多数服务候选有这样的需求但是编排和组合服务有意设计为其他服务的组合。封装遗留系统的服务也可能违反这一要求，为了安全性和粒度需求，有时候我们也会采用冗余接口的方式加以设计】。	×
根据业务分析方法及其自身特点，在对服务进行设计时，可以将服务分为应用服务、以实体为核心的业务服务、以任务为核心的业务服务和编排服务。各种不同类型的服务在面向服务原则的应用上各有不同，因此需要在分析和设计时区别对待，为每种类型的服务分别指定分析和设计标准。	√
在提炼和应用面向服务原则的过程中，不应局限于产生该服务的初始流程和上下文。一方面，需要综合考虑服务生态系统中所有可能复用该服务的流程和上下文；另一方面，应当充分考虑服务的进一步演化和全新流程的构建。	√
以任务为核心的业务可以使用服务组合加以实现，而以实体为核心的业务服务不能使用服务组合加以实现【两者均可】。	×

服务设计原则

题目	判断
标准化服务合约原则要求制定服务生态系统中的服务合约标准。越是标准化的服务合约越利于服务的可理解性和可复用性。此外，标准化的服务合约还倾向于生产标准粒度的调用数据，从而避免不必要的数据转换，减少服务实现的复杂度。	√
服务松散耦合原则允许的积极耦合包括：逻辑——合约耦合、消费者——合约耦合。	√
服务的抽象原则要求服务合约对外隐藏非必要信息。这些信息抽象包括：技术信息抽象、功能抽象、程序逻辑抽象和服务质量抽象。越是抽象的服务合约，越倾向于较高的可复用性【完全抽象的服务合约可能需要额外的其他元信息交换渠道，反而不利于服务的可复用性】。	×
服务的可复用性原则要求将服务生态系统中的所有服务均设计为无关服务 (Agnostic service）【不是所有的服务均是无关服务，垂直服务在大多数情况下是和消费者有关的】 ，从而确保最大程度的可复用性。	×
服务自治原则，将运行时自治的情况分为共享自治、服务逻辑自治和完全自治。虽然高自治的服务倾向于高性能、高可靠性和可预测性，但是由于高自治服务往往需要较多的软硬件资源，在设计服务的时候需要慎重考虑。	√
服务的无状态性原则，鼓励利用调用该消息或状态数据库，在必要时卸载/还原服务的状态信息，将服务的实例转换为无状态/少状态，从而减少资源的消耗，提升服务的可扩展性。	√
服务的可发现性原则，要求服务不仅能够被发现，而且要求服务合约所提供的信息使得服务的现在调用者能完全了解该服务的目标、能力和限制等。良好的可发现性是服务具备的较高可复用性的前提条件。	√
服务的可组合性原则，要求服务应尽量设计为使用服务组合来加以实现。作为组合控制器 (Composition Controller) 的服务调用的组合成员（Composition Member）越多，该服务组合越复杂，担任组合控制器的服务可组合型越好【服务的可组合性主要面对非功能性需求，由其他服务设计原则的综合表现进行评级】。	×

简答题整理

面向服务的泛型

服务和制造的区别？为什么要区分？相似和不同之处？

为什么需要面向服务的泛型？

服务和制造的区别

服务模式（Service Mode）和制造模式（Manufacturing Mode）的最大差异在于：服务模式的产物是服务（Service），而制造模式的产物是货物（Goods）。服务是无形的、挥发的，并可能以消费者参与的方式定制化生产；而货物是有形的、可存储的，消费者不直接参与货物的生产过程。

为什么需要面向服务的泛型

1. 面向服务的快速发展导致单个组织无法独立提供全套服务，提供的有限服务也无法被广泛运用；已存在的服务并不能很好地被发现和调用，也导致大量冗余服务。
2. 另一方面：原先的服务系统是复杂、脆弱、特殊的，从上层业务看，无法灵活应对实际业务的变更；从底层实现看，也无法及时应对底层技术的更新、或者新增的功能。
3. 因此构建服务生态系统，运用面向服务的分析和设计原则，使得产生的服务具有良好的可发现性和可复用性，同时能灵活应对业务领域和技术领域的变更。

SOAP

SOAP 包的结构，如何配合在一起完成消息交互。协作完成任务的例子。

结构

SOAP（Simple Object Access Protocol）包结构：

SOAP 包本质是一个 XML 文档，包含下列元素：

1. Envelope 元素：必须元素，根元素，标识此 XML 文档为一条 SOAP 消息；可以包含命名空间和声明额外的属性。如果出现额外属性，则必须使用命名空间修饰。
2. Header 元素：可选元素，有关 SOAP 消息的应用程序专用信息（比如认证、支付等）。
3. Body 元素：必须元素，包含所有的调用和响应信息。
4. Fault 元素：可选元素，提供有关在处理此消息所发生的错误的信息

处理模型

1. 用 XML 打包请求：
   1. 将接口名作为根节点
   2. 方法和参数作为节点
2. 将请求发给服务器：
   1. 不创建自己的 TCP/IP 信息，利用 HTTP
   2. 将请求封装成 HTTP POST 请求格式发出
3. 服务器收到请求，解码 XML，处理请求，以 XML 格式返回响应
   1. 与请求比较，方法的节点名字变为请求的方法名后缀 Response（例如，find->findResponse）
   2. 客户程序自己调用了哪个方法，根据方法名后缀 Response 寻找调用方法的返回值

WSDL

WSDL 的核心是什么，每一个部件的做些什么。

WSDL 对服务能力、服务中使用的数据结构以及传输绑定给出定义和描述；提供了一种基于 XML 的标准接口定义语言/服务能力定义语言，用以在服务的提供者/调用者/服务注册之间，交换必要的有关的 web service 的信息。WSDL 的核心是描述 Web 服务的接口和操作，以及如何访问这些操作的消息格式和传输协议。

结构

WSDL（Web Services Description Language）2.0 以 description 元素为根节点。

import、include：拼装不同部门/组织定义的文档，形成完整的 WSDL 语义

1. 抽象部分：
   1. Types：使用到的数据结构或者叫数据格式范式，独立于语言和平台
   2. Interface：operation 的集合即服务能力的集合，描述服务能力。operation：input、output、infault、outfault
2. 具体部分：
   1. Binding：特定端口类型的具体协议和数据格式规范的绑定。
   2. Service：对服务整体的抽象，包含若干个 endpoint。endpoint：将绑定与当前地址关联

面向对象 VS 面向服务

试对比面向服务泛型和面向对象泛型（提示：方法论、抽象和协作层次、代码共享和复用、动态绑定和重新组合、重组、组件通讯和接口，系统维护、可靠性、软件拥有）

特点	面向对象的计算	面向服务的计算
方法论	- 通过定义紧耦合的类来进行应用开发 - 应用架构为基于继承关系的层次式架构 - 从构造函数——通过类或模型——到系统设计	- 通过定义松耦合的服务来进行应用开发，并将服务组装成可执行的应用 - 从系统模型到服务模块，从服务抽象定义到服务实现绑定 - 通过搜索获得可用的服务实现
抽象和协作层次	- 往往由一个团队来负责应用的开发，并负责整个生命周期 - 开发者必须了解应用领域的编程知识	- 开发任务由三个独立方承担：应用程序开发者，服务提供方和服务代理 - 其中，应用程序开发者需要了解应用逻辑，但不需要了解具体的服务是如何实现的。 - 服务提供者需要编程能力，但不必了解使用服务的应用
代码共享和复用	- 代码复用通过类成员的继承和库函数加以实现。其中库函数在编译时引入，且往往是平台相关的	- 代码在服务层次复用。服务使用标准的结构，并发布在 internet 库中。服务是平台无关的，且能够被查找并远程调用。服务代理支持系统的服务共享
动态绑定和重新组合	- 在运行时将名称和方法进行关联。方法必须在应用部署前链接到可执行的代码	- 在运行时将服务调用和服务进行绑定。可以在应用部署后，再进行服务选定。这一特色使得应用可以在运行时重组
重组	- 多在设计时决定导入的组件	- 可以动态改变应用系统中服务的组合关系，以及服务定义与服务实现之间的绑定关系，即实现动态地添加、修改、删除各个服务节点。
组件通讯和接口	- 与平台和语言有关，例如 c++ 程序难以直接和 java 程序通信	- 与平台和语言无关。组件间通过标准协议通信，如 XML，WSDL 和 SOAP.
系统维护	- 用户需要时常升级软件，且在执行升级时，应用必须停止	- 通过互联网升级系统，因为服务多运行在远程服务器上，用户通过互联网进行访问。维护对用户透明
可靠性	- 在设计时决定可靠性的方法	- 对于服务提供者，每个服务相对简单，更加可靠。对于应用程序存在多个满足同一需求的服务，可通过将故障服务的节点断开并重新绑定到备选服务节点上，获得不间断的应用系统
软件拥有	- 软件作为产品销售，为用户所拥有	- 软件存在并执行于独立的服务提供商的设备上，用户按照每次对服务使用付费，而不是按照软件产品付费。

八大设计原则

某个原则和其他设计原则的关系：有关、无关、正向、逆向。风险是什么。

参见 [1.8 服务设计原则](# 服务设计原则）

graph TD;
    A[标准化服务合约]-->B[服务松散耦合]
    A[标准化服务合约]-->C[服务抽象]
    A[标准化服务合约]-->D[服务自治]
    A[标准化服务合约]-->E[服务可发现性]
    B[服务松散耦合]-->F[服务可复用性]
    B[服务松散耦合]-->G[服务无状态性]
    C[服务抽象]-->F[服务可复用性]
    C[服务抽象]-->G[服务无状态性]
    D[服务自治]-->G[服务无状态性]
    E[服务可发现性]-->H[服务可组合性]
    F[服务可复用性]-->H[服务可组合性]
    G[服务无状态性]-->H[服务可组合性]

标准化服务合约

和其他原则的关系

• 标准化服务合约与服务松散耦合
  • 消费者和服务之间存在对服务合约中技术接口的依赖
    • 技术服务合约越详细，越内容丰富，消费者和服务之间的依赖关系越强
    • 两个服务之间所达到的松散耦合程度直接与在服务合约中的依赖关系数量相关
  • 标准化的合约将会有助于提高服务之间的一致性和耦合质量
• 标准化服务合约与服务抽象
  • 服务抽象原则要求简化合约：非核心信息都被隐藏
  • 服务合约的设计决定了抽象的程度：在合约中的内容越仔细，服务中被抽象的信息就越少
• 标准化服务合约与服务可复用性
  • 服务可复用性原则常常侧重于服务封装的逻辑是否足够一般和通用
  • 可复用方案逻辑与数据交换之间的关系最终要由服务合约是如何设计的来决定
  • 服务合约越是通用、灵活和可扩展，服务的长远复用潜力就越大
• 标准化服务合约与服务可发现性
  • 服务合约越是得到一致的标注和结构化，对于那些需要使用它们的人来说就越是可以预测的
  • 服务合约越是标准化，元信息的技术接口细节提供得越是充分，服务的可发现性就越高
• 标准化服务合约与服务可组合性
  • 服务的可组合性需求常常与服务合约表达其能力的粒度有关
  • 粗粒度的操作拥有更高的效率，但常常不适应于需要参与到更大规模组合中的服务

可能的风险

• 版本化（服务合约的演化）
  • 服务实施后，就有可能建立起与服务消费者之间的依赖关系
  • 底层逻辑越是可复用，那些需要消费它的程序的数量和消费频率就会越大
  • 可扩展性可能引入“破坏”既定合约的重大变化，从而导致发布新的服务版本的要求
• 技术依赖
  • 不同的编程语言和开发平台来实现
  • 使用基于构件的系统并通过增强的 RPC 技术以支持面向服务
    • Web Service 平台以及它的非专用的通信框架
    • 操作性系统层的技术性变化导致服务合约变化
• 开发工具缺陷
  • 使用开发工具自动生成合约可能产生非标准化的服务合约

服务松散耦合

和其他原则的关系

• 服务松散耦合与标准化服务合约
  • 松散耦合鼓励调节技术合约内容的数量和复杂度，从而最小化消费者依赖需求、最大化服务所有者的自由度，在不影响现有消费者的情况下随着时间演化和改变服务
• 服务松散耦合与服务抽象
  • 创建更低耦合的消费者关系，明确地要求应用良好定义的功能和技术抽象级别
• 服务松散耦合与服务可复用性
  • 减少依赖关系可以使服务更容易被组合、演化甚至扩充以支持不断变化的业务需求和方向
• 服务松散耦合与服务自治
  • 减少消极耦合类型的程度，会为运行时和设计时的更高自治级别提供支持
  • 服务消费者具有越多的跨服务依赖，它所具有的自主权就越少（服务消费者可能同时担任复合服务中的服务协调者）
• 服务松散耦合与服务可发现性
  • 服务松散耦合有助于元数据的调节
• 服务松散耦合与服务可组合性
  • 在服务组合中，避免消极形式的耦合
    • “合约-逻辑”耦合 如果服务合约是自动生成的，就很有可能在被其他服务使用时不符合标准。因此需要在它和其他组成成员之间进行转换
    • “合约-技术”耦合 如果同一个组合中的不同部分同时使用开放与专用服务技术，就会需要在本地实现技术转化层
    • “合约-实现”耦合 当一个服务合约与底层实现特性之间产生耦合时，就会最终把这些性质强加到作为一个整体的组合之上

可能的风险

• 逻辑-合约”耦合的限制
  • 同一底层逻辑对应两个或者多个合约，从而建立多个入口，每一入口向不同类型的消费者暴露不同的服务能力（Service Facade）
• Schema 耦合太“松散”
  • 为了强调服务的兼容性演化能力，通过过分简化服务合约，追求减少消费者依赖，仅确定了一些非常通用的数据类型（弱类型）
  • 验证并处理弱类型，增加服务所需的性能要求
  • 服务合约发布的信息越少，消费者程序就需要知道越多关于服务实现逻辑的信息，从而产生消极耦合

服务抽象

和其他原则的关系

• 服务抽象与标准化服务合约
  • 服务抽象出来并对外界可用的信息就是服务合约，服务抽象原则的应用影响到服务合约
  • 服务合约的设计标准也会影响到功能、技术和逻辑抽象的等级
• 服务抽象与服务松散耦合
  • 抽象的程度对可能耦合的程度有直接的关系
  • 少量的高度详细的技术接口约束会导致比大量含糊或开放的数据约束更多的紧密耦合需求
    • 耦合的程度一般由被抽象的信息数量和信息本身的属性的组合来决定
    • 最终由服务合约的粒度加以体现
• 服务抽象与其他原则
  • 其他的服务设计原则，如服务可复用性、服务可组合性和服务可发现性等原则都鼓励创建更多的、关于服务的元信息
  • 而服务的抽象原则要求在发布这些元信息前评估其必要程度

可能的风险

• 多消费者耦合的需求
  • 不同消费者可能需要不同的技术接口细节，所需的抽象程度也不尽相同
  • 使用合约反规范化，提供不同级别的抽象粒度
• 人为误判
  • 过于抽象的服务合约导致曲解或不能充分理解一个服务。从而丧失潜在的复用机会
  • 过于具体的服务合约导致对服务的行为作出与服务实现相关的假设，从而导致实现耦合
• 安全和隐私的考虑
  • 服务合约可能暴露私有或者敏感信息
    • 不同的使用环境（组织内部 vs. 组织外部）
    • 并发和冗余的服务合约内容以解决这一问题

服务可复用性

和其他原则的关系

• 服务可复用性与标准化服务合约
  • 可复用的服务需要足够的灵活性来支持带有不同交互需求的消费者
  • 导致降低合约验证约束（尤其是那些易变的）的设计标准
• 服务可复用性与服务抽象
  • 合约的自描述性与简洁之间的平衡
  • 元信息的抽象程度反映这一平衡
• 服务可复用性与服务松散耦合
  • 一个服务的依赖需求越小，复用它就越简单
  • 当追求服务逻辑的可复用性时，总是有一种减少服务合约约束的趋势
• 服务可复用性与其他原则
  • 服务自治
    • 自治是对可复用服务潜在高性能和并行使用的保证
  • 服务无状态
    • 通过最小化状态管理责任，提高一个服务的可用性，从而提高有效扩展的能力
  • 服务可发现性
    • 可复用服务必需可发现、可解释
  • 服务可组合性
    • 可组合是复用的一种形式，可复用潜能越大，服务被反复组装的机会就越大

可能的风险

• 文化上的考虑
  • 当项目团队被要求遵守特定可重用服务的逻辑集中化时，会出现常见的文化问题
• 治理上的考虑
  • 面向服务将相互无关的逻辑单元抽象为服务，与业务流程、应用程序或用户基础都没有任何直接联系
• 可靠性上的考虑
  • 可复用服务的单点失效会导致多个业务流程的失
  • 通过对关键服务的多重复用来解决
• 安全上的考虑
  • 在不同应用场景中的安全性要求不同
  • 安全级别可能和信息交换的方式直接相关，甚至可能和服务合约所暴露的功能类型相关
• 商业设计需求上的考虑
  • 领域专家在进行服务分析和建模阶段中引入的风险和问题
• 敏捷交付上的考虑
  • 在需要以敏捷开发方法来解决短期和战术上的业务目标时，提倡服务的可复用性是非常困难的

服务自治

和其他原则的关系

• 服务自治与标准化服务合约
  • 服务合约自治直接与服务合约紧密相连
  • 规范化的考虑会影响到合约如何形成，以及如何与其他服务协调
  • 在服务合约上有越大的控制权，服务合约能被更好地定制和标准化，越能够确保底层实现可以在遵循既定自治级别的前提下，被独立设计
• 服务自治与服务松散耦合
  • 由于同样期望将服务之间的依赖最小化，服务自治在很大程度上支持服务松散耦合原则
    • 积极耦合会直接导致设计时自治的增加；设计时自治的增加，又能更好地增强和优化服务的实现，从而持运行时的自治
• 服务自治与服务抽象
  • 将一个服务的自治级别作为整个服务合约的一部分来发布
  • 服务自治的信息是服务质量信息抽象的一个例子
• 服务自治与服务可复用性
  • 自治的增加提高了一个服务的复用潜力
  • 通过增强服务的可靠性和提高服务行为的可预测性，其逻辑可以更加容易地适应多个服务消费者的需求
  • 更好地支持服务运行环境的演化，从而应对复用所带来的并发要求
• 服务自治与服务无状态性
  • 实现高级别的服务自治可以直接支持服务无状态性程度的增加
• 服务自治与服务可组合性
  • 服务组合的整体自治性取决于它的所有组成成员自身的自治性
  • 服务有越好的可靠性和可预侧性就越能组成更高效的大型服务组合

可能的风险

• 错误地判断服务的范围
  • 反模式
• 包装服务和遗留逻辑封装
  • 无法改变的自动化系统无法回避自治问题
• 对服务需求的过高估计
  • 过于追求高自治

服务无状态性

和其他原则的关系

• 服务无状态性与服务可复用性
  • 减少活动相关逻辑使一个服务变得更加无关（而无关服务具有更好的可复用性）
  • 提高服务的可扩展性和可用性使得它们可以在更多的服务组合中被更多的服务消费者复用
• 服务无状态性与服务自治
  • 状态信息的本质通常是特定于一个给定的活动或者业务流程的，通过在服务边界外改变状态管理机制和流程的职责，就可以降低服务逻辑依赖于更大的业务任务的可能性。这使得服务能够更加自给自足，并且能够被定位成技术环境的一个独立部分，因而直接增加其整体自治性
  • 另一方面，由环境架构所提供的状态管理延迟选项可要求服务形成在其边界外的一个直接依赖。这种类型的外部实现耦合会影响到一个服务的整体自治

可能的风险

• 对于架构的依赖
  • 要建立服务设计和一个外部状态延迟选项的相互依赖关系
  • 需要权衡这种依赖关系和延迟状态所带来的好处
• 增加的运行时性能需求
  • 在从无状态到有状态进行切换时，可能会需要找回、解析然后再在服务中执行状态数据，这将会在消息内容的实际处理之外引入额外的性能开销
• 低估交付代价
  • 特定于活动的数据需要在运行过程中被接收、解析、处理和延迟的事实，需要服务的底层方案逻辑包含这些复杂的算法和例程。这不仅会带来额外的设计考虑，还伴随着确保该服务能够处理大量可能的情况和大量的活动数据所需要的编程和测试的代价

服务可发现性

和其他原则的关系

• 服务可发现性与标准化服务合约
  • 使服务更加容易可发现和可解释会影响服务合约的内容
  • 服务可发现性会直接地影响功能表达设计标准的确定
• 服务可发现性与服务抽象
  • 服务抽象的原则需要减少合约当中所发布的信息数量；服务可发现性则要求提供更多的信息；两者之间需要取得平衡
  • 一旦实现了可发现性和抽象之间的适当的平衡，那么随后实现的服务的可发现性将基于那些已发布的（而不是被抽象的）元信息
• 服务可发现性与服务可复用性
  • 强调服务可发现性的主要目的是支持服务可复用性
  • 当表述可复用功能时，应当应用可发现性相关的设计标准，以保证能通过实际的技术合约把服务的目的和能力尽可能清楚地表述出来
• 服务可发现性与服务可组合性
  • 潜在的组合成员应当容易定位和识别，以避免在无意间创建冗余的服务逻辑
  • 当服务组合为了适应上层业务流程的变化或者为了增加整体的业务需求实现而发生演变时，需要查找从组合的原始版本创建以来，新加入的服务和功能

可能的风险

• 可发现性在实施后的应用
  • 在服务定义完毕后，再记录元数据，甚至由其他人员来加以记录，从而导致发现性和可解释性元数据的质量的损失
  • 应当在设计阶段，早于服务最初发布时，就把那些元信息添加到文档中
• 由不擅交流的人员来应用本原则
  • 如果可发现性信息仅仅是由业务或者技术专家创建的，那么它很可能不足以应付其他的项目组成员的使用

服务可组合性

和其他原则的关系

• 服务可组合性与标准化服务合约
  • 服务可组合性的应用强调服务间需要一致的合约标准
  • 由服务可组合性原则引起的考虑可以用来帮助形成服务合约设计标准，以便支持特定于组合（尤其是复杂的组合）的需求。
• 服务可组合性与服务松散耦合
  • 服务所具有的依赖关系会造成一些根本性的约束，直接制约服务能够达到的可组合性级别
• 服务可组合性与服务抽象
  • 当抽象被应用到复杂组合被隐藏的程度时，对这些组合高效可靠地执行的要求被大大放大。作为回报，组合所有者可以更好地控制如何改进组合配置。
• 服务可组合性与服务可复用性
  • 当一个成熟的服务库存建立起来的时候，服务组合就成为最常用的服务复用方式
    • 可复用但不可组合（参与多个点对点活动）
    • 可组合但不可复用（很高的“服务-消费者”耦合）
• 服务可组合性与服务自治
  • 这两个原则之间是“整体-部分”的关系
  • 控制器服务在组合其他服务时需要牺牲其自治性（等价于对所有涉及的服务组合成员的自治性的综合度量结果）
  • 服务自治性的提高有助于产生高效的组合成员
• 服务可组合性与服务无状态性
  • 尽可能地减轻每个组合成员在状态管理方面的责任，可以更精细、更优化地执行整体的组合实例
  • 为了能够在同一个服务库存中重复地装配出高效的服务组合，服务之间需要能够通过一致并且有效的方式共享状态数据
• 服务可组合性与服务可发现性
  • 作为组合控制器的服务能力可以负责描述它所封装的整个组合逻辑，并达到服务抽象原则所允许的任意程度

可能的风险

• 组合成员成为单点失效的源头
• 组合成员成为性能瓶颈
• 对于组合中“过度复用”所带来的治理强度

综合题

Web Service 从创建到调用

试结合相关协议和框架，描述一个 web service 从创建开始到被最终服务消费者调用的全过程对服务的建模、查询和调用的全过程。

协议栈的还原。

服务的建模

XML（Namespace、XML Schema）、SOAP、WSDL

• XML 定义了 web 服务中的消息交换格式，使用 XML Schema 定义不同的数据结构，引入 Namespace 使得 XML、XML Schema 中的元素和属性全球唯一且全球共享；
• SOAP 提供了一种标准的方法，使得运行在不同平台、使用不同的技术和编程语言的应用程序可以相互进行通信，服务的发布、查找、调用，都通过 SOAP 传递的 XML 消息。
• WSDL 对服务能力、服务中使用的数据结构以及传输绑定给出定义和描述；提供了一种基于 XML 的标准接口定义语言/服务能力定义语言，用以在服务的提供者/调用者/服务注册之间，交换必要的有关的 web service 的信息

对于大多数服务，用以上三个协议和框架可以完成建模；对于一些更为复杂的服务，如复合服务或者是带有非功能性需求的服务，还需要用到其他协议和框架完成建模。

• BPEL（Business Process Execution Language）定义多个服务间如何交互和合作，从而将一组现有的服务根据业务流程构建起来，实现业务服务。
• WS-Policy 可以实现一些非功能性需求，如信息加密，权限验证等。

建模完成后，服务提供者，通过 UDDI 或者 WSIL 将服务发布出去。其中，UDDI 利用分页机制，让服务得到最大可能的复用和共享范围；WSIL 使用树形连接结构，适用于企业既定的业务。

服务的查询

1. 消费者程序发送 SOAP 信息给服务注册，描述自己需要的服务；
2. 服务注册查询注册表，通过 WSDL 服务合约找到一系列符合条件的服务；
3. 服务注册将查询到的 WSDL 通过 SOAP 发送给消费者程序，让消费者程序从中选择可用的服务；
4. 或者服务注册自动化筛选出当前最符合消费者程序要求的服务，通知消费者程序。

服务的调用

消费者程序根据 WSDL 中提供的服务位置进行调用；

1. 消费者和提供者基于 WSDL 中约定的接口进行消息的发送和接收；
2. 当前服务可能同时被多个消费者程序使用，创建了一系列服务实例，WS-Addressing 提供了相应的机制，确保服务消费者能在实例池中找到特定的实例并与之通信。
3. 由于创建的实例是有状态的，利用 WSRF（Web Service Resource Framework）对状态数据进行存取，进行状态管理，提高资源利用率。

服务分析和服务设计

以电信企业为应用背景，举例描述服务分析和服务设计的过程。并结合面向服务的设计原则（标准化服务合约、服务松散耦合、服务抽象、服务可复用性、服务自治、服务无状态性、服务可发现性、服务可组合性），讨论“schema 集中化”“合约集中化”“逻辑集中化”在设计过程中的应用。

举例：电信企业有订购、退订套餐，账单结算等基本业务流程

服务分析流程

面向服务分析的目标是讨论需要构建哪些服务，每个服务应该封装哪些逻辑。分析的核心是业务服务：

1. 进行文档化的需求描述，定义流程自动化需求，作为服务候选建模的依据；由于电信企业发展比较完善，可以直接使用之前的需求文档分析
2. 对现有的自动化系统进行分析、识别；分析企业正在使用的系统具有的功能
3. 对服务候选建模，识别服务操作候选，并将其分组

在面向服务分析流程中，需要考虑服务可复用性、服务自治和服务的可发现性

• 可复用性：在服务建模中，需要：精化已有的服务能力候选，使其更加一般化和可复用；定义额外的服务能力候选，这些能力是在构成服务建模过程的基础的业务流程自动化所需之外的
• 自治：对已有自动化系统收集得到的消息，会影响服务系统所能达到的自治级别；比如根据信息决定保留遗留系统，那么达到共享自治，独立开发的可能达到逻辑自治或完全自治
• 可发现性：从服务生命周期开始，尤其是在产生服务操作候选时，需要以统一的方式，记录所有元数据；在服务建模过程中，业务和技术专家需要一起合作，建立服务候选

服务设计流程

服务设计过程，是从服务候选（逻辑）派生出具体的服务设计（物理），然后装配到实现业务流程的抽象组合中。

1. 组合 SOA：选择编排、业务、应用服务层中的哪些进行实现，定义核心的 SOA 标准，选择 SOA 扩展（WS-* 协议）
2. 根据业务层级，分别设计以实体为核心的业务服务，应用服务，以任务为核心的业务服务
3. 设计面向服务业务过程，组合服务构建出业务流程

设计过程应采用如下的设计原则：

1. schema 集中化：在服务设计过程中，应将所有数据结构统一定义在一个 schema 文件中，以确保服务接口的一致性和互操作性。
2. 合约集中化：在设计过程中，需要建立一个标准的服务合约，包括服务接口、数据结构、操作等。这可以确保服务接口的一致性和互操作性。
3. 逻辑集中化：在设计过程中，应将服务实现的逻辑集中到一个中心位置，以确保服务的一致性和可维护性。

schema 集中化

传统的做法是在订购服务、退订服务中使用不同的套餐数据结构，而按照标准化服务合约，所有使用的数据结构都应该被单独定义、管理，与具体的操作流程无关。

采用 schema 集中化的设计模式，将电信企业划分为多个分离的领域（部门），每个领域都可以被独立地进行标准化和治理，每个领域定义和管理自己的 schema，作为整个服务系统的基本数据结构；在不同的服务中，使用这些 schema，避免了频繁且不必要的数据转换；在必要的情况下，可以利用这些 schema 定义新的数据结构

合约集中化

为了保证服务松散耦合，避免消极耦合，采用合约集中化，将对服务的访问严格控制在合约内：

1. 所有的合约应该被集中管理，拥有一致的设计原则和设计目标
2. 在服务生态中，任何情况都不可以绕开合约去访问具体内容

服务抽象&服务可发现性：设计服务暴露的信息

服务抽象：技术信息、功能、程序逻辑、服务质量抽象

服务抽象出来并对外界可用的信息就是服务合约，服务合约的设计标准会影响到其他

逻辑集中化

为了实现服务可复用性，让消费者程序只调用指定的服务，要建立服务库存。在规范的服务库存中，每个服务代表了一个独特的功能域，这就要求服务边界之间没有重叠。

设置专家管理服务库存，应用开发人员不能直接往服务库存中增改需要的服务，只能请求当前服务库存管理人员进行审查，做出恰当的决策。

同时，服务可发现性是实现服务可复用的前提，服务自治是可复用服务潜在高性能和并行使用的保证；无状态性能提高服务的可用性。