微软《SOA in the Real World》笔记10——第二章

 

微软SOA in the Real World笔记10——第二章

 

服务分类

在考察服务类别时会注意到两种主要的服务类型：本来是基础设施的服务，提供通用的、不会被认为应用的一部分的功能，以及属于应用的一部分的服务，提供应用的构建块。

 

软件使用了一系列不同的通用功能，包括由操作系统提供的诸如内存管理和I/O处理的底层服务，以及由C语言运行时库（RTL）、Java平台或者.NET Framework等所提供的高层次的、特定运行环境的运行时服务。使用SOA创建的解决方案同样使用通用的功能，例如服务验证框架（如WCF）和一组用于支持分布计算的服务。这部分服务命名为总线服务（Bus Services）。

 

总线服务可以进一步分为通讯服务（Communication Services），提供诸如消息路由和出版订阅机制等的消息传递功能，以及应用服务（Utility Services），提供诸如服务发现和联邦安全性等的功能，这些功能与消息传递无关。

 

通过使用粗粒度的、高层次的构建块能够进一步提高软件开发的效率。在面向组件时代（如VB或Delphi）盛行的RAD开发环境提供了快速简单地组合功能模块创建新的应用程序的能力，这些功能模块由已有的构建块提供，具有特定的应用程序域。这种组件的例子包括更通用的GUI控件和数据库访问组件，和更为具体的图表或事件日志组件。SOA中的组合应用同样采用这种属性的构建块。这些构建块可称为应用服务（Application Services）。应用服务可进一步服务实体服务（Entity Services），用于暴露和操作业务实体，功能服务（Capability Services）和活动服务（Activity Services），用于实现应用程序的构建块（有时称为组件或模块），以及流程服务（Process Services），用于组合和编排功能服务和活动服务，从而实现业务流程。

 

下图展示了上文中所说的服务分类的一种可能的组合方式。

 

总线服务是没有提供任何明确业务价值的通用功能，但它是在SOA中实现业务流程的必要的基础设施。总线服务通常是外购的或者是核心的组件，为多个应用程序提供服务，通常集中管理。

 

通讯服务

通讯服务负责把消息传入、传出系统，以及在系统内传递消息，而不用考虑消息的内容。例如，一个桥接器可以穿过网络边界把消息来回传递（也就是说，桥接两个不同的断开的网络），或者是穿越协议边界（例如在WebSphere MQ和MSMQ间传递队列消息）。通讯服务的例子包括转发器、发布订阅系统、路由器、队列和网关。

 

通讯服务不保持任何应用程序状态，但是在很多场合中，他们被配置使用在相关的应用程序中。特定的程序可能需要指示和配置通讯服务如何在应用程序内传递消息，这样才有可能在松耦合架构中实现组件间的通讯。例如，一个以内容为基础的路由器可能需要应用程序提供路由指令，这样，路由器才会知道把消息转发到哪里去。另一个例子是发布-订阅服务器，通过应用消息内容过滤器，把消息发送给注册的订阅者。应用程序可以设置这个过滤器。在这两种情形中，通讯服务都不处理消息的内容，而是使用消息的一部分作为指令，以便决定消息的去向。

 

除了特定的应用需求之外，由安全性、规范或其他类型的约束所强加的限制指出，为了使用通讯服务所提供的功能，用户需要获得一定的许可。可以在应用程序的范围内设置这些许可（也就是说在不考虑使用这个应用的特定用户的情况下，允许应用程序使用服务），也可以在用户的范围内设置（也就是说在不考虑用户正在使用的特定的应用程序的情况下，允许特定的用户使用服务），或者在应用程序和用户的范围内设置（也就是说在运行特定的应用程序时允许特定的用户使用特定的应用）。例如，发布订阅服务可以配置用来限制只能由订阅的用户才能访问特定的主题。

 

