Programming WCF Services翻译笔记（一）

一、缘起

从去年的九月开始以来，我开始体验到了笔耕不缀的乐趣与痛苦。说是乐趣，是因为我非常享受码字的这种感觉，仿佛是小说家在倘佯在自己虚构的世界一般，任思想天马行空，无拘无束。虽然说技术要求严谨，但又何尝不需要一点点想象力呢？严谨方可以确保技术的正确与准确，然而如果没有幻想与创新，那么技术的突破就会成为奢谈了。

托尔斯泰曾说到：幸福的家庭总是相似的，然而不幸的家庭却各有各的不幸。然而，对于创作的痛苦而言，文学创作也好，技术创作也罢，这种痛苦却是完全相似的。就像秀才作文，愁眉苦脸比自己老婆的生小孩还痛苦。那是因为老婆生小孩虽然痛，但好歹肚子里有一个小孩在；而自己腹中空空，什么也没有，怎么写得出来。我在著作《软件设计精要与模式》时，深刻体会到了这种刻骨铭心的苦恼。

12月底，在诸方的催促下，总算如期交稿。在等待出版社校对与出版期间，一种创作的欲望似乎告别了冬眠，彻底地醒转过来。正巧当时没有什么项目开发任务，于是我寻思着把自己的《叩开C#之门》系列形成为书。简单地列了一个目录，然后就兴致勃勃地开始了创作。写书总是一件让我惶恐的事。因此，写了两章之后，我赶紧放到网上去，希望能看看大多数人的反应。没想到获得的好评极大地刺激了我的虚荣心与自信心，而此时清华大学出版社也开始联系我，想看看本书似乎有出版的价值。正想要开始我的C#创作之旅时，一天，机械出版社的陈冀康先生忽然找到我，问我是否愿意翻译Juval Löwy的Programming WCF Services一书。这一提议让我怦然心动，毕竟WCF正是我研究的方向，如果本书经我翻译出版，或许能够成为国内WCF著作的先行者吧。

因为重装了机器，丢失了所有的邮件地址，我无法联系到清华大学出版社的陈小姐。反正，市场上有关C#的书多如牛毛，也不缺我这一本，因此优先级自动降到最低。于是，Programming WCF Services一书的翻译就开始提上日程了。在交付翻译的样章后，陈先生的效率很高，没有几天就与我签订了翻译合同。没想到这就开始了我的磨难。

因为出版社要稿要得很急，如何在保证翻译进度的同时，保证翻译的质量，成为了我的苦恼。厚达600页的著作也不是那么容易啃下的。幸运的是，邀请到了徐宁先生与我共同翻译本书，总算把重担略为分出了一些。然而，陆续遇到的翻译过程之中的障碍，逐渐使得我视翻译如虎，却又不得不硬着头皮上景阳岗。
翻译的过程真可以比得上是打虎的过程。不，应该说更难，因为我的目的不是打虎，而是要驯虎。而要驯服一头成年的老虎，给观众带来精彩的演出，更是难上加难。不过毛主席不是教导我们要将敌人看作是纸老虎吗？幸好这本书还真的是用纸印刷的，纸老虎而已，我也应付得下。

因为我的一个旧习，我产生了将这次翻译过程记录下来的想法。我可以将翻译过程中收获的经验、体会以及困难一一记下。此外，也可以将本书的精彩之处撷取出来，与读者共享。最重要的是希望能获得更多的批评与建议，可以使得我驯虎的过程可以平坦一点。

二、翻译障碍

翻译的标准无非是“信达雅”三字。说易行难，毕竟这三个字尽数了翻译过程的三个境界。对于一般的文学翻译而言，要达到“信”的标准，相信不难。然而对于技术书籍的翻译而言，则未必尽然，最头疼的问题就是技术术语的翻译。特别是本书，由于WCF是基于.NET 3.0平台的SDK，可以说是一门全新的技术。我很难找到有关WCF技术的中文文档，也就是说，这就限制了我无法站在前人的肩膀上望远，也失去了“前人栽树，后人乘凉”的机会。

