辨明SOA认识的四大误区

日期: 2008-02-24 来源:TechTarget中国

  在今天,竞争激烈、变化越来越快的全球化商业环境中,传统企业观受到严重挑战,如何灵活快速适应变化、创新求变,成为企业生存和发展的头等大事。在业务敏捷性的实践中,SOA正成长为IT促进业务提高的转移范式,从设计原则、架构范式以及技术、标准和产品中实践着它面向服务架构的伟大使命。

  业务敏捷性向业务与IT两个世界发起挑战

  事实上,许多企业都无法实现“业务敏捷”。他们的工作人员各自行动,计算机系统又相互隔离,不能协同工作:一方面是由IT部门负责的信息系统是,另外一方面则是调整IT系统所需要必要时间和成本。受这二者的制约,企业变化要么时机已逝,要么得不偿失。因此,业务方作为利润中心,总是抱怨IT每年都要花很多钱,不仅不能获得良好的投资回报,也不能帮助建立战略性的竞争优势。而IT方作为成本中心,往往怨恨自己没有得到应有的重视,资金不够、加班加点。这种现象的出现也就不足为奇。

  到底应如何看待IT与业务之间的关系?

  首先,业务活动是由业务人员和信息系统共同完成的,业务人员执行人工活动,比如拜访客户、输入订单和客户资料、做出商务决策等等,而信息系统执行各种自动化活动,包括商业逻辑、业务规则、管理业务数据,提供界面连接人员和信息系统。所以IT是业务的一个重要组成部分。

  其次,业务方决定人工活动和自动化活动的需求,管理人工活动,但是他们往往不具备必要的技术能力来建立、维护和运营那些支持自动化活动的信息系统,这些工作被委托给自己的IT部门或者外包。所以IT要服务于企业战略,为业务建立竞争优势,帮助业务快速应变和创新求变。
 
  可见,业务敏捷性首先需要的是一个灵活的业务模式(Business Model),业务自身不灵活,想改变却心有余而力不足,IT 再能干也是干着急。其次,需要IT的敏捷性,也就是说一个当业务改变的时候,那些自动化活动说变就变,随业务的变化而变化,花的时间少,花的人力物力也少。这种IT的灵活性,对IT的所有方面都提出了挑战,从架构、方法论、技术、产品,到过程、成熟度和管控。最后,还需要IT与 业务这对“冤家”之间的有效沟通与亲密合作。

  这很不容易,业务与IT来自两个不同的世界,看世界的方式不同,所使用的“语言”也不同。大多数时候,业务不愿意花足够的时间在 IT 上,反过来,IT也不愿意花足够的时间去理解业务。他们把更多的心思放在技术上,有时候甚至为技术而技术,忘了IT是为业务和战略服务的。 因此,业务敏捷性同时向业务和IT两个世界发起挑战,沟通和协调成为必然。

  SOA畅行业务与IT两个世界

  业务架构描述业务世界:从业务领域、业务组件、业务对象,到业务服务、业务流程、业务规则……IT架构描述IT世界:从应用、数据、集成、安全、基础设施(包括服务器、存储、网络),到IT运营,全面覆盖……两个“世界”共同服务于企业,而如何实现两个世界协作则成为企业战略目标实现的关键!

  SOA正是沟通两个“世界”使命的承担者,它提出了架构管控的概念,从角色、活动、职责,到协作、审批和监管的框架,保证有一个游戏规则来让这些东西真正地服务于企业的战略和目标。
 
  然而,大多数企业对自己的业务模型仍停留在自发状态,缺乏业务方面的严谨企业架构实践,更谈不上业务与IT的沟通,这直接带来两个问题:

  一是业务优化、应变和创新缺乏形式化和数字化的基础,很容易靠感觉办事。这种“拍脑袋”应变策略,往往带来很多问题,有些时候,这些问题的原因被强加到IT的头上,而使IT承担了不应承担的责任。

  二是业务和IT之间缺乏“可追溯性”(Tracability)。在将业务的需求映射到IT的时候,使用模糊的自然语言,容易造成翻译后的失真和变形。同时,细粒度的操作层次所定义的需求,受到变化的冲击大而快。这最终导致业务和IT在进行需求映射,尤其是在需求发生变化时,很难保证好的可追溯性,从而导致业务的需求无法准确地映射到IT,业务需求的变化很难被快速地定位到IT。

  传统模式需要引入新的IT架构范式和抽象层次,从而为企业的业务活动和流程提供多系统相互协作的IT支持,SOA则恰好扮演了这个角色。

  SOA为业务与IT两个世界带来什么?

  SOA究竟在实现业务和IT两个世界的沟通中体现了怎样的价值?笔者认为:

  ① SOA在业务与IT之间增加了一个新的抽象层次,就是“业务层次上的契约”,用来描述不同的业务组件(或者业务对象)之间交互的接口。这就是SOA通常所说的“服务”。

  其中包括功能接口、服务质量约定(Service Level Agreement)和业务策略等。它们是用于组件化地对业务建模,通常其粒度比技术层次上的对象或者组件接口要粗,而业务流程就是通过将这些服务编排在一起得到的。当业务流程发生变化时,有些变化通过改变服务的配置(如业务策略)来完成,有些变化通过重新组装已有服务来完成,有些变化要用到现有服务之外的业务功能,则需要外购或者开发少量新服务,然后重新组装。

  业务组件化建模所得到的服务模型,解耦了业务架构和IT架构,提供了业务架构和IT架构之间良好的映射能力和变化的可追溯性,即在服务定义不变的情况下,业务和IT可以独立地演变,带来很好的灵活性。

  ② SOA建立了一个新的集成架构,负责将遗留系统和新建的系统连通起来,让不同技术世界的服务组件可以相互以Web服务接口为中介来松散耦合地交互。

  这牵涉到各种协议、API、消息格式的转换、服务端点的发现和绑定、消息的路由、服务质量的保证、服务策略的实施等等。SOA继承了过去EAI (Enterprise Application Integration)和MOM(Message Oriented Middleware)的最佳实践,比如“企业服务总线”(Enterprise Service Bus,ESB)作为一种架构风格元素,用于在分布式环境下提供松散耦合的集成基础,但是SOA使用了Web服务,建立在标准和开放技术的基础上,而不是私有的技术、标准和方式。新的集成架构还引入Service Registry,ESB与之合作提供服务的动态发现和绑定。ESB的实现通常会利用已有的消息中间件。

  ③ SOA通常会创建一个数据服务层,集成EII(Enterprise Information Integration)的技术和最佳实践。

  这个集成架构,要确保所有服务和应用在开发之时,能够跟其他的应用和服务集成,不管它们今天是否存在,互联互通、相互集成、“开发即集成”是SOA对技术层面的基本要求。

  值得提醒的是,SOA一个很重要的设计原则ESB是基于“服务”的分布式集成,很多基于“细粒度”的接口和消息集成,并不符合SOA的设计原则,也将导致可能的性能问题。

  ④ 在应用架构方面,新的SOA技术和标准,比如SCA/SDO允许你采用平台和语言相关的方式实现,但是组件实现的服务接口则是标准化的。

  复合应用(Composite Application)建立在其他应用的基础上,通过将来自Portal应用的人工活动、B2B的合作伙伴应用、数据服务和本地业务服务来快速形成新应用。基于BPEL等标准的流程引擎,使用“声明式”的方式来将服务编排在一起,在复合应用中起着重要的作用。这些都是在已有的应用平台上增加而来,比如IBM的WebSphere Process Server支持SCA/SDO和BPEL,它是在IBM的J2EE服务器WebSphere Application Server的基础上实现的。

  我们前面所设计的服务,实现它们的IT组件就表现为一些SCA组件,或者EJB、POJO组件,而业务流程则在IT层次上实现为BPEL或者一些SCA组件。这些服务和流程都有自己基于标准的形式化描述,保存在服务注册库(Service Registry)中。

  ⑤ SOA Governance被用来在整个服务的生命中期中,将来自业务和IT的人协调起来,让他们各司其职,有章可循,相互协作。

  在实现层面,这通常需要借助于Service Registry来管理服务的生命周期,同时,我们需要扩展现有的管理产品,从基础设施、应用和组件的管理,延伸到服务、流程和业务活动和业务绩效的管理。在这个基础上,建立数字化的服务和流程优化策略,从而使得IT可以主动地向业务提供业务优化和调整的支持。

  辨明SOA认识的四个误区

  简单的说,SOA的产生遵循了这样的逻辑主线:业务敏捷性需要一个灵活的业务模型,业务模型需要一个灵活的IT来支持。同时,良好的业务建模,IT与业务之间的对齐和互动变得很重要,所以基于企业架构的实践,横贯业务和技术的SOA管控被用来保证SOA转型的成功。

  一个灵活的IT需要遵循必要的设计原则,比如关注点分离、松散耦合,而这些设计原则结合具体技术形式体现在IT架构中,将会形成自己的架构风格,这当然也由一些架构元素支撑,比如ESB,服务注册库等。这些架构元素多多少少都能够从过去的IT当中找到些影子,但是,它们使用新技术,建构在开放标准和技术的基础上,融合和继承了过去的实践成果,也同时容易产生误解:

  误解一:SOA = ESB

  ESB只是SOA架构中的一个元素,负责转换、路由和服务质量等。看待SOA,应该从业务、技术、管控等不同的角度来看待。

  误解二:SOA = Web Service

  Web Service通常指基于SOAP/HTTP的Web服务,这些服务是实现SOA中所定义服务的一种技术形式。Web Service提供了分布式环境下卓越的互操作能力。

