面向服务的架构SOA十诫

第 6 页 SOA如何支持正式历史记录
SOA如何支持正式历史记录
SOA方法提供了一种再现正式历史信息的高效方案，不只针对单个数据库，而是针对组织在其管理流程中使用或者产生的所有信息。SOA对组织信息更新所需的数据收集和实际执行更新的分离让数据可以在记录管理程序中得以归档。一旦应用了SOA，这就可以自动完成，而且合并新的数据集几乎不消做多余的努力。这样一来，你可以获得由自己雇员所做的所有输入消息以及更新。

对即将离开的线下信息情况来说，可能更简单。SOA厌恶将琐事与对客户的附加值混合起来，这种混合导致客户很自然地会去使用输出管理服务以确保离线信息通过适当的渠道发送至目标接收者，发送时要确保地址是接收者会使用的，并且格式是接收者确实能收到的。输出管理服务能够自动记录输出信息。

尽管如此，还是有个问题。组织使用SOA传播信息的难易程度有可能导致对外界的服务响应数量大大增加。通常这些服务响应都隐含了组织对他们声明内容的承诺。如果它们不正确的话，组织可能会陷入法律难题。SOA处理这种问题的标准方法包括以下指导方针：

实现和SOA交易概念相一致的业务交易。
将放弃承诺包含在对全部信息进行检索的服务的服务水平协议中。
在需要使用时才访问数据。这样可以使数据尽可能的最新。
不要撒谎。如果一直讲真话，你将很少遇到关于信息不正确的投诉。
如果使用放弃承诺还使得你不得不对声称信息是不正确的声明作出反应，那对每个服务请求和回应进行日志，采用标准的组织范围的服务。
这种工作方式要比数据库化的方案组织起来更简单，因为不需要对每种消息类型都要求一种额外逻辑，而是调用日志服务，在日志服务中整个输入或输出消息都被当成是单一的数据项来处理。

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

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

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

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

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

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

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

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