机械网--警惕SOA架构暴露固有缺陷

对很多企业领导者来说，半夜两3点电话响起不是什么好事情——这很可能意味着，企业出了事，而且这些事情很有可能不知道该由谁解决。随着企业范围的逐渐扩大，企业的复杂性也不断增加，不同部门之间职责、利益、流程的交错，让包括部分高层管理者在内的很多人不清楚，如果企业某个地方出了问题，到底应当追根溯源到哪个部门、哪个人。这类现象对已深入到企业每个角落的IT产品、IT服务也是如此。早上ERP登录不上去了——这究竟是网络问题，还是ERP问题，或是数据库、服务器出错了？IT部门到底应当找哪个供应商解决问题呢？ 当我们把眼光转向SOA时，1样的问题出现了——当利用由于1个根本性的故障而被迫终止的时候，应当由谁来负责接听并处理用户的紧急求助？目前SOA已步入实行的纵深阶段，但是，近来国外的1系列SOA实行案例表明，曾备受肯定的SOA架构正暴露出其架构的固有缺点——当基于SOA的服务管理到达1定深度时，目前的SOA管理策略在服务故障的追根溯源方面力有未逮，这1现实对全部SOA架构和管理理念都提出了严峻的挑战不满拆迁方案如何申诉。国内SOA用户应当对这1动向保持足够的警惕。谁该为故障负责分析师兰蒂·海福纳认为，曾被广为称赞的SOA的架构特性正在暴露出它的固有缺点——目前，大部分利用了或正在利用SOA架构的公司和组织对“应当由谁来负责响应故障求助”这1问题困惑不已。从目前的状态看，恍如总是能找到这样或那样的团队负责提供利用故障服务，但是最后的结局常常是所有益用相干的开发团队都被扯进来，围绕纠缠不清的责任问题1筹莫展，问题的根源却无从确认。SOA架构具有太多处于移动状态的组件，因此，顺藤摸瓜找到服务故障产生的根本肇因其实不是1件容易的事情，更何况与此同时SOA还是1个由多个相互关联的层组成的架构，这更增加了查错的复杂性。海福纳认为，目前的大部分SOA管理工具必须进行有针对性的改进以应付这类难堪局面。SOA管理工具必须具有锁定深层次服务管理问题的能力。应当说，现有的SOA管理工具在定位问题的产生方面做得不错，它们大都能在问题产生时通过1项服务提示CIO，即使故障产生的环境非常复杂。比如在Java、确定违章建筑的标准.NET、消息中间件或是遗留系统接口内部这类环境，这些管理工具仍然能够迅速发现问题。但是，仅此而已。CIO们被告知系统中产生了1个故障，“好吧，接下来问题来了，SOA服务产生了问题，我们该向谁拨打这个求助电话呢？”海福纳说，面对实行进程复杂、需要由多个团队协作的SOA架构中产生的问题，每个团队都会龟缩在各自的阵地中大喊：“这不是我的错——我负责的部分工作得很好！”这明显是CIO们始料不及，却可能得到的唯1答案。SOA管理缺少全局眼光“这是由于每个人的眼界都被限定在他们自己负责的那部分基础架构工作里，而这恰正是SOA架构的特点之1。”海福纳说。那些服务管理到达1定深度的CIO们目前面对的现实状态很不乐观，为了解决这1问题，SOA的管理策略和解决方案必须重新进行调解，以帮助他们解决那些深层次服务管理问题。海福纳认为，SOA管理方案应当从多个方面调解各种服务之间的关联，比如为消息添加更多的标识。这样1来，服务中产生的问题可以更容易被独立鉴别出来，CIO们也更容易判断应当向哪个开发团队求助。海福纳还指出，通常，SOA管理解决方案的眼界未能上升到全部SOAP界面。但是，即将出现出的新1代管理工具必须站在全部服务界面的高度审视底层的数据库、服务和消息层。“你所购买的SOA管理解决方案，必须能够处理实行复杂服务的SOA底层服务需求。"海福纳说，这1任务可能细致到触及调用Java消息服务、MSMQ、Java RMKI或CORBA等1系列服务，这背后乃至需要1个专门的ESB或利用服务器予以支持。 将“深度”牢记于心对此，海福纳对那些未来希望基于SOA架构搭建利用的CIO们提出了自己的建议。建议之1就是忠告他们充分理清自己的SOA管理策略。他认为，在CIO开始考虑该选用那种SOA管理工具之前，应当首先弄清楚你打算怎样做好SOA管理。CIO们将不能不深入了解各种技术，了解自己企业将要实行的SOA管理将会复杂到何种程度，了解SOA解决方案是否是能够帮助自己管理跨技术平台的服务和了解SOA管理方案是否是能与现有SOA的复杂度匹配起来。另外，1个称职的CIO必须站在全部SOA管理全局的高度，着手建立深度SOA监督和管理机制。这套机制应渗透到架构设计、服务组件和服务接口背后的1切细节当中。总而言之，在寻求任何SOA利用解决方案时，CIO们必须将深度服务管理的理念牢记在心。(end)资讯分类行业动态帮助文档展会专题报道5金人物商家文章