基于SOA的业务流程分析和设计

日期: 2010-01-04 作者:人月神话 来源:TechTarget中国 英文

  SOA是一直架构模式,更多的是充分体现了业务驱动IT的思路,这和我们在企业信息化规划里面的思路是吻合的。对于SOA的业务流程和需求分析和传统的结构化需求分析,面向对象的需求分析并不冲突。要注意SOA是站在更高的一个层面,具体到了某一个具体的模块或功能的实现仍然是采用结构化或面向对象的需求表达,以明确功能的输入,输出,数据,业务处理流程和规则等内容。

  对于一个全新的系统开发,如果基于SOA的思路,仍然是首先通过价值链分析,一级流程到二级,三级流程的分解从流程中发现关键的业务活动,然后分析业务活动间的关联关系和耦合程度。根据高内聚,松耦合的原则,充分考虑企业的业务和组织机构设置来考虑业务架构的建模。而该业务架构中最重要的就是业务的组件化,需要充分考虑业务和流程进行组件化而不是从设计实现的角度去考虑模块化,这是一个关键点。

  在业务组件化后,接着要做的就是根据流程分析来考虑业务组件之间存在的关联关系,业务组件之间究竟存在什么样的关联,需要传输什么样的数据?这一步是重要的一个分析步骤,通过该步骤的分析后我们发现关联关系会转化到SOA业务建模中的服务视图,而传递的数据和信息转换为SOA业务建模中的数据视图,接着再详细描述服务信息和数据元的定义。

  在通过流程分析后自顶朝下的得到了服务视图和数据视图,然后再返回去结合实际的业务流程来细化流程视图。通过BPM业务流程管理工具和模块进行流程的编排。这个时候编排和实现的流程就是完全由业务驱动的IT实现,接着在讲跨业务部门和系统的通过流程编排实现的IT应用集成到EIP门户中,这就完成了一个完整的SOA需求分析和实现的过程。

  上面讲的是对于一个全新系统的开发基于SOA的需求分析和实现的过程。但是我们往往面临的是已有的老系统的诸多系统基于SOA思想的改造和集成。上面讲的总体方法和思路仍然是适用的,但是我们考虑差别点。

  对于已有系统的SOA改造和集成,往往仍然需要去分析和梳理系统对应的业务流程,但是不需要做全新的业务架构和业务组件的规划。同时在进行流程分析的时候我们看到流程仍然要分解,但是我们只关心和细化和外部系统存在信息交互的接口和流程。通过对这些流程的分析目的就是要发现系统之间的关联关系和接口,已经在关联关系中传递的数据对象。

  对于数据视图的分析仍然是必要的,在对已有系统的改造的SOA集成中,这个时候的数据对象往往已经可以细化到具体的数据库中的数据表和数据视图。数据视图的形成主要分为四个主要的步骤,关联数据分类,数据元抽取,元数据定义,形成实体数据和实体数据关系。

  在流程视图中已经有关联关系,宿主模块和关联数据的分析,在这里通过宿主模块和关联数据名称进行排序,以形成关联数据细化的分类。而对于元数据定义则是对关联数据进行具体的描述,包括对组织关联数据的多个数据元的名称,类型和格式等信息的描述。在一个关联数据可能在多个模块中都可能会使用到,在形成关联数据的数据元时候,需要综合考虑多个模块对关联数据的使用需求。

  服务视图主要是根据前面的流程分析和数据分析,对流程视图中存在的接口和服务调用,通过定义服务的各项属性,描述服务的基本信息和配置信息,以及服务具体的调用规则,为后续服务的设计开发做准备。对于已有系统的SOA集成,则重点是分析已经存在的各中IT应用相互之间点对点存在的接口,将接口转化为服务。对于每个服务的描述重点又是服务编号,服务的名称,提供的系统和模块,服务对应的流程,服务执行频率,同步/异步,输入,输出,服务对应的数据视图,异常处理机制,服务的响应时间和吞吐量等信息。这些信息将是通过各种SOA开发套件进行服务的设计和开发时必须具体的基础信息。

  综上,基于SOA的需求分析重点主要包括四各方面的内容,即关联关系分析,数据视图,服务视图和流程视图,同时以业务的流程分析为导入,最后又以SOA提供的BPM流程编排为输出的完全系统化的分析过程。

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

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

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

微信公众号

TechTarget微信公众号二维码

TechTarget

官方微博

TechTarget中国官方微博二维码

TechTarget中国

相关推荐