建设“更贴近于国内实际应用的开源ESB产品”—召集贴想法由来已久，可能与自己几年的商业ESB架构以及研发经历
建设“更贴近于国内实际应用的开源ESB产品”—召集贴
想法由来已久，可能与自己几年的商业ESB架构以及研发经历有关。
前后换了两家公司，但是一直没有做出自己心目中的ESB产品，颇觉遗憾。当然商业级的产品盈利是第一目的的，不可能由着自己的兴趣和爱好来做。
当前国外开源的ESB产品有一大堆，但是这些开源的ESB产品和国内实际的应用是有很大差距的。举几个最简单的例子：
第一：使用ServiceMix、mule等开源产品的时候，有些操作是需要修改配置文件的（这样的操作有很多），但是在实际的项目中，这种直接修改配置文件的形式很难为客户所接受。客户是希望通过简单的界面操作来完成，而不需要修改哪怕一行代码（客户的理想）。
第二：SOA的很多咨询文档中（包括我本人也写过很多这样的文档）都写到“通过使用XXX可以使开发人员不需要关注具体的技术，而只需关注业务”，但是实际中是这样的吗？我们使用哪种新技术时，不是费了半天劲去学习呢？试想一下，当计划使用TuscanySCA开发服务时，我们需要多大的学习成本？如果这个时间再乘以项目组成员人数，那么使用一个SOA新技术的学习成本就更高了。
第三：国外开源产品的“水土不服”。国外开源产品更多的是功能上的实现，并不适合于国内的实际情况
如果项目实施人员能够使用开源ESB产品进行“傻瓜式”开发，那些很深的SOA技术对于他来说是黑盒（当然实施人员多少也得懂点），让SOA相关技术能够通过简单的方式用起来，我想对于我们这些软件人来说，都应该是不错的事情。
“做想做的事，干想干的活，按照自己的想法工作”。
本人已经有了关于产品研发的一些计划和规划，本帖仅仅作为一个召集贴，供大家交流。欢迎有兴趣的朋友讨论、拍砖，更希望做过相关工作的朋友与我联系讨论该项目
我的联系方式：
MSN：boyingking@hotmail.com
Mail: boyingking@gmail.com
63 楼 guo7845703 2009-02-11 竹十一 写道先报名-_-
万一有空就去学习！
恶搞一下名字：
1/ CAN Bus
2/ Field Bus
3/ 502
4/ 好兄弟
5/ backbone
我也算一个，初步计划出来告知一下。 64 楼 boyingking 2009-02-12 guo7845703 写道竹十一 写道先报名-_-
万一有空就去学习！
恶搞一下名字：
1/ CAN Bus
2/ Field Bus
3/ 502
4/ 好兄弟
5/ backbone
我也算一个，初步计划出来告知一下。
活动计划已经制定，现在正在联系场地，等活动地点定下来以后，将会在下周一之前发布活动贴。
65 楼 dapeng.gml 2009-02-12 算我一个，正在做毕业设计的SOA相关的实验。有大把大把的时间 66 楼 boyingking 2009-02-12 dapeng.gml 写道算我一个，正在做毕业设计的SOA相关的实验。有大把大把的时间
谢谢支持，我们也需要这样的^_^ 67 楼 fjlyxx 2009-02-12 也算我一个吧 搞搞看看 68 楼 freehand 2009-02-12 呵呵,我做了两年ESB开发了,一直很希望自做的产品能够普及出去.如果lz要带个头 ,那么我参与 69 楼 jnn 2009-02-12 asd 写道看了半天，说实话，我没有看出各位在说什么，隐隐约约是大家研究了很多开源的号称“esb”的产品，然后有各种想法，至于是哪里不爽，好像各位自己说得明白，像我这样的看官看的云里雾里。
我倒是有个疑问：各位准备把“符合国内实际”的ESB用在什么地方？很难理解为什么还出现类似于客户对"esb"的配置感觉不方便这样的问题。难道你们的esb真的是一个让业务人员都可以操作的全自动UI?
我觉得LZ的召集还是有点虚， ESB和以前的J2EE,CORBA 等中间件一样， 只是一个工具，由于国内大部分的应用都是交钥匙的工程， 国内厂商在这个生态链中可以找到一个自己的位置，就是建立实际应用与已有开源ESB之间的桥梁。
如果只是做一个全自动UI， 是不是有点太肤浅了。 70 楼 boyingking 2009-02-12 jnn 写道asd 写道看了半天，说实话，我没有看出各位在说什么，隐隐约约是大家研究了很多开源的号称“esb”的产品，然后有各种想法，至于是哪里不爽，好像各位自己说得明白，像我这样的看官看的云里雾里。
我倒是有个疑问：各位准备把“符合国内实际”的ESB用在什么地方？很难理解为什么还出现类似于客户对"esb"的配置感觉不方便这样的问题。难道你们的esb真的是一个让业务人员都可以操作的全自动UI?
我觉得LZ的召集还是有点虚， ESB和以前的J2EE,CORBA 等中间件一样， 只是一个工具，由于国内大部分的应用都是交钥匙的工程， 国内厂商在这个生态链中可以找到一个自己的位置，就是建立实际应用与已有开源ESB之间的桥梁。
如果只是做一个全自动UI， 是不是有点太肤浅了。
就像jnn说的，这种buzz word 确实没有太大的意义，叫什么无所谓，属于哪个技术系列也无所谓，最重要的是他能解决大量的问题，这才是我的目的。
如果仅仅是做UI，就不会费这么大劲了。近两年做过国内整合项目（披着SOA外衣的以及没披SOA外衣的）的，对我前面帖子中提到的种种问题，我想是很容易理解的。
功能边界定义在本月底出，等这个东西出来，做过和没做过的，就都明白要做什么了。
到时候希望大家拍砖。 71 楼 honno 2009-02-13 jnn 写道asd 写道看了半天，说实话，我没有看出各位在说什么，隐隐约约是大家研究了很多开源的号称“esb”的产品，然后有各种想法，至于是哪里不爽，好像各位自己说得明白，像我这样的看官看的云里雾里。
我倒是有个疑问：各位准备把“符合国内实际”的ESB用在什么地方？很难理解为什么还出现类似于客户对"esb"的配置感觉不方便这样的问题。难道你们的esb真的是一个让业务人员都可以操作的全自动UI?
我觉得LZ的召集还是有点虚， ESB和以前的J2EE,CORBA 等中间件一样， 只是一个工具，由于国内大部分的应用都是交钥匙的工程， 国内厂商在这个生态链中可以找到一个自己的位置，就是建立实际应用与已有开源ESB之间的桥梁。
如果只是做一个全自动UI， 是不是有点太肤浅了。
赞同jnn的观点("建立实际应用与已有开源ESB之间的桥梁"),我想我们这次要做的国内首款开源ESB其目的之一就是合理利用开源ESB,做一款适合国情的开源ESB,来降低学习和使用ESB的门槛.
虽然开源ESB都有eclipse插件工具或者独立的开发工具,但与直接通过图形界面进行拖拽还是有很大的差距,如果国内能对其开发工具进行优化,达到直接拖拽的效果,那么对开发人员来说无疑是件好事情. 72 楼 dannycole 2009-02-13 boyingking 写道就不继续引用了，再引用就乱套了^_^
简单列几个共性的问题吧，我这里有上百个，取其中几个大家容易理解的来讨论。可能有的开源产品中存在这些问题，有的不存在。如果例子不够，后面继续再贴。
1）服务注册：注册中心的实现机制都不是很灵活，比如说在Mule中注册的服务是写到xml中的。暂且不论这种方式的好与坏，性能的高与低。可能会存在以下几个问题：
手动修改XML文档，难免会出现错误这是其一。
其二：当服务以百为单位计算时，还能维护吗？
其三：针对注册服务的查询，统计分析工作是不是很难开展。
其四：我想要根据服务的分类查询，服务所属部门查询，服务注册时间查询，全都得歇菜。
其五：性能的高与低？
2）服务声明周期的管理以及版本治理。
有些产品比如ServiceMix中提供了一些对JBI组件的生命周期的管理，但是我遇到的实际情况都是这样的：已有业务系统是一个老的Delphi或者VC或者JAVA系统，仅能对总线提供一个地址（WebService或者RMI后者Socket），不可能物理部署到总线上，这个时候他的生命周期管理功能就不够用了。
3)监控：简单例证：部署在远程服务器上的一个Delphi开发的WS服务，怎么监控？
4）服务的调试： 例，已经发布的服务，注册到总线上。此时想要对其测试一下，看看能否通过总线按照预想的方式通信。我们需要写测试用例来与总线通信。实际上这些测试用例完全不用写，总线应该具备一定的简单的测试功能的。
5)服务调用权限的管理：领导说“MD，再弄老子不让你们访问这个服务了”。这个也不用多说了，通常情况都是项目组中自己开发的，很少有开源产品提供这种支持。
6)统计分析也不多说了，也是个没有最好只有更好的东西，反正一般的开源产品提供的相差都比较远。
7)服务访问与响应的统计分析以及图形化表示：这些数据是很重要的，比如说一个服务每天被访问了1000000000次，那么架构人员就应该考虑是不是要对他的硬件进行升级，或者做个集群什么的了。服务对每次请求的响应时间达到1000秒，是不是该修理修理他了？下课？不必了。
8)事务管理：实际项目中，很多的开源ESB产品的事务机制都不能满足要求。
9)WS-*有那么一大堆的东西，通过总线能简化一点他的使用吗？
10)SCA开发的标准的服务，能够更简单的部署到BUS上吗？
…………先贴这几个吧
对这些有点感受了，我们公司也在构建自己的ESB系统，目前初步实现了消息流和一些简单的消息处理机制，但还没有上升到具体的服务编制等方面，我也是刚由PM分配去做一个关于开源ESB的适用性研究，以前从来没接触过，看了各位老大的帖子，思路也清晰了不少，希望有机会能更进一步的接触这个project. 73 楼 candy_hr 2009-02-13 我报名参加一个，对ESB比较感兴趣，使用过我们自己公司的ESB产品，3年J2EE开发经验。使用多了国外的开源软件，为国内的开源做点贡献。
msn:ecliujie#163.com 74 楼 liubaoshan 2009-02-14 算我一个 OK! 75 楼 zozoh 2009-02-14 boyingking 写道就不继续引用了，再引用就乱套了^_^
简单列几个共性的问题吧，我这里有上百个，取其中几个大家容易理解的来讨论。可能有的开源产品中存在这些问题，有的不存在。如果例子不够，后面继续再贴。
1）服务注册：注册中心的实现机制都不是很灵活，比如说在Mule中注册的服务是写到xml中的。暂且不论这种方式的好与坏，性能的高与低。可能会存在以下几个问题：
手动修改XML文档，难免会出现错误这是其一。
其二：当服务以百为单位计算时，还能维护吗？
其三：针对注册服务的查询，统计分析工作是不是很难开展。
其四：我想要根据服务的分类查询，服务所属部门查询，服务注册时间查询，全都得歇菜。
其五：性能的高与低？
2）服务声明周期的管理以及版本治理。
有些产品比如ServiceMix中提供了一些对JBI组件的生命周期的管理，但是我遇到的实际情况都是这样的：已有业务系统是一个老的Delphi或者VC或者JAVA系统，仅能对总线提供一个地址（WebService或者RMI后者Socket），不可能物理部署到总线上，这个时候他的生命周期管理功能就不够用了。
3)监控：简单例证：部署在远程服务器上的一个Delphi开发的WS服务，怎么监控？
4）服务的调试： 例，已经发布的服务，注册到总线上。此时想要对其测试一下，看看能否通过总线按照预想的方式通信。我们需要写测试用例来与总线通信。实际上这些测试用例完全不用写，总线应该具备一定的简单的测试功能的。
5)服务调用权限的管理：领导说“MD，再弄老子不让你们访问这个服务了”。这个也不用多说了，通常情况都是项目组中自己开发的，很少有开源产品提供这种支持。
6)统计分析也不多说了，也是个没有最好只有更好的东西，反正一般的开源产品提供的相差都比较远。
7)服务访问与响应的统计分析以及图形化表示：这些数据是很重要的，比如说一个服务每天被访问了1000000000次，那么架构人员就应该考虑是不是要对他的硬件进行升级，或者做个集群什么的了。服务对每次请求的响应时间达到1000秒，是不是该修理修理他了？下课？不必了。
8)事务管理：实际项目中，很多的开源ESB产品的事务机制都不能满足要求。
9)WS-*有那么一大堆的东西，通过总线能简化一点他的使用吗？
10)SCA开发的标准的服务，能够更简单的部署到BUS上吗？
…………先贴这几个吧
简单的说
1. 使用 Ioc
2. 对象的注入信息不要存在XML里，存在数据库里
3. 开发一个GUI 编辑这个数据库 76 楼 Colin.Chen 2009-02-16 比较感兴趣 77 楼 summerleaf 2009-02-16 也算我一个，王大哥 78 楼 UlsterBoy 2009-02-17 我报名参加一个，对ESB比较感兴趣.
没有经验，只是无聊的时候 看过点 ESB 的文章
msn: iamtwang@hotmail.com 79 楼 boyingking 2009-02-18 由SOA草根论坛发起的，SOA草根论坛与TechTarget中国共同主办的“开源ESB：是否可以入乡随俗”活动，现在已经发布活动帖：
（报名地址）
http://www.techtarget.com.cn/Salon/2009/ESB/index.aspx
活动主要内容如下：
从两个实际ESB整合项目入手，交流如何使用开源ESB产品实施项目 。
一起使用Camel进行整合，现场code。
教您如何使用ServiceMix， 现场code
交流使用开源ESB产品实施项目时遇到的困难，交流解决方案。
交流基于开源ESB产品开发自己的SOA产品时，遇到的困难以及解决方案。
交流“国内首款开源ESB产品”功能边界以及边界定义。
交流“国内首款开源ESB产品”技术白皮书。
有兴趣的请报名参加^_^
80 楼 portrait 2009-02-18 “国内首款开源ESB产品”技术白皮书。
什么时候写出来啊，我要船家esb开发 81 楼 java-bin 2009-07-17 精通CRUD可以凑个热闹吗，大哥？ 82 楼 WorldHello 2010-01-20 还找人不？
我对EAI/ESB/SCA/SDO/SOA等比较熟悉
同时对openadaptor有深入研究，同时也研究过mule和tuscany（这个很肤浅）
