记录督促学习历程17

一旦选择了可选服务，服务工程过程的下一个阶段就是设计服务接口，这包括定义与服务关联的操作以及它们的参数。也需要仔细地考虑服务操作和消息的设计，目的是使得完成服务请求一定要发生的消息交换的辞书最小，必须确保在一个消息中尽可能多地携带索要传递给服务的信息，而不采用同步的服务交互。

应该记住服务的状态管理特定服务应用状态是服务用户的职责。
服务接口设计有三个阶段：
1逻辑接口设计，2消息设计 3 WSDL开发，用WSDL语言将逻辑设计和信息设计翻译成抽象接口描述。WSDL（Web服务描述语言，Web Services Description Language）是为描述Web服务发布的XML格式

定义异常和异常如何传达给服务用户是特别重要的，服务工程师不知道他们的服务将会被如何使用，且假定服务用户将会完全理解服务描述通常是不明智的。输入消息可能是不正确的，所以应该定义异常向服务客户报告不正确的输入。

一旦建立了有关服务应该做什么的非正式逻辑描述，下一个阶段就是定义输入的输出消息的结构以及在这些消息中使用的类型，XML不适合在这个阶段中使用。

注意在理是如何把细节加入到描述中的，是通过用约束注解UML图表，定义了表示公司和目录项的字符串的长度，指定项目数必须大于0，交付必须在当前日期之后，注解也现实了与每个可能的故障关联的错误代码。

服务设计过程的最后阶段是将服务接口设计翻译成WSDL，如前面所讨论的，WSDL表示很长且很详细，因此如果在这个阶段手工完成这些就很容易出错。

服务实现和部署，一旦找到了可选服务且设计了它们的接口，服务工程过程的最后阶段就是服务实现，实现可能设计使用某个标准的编程语言。编写服务程序，这两种语言现在都包括对服务开发广泛支持的库。

服务的开发可以通过向现有组件或遗留系统（？）添加服务接口的办法实现。
服务一经实现，在部署它之前必须通过测试，这包括检查和划分服务输入，创建反映这些输入组合的输入消息，然后检查输出是否是预期的。

服务部署时过程的最后阶段，包括在Web服务器上部署此服务，绝大多数服务器软件使这步变得非常简单，只需要在特定目录下安装包含可执行的服务的文件。

服务描述可能包含的信息主要是：
1有关企业的信息、联系方式等。
2服务提供的功能的非正式描述。
3接口类型和语义的详细描述
4订阅信息，允许用户注册以获取有关服务更新的信息。

服务描述的一个一般问题是，服务的功能行为是通过自然语言描述非正式给出的。

遗留系统服务，遗留系统是指一个机构使用的旧的软件系统，遗留系统通常依赖过时的技术但是对于业务仍然至关重要。

增强系统以支持这些需求事实上是不可能的，所以公司决定为维护人员和呼叫中心人员提供新的应用。

遗留系统将被用作实现多个服务的基础，所提供了一些服务：1维护服务2工具服务3日志服务，为访问遗留系统所开发的服务是关联的，每一个支持单一方面的功能。这不但降低了复杂性并且使其在其他应用中更容易理解和复用。

使用服务的软件开发基于：组合并配置服务来创建新的复合服务，这些复合服务可以与一个在浏览器上实现的拥护界面集成来创建一个Web应用，或者可以被当做组件用于某个其他服务组合。

服务组合是衣蛾集成过程，可以用来集成分离的业务过程从而能提供更加广泛的功能。

工作流是一个简单的思想，服务组合要比简单模型所暗含的要复杂得多，，必须考虑服务时效的可能性，并加入一些机制来处理这些失败，

我们必须能够应付：工作流不得不改变，因为某一个服务的正常执行总是导致与其他服务之星的不兼容。
通过复用现有的服务的新服务设计过程，本质上是使用复用的软件设计过程。使用复用的设计不可避免要在需求上作出妥协。
通过组合构建服务 的过程有六个关键阶段：
1表达概略工作流
2发现服务
3选择可能的服务
4精炼工作流
5创建工作流程序
6测试完成的服务或应用。

工作流设计包括分析现有的或计划中的业务过程来理解所发生的不同活动以及这些活动是怎么交换信息的，接着用工作流设计符号定义新的业务流程。工作流设计列出了执行过程中的各个阶段和不同过程阶段之间所传递的信息。

工作流表示的是业务过程模型，且通常使用图形形式来描述，工作流模型标准的制定将会是基于这种整合后的语言。
BPMN是一种相当容易理解的图形语言，人马定义了一种映射，将此语言翻译为较低级的、基于XML的描述-WS-BPEL
BPMN创建工作流模型核心概念一些是：1圆角矩形表示活动，一个活动能被一个人活着一个自动化服务执行
2圆圈表示时间。一个事件是在一个业务过程当中发生的某事，简单圆圈用来表示一个开始时间，教黑的圆圈表示一个结束时间。
3菱形用来表示一个通道，通道是过程中的一个阶段，在此做出某个选择。
4实践箭头用来表示活动序列，虚线箭头表示活动之间的消息流
这些主要特征足够描述大多数工作流的本质。

BPMN术语中，每一个机构的工作流被表示在一个独立的池中，用图表示为：将过程中的每个参与者的工作流包在一个矩形，并在左侧边缘上垂直写下名称。

一旦业务过程模型设计出来，它必须经过提炼，这依赖于已经发现了的服务。

一旦最终设计完成，必须将其转换成一个可执行程序，过程主要包含两个活动：
1实现找不到可供复用的服务。
2生成工作流模型的可执行版本。

为了提供对 Web服务组合实现的直接支持，人们提出了一些Web服务标准。

测试对于所有的系统开发过程来说都是重要的，因为表明一个系统满足它的功能性和非功能性需求，且检车在开发过程中所导入的缺陷。许多测试技术，比如，程序检查和覆盖测试，依赖于对软件源代码的分析。但是，当服务由一外部提供者所提供时，服务实现的源代码是不可得的，因此基于服务的系统的测试不能使用工人的基于源代码的技术。

在对服务和服务组合进行测试时，除了有对服务实现的理解问题外，测试者也可能面对更大的困难：
1外部服务是受控于服务提供者而不是服务的拥护。
2面向服务体系结构的远景目标是服务丰台绑定到面向服务的应用，
3服务的非功能性行为不只依赖于它是如何被正在测试的应用使用，
4服务的支付模型可以使服务测试变得昂贵。
5当某个异常发生而先前做出的承诺不得不撤销的时候，补偿动作被调用，对这样的动作进行测试存在一个问题，因为它们可能与其他的服务失败有关，确保这些服务在测试过程内真的时效可能非常困难，

当使用的是外部服务时，这些问题就特别敏感。