软件架构:构建软件架构SOA

     Web服务一种作为炙手可热的技术,应用到企业的IT系统和商业流程之中,并给企业带来直接的经济效益,一直以来得到了国内外企业管理者的推崇。而在近两年,伴随着企业需求的不断变化,一种被誉为Web服务的技术架构,再一次引起业内关注,这就是SOA(Service-Oriented Architecture,面向服务架构)。


  早在1996年,Gartner最早提出SOA的预言,2002年12月,Gartner又提出了SOA是“现代应用开发领域最重要的课题”,并预计到2008年,SOA将成为占有绝对优势的软件工程实践方法,主流企业现在就应该在理解和应用SOA开发技能方面进行投资。

软件架构:构建软件架构SOA_第1张图片
  更好地支持商业流程
SOA并不是一个新事物,IT组织已经成功建立并实施SOA应用软件很多年了,BEA、IBM等厂商看到了它的价值,并且纷纷跟进。SOA的目标在于让IT变得更有弹性,以更快地响应业务单位的需求,实现实时企业(Real-Time Enterprise,这是Gartner为SOA描述的远景目标)。而BEA的CIO Rhonda早在2001年6月就提出要将BEA的IT基础架构转变为SOA,并且从对整个企业架构的控制能力,提升开发效率、加快开发速度、降低在客户化和人员技能的投入等方面取得了不错的成绩。


  由于SOA是在计算环境下设计、开发、应用、管理分散的逻辑(服务)单元的一种规范,这就决定了SOA的广泛性。SOA要求开发者从服务集成的角度来设计应用软件,即使这么做的利益不会马上显现。SOA要求开发者超越应用软件来思考,并考虑复用现有的服务,或者检查如何让服务被重复利用。SOA鼓励使用可替代的技术和方法(例如消息机制),通过把服务联系在一起而非编写新代码来构架应用。经过适当构建之后,这种消息机制的应用允许公司仅通过调整原有服务模式而非被迫进行大规模应用代码的开发,使得在商业环境许可的时间内对变化的市场条件做出快速的响应。


       SOA也不仅仅是一种开发的方法论,它还包含管理。例如,应用SOA后,管理者可以方便地管理这些搭建在服务平台上的企业应用,而不是管理单一的应用模块。其原理是通过分析服务之间的相互调用,SOA使得公司管理人员方便地获取什么时候、什么原因、哪些商业逻辑被执行的数据信息,这样就帮助了企业管理人员或应用架构师迭代地优化他们的企业业务流程、应用系统。

软件架构:构建软件架构SOA_第2张图片
      SOA的一个中心思想就是让企业应用彻底摆脱面向技术的解决方案的束缚,轻松应对企业商业服务变化、发展的需要。企业IT架构环境中单个应用程序是无法包容业务用户的(各种)需求的,即使是一个大型的ERP解决方案,仍然不能满足这个需求在不断膨胀、变化的缺口。对市场快速做出反应,商业用户只能通过不断开发新应用、扩展现有应用程序来艰难地支撑其现有的业务需求。通过将注意力放在服务上,应用程序能够集中起来提供更加丰富、目的性更强的商业流程。其结果就是,基于SOA的企业应用系统通常会更加真实地反映出与业务模型的结合。


  服务是从业务流程的角度来看待技术的——这是从上向下看的。这种角度同一般的从可用技术所驱动的商业视角是相反的。因为服务的优势很清楚,它们会同业务流程结合在一起,能够更加精确地表示业务模型、更好地支持业务流程。相反,我们可以看到,以应用程序为中心的企业应用模型,迫使业务用户将其能力局限为应用程序的能力。


  企业流程(Enterprise Process)是流经企业框架的空气,它赋予业务模型里的组件以生命,并更加清晰地定义了它们之间的关系。流程定义了同业务模型进行交互操作的专门方法。例如,会计可能是企业服务系统的一个组件,但是将发票寄给客户却是一个业务流程。服务被定义用来支持业务流程,因而自始至终地贯穿整个流程:各种服务组件在流程和逻辑实现过程中的装配操作,理解业务流程是定制服务的关键所在。


  有利于企业业务的集成
  传统的应用集成方法,如:点对点集成、企业消息总线或EAI、基于业务流程的集成等,都很复杂、昂贵,而且不灵活。这些集成方法难于快速适应基于企业现代业务变化不断产生的需求。


  基于SOA的应用开发和集成可以很好地解决其中的许多问题。它描述了一套完善的开发模式来帮助客户端应用连接到服务上。这些模式定制了系列机制用于描述服务、通知及发现服务、与服务进行通信。

软件架构:构建软件架构SOA_第3张图片
  不同于传统的应用集成方法的是,在SOA中,围绕服务的所有模式都是以基于标准的技术实现的。大部分的通信中间件系统,如RPC、CORBA、DCOM、EJB和RMI,也同样如此。可是它们的实现都不是很完美的,在权衡交互性以及标准定制的可接受性方面总是存在问题。SOA试图排除这些缺陷。因为几乎所有的通信中间件系统都有固定的处理模式,如RPC的功能、CORBA的对象等等。然而,服务既可以定义为功能,又可同时对外定义为对象、应用等等。这使得SOA可适应于任何现有系统,并使得系统在集成时不必刻意遵循任何特殊定制。


      SOA帮助企业信息系统迁移到“leave-and-layer”架构之上,这就意味着在不用对现有的企业系统做修改的前提下,系统可对外提供Web服务接口,因为它们已经被可以提供Web服务接口的应用层做了一层封装,SOA可以将系统和应用迅速转换为服务。SOA不仅覆盖来自于打包应用、定制应用和遗留系统中的信息,而且还覆盖来自于如安全、内容管理、搜索等IT架构中的功能和数据。因为基于SOA的应用能很容易地从这些基础服务架构中添加功能。所以,基于SOA的应用能更快地应对市场变化,使企业业务部门设计开发出新的功能应用。


  与传统的企业应用集成架构的主要区别在于,基于SOA的企业应用系统使用基于标准的服务,并包括过程/数据服务、编排和组合。基于标准的服务成了应用间的集成点。服务的编排和组合增加了服务的灵活性、重用性和集成性。


  两种粒度实现SOA服务
  可以按基于服务的功能及发送和接收的数据数量来定义服务,如细粒度服务、粗粒度服务或组合服务。


  在SOA中服务粒度有两种相关的意思,即服务是如何实现的,服务使用和返回了多少数据或多少消息。细粒度服务执行了最小的功能,发送和接收少量的数据。粗粒度服务执行了较大的业务功能,并交换了更多的数据。


  细粒度服务是供粗粒度服务或组合服务使用的,而不是由终端应用直接使用的。如果应用是使用细粒度服务建立的,则应用将不得不调用网络上多个服务,并且发生在每个服务上的数据量较少,因而会对对系统整体性带来影响。所以,粗粒度服务的用户不能直接调用他所使用的细粒度服务。然而,由于粗粒度服务可能使用多个细粒度服务,因此它们不能提供粒度级的安全和访问控制。


  组合服务可以使用粗粒度服务和细粒度服务进行组装。数据数量不是粗粒度服务和组合服务之间的区别。粗粒度服务例子,如创建新客户,在这一过程的操作是:需要通过一些外部服务验证对客户进行验证,并在CRM应用系统中创建客户记录。组合服务例子可以是提供一个新的DSL线,这需要一个服务调用来验证订单、创建或验证客户,确认产品库存及为数据线分配资源。


  通过一组有效设计和组合的粗粒度服务,业务专家就能够有效地组合出新的业务流程和应用程序了。

软件架构:构建软件架构SOA_第4张图片
  成就商务自主
  作为面向服务的计算架构,SOA简化了IT的计算环境,其兼容性、互通性以及最终实现的商务自主的能力,满足了高度动态的商务环境(Dynamic Business),实现了IT对业务从数月到分秒的响应。专家指出,SOA的最终价值在于让IT和业务同步,在规划上以面向提供弹性的业务服务为目标。从CIO到负责规划的架构设计师,都需要和业务部门之间有充分的沟通。因此,SOA的建立,将会是一个为期数年的承诺,基础建设和标准必需逐步实施。
  在中间件领域,SOA架构日益成为中间件软件供应商争夺的新焦点,谁都希望自己能够先于竞争对手提供最优的SOA技术实现平台,BEA也不例外。从技术上来说,Web服务、组件技术的采用将有助于SOA的进一步普及;从业务上来说,企业用户要求性价比更高的应用系统,SOA恰恰适应了这样的趋势。


       在美国旧金山举办的BEA第九届技术年会eWorld上,来自全球的BEA技术精英将会在现场尽情体验到BEA的技术专家在现场带来的在BEA WebLogic Platform 8.1上的SOA系统设计模式和最佳实践,即有关如何构建SOA系统的技术准则,BEA要让全球的企业用户的信息系统都能够最大化地享受到SOA带来的商业价值。


       GartnerGroup预计,SOA将成为占有绝对优势的软件工程实践方法,它将结束传统的整体软件体系架构长达40年的统治地位(可能性:70%)。Gartner建议,主流企业现在就应该在理解和应用SOA开发技能方面进行投资。总之,如何把握,如何运用到自身的企业建设中,SOA已经给出了一个很好的基础

你可能感兴趣的:(计算机,软件架构,IT行业,软件工程)