结合经验浅谈SOA的剖析(四)
版权声明:原创作品,如需转载,请与作者联系。否则将追究法律责任。 |
SOA对EA的impact
让我们重新回到SOA对EA的impact上面来,总的来说,SOA对EA的四个远景都有着深刻的影响。 业务远景
SOA有助于把功能点分解成多个可维护,可重用的部件,而这些部件又可以分开设计,开发以及维护。采纳SOA也就意味着整个企业的功能点划分是以服务和进程为单位的。这种划分办法能够容许业务远景和应用远景更好的对应起来。如果可以更容易地从业务远景回溯到应用远景的话,那么就更简单地实现功能点的需求变更。这么一个策略也同时便于把业务服务(相当稳定的处理单元)从进程(一个业务模型中快速改变的元素)中分离出来。
把潜在的应用和功能点对应起来同时也是对业务行为监测(BAM,Business Activity Monitoring)的一个更直观的介绍,这个BAM是对业务事件和事务的实时监测。业务进程的提前实现考虑到把BAM的技术和业务进程的执行紧紧的整合起来。BAM交付给管理者的是实时的,关于企业整合的商业智能。
企业的业务进程需求驱动着业务服务的发掘和定义。对此,下图提供了一个高级而简单的算法。
![]() 第一步是创建一个业务模型用以标识业务所提供的基础实体和进程。域和业务需求应该驱动这一步的开展。整个过程的其中某个部分包含了识别一整套的服务,以及为每个进程所提供的服务接口。当一个模型完成或者微调的时候,服务就会基于所有所需服务的共同功能点而进行重组。下一步是把现有的系统和所需的服务对应起来,并同时定义需要创建新服务的需求:
应用远景
在应用远景中引入服务就带出了松耦合的概念。每一个服务都可以单独进行设计,构造和维护。这种做法大大减轻了对整个应用业务的维护工作量。服务的引入,就导致了下图显示的应用的架构。
![]() 这个架构是由异类的服务在服务总线上相互进行沟通而组成的。额外的组件是:
相比较于写一个standalone的应用,健壮服务的设计过程,开发,部署,管理以及维护都需要更高的代价。
信息远景
SOA的实现引入了两种数据级的考虑:
这种分离的考虑充分简化了整个企业的信息策略。在一个SOA的实现中,被企业应用业务暴露出去,和被内外部企业进程使用到的数据模型,是由消息数据字典所定义的,而它与基础数据模型是完全解耦的。不同的服务可以使用完全不相关的内部数据模型(由服务所封装好),只要他们所暴露的数据语义是符合企业认可的数据字典语义。
由于消息数据字典通常都比基础数据模型简单很多,因此获取常用的消息语义也通常比统一基础数据模型来的容易多了。
技术远景
它其实是建立企业级服务的基础。它提供了一致策略的基础和服务开发和维护的管理。SOA通常需要开发一套基础设施,而这套基础设施是被很多为了满足各种各样功能需求而交付的服务所共用的。在一个企业组织里面,对所有服务的可操作性支持能力只需要实现一次即可。
下图显示的是一套为SOA实现提供企业范围的服务的基本设备(基于上面提到的服务生命周期需求)。
![]() 这些设备提供了在应用范围内任何服务所需要的共同支持。上图其实包括三个主要部分,这三个主要部分又致力于三种技术平台组件:工具,基础设施,和运行期支持。工具组件包括工具,进程,方法,和模式(用以设计,开发,装配和测试服务和基于服务的进程)。基础设施组件包括对服务运行期的基础支持,由以下几个方面组成:
运行期组件主要负责对SOA的额外支持,包括以下两个部分:
下转“结合经验浅谈SOA的剖析(五)” 本文出自 “jayenho” 博客,转载请与作者联系! 本文出自 51CTO.COM技术博客 |






jayenho
博客统计信息
热门文章
最新评论
友情链接