|
锁定老帖子 主题：SOA是旧瓶装新酒吗？
该帖已经被评为精华帖
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2004-09-17
gigix 写道 albert_qhd 写道 谈谈我的理解
首先,SOA要解决什么问题？应该是应用集成的问题。 比如，最早有一个HRM系统，后来公司又上了一个OA系统。客户提出一个需求，在HRM中增加一个员工后，自动在OA系统添加他的帐号。 在没有HRM源码的情况下，有三种方案可以使用 1、轮询HRM数据库。发现新增记录就在OA中增加 2、在HRM的Employee表中增加个Trigger 3、当然，HRM如果提供此类功能的接口就最好了.但很多时候这是个奢望 而SOA呢,好像有点像以前MS提出的Windows DNA架构.每个功能都做成一个可替换的component,通过web service调用.这样的话,再进行集成就方便多了 但SOA这种方案另一个问题就是划分粒度,太大了集成时可能会有问题;而太小了,效率又会成问题.trade-off 我不懂你举这个例子是什么意思。如果OA使用的用户库跟HRM不是同一个，并且OA不提供“增加用户”的接口，管你SOA还是什么A，难道OA那边就会自动加上一个新用户了？ 是我没说明白,sorry 这里有两个问题: 1、HRM如何主动调用 2、OA提供怎么的接口供别人调用 对于第一个问题，按我的理解,SOA应该是个系统架构，应该包括类似BPM的东东。这样的话，你就可以配置一下接口使HRM主动调用。 第二个问题，OA系统提供web service接口。别的系统就可以很方便的调用了 这应该就是SOA给我们带来的帮助 当然，这样的东东对现有系统可能帮助不大，但对未来构建系统会有一定帮助 to firebody:你认识我吗？银行前置、自定义报文格式，这些东西让我感觉很熟悉 |
| 返回顶楼 | |
|
发表时间：2004-09-17
to firebody:你认识我吗？银行前置、自定义报文格式，这些东西让我感觉很熟悉
我怎么会认识你？ 只不过可能我们都做过跟银行对接的接口系统罢了! |
| 返回顶楼 | |
|
发表时间：2004-09-17
引用 其实，如果真的象它所说的那样的话，web service要不要上，也值得探讨。同一局域网内的多系统互通问题，完全可以利用socket通讯，约定交易码，报文。似乎要来的更快些，更何况不是每一个人都很熟悉web service。这种情况在真正应用中也是直接采用socket通讯的居多。WS有必要吗？很值得怀疑。想起WSDL，UDDI，SOAP我就有点头晕。
呵呵，不用头晕，如果这里要用的话，就捏SOAP这块就行了，不用考虑WSDL和UDDI。如果是在同一局域网，确实是没必要用WS的，利用SOAP做通讯协议就是为了能直接穿透防火墙，效率上是有损失的。用Socket工作量稍大一点，但也值得。 回到原题，究竟“SOA是新瓶装旧酒吗?”。 前面有人强调了SOA是架构，gigix如是说： 引用 作为architecture，我也没看到多少有价值的东西，倒像是一大堆我们老早知道的东西攒巴攒巴再改个名。
我也赞同，因为还是没看到SOA提出新的东西来。技术上没有，概念上也没有。 引用 实际上SOA本身的长处是在动态松耦合上，这是和传统组件架构相比较的，比如COM。但如果仅提这样一个概念是不能解决什么实际问题的，Web Service没有流行起来，这是显而易见的。其实更加完整的例子是Sun在99提出了JES，就是后来的OSGi标准（据说这个标准是现在Sun中国研究所的所长宫力提出的，题外话）。
所以后来有人提出了将SOA这种长处和组件结合起来，结合组件结构化的特点，用于开发灵活的系统架构。这方面eclipse是个比较好的实现例子，虽然eclipse的扩展架构不是自SOA始，但它已经覆盖了今天SOA自身所谓的许多内涵。早期eclipse唯一缺乏的就是“动态”能力。所以在eclipse 3中引入了OSGi的底层框架，扩展了这方面的能力。但是一般的人是感觉不到的，因为plugin自身结构没有变化，而只是由框架统一提供了到OSGi的适配器（这方面也可以看出IBM/OTI的功力深厚）。 从这个例子中，我们可以看出SOA的范畴可以收缩的很好，服务的概念被接口所具体化，而框架本身就是SOA的一个具体实现。换个角度，SOA也可以扩展的很大，就是所谓企业软总线的概念（仅仅是概念，恕我见识短浅，还举不出完整的例子） IoC也可以看作是和SOA有所重叠的地方。实际上Howard（Tapestry的作者）在提出HiveMind时就明确的表明这是一个SOA架构，虽然很多人认为就是IoC容器的另一个实现，当然也有人把OSGi当成一个半吊子的IoC容器。另外，Apache avalon被认为是一个典型的SOA架构实现，看看IoC和SOA下面会怎么样吧？ 动态松耦合一直是设计人员追求的目标，也出现了很多为这个目的而产生的技术，SOA是否给出了新的解决方案？如果没有的话，是不是可以说“Web Service、IOC、JMS等等技术就构成了现在这个SOA”？那就成了“新瓶装混和旧酒”了，也没多少意义啊。 |
| 返回顶楼 | |
|
发表时间：2004-09-17
虽然表面看起来SOA框架和IoC容器很相像，OSGi和JMX有重叠，Service和Web Service属一类，但应该还是有所不同之处的。比如同属于对象/组件/服务管理的OSGi和JMX，他们侧重点是不一样的（所以Eclipse选择了OSGi）；SOA框架自开始应该就比IoC容器的针对性更强一些，比如SOA一开始就包含有组件生命期管理的功能，而IoC只是发展了一段时间后才有所涉及（我在IoC板中曾经提出这个问题），其组件概念也显得更加大气，也就是在软件架构中的作用将更加明显；至于Web Service本身已经不是重点所在了。个人以为从发展的眼光看，目前的一些IoC容器将合并有SOA的功能就是说向SOA转变，当然也许还保留那么一些原始的纯洁（正如Ajoo他们讨论的结果，IoC作为工具类未必有很大的作用，请参考Ajoo公理）。
后面还想说什么，只是一下子不知道该怎么表达，想像一下Eclipse，引用Apache WS讨论区里某人的话：你会为这种动态扩展结构的美妙着迷的。 |
| 返回顶楼 | |
|
发表时间：2004-11-08
quote]
动态松耦合一直是设计人员追求的目标，也出现了很多为这个目的而产生的技术，SOA是否给出了新的解决方案？如果没有的话，是不是可以说“Web Service、IOC、JMS等等技术就构成了现在这个SOA”？那就成了“新瓶装混和旧酒”了，也没多少意义啊。 soap的注册，用户先访问注册中心，获得了服务地址之后，就与服务直接交互，这便是动态松耦合啊。 webservice不是万能的，在实时性要求比较高的系统，采用传统的socket通讯方式是最好的，而对于大规模的b2b应用来说，比如一个行业使用一个集成系统来进行分布式计算，许多公司、许多行业一起合作，等等，这些情况下，就需要一个开放的标准和访问协议，以方便扩展，这个时候标准协议的力量就体现出来了，对于企业内部应用，如果实时计算的要求不是特别高，但是需要比较强的扩展性，可以考虑使用webservice来代替传统的分布式计算方案，当然也要考虑成本，使用socket和使用webservice的开发成本是相差很大的。 webservice除了c/s架构外，还有一个p2p架构，这个架构的性能是与c/s结构的架构的性能不可一概而论的。 个人觉得各大厂家和媒体对soa的大力宣传不是盲目的。 |
| 返回顶楼 | |
