The consequence of not thinking about reliable communication or not implementing it in our OSB services can lead to many problems in case of error. It can lead to the loss of your messages, a destination can receive multiple messages and this means that the sending application can't trust the service bus. The application needs to monitor its own requests.
Reliable communication is all about Distributed Transactions—XA, Quality of Service (QoS), and persistence.
XA is a transaction that can be shared across multiple resources such as a JMS queue, coherence, direct binding, JCA binding, or an EJB session bean. Be aware that the HTTP transport does not support XA and can't take part in the so called global transaction. When an OSB transport or a JCA adapter starts a transaction, this transaction will be handled or controlled by the Java Transaction API (JTA) of the WebLogic server. XA will use a two-phase commit so all resources either do a commit or a rollback together.
When a destination...
In this recipe we will configure the redelivery limit and expiration policy on a Queue that will take part in a reliable communication. This option prevents an infinite loop: when the redelivery limit is reached, the message will be moved to the error queue. The redelivery limit on the queue will always override the value set on the message itself.
For this recipe we need the two queues from the standard environment and a proxy service that consumes the messages from the SourceQueue. The proxy service will initially just log the content of the message to the console using a Log action.
Import the OSB project into Eclipse from \chapter-10\getting-ready\configuring-retry-handling
and deploy it to the OSB server. In the WebLogic console, perform the following steps to send a message to the queue for testing:
Select Services | Messaging.
Click on JMS Modules and in the list of modules click on OsbCookbookResources.
Click on the SourceQueue queue.
Navigate...
When we send messages to a JMS queue, the Message Delivery Mode option controls if a message is guaranteed to be delivered once, and if it is safely stored in the persistent store of the JMS server. There is also a non persistent option, where the messages are stored in memory and may be lost in case of a WebLogic or JMS server failure, or when the WebLogic server is rebooted.
In this recipe, we will set the delivery mode option on a JMS message with the OSB Transport Header action.
This recipe will show the different error scenarios, which we can have with XA and non XA enabled resources and how QoS can influence this.
For this recipe, we will use a setup with three queues from the standard environment, a proxy service that consumes messages from a JMS queue, and a business service that sends th messages to another JMS queue:
You can import the OSB project into Eclipse from \chapter-10\getting-ready\working-with-global-transactions-and-qos
.
First, we will show you the behaviour of the service without a global transaction.
In Eclipse OEPE, perform the following steps:
Navigate to the proxy service JMSConsumer.
Navigate to the Transport tab.
Change the Endpoint URI to use the non-XA JMS Connection Factory : jms://[OSBServer]:[Port]/weblogic.jms.ConnectionFactory/jms.SourceQueue
Navigate to the Message Flow tab.
The message flow contains a Pipeline Pair node and a Route node with a Routing action...
In this recipe, we will create a one-way (fire and forget) proxy service that contains a long running WS-RM (Reliable Messagng) policy and test this WS-RM policy in a JDeveloper web service proxy client.
We will use the WS transport, which implements both inbound and outbound requests for SOAP-based services with a WS-RM policy.
For this recipe, we will use a setup with a very simple proxy service based on a WSDL containing only a one-way operation. For the WS-RM client we will use JDeveloper.
You can import the OSB project into Eclipse from \chapter-10\getting-ready\using-reliable-msg-with-ws-transport
.
First, let's change the proxy service to use the WS transport and add the reliable messaging policy. In Eclipse OEPE, perform the following steps:
Open the Provider proxy service and navigate to the Transport tab.
Select ws in the Protocol field to specify the WS transport.
Navigate to the Policy tab.
Select the...
In this recipe, we will implement reliable SOAP communication over JMS and not over HTTP. The only difference is that your request and response will be published on a queue. This way the request can't be lost (when it has JMS persistence with XA/QoS). The response will also be published on the queue and the client can consume this response.
For this recipe, we will use an OSB project with a proxy service that is based on a WSDL with a synchronous request/response operation. The SOAP message will be sent over JMS instead of HTTP. JDeveloper will be used to generate a test client:
You can import the OSB project into Eclipse OEPE from \chapter-10\getting-ready\sending-soap-over-jms
.