Typically, when a method invocation is made on a service through messaging, the call is made remotely to the deployed service behind the scenes. This is fine, but sometimes it is better to have the invocation store and forward to the remote machine and then make the invocation there. In most cases, this provides better performance. If you are running a batch job and want to send numerous invocations, but don't want to wait for each and every invocation to take place before terminating the job, this is definitely a better way to go.
To enable store and forward, set this parameter in the XML configuration for each application setup:
<param name="bus.storeAndForward">true</param>
This feature only works for Java. This parameter will make any Java-based service store and forward. You should consider using it with every Java service.
Store and forward behavior affects how calling code invokes remote services when using the asynchronous or message-style invocation.
Typically, invoking a service through asynchronous messaging will simply queue the call to be made at some point by a local thread, persisting or not persisting the message to the database in the meantime based on the message.persistence configuration parameter.
When store and forward is enabled, the call to the service is not made directly. Instead, a call to a remote forwarding service is made and that service will queue the call on the remote node.
Whether or not store and forward is enabled, the method invocation is made asynchronously, and the service call run on the target server. However with call and forward enabled, the caller thread does not block as long on the call, presumably because the ForwardedCallHandler implementation is much simpler.
When you enable store and forward, the RemotedServiceRegistry, which is responsible for keeping a table of services that the local node has deployed and/or published, will publish a special "forwarding" service alongside each published Java service. This forwarding service definition will be similar to the original service, except that the implementation will be a ForwardedCallHandler, and it will simply re-dispatch the persisted message.
The MessageServiceInvoker, which is responsible for executing service invocations, will first consult the storeAndForward flag, and, if enabled, will attempt to obtain not the actual service, but instead the special "forwarding" version of the service. It will then invoke that forwarding version of the service, instead of the actual service.
To avoid infinite recursion on forwarded service invocations (in other words, the MessageServiceInvoker called by the ForwardedCallHandler itself invoking the forwarded version of the service again), the ForwardedCallHandler sets a property on the method call (isIgnoreStoreAndForward) that prevents store-and-forward from being used again on the delivered message. The MessageServiceInvoker checks this flag on the call before attempting to forward a message.