At TSSJS last week I had a conversation with a Mule user that was having a problem invoking more than one method on a service component (just a POJO object). His scenario was that he had a service with multiple inbound endpoints and a service component with multiple methods, some with matching parameter types. Existing Mule users will be aware that Mule will match methods against the parameters received in the current message. Thus is two methods have the same parameters Mule cannot match the method to invoke.
Well Mule can do it. By adding a ‘method’ property to the inbound endpoint or even as a message header, Mule will automatically use the name specified in the ‘method’ property and nook that method instead.
For example say I have a service component called StringMangler
with a couple of methods –
public class StringMangler { public String reverseString(String string) { return StringUtils.reverse(string); } public String upperCaseString(String string) { return string.toUpperCase(); } } |
And we have a service definition that has two inbound endpoints that will receive requests to be processed by the StringMangler
component.
<service name="Service"> <inbound> <vm:inbound-endpoint path="reverse"/> <vm:inbound-endpoint path="upperCase"/> </inbound> <component class="org.mule.test.entrypoint.StringMangler"/> </service> |
This illustrates the problem that Mule will not be able to match requests to method calls since the request endpoints will both be receiving the same data type, (String) and both of our component methods also accept a String.
The way around this is to add a ‘method’ property to the endpoints which will determine which method to call on the StringMangler
component.
<service name="Service"> <inbound> <vm:inbound-endpoint path="reverse"> <property name="method" value="reverseString"/> </vm:inbound-endpoint> <vm:inbound-endpoint path="upperCase"> <property name="method" value="upperCaseString"/> </vm:inbound-endpoint> </inbound> <component class="org.mule.test.entrypoint.StringMangler"/> </service> |
The ‘method’ property can also be set on the inbound message so it would be possible to have a single endpoint for both methods on the StringMangler
component. Furthermore, the property on the message would override the same property on the endpoint so it would be possible to set a default ‘method’ property on the endpoint but allow individual requests to override it.