ITPub博客

首页 > Linux操作系统 > Linux操作系统 > SOA方法学(二)

SOA方法学(二)

原创 Linux操作系统 作者:isoa 时间:2009-01-08 09:07:11 0 删除 编辑

  在掌握了业务领域划分、业务流程、业务目标和现有系统后,SOMA按照三个阶段来进行服务分析和设计--发现服务、描述服务和服务实现,如图4-3所示。在SOMA三个阶段的分析和设计过程中,分析和设计人员还需要借助于传统方法中的一些素材,如业务环境和业务用例、IT环境、当前应用或组件的模型和设计等,从而完成与现有业务和IT紧密结合的服务规范和服务设计。在运用SOMA的过程中,这三个阶段并不是一次性完成的,一般需要一个迭代的过程。另外,从企业范围而言,分析和确定的服务模型也有一个演化的过程,并逐渐地精化,越来越贴近业务。

  图4-3 面向服务的建模和架构(SOMA)概貌图
 
  4.2.1 服务发现

  服务发现是SOMA进行服务分析和设计的第一步。服务发现的主要任务,是确定在一定范围内(通常是企业范围,或若干关键业务流程范围内)可能成为服务的候选者列表。

  目前有三种方式发现服务的候选者,它们分别是自上而下的领域分解、自下而上的现有系统分析和中间对齐的业务目标建模。

  1.自上而下(领域分解)方式

  自上而下的领域分解方式从业务着手进行分析,选择端到端的业务流程进行逐层分解至业务活动,并对其间涉及的业务活动和业务对象进行变化分析。

  业务组件模型是业务领域分解的输入之一。业务组件模型是一种业务咨询和转型的工具,它根据业务职责、职责间的关系等因素,将业务细分为业务领域、业务执行层次和业务组件。由于企业内部和外部环境的不同,每个业务组件在成本、投资、竞争力等方面不尽相同,因此,每个业务组件在企业发展的过程中战略职责和演化的路径也是不同的,于是由于角度的不同,就形成了所谓的业务组件的"热点视图"。SOA是一种特别强调业务和IT互动的技术。对于面向服务的分析和设计,业务组件模型提供了进行服务划分的依据,而且这种划分的方法可以平滑地从业务视图细化到服务视图。

  端到端的业务流程是业务领域分解的另一个输入。将业务流程分解成子流程或者业务活动,逐级进行,直到每个业务活动都是具备业务含义的最小单元。流程分解得到的业务活动树上的每一个节点,都是服务的候选者,构成了服务候选者组合。业务领域分解可以帮助发现主要的服务候选者,加上自下而上和中间对齐方式发现的新服务候选者,最终会构成一个服务候选者列表。在SOA的方法中,服务是业务组件间的契约,因此将服务候选者划分到业务组件,是服务分析中不可或缺的一步。服务候选者列表经过业务组件的划分,会最终形成层次化的服务目录。

  变化分析的目的是将业务领域中易变的部分和稳定的部分区分开来,通过将易变的业务逻辑及相关的业务规则剥离出来,来保证未来的变化不会破坏现有设计,从而提升架构应对变化的能力。变化分析可能会从在未来需求的分析中发现一些新的服务候选者,这些服务候选者需要加入到服务候选者目录中。

  2.自下而上(已有资产分析)方式

  自下而上的已有资产分析方式的目的是利用已有资产来实现服务,已有资产包括:已有系统、套装或定制应用、行业规范或业务模型等。

  通过对已有资产的业务功能、技术平台、架构及实现方式的分析,除了能够验证服务候选者或者发现新的服务候选者,还能够通过分析已有系统、套装或定制应用的技术局限性,尽早验证服务实现决策的可行性,为服务实现决策提供重要的依据。

  3.中间对齐(业务目标建模)方式

  中间对齐的业务目标建模方式的目的是帮助发现与业务对齐的服务,并确保关键的服务在流程分解和已有资产分析的过程中没有被遗漏。

  业务目标建模将业务目标分解成子目标,然后分析哪些服务是用来实现这些子目标的。在这个过程中,为了可以度量这些服务的执行情况并进而评估业务目标,我们会发现关键业务指标、度量值和相关的业务事件。

  结合这三种方式的分析,我们发现服务候选者组合,并按照业务范围划分为服务目录。同时为服务规约做好其他准备,如通过对已有资产分析进行的技术可行性评估,通过业务目标建模发现的业务事件等。

  关于服务发现示例,请参见本书第13章"SOA体系结构的实例讲解"。

  4.2.2 服务规约

  经过服务发现阶段,服务目录基本形成,但是对于每个服务本身的属性信息依然零散。为了能够将服务作为业务和IT层面互动的契约,服务规约阶段是必不可少的。服务规约阶段的主要任务是规范性地描述服务各个方面的属性,其中既包括输入/输出消息等功能性属性,服务安全约束和响应时间等服务质量约束,以及服务在业务层面的诸多属性,如涉及的业务规则、业务事件、时间/人员消耗等。与此同时,规范描述服务相关方面的关系也很重要,如服务间依赖关系,服务和业务组件间关系,服务和IT组件间关系和服务消息间关系等。

  进行服务暴露决策是服务规约的第一步。理论上所有的服务候选者都可以暴露为服务,但是一旦暴露为服务,该服务候选者就必须满足附加的安全性、性能等方面的要求。企业还必须为服务的规划、设计、开发、维护、监管支付额外的开支,因此,我们会根据一定的规则来决定将哪些服务候选者暴露为服务。

  这些规则包含以下几个方面:

  ·业务对齐。该服务候选者可以支持相关的业务流程和业务目标。
  ·可组装。该服务候选者满足技术中立、自包含及无状态等特点,同时还满足复合应用的相关非功能性需求。
  ·可重用。该服务候选者可以在不同的应用、流程中重用,从而减少重复的功能实现,降低开发和维护的成本。

  基于企业应用开发的经验,我们还可以有其他一些方面的考虑。

  经过服务暴露决策后,层次化的服务目录基本形成。下一步是结合传统的方法学对服务各方面属性进行描述。这里说的传统的方法学是指企业架构,面向对象的分析和设计等。在企业架构方法学的产物中,企业数据模型有助于服务消息的定义,IT组件模型有助于服务和IT组件间关系的描述,企业安全架构有助于服务安全约束规约,企业基础设施架构有助于服务质量的描述。在面向对象分析和设计的产物中,业务用例和系统用例有助于服务消息、服务相关业务规则和业务事件等描述,组件静态模型和动态模型有助于描述服务间关系。

  经过服务规约,服务组件(企业组件)和服务的各个方面的属性被规范下来,它会成为业务和IT层面互动的基础。以后,业务对IT的新需求会体现为服务层面的变更,IT层面的变化会尽量遵循服务规约。在SOA监管的配合下,任何对服务规约的变更都是可管理和可控制的。

  关于服务规约示例,请参见本书第13章"SOA体系结构的实例讲解"。

  4.2.3 服务实现

  经过服务规约阶段,作为业务和IT互动的服务契约已经形成。但是服务契约和IT的现状还是有很大差距的,如和某个服务对应的业务逻辑分散于不同的应用中,分散在不同的地域,某些服务目前主要依靠人工完成,还没有IT层面的实现。

  为了将服务契约落在实地,服务实现阶段通过差距分析,并结合传统方法学完成每个服务实现决策。这其中包括的内容甚多,其主要内容如下。

  (1)现有系统分析:调研现有系统架构,了解架构风格、主要架构元素和能力和架构元素的基本特征;调研现有应用,了解应用主要功能和对外接口,技术实现特征等;如果应用构建已经遵循基于组件开发规范,编制应用已有组件目录;如果应用并没有组件化,将应用覆盖的业务功能和服务规约确定的企业组件进行映射,确定应用现有"组件"目录。

  (2)确定服务分配:通过服务组件和现有系统分析确定的IT组件间差距分析,确定服务组件和IT组件间映射关系。例如,一个服务组件对应一个或多个IT组件,没有IT组件和服务组件对应,没有服务组件和IT组件对应,服务组件和IT组件对应时有能力缺失或不匹配等。经过差距分析,一些服务中介被确定下来去实现服务路由,或消息格式等不匹配现象,一些新的IT组件被确定下来,如实现某业务流程的组件或实现人工服务的组件等。最终,服务组件都被映射到IT组件上,从而完成服务分配。

  (3)服务实现决策:服务分配仅仅确定了需要哪些组件来实现服务,但是并没有实现的策略和技术层面的决策。服务实现决策首先帮助确定服务实现策略,是在现有基础上进行服务包装,还是重新构建,如果重新构建,是采用已经包装好的应用,还是外包,或者自己构建;如果是服务包装的话,有哪些候选方案等。通常服务实现决策和传统的架构决策是关联在一起的。

  (4)服务基础设施设计:服务的功能实现,非功能需求的满足都需要服务基础设施的支持。在进行服务实现决策后,需要根据具体的需求确定服务基础设施的能力,如用于支撑人工服务的人工服务容器,用于支撑服务编排的流程引擎等。

  将服务实现阶段的各种产物和传统设计方法结合起来,就可以开始指导实际服务实现的实施。

  4.3 本章小结

  本章从方法学发展的角度,阐述了SOA方法学和其他方法学间的关系,并通过介绍SOMA(面向服务的建模与架构)解释了SOA方法学的主要内容。在实际的SOA实施过程中,SOA方法学的应用是最重要,同时又是最难掌握的部分。请大家参见本书第13章"SOA体系结构的实例讲解"一章的SOA方法学实践部分,体会SOA方法学应用的技巧。(来自search soa)

 

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

上一篇: SOA方法学(一)
请登录后发表评论 登录
全部评论

注册时间:2008-07-07

  • 博文量
    251
  • 访问量
    296194