浅谈SOA.

    最近因为系统的扩大,发现以前的软件实在是越来越难维护,每次都要业务经理给我讲清楚业务流程,
我在给程序员讲清楚相关的业务流程,然后才可以进行开发维护.以前的项目经理没有留下任何文档,都要
我来理清业务,书写文档等事情.头大之余在网上看到了SOA,这里谈下自己对SOA的理解.
    SOA实际上是一个体系结构,概念在很多网上都可以搜索到,这里就不粘出来了.按照我的理解SOA实际
上就是将一个程序划分给多个服务,分别来处理不同的业务.例如:一个公司有财务部,业务部两个部门.按
照以前我们开发会创建一个数据操层,一个业务层,一个表示层(最简单的三层).如下图:

图1
需求提出了,因为公司的扩大我们需要将财务部的操作外包给一个公司,业务部的操作外包给另一个公司.如下图:

图2
问题出现了两家公司有牵连的地方了,需要做系统整合.按照以前的做法大家坐一起开会探讨dll的接口,然后回去开发,过段
时间系统整合,大家再坐一起在开会探讨新的dll接口,回去开发......好的问题解决了.
需求又提出了,公司改革将财务部成立为一个公司,业务部成立为一个公司,将财务和业务彻底分开了.问题出现了,现在财务
公司不希望我的一些资料让业务公司知道,而业务公司也不希望他们的一部分资料要财务公司知道.那么我们就不能做成一个
软件了.
SOA提出了一个解决方法.财务公司研发自己的软件提供服务的接口,业务公司研发自己的软件提供服务接口.财务公司如果想
要业务的部分数据直接访问业务公司提出的服务接口就行,业务公司同理.如图3:

图3
问题解决了.如果业务公司更加庞大再分出第二,三家公司,我们也不害怕了,只需访问相应的财务接口变解决了一切问题.
    最后沿用网上有关专家的一段话:SOA 是一种 IT 体系结构样式,支持将您的业务作为链接服务或可重复业务任务进行集成,可在需要时通过网络访问这些服务和任务。
小弟知识有限只能理解到这么多,希望大虾们知道一下,谢谢!
posted @ 2007-10-25 11:11 H2O、winnerzone 阅读(1586) 评论(9)  编辑 收藏

  回复  引用  查看    
#1楼 2007-10-25 11:26 | 非我 [未注册用户]
你说的是soa最概括的表现方式,soa真正的问题在于这些服务的域的划分,接口的设计,通讯系统的架构等等,虽然soa的概念很好理解,但恰恰细节决定soa的成败……
  回复  引用  查看    
#2楼 [楼主]2007-10-25 11:40 | winnerzone      
@ 非我
原来SOA的真正成败是在内部细节之处.感谢非我给我的指引.
  回复  引用  查看    
#3楼 2007-10-25 12:29 | zdg1977 [未注册用户]
不理解
  回复  引用  查看    
#4楼 2007-10-25 12:30 | zdg1977 [未注册用户]
不理解你们的业务经理为什么不亲自和程序员讲清楚相关的业务流程.


  回复  引用  查看    
#5楼 2007-10-25 13:13 | 半山旅客      
.....
  回复  引用  查看    
#6楼 2007-10-25 13:16 | Jeffrey Zhao      
SOA的这些东西其实很容易理解,但是关键在实施上。
在事实上,理论和技术上其实都不能算是成熟。
  回复  引用  查看    
#7楼 [楼主]2007-10-25 14:16 | winnerzone      
@Jeffrey Zhao
恩,有同感,不过毕竟SOA是在完善的.
  回复  引用  查看    
#8楼 2007-10-26 09:34 | bighope2 [未注册用户]
.................................
感觉soa就是协议,其实没有帮你把系统完善,它也只是一个接口规范而已,看你怎么用了。
  回复  引用  查看    
#9楼 2007-10-26 21:10 | adaiye [未注册用户]
--引用--------------------------------------------------
zdg1977: 不理解你们的业务经理为什么不亲自和程序员讲清楚相关的业务流程.


--------------------------------------------------------
应该是因为跟一个人讲比跟一群人讲简单得多了!  嘿嘿
  回复  引用  查看    
#10楼 [楼主]2007-10-29 13:38 | winnerzone      
@adaiye
@zdg1977
并不是这样的,毕竟每一个人都有自己的职责,我们的经理是业务经理,他如果和程序员直接讲业务流程:
第一,浪费时间比较多.
第二,程序员不一定能理解.
第三,业务经理并不是项目经理,他没有职责要每一个程序员搞懂业务,他的职责是告诉项目经理业务上应该如何增加或者修改某些业务需求.

标题  
姓名  
主页
Email (只有博主才能看到) 
验证码 *  看不清,换一张
内容(请不要发表任何与政治相关的内容)  
  登录  使用高级评论  新用户注册  返回页首  恢复上次提交      
 
另存  打印
最新IT新闻: