谈面向服务的组件和模块化


最底层是基础硬件设施和数据库服务。在底层的各种业务使用的数据库中,数据库本身可以是独立和分布式的。数据库之间不应该直接建立太多的数据交互和传递。具体的数据同步和交互也需要注册到ESB服务总线上,按一定的规范标准提供数据服务。


在ESB企业服务总线上有两类服务和引擎,一类是提供基础的技术架构和服务的引擎,一类是提供业务SOA服务的引擎。在快速软件开发中我们强调的权限建模,流程建模,组织结构建模,报表,图表和数据服务等都可以抽象为标准的技术类服务引擎。这些引擎可以让我们快速的搭建一个业务软件的开发平台。另一类是涉及业务的引擎,如采购服务引擎,库存服务引擎,销售服务和信用服务引擎等等,这类引擎是对常见业务的通用规则的抽象,同时又需要考虑在不同场景下使用时候的可配置性和可扩展性。


当业务都已标准的SOA服务暴露出去后,我们看到可以通过业务流程编排将我们提供的各种业务SOA服务编排在一起,完成一个完整的业务操作和流程。一个完整的业务流程正是各种SOA服务和引擎的编排和组合。在流程编排过程中我们还可以设置各种业务规则,建立分支,因此在这里是完全可以再抽象出一个独立的业务规则引擎。


SOA的服务概念要落地,需要借助于面向服务的架构模型SCA,SCA是基于SOA思想的一整套开发和部署规范。原来我们实现SOA的时候一般是通过 Web Service将服务暴露出来,也就是说仅仅是实现到数据层和业务服务的组件化和可重用。在这里我们的看法是随着SCA的发展,一个完整的业务服务应该是是垂直切分的,即从UI->服务->数据,提供一整套的复用。至于在前台它就是可以很独立的符合某种标准和规范的UI Part,这种面板可以很灵活的在Portal中进行配置和组装。如果我们的服务不到UI层,我们依然无法解决重复开发的问题。

发表评论

电子邮件地址不会被公开。 必填项已用*标注