SOA到底是什么?
SOA到底是什么?当大家对SOA开始有所了解后,往往有种雾里看花的感觉,看上去很美,可就很难摸透和落地。业界有些人把SOA说成是解决业务问题而不是技术问题,也有些人把SOA看成是解决IT资产的复用和管理问题,当然更多的人还是从心里把SOA当作新的技术架构。那到底我们应该建立怎样正确的SOA全景图呢?
SOA从概念到实践已经有了10多年的时间,随着技术本身的进步和应用需求的发展,SOA肩负的时代使命也变得愈加清晰起来。简单来说,SOA是新一代的企业应用架构,它通过对业务、技术与管理这三个维度的架构模型,统一解决我们企业应用面对的挑战。具体来说,首先SOA通过业务维度的构件化业务模型对业务进行模块化设计和流程梳理,从而在业务维度至上而下打破应用系统的障碍,形成企业业务服务的共享;其次SOA通过技术维度进一步对流程、服务及具体实现的剥离和标准化,将应用的信息、流程和交互进行了更加有效的逻辑梳理,从而在技术上打破各种现有技术带来的障碍,实现应用在各层资产(信息、流程和交互)的标准化和最大化复用;最后SOA通过从管理维度上提升对于服务的监控和策略管理从而为IT和业务层面带来全面的管控和治理能力。SOA以统一的架构解决了我们面对的业务、技术和管理的应用问题,从而带来了业务上的灵活性,技术上的高效率和管理上的可治理。
众多平台厂商、开发集成商和企业用户都希望可以随着这次SOA的大潮,加强自身的竞争优势,从而提升业绩和赢得更多的市场。
如何建立良好的SOA体系?
建立良好的SOA体系需要从我们自身的发展现状和需求看起。我们不难发现,欧美国家的业务和管理流程通过这几十年下来已经相当的成熟和稳定,应用内的需求变化相对较少,应用内的业务操作也都已基本稳定。而随着部门和业务整合的需要,则更加需要企业级跨部门的流程改造和流程管理。而中国的企业客户的现状却很不相同,我们还处在信息化的快速发展阶段,我们中国客户的各种应用还在通过一期、二期、三期的不断建设过程中发展成熟和逐步稳定下来。因此也注定了中国客户的SOA实施策略和SOA体现的价值会和欧美有较大的不同。中国客户需要通过SOA更多地解决应用内的服务构造、服务再造和服务稳定,同时借助SOA的架构技术和标准达到各种业务模块间和应用系统间的互联互通。
从下图IDC的统计分析可以看到,中国客户已经从概念的接受到局部的实验,有一些行业的领头羊企业更已开始进入到全企业规划和部署阶段。我们所接触到的绝大部分的企业,无论是金融行业、电信行业还是电子政府、制造、能源等都已经走到了实践SOA的道路上。并且,他们也不再轻信SOA的一种实施策略可以包打天下,而更多地从自己的处境和想要解决的问题开始,寻找适合自身发展的SOA实施策略。
应该说,要想在中国发挥SOA的最大效用,把SOA用到实处,就必须建立符合中国企业发展的正确的SOA体系架构、技术规范、业务模式、开发方法、治理策略和实施路线图。目前中国客户期望SOA解决的问题不少,有技术架构和规范的,也有业务开发模式和管控治理的,我们需要一次为基础梳理出需要解决问题的轻重缓急。在有明确建设目标的前提下,规范和标准化企业统一的SOA架构和工具平台,并通过分步实施的策略逐步在实际的项目中建立起行之有效的开发方法论和组织级共享的各类基础构件库和业务服务库。这样就可以依托SOA的时代大潮,走上良性健康发展的道路。
如下图,就是普元提出的建设SOA体系的总体应用架构的规划模型:
SOA应用架构模型从业务、技术和管理的三个维度,实现了三者矛盾的有机统一体。
首先是应用的业务逻辑,通过业务构件化的模式可以自顶向下从企业的业务规划蓝图开始到梳理业务流程,再到业务领域功能和业务逻辑,直到基础技术构件;当然也可以自下而上从平台提供的或是组织积累的基础技术构件开始,在项目中不断组装出更粗粒度和共性的业务领域构件,直到组装出我们的业务流程。这两种方法相辅相成并不矛盾,自上而下的方法是在业务规划明确和清晰的领域使用,而对于那些还很模糊的业务域则更多采用自下而上的方法,通过项目实践来积累各个层面的构件。所以构件化的业务模型,就是把业务分层的过程。有了这样的模型以后才可以说达到了更佳的业务专业化分工和业务需求的灵活应对。
接着就是应用的技术架构,同样也是通过技术分层的架构方式来对应用的各层资源进行分层解耦和规范标准化。SOA与以往不同的技术架构在于把具体的构造技术与服务及流程的分离。举例来说,具体构造一个业务逻辑的时候并不局限于一种实现技术和语言,既可以用现有的Java技术,Spring技术,C++技术等,也可以用普元提供的高效的图形化逻辑组装开发技术。这些都在构件层解决了对于各种实现技术的支持。到了服务层则与构件层的具体逻辑实现和实现技术无关,通过SCA、SDO等技术标准实现了企业应用的服务松耦合、服务标准化、服务灵活装配和服务资产管理。应该说SOA的五层技术架构在企业的整个组织层面实现了‘人’、‘流程’和‘信息’的解耦、标准化、灵活复用、动态配置和管控治理能力。
最后则是应用的管理框架。在上述SOA的应用业务逻辑和技术架构的模式下,企业需要有手段和工具能够持续不断的监控、治理、优化其业务逻辑与应用资源。因此就有SOA应用架构的管理纬度来承担此项。通过一个服务的管理框架,监控、治理到业务逻辑与应用技术的各个层面,比如应用技术上的数据操作、构件操作、服务操作、流程操作等等,比如业务逻辑上的运营效率、绩效管理、风险管理、运营策略等等。当然应用的管理框架也是一个动态可扩展的框架,可以不断把各种IT和业务的策略加入进来,从而达到不断提升业务和管理水平的目的。
SOA的实施全生命周期
有了SOA的应用架构之后,我们又怎样把这个能力融入到具体的应用当中去呢?也就是如何通过一个生命周期,应用和服务能够从无到有和成长消亡?要知道资源和服务都是有生命的,它们都会经历孕育、诞生、发展、和消亡的整个过程。如下图,就是普元提出的SOA的实施全生命周期模型:
在介绍这套生命周期的模型前,我们先看下埃森哲CTO最近的一个观点:“现在如果说我没有足够的业务构件的时候,我绝对不会采购ESB的。”正如他所言,如果违背了生命的客观规律,那就变成了一种随波逐流的投机行为。我们有些客户也采购了ESB,但是却基本没有用起来,ESB在那里空转。SOA不是要往脸上贴金,而是要确实知道企业采用SOA的目标是什么?策略和愿景是什么?业务规划蓝图是什么?流程如何梳理?业务逻辑如何构造?最终了解这些之后,需要采用相应的技术平台来帮助在应用实践中不断构造业务服务,不断构造业务流程,并在应用实践中稳定这些构造出来的服务和流程、复用这些服务和流程。当业务服务和业务流程积累到一定程度时,我们就需要在组织级管理它们,上图模型中的运营和管理的第三个阶段将开始发挥作用,我们的服务和流程在企业范畴内就会更为有效地共享和被管理起来,它们的价值也会更大程度地被显现出来。
所以了解了这样的一个SOA实施生命周期的时候,就会知道应该从哪里开始。有了这样的一套方法的时候,我们就知道应该选择怎样适合的平台来承载,来帮助我们的服务、流程和应用的开发和运行。
企业计算架构的发展推动业务与创新
SOA似乎正代表着新一代的企业计算架构,也代表着新的先进的软件生产力的方向,它的高效、灵活和管控能力是我们的价值诉求。
让我们再来了解下历史,以更加明白现在的处境和未来的趋势。
我们可以看到企业的计算架构已经发展到了第四个阶段。对于我们现在司空见惯的在银行业的通存通兑的业务模式往往在二十多年前是不可想象的,这正是当时的计算架构所限;对于我们想在司空见惯的24小时的在线服务往往在十多年前也是不可想象的,这也正是当时的计算架构所限。可见我们现在看似平常的业务功能由于计算架构的问题而带来了业务发展上的限制。现在新的问题又来了,我们希望专业化社会分工,不同的开发商提供的CRM、HR、ERP和各种业务系统都可以协同工作,但是目前不同的软件模块间却做不到无缝地协同工作,这也正是我们现在架构带来的问题。所以很明显SOA架构的诞生,正是要让我们更为创新新的业务模式的推出成为可能。
让我们一起期待和努力,一个更为专业化分工、高效协同和标准化运营的竞争力社会的到来。我们也期待更多业务的创新能够在SOA的计算架构下不断地涌现出来,把我们带到一个崭新的世界。
原文出处:http://gocom.primeton.com/blog10731_6.htm
我们一直都在努力坚持原创.......请不要一声不吭,就悄悄拿走。
我原创,你原创,我们的内容世界才会更加精彩!
【所有原创内容版权均属TechTarget,欢迎大家转发分享。但未经授权,严禁任何媒体(平面媒体、网络媒体、自媒体等)以及微信公众号复制、转载、摘编或以其他方式进行使用。】
微信公众号
TechTarget
官方微博
TechTarget中国
作者
相关推荐
-
事件驱动框架和SOA在空军的应用
空军正在利用SOA来改善数据共享,并实时跟踪战机,美国空军机动司令部的Michael Marek解释了企业可从中学习的经验。
-
揭秘New Relic APM技术细节
New Relic应性能管理(APM)套件主要用于Web软件开发。它允许用户在面向服务的架构(SOA)上跟踪关键事务性能,并且支持代码级别的可见性来评估特定代码段和SQL语句对性能的影响
-
仅凭SOA和云无法解决业务数据管理风险问题
SOA和云可以是某些恼人问题高效的解决方案;这一点我们已经知道了。但是也要记住它们并不是所有事情的直接答案,特别是当你的问题是业务数据管理风险,而不是技术问题时。
-
如何避免云计算与SOA冲突