标准化服务端点

来源：互联网发布：优化经济发展环境讲话编辑：程序博客网时间：2024/05/29 05:11

　　与之前的所有分布式计算体系结构相比，面向服务的体系结构 (SOA) 对于标准化的需求更为强烈。向 SOA 转变的全面铺开为用户提供了将具有深远意义的标准化合并至体系结构中的机会，以支持在企业内跨不同技术平台实现同质联合状态。

　　创建为面向服务的解决方案组成部分的 Web 服务是其提供的任何业务功能的潜在端点。尽管可能需要限制对某些服务的访问，但也可使来自各种源的用户访问许多其他服务。以标准化的方式完成此操作将非常有助于发展为名副其实的面向服务的企业。

　　本文将详细介绍在设计服务接口定义方面的努力会如何帮助促进标准化 SOA。其中探讨了一系列使用 WSDL 的设计惯例，并简要介绍了 Oracle SOA 平台中即将推出的增强功能，这些功能支持创建标准化的服务端点。

　　面向服务的范围

　　现在，围绕面向服务的体系结构模型构建技术平台代表了分布式计算发展的下一阶段。SOA 的基础和定义(即面向服务的设计范例)将对自动化逻辑(服务)的个别单元产生显著影响，并由此形成使用这些服务的大型自动化环境的结构。

　　面向服务所提倡的原则(如重用、互操作和联合)最终会对个别企业服务、解决方案以及集成环境等的设计产生重大影响。这种设计反过来会影响到由这些环境代表的个别企业域存在、运行以及相互关联的方式。尽管 SOA 模型允许企业通过标准化服务接口层包住外部环境和完全不同的环境，但是只有从一开始就实施并使用标准，才能获得这个重要的好处。

　　标准的影响

　　与其他框架、技术平台或体系结构模型一样，指导原则可能被滥用。在面向服务的计算领域中，由于应用程序范围潜在的广泛性，因此滥用的危险性更大。如果企业还没有使用内部标准并尊重其使用的习惯，则引入此种概念将面临很大的挑战。

　　在标准建立阶段，企业中的一些顶级专家将需要了解当前环境的局限所在，并根据 SOA 战略目标以及由典型转变而导致的技术和机构更改对其进行权衡。可以确定的是，创建标准会花费大量时间和精力，并需要做出大量的决策。

　　一旦制定了标准，就需要在项目生命周期中使用这些标准。有时，说服他人使用标准要比实际创建标准更为困难。标准的推广通常不会一帆风顺，这是因为很多人将其视为开发流程中阻碍创造力和降低灵活性的条条框框。

　　然而，通过明确分工使项目组成员不必重复研究各种设计，固执的开发人员也可能会发现标准确实可以简化解决方案流程。这可以为开发前项目阶段节省很多时间，并可简化整体解决方案设计。

　　不过，支持企业级 SOA 转变的标准会对个别项目产生不合理的要求。例如，对于重用的强调可能需要额外的时间和精力来识别自动化逻辑单元，而这些单元可能在当前解决方案范围之外有用。

　　相反地，当存在可重用服务时可能会阻止项目增加特性。此种情况下，开发人员将被迫围绕一个或多个现有服务合并和构建解决方案。

　　这些以及其他许多情况可能导致出现这样的想法，支持 SOA 的标准对个别开发项目会造成不必要的负担，使得整体解决方案的设计更加复杂，并对预算和时限产生了负面影响。

　　建立可预测的面向服务的企业

　　标准可应用于不同级别的面向服务环境。在最高级别，可以标准化体系结构规范和其他类型的内部文档以及一些基础架构组件，如服务注册表。

　　最常被忽视但又对获得成功的面向服务性至关重要的设计标准是那些应用于个别服务的设计标准。

　　在将服务实施为 Web 服务时，这些标准的意义将更为重大。身为 Web 服务基础的非专有通信框架使得企业中任何能够参与作为服务请求方的部分都可以使用该服务。随着企业内标准化 Web 服务的增长，它成为了重新利用已开发和部署服务中投资的有效方法。

　　Web 服务提供了当今获得标准化 SOA 的首要方法，但在开始之前，我们需要假定 WSDL 定义的所有权。本文的其余部分将探讨支持面向服务的标准是如何创建服务接口的。

　　控制 WSDL

　　构建 Web 服务的“WSDL 优先”方法实质上倡导开发人员通过自定义 WSDL 定义尽量减少对自动生成实用程序(多数开发工具都有提供)的依赖，而改用手动方式定义服务接口。这种方法的好处是开发人员可以控制服务的接口和封装的逻辑。

　　为了了解接口级标准化，我们需要分解构成 Web 服务接口的 WSDL 定义。WSDL 定义是一种由 W3C WSDL 规范定义的 XML 文档，它包含正式表述服务接口及其支持的实施抽象和具体的描述。这些都是分开的，以便更改实施细节而不会影响消息数据的特征。

