Function Selectors, Native Methods, and All That
August 15, 2007 1 Comment
Confused about function selector terminology? Read on…
The messaging transport binding types in WebSphere ESB (and Process Server) – JMS, MQ/JMS, and MQ – allow one to specify a function selector on an export. This function selector is a Java class that determines which function (a.k.a. native method) is used to process the message throughout the Module in question. There is a default function selector for JMS and MQ/JMS, called com.ibm.websphere.sca.jms.selector.impl.JMSFunctionSelectorImpl, but you can write your own. This default function selector extracts the TargetFunctionName header from the JMS message and uses that as the function name. For MQ, there are four different pre-supplied function selectors, but again, you can write your own if these don’t suit.
However, there is an extra level of indirection. The export also allows the specification of ‘method bindings’. These bindings map the function (native method) name onto the operation name in the interface(s) specified on the component. By default, these method bindings implement identity – the operation name and the native method name are the same – but you can change this if you wish.
The best way to use all this functionality is to implement function selectors that are as generic as possible – perhaps they extract a particular field from the message and return that as the native method name. Then, if you need to do some more complex mapping because the names of your operations don’t match, do that in the method bindings. However, this is a best practice only, and you don’t have to do things that way.
Web service and SCA bindings don’t have these facilities because the operation name is already directly encoded as a side-effect of the way the export is invoked.
Thanks to Simon for clearing all this up for me.