ESB就是又一个EJB

我听过不止一个愤青说过，SOA就是一个EJB，下场是一样的。

 

我不同意他们的这个说法，但是我其实明白他们想说什么：ESB就是又一个EJB，这个我倒是非常同意的。

 

首先我说说为什么我不同意“SOA就是一个EJB”：

SOA包括什么内容？我的观点请见http://hongsoft.iteye.com/blog/289341

1）服务的实现和封装（webservice/sca)

2）服务的管理 （服务管理库、服务总线，但是不是ESB）

3）服务的编排（BPM）

很明显，SOA不是下一个EJB。

 

但是，我认为ESB就是下一个EJB。

很明白，他们都做了些什么事情？

一般的服务总线都有如数据转换、协议转换、消息路由等等通用功能，（很黄很暴力）

而ESB还多了负载均衡、安全策略、服务监控、团队开发支持等特性。（和EJB的这些特性一样，基本就是废物）

 

我认为，我们的负载均衡、安全策略、团队开发支持 根本就不需要由这些产品来支持，我们开发人员有自己的办法来搞定他们。

所以，ESB就是又一个EJB。

评论

25 楼 hongsoft 2008-12-10  

1）是他们要走总行。不是我们。呵呵。
2）直接访问 另外的分行，和点对点的模式 区别就不大了。所以IBM不会让他们直接连分行的。

我比较建议的模式，是 （前）BEA的某 aqualogic service bus的架构师的一本书写的模式。（有中文版）

BEA这个公司在ESB方面并没有包袱，所以可以做出比较纯粹的东西（服务总线）。IBM等公司做的ESB，和卖的ESB，大都是以前的存货，换了标签而已，这个是比较麻烦的。

24 楼 fjlyxx 2008-12-10  

我不明白 你为什么要走总行，第一就技术而言 这是自找苦吃，第2 不够灵活。当然我这些考虑是脱离业务的。
我就脱离了业务的要求说下我的设计。
第一，行和行间在安全机制允许的情况下可以直接通信。 要解决这个问题 你也许需要在总行发布一个路由和资源同步的服务。每个节点向这个服务去同步整个网络和服务信息（可以加上安全控制策略） 当然你也可以由总行的这个服务进行同步信息推送（就是一个拉和推的选择）。
在这种机制下 你的访问可以不通过总行。

也许我们SOA平台提供的内核服务机制不一样所以可能理解方面有点不同。因为我们不存在实际的ESB总线。所有的节点都是ESB总线功能的一个副本，在脚本的控制下（数据驱动）会流向不同的ESB挂接的服务。所以我们不存在夸区域访问还需要一个处理节点的问题。

23 楼 EJB_wawa 2008-12-10  

EJB 还是好.soa.webservice都要会用.服务总线类的还要了解.

22 楼 hongsoft 2008-12-10  

fjlyxx 写道

  

我想问一下，
1。分行间要通信你是走总行还是可以直接通信。

呵呵，当然要走总行了。否则IBM不是自己打自己嘴巴？
但是 服务总线的分级并不是 按 分行、总行来划分的，想想：  A系统是 跨了 广东省和 江西省的系统，它的服务部在哪里？  呵呵，很明显的就是以前的EAI的变脸嘛。

服务总线的分层分级，是在SOA的建设过程中，根据对业务的整理和对业务域的分析，一步步按 业务来划分的。在某个业务域内的服务的依赖关系，并不需要纳入 服务总线管理。
而服务总线的分层分级，应该是按 业务域来划分，而不是按 分行总行来划分。

21 楼 hongsoft 2008-12-10  

