典型通用功能
其他的琐事还包括，但并不仅限于以下几个方面：
安全：建立服务请求者身份和访问权限。
通知：确认某一业务事件应通知哪些人。这包括了维护基于此的事件订阅。
输出管理：在线下进行信息通信，而不是作为一种服务响应。典型例子就是当客户请求必须被正式确认时，比如使用电子邮件来确认你刚刚通过浏览器所做的网上采购。对那些主动提供的消息也是需要的，比如每月的账单。输出管理必须决定通过哪条渠道去发送信息，以及使用哪个地址来发送。它应该把消息转换成接收方能够接收的格式，发送消息，并把消息添加到归档文档。输出管理包括维护那些被用来将数据转换成用户可理解消息的模板，以及潜在接收者的地址和渠道偏好。
数据转换：把数据从一种格式转换为另一个，把独立的各个服务打包为一个服务——用麦当劳的说法，开心乐园餐——以及分解拆包，将服务请求拆分成适用于不同人群的各个独立请求，汇集各个回应，排队及出列，或协议转换。
流程编排：编排某一流程，以确保按适当顺序且仅相关时来执行那些组成流程的服务，确保快要逾期时发送告警信息，以及确保因辅助信息或者逾期打断从而引起的新流程分支被启用。
归档管理：维护及访问相关的归档信息。这些可能是虚拟的档案，从某种意义上是展现给用户的信息，当他需要某个档案时可以使用查询来检索。对那些从数据库中抽取的内容，这被认为是正常的，但是没有特殊理由不对文档使用相同的方法。在某些情况下应使用设备来特别增加指派文档至档案中。
记录管理：维护那些不允许被更改的信息。
至下而上叙述
这些实现琐事的服务不能形成业务服务层次的部分。不能使用自上而下的方式去设计它们，因为这些服务都没有所谓的“上”。对这样的服务，使用旨在实现最大程度重用的自下而上的方法会更适合。这使得从这个阶段起就能够实现服务的优胜劣汰。
采用数据库化的方法，很少能够实际把次等通用功能用更好的替换，因为这要求修改所有使用该方法的应用。使用SOA则不同，这种替换很简单，前提是已经应用了“不去了解你不需要了解的事情”这条规则，包括其推论：服务请求不应该包含超过指定该请求必要信息之外的其他信息，而且服务本身应该在需要时主动要求更多信息。如授权服务，该服务由某应用调用，旨在决定是否允许某特定用户在某客户数据上执行某项功能——比如说：“我们的雇员Donald Jones是否被授权可以访问Acme Widgets company公司相关的财务数据?”。服务的简单版本可能具备处理某些特定情况的能力，在此特定情形下可以通过使用雇员功能对应表来回答这些问题。稍微复杂一点的版本可能会识别出Donald Jones属于某个或多个组的成员，除了个人权限外还拥有该组的权限。再更近一步，授权服务可能会使用用户证书去区别雇员和客户，并允许客户只能够访问他们自己的数据。一个完善的版本可能会使用标准化的服务去调用业务流程管理系统或者项目管理系统，询问Donald Jones是否已经被赋予了任何我们和Acme Widgets交易相关的职责。更好的做法是，授权服务会记录请求和应答的日志，而简单的版本不会这样做。组织可以从一个服务的版本切换到另一个而无需对调用服务的应用做任何改变。
也有可能设计出根据操作必需的条件自动配置自己的通用服务。例如，授权服务可以检查是否有服务可以告知它员工对某些特定客户有职责，并在该服务不可用的情况下决定只使用个人还是群组的访问权限。用这种方式，服务可以在很多组织之间复用。
5.不要在测试上自寻烦恼
为什么SOA更容易测试
对SOA缺点的一种看法是测试困难。这种看法完全不恰当，原因有很多。
首先，在SOA中使用元数据可以避免错误被植入到系统中。可以在元数据层次就对系统进行验证，例如，保证所有需要处理的数据在使用前就被汇总并校验。在整个业务流程范围内都可以实现这点。当你可以验证设计的时候就不要测试整个系统。
其次，几乎所有测试，包括所有系统集成测试，一旦测试基准被建立后都可以自动完成。但是，需要一些前提条件。表现层和业务执行层必须被严格的区分。好在这是使用SOA的一种很自然的方式。对所有输入，都应该存在相应的XSD。使用该XSD，可以生成测试记录。同理，也可以生成带有预期输出结果的测试记录。在测试过程中，不能产生可以证明系统运行正常的任何输出地方，必须在测试脚本中添加专门为此生成的附加输出的查询语句。当测试开始运行时，测试记录被一条条输入系统，然后输出的结果自动和期望的结果进行对比。这会产生一个异常列表，其中每项都应仔细考虑。测试可以按需进行。自然，测试的结果可能取决于存积在数据库中的数据，所以这点需要进行弥补。而且，系统不可表现出时间相关的行为。系统必须有能力响应每隔一段时间(它对自动化测试序列更适合)就产生的事件，而不是花上一周时间去等待某个基于时间的触发器被触发。用户界面的测试应该单独进行，而且永远不在集成测试中使用。
第三，SOA的设计趋向于产生更加健壮的系统：系统出错的机会更少。SOA减少了信息系统为了协同工作而需要达成协议的因素数量，这样一来，导致在某关键因素上产生分歧的设计错误的概率也减少了。就算真的出错，也能够在造成损害之前检测到。使用SOA，消息在被处理前会被验证，这样可以判断消息是否格式正确、是否符合相应的XSD。
可行性测试
最后，作为数据库时代特有的产物——测试环境和生产环境必须严格区分，从此不再需要了，而且有时候这也是不适合的。这是很有可能的，这是因为我们不再实际进行系统测试了，而是对测试通路和信息处理的方式进行测试。SOA提供了三重安全的、有效区分测试消息和生产消息的方法。除了被封装好的消息，其他每个消息自身和相应的命名空间都包含版本号。而且每个消息都包含一个标签用以指示它是用于测试还是生产。所需的只是一个SOA网关，它存在于防火墙内部，对每条进入消息进行如下处理：
校验消息以确定其是否与一个已知XSD的版本相符(被封装好的消息除外)。
使用我们对相应XSD的副本对消息进行校验，以确定其是否有效。
如果消息用于生产的，就验证消息版本号是否被允许用于生产。只有这样，消息才能够被传递到生产系统。其他所谓的“生产”消息都会被拒绝。
如果消息用于测试，消息可能会被传递到指定的测试版系统。在特殊情况下，消息如果只是用来做数据检索，那也有可能被传递到生产系统。
只有在消息被完全测试过后，生产版本的注册库和XSD才能得以更新。
这样的处理方法不仅仅只是三重安全的，而且使得消息的路由能以一种合乎实际的方式得到测试。这也大大降低了从测试系统切换到生产系统时重新进行配置的需求。因为这种重新配置天生就是不可测试的，常常成为错误的根源。发布经理只能通过在半夜或者周末发布新的版本软件来弥补这类错误;这样，就算新版本出现了任何错误，也可以在有人发现错误之前恢复到老版本。但如果这样的变化影响到了其他组织那就没有办法这样操作了。SOA发布管理要简单得多!
我们对于SOA测试的一般认识是时候该改变了。SOA是能够把测试需求和设置测试的工作减少到最低的一种方案。它能使重要测试更自动化的完成，结果也更好。
完善之理论
SOA使得信息系统的开发和部署能够比使用数据库化的方法支持更为丰富的用户体验。这样的系统能够涵盖更多的信息格式、更广的行为集合，其行为上也可以达到更高层次的统一和一致以及更加可靠，不管是从客户还是从组织内关注合规的人员的观点来衡量。然而，要想获得这些好处需要我们跟已有的数据库方法实践说再见。
6.始终信守你的诺言
为什么数据库不能一直信守诺言
接收一个服务请求的动作是通过定义一个承诺，即向请求者承诺服务请求会被执行，来确定的。这种执行定义了一个流程，其至少包含一个步骤，但通常是多个步骤。
数据库化的思考和流程不能融洽相处。从它们各自的本质来看，数据库就像是一个个孤岛。而孤岛会促使偏狭地思考问题：任何孤岛之外的东西都不重要。可以通过数据库中的事务概念来形象地解释这个问题：某个工作单元把数据库从一种一致性状态转移到另一个。在一些特殊的情况下，该概念可能会被扩展到多个数据库，虽然可以通过两阶段提交技术来做，但这也有局限性。逻辑一致性可能需要贯穿整个业务流程得以维护，而不只是恰好在某个时刻;需要在信息改变波及的所有地方去维护，其中不仅包括数据库还有流程管理系统、信息以及发送和接受信息的人工代理，而这一切从数据库世界的观点看来是完全陌生的。
SOA交易概念
对数据库世界陌生的东西对与SOA来说却是再自然不过了。业务交易——实现它的一般是一个流程——就是服务。为了理解SOA何以能很好支持逻辑一致性需求，理解业务交易的需要很重要。业务交易由下面元素组成：
厂商给客户提供信息，客户据此可作出采购决定。一般来说，这种信息包括出售商品和服务的属性、得到该商品的条件——包括，当然，价格——以及可用性。从法律的角度，厂商所描述的这一信息是真实的。
用户基于厂商描述的信息下采购订单。
厂商核实该采购决定依据的信息是否仍然适用，如果是，则确认该订单。如果有变化——可能由于产品或服务已终止，或产品已经涨价，也可能是货物或服务的规格已经变更——那么需要一些处理来决定到底应该如何做：是不管三七二十一继续提交订单，还是通过协商修改订单，或者干脆取消订单。
厂商和客户双方履行采购协议中各项条约。
SOA怎样维持一致性
SOA通过多种方法维护业务交易的逻辑一致性。第一，所有暗含对前一个状况改变的通信都要使用能够保证消息安全交付的协议来完成。只要厂商或用户做出某个承诺，为实现该承诺所要做的动作就应该包含这样的改变。这样的话，客户和厂商就不可能对当前业务状态持有不同的看法了。
第二，数据库的逻辑一致性和流程管理系统中处理过程的记录可以通过两阶段提交协议来维护。跨多个数据库的逻辑一致性通过一连串这样的两阶段提交维护。首先让数据库A和流程管理系统同步，然后流程管理系统再和数据库B同步，以此类推。
第三，从厂商给客户展示产品到订单下达期间，厂商面对的任何改变都可以使用乐观锁并发控制机制来处理。这种处理方式对SOA来说很自然：判断是否存在相应改动的过程可以完全自动化。因为SOA使得数据在被用来作决定的同时也可以进行访问，找不到乐观锁而需要人工介入的情况几乎鲜有发生。
最后，一笔交易的中止——比如说用户撤销了订单，原因可能是用户没有能力支付，或者用户去世了——使用SOA可以相对容易地处理。因为在交易上下文中使用或产生的记录可以被清晰地识别，所以可以确定需要哪些补偿信息用以纠正用户和厂商的不同认知。因为哪个数据库更新和该交易有直接关系是很清楚的，在数据库中的哪些变更需要使用补偿交易服务做回滚也很清楚。假设，交易中止的发生相对不那么频繁，使这些活动完全自动化通常是高投入低产出的，但是你的设计必须要考虑到这些。
请注意业务交易的范围限制在那些为了处理某个服务请求而直接完成的操作。在SOA中，编排你自己的流程并提供事件通知给他人，是一条守则。如果服务中止了，那么有必要发通知用户这一个变化。至于他们要怎么处理，则完全是他们自己的事。
也请注意，创建用户服务请求的内容，严格说起来，应该在流程处理之前进行，而不应该作为流程处理的一部分。这真的不是你该做的事：原则上，提供消息的XSD和消息验证服务给用户就够了，让他决定是从键盘录入数据还是从他自己的信息系统以某种方式直接生成数据。对消费者来说，这并不是——尚未成为——一个可行的方法，但采集数据和处理数据是两件独立的事情，并使用不同工具在各自的环境中执行这些事情，对于这一点仍然是有效的。同样是数据采集，有很多实现方式，这取决于用户的期望以及他们和你沟通的渠道，但不管怎样都应该只有一个服务去处理这事儿。
7.不要将自己禁锢于模型
数据库只是模型，SOA代表更多
领域模型是领域本身的体现，操作领域模型要比直接操作领域更简单。绝大多数的数据库都是模型。它们以这样一种方式代表一些管理的、物理的或者社会的领域：相关领域的问题都可以通过查询数据库来得到答案，而存在于领域中所需的行为可以从数据库内部得到指示。比如说，通过访问数据库查询用户的地址信息要比跟随用户到他家然后抄下他所进房子的门牌号要方便的多。而且，在数据库中对记录进行计数也要比清点一个城市有多少人或仓库里有多少产品要容易。原则上，提供对这些功能的支持足以确定数据库的数据结构。尽管这样，因为一般不太可能事先就能明确所有这些功能，所以我们使用数据建模技术对领域中感兴趣的对象进行分析，包括对象之间的关系，以及信息项(它们会告诉我们关于其自身的一些我们可能想知道的东西)。例如，若数据库和用户有关，那么每个用户通常都应该存在对应的数据库记录，包括一些数据库使用者感兴趣的与用户相关的信息。因为数据模型更多是基于功能上的考虑而不是某些特定数据库的使用，所以将数据结构建立在这种模型之上会使数据库能够更易适应各种未预见的需求。数据库在语义上被结构化了;换句话来讲，数据库是根据其表达出的意思来构造的。
对没有实现数据模型的数据结构，数据库技术就没那么方便了。它实在不能在描述、文本、图像等方面做很多贡献。相反，SOA却能够很好地处理文档、记录，就像可以很好处理那些根据数据模型构建的数据一样。SOA允许单个设计能够处理语义结构化信息和文档。尽管如此，由于数据库系统支配了我们的思维模式，所以当应用SOA时免不了很自然的会坚持其局限性。但是在SOA的世界里不存在特殊的理由要去应用这种限制，任何理由都不能够这样做。
超越模型的益处
将语义上结构化的数据和一些像超链接、文本、图片以及音频片段的东西结合起来的一个主要原因是创建更为丰富的用户体验。对消费者来说，这是必须的，而不是可选的。对你雇佣的知识型工作人员而言，这会使他们做事更有效率。只有对从事日常管理的员工来说，它才会成为一种障碍。然而你应用SOA越多，你对这些人员的需要就越少。他们从表单键入数据的工作可以外包给任何人做：你需要做的仅仅是扫描每个表单然后把图像发送给代理，代理本质上使用和用户一样的Web表单去键入数据。至少真正需要雇员日常处理的工作都可以用自动化完成。
不要让自己禁锢于数据库数据的第二大原因是，把数据库化和基于文本的数据结合起来是目前维持营运合规所需记录信息和审计线索最简单的方法。数据库因其特有的性质并不适合这样的最终目的。因为通常某个数据库是为担当某种管理现状模型而构建的，所以当该管理现状改变的时候，它应该很容易去做相应改变。数据库管理系统就是为了方便这种改变而设计的。当它们被用来维护不允许被更改的记录时——比如，簿记条目——设计者不得不把各种安全防御构建到系统中，从而防止对记录的恶意操作。即便如此，神智清醒的外行人也不会去信任数据库的。为营运合规目的需要的记录信息和审计线索必须被委托给记录管理程序，然后通过SOA来与数据库系统进行关联。
使用SOA，把语义结构化的数据和其他形式的信息表示连接起来很容易。这使得它是内容管理和内容表示的理想之选。数据库可以将超链接保存到其他信息中。比如，我们可以用交易的数据库记录来存储产生该交易的输入文档的超链接。当显示交易记录的同时，链接也跟着展现，而且可以让使用者通过单独的服务去激活它。开发一个使其能够从归档文件去访问文档的服务不会比开发一个从数据库访问数据的服务更困难。当然了，除非你的归档文件不具有SOA能力，此时第一件要做的事情就是替换掉它。
但是，反过来也一样。不仅语义格式化的数据通过链接来丰富记录，而且记录也可以通过链接来丰富语义格式化数据。当你将记录存储于归档文件中的时候，与记录相关的语义结构化数据通常会包含所有为其索引而需要的信息。几乎不可能不需要手工索引记录。可喜的是，每当交易在数据库中进行一次，索引就可以自动对其更新从而逐步丰富起来。
集成数据库化和基于文档的数据有另一大优点，就是很容易支持数据的多个版本。在数据库世界这是说不通的，因为数据库作为一种模型，且作为一种有用的模型，它必须在对管理现状模型的任何提问作出至少一个最佳的猜测以应答。一个文档，实际是某个特定组织在特定时间以及特定环境所做的一个声明，而且这也很有可能——经常被用来了解——相冲突声明的存在。
文化冲击
请注意，数据库化的思考者不是唯一在统一文档和数据库世界遭遇困难的人。那些思维方式受当代文档和记录管理系统影响的人会遇到更大的困难。一时之间，归档文件成为业务流程的一部分，而不是流程完成后形成。而索引不是人工完成，也不是一个文档一个索引，而是自动并持续更新的。索引也不再是归档的一部分：归档仅仅只包含文件，而索引分开维护。因此不需要把自己局限于一个归档，或者只局限于你自己的归档。这些改变是如此深远，很难想象那些适应了旧世界的人也能对新世界适应。
8.不要使用快照模型
具体而正式的历史信息
我职业生涯中最大的错误就是设计了这样的数据库，其中所有服务请求都被给予一个时间戳，以便数据添加进去后，服务可以根据指定时刻数据库存放的数据内容来响应，而不是根据当前内容。这个数据库极其昂贵，把执行速度拖累得就像龟行，而且没能起到很大作用。当用户想看看过去某个特定的结果是怎么被计算出来的时候，他们不免只能够查询归档文件，因为这些归档文件总是会包含之前与用户沟通的结果。而这也正是他们想要知道的东西。
请注意数据库的用途不是去记录过去那些成为问题的情况。数据库是现实世界某些部分的模型，以及在过去某一段时间里现实世界那部分的状态——它的具体历史——可能和模型的目的非常相关。但是，如果它想要再现自己在过去某个点的状态，换句话说去记录它的正式历史信息，数据库就太把自己当回事儿了。
SOA如何支持正式历史记录
SOA方法提供了一种再现正式历史信息的高效方案，不只针对单个数据库，而是针对组织在其管理流程中使用或者产生的所有信息。SOA对组织信息更新所需的数据收集和实际执行更新的分离让数据可以在记录管理程序中得以归档。一旦应用了SOA，这就可以自动完成，而且合并新的数据集几乎不消做多余的努力。这样一来，你可以获得由自己雇员所做的所有输入消息以及更新。
对即将离开的线下信息情况来说，可能更简单。SOA厌恶将琐事与对客户的附加值混合起来，这种混合导致客户很自然地会去使用输出管理服务以确保离线信息通过适当的渠道发送至目标接收者，发送时要确保地址是接收者会使用的，并且格式是接收者确实能收到的。输出管理服务能够自动记录输出信息。
尽管如此，还是有个问题。组织使用SOA传播信息的难易程度有可能导致对外界的服务响应数量大大增加。通常这些服务响应都隐含了组织对他们声明内容的承诺。如果它们不正确的话，组织可能会陷入法律难题。SOA处理这种问题的标准方法包括以下指导方针：
(责任编辑：)
