ITPub博客

首页 > Linux操作系统 > Linux操作系统 > 规划 SOA 参考架构(2007年12月04日)

规划 SOA 参考架构(2007年12月04日)

原创 Linux操作系统 作者:tigerhsiao 时间:2009-04-21 10:59:17 0 删除 编辑
:这阵子参与编写一本专为下个月在上海的 BEAWorld 大会所准备的 SOA 专刊,因篇幅关系,部分内容无法纳入,在此将其以博客形式发表。

SOA 参考架构 (Reference Architecture) 是一个框架,使各个项目都有一个遵从的依据,借以促进一致性、最佳实践典范,和标准化。参考架构并不受限于目前的 IT 现况,而应该针对一个经过深思熟虑的愿景目标,可以说是 IT 指导未来所有的新开发工作,借以实现该目标的参考依据。一般来说,2-3 年的规划,是一个比较合适的涵盖范围,既能提供足够的时间来达成面向服务的转型,而又不至于过于长远而虚幻。因此,参考架构提供了一个沟通目标愿景的方 法,协助部门和角色各异的 IT 人员,逐渐朝向该目标会合。

高效的 SOA 需要采用新的方法来对待 IT 基础设施,并且根据个别企业的需求来量身定做,并将服务基础架构、共享的技术服务、安全服务,以及信息/数据、和遗留系统访问服务等,全部定义在内。

为了满足 SOA 的要求,所有公司都需要 SOA 参考架构和路线图,来指导部署一套能随时间演进、而逐渐丰富的工业级服务基础设施,同时指导对面向服务应用的开发和管理。
此外,企业也需要对参与 SOA 架构的各个个别系统的设计,进行监管,并在适当的地方,建立通用服务,透过协作来发挥更高的效率。对于这些举措,连接端点的标准化(通过建立定义清晰的契约和接口),是达成 IT 系统一致性的先决条件。

SOA 参考架构指导所有实施 SOA 的各个项目,能共同朝向企业级服务,和 SOA 基础架构标准方向的集中发展,尽早使企业从中获益。换句话说,参考架构规划的重点,在于开发一个特定于某个企业需要、切实可行的路线图,以填补当前和愿景 目标之间的鸿沟;评估用于开发、部署和管理、监控的现有系统和技术,定义目标状态愿景,目标参考架构模型。

SOA 参考架构可说是指导 SOA 成功的蓝图,其作用包括:

  • 促进 IT 与业务的紧密配合: 参考架构的制定,以业务驱动力和 IT 目标为出发点,分析 SOA 解决方案能对这些驱动力带来多大的正面影响,进而为从目前 IT 现况演化到愿景架构,定出实现架构、相关规范及路线图。参考架构因此提供了从业务和 IT 目标,到实现架构间的可跟踪性,是业务与 IT 之间进行沟通的重要媒介,是企业实现业务灵活性、可管理性和变更规划的基础。
  • 协助企业向重用、团队协作和资源共享的文化迁移:参考架构确立了 SOA 架构标准和技术部署的最佳实践,为日后各个 SOA 的实施项目,订立架构遵从性的度量标准和指标。

参考架构并非一成不变。在一个新的 SOA 策略与规划迭代中,SOA 的参考架构和规范标准,可能需要针对新的业务、IT 情况,和已实施的 SOA 项目中得到的反馈,进行调整,因此,SOA 参考架构不仅是 IT 模板,也是也描述 SOA 原则和标准的活文档。

我们可以将参考架构的内容,粗分为两大部分:

  1. 对服务建立一套共同的词汇和做法,包括:
    • 服务的正式定义 – 例如服务必须由契约 (contract)、接口 (interface),和实现 (implementation) 所组成
    • 服务的分类(核心业务功能服务,数据服务,展现服务等),以及各类服务的设计原则和建议
    • 接口标准 (JMS, RMI, HTTP 等),建议的接口样式(例如:尽量采用粗粒度、异步的服务调用模式),可靠性要求等
    • 需要遵从的 WS-* 标准
    • 安全策略
    • 服务版本控制策略
    • 服务和数据模型采用规范
    • 服务生命周期定义
  2. 与服务基础设施,例如企业服务总线 (ESB)、业务流程管理 (BPM)、注册库 (Registry)、资产库 (Repository) 等相关的规范,包括:
    • 必须支持什么样的部署配置
    • 必须具备什么样的能力
    • 各个部件的责任
    • 部件之间的耦合关系和原则,应避免的事项,例如,展现服务和业务流程服务不可直接调用数据服务,而必须通过核心业务服务;换句话说,数据服务不可直接与展现服务和业务流程服务有耦合关系
    • 各个部件应支持那些科技和标准(例如:SCA, SDO…)
    • 有哪些安全顾虑需要考虑,如何管理权限
    • 要采用哪些产品