[quote="neo_q负载均衡在小型应用上当然是很少的，但是在大型的企业应用上有负载均衡是绝对可以带来明显的性能提升的。
安全策略，当然你可以说你可以在别的地方来做策略管理，我不知道你对策略管理是怎么理解的，难道你直接加在service上？在ESB里面加上策略管理明显是可以灵活地插拔。
对于ESB还有一个重要的功能，在一个大型的企业中存在各种service但是这些service的实现方式肯定是有很大差异的，因为语言或者规范的差异，会导致彼此的调用或者编排不是设计中那么高的兼容性，而ESB的一个功能就是可以消除这种差异性，在真实的大型SOA项目中是绝对好用的feature，君不见，oracle以前的ESB产品就是一堆adapter吗？

下面从技术的角度来讨论：

1）ESB或者服务总线并不是在 “大型或者 小型应用”上用的，SOA考虑的是 分布式系统，强调的是多个应用，可能是跨领域的。
2） “大型的企业应用上有负载均衡”：  这个与ESB无关。
3）“在大型的企业应用上有负载均衡是绝对可以带来明显的性能提升的。”负载均衡怎么可能提升性能呢？别开玩笑了。
4）策略当然是加在服务上的。我们有个客户强烈要求我们做到这点，呵呵。你看看现在的产品（包括开源的），策略都是在服务上的。（当然，endpoint可以统一配置一个策略）
5）我理解的策略就是ws-policy，没有感觉到有其他的需求。
6）ESB里面的策略管理，灵活地插拔什么？
7)你说的语言或者规范的差异，就是我说的 “数据转换，协议转换”。这个是需要的。

我认为我们需要的是 轻量级的服务管理功能，而不是把以前的EAI产品或者MQ改造的“新”的ESB.

20 楼 fjlyxx 2008-12-10  

  总行一个ESB，分行各一个ESB，部分支行还买了ESB。
   采用的是“联合ESB”架构。其使用方式和EAI并无本质区别。

我想问一下，
1。分行间要通信你是走总行还是可以直接通信。
2。jt银行的ESB上面管理了 极少的服务（一个表+一个web应用就可以搞定的事情） 发布成一个WS接口就可以了。
3。ah电信的几个系统本来运行很正常的，买了ESB后，经常down机.....不走ESB就又正常了，但是问题就是发现不了  请查看你的数据库操作，第一日志是否缓存批量。第2，访问水位是否有保护，第3 下班了。以后说

19 楼 hongsoft 2008-12-10  

hongsoft 写道

呵呵，我真的没有见过 哪个企业 用到了
ESB的  负载均衡、安全策略、团队开发 功能？能否说说让我学习一下/

当然，没有 服务管理特性，就不是SOA。这个我是同意的。

晕，你没见过并非代表没有用或者不存在！
quote]

先说说我大概了解的ESB的产品使用情况：
1）js银行的ESB的总体结构是：  总行一个ESB，分行各一个ESB，部分支行还买了ESB。
   采用的是“联合ESB”架构。其使用方式和EAI并无本质区别。
2）jt银行的ESB上面管理了 极少的服务（一个表+一个web应用就可以搞定的事情）
3）ah电信的几个系统本来运行很正常的，买了ESB后，经常down机.....不走ESB就又正常了，但是问题就是发现不了

不要受大厂商的HY，自己明白自己需要什么。

18 楼 neo_q 2008-12-10  

hongsoft 写道

在我看来EJB的技术范围比hibernate要广很多。

我认为应该用轻量级的服务总线，而且是多个并用。

我认为不应该存在 企业服务总线，实际上这样级别的SOA项目也不存在。

虽然人家叫ESB，但是本来就是支持多个并用的。

17 楼 neo_q 2008-12-10  

hongsoft 写道

呵呵，我真的没有见过 哪个企业 用到了
ESB的  负载均衡、安全策略、团队开发 功能？能否说说让我学习一下/

当然，没有 服务管理特性，就不是SOA。这个我是同意的。

晕，你没见过并非代表没有用或者不存在！
负载均衡在小型应用上当然是很少的，但是在大型的企业应用上有负载均衡是绝对可以带来明显的性能提升的。
安全策略，当然你可以说你可以在别的地方来做策略管理，我不知道你对策略管理是怎么理解的，难道你直接加在service上？在ESB里面加上策略管理明显是可以灵活地插拔。
对于ESB还有一个重要的功能，在一个大型的企业中存在各种service但是这些service的实现方式肯定是有很大差异的，因为语言或者规范的差异，会导致彼此的调用或者编排不是设计中那么高的兼容性，而ESB的一个功能就是可以消除这种差异性，在真实的大型SOA项目中是绝对好用的feature，君不见，oracle以前的ESB产品就是一堆adapter吗？