通讯服务可以提供的其他应用程序级别的功能有监控、诊断和业务活动监控（BAM）。通讯服务可以提供应用程序的统计信息，例如消息流量模式分析（例如每秒通过一个网桥的消息的数量），错误率报告（例如每天通过一个路由器发送的SOAP中出错的数量），或者是业务级别的性能指示器（例如通过一个合作伙伴的网关进来的购买订单的数量）。尽管这些功能可能只针对特定的应用程序，但是他们与那些控制消息流的配置功能也没有什么不同。这些信息一般由通讯服务的通用功能提供，通常由应用程序进行配置。提供的统计信息通常由应用程序的特定部分所消费，应用程序知道如何处理这些信息（例如，在数据中心生成一个安全警告，或者在CFO的计算机屏幕上更新一个与BAM有关的图表）。

 

应用服务

应用服务提供通用性的、与具体应用无关的服务，用于处理与消息传输无关的有关方面的问题。和通讯服务一样，他们提供的功能是SOA基础设施的一部分，而且与特定的应用程序逻辑和业务流程无关。例如，在松耦合的应用程序中，发现服务可用于组件基于特定的条件查找其他的组件（例如，部署到预生产环境中的服务可以查找实现了特定接口的其他服务，这些服务也部署在预生产环境中）。应用服务的例子包括安全和身份服务（例如身份联邦服务或者安全令牌服务）、发现服务（例如UDDI服务器）和消息转换服务。

 

和通讯服务一样，特定的应用程序也能指示和配置应用服务如何执行其上的操作。例如，消息转换服务可以把一种消息样式转换为另外一种消息样式，这种转换是以使用该转换服务的应用程序提供的转换影射为基础的。

 

尽管应用服务不保留任何应用的状态信息，但是应用服务的状态可能受到系统状态改变的影响。例如，在应用程序中增加新的用户可能需要更新安全令牌服务中的信任证书设定。与通讯服务不同的是，客户服务直接与应用服务进行交互，这些应用服务处理以及答复（如果必要的话）客户服务发送来的消息。

 

应用服务的用户可能需要为他们配置相应的许可来使用这些服务，可以在应用程序、用户或者是程序—用户的范围内进行配置。例如，发现服务只为通过了域验证的用户提供服务（也就是指那些用户拥有Windows域控制器所发布的信任证书）。

 

与通讯服务一样，应用服务也可以提供应用程序级别的功能，包括监控、诊断和业务活动监控（BAM）等。这些功能包括使用模式的统计信息（例如，组织中有多少用户使用了联邦身份进行验证），与业务相关的出错率（例如，由于传入消息的恶劣的格式而造成的消息格式转换失败的数量）等等。与通讯服务一致的是，这些功能同样是应用服务的通用特性，他们需要在特定的解决方案中进行配置和应用。

 

应用程序服务

应用程序服务是那些参与业务流程实现的服务。他们提供了明确的业务价值，以多种方式存在，从能够应用于组织中的任何组合应用的通用服务，到只应用于单个组合应用的特殊服务，以及处于两者之间的那些可用于两个或多个组合应用的那些服务。

 

实体服务

实体服务为系统中的业务实体进行了松绑，提供了统一访问服务。他们可能被看作业务流程中的数据组件（“名词”）：雇员、客户、销售单等等。实体服务的例子有客户服务，用于管理客户信息，和订单服务，用于跟踪和管理客户所下的订单，等等。

 

实体服务对数据存储（如SQL Server、活动目录等）进行了抽象，通过服务接口暴露了系统中保存在一个或多个数据源中的数据。因此，可以肯定地说，实体服务管理着系统的持久状态。在某些情况下，所管理的信息会超出单个特定系统的边界，用于多个系统甚至是组织中的所有的系统中。

 

实体服务通常提供的功能包括：提供实体级别的CRUD接口，为特定的问题域增加相关的的操作，支持应用程序的特性和用户场景。特定领域操作的一个例子是在客户服务中暴露一个名为FindCustomerByLocation的方法，该方法可以通过给定的客户地址确定客户的ID。

 

