JMS over XML-RPC With Http protocol
- Posted by: satya ranjan
- Posted on: February 04 2006 13:51 EST
This article describes how JMS can be used over XML-RPC using Http protocol.
XML-RPC is used to call remote method by sending/receiving data in XML format. But in some critical applications where data reliability is most important, XML-RPC doesn't give guarantee of data delivery. So to ensure that message will be delivered to the receiver , we have to fit some messaging framework with XML-RPC. That messaging framework should be intelligent enough to handle system failure or any acknowledgment from the receiver. So after the sender sends the message, messaging framework handles the proper delivery of the message to the receiver.
Virtually all XML-based transactions will take place in a loosely coupled environment , where connectivity can't be guaranteed, unpredictable latency is the course of the day, transactions require security.
Developing a function that requires communication between two distributed components can be surprisingly difficult when you consider all the possible failure scenarios. Consider the case of a program sending a purchase request to another program over a network. If the message is not delivered and the sender is not made aware of the delivery failure, then the purchase request will be lost. If the message is delivered more than once and the target is unaware of these multiple deliveries, then too many purchases will occur.
Reliable messaging refers to the ability of a sender to deliver a message once and only once to its intended receiver. It is a necessary building block for most non-query communication between programs. The basic method for achieving reliable delivery is for the sender to send the message repeatedly to the target until the target acknowledges receipt of the message. The message must contain an identifier of some kind so that the target will discard any duplicates it receives. While this should be simple task to perform, it is surprisingly difficult to achieve in the full context of possible failures and acceptable efficiency.
For example, consider the task of resending a message. If the sender_s server goes down the sender may lose its copy of the message and, therefore, will not be able to resend it. For this reason, senders need to record the message in a reliable store until it is definitely delivered. Furthermore, the sender frequently needs to make a record of the fact that the request has been sent (that is, the sender needs to record the fact that the business process in which it is participating has moved to the next step).
To carry this task out reliably, the sender needs to send the message and update its record of the transmission in a single transaction. This is quite a difficult task to perform efficiently. The only simple way to do it is to hold the transaction open for the entire process, which lengthens the lock holding time at both the sending and receiving ends and reduces system throughput.
What Is JMS?
The Java Message Service is a Java API that allows applications to create, send, receive, and read messages.
It provides enough features to support sophisticated messaging applications.
The JMS API enables communication that is not only loosely coupled, but is also:
Asynchronous: A JMS provider can deliver messages to a client as they arrive; a client does not have to request messages in order to receive them.
Reliable: The JMS API can ensure that a message is delivered once and only once. Lower levels of reliability are available for applications that can not afford to miss messages or receive duplicate messages. If there is no receiver for a message while sending the message, the message will be stored in the JMS Server and will be delivered to the receiver when it comes up next time.
XML-RPC With JMS
JMS server can communicate between client using many protocols like RMI, TCP/IP, HTTP etc. Most of the current application servers support JMS using RMI protocol. I am not sure how many of them support JMS over Http.
A Sample design for JMS with XML-RPC
All Messages are transferred in XML format.
app1.war is deployed on appserver 1.
JMSapp.war is deployed on same appserver 1.
app2.war is deployed outside firewall on appserver2.
app3.war is deployed outside firewall on appserver3
Only 80 port is opened for outside firewall from appserver1. So that it can communicate with outside application only using Http protocol.
A topic “JMSTopic” is added to JMS Server.
app2.war is started.
app2.war calls registerListener() on appserver1 (app1.war).
Listener1 is created with JMSTopic for app2.
app1.war sends a message to JMSApp.war. Which goes to JMSTopic. JMSApp.war exposes some xml api which allows to send data to JMSTopic.
After getting message, the listeners for JMSTopic try to send the message to app2.war which is on appserver2.
JMSApi.war calls the xml-rpc api method of app2.war to send the message to original destination.
To optimize the performance we can create multiple Topic/queue for each remote component.
FWIW a few JMS providers do support HTTP as a transport. e.g.
We have an application which does,t have any Front end and is using JMS for sending and recieving messages.... protocol that they use to communicate the client and server is JMS, T3 (Web Logic specific EJB calls)... can any one tell me the approach how can we go for Laod Testing ... Please consider it as urgent.
More important is to know when simple rpc mechanisms might be better than JMS.