＋设为首页 ＋添加到收藏夹
一家公司把业务流程与应用功能分解成服务的能力,将决定它能够获得什么样的灵活性与可重用性,最终决定soa项目的成功程度.
丹麦银行（danske bank as）在构建soa方面的开创性工作已到了非常深入的阶段,现在,它的大型机与应用服务器发布出来的服务有1000多项.但这家总部设在哥本哈根的银行却发现自己落入了让人沮丧的困境.这家银行的首席架构师claus torp说: “服务太多了,我们找不到它们.”
这个问题有可能让soa的主要优点之一 重用化为泡影.不得已,丹麦银行开始着手改动服务的概念,改进服务中心库,并制订了执行最佳实践的管理流程.结果把服务数量精简至140项,这大大提高了可管理性.
如果你深入分析soa方面的几个开创者,就会发现丹麦银行所采取的措施是公司能够重复使用代码.提高开发应用的速度与效率.并且最终节省资金的关键所在.但这并非易事,同是,实施的先后顺序也很重要.如,sun公司曾构建了注册中心（registry）,还成立了一个架构审查委员会.但it部门只是现在才回过头去,对sun的80到100项web服务进行比较认真的审查及分析.
sun的it主管karen casella建议,开始踏上soa之路的公司应当首先分析业务需求,然后确认需要哪些web服务.她说: “我们吃过苦头才明白了这个道理.我们还没有完全弄清楚实施soa需要什么,就建立了一部分基础设施.”
定义服务是关键
公司要弄清楚哪些业务流程可以转化成服务.认真设计及定义服务,并且学会区别服务与组件.
丹麦银行开始构建标准接口以发布遗留程序时,它把服务定义为“一项功能”.如今它在较高的层面来描述服务: 即从逻辑上分组的功能与数据,譬如“顾客”或者“账户”.该银行的140项服务每一个都由大约10个“操作”或者组件组成,这些实际上就是粒度更细的服务.目前共有超过1365个操作.丹麦银行估计最终会有250项服务.
torp说,一家公司把业务流程与应用功能分解成服务的能力将决定它能够获得什么样的灵活性与可重用性.
丹麦银行利用建模工具来设计功能模块与业务流程的逻辑图（logical map）.然后,它把业务流程与服务进行匹配,确保自己解决了所要解决的问题.
torp说: “大量正向服务的开发工作就是为了确保,你可以在同样的服务基本模块上运行不同的业务流程.如果你想取得良好效果,就要确保同样的功能只有一个地方在实现.”
首席技术官robert wiseman说,cendant公司的旅行分销服务部门为了确定服务与服务组件的最佳粒度花了相当长的时间.最终确定服务是可以借助名称为rosetta stone的业务领域模型（business domain model）供外部调用的构件,而服务组件如日志功能只是在内部调用.... 下一页