如果是写技术博客，那么完全可以直接使用这些术语，有时候“不译”反而比“译”更容易让读者明白。然而，翻译书却不能这样，唯一的原因就是出版社不允许。我很佩服前人翻译技术术语的创造力，例如多态（polymorphism），架构（Architecture）、原型（prototype）等等，虽然读来平淡无奇，但却准确地体现了英文的原意。

面对WCF的新奇术语，我就开始苦恼了，我在思考如何来翻译这些桀屈敖牙的名词。如果翻译不好，没准就会成为译作的硬伤。仔细思考，解决的办法大约有这么几个：

1． 尽量与已有的翻译保持一致

例如WCF中的contract（契约）、endpoint（端点）、Hosting（宿主）等等，基本上它们的翻译已经得到了大多数人的认可。如果我硬要将它们分别翻译为合同、结束点、运营者，那就是属于没事找抽了，何况这些翻译已经足够好了。

有的词语比较少见，但我们可以借助网络去查找已有的翻译，然后比较一下，看是否可以采纳。例如Network Hops，当我看到这个词语的时候，就非常困惑。毕竟我对于网络技术比较陌生。在Google下查找之后，我得到一个答案，就是hops常常是hop count的缩写，一般翻译为“跳数”。因此，将Network Hops翻译为网络跳数，应该不会有太大的争议。

2． 通过对上下文的理解创造新的词语

这些词语往往是一些合成词或短语。以英文方式合成这些词语一点都不奇怪，翻译成中文时，就有些让人读不懂了。例如Ordered Delivery，应该翻译为什么呢？由于它的本意是代表消息的交付必须按照一定的顺序，最后根据这一层意思，我将其翻译为有序交付，或者可以说是差强人意。再例如Federated WS binding，根据上下文意思，知道它是由WSFederationHttpBinding类实现，支持WS-Federation安全通信协议，所以思考再三，决定将其翻译为WS联合绑定。类似这样的翻译，到处都是，但由于这样的术语可能是第一次使用，因此往往我会在翻译的词语中，增加英文原文的说明。

3． 不翻译

实在是不能翻译的，或许保留原文是最佳的办法。然而在翻译书中，这种情况只限于大家已经耳熟能详的名词，特别是缩写，例如WCF、HTTP等。

为了保证技术术语的准确性，我会维护一个术语表，预备放到网站上，希望能获得更多人的建议。

三、以开发的方式进行翻译

    虽然是翻译，但我们仍然可以将项目开发应用到整个翻译过程中。总结下来，大约分为这样几个步骤。

1、 快速原型
在软件开发过程中，经过需求分析阶段后，为尽快地获得客户的认可，最佳方式就是采用快速原型的办法，建立初步的软件模型，向客户提交一个Demo版本。对于翻译而言，就是尽快地将英文原文翻译为中文，里程碑目标就是“信”。在翻译过程中，可以基于自己对这门技术与英文的理解，获得一个粗糙但忠实于原文的版本。这个版本允许语言不通畅、允许不去分析代码，允许出现小错误，甚至可以对原文“不求甚解”。目前，对于Programming WCF Service一书，我已经完成了“快速原型”阶段。

2、 定期迭代
比之于瀑布模型而言，RUP的方式更容易控制需求变更。如果能够采用敏捷编程的定期迭代，则更能够快速地满足客户的需要。本阶段的里程碑目标是“达”。要求能够在“信”的基础上，做到逻辑清楚、语言通顺，同时要保证技术表达的合理与正确。要完成这一目标，必须深入理解作者的创作意图与实现目标。要实现这一阶段的里程碑目标，可以采用如下的方法：
（1）重构
    在软件设计时，重构的目的就是改善既有代码的设计。翻译过程中，在“信”的基础上进行重构，就是要改进第一阶段译文的词汇、语序的用法。由于第一阶段仅仅是忠实原文意思的翻译，因此可能会出现西化方式的语序。尤其是长句的翻译，一大堆定语从句，如果如实翻译过来，会显得语句冗长不易理解。词汇也是如此，对于同一个英文单词，有许多相似相近的中文词语与之相配。特别是很多时候，需要对照上下文，才能获得准确表达原文意思的词语。重构，就意味着对词语的推敲，争取找到最适合的词语，表达原文的涵义。
