CIO该如何应对SOA架构固有缺陷.docVIP

CIO该如何应对SOA架构固有缺陷 CIO该如何应对SOA架构固有缺陷 PAGE / NUMPAGES CIO该如何应对SOA架构固有缺陷 CIO 该如何应对 SOA架构固有缺陷 ? 当我们把目光转向 SOA时，同样的问题出现了当应用因为一个根本性的故障而被迫终止的时候，应该 由谁来负责接听并处理用户的紧急求助 ?对于很多企业领导者来说， 半夜两三点电话响起不是什么好事情这很可能意味着，企业出了事，而且这些事情很有可能不知道该由谁解决。 随着企业规模的逐渐扩大，企业的复杂性也不断增加，不同部门之间职责、利益、流程的交错，让包括部分高层管理者在内的很多人不清楚，如果企业某个地方出了问题，到底应该追根溯源到哪个部门、哪个人。 这种现象对于已经深入到企业每个角落的 IT 产品、 IT 服务也是如此。早上 ERP登录不上去了这到底 是网络问题，还是 ERP问题，或者是数据库、服务器出错了 ?IT 部门到底应该找哪个供应商解决问题呢 ? 当我们把目光转向 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的管理 策略和解决方案必须重新进行调整，以帮助他们解决那些深层次服务管理问题。 海福纳认为， SOA管理方案应当从多个方面调整各种服务之间的关联，比如为消息添加更多的标识。 这样一来，服务中产生的问题可以更容易被独立鉴别出来， CIO 们也更容易判断应当向哪个开发团队求助。 海福纳还指出，通常， SOA管理解决方案的眼界未能上升到整个 SOAP界面。但是，即将涌现出的新一代管理工具必须站在整个服务界面的高度审视底层的数据库、服务和消息层。 “你所购买的 SOA管理解决方案，必须能够处理执行复杂服务的 SOA底层服务需求。海福纳说，这一任务可能细致到涉及调用 Java 消息服务、 MSMQ、Java RMKI 或 CORBA等一系列服务，这背后甚至需要一个专门的 ESB或应用服务器予以支持。 将“深度”牢记于心 对此，海福纳对那些未来希望基于 SOA架构搭建应用的 CIO 们提出了自己的建议。建议之一就是忠告他们充分理清自己的 SOA管理策略。他认为，在 CIO 开始考虑该选用那种 SOA管理工具之前，应该首先搞清楚你打算怎样做好 SOA管理。 CIO 们将不得不深入了解各种技术，了解自己企业将要实施的 SOA管理将会复杂到何种程度，了解 SOA解决方案是否能够帮助自己管理跨技术平台的服务以及了解 SOA管理方案是否能与