　　因为具体的定义通常受现有技术基础架构影响或由其定义，所以本文将着重介绍抽象定义的设计，其中需要考虑到以下设计注意事项:

　　服务接口粒度 — 把由服务封装的逻辑分割并通过服务操作提供。
　　服务数据交换要求 — 建立特定的消息处理要求。
　　服务数据表示 — 定义和引用数据结构和数据类型。
　　服务接口标注 — 应用于服务接口本身的命名惯例。

点击放大此图片

　　图 1:可应用标准的抽象 WSDL 定义领域

　　抽象定义设计的一些主要方面可在总体上提高服务的质量和可用性。以下是对各注意事项的详细介绍。

　　服务接口粒度

　　确定如何通过服务的公共接口提供其基础逻辑可能是服务设计中所面临的最大挑战之一。这会引起您企业内部对“是要粗粒度操作还是细粒度操作”的大量争论。

　　细粒度操作一般与远程过程调用 (RPC) 型的通信模式关联，这种方式重点放在为完成某项特定任务进行的少量参数数据交换。如果需要由同一服务执行其他任务，则只需随后调用其他服务操作即可。示例 1 显示了用于定义细粒度操作的“消息”和“操作”结构。

示例 1
GetProfileName 操作要求一个输入值，用作检索配置文件名输出值的搜索条件。此时，输出和输入值均由简单的自带 XSD 类型表示。（元素结构简单的复杂类型也可用于定义细粒度消息。）

　　众所周知，使用细粒度方法的不利方面在于，服务操作中基于消息的调用代价高昂，从而导致完成较大流程中较小子任务的个别消息传输和处理的开销。

　　粗粒度操作可在单个服务调用中提供大量功能。它通常会将各种较小的任务捆绑为单一的粗粒度操作，以便通过传输一个请求消息来完成更多的任务，如示例 2 所示。

示例 2
GetProfileInfo 操作通过复杂类型结构接受多个输入搜索条件值。类似地，该操作响应一个复杂类型，它能够包含多个输出值（其中之一可以是配置文件名）。尽管在设计灵活模式时，将其归为粗粒度操作，但是该类型操作可接纳细粒度和粗粒度数据交换。

　　粗粒度方法的优势在于，请求方到提供方之间的往返比较少，从而相应的处理周期也较少。只是，粗粒度操作经常会提供超过其实际真正需要的功能。结果，它们可能向服务请求方请求更多的输入值或较大的文档结构，而实际上可能只有一小部分数据与请求方要求服务执行的操作有关。

　　尽管在服务设计中通过标准化一个粒度级别来促进面向服务比较困难，但是请牢记一个关键目标，即流程必须在容纳这些可提供即时解决方案的项目和那些业务调查和推测性分析所需的项目之间进行平衡。这种平衡将确保服务接口达到的粒度级别可满足当前和已知的未来数据交换要求。

　　服务数据交换要求

　　一旦确定服务将提供哪些操作以及每个操作将封装什么逻辑，您就需要确定操作执行其任务所需的输入和输出值。这些设计决策的复杂性与接口粒度的级别有关。细粒度操作的数据交换要求往往比较简单，而较粗粒度的操作则可能引入多种输入和输出数据集组合。

　　避免粗粒度操作要求过多不必要数据传输的常用策略是使用可选参数。一个操作可能能执行多种相关功能，但实际执行的功能却由接收到的参数来决定。相应地，根据操作实际完成的工作，其返回的输出值也会有所变化。

　　尽管可选参数实用且可扩展，但它们的使用应限制在 Web 服务内。可选参数可导致服务接口设计错综复杂以及各种令人迷惑的数据交换情形。此外，可选值的扩展通常受限于定义消息结构的基础 XML 模式。代表已建立的公司文档的标准化模式可采用严格的数据结构。

　　相关注意事项是与服务操作通信是要求单向还是双向数据交换。在 RPC 时代，同步模式在许多架构师和开发人员中已是根深蒂固，但是，消息处理框架中的要求由支持异步交换模式的单向数据传输来完成效果通常会更好。仔细构建的标准和准则将有助于服务设计人员和开发人员以统一的方式处理这些问题。

　　服务数据表示

　　所有严谨的 WSDL 定义的核心都是一个定义良好的 XML 模式。就特定业务流程或解决方案环境而言，XML 模式(定义输入和输出服务消息的数据结构)的可重用和不可知非常重要，对于表示整个服务逻辑的 WSDL 定义也是如此。构建集中的模式集来表达横切信息集(用在不同解决方案环境中的数据体)，从而在一致且纯粹的数据表示体系结构中避免了大量冗余的模式设计和工作。

　　换言之，正确标准化服务端点需要标准化基础 XML 模式定义。值得注意的是，在构建特定 WSDL 定义时，XML 模式一般看起来有所不同(与使用现有数据模型设计新的数据模型相比)。例如，为 Web 服务专门创建的模式往往会整合引用服务请求和响应消息的命名，如示例 3 所示。另一方面，XML 模式内的元素(用于表示公司文档)将只关心该文档(请参阅示例 4)。

示例 3
“part”元素将引用在该特定 Web 服务内在其角色之后明确命名的类型。

示例 4
这些“part”元素中引用的类型都很普通。它们的用途在其与父“message”元素名关联后更为清晰。

　　引入模式建模标准将增加类似于开发标准化服务接口所需的那些分析步骤。该分析的基础是这样一种概念，即表示有重用可能性的数据的模式不应专为 Web 服务设计，除非这些数据的重用能力直接与基础服务逻辑相关。

　　服务接口标注

　　定义良好的服务会将独立功能封装在简单明了的上下文中。通常标注这样一个服务较简单，因为事先已考虑好它的用途和范围。剩余的工作就是以简洁的方式将其传给潜在的服务请求方。

　　没有经过这样良好定义的服务可能更容易引发问题。如果服务表述的操作在某些逻辑上下文中不相关，则找到一个准确表示该服务功能的名称会非常困难。

　　从开始设计服务时，您将发现根据预先存在的服务模型对其进行分类非常有用。这些模型已建立了建议的上下文和界限，可在其中构建服务模型。常用服务模型包括应用程序服务、以实体为中心的业务服务以及以任务为中心的业务服务。这些模型分别建立了以实用程序为中心、以实体为中心以及以任务为中心的服务上下文。(我在我所著的 Service-Oriented Architecture:Concepts, Technology, and Design 一书中详细介绍了服务模型。)

　　以实用程序为中心的上下文位于应用程序服务中，它涉及封装横切功能的操作，如事件日志、意外处理或通知。在特定解决方案环境不可知的情况下，这些可重用的服务需要根据特定的流程上下文标注。例如，可能将一个实用程序服务命名为 Notify。

　　以实体为中心的上下文构建在代表特定业务实体的业务服务中，如发票或购买订单。通常用实体名称预先确定以实体为中心的业务服务的标注。例如，可以简单地将服务命名为 Invoice 或 Customer。

　　构建为封装流程逻辑的服务要求以任务为中心的上下文。此种情况下，将成组操作连在一起的线程是一项由服务逻辑自动化的特定活动。因此，在服务名称中使用动词很常见。例如，以任务为中心的服务可以称为 GetProfile 或 ProfileRetrieval，如果这些名称准确表达出了该任务的范围。

　　对于服务名称，标注单个服务操作也是一种流程，也应遵循标准和准则，此外还有几个最佳实践。

　　例如，服务本身的命名应该影响个别操作的标注方式。因为，好的服务名称应立意明确、上下文清楚，应简化操作名称，避免使用冗长的措词。例如，为名为 Invoice 的服务接收发票历史数据的操作。不需要将该操作标注为 GetInvoiceHistory，这是因为服务名称已确定了发票上下文。使用 GetHistory 足矣。

　　标注操作的另一个注意事项是由操作和服务本身封装的逻辑的潜在可重用性。如果有重用的可能性，则应避免使用将操作功能与特定活动或任务相连的名称。换言之，选择通用的操作名称来提升将来的重用机率通常都是明智之举。例如，将操作的初始名称 GetCurrentWidgetPrice 缩短为 GetCurrentPrice 或就采用 GetPrice 更为妥当。

　　命名惯例一开始看起来微不足道，但随着服务数量的增加，个别服务的重用、重新利用以及存档集成通道的可能性也会增加。在大型企业中，这意味着越来越多架构师、分析人员和开发人员都将在他们的解决方案中发现外来服务，然后对这些服务进行整合。在可以更为容易识别并抓住互操作和重用机会后，为跨所有服务端点建立统一的粗粒度级别付出的努力将很快得到回报。

　　标准化服务端点和 Oracle SOA 平台

　　Oracle 通过各种技术委员会以及 Web 服务技术的实施(如 Oracle BPEL 流程管理器)，为 Web 服务技术的成形推波助澜，使其在过去的几年中获得了长足的发展。

　　Oracle 还公开支持整个行业内向基于 SOA 计算平台的转换。当 Oracle 在 Oracle JDeveloper 10g 第 3 版中宣布了对“WSDL 优先”开发方法的支持后，其对需要赋予解决方案开发人员标准化服务端点的能力的观点最近得到了证实。除提供更多开发人员已习惯使用的自动生成和向导驱动的特性外，该版本还提供了 WSDL 编辑器。现在，可自行设计而不是派生 Web 服务，从而加强了存档标准化 SOA 所需的控制力。

　　长期任务

　　标准化 SOA 端点是一个持续进行的过程，需要大量的前期投资以及极大的耐心和自律。要成功管理 SOA 转换，最好整个企业都了解在 SOA 内达到标准化的初始成本最终将如何使企业获得重大改善。

　　一切始于服务。确保将标准应用于接口级，通过一致的端点为纯面向服务的环境构建基础，进而促进数据共享和高度合成的解决方案。