实体服务所管理的信息通常比业务流程要存在得久一些。实体服务所暴露的信息通常是结构化的，而不是关系型的或层次化的。例如，实体服务可以把存储在多个数据库表，甚至是多个分散的数据中的信息聚集起来，并把这些信息发布为一个单一的客户服务实体。在某些情况下，特别是为了方便的原因，实体服务的实现选择了把数据暴露为DataSet而不是强格式化的XML数据。即便DataSet不是严格意义上的实体，这些服务从分类方面仍旧被当作是实体服务。

 

实体服务的用户可能需要为他们配置相应的许可来使用这些服务，可以在应用程序、用户或者是程序—用户的范围内进行配置。这些许可可以对数据访问和修改施加限制，可以在“行（实体）”的级别，也可以在“列（实体元素）”的级别施加这些限制。在列的级别施加限制的例子如下：一个HR系统可以访问雇员实体的社会保险号和家庭地址，而一个打印检查服务则职能访问家庭地址。在行的级别施加限制的例子如下：一个费用报表程序允许经理查看和审批那些向他汇报的雇员们的费用报告，而不能处理不向汇报的雇员们的报告。

 

实体服务中的错误补偿大多数情况仅限于寻找替代的数据源，或者根本不进行补偿。例如，如果实体服务不能访问本地数据库时，它会尝试连接数据库的远程副本以获取所需的信息。为了支持系统状态的一致性，实体服务通常支持紧耦合的分布式原子事务。支持分布式原子事务的服务参与流向他们的事务，并把数据存储中状态的改变提交到那些分布式原子事务的结果中去。为了更低程度的状态改变的耦合性，实体服务可以为更松散耦合的预订模式提供支持，而不管是否支持分布式原子事务。

 

实体服务通常在内部建造成一个现有数据库的包装容器。这些服务典型的实现方式是，通过手工编码把数据库映射到实体并暴露为服务接口，或者是通过软件工厂生成映射代码和服务接口。来自于Microsoft的Patterns & Practies组的Web Services Software Factory就是软件工厂的一个例子。在某些情况下，数据库（例如SQL Server）或者是以数据为中心的应用（如SAP）本身可能会提供通过服务接口访问数据的功能，消除了创建和维护分离的实体服务的工作。实体服务通常用于不止一个的组合应用中，因此通常是集中管理的。

 

功能服务

功能服务实现了组织的业务级别的功能，代表着以活动为中心的构造块（或称为“原子动词”），这些服务组成了组织的业务流程。功能服务的为数不多的例子包括第三方接口服务，例如信用卡处理服务，用于组合应用中与外部的支付网关进行交互，该组合应用支持信用卡支付，增值的构造块，例如评分服务，用于处理和计算用户对应用程序中可以进行评分的内容（如帮助页面、书籍、厂商等等）所作的评分，或者是通讯服务，例如Email网关服务，可以在所有的组合应用中使用，发送Email给客户和雇员。功能服务可以按照其提供的服务类别紧紧行进一步的细分（如第三方接口、增值构造块或者是通讯服务），更深一步的区别超出了本章讨论的范围。

 

功能服务暴露了特定于其提供的功能的服务接口。在某些情况下，现存（遗留）的或新增加的业务功能可能与组织把功能暴露为服务的方式不一致，甚至根本不可能暴露出服务接口。在这种情况下，通常把功能包装成一个薄的服务层把功能的API暴露为服务接口，从而与组织暴露功能的方式保持一致。例如，信用卡处理服务公司发布了以HTML为基础的API，可以要求用户填写Web表单。类似上述的功能可以 in-house-created-and-managed-façade-service使用进行封装，提供了针对功能的更容易的编程访问方式。这种外观服务是不透明的，掩盖了服务背后的功能的实际特性，这样可以达到在不改变服务接口的情况下替换掉相应功能实现的目的。因此，这种外观服务可以被当作功能服务，相应的功能只不过是外观服务的实现细节。

 

功能服务通常不直接管理应用程序状态，而是在应用程序中使用实体服务进行改变修改。如果功能服务进行了状态管理，这种状态通常是暂时的，其持续的时间也比完成功能服务所参与的业务流程所需的时间要短。例如，提供了包裹运输报价单的功能服务可能需要记录发送到运输提供者的询价请求，直到收到了回应，然后删除该记录。进一步说，实现为工作流的功能服务将会管理所有当前运行的工作流实例中持久的及临时的执行状态信息。因为大多数功能是“无状态的”，因此就有了事件日志这类明显的功能来管理和封装状态。

 

