前言:
本文只是作者在对SOA有了浅显认识后进行的学习心得总结,内容肯定存在很多的理解偏差,希望同行能批评指正,并一起探讨,共同学习提高。
对SOA的浅显理解:
以下图说明了产品,系统,模块,功能之间的关系。
系统n |
系统2 |
系统1 |
产品1 |
产品n |
模块n |
模块3 |
模块2 |
模块1 |
功能1 |
功能2 |
功能3 |
功能4 |
功能n |
产品是由不同的系统构成,系统是由不同的模块构成,模块是由不同的功能构成。本文的作者比较愚笨,只能这样机械的理解。
从上图看出,各层级之间的关系都是1:N的,各功能不同,各模块不同,各系统不同,各产品不同。在这种情况我们去选择功能1,功能2,就可以构建一个模块1出来。这样构建一个模块是不是效率就会很高呢?但是我们如果去重复创造出一个功能1,构建模块1所需的过程时间自然就加大了。我们只有利用现有的功能,我们的工作效率自然就提升了。(BTW:好像有点废话,现在谁不知道重用能提高效率)
未来的企业需要的信息化系统?我们谁也不知道!至少在某些领域,有专人在研究它,我们就暂且拿这些已经存在的对未来变化的分析做个自我理解吧。
SOA(面向服务的架构),是目前在产品架构方面讨论的非常火热的话题,它和MVC不一样,SOA重在解决各业务模块,系统之间的关系,而MVC重在解决具体系统设计上的问题。个人在SOA方面的理解如下:
1、 SOA的核心是组件化、松散耦合
2、 SOA的目标是能快速响应业务的变化
组件化,如何将模块组件化?我们去思考一下螺丝和螺帽,它们是有标准的,只要复合标准,任何螺帽可以套在和它配套的螺丝上。这个是一个比较简单的理解。做为业务模块,如何设定一个标准,让它能够组件化?我们暂且考虑简单一点,其实就是功能的使用和数据的展现:
1、 如何让用户能快速的获取到能操作的功能?
2、 如何能将数据快速的展现?
我们以“待办工作”(因为大量的业务系统可能都存在待办工作)为例进行分析,待办工作主要是纪录当前用户需要办理的工作,将它组件化后,在不同的平台,不同的业务系统之间就可以相互应用了。那么如何在不同的平台,不同的业务系统之间实现“待办工作”的应用呢,我们要从以下方面考虑:
(注:这里我们暂且不去考虑不同平台,不同系统之间的耦合时需要解决的统一目录,单点,权限等问题。)
1、 待办工作的数据结构
Ø 基本:待办人,待办标题,阅读标志
Ø 扩展:待办来源,待办信息发送时间,待办紧急程度
2、 待办的存在消亡:
Ø 生成待办
Ø 更新待办
Ø 删除待办
3、 待办展现的要求:
Ø 全部待办信息
Ø 根据个人待办信息
Ø 根据某时间段内个人以及全部待办信息
Ø 根据阅读标志显示待办信息
Ø 根据待办来源展现待办信息
Ø 根据紧急程度展现待办信息
Ø 展现待办对应文档的详细信息
我们将待办的存在消亡和待办的展现里面涉及到的全部看成是服务,这个时候,组件化的思路就有了。
如何去快速响应业务的变化?对于变化,作者的理解是我们能掌握住有规律的变化,但绝对掌握不了未知的变化,因为它是创造出来的,而不是推理出来的。我们无法避免业务系统的变化,业务的变化必然导致程序,架构的变化,但是我们要努力地减少系统重构的过程,新增加的功能以插入的方式介入。(BTW:这一段好像有点唐僧)
当然,围绕着这些功能,模块,系统,我们还必须提供一套完整的策划,运维,实施机制去不断的改造,以应对不同的市场要求,如下图所示。
策略和规划 (定期的) |
服务工程 (项目实施) |
生产运营 (持续优化) |
(未完待续)