我们一直都在努力坚持原创.......请不要一声不吭,就悄悄拿走。

我原创,你原创,我们的内容世界才会更加精彩!

【所有原创内容版权均属TechTarget,欢迎大家转发分享。但未经授权,严禁任何媒体(平面媒体、网络媒体、自媒体等)以及微信公众号复制、转载、摘编或以其他方式进行使用。】

微信公众号

TechTarget微信公众号二维码

TechTarget

官方微博

TechTarget中国官方微博二维码

TechTarget中国

相关推荐

  • 事件驱动框架和SOA在空军的应用

    空军正在利用SOA来改善数据共享,并实时跟踪战机,美国空军机动司令部的Michael Marek解释了企业可从中学习的经验。

  • 揭秘New Relic APM技术细节

    New Relic应性能管理(APM)套件主要用于Web软件开发。它允许用户在面向服务的架构(SOA)上跟踪关键事务性能,并且支持代码级别的可见性来评估特定代码段和SQL语句对性能的影响

  • 仅凭SOA和云无法解决业务数据管理风险问题

    SOA和云可以是某些恼人问题高效的解决方案;这一点我们已经知道了。但是也要记住它们并不是所有事情的直接答案,特别是当你的问题是业务数据管理风险,而不是技术问题时。

  • 总线技术究竟该不该用?

    曾几何时企业服务总线(ESB)被视为企业IT的核心。今天,不仅ESB受到了比被废弃还要糟糕的攻击,若干开发趋势似乎对更简单的消息总线也发起了质疑。