SOA管理应具备全局眼光

SOA已经步入实施的纵深阶段，然而，近来国外的一系列SOA实施案例表明，曾经备受肯定的SOA架构正暴露出其架构的固有缺陷--当基于SOA的服务管理达到一定深度时，目前的SOA管理策略在服务故障的追根溯源方面力有未逮，这一现实对整个SOA架构和管理理念都提出了严峻的挑战。国内SOA用户应该对这一动向保持足够的警惕。

谁该为故障负责

分析师兰蒂·海福纳认为，曾经被广为称赞的SOA的架构特性正在暴露出它的固有缺陷--目前，大部分应用了或正在应用SOA架构的公司和组织对于“应该由谁来负责响应故障求助”这一问题困惑不已。

从目前的状况看，似乎总是能找到这样或那样的团队负责提供应用故障服务，但是最后的结局往往是所有应用相关的开发团队都被扯进来，围绕纠缠不清的责任问题一筹莫展，问题的根源却无从确认。

SOA架构拥有太多处于移动状态的组件，因此，顺藤摸瓜找到服务故障发生的根本肇因并不是一件容易的事情，更何况与此同时SOA还是一个由多个相互关联的层组成的架构，这更增添了查错的复杂性。

海福纳认为，目前的大部分SOA管理工具必须进行有针对性的改进以应付这种尴尬局面。SOA管理工具必须具备锁定深层次服务管理问题的能力。应该说，现有的SOA管理工具在定位问题的发生方面做得不错，它们大都能在问题发生时通过一项服务提醒CIO,即使故障产生的环境非常复杂。比如在Java、。NET、消息中间件或者是遗留系统接口内部这类环境，这些管理工具仍然能够迅速发现问题。

CIO们被告知系统中产生了一个故障，“好吧，接下来问题来了，SOA服务产生了问题，我们该向谁拨打这个求助电话呢?”海福纳说，面对实施过程复杂、需要由多个团队协作的SOA架构中产生的问题，每个团队都会龟缩在各自的阵地中大喊：“这不是我的错--我负责的部分工作得很好!”这显然是CIO们始料不及，却可能得到的唯一答案。

SOA管理应具备全局眼光

“这是因为每个人的眼界都被限定在他们自己负责的那部分基础架构工作里，而这恰恰是SOA架构的特色之一。”海福纳说。

那些服务管理达到一定深度的CIO们目前面对的现实状况很不乐观，为了解决这一问题，SOA的管理策略和解决方案必须重新进行调整，以帮助他们解决那些深层次服务管理问题。

微信扫一扫实时了解行业动态

微信扫一扫分享本文给好友