梵天的读书笔记 2009-04-20
最近在基于公司研发的SOA平台上做一个项目,最终目的是将全市的几个业务部门业务库的数据整合为一个共享库,于是大家又按部就班的开始数据抽取,清洗,转换,整合的工作。可是等一下,不是基于SOA平台吗?解决信息孤岛,整合各部门应用不正好是SOA的基本目标吗,有了SOA,服务一开放,数据不就是大家的了吗,为什么还要数据抽取整合汇总到一个大数据库里?
是的,用户要的就是其他各部门的数据,每个部门的用户都认为只有数据在手上那才真正是自己的东西,你卖你的SOA平台,我要我的共享库,我还能带个SOA的先进帽子,于是公司也心安理得的完成了这笔交易,SOA平台在这个项目中起到的作用仅仅是数据抽取的时候装模作样的调用了一下WebService。
在SOA环境下,各部门的数据以服务的方式开放出来,大家可以自己通过流程设计器写出适合自己业务的流程脚本,比如查询A部门B部门C部门的数据后整合显示,再有什么新的业务系统挂接上来,或者想多查些其他的字段内容,流程脚本一改,界面一加就OK了,数据统计方面就更不是什么难事了,各业务部门把自己统计的视图开放接口,流程脚本跑一遍什么都有了,各业务部门间的协同工作也可以轻易实现。
我们做的这套SOA平台还是不错的,但是试点了几个地方大都没有真正的用起来,基本都是点对点的走一下平台调用一下webservice就结束了,究竟是SOA适用的环境太少了,还是用户的需求跟不上节奏,还是需要我们更多的引导客户?
另外销售部门也一直对SOA平台搞的不是很明白,因此我们研发也决定介入销售与售前的工作,来直接引导客户认识到SOA的作用,使用更好的方式解决业务需求,我们也一直认为SOA并非忽悠,他是个很好的东西,是能够解决实际问题的。