（2）持续改进
    持续改进主要是要修订第一阶段译文的原则性错误，特别是术语技术范畴的错误。那么前提条件就是必须对翻译的内容，有足够深度的理解。如果有代码，最好能通读一遍，完全理解。如果有示例，则最好能运行一遍，体会作者的意图。如果作者出现了错误，最好能够纠正这些错误。不能寄希望于持续改进的目标是一蹴而就，翻译的时候，可能需要反复地阅读原文与译文，争取能够使得译文与原文完全吻合。
（3）变更控制
    变更控制比较特殊，主要是基于作者对原书的修改，例如原著作的勘误表。一旦发生了原著作的变更，好的做法就是要将这些变更体现在译文中。译者要翻译好书，最佳的方式是与作者进行无障碍的沟通。只有在充分理解作者意图的基础上，方能够创作出好的译文，通达的译文。而作者也可以通过这样的交流方式，及时将变更消息通知译者，好在译文中作出修订。

3、 版本交付
一般而言，在将软件交付之前，都需要执行测试阶段。对于翻译而言，特别是多人合译，那么最重要的测试过程就是：集成测试与UAT（用户验收测试）。集成测试需要统一风格、统一技术术语，统一描述方式。这是必要的，否则会给读者带来支离破碎的感觉。UAT的执行过程比较困难，因为翻译的客户就是读者，考虑市场的需要，译者不可能事先将译文交付给读者。少去了这样一个环节，确实会带来许多质量问题。但如果能有选择性的公布个别章节或个别内容，仍然是有好处的。
版本交付阶段的里程碑目标是“雅”，因此除了bug的修复之外，持续地改进仍然是有必要的。“雅”的境界很难达到，但趋近于“雅”，越能够创作出经典的译作。就像软件开发需要优雅的设计一样，译者的全局掌控能力与细节雕琢能力，决定了这一目标是否能够达成。

四、本书的内容

本书作者的声名不用多说。他是IDesign的负责人，软件架构师，是《COM与.NET组件服务》、《.NET组件开发》的作者，还是Visual Studio杂志以及.NET杂志的特约撰稿人。他在.NET组件开发以及分布式开发领域，享有盛名。Programming WCF Services是他的又一部力作。

本书一共分为十章，分别为：WCF基础、服务契约、数据契约、实例管理、操作、错误、事务、并发管理、队列服务、安全。内容几乎囊括了WCF技术的方方面面。通过阅读本书，可以使得你能够全面深入地了解WCF技术，并迅速成长为一名WCF专家。毫无疑义，通过对本书的翻译，在整个过程中我也在不断地成长，对WCF的理解也能愈发地深刻。这也正是我愿意本书最重要的理由。

以下摘自我对本书序的翻译，简单介绍了各章的内容。

第1章   WCF基础

本章从一开始阐释了WCF的技术原理，并描述了WCF的基本概念和构建模块，例如地址（addresses）、契约（contracts）、绑定（bindings）、端点（endpoints）、宿主（hosting）和客户端（clients）。本章末尾还探讨了WCF架构，它将是帮助我们理解后续章节内容的关键。本章假定读者已经了解面向服务的思想与优势。如果你不具备这方面的知识，可以先阅读附录A的内容。即使你已经非常熟悉WCF的基本概念，我仍然建议你对本章作一次快速浏览，它不仅能够巩固你的已有知识，而且本章介绍的一些帮助类与技术术语将有助于你阅读全书。

第2章    服务契约

本章专注介绍服务契约的设计，以及如何使用服务契约。首先，你会了解到服务契约的相关技术，包括服务契约的重载与继承以及其它高级技术。接下来，本章将深入探讨契约的设计要素，以利于系统的重用、可维护性与可扩展性。最后，本章演示了如何通过暴露的契约元数据完成运行时的交互编程。