16 楼 fjlyxx 2008-12-10  

在我看来EJB的技术范围比hibernate要广很多。

我认为应该用轻量级的服务总线，而且是多个并用。

我认为不应该存在 企业服务总线，实际上这样级别的SOA项目也不存在。

认同，非常认同。所有我做的叫SB不叫ESB。但是SB也不轻量，主要是因为要靠广泛的支持去实现特别的需求。 多个并用还不够 ，还可以分层套用。

15 楼 hongsoft 2008-12-10  

在我看来EJB的技术范围比hibernate要广很多。

我认为应该用轻量级的服务总线，而且是多个并用。

我认为不应该存在 企业服务总线，实际上这样级别的SOA项目也不存在。

14 楼 linginfanta 2008-12-10  

如果ESB是又一个EJB,那谁是Hibernate？

13 楼 hongsoft 2008-12-10  

从技术上看，服务可能是：
1）wsdl所表达的业务接口
2）idl所表达的业务接口
3）XXX所表达的业务接口

他们有业务含义。可能还是 无状态的、自治的、有安全、事务策略的 等等。

12 楼 fjlyxx 2008-12-10  

技术角度应该说一切能够识别SOA平台接口描述的应用，就好像WS可以识别SOAP报文一样。 只要能识别就能被平台调用，就具备构成一个服务的条件。
大概的说SOA的服务方都是适配器。WS也可以看成一个适配器。 不知道这样说行不行呢？

11 楼 hongsoft 2008-12-10  

fjlyxx 写道

1）我开发一个新的应用，对外暴露webservice非常方便，不增加工作量（自动的暴露为服务）

SOA的服务方好像不单是webservice吧，还有很多其他的东东，可以是一个应用的适配器，可以是一个数据库访问的URL 还可以是MQ平台，一切尽有可能。

是的，SOA的S是服务，不一定是web service。这句话是从业务的角度来说的。
从技术角度看，基本上都是web service吧？我还听到过corba体系下实现的soa架构。其他的好像没有听过。

SOA的服务不一定是web service这句话就是国外那帮 非技术人员说的。这句话是对的，但是我一般就认为是web service.

10 楼 fjlyxx 2008-12-10  

哦~~我不同意~
我恰恰认为ESB是SOA的精华所在~

我更觉得SB才是精华，E只是在SB的基础上进行特例话的东西。

9 楼 fjlyxx 2008-12-10  

体外话，也许把ESB的E去掉 SOA平台会简单很多。也会好理解很多。为什么非得加一个企业呢？加上这个E好像就一定要和业务有关系了。SB多好.

8 楼 fjlyxx 2008-12-10  

1）我开发一个新的应用，对外暴露webservice非常方便，不增加工作量（自动的暴露为服务）

SOA的服务方好像不单是webservice吧，还有很多其他的东东，可以是一个应用的适配器，可以是一个数据库访问的URL 还可以是MQ平台，一切尽有可能。

7 楼 hongsoft 2008-12-10  

服务总线==轻量级ESB==我们普通情况下对开源ESB的使用

足够了。

当然，开源的东西都有它的缺点，这个是另外一个话题。

6 楼 hongsoft 2008-12-10  

业务敏捷从技术上怎么体现？
我认为从如下方式：

1）我开发一个新的应用，对外暴露webservice非常方便，不增加工作量（自动的暴露为服务）
2）我如果要调用一个服务，可以通过服务总线的 服务路由、数据转换、协议转换 很方便的做到。
3）我要开发一个业务，可以由BA来画流程图，画的图 是可以执行的，然后 部署人员 配置技术方面的参数，就可以 执行流程了。BPM调用服务。
4）我的系统有新的需求需要调整一下，很方便可以做到（我在服务总线中做调整就可以）