面向服务开发的七项原则

面向服务开发的七项原则
未来的软件结构要求有一套新的开发方法。

你们公司做好准备了吗？
当今关于Web服务（web services）的描述主要是关于集成的。

走出不景气阶段的企
业都把降低集成成本作为一个明显的目标。

运用公开的、基于标准的、松散藕合的Web
服务技术就给企业提供了一个不是很昂贵的集成方法。

然而，Web服务不仅仅是使集
成简单化了，它们的用处更多。

实际上，它们将注定要从根本上改变人们创建和使用
软件的方式。

为了摆脱老式的思考方式，软件专家必须要了解Web服务的技术，并且要了解Web服务
可以给我们带来怎样的前景。

下面的面向服务开发的七项原则——它们是随着老式思
考方式转变到新的思考方式而产生的——为你形成这种新层次的观念提供了指南。

1. 动态的服务替代了静态的组件
构建一个Web服务不仅仅是像传统的组件开发期望的那样创建具有特殊功能的软件。

一个Web服务的Web服务描述语言（WSDL）文件动态地描述了Web服务的功能。

所以，开发人员只需要指出在哪里找到WSDL文件，这样调用Web服务的软件在运行时就可以找到对服务功能的描述。

该原则要求在运用Web服务的系统中显示逻辑层同商业逻辑
层和持久（persistence）逻辑层分离开。

当开发人员构建一个Web服务时，他们可能
不知道那个服务是如何被调用的、或者Web服务使用者的用户界面将是怎样的。

一个Web服务架构师不能将商业逻辑和显示逻辑结合起来。

2. 服务呈现（Exposure）和响应（Reflection）替代了传统的系统集成
当今的系统架构师根据系统级的需求来集成项目。

架构师计划各种组件应该如何集成。

作为这种top-down方法的替代，面向服务的开发采用了一种bottom-up的方法。

在
任何系统结构形成前，系统中的每个组件都呈现成一个Web服务。

然后，每个服务（
查询一个服务自己的功能）给外部系统提供它们访问服务所需要的信息。

在构建一个系统时，Web服务架构师首先考虑系统的需求，并进行服务装配。

在服务
装配过程中，架构师访问服务的动态描述，它们只代表了实际的API的一部分。

然后
，架构师确定系统的结构，即使在运行前，单独的组件及其接口并没有被完全地描述。

3. 为广泛的适用性编写代码替代了为可重用性编写代码
为可重用性编写代码是面向对象编程的一个重要的特点。

实际上，对开发人员来说，
编写可重用的代码可能比为单独用途的应用程序编写代码更具挑战性。

因此，灵活的
软件方法（如Extreme Programming（XP））就避开了可重用性。

在XP中，如果外来
的功能进入到代码中，那么开发人员就重新编写、或重构（refactor）代码，直到它
尽可能地简单。

虽然重构可以形成一些重用的方法，因为最终代码满足很多情况，但这种方法同传统
的为可重用性编写的代码不同，因为它的目的是创建灵活的和广泛适用的代码。

重用
性和广泛适用性的代码的区别是很小的，但它们却是面向服务的开发过程的本质。

最
好的方法就是把面向服务开发的结构性原则同灵活的开发原则结合起来。

4. 特别的升级替代了单独的组件（Disruptive）升级
模块性是面向对象编程的另一个基本的原则。

如果系统是模块化的，那么构成系统的
单独的组件就可以被升级或替代，而不影响系统的其它部分。

不幸的是，在如今的企
业组件结构中，模块性在很大程度上是个谜。

当然，问题是在一个复杂的系统中替换或升级组件并不像人们期望地那样简单或便宜。

Web服务呈现了动态服务描述，而不是简单地呈现APIs。

如果根本的API发生改变，服务描述自动调整，系统的其它组件在运行时可以根据变化做出调整。

5. 可扩展性采用Bottom-Up式设计过程，而不是Top-Down式设计过程
可扩展性比随处添加一个附加的服务器要复杂多了。

首先，架构师要预测使用模式并
为负载平衡和故障转移（failover）做计划。

然后他们必须设计系统以避免出现瓶颈
问题。

这种用于可扩展性的方法就是top-down式的，因为它首先从企业级角度考虑了潜在的系统交易模式。

然而，在一个完全实现了的具有Web服务的环境中，可扩展性应该是以bottom-up模式来处理的。

架构师可以设置UDDI注册来提供备份Web服务清单，主要是为了可扩展性和故障转移。

如果一个系统遇到未预料到的交易，它就可以自动在注册文件中找到备
份服务，得到它们的服务描述，然后很快绑定到附加的服务上。

6. 平台依赖性为平台不相关性让步
企业系统开发的基于组件的方法就是在平台上构建组件，并通过它们的接口来呈现它
们的功能。

本质上，组件就像踢球的足球运动员，平台就像球场。

因此，如果俩个球
员在不同的球场，那么他们之间的交流就会很困难。

面向服务的方法采用的观点是，整个软件环境是由动态描述的服务组成的，在需要的
时候，它们可以很快地被找到并调用。

要注意，平台在任何时候都不会很快被抛弃，
这是很重要的。

Java 2 Platform、Enterprise Edition（J2EE）和.NET将转移到用
户所处的外围，这些平台提供了必要的底层框架来编写和运行Web服务，并提供了用户需要访问那些服务的接口支持。

面向服务的争论的中心议题只会是Web服务，它们是以XML为基础的。

7. 软件的松藕合（Federation）替代了紧藕合（Dictatorship）
Web服务的松散藕合解决了带有严格APIs的基于组件的结构中紧密藕合的许多问题。

但是，面向服务开发的松散藕合原则对企业软件的传统的、紧密藕合的世界还有更深
远的影响。

运用松散藕合，架构师就可以通过组合Web服务的动态描述的集合来创建企业软件。

软件供应商将提供服务的松散藕合。

随着时间的推移，由于开发人员进行
了特别的升级，构成这种企业包的各种Web服务将一天一天地发生变化，通过根据需要装配另外的Web服务，在运行时，系统就会不断发生变化。

ZapThink Insight
今后的目标是什么
虽然上述有些原则才刚刚被人们广泛采用，但也许在五年后，会出现更多的其它的原则。

预测未来是很可能犯错误的，但我们有理由期待面向服务的开发在软件供应商及企业开发人员中不断发展的趋势。

ZapThink公司打算为我们在这里详细讲述的面向服务的开发的原则提供必要的前提使我们可以更好地预测软件结构和开发的未来。