第3章    数据契约

如果客户端与服务的数据类型无法共享，如果没有采用相同的开发技术，那么应该如何处理它们之间数据的交换？通过本章，你可以看到一些有趣的现实问题，例如数据版本、元素集合的传递，究竟是如何处理的。

第4章    实例管理

究竟哪些服务实例处理何种客户端的请求，本章给与了一一的回答。WCF支持多种服务实例管理、激活与生命周期的管理，这些技术与系统规模、性能息息相关。本章介绍了每种实例管理模式之间的关系，指导读者何时以及如何有效地利用它们。本章介绍了与实例管理相关的论题，例如分流（throttling）。

第5章    操作

通过处理操作类型，使得客户端能够调用服务，并遵循相关的设计指导，例如如何改善和扩展基本功能，以支持回调的安装与销毁，管理回调端口与通道，提供类型安全的双向代理（duplex proxies）。

第6章    错误

本章全面介绍了服务如何报告错误，然后如何将异常回送给客户端。既然异常与异常处理的创建是与特定技术紧密结合的，因而无法跨越服务边界。本章深入探讨了有关错误处理的最佳实践，使得客户端的错误处理与服务实现解耦。同时，本章还演示了如何扩展和改善WCF基本的错误处理机制。

第7章    事务

本章一开始从整体上介绍了事务的动机，接着讨论了事务服务的方方面面，包括：事务管理架构、事务传播配置（transaction propagation configuration）、WCF提供的声明性事务支持、以及客户端创建事务的方法。本章末尾则讨论了相关的设计指导，例如事务服务状态管理与实例化模型。

第8章    并发管理

WCF针对并发与同步的管理，提供了强大然而简单的声明式实现。本章详细地介绍这一实现方式。然后，本章还展现了更多的高级技术，诸如回调、可重入性（reentrancy）、线程关联度（thread affinity）、同步上下文以及避免死锁的最佳实践与指导。

第9章    队列服务

本章描述了客户端如何实现将面向服务的调用放入队列，如此就可以采用异步方式，完成脱机工作。从一开始，本章就介绍了队列服务的创建与配置，然后集中讲解诸如事务、实例管理、操作失败以及它们对服务业务模型以及实现所造成的影响。

第10章    安全
通过将多方面的任务分解为基本要素，如消息传递、认证与授权，就可以揭开面向服务安全的神秘面纱。本章继续探讨了如何为intranet和internet应用程序等关键场景提供安全保障。最后，我介绍了针对声明式WCF安全所设计的框架，它可以自动配置安全，简化对安全的管理。

附录A    面向服务概述

附录A为那些渴望了解面向服务基本知识的读者提供。全篇介绍了我对于面向服务的具体应用。附录定义了面向服务应用程序（而非通常所谓的架构）和服务本身，并从方法学的角度，考察了面向服务体现出来的优势。附录还介绍了面向服务的原则，以及从大多数应用程序都需要的实用点出发，重点突出了面向服务的抽象原则。

附录B    服务发布与预订

附录B展示了我设计的框架，它能够实现发布-订阅（Publish-subcribe）事件管理系统。该框架能帮助你简化发布-订阅服务，只需要编写一两行代码即可完成。发布-订阅模式是第5章讲述的内容，之所以将其放到附录中，是因为它使用了其它章节的内容，例如事务与队列调用。

附录C    WCF编码规范

附录C基本上列举了书内书外所有与WCF相关的最佳实践。本编码规范只在于解释“如何做”以及“怎么做”，而不阐述其原因。规范背后隐藏的基本原理可以参见本书各大章节。本编码规范同样使用了本书讨论过的帮助类。

是否渴望阅读本书的所有内容呢？目前，我已经完成了快速原型阶段，进入了定期迭代阶段，然而离版本交付还有接近三个月时间。如果你已经不耐烦了漫长的等待，那么请跟随着我的翻译笔记。这个系列会逐步展示本书的冰山一角，庶几可以满足你的部分愿望。