Mule ESB provides a built-in mechanism to call a Spring bean. Mule also provides an entry point resolver mechanism to choose the method that should be called on the desired bean. One such method is the property-entry-point-resolver. This means the incoming message includes a property that specifies the method name. It looks like this:
<component doc:name="Complaint DAO"> <property-entry-point-resolver property="daoMethod"/> <spring-object bean="acmComplaintDao"/> </component>
This snippet means the incoming message includes a property “daoMethod”; Mule will invoke the acmComplaintDao bean’s method named by this property.
I’ve had three problems with this approach. First, you can only specify the bean to be called, and hope Mule chooses the right method to invoke. Second, Mule is in charge of selecting and providing the method arguments. Suppose the bean has several overloaded methods with the same name? Third, only an incoming message property can be used to specify the method name. This means either the client code invoking the Mule flow must provide the method name (undesirable since it makes that code harder to read), or the flow design must be deformed such that the main flow calls a child flow only in order to provide the method name property.
How I Resolved the Issue
Last week I finally noticed Mule provides access to a bean registry which includes all Spring beans. And I noticed Mule’s expression component allows you to add arbitrary Mule Expression Language to the flow. Putting these two together results in much simpler code. I could replace the above example with something like this:
<expression-component> app.registry.acmComplaintDao.save(message.payload); </expression-component>
The “app.registry” is a built-in object provided by the Mule Expression Language.
In my mind this XML snippet is much more clear and easy to read than the previous one. At a glance the reader can see which method of which bean is being called with which arguments. And it fits right into the main flow; no need to setup a separate child flow just to specify the method name.
A nice simple resolution to the issues I had with my earlier approach. And the new code is smaller and easier to read! Good news all around.