采用面向服务架构(SOA)中常见的错误易于理解,只要稍加努力,就可以避免这些错误。
忽视这些错误(因而重蹈覆辙)可能导致你为引入SOA而付出的全部努力偏离轨道,并且失去你的优势。下面列举了由Gartner综述的在SOA的实施执行中最常见的十二个错误。
错误一:非理性的SOA扩展
服务太多,还未准备好与应用的商业模式相匹配。这样的SOA环境意味着应用完成后需要再次检查。
这样的环境可能具有服务众多、大量文档以及新工具和中间件丰富的特点,但却缺乏敏捷性和增量软件版本性,或重用性。
错误二:遗忘数据
设计一个服务模型就像设计一个数据模型。在处理过程中遗忘数据易于导致服务性能差,从而影响应用的完整性。
在设计服务时,努力配合基础数据库的设计模型。
错误三: 将SOA留给技术人员
如果把SOA的大部分过程留给企业的IT部门处理,优化软件性能和可靠性的设计服务出发点将面临风险,可能不会完全反应出商业要求。
明确商业接口是跨应用集成或多企业使用的本质所在。
错误四:忽略企业文化障碍
SOA带来的预期优势之一就是增强软件重用性,但是达到这个预期目标是一个很大的挑战。
企业文化障碍会影响SOA重用的效果。例如,如果IT部门患有“非我发明”症(not invented here),程序员、项目领导和架构师就会不信任其它组开发的重用服务,或者只是希望自己去开发整套的解决方案。
“非我发明”症会导致多余的编程工作,多余人员分配以及因缺乏可用资源而丧失机会,这里体现了SOA重用机制的主要障碍。
错误五:做出突然的投入。
许多企业,特别是那些认为在SOA方面起步已晚的企业,容易倾向从先前的怀疑一下子跳跃到突如其来的策略投入。但是,没有做好正确的准备和计划之前,就投入大规模的SOA开发,这往往会导致严重的错误。
因为面向服务是一个长期的阶段,企业应该在进行意义关键的SOA项目之前,多投入理解该项目和培养企业文化。对大部分公司而言,循序渐进才是可取的方式。
错误六:错误的起点
最常见的错误起点是遵循订购服务的第一个用户的商业需求。例如,如果服务是一个面向用户的应用程序,你可能设计的工具符合他们对数据的需求。
然而,这样的设计过程可能最后会生成出和用户接口一样多的服务,常常导致服务多余并持续增长的问题。
更加统一、系统化和有效的方法是围绕应用程序的商业过程或数据模型来设计一系列耦合的信息服务。
错误七:误以为每个人的想法都与你一致。
SOA起源于一种用于先进分布式系统的技术设计模式。现在SOA远是编程社区之外的热门话题。在适应商业通信时,我们要考虑并认同这些各个层次上的差异。
对于程序员而言,SOA是一种分布式计算的形式,其功能块可能可以运用于其它应用程序。
对于软件架构师而言,从另一方面说,SOA起到翻译的作用,消除了不同应用产品之间的障碍。
对于首席信息官而言,面向服务是一种未来投资。代码重用意味着减少开发新应用程序的开销和时间。
不过,对于首席执行官而言,SOA可以有助于IT更好地响应商业需求,并且适应竞争激烈的商业变化。
错误八: 选择独裁以反抗无政府主义
独立的IT项目、组、部门和领域通常都有自主的渴望,可以把这看作“无政府主义”,因为由于这样会导致一个大企业里不能实行共享目标。
与这样的无政府主义的另一种极端是独裁,即部门和项目被强制遵从中央命令。
这两种方法都无法为一个成功的SOA环境提供所需的平衡。
一个结构良好的SOA环境通常包括一个SOA卓越中心(COE),包括所有的早期参与者以及独立项目之间或者企业内部不同部门之间的协同合作。
卓越中心还要将对内部过程的参与者造成不必要的干扰降低到最小。IT员工在为公司共同目标努力的同时,仍可以保留他们的自主性。
错误九: 低估技术问题
SOA用户必须了解中间件的复杂性。
尽管面向服务越来越流行并且有越来越多的基于SOA的中间件,对于新手来说仍存在很大的风险会做出错误的决定。
为一个小规模、试验型的SOA项目,采用点到点的网络服务连接。
如果配置的服务超过二十或三十个,就用基于中间件的中介:SOA背板。
错误十:允许不可共享的服务数量激增。
共享服务促进了消费应用产品的更快发展,降低开发成本和更加方便维护。
如果每个用户应用程产品的平均服务数量明显超过共享服务的20%或者低于10%,这也许意味着共享服务的数量不是最理想的。
错误十一:过度集中化。
与其强加一个单独的、企业级的SOA背板,还不如采用联邦方法,也许会更可行和明智。公司的SOA计划 划分为SOA域、子公司、商业单位或者部门。
每个域由一名商业管理者和一名技术经理共同管理。每个域都有它自己特定的SOA背板和服务注册表。它由一个域SOA卓越中心提供支持,并按照以政府规为基础来进行管理。
错误十二: 在你准备好之前就推行SOA
一个企业级的SOA需要高层管理者,也许还有董事会的支持。然而,过早寻求管理者对企业级的SOA的支持是一件很危险的事。
到2010年底,只有少于25%的大公司将具备在企业范围内推行SOA所需的技术和组织技巧。
Massimo Pezzini是Gartner的副总裁和著名分析家。
一个成功的SOA项目的最好实践技巧。
*要意识到重用并不是SOA唯一的优点。其他优势包括清晰的软件设计,增量软件开发技术,高效的部署和维护,以及增进了商业模型和软件设计之间的耦合。
*在集成的早期阶段,为设计和管理SOA类型项目开发最优的方法。长期而言,计划投入于特定的基本架构和生产工具,来保证你从你付出的SOA努力中获取了最好的回报。
*在把应用产品向创建快速、随机服务开放之前,需对核心工具的系统设计进行投入。
*从长远考虑,不但要从实际出发,并且要从小规模的项目的过程中获取里程碑性的经验,不断走向成熟。
*确保设计服务时考虑了对商业模型分析,并且只要在合适的情况下,服务反应的应该是商业功能,而不是软件的技术分区。
*促进企业中的分享和合作的文化。
我们一直都在努力坚持原创.......请不要一声不吭,就悄悄拿走。
我原创,你原创,我们的内容世界才会更加精彩!
【所有原创内容版权均属TechTarget,欢迎大家转发分享。但未经授权,严禁任何媒体(平面媒体、网络媒体、自媒体等)以及微信公众号复制、转载、摘编或以其他方式进行使用。】
微信公众号
TechTarget
官方微博
TechTarget中国
相关推荐
-
事件驱动框架和SOA在空军的应用
空军正在利用SOA来改善数据共享,并实时跟踪战机,美国空军机动司令部的Michael Marek解释了企业可从中学习的经验。
-
揭秘New Relic APM技术细节
New Relic应性能管理(APM)套件主要用于Web软件开发。它允许用户在面向服务的架构(SOA)上跟踪关键事务性能,并且支持代码级别的可见性来评估特定代码段和SQL语句对性能的影响
-
仅凭SOA和云无法解决业务数据管理风险问题
SOA和云可以是某些恼人问题高效的解决方案;这一点我们已经知道了。但是也要记住它们并不是所有事情的直接答案,特别是当你的问题是业务数据管理风险,而不是技术问题时。
-
购买应用集成工具可以采取平衡做法
购买应用程序集成工具需要好好看看你的公司需求,知道从供应商里面要寻找哪些关键功能。