实体服务的用户可能需要为他们配置相应的许可来使用这些服务，可以在应用程序、用户或者是程序—用户的范围内进行配置。通常在应用程序级别设置功能服务的访问权限。针对单个用户的许可通常由使用功能服务的流程服务进行管理，可以简化管理，防止流程中的访问失败。

 

功能服务中的错误补偿仅限于满足功能的服务级别例外处理（SLE）和服务级别协议（SLA）。例如，Email网关服务可以在后台把email通知放入队列中以便于延迟投递，即如果邮件服务出了问题，在以后email连接恢复之后重新发送。快递服务通常比较四个供应商（如FedEx、UPS、DHL和一家本地服务公司）的费率和投递时间， may compensate for a vendor‘s unavailability by ignoring the failure and continuing with the comparison of the rates that it was able to secure as long as it received at least 2 quotes 。这些例子显示了失败可能会造成更低的效能。这种降级可以用如下属于进行表示：反应时间（客户Email服务的情况下）、服务质量（如快递服务可以只比较2个报价而不是4个报价）以及其他许多方面，因此需要在服务的SLE和SLA中进行描述。

 

功能服务支持分布式原子事务和预订模式。大多数功能服务不管理那些需要通过原子事务进行状态管理的资源，但是功能服务可以把其包含的原子事务传递给它所使用的实体服务。Capability Services are also used to implement a reservation pattern over Entity Services that do not support that pattern, and to a much lesser extent over other Capability Services that do not support that pattern。

 

功能服务可以在内部开发和管理，也可以从第三方购买在内部管理，或者是从外部供应商那里“租赁”并以SaaS的方式进行使用，这种方式下，服务是在外部开发、维护和管理的。

 

当内部开发时，功能服务可以通过规则代码或声明式工作流进行实现。如果通过工作流进行实现，功能服务通常建模成短期运行（原子的、 non-episodic）的业务活动。长时间运行的业务活动可能会出现错误或者需要补偿行为，通常归类进流程服务。

 

功能服务几乎总是用于多个组合应用，因此通常进行集中管理。

 

活动服务

功能服务实现了业务级别的功能，或者是一些以活动为中心的业务逻辑元素（或称为“构造块”），这些功能对于特定的应用程序是唯一的。活动服务和功能服务的主要区别在于他们应用的范围。功能服务是一种组织资源，而活动服务则用在小得多范围内，例如单个组合应用中或者是单个解决方案（由多个应用组成）中。经过一定的时间以及足够多的重用，活动服务可以演化为功能服务。

 

创建活动服务通常是为了方便复杂流程的分解，或者是为了特定的功能模块的重用，这些功能模块可以用在特定流程服务中的多个地方，也可以用在应用中不同的流程服务中。创建活动服务的动力来源于多个方面，例如组织的力量、安全需求、规范化的需求等等。用于分解场景的活动服务的例子是， a Vacation Eligibility Confirmation Service that due to security requirements separates a particular part of a vacation authorization application‘s behavior such that that part could run behind the safety of the HR department‘s firewall and access the HR department‘s protected databases to validate vacation eligibility ；用于共享功能的活动服务的例子是， a Blacklist Service that provides information on a customer‘s blacklist status such that this information can be used by several Process Services within a solution 。

 

与功能服务一样，活动服务提供了特定于其提供的功能的服务接口。把现有的功能单元封装为活动服务是可能的，特别是在把已有系统升级或者是加入到SOA解决方案的过渡的情况下。

 

与功能服务一样，活动服务通常不直接管理应用程序状态，而是在应用程序中使用实体服务进行改变修改。如果功能服务进行了状态管理，这种状态通常是暂时的，其持续的时间也比完成功能服务所参与的业务流程所需的时间要短。但是， due to their slightly larger granularity and the cases where Activity Services are used to wrap an existing system, it is more likely than an Activity Services will manage and encapsulate application state。

 

