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，可悲！