Resilience在SOA中所扮演的角色

　　正如，在灵活性模型中，我们可以利用其可变性，在不同的层面上设计适应性，我们也可以在不同的层面设计Resilience。具有Resilience的服务不仅要处理大量的请求类型，同时还有大量的服务请求。既然服务基础设施（包括普遍的ESB产品）可以处理这样的服务可用性Resilience，设计师的最佳实施就是考虑故障切换服务、服务实施组，或者通过在服务合同中描述多个服务接口和服务端点实现负荷平衡，这样设计师就不必依靠具体的基础设施处理不同的服务负荷了。

　　但是服务层面的Resilience不足以保证整个企业架构的Resilience。就像服务需要冗余度，负荷平衡以及适量的物资供应一样，在业务流程的实施过程中也需要这些组合。故障切换流程为业务逻辑提供了另一种执行路径，冗余进程将交替调用机制的相互作用提供路径，当其它流程要翻倒的时候，创建事宜的流程。所有这一切都要考虑进来。

　　可能在基础层面，Resilience的简单形式更容易实现。SOA基础设施可以处理广泛的使用负荷和调用方法，但是这取决于单一的一个供应商或者是一个实施。好的设计师可以通过冗余，负荷平衡并且轮流的运行引擎完全依靠基础设施的Resilience。通过使用分散式，不同类的网络中介代替单一供应商，所有权以及ESB单个故障点。机构同时也要实施超高速储存。卸载XML语法分析，并将近期的绑定、网络通路（用以处理远离服务端点的安全性和策略实施）以及注册表联系在一起。当你依靠高层的Resilience时，基础设施层面的Resilience更具有可行性。而不用完全依靠供应商的实施。

　　但是为什么要就此罢手呢？寻求SOA Resilience的机构同时还要确保拥有弹性的服务原则。这不仅需要冗余原则强制机制，还需要故障原则定义点甚至故障切换，以及负荷平衡服务原则。当你在运行时使用原则来决定服务绑定时，如果服务原则定义突然中断，就会导致严重的损失，这种损失和服务本身瘫痪所带来的损失大相径庭。

　　同样，企业在服务合同和模式层面也需要Resilience。如果冗余的服务实施共同享有一个服务合同文件，冗余服务实施就不具备合理性了，因为这一份文件很容易丢失，尤其是在未经保护事物文件服务器中。通过将元数据锁在原则强加的注册表之外，可以保护你的元数据，但是同时还要确保冗余度，故障切换以及负荷平衡，以避免移动单一的故障点。这一点对所有的服务元数据、流程元数据、数据模式和语义映射（有利于系统进一步的正常运转）都适用。

　　ZapThink采取的措施

　　上述所说的所有一切可能并不重要，如果企业架构中最重要的部分，即设计师不具备Resilience，那一切就显得毫无意义了。在你的机构中，你是唯一拥有SOA的企业设计师吗？或者更糟，你是机构中唯一的企业设计师吗？一旦你更换工作、或者下岗、或者机构改变了对SOA或者EA的态度，你该怎么办呢？这会毁掉整个SOA项目吗？预算和资金又从哪出呢？你是否正在边缘工作，希望有朝一日有人能够推你一把？如果是的话，那么你需要的是结构和机构Resilience。确保拥有广泛的支持（冗余度）。为结构活动分配工作量和责任，确保拥有一个设计师团队，而不是孤立的十字军团（故障转移和群集）。让机构的其它部门都可以看到所有这些活动带来的收益，确保具体的EA任务有具体的业务收益，并在短期内重复提供二者的闭合交互作用。

　　灵活性和适应性并不足以保证SOA的成功实施。实际上，在过去的8年里，ZapThink讨论的主要问题都是围绕企业架构的灵活性，Resilience所展开的。如果一些所谓的SOA收益即将消失（即基于标准的集成），但是我们仍然保有灵活，富有弹性的企业设计师，我们已经实现了SOA的首要目标。要使业务能够在不断变化的环境中持续发展，同时还要考虑高昂的成本和很长的等待时间，这就需要企业设计师要针对Resilience以及灵活性，多多思考，多多实践。