活动服务的用户可能需要为他们配置相应的许可来使用这些服务，可以在应用程序、用户或者是程序—用户的范围内进行配置。与功能服务一样，通常在应用程序级别设置活动服务的访问权限。针对单个用户的许可通常由使用功能服务的流程服务进行管理。

 

活动服务具有和功能服务相同的错误补偿和事务使用方式。

 

活动服务可以在内部开发和管理，可以通过规则代码或声明式工作流进行实现。与功能服务一样，如果通过工作流进行实现，活动服务通常建模成短期运行的业务活动。

 

活动服务通常用在单个的应用或单个解决方案中，因此单独进行管理（例如在部门级别）。如果一个活动服务演化为功能服务，服务的管理通常也就转为集中管理方式。

 

流程服务

流程服务把以数据为中心的构造块和以行为为中心的构造块联结起来，实现组织的业务流程。流程服务把活动服务、功能服务和实体服务提供的功能进行组合，并用流程服务中的业务逻辑联结起来，这些流程服务创建了定义业务操作的蓝图。流程服务的例子有采购订单处理服务，该服务接收采购订单、进行验证、检查黑名单服务以确定合法客户、使用信用验证服务检查客户信用、通过库存（实体）服务确认库存、使用快递服务安排发货、通过Email网关服务通知客户订单已完成以及货物的ETA，以及最后在订单列表中把订单标记为完成状态。

 

流程服务可以组合进其他流程服务的工作流中，但是由于其长期运行的特性，不能转为功能服务或者是活动服务。

 

因为流程服务实现了组织中的业务流程，所以经常通过用户界面来启动、控制和监控工作流程。The service interface that these services expose is typically geared towards consumption by an end user application, and provides the right level of granularity required to satisfy the use cases that the user facing front-end implements. 监控业务流程有时需要暴露BAM信息的分离的监控接口。例如，订单处理服务可以报告未确定的、处理中的和完成了的订单的数量，以及和他们有关的统计信息（用于处理订单的平均时间、平均的订单大小等等。）。

 

流程服务通常要管理流程活动期间的与流程有关的应用程序状态。例如，采购订单服务管理订单的状态直到流程完成。同时，流程服务也会维护和跟踪业务流程的当前步骤。例如，实现为工作流的流程服务会保持所有当前运行的工作流实例的执行状态。

 

流程服务的用户可能需要为他们配置相应的许可来使用这些服务，可以在应用程序、用户或者是程序—用户的范围内进行配置。通常在用户级别设置流程服务的访问权限。

 

流程服务很少参与到分布式原子事务中，这是因为他们支持长时间运行的业务活动（也就是熟知的长时间事务），错误补偿出现在业务逻辑级别，可能涉及人参与的工作流。当调用他们所使用的服务时，流程服务也可以使用分布式原子事务。

 

流程服务通常在内部开发和管理，因为他们捕捉了组织中核心价值，即“秘密调料”，这部分内容决定了组织从事业务的方式。Process Services are designed to enable process agility (i.e. to be easily updatable) and the process that they implement is typically episodic in nature (i.e. the execution comprises of short bursts of activity spaced by long waits for external activities to complete). 因此，流程服务最好实现为声明式工作流，实现时使用集成性服务器（如BziTalk Server）或者工作流框架（例如Windows工作流基础）。

 

流程服务通常使用在单个应用程序中，因此可以单独管理（例如在部门级别）。在某些情况下，可重用的业务流程就能作为SaaS来提供和使用。

 

在设计业务软件时，应该记住的是我们的目标是交付敏捷的系统，用于支持业务，而不是支持面向服务（SO）。SO是让业务和技术变得敏捷的方法，而不是其本身。This must particularly be borne in mind with references to Web services. Achieving the agility that so often accompanies Web services is not just a consequence of adopting Web service protocols in the deployment of systems, but also of following good design principles. In this article, we consider several principles of good service architecture and design from the perspective of their impact on agility and adaptability.