Microsoft.NET的企业解决方案模式.第6章服务模式.docVIP

第6章 服务模式 发布日期： 2004-04-16 | 更新日期： 2004-04-16 版本： 1.0.0 抽象使我们能够为在运行时进行交互的分散的软件块指派行为和数据。在 体系结构完善的系统中，这些交互共同构成一个内聚在一起的可执行智能，从而为企业提供切实的业务价值。 上一章介绍了使用基于实例的协作和由近链接分隔的系统来将单个应用程序分布到多个处理节点上的模式。您可能已经回忆起来，“近链接”是连接驻留在同一个信任区域和同一个企业内的分布式系统的可靠链接；近链接不需要互操作性。远链接是所有其他链接（包括跨越 Internet 的链接）。本章主要关注通过远链接连在一起并且使用基于服务的协作的系统。 在构建由近链接连在一起并使用基于实例的协作的分布式系统时，开发组织通常能够完全控制解决方案中涉及的所有组件。但是，很多大型企业应用程序包含由远链接分隔的系统，不得不与预先已存在的、通常不受开发组织控制的系统交互。例如，订单管理系统可以使用在预先已存在的系统中实现的信用评分功能或者由外部服务提供者提供的销售税额计算服务。因此，复杂的解决方案有可能必须与由外部组织控制的功能进行交互，而且必须按其原样使用。 本章重点介绍应用程序和外部服务之间的协作。为了描述 Web Service 如何提供便于这种协作的互操作环境，本章概述了下列主题： ? 基本协作概念 ? Web services ? 使用 Web Service 实现的基于服务的协作模式 协作概念 类、对象、组件和接口是现代软件的基本构建单元。其中的一些元素用于封装问题域，而另一些元素则提供系统基础结构和技术体系结构。每个构建单元都提供一个有用的功能，但是实际功能取决于为一个企业（或许多互相联系的企业）提供实际业务价值的协作解决方案中各个元素的综合效果。为了实现这种级别的协作，软件元素必须遵循约定的组织原则，并且必须互相公开标准接口。如果组件不相似，则一个元素必须适应另一个元素，或者二者必须都要符合约定的标准。 基于服务的协议 第 5 章介绍了基于实例和基于服务的协作的概念，并重点介绍了每种方法的优缺点。基于服务的协作非常适合以下情形：使用服务的应用程序无法控制远程服务，或者必须与在不同的编程语言或平台之上所开发的解决方案实现互操作。 基于服务的接口负责公开用来向潜在使用者提供服务的接口的单个实例。在 Web Service 上下文中，Microsoft 将软件服务定义为“用于将适合通过网络进行访问的基于消息的接口公开的、离散的应用程序逻辑单元”。[Microsoft02-2] 服务不依赖于调用它的进程；它是独立的并与上下文无关。这将允许网络中的任何潜在使用者访问服务。可以用指定服务请求及相关回复的格式的合约方式很好地定义服务。 虽然不一定要基于消息，但是在分布式应用程序出现之前，在应用程序开发中使用了创建一组逻辑分组服务的概念。例如，操作系统向其上运行的所有应用程序提供服务，如 Microsoft Windows? GDI 库提供图形服务，开放式数据库互连 (ODBC) API 提供数据库访问服务。正如将操作系统的一些核心功能抽象为一组服务有助于简化应用程序编程模型一样，标识企业的核心业务功能并将它们封装为一组互操作服务有助于简化与企业防火墙外部的模式进行协作。 面向服务的体系结构 面向服务的体系结构 (SOA) 将服务概念应用于分布式企业应用程序。在 SOA 中，每个应用程序都将高级业务功能以服务的形式公开，以便供其他应用程序使用。因为这些面向服务的解决方案的范围很广且比较复杂，所以面向服务的体系结构除提供调用远程服务功能以外，还必须提供其他功能。其中最重要的功能包括： ? 使服务可在运行时找到。 独立应用程序能够很容易地找到操作系统服务（如 GDI 调用），这是在名为 gdi32.dll 的本地动态链接库中实现的。但是，企业服务可能会跨许多计算机、网络或设备分布。其中的一些服务是绑定到现有应用程序的，所以其位置可能会发生变化。因此，在面向服务的分布式体系结构中查找服务可能是一项复杂的任务。 ? 让服务和使用者约定公用格式。 找到正确的服务之后，使用服务的应用程序必须能够动态确定要使用哪个协议来访问服务、如何格式化请求以及期望哪种类型的响应。因为服务可以使用各种语言和平台实现，所以使服务和使用者约定公用格式也可能是一项颇具挑战性的任务。 服务合约 当一个方法调用应用程序内的另一个方法时，该方法签名定义了此方法与调用方之间的“理解”，例如，传递到该方法并在完成时返回的参数的数量和类型。因为调用方和方法进行了许多隐式假设，方法调用可将它们的理解嵌入到一个简单的方法签名中；例如，这两种方法都在同一个进程中执行，并且使用共同的内存空间；这两个方法都使用同一种编程语言；在被调用的