Because the JBoss Enterprise SOA Platform allows services to be invoked concurrently across multiple different transports, it is straightforward to design services in such a way that they can achieve high performance and reliability. Do this by making a suitable choice of transport for each type of message.
Earlier versions of the product did not support this transport and required every service to be configured with at least one message-aware listener. This is not longer a requirement; Services can now be configured without any <listeners> configuration and still be invokable from within their own virtual machines:
<service category="ServiceCat" name="ServiceName" description="Test Service">
<action name="action" class="org.jboss.soa.esb.listeners.SetPayloadAction">
<property name="payload" value="Tom Fennelly" />
This makes service configuration a little more straightforward.
Control the InVM service's invocation scope through the <service> element's “invmScope” attribute. Two scopes are supported:
GLOBAL: (Default) The service can be invokable over the InVM transport from within the same Classloader scope.
NONE: The service cannot be invoked over the InVM transport.
The InVM listener can execute within a transacted or non-transacted scope in the same manner as the other transports which support transactions. This behaviour can be controlled through explicit or implicit configuration.
The explicit configuration of the transacted scope is controlled through the definition of the “invmTransacted” attribute on the <service> element and will always take precedence over the implicit configuration.
The ImVM listener will be implicitly transacted if there is another transacted transport configured on the service. At present these additional transports can be jms, scheduled or sql.
The InVM transport in the JBoss Enterprise SOA Platform is not transactional and the message queue is held only in volatile memory. This means that the message queue for this transport will be lost in the case of system failure or shut down.
You may not be able to achieve all of the ACID semantics, particularly when used in conjunction with other transactional resources such as databases, because of the volatility aspect of the InVM queue but the performance benefits of InVM should outweigh this downside in the majority of cases. In the situations where full ACID semantics are required, Red Hat recommends that you use one of the other transactional transports, such as Java Message Service or database.
When using InVM within a transaction, the message will not appear on the receiver's queue until the transaction commits, although the sender will get an immediate acknowledgment that the message has been accepted to be later queued. If a receiver attempts to pull a message from the queue within the scope of a transaction, then the message will be automatically placed back on the queue if that transaction subsequently rolls back. If either a sender or receiver of a message needs to know the transaction outcome then they should either monitor the outcome of the transaction directly, or register a Synchronization with the transaction.
When a message is placed back on the queue by the transaction manager, it may not go back into the same location. This is a deliberate choice in order to maximize performance. If your application needs specific ordering of messages then you should consider a different transport or group related messages into a single “wrapper” message.