面向服务的架构(SOA)是一种组织信息处理的方法。各系统为协同工作在各方面达成了协议，SOA通过减少这些协议的数量，能够降低信息系统互操作性的成本。如果SOA能得到大范围的应用，系统将呈现与现在截然不同的前景，这就好比当今货运行业有别于集装箱出现前的货运业时代一般。然而，目前的应用方式却导致了额外的开支却并未体现出这些互操作性的优势。将适用于数据库时代的范式应用于SOA中，会招致反效果，往往是愚蠢的，有时甚至是十分危险的设计。这些模式必须由新的思想和行为方式所替代，以确保SOA朝着接口更简单、IT方案更优化以及项目更可控的方向发展。这一点可以通过遵守以下十大戒条来实现。
引言：SOA的潜在影响
面向服务的架构(SOA)是一种组织信息处理的方法。这种方法以服务的形式描述所有交互活动，服务请求者请求代理完成某些处理，代理确保处理得以完成并将处理结果反馈给服务请求者。这种思维方式可以应用于业务级别，以描述各组织机构之间的交互;应用于功能级别，以描述组成业务流程的活动的交互方式;应用到信息系统级别，以描述系统及系统各部分的交互方式。每个级别的准则都是相同的：代理完成所需工作的方式与请求者无关，乃至与是否完全自动、完全人工亦或两者兼具都无关系。哪怕代理将部分或者甚至全部工作外包给其他代理完成也与请求者无关。所有请求者所需关注的是与代理就以下方面达成一致：请求及响应应该如何制定，以及服务的效果如何。
SOA被大肆宣扬为一种具有巨大潜力的范式，能够降低系统发展、测试及维护的成本。特别需要指出的是，SOA承诺可以通过大幅度减少达成协议的因素的数量，从而降低信息系统各模块协同工作的成本。采用SOA，诸如像计算平台和数据格式之间的差别造成的系统间通信屏障会较采用早期的范式要少得多。这使得更大范围上的协作变得可能，因为它减少了障碍，使系统设计师们不必被强行要求相互达成一致，就此而言，也使得系统配置员之间不必被强行要求达成一致。如果这种承诺可以实现，其结果将会是革命性的。就像汽车改变了城市区域形态，集装箱运输革新了货运行业，以及交易费用的降低发展了现代自由市场经济，SOA将开启新的合作模式。当SOA主导我们应用IT的方式，系统前景将与今日迥然不同，好比围绕汽车来设计规划的城市和围绕火车来设计规划的城市截然不同一般。对我们之中那些思维受限于目前技术的人来说，SOA可以产生多大的不同是难以想象的。然而SOA所提供的灵活性优势就好比汽车胜过火车一样：即便火车可以被制造跑得和汽车一样快，火车还是绝不可能像汽车那样提供门到门的运输服务。把火车站安置在每个车道的尽头，亦或甚至把铁轨铺设在每条道路上都是根本不现实的。
为何此影响尚未实现
为获取新范式带来的好处，我们必须好好利用其所能提供的各种新的可能性。遗憾的是，目前围绕SOA的言过其实的宣传对这些可能性的提及是言之甚少。大部分讨论似乎都关注于如何利用SOA帮助单独信息系统更快速地开发。然而，这并非SOA所能创造的最大价值之处。事实上，SOA是否真正能够改进以往的方法，即各个功能点通过某一共同的数据池(通常是以数据库的方式实现)来实现交互，还存在争议。使用SOA来构建单独、孤立的信息系统就像使用集装箱在加工厂附近搬运货物一样：当然，它限定了内部物流的顺序和组织，但是集装箱更多的是挡了道路而非提供帮助。SOA使信息系统间达到更好的互操作性，就像集装箱促使了运输商之间的互操作性一样。那是一种重要优势，因为从需求确定到信息系统可操作之间的时间周期通常很大程度上是由互操作性决定的。要使某一信息系统能够与其操作环境中的其他系统一起工作，那将会花费比重新构建这样一个系统更多的时间和精力。
关注于SOA在信息系统内部而非各系统之间的使用是情况更加恶化的征兆：因为看起来SOA是一种全新的处理我们一直以来所做的事情的方式，我们无法直接获取它所带来的收益。SOA概念和技术正为目前的系统开发范式所利用。这些范式还是数据库时代的开发产物，同时也带有数据库技术的一些限制。在这些限制下应用SOA将会导致额外的开支，而不能获得额外的收益。然而，这些“数据库化”的范式是如此普遍和有害以至于我们常常忽略了它们对我们的思维影响有多大。它们是如此根深蒂固，以至于我们会不自觉将其视作常理。遗憾的是，这样通常招致相反效果，常常是愚蠢的，有时甚至是相当危险的。它们导致了一种不好的方案，这种方案集合了数据库时代的缺点以及SOA不好的一面，而又不能体现SOA必定提供的优点。
需要改变什么
SOA范式有其自身的常识守则，较之数据库范式的守则截然不同。基本戒律有十项。前五项关于如何简化事物，使其比数据库化的范式要求更加简化——从坚持要点意义上更加简化。如果我们以此种方式简化事物，同一问题的不同解决方案相互间协作的可能性将大大提升。接下来的四项关于使IT解决方案优于同等数据库解决方案，这是通过阻止那些戴着有色眼镜、惯于数据库思维方式的人开发出无效解决方案来实现的。最后一项关于如何使IT更可控，尤其是组织系统开发以降低项目复杂度和风险。SOA使这些成为了可能——同样也是必须的——因为它让更多的功能交付成为基础架构。
简化之理论
在高空杂技表演中，高效的合作的基础是每个空中飞人演员完全默契地配合，对方会及时地在每个时点出现。一些空中飞人演员非常自信，他们经常蒙着眼进行表演。他们能够接到彼此正因为他们确定在某个特定时刻对方只可能出现在一个可能位置。
成功应用SOA以达到最大化的协作性与高空杂技表演非常相似。互操作性要求关于如何进行交流的解决方案从数以百万计减少到只有一个，交互双方都可以依赖该方案。这并不意味着其他方案有问题：这好比我们既可以靠左行驶也可以靠右行驶，但重要的是我们必须都靠同一边行驶。
当只有一方执行服务，一方接受服务时，只要双方协议好，具体使用哪种方案其实并没有太大区别。双方中任一方的特异性可以决定最终方案，无需做更多的沟通努力。毕竟，无论使用哪种方案，这些特异性总要被处理。但是如果是多方请求服务或者多方执行服务，那将呈现不一样的情景。此时使通信方案精简非常重要，如此，各方必须处理各自的特异性，无需面对另一方。
将信息通信与外科移植手术对比很能说明问题。成功的移植手术，要将一个人身上的器官移植到另一个人身上，要求该移植器官必须在多方面与接收者匹配，而其中大部分匹配因素与该器官的生物功能无关。换句话说，被移植的器官必须和接受者本身有相同的特征。因此，我们的器官不能像拼搭乐高积木一样随便被移植。目前的信息通信恰恰如此。当一个信息系统为另一个系统提供服务时，它们必须在很多方面达成一致。它们必须使用相同的词汇(元数据)、相同的由一方调用而另一方执行的功能集、对于每个功能请求应答数据内容的相同期望、相同的编码系统、相同的技术通讯协议、相同的用于信息传递的寻址模式、兼容的可预期的响应速率、兼容的确保消息不被丢失的技术、兼容的认证机制以确保双方安全通信而不是与冒名者通信、兼容的加密技术以及密钥管理以确保消息不被窃听或者篡改等等。为了促进互操作性，必须确保参与各方从彼此独立制定各自标准变为形成兼容的标准规范。只有当一些非常严谨的规则得到遵守时这才有实现的可能，接口才能减至精要。如此一来特异性将无容身之地。
严谨的规则都关注于如何使得服务接口更为简单。我们规定的越少，争议的余地就越小。
1.不了解你不需要了解的
你不需要去了解的东西不会伤害到你
SOA范式的本质在于使得合作各方或系统之间达成最少限度的协议却可以实现最大程度的合作。这是一种巨大的优势，因为任何你不需要了解的东西既不需要被测试也不需要被维护。你不需要去了解的东西不会伤害到你。假设40%的系统开发成本用于测试上，而高达80%的信息系统生命周期的成本被花费到了系统维护阶段，任何SOA范式让你无需了解的东西都代表了你能节省的金钱。
元数据
你最不需要了解的就是结构、含义以及容许值——这些元数据——不会被系统中筛选、排序或执行计算的逻辑使用的数据。你并不需要去了解这些，因为SOA技术使得数据和元数据同时出现。你的系统可以实时解读元数据，所以如果你要做的仅仅是获取、呈现或传送相应的数据，你完全不需要为系统构建元数据知识。在有相当精密的表示(presentation)功能的帮助下，它甚至可以为用户实现各种各样特定的筛选及计算，且只使用与已有数据同时提供的元数据，而不是内部构建元数据。
通过解读数据相应的元数据，而不是把元数据构建到系统中，你的系统不需要随元数据的改变而改变。需要改变的仅仅是源系统。想想如果遵守该守则，你能在开发、测试和维护上节省多少金钱!记住，在两个系统上做更改，平均来说，其复杂度是在单个系统做更改的四倍，因为其中包含了所有各方的协作。
对于很多面对客户的系统来说，表示以及特定筛选功能基本是其主要的功能。这些系统只针对最基本的客户数据要求内部构建元数据。这并不包括当前或过去的订单、客户通讯录、照片、信函以及任何可用于展示的其他数据，所有这些数据都可以用一种不需要这些数据本质相关知识的方式进行表示，内建于系统中。
技术
许多你不需要了解的事情是与技术相关的。有了SOA，你不需要了解你正在接口的系统是否采用“软件即服务”(Software-as-aservice)，不需要了解实施该系统的计算机安放在何处，是哪种类型的计算机或者运行于何种操作系统，防火墙是如何配置，使用的是哪种数据库管理系统，亦或可以使用哪种交易管理系统。其他你不需要了解的事情是与你所通信的系统内部相关的。尤其是，你不需要去了解任何用于内部数据存储的元数据，因为任何其他系统需要同XSD一致的转换都是其自身的问题，而不是你的。
即便如此，使用SOA进行通信的各方必须达成一致的技术相关的标准还有很多选择。特别是有很多与Web服务相关的那些标准，SOA从业者将其统称为WS-*标准(*指可以使用很多可能的标签替换)。在一定程度上，这些标准提出得很恰当，因为SOA社区并没有满足于不去了解它不需要了解的东西;本文这个白皮书给出了一些指导以期降低由这些标准引起的问题的影响。遵守这些指导，SOA需要的先期协议将比其他方法要少得多。
设计稳定的接口
如果想获取SOA提供的种种好处，不去了解你不需要了解的东西会成为你的习惯。请铭记这点!比如说，当设计一个订货服务时，请记住服务请求者只需要知道，当他需要货物的时候该货物是否会有货，而不需要去了解当前的库存量。如果你的程序调用某一安全服务以判断请求活动是否被授权，不要在系统内构建任何超过其所需服务工作的知识。例如，如果安全服务需要使用输入到程序的安全证书，唯一必须做的就是传递该证书!对你来说，它们只是被封装在输入消息中的单个数据项。该证书是否是格式完整的XML也不要去验证。如果，由于某些只有那些负责安全的小鬼知道的原因，他们选择了违背标准的SOA操作或对证书进行了加密，那么这是他们的问题，不是你的。如果他们改变了任何与证书相关的东西，你的程序不应该为此做任何改变或调整。任何你不需要了解的东西不会伤害到你。当然了，除非你硬要去了解它，在这种情况下如果你们不想在SOA上浪费时间的话，其他人可能最好离远点儿。
不去了解那些你不需要了解的东西可能比你想象的要难。如果你开发专门用于与你通信的信息系统的信息检索服务，你的思路已经不对了，因为你已经把其他系统的知识归并到系统中了。需求中的任何更改将会迫使双方系统都作出更改。通常来讲，比较好的方式是采用数量有限的检索服务暴露系统数据，当检索服务结合在一起使用时，它们涵盖了所有相关服务的信息检索需求。例如，某个产品数据库可能通过好几个服务分别暴露出去：一个简单的仅包含编码、描述、部门以及产品定价的服务、一个暴露出所有该产品财务方面信息的服务，以及一个暴露出所有该产品物流方面信息的服务。许多系统仅需简单服务即可得到满足，大部分只需要部分数据而非全部，或财务或物流的服务，而有一些两者都需要，但此外没有任何一个需要特别接口的系统。这种工作方式被称为麦当劳方式：客户从标准产品中搭配出自己需要的产品。支持这种方式并不困难，因为不管怎样你都需要这些服务去支持面向客户的程序。你甚至可以用这种方式来支持非常特别的信息需求，因为那些不需要的数据可以在消费前就过滤掉。如果不想在巨无霸汉堡中放小黄瓜，扔掉它就可以了!这种方式的基本思路是提供过多的信息要比提供过少的信息遇到的问题少，因为接收方系统可以很容易通过程序过滤掉不需要的信息，但是如果缺少信息那就麻烦了。
不去了解你不需要了解的东西也会使得为支持业务流程所需的信息交互大大简化。在SOA的范式中，当你请求另一个代理为你做一些事，那就是你所需要做的全部。你不需要为代理提供可能有助于完成任务的或者是其必需的额外信息。在点菜时，确保有用于这道菜的原料是厨师的职责。你说出想要的东西，然后就可以静候佳音了。反过来，代理会使用信息检索服务来向你咨询所有信息，但是检索什么、何时检索以及从何检索，这些问题都应该由他来决定，你无须去了解，更不用将该知识归并至你的系统中。这样，在他那一端的更改几乎不需要你这边作出更改。比如说，如果他决定停止维护对你数据的拷贝，你什么更改都不需要做。
当然，不去了解你不需要了解的事情确实会导致效率低下。原本只需要一次交换即可实现的操作现在将需要多个步骤。麦当劳方式常常会导致原本一个服务即可满足却提供了多个服务的情况，另一边却还在检索信息，而这些信息又常常是冗余而非十分必要。总会出现一些情形，可以通过好的商业意识来优化这些通信模式。也会有很多场合你会想要优化用户接口，那也只是因为当前的表示设备并不擅长提供给用户吸引人的界面。但是在你优化之前，请考虑你会失去什么样的灵活性。另外绝不要想去优化那些尚未稳定的功能需求。
2.不要了解你还不能了解的事情
为时过早的规范冻结
数据库范式中，一个真正的难题在于：它要求在你还未足够了解并有能力去确定数据的具体结构前，就去做这件事。因为它们忽视了一个生活中简单的事实：只有当用户看到他们不想看到的东西时，他们才知道其真正想要的是什么。
其工作原理是这样：一旦完成了数据结构的设计，任何后续修改都会引起杂乱的数据库转换，除此之外每个访问该数据库的系统也会改变。所有这些改变必须都协调好，当所有对数据库的操作都限制在单个系统时候，这种协调是很困难的，但如果有多个系统都在操作，那就更难了，尤其是：如果其中有些系统被不受你控制的参与方管理的时候。事实上，在系统开发阶段做这些更改就已经很成问题了。其后果是，数据库设计早在系统开发阶段就被冻结，然后数据分析师们再去竭力修正这些设计。
现在的问题是数据分析师们面临着不可能完成的工作。他们必须在用户理解这个设计(且不说赞赏这个设计实际应用如何)前就确定该设计。只有在过了很久之后——系统已经构建好之后——用户才能对该系统有所体会并对其是否满足自己的需求作出评估。如果此时发现数据结构上有任何大问题，要想修复就太晚了。
SOA原型法
你可能会问：“SOA是怎么个不同寻常呢?”说到底，难道SOA不像数据库范式那样一样需要结构化数据吗?这个问题的简单答案：不管请求数据时，被人工代理处理还是被自动化系统处理，SOA都是管用的，并且就算数据没有被最优结构化，人们还是可以解读它。比如说，用户可以判断信件是否正在被发送至另一个国家，无论信件的地址是用行一、行二、行三和行四来表示的，而信息系统需要至少“国家”来作为数据结构可识别的一部分。
仔细回答这个问题就包括了对SOA原型法的讨论，这种讨论包括以下几方面：
识别将被构建到系统中的元数据。把它放在主命名空间中，用传统方式根据其结构把数据存储到数据库管理系统(DBMS)。例如，用户信息，这个元数据可能由用户ID和用户名构成。因为这个元数据被构建到系统中，所以为了使用这些字段而把逻辑也构建到系统中是完全有可能的，比如通过用户ID检索记录并基于用户名排序和筛选记录。
对每一条数据库记录，把不包含在主命名空间的所有数据放到一个单独的XML字符串中，该字符串作为一个单独的字段添加到数据库记录中。对每个XML字符串，构建一个二级命名空间，开发XSD，同时添加一个单独数据项到主命名空间。对用户记录的初步实现来说，这个字符串可能包括地址行一、行二、行三和行四的元数据。用户记录本身的XSD将会包括三个字段的元数据：用户ID、用户名和以XML字符串包括的附加的用户相关数据。附加用户数据的XSD包括每条地址行的元数据。
使用基于XSD的逻辑来为数据库记录的各相关层次获取及展示所有数据，这可以通过给每个XML字符串(包含对主记录的字符串)增加一个标准验证服务来实现。如有可能，利用某种工具来产生使用XSD的接口而不要自己去编程。该工具必须使用二级XML字符串所包含的元数据来将其解包，并且必须同时使用主、次两级XSD的逻辑来获取新记录。其结果就是一个可运行的原型，用户可用以评估预期使用的系统。
要尽量适应和修改基于XSD的逻辑以及验证服务直到用户对系统满意为止。就拿用户记录来说，一个新的针对字符串的XSD可包括以下元数据：街道地址、邮编、县市、以及国家。使用旧XSD存储的数据仍会正确显示，所以无需立即将其转换。而使用新XSD将会获取新的记录。
一旦用户和你确信元数据已经稳定了，那么请考虑把数据迁移到传统的数据结构和主命名空间。
当然，SOA原型法并不总是必要的。当需求受限于如此多的不确定性时，请使用原型法，这样先做原型然后再将其稳定比较经济。但是请记住这个肯定要比数据库化原型法要简单的多。在数据库化的时代，原型法只是可有可无，但是在SOA的时代，它便是家常便饭。不要将设计细节固定，除非你确定它们是正确的;就是这么简单。
3.除了要求的不要多做
产品驱动的服务分解
SOA主要的优势就是它是一个能被转化成技术的业务概念，不像数据库世界里那样，技术概念总想试图跟上业务的步伐。在SOA中，每个服务必须明确地增加价值，不只是在抽象意义层面上，而更具体地要针对那些调用方而言。发生的一切之所以这样发生了，是因为服务请求者要求其如此。通过不实现任何服务请求者没有明确要求的东西，服务可以被限定在它们的核心功能上。如果SOA中所有的参与者都积极这样去做，那么将会使互操作性大大增加。
SOA中最高层次的服务是业务交易：某个客户下了一个货物或服务的订单——除非订单被供应商拒绝——否则这就开始了一个订单交付。在SOA范式中，任何从接受订单到订单交付之间所发生的都可以也应该以服务的形式实现。为实现订单交付而要求的每个中间产品或状态，供应商会要求某些人或某些组织机构——不一定是供应商内部的组织——来执行交付。然后这些中间服务自身又可以分解成多个服务，一直到增加价值的基本组织层面。
层次服务分解是SOA范式中非常重要的一部分，因为它使服务交付通过服务水平协议的方式管理。它可以确保每个服务都有专人负责，并且服务消费者们知道他们会得到什么。
通用的中间产品和通用的服务
服务分解都是关于产品的。只有当组成服务的那些子服务不能立即执行时流程才会出现。例如，如果决定是否接受客户订单的服务要求：先执行判断订单价值的子服务，再执行确定客户信用状态的子服务，那么实现该服务就包含了一个流程。每个这样的流程只与一个服务相关。如果你发现有个流程不仅限于单个这样的服务，那么你很有可能是忘了把客户的初始需求建模为服务了。
有可能出现这样的情况，相同的中间产品——当然还有相同的服务——可能会被不同的高级别产品需要。比如，那些要求明显区分交付过程的商品，在中间产品的环节，其中的差别一般来说几乎微乎其微，中间产品其实也是由客户来支付——为了从客户那里赚取利润，我们需要金额、日期以及让我们可以冠冕堂皇地向客户要求支付的条款，实际是什么则并不用去理会。在这种情况下，正常的基准是如果存在通用的中间产品，那么它应该由单个服务来实现，而这个服务能够被多个高级别的服务调用。
这种服务只有结果是重要的——不是开始——因为收集对交付服务有用的信息是服务本身的一部分，而不是请求服务源头的一部分。需要注意的是：是否需要单个服务是由业务决定的，和信息技术没有任何关系。如果不管是现在还是相关的未来，交付相同的中间产品都是切实有用的，那么就应该有单个服务。除非在现在或相关的未来有商业力量发挥作用使中间产品发生结构性分化，那我们最好不要为每组需求分别提供相应服务。然而事实偏偏相反。在SOA，事物是由相同走向不同，而在数据库化的方法中，事物则是由不同走向相同。
带有多种行为的通用服务
你可能会问，如果需要两种完全不同的行为而你只为其提供一种服务，这样做的意义何在呢?难道我们还在被同样困扰数据库世界的“一刀切”做法限制?比如，如果我们出售两种类型的产品，其中一种使用固定价格而另一种则根据某些复杂的公式计算出变动价格，为什么不用两种结算服务，为每种特定的产品各订制一种呢?
这些问题很好，但问错了地方。它们是好问题，那是因为任何不能充分应对发生在问题域内变化的设计方法注定会失败。但是它们问在了错误的地方，这是因为根据问题域中的变化来调整方案的灵活性应该构建到服务中，而不是围绕着服务来构建。就拿结算服务来说，每次调用一种方法时，它应该决定这两种算法应该使用哪一种。那样的话，如果引入第三种结算算法，那么只有结算服务需要去做调整。请注意这并不意味着结算服务必须被设计成某种“万能”机器;它同样可以很好地为每个算法分别调用相应的子服务。这种选择——介于多功能解决方案和包含不同组件的框架之间——是一种可以根据服务来决定的选择，因为它不需要被服务请求者知道。在SOA中，这种选择更常见，但目前的做法则常常导致产生框架解决方案，因为需要多功能方案的感觉在很大程度上是由于不能从那些需要执行的信息里识别出服务请求造成的。这种需要高素质专家来实现的带有如此多参数的以一应十的多功能方案的日子不会长久了。
坚持要点
流程驱动方法也可以使我们分清我们是代表服务请求者做事还是为自己做事。以服务请求者身份做的事应该作为服务的一部分来执行，而其余的就不应该了。通过这种区分，我们可以让服务尽可能简单，这样可以在不需要改变各式各样其他东西的情况下替换掉该服务。举例来说，我们会生产产品来满足外部服务请求，但是维护簿记系统是为了满足我们自己的需求，而不是请求者的。如果要开发一项服务将客户订单转变成制造活动及账目簿记，那么只要我们实现一个新的簿记系统，我们就要去修改一次这个服务。这听起来似乎还不是太糟糕，但试想一下所有事情都是为我们自己而做，那就太糟糕了。包含最新数据的数据仓库的簿记、日志、储存、员工绩效数据的维护：所有这些及其他事情一般都由系统完成，这些系统随组织机构和时间的不同而不同，因此在业务服务中包含这些知识会降低互操作性，增加了用其他系统来实现服务替换的难度。我们可以通过产生通知的方式来避免此类问题，即：如果对这些功能很重要的事情发生了，就发出通知，然后它们可以使用通用服务检索处理事件所需的信息。
另一类不应作为服务一部分执行的业务活动包括那些一旦服务请求被撤销就无法逆转的活动。通常来说，这类活动包括诸如因客户订货导致库存量低于补货水平从而需要订购补给、注册新用户以及更新现有用户信息。这些活动是整个流程中的各个步骤，应使用单独的服务一一执行。
当然，这种思维方式可以与数据库范式紧密结合。但并不是其所特有的，因为它与SOA有关。结果是，许多SOA的实现与数据库化的思维方式背道而驰，而正是这种思维方式激发了他们以自下而上的方式识别服务，而非SOA的自上而下方式。在自下而上方式中，原本一开始为某个问题开发的服务也可以为其他问题复用，这多亏了设计它的人对于如何更广泛地应用做了认真的思考。SOA中，在多个上下文中使用某个服务是缜密设计的结果，而不是靠直觉，并且从设计之初就将所有那些上下文都考虑了进来。说到复用某一服务来交付某一通用的中间产品就好比说重复使用前门进入房子，不管那扇门是通向客厅、厨房，还是卫生间。你能想象厨房设计师说：“真妙!那家伙设计的室外通向客厅的入口正好可以被我用来作为通向厨房的室外入口!”吗?任何谈论“复用”(如复用支付服务)的人都还没有实现它。请注意，这并不是错误的，只是有点奇怪和没有什么启发性罢了。
服务遵从业务
采用SOA方式思考问题的一个结果就是SOA会使得服务依据其业务意义而非机械的实现来表述。例如，名为增加用户记录的服务是数据库化的，而名为注册新用户的服务就是SOA的，即便这两个服务做的事情完全一样。我们对服务的命名十分重要，因为它告诉我们是谁在请求该服务，以及为什么他要请求这项服务。在这个特定的例子中，SOA自上而下的方法会得到一个结论，那就是业务流程需要一个有效的用户注册服务，该服务通过修改现存的注册服务(如果有的话)来完成，而不是重新自动创建一个新的。在SOA中，这是用户注册服务的责任，而数据库化的方法却会把这个责任推到服务请求者身上。类似地，SOA注册用户服务自身会决定用户ID是什么，而数据库化的服务可能就会干脆让服务请求者做这个决定。
汇聚到单个方案
总的看来，SOA由上至下的思维方式使得很多设计决策只存在一个选项，而数据库化的思考者会把该选项仅仅看作众多可选方案之一。这是SOA很重要的一个优势，考虑到SOA是以互操作性为导向的，而互操作性要求我们行车时都在同一边行驶而不用去和我们碰到的每辆车去交涉。那些忽视这点的人--比如通过主张Web服务只是众多实现跨系统边界SOA的一种方式--能够一直成功的机会和那些只考虑下一步的棋手差不多。诚然，总是有比Web服务更简单的方法去连接两个系统，但是为了让呼叫中心或输出管理设施能使用相同数据你会怎么做?为了确保数据仓库能够在你把事件从一个系统转换到另一个系统时得到通知，或者事件一发生便能及时通知你的客户，你又会怎么做呢?在SOA的世界里，数据和事件必须在多个系统中可用，而Web服务是能够确保在低投资和低维护成本的前提下达到这一效果的最有效的方法。
存在这一明显差异的一个领域就是电子数据交换(EDI)。传统的电子数据交换(EDI)技术旨在确定组织之间通信可能需要的信息，并为该信息定义词汇。那和定义某一特定的信息交互不是一回事。比如，你可以使用相同的EDI报文来下订单、查询其进展以及修改它。两个组织想通过这些规范进行通信必须坐下来一起就这一词汇的使用方式达成一致。SOA分离了这些关注点：词汇由命名空间来处理，而这些命名空间可能会被多个服务使用，每个服务有各自特定的目的。
“SOA由上至下方式导致更具体的结论”的另一领域是这样一个问题：是什么筑起了一个编排过的流程边界。通常，这个问题会引起无休止的争论。比如，采用输出管理服务给客户发送确认信息是否应被编排为用户流程的一部分，如果是的话，它应该采用即发即弃(fire-and-forget)的方式处理还是应该由输出管理服务来报告动作成功完成?按SOA的话讲，所有这些东西都是用户意图的一部分，因此都应该被编排的。其他一些行为，比如考虑到新用户订单的更新数据仓库或者更新总分类，很显然都不是用户意图的一部分，不应该包含在流程编排中，哪怕它们是同一方执行的。
4.不要自己做琐事
通用功能
业务服务应该只包含特定于该服务的那些功能逻辑。它应该把其他功能都委托出去。那样的话，服务自身就可以尽可能简单。这使得设计、测试以及替换服务，如有必要的话，更容易。这是个基本的数学知识：新软件模块需要匹配的因素越多，那么同价位下的成品软件(COTS)的共性越少，而且若恰好有个方案可用时它也会更贵。如果可以将这些非特定功能委托给标准服务，那么就可以降低需要匹配的因素个数。
服务可以代劳的首要任务是琐事：都是些“家务事”而非真正业务相关的功能。这些琐事天生就是普遍的，换句话说完成这些琐事的方式并不是为支持业务上下文的服务量身定制的。
通用用户接口
当你得知信息系统最不应该做的一大琐事就是管理用户体验时你可能会觉得惊讶。这是一个通用的功能，应该尽可能的采用标准工具来处理。用户体验包括用户可以选择要执行工作项的工作列表，工作项执行的工具——比如通过启动一个用户界面(如果有的话)来关闭已完成的工作项。它包含了用户有可能执行的交易甄选，输入信息屏幕的表示——一般是从XSD生成——以及使用和交易相对应的标准验证服务进行验证。它包括了保持当前用户上下文环境，这样他就无需再次输入当前的客户、产品、项目、流程实例或者其他任何东西，而是可以使用这些默认值或者在必要时候重写它们。它包括了和当前用户上下文环境相关的所有文档的介绍。它包含了用户可能需要作出响应的提示对话框。
所有这些东西都可以使用无需包含任何业务知识的工具实现。总的来说，给用户提供一个统一、包含所有东西的环境远比为某个特定行为而优化的用户界面要好。如果有业务案例违背了这一原则，请至少记住这点：在稳定用户界之前，不要去优化它。
(责任编辑：)
