First, let's execute the Chapter5 sample application that was opened at the beginning of thi chapter:
- In JBoss Developer Studio, select the Chapter5 project and click Run | Run As | Run on Server.
- Click Next. A window with the project pre-configured to run on this server is shown. Ensure that we have only our project Chapter5 selected on the right-hand side.
- Click Finish.
- Select the
srcfolder, expand it till theSendEsbMessage.javafile is displayed in the tree. Now click Run | Run As | Java Application.A log will be printed in the server console showing the following output:
INFO [STDOUT] Incoming: INFO [STDOUT] [Chapter 5 says Hello!]. INFO [STDOUT] Incoming to B: INFO [STDOUT] [Chapter 5 says Hello!].
- Now refresh the FileProvider Filter created at the beginning of this chapter by selecting Edit File Filter and then clicking OK. You should now see the temporary file which was created, as shown. The name of the file will be different but it will have the extension .dat.sentToEsb.
You created a File based bus provider that was used by ServiceInvoker to invoke the Chapter5Service and also an InVM bus that was used by this service to invoke a second Chapter5BService service. The temporary file was the result of the message being serialized into the file system.
Go ahead and open the temporary file in a standard text editor to see the message contents. Experiment with more messages and see how the temp files are created when you edit the FileProvider filter.
The InVM transport allows messages to be sent within the same JVM instance but without any I/O overhead, such as networking or writing to the disk, and can either be enabled for every service deployed into the ESB or specified explicitly as part of the service declaration. An example configurtion would be:
<service category="Chapter5Sample" name="Chapter5Service"
invmScope="GLOBAL">
<actions mep="OneWay">
<action name="action"
class="org.jboss.soa.esb.actions.SystemPrintln"/>
</actions>
</service>The specification of the InVM transport can be in addition to the configuration of other listeners, allowing communication with the service to occur over the InVM transport, if within the same JVM, or over a remote transport.
Explicit declaration of the InVM transport for a service is handled through the invmScope attribute on the <service> element. The attribute currently supprts two scopes:
The default InVM scope for any JBoss ESB service can also be set in the jbossesb-properties.xml file through the core:jboss.esb.invm.scope.default config property. If not defined, the default scope is NONE.
A service can choose to explicitly exclude the use of the InVM transport through the invmScope attribute on the <service> element of their services configuration, such as in the following example:
<service category="Chapter5Sample" name="Chapter5Service"
invmScope="NONE">
</service>Note
The decision to enable the InVM transport for every service is specific to the context of those services being deployed. It is usually recommended to have the default scope set to NONE and explicitly declare support for the InVM transport, when necessary, in the service level configuration as this is more likely to avoid any confusion when the services are not intended to be invoked over the InVM transport.
The InVM transport can participate in transactions in a similar way to the other transactional transports. The decision whether to enable the use of transactions can be an explicit configuration or, if not specified, can be derived implicitly using the information in the other configured listeners.
The transactional behavior will be implicitly enabled if there are any other transactional transports configured on the service, either JMS, SQL, or scheduled, and one of those transports has support for transactions.
Explicit configuration of the transactional behavior is handled by specifying the invmTransacted attribute on the <service> element. This configuration will always take precedence, irrespective of the existence of any other transactional listener configured for the service.
Tip
One caveat to be aware of is that, although transactional, the InVM transport does not support full ACID semantics, specifically due to the lack of a durable store. Any message sent using an InVM transport would be lost, should the JVM crash or halt through normal operation, and may lead to inconsistency should the transaction involve multiple transactional resources such as accessing databases.
If full ACID semantics are desired then it is recommended to use an alternative transport such as JMS (Java Message Service) or SQL transports.