Showing posts with label esb. Show all posts
Showing posts with label esb. Show all posts

Friday, April 11, 2008

BridgeComponent.. OMG

In Mule, BridgeComponent is the root of a lot of evil if you do not pay enough of attention, for instance, you might be wondering why interceptor was not working then realized that BridgeComponent was the culprit!

What is a BridgeComponent? According to the API documentation:

The BridgeComponent is a standard Mule component that enables a bridge between an inbound and outbound endpoints. Transformers can be used on the endpoints to convert the data being received in order to 'bridge' from one endpoint transport to another.

When the BridgeComponent is used, it configures itself so that it will not actually be invoked, instead it tells Mule to bypass invocation of the component, which has a slight performance improvement. Note that because the component is never actually invoked any interceptors configured on the component will not be invoked either.


It is an implementation of the Messaging Bridge pattern in integration. A messaging bridge is responsible to connect two different channels, it is smart because it has a big list of channel adapters.

Fair enough, the API documentation has warned you about interceptor. It's all your fault if you did not read it.

I had been working on a response router problem since morning, scratching my head since then, and in the end realized that the culprit of my unexpectation was the BridgeComponent. What is a response router? Basically, in Mule, a response router is used for request-reply scenario, where a request will be blocked until a response is formed (usually using an aggregator) from results of asynchronous calls. But what is the problem? When my client sent a request to Mule, it received a null response straight after the invocation, before the asynchronous calls were ever made.

I had done a lot of debugging, drilling into the code to find out which part that I could have missed out, perhaps it would just be a missing property? Yes, there was a lot of WTFs. Until I did a full code search on "*ResponseRouter" and noticed that DefaultMuleProxy was in the results..

What had happened? The DefaultMuleProxy is a proxy to a UMO component and it handles its lifecycle (start/stop), interceptors and message routing (which includes response router). When you use a BridgeComponent, request will be forwarded from the inbound to the outbound directly without invoking the UMO component, and thus the response router part will not be not taken care. As Mule dispatches messages asynchronously if ReplyTo is detected at the outbound, a null response will be returned. This explains why I was getting a null response.

So, please take note when you are using BridgeComponent!

- yc

Monday, December 3, 2007

JIRA Transport 1.0 Released

I have released my MuleForge project -- JIRA Transport yesterday. The transport enables easy integration of Mule (the leading open source ESB) with JIRA, and at this version, it has yet to support message receiving.

Click here to find out more about it.

- yc

Tuesday, October 16, 2007

From ESB to REST, Polyglot Programming, JSON

I spent about an hour to do some blog reading. Around two weeks ago I left a comment in Patrick Logan's (an open-source developer) blog on More on the ESB. And just now, while rolling through the feeds consumed by the demon, I found a very good blog by Steve Vinoski (former chief engineer of IONA Technologies) in response to Patrick's blog -- The ESB question. His answer to the problems is REST. Steve subsequently wrote another two blog entries.

Bob Warfield of SmoothSpan summarized the discussion and stretched on multiple language approach as solution to enterprise problems, see ESB vs REST (Another Case for Multi-Language Programming).

They are very good reads which create room for me to start thinking again.

Lately, I am working on the JIRA Transport for Mule and one of the cool things about it is it reads JSON defined at the endpoint, then parses it to invoke the SOAP service of JIRA. I have never been a fan of writing SOAP client using Java and I hate the stubs, it is always Python or Perl.

- yc, reading