由于在规划服务基础设施参考架构时,需要涵盖几类 SOA 参与者和干系人 (stakeholders) 各自不同的顾虑,包括架构师、程序员、和负责部署、运营、监控的 IT 人员,我们可以采用一个针对服务基础设施参考架构调整过的 4+1 视图(如下),来协助我们分离顾虑,来将不同层面的规范和目标架构一一制定,通过逻辑、实现、部署,和进程等四个视图,配合最佳实践典范和模式,来对参考 架构的各个层面,进行描述和规范,如附图。


图说: 为 SOA 参考架构调整过的 4+1 视图,源于 Kruchten 在 1997 年发表的《Architectural Blueprints – the 4+1 view model of software architecture》


 图说: 服务基础设施参考架构的逻辑视图 (Logical View)


图说: 服务基础设施逻辑视图下的功能视图 (Functional View)


图说: 服务基础设施参考架构的实现视图实例(场景为某电信客户的 provisioning service),描绘所计划采用的产品,以及如何通过这些产品间的交互,来实现解决方案

参考架构的规划过程(如下图),应先起于业务驱动力 (business drivers) 分析,可有助确保目标架构能够支持业务的发展策略和方向,展现 SOA 建设对业务的价值,彰显 SOA 投资的正当性,并获得相关业务部门的经费赞助。以金融行业为例,业务驱动力包括像是:

  • 提升效率
  • 借贷流程优化
  • 呼叫中心优化
  • 增长销售额,并显著超越同业
  • 快速灵活地推出创新的金融商品
  • 扩展客户关系,统合客户数据
  • 交叉销售
  • 依据关系定价的策略
  • 降低成本

这一类的价值驱动。分析业务的价值驱动后,接着考虑各种 IT 目标,以及它们如何支持这些业务驱动力;例如:

  • 从关注各业务线烟囱/竖井式的应用系统,转向专注于跨系统/业务线的流程/服务
  • IT 资产重用
  • 提高跨部门协作的业务流程的透明度

并且应订立评价标准,作为日后考核实现各价值驱动力的指标。接着下来,我们可以根据业务和 IT 驱动力,进一步制定恰当的 SOA 策略,考虑采用 SOA,将对那些业务线,在那些驱动力方面,产生最大的价值,据以订立实施 SOA 项目的优先级别。


图说: 参考架构规划过程


图说: 从业务驱动力和价值链分析,来找出应优先考虑采用 SOA 来协助提升的业务和 IT 能力。
√√ 代表 SOA 项目能产生很大的正向影响,依此类推。

针对各价值驱动力,我们可以参考附图中的矩阵分析方式,从价值链或业务线中的各个主要的职能(纵向),和各个识别出来的业务和 IT 驱动力(横向),对 SOA 所可能产生的正面影响力,一一进行评估,进而挑选出面向服务解决方案最能嘉惠的业务能力,作为首期实施 SOA 项目的切入点。图中的范例只是一个三万尺高空的起点,在真实的情况下,往往会针对范例中某个或某几个得分较高的业务线,往下展开细化,对该业务线中的各个 主要业务能力,进一步进行 SOA 价值驱动力分析;换句话说,价值链分析中的各个职能域,应该自粗到细,逐步钻取、drill down 到适当的深度,才能更精准地确定 SOA 能对哪些要迫切改善的业务能力,带来最大价值。

依据业务和 IT 驱动力,选定了 SOA 策略后。接着应根据企业目前的现况,和未来 2-3 年的目标,进行差距分析,并根据最佳实践典范 (best practices),制定 SOA 发展的蓝图、路线图和指导规范,完成参考架构的规划。接着便可开始根据路线图中制定的项目,以渐进的方式,通过一致的服务工程方法,一个接一个项目去执 行,并在此过程中,逐渐将蓝图中的服务基础设施搭建起来。

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/16186206/viewspace-591117/,如需转载,请注明出处,否则将追究法律责任。

请登录后发表评论 登录
全部评论

注册时间:2008-09-26

  • 博文量
    20
  • 访问量
    51593