Mule ESB使用之高并发问题

Mule ESB作为开源社区的企业级服务总线容器实现。其兼容的实现协议多,使用起来方便,并且有Mule Studio作为支撑。使用非常方便。

由于工程项目需要,开发企业服务总线时使用过他。不过也遇到非常多的问题,很多问题都是一层窗户纸,难者不会,会者不难!

其中最有意思的便是中国土地上,电信领域的ESB的误用!电信领域的甲方用户,对企业级ESB服务总线也是一知半解,从调用的保温上就可以看出来,他们完全错误的被误导了。让webservice的ESB服务总线,成了一个请求调用的转发代理,不仅如此,还让调用者陷入到痛苦之中!

Mule ESB的高并发问题,主要在于拦截器中对MuleMessage 的操作。在extends AbstractPhaseInterceptor<SoapMessage> 的SOAP拦截器中,如果你使用

              DefaultMuleEvent   muleEnv = (DefaultMuleEvent) message.getExchange().get("mule.event");

来间接获取MuleMessage 对象。就会导致线程并发的混乱。这样应用是极不安全的,会导致线程错位。因此必须避免这样使用。如果你要操作报文,就不要使用CXF原生的拦截器,而要使用Mule ESB自己封装的拦截器。并且另外,条条大路通罗马,如果你这样用了,就说明你的思路错了。换一种思路吧!

而对于ESB来说,透明性非常重要!因此总线的第一作用就是要透明!中国电信领域的ESB应用,尤其是针对webservice的,几乎所有的人都被误导。连测试的方式都不对,整个变成了对XML字符串处理能力的PK,可悲!

你可能感兴趣的:(并发,webservice,SOAP,mule,ESB,ESB)