典型通用功能
其他的琐事还包括，但并不仅限于以下几个方面：
安全：建立服务请求者身份和访问权限。
通知：确认某一业务事件应通知哪些人。这包括了维护基于此的事件订阅。
输出管理：在线下进行信息通信，而不是作为一种服务响应。典型例子就是当客户请求必须被正式确认时，比如使用电子邮件来确认你刚刚通过浏览器所做的网上采购。对那些主动提供的消息也是需要的，比如每月的账单。输出管理必须决定通过哪条渠道去发送信息，以及使用哪个地址来发送。它应该把消息转换成接收方能够接收的格式，发送消息，并把消息添加到归档文档。输出管理包括维护那些被用来将数据转换成用户可理解消息的模板，以及潜在接收者的地址和渠道偏好。
数据转换：把数据从一种格式转换为另一个，把独立的各个服务打包为一个服务——用麦当劳的说法，开心乐园餐——以及分解拆包，将服务请求拆分成适用于不同人群的各个独立请求，汇集各个回应，排队及出列，或协议转换。
流程编排：编排某一流程，以确保按适当顺序且仅相关时来执行那些组成流程的服务，确保快要逾期时发送告警信息，以及确保因辅助信息或者逾期打断从而引起的新流程分支被启用。
归档管理：维护及访问相关的归档信息。这些可能是虚拟的档案，从某种意义上是展现给用户的信息，当他需要某个档案时可以使用查询来检索。对那些从数据库中抽取的内容，这被认为是正常的，但是没有特殊理由不对文档使用相同的方法。在某些情况下应使用设备来特别增加指派文档至档案中。
记录管理：维护那些不允许被更改的信息。
至下而上叙述
这些实现琐事的服务不能形成业务服务层次的部分。不能使用自上而下的方式去设计它们，因为这些服务都没有所谓的“上”。对这样的服务，使用旨在实现最大程度重用的自下而上的方法会更适合。这使得从这个阶段起就能够实现服务的优胜劣汰。
采用数据库化的方法，很少能够实际把次等通用功能用更好的替换，因为这要求修改所有使用该方法的应用。使用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.始终信守你的诺言
为什么数据库不能一直信守诺言
接收一个服务请求的动作是通过定义一个承诺，即向请求者承诺服务请求会被执行，来确定的。这种执行定义了一个流程，其至少包含一个步骤，但通常是多个步骤。
数据库化的思考和流程不能融洽相处。从它们各自的本质来看，数据库就像是一个个孤岛。而孤岛会促使偏狭地思考问题：任何孤岛之外的东西都不重要。可以通过数据库中的事务概念来形象地解释这个问题：某个工作单元把数据库从一种一致性状态转移到另一个。在一些特殊的情况下，该概念可能会被扩展到多个数据库，虽然可以通过两阶段提交技术来做，但这也有局限性。逻辑一致性可能需要贯穿整个业务流程得以维护，而不只是恰好在某个时刻；需要在信息改变波及的所有地方去维护，其中不仅包括数据库还有流程管理系统、信息以及发送和接受信息的人工代理，而这一切从数据库世界的观点看来是完全陌生的。
喜欢 
顶
难过
囧
围观
无聊
