实现和SOA交易概念相一致的业务交易。

     将放弃承诺包含在对全部信息进行检索的服务的服务水平协议中。

     在需要使用时才访问数据。这样可以使数据尽可能的最新。

     不要撒谎。如果一直讲真话，你将很少遇到关于信息不正确的投诉。

     如果使用放弃承诺还使得你不得不对声称信息是不正确的声明作出反应，那对每个服务请求和回应进行日志，采用标准的组织范围的服务。

     这种工作方式要比数据库化的方案组织起来更简单，因为不需要对每种消息类型都要求一种额外逻辑，而是调用日志服务，在日志服务中整个输入或输出消息都被当成是单一的数据项来处理。

     9.不要相信系统

    SOA安全

     如果你的身体使用与大多数Web网站相同的防御规则来抵制外物，只消一天你就会死亡。我们生活在一个怀有敌意的世界，这里唯一能够避免信息系统遭受攻击的办法就是让它们不可访问。在这样的世界，SOA是一种绝妙的安全概念。原则上说，唯一必须让其通过防火墙的消息是牢牢封装好的XML消息。它们可以以这样的方式通过防火墙：在进一步处理之前它们会接受格式良好、XSD一致性以及授权有效性方面的检查。这样，造成危害的可能性非常小。缓冲区溢出只能够在安全防御区内爆发，而SQL注入不过是我们对其充耳不闻的一种语言上的祸害。像这样畸形的消息在其作出任何伤害之前就能被识别出来。

     认识到这点很重要：即这种方法的优势是基于消息的认证和校验而非系统的。这是必要的，因为封装好的XML常常通过那些对其内容不负任何责任的系统传递，以至于检查消息是否来自认证过的系统并不能保证什么。它更健壮，因为某信息系统或电脑一次成功侵入并不会为其他侵入打开大门。

     SOA的安全和数据库时代基于系统的安全形成了鲜明对比。有了基于系统的安全保障，对每个消息类型和数据项来说，每个系统的任务就是避免缓冲区溢出。有上千个点可能成为出错点。因此，就少不了薄弱点存在的可能性。而另一方面，某个SOA关守(gatekeeper)，可以在单一的点上完成所有这些。基于系统的访问安全倾向于把授权控制构建到系统中，这不仅使得跟踪记录变得几乎不可能，而且引入结构性改变(比如把外部组织的客户添加进来)也是很昂贵的花销。

     使用SOA关守的另一大优势在于可以保证所有输出消息被适当加密和签名，这样就没人能够窃取消息或在传输中篡改消息。原则上，大部分WS-*标准都可以完全由SOA关守处理。

     超越基于系统的授权

     基于系统的安全也会产生了一些心态，这些心态更多的是由基于系统的思维决定的，而不是如我们所愿意承认的那样。因为系统是围绕着功能点和数据结构构建的，授权就是这样表达的。例如，雇员要么有权限改变产品价格，要么没有，这是基于他在组织中的角色而定。对后端雇员不会遇到这种问题，但对管理层雇员以及用户而言，这就不适合了。对他们来说，允许他们查看和完成事情的决定因素是横跨所有系统和数据库的手头客户的信息切片。一个简单的信息安全文献扫描就足以构建那些信息安全咨询公司尚未企及的一点：对每一个基于切片的访问安全引用有数以千记的基于角色的访问安全。从积极的角度看，涌现出大量的概念，它们对充分发挥SOA提供的各项技术(基于声明的访问控制、联邦身份及网络边界去除技术)的优点来实现访问安全有长期正面的影响。

     可管理之理论

     想要取得SOA最大化的利益，仅仅采用新的行为准则是不够的。组织机构考虑自身的方式及IT方式也需要改变。否则当前的组织将还是退回到老样子，并不是因为它想要这样，而是因为它把这看作是控制自身日常行为的唯一方法。为了克服这点，你必须从项目的组织去着手。

     10.不到最后不要扔掉基础设施

     为什么要担心基础设施?

     SOA就是要使基础设施从业务中分离开来，不只是在功能上，而且还在项目管理上：项目经理应该能够把思想集中在他负责开发的服务的商业附加值上，而不是担心基础设施。业务项目经理应该去组织开发一个作为项目一部分的新授权服务，而不是去构建一个新电话局，这不会荒谬到哪里去。让项目经理承担类似这些事情会导致他要协调的事物数目增加，从而进一步导致其工作复杂性不成比例的增加。就算让他等待直到其他项目经理把基础设施交付了，这也是应该尽可能去避免的。

    上述评论适用于硬件基础设施也同样适用于基础设施服务。计算能力和网络容量应该总要超过需求，这样的话实施新服务的项目经理就不用担心基础设施是否能够为比原先预想更多的每天上千个服务请求提供支持。鉴于软件开发一般都比IT基础设施要贵出一个数量级，我们最不想要的就是：系统开发项目由于那些需要确保IT基础设施可用性的官僚性流程而被纠缠停滞不前。

     基础设施：SOA有何不同

     好消息是用SOA的方式去提出你的要求然后静观其变会得到简单、稳定的基础设施服务接口。这也就是为什么在你没有启动任何业务项目前，没有必要去实施世界上最先进的基础设施服务。这些服务的复杂性不在于用来调用它们的接口，而在于它们从其他来源——或者从自我维护中——要求的信息，以便生产一个优化的结果。因此，完全可行的办法是有了初步的基础设施服务就启动项目，然后在业务项目中花足够多的时间去使用这些服务来做测试和生产。

     坏消息是SOA会导致更多的功能被分类为基础设施。尤其是，每个琐事引起一个通用的服务，而这一服务必须作为基础设施的一部分而不是成为需要它的每个业务功能的一部分来实现。虽然就本身来说不算很坏，但这的确导致了一个新问题：对于基础设施的每个部分来说，如何去组织安排各项事宜才能使既拥有权限又具有资源的人去确保它能按时可供使用而且具备了适当的功能和容量。组织若是不能妥善处理这一问题的话，就不能很好地实施SOA——事情就这么简单。

     敢问路在何方?

     虽然组成SOA的要素已存在多时，但SOA本身是全新的。就像集装箱一样，它不只是一种全新的处理我们一直以来所做事情的方法，因为它使得我们能以新的规模合作。而且SOA根本不是一项新技术，而是一种新的思维方式。SOA与我们现在考虑问题的方式是如此不同，所以要是你通读本文几遍才开始理解其中的意思，你并不用感到难为情。你对此的自然倾向是，你会觉得这些建议不切实际或没有必要或者两者皆是，而使你根本无法对它作出评估，在这之前你还需要适应一段时间。

     公正地说，也会出现SOA方案对你不直接起作用的情况。比如，你可能会从一些厂商那边以打包的形式获得你所有的系统，而那些厂商对采用本文中提到的方式来应用SOA一点特别的兴趣都没有。那样的话，把本文中所给的建议作为指南：使用它们来判定是否你做的选择会把你带向正确的方向。

      SOA是如此之新，所以并不是所有为了充分利用SOA而被我们需要的概念、工具及标准都已经可用了。我们不能期待现行的关守(gatekeeper)像一个SOA关守(SOA gatekeeper)一样为我们代劳一切，现行的用户接口设备对于封装的XML有困难。更糟的是，正如本文表明的那样，当前SOA世界里存在很多扑朔迷离、多余或者错误的东西。目前，SOA概念和技术的应用无论在哪里都没有达到SOA互操作性能力所能够达到的层次。我们遇到的互操作性问题往往都是由于其他一些人选择了实现稍有不同的众多WS-*标准中的子集。那些数以百万计的多方通信的可能方案已经减少到很少的一把了，但依然还是实在太多了。

     不管怎样，我们开了个好头。接下来我们可以沿着这条路继续走。SOA也同样如此。我们不需要为了进步而要去了解我们还不能了解的东西。向前看，我们有极大的潜力去使得事情更简单、更可靠，更具可预测性以及功能更丰富。是时候出发了。
 

(责任编辑：)