|
SOA的架构功用需求分析 X( O' `3 S. \
在简单高效的SOA根底架构的支持下,IT将可以完成“效劳驱动”的愿景,快速推出新效劳,在几乎不中缀IT根底架构的情况下重用有价值的业务功用;使IT与业务需求坚持分歧,响应业务流程的更改,并为用户提供更杰出的效劳。; A, ~3 \/ @9 \$ \7 R
为使IT架构尽可能快地响应业务需求,需求改动架构本身的角色。面向效劳的架构就是提供改动的一种方式。SOA有明白的特征,与目前大多数大公司定义的架构方式根本不同。这些特征完好可以顺应更快的变化,并能加强业务与企业IT之间的协作。
8 W( |. ~+ ]; B) ^4 O" |% c 一基于效劳
6 A* _0 Z g( }$ Y6 w IT通常为了满足一个特定业务范畴的请求而呈现或开展,只思索那个范畴的利益。IT通常都根据项目来投资和创立,目的是处理特定请求,故易呈现功用反复的情况。由于采用“逐一项目”的开发方式,在代码或组件级别来共享功用的传统方法曾经宣布失效。
) P2 Z' U: G9 L 基于效劳的IT方法改动了功用的开发和托付方式。功用被一次性地思索、合成和部署在企业的一切级别中,这降低了本钱,加快了托付,进步了IT顺应变化的才能。除要改动IT投资和管理方法外,基于效劳的方法还请求在功用的打包和部署方式上做出改动。SOA还思索使功用转化为效劳的可能方式,以及这些效劳的管理和监控方法。
9 J1 K! a" W) h, G) O* y. H( d# z. P 二基于标准
, `, b& |3 a4 K6 q( {! @ 传统IT托付的另一个方面是每个项目通常都选取最有利的方法去满足本身需求。这招致了技术增生。当思索如何使树立在这些技术上的应用交流信息时,就会显显露问题。以前像CORBA和DCOM等基于标准的组件模型效果不好,由于缺少执行它们的技术,还可能延缓支持标准的开发,或二种情况都有。更新技术(如XML、Web效劳及UDDI等)为支持重用的、基于标准的SOA奠定了根底,支持这些标准的技术很容易得到,并真正做到了平台中立。
. E$ |0 w5 n D; }4 ]& n0 ]" Z 三企业焦点5 s' B' r0 f, ?! }& O5 K
假设在业务部门内按项目来开发IT,完成企业范围的流程或信息的可视化与管理将变得极端困难。许多机构经过成立企业架构小组或委员会来处理这些问题。这些小组通常只关注技术选择,而没有执行其他建议的权利。除加强管理外,这些小组需求一个机制,从而根据标准方式,按恰当粒度和用户社区可视化程度去定义、配置、监控和管理对企业功用的访问。只需一个构建合理的、基于效劳的且契合正确管理原理的企业架构,才干提供所需求的部署平台。
" Q5 N v6 ^' ~/ f/ ~ 四业务焦点
9 _9 w4 h I# h; r; J. N 在大多数企业中,业务用户需求多种应用去完成他们的日常工作,各个独立的应用是为不同的需求组合而创立的,这又是一个传统IT托付的副产品,会构成糜费工作、增加培训费用、过度依赖专业技艺、反复记载数据和缺乏对全部业务流程的可视性和控制等诸多弊端。SOA的目的为业务在用户可以想象的级别上提供功用,使其日常运用变得易于理解、说明、测试和操作。% I: g$ E9 `9 M* D' {1 ~
五完毕语
3 t! R- e# e" n3 M/ C/ T 在施行SOA战略时,IT并不会“取代和淘汰”现有根底架构,而是将这些应用展现为效劳,供其他业务流程和应用重用,从而降低本钱和复杂性。这就是说,要成功地施行SOA,必需有一个支持在异构环境中执行动态交互的集成层。这个集成层必需思索IT环境固有的“演化”特性:必需支持不时地改良现有效劳,并能随着业务的扩展而快速地添加新效劳,以满足新客户、协作同伴和业务的需求:必需对效劳运用者躲藏效劳端点的更改;还必需自动管理效劳交互。+ Q4 r v1 |0 q r8 }4 Y/ O: h
& b7 }; H# I* E8 \% {: x( d |
|