ServiceMix无痛起步
有兄弟评论说,“看了之后,感觉和技术没边,好像一个怨妇再发牢骚,我们程序员需要的是真实的解决方案,哪怕是个hello world的例子”,这就是本文的由来。而且除了SerivceMix主页,其他地方能找到的ServiceMix入门文章基本没有,希望这篇B文能带对ServiceMix感兴趣的兄弟们入个门。
本文是ServviceMix 3.3 的hello world,如果有后续文章,将会采用最新的ServiceMix 4。
ServiceMix无痛起步
有兄弟评论说,“看了之后,感觉和技术没边,好像一个怨妇再发牢骚,我们程序员需要的是真实的解决方案,哪怕是个hello world的例子”,这就是本文的由来。而且除了SerivceMix主页,其他地方能找到的ServiceMix入门文章基本没有,希望这篇B文能带对ServiceMix感兴趣的兄弟们入个门。
本文是ServviceMix 3.3 的hello world,如果有后续文章,将会采用最新的ServiceMix 4。
ESB、BPEL、SCA简单区分
就我目前的理解,SCA其实是把其他各种服务引入自己应用的工具。
举例来说,现在有A->JEE(EJB/JMS/..)的应用(服务),B->BPEL(..) process,C->Web2.0 Component(Widget/json/..),如果现在要做一个建立在A、B、C基础之上的应用,那么SCA是一种最合适的工具,它用类似的方式,把三种不同类型的服务引入系统,避免了维护三种不同服务接口的工作量。
而作为发布服务的工具,SCA其实是不太合适的。
再举例 :-) 已有应用是Web2.0类型的。现在要发布出一个服务,不管我是选择RESTful的,还是widget,还是json,都有相对应的简单工具,为什么我要引入SCA这么大型的工具呢?就好比现在我就想剪指甲,非买个瑞士军刀来剪,我觉得酷,你也看我像装13对吧?(又举例,真是一例解千愁啊)
ESB和BPEL都有他们各自的应用场景,直接拿来和SCA比较并不太合适,而且他们也不是同一层次的工具。ESB是要解决服务通道,BPEL要解决服务流程,SCA要解决服务装配。
BTW: 这篇B文是在一个Google Group里的回帖。贴在这里主要是觉得,还稍微有点价值,而且还有很多可以发挥的点,以后说不定可以做成一篇大大的B文。
Recent comments
3 min 57 sec ago
6 weeks 1 day ago
38 weeks 2 days ago
38 weeks 4 days ago
38 weeks 4 days ago
44 weeks 2 days ago
52 weeks 18 hours ago
1 year 6 hours ago
1 year 6 weeks ago
1 year 6 weeks ago