First, let's execute the Chapter5
sample application that was opened at the beginning of thi chapter:
src
folder, expand it till the SendEsbMessage.java
file 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!].
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>
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.
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.