WS-RM is not a the ugly duck of the story and need more attention from community because it allows you to design solutions where you will be able to
- Guaranty of message (= web services) delivery required by example in financial order processing, alarm monitoring systems, ...
- Control the communication between the client and the server (retransmission, ...)
- Implement asynchronous solution by decoupling the request from the reply
Well, what I have presented could be assimilated to a style exercise or a faith act and you will adhere or not. To convince you about the interests to use WS-RM, I will show you How easy it is to design such a solution using Apache CXF framework. This process can be achieved in three simple steps
- A. Turn on your WSDL contract into a WS-addressing
WS-addressing needs to be used because the communication between the client and server will be governed by the Reliable Message Server which is running on a different
port address number. This decoupling is required to allow to retransmit message, acknowledge the messages received and guaranty the delivery
Here is one way that you can adopt :
the other consists in to use a Policy Rule (= WS-Policy)
- B. Activate the Reliable Server
Now that the WSDL contract is modified, we need to add the Reliable Server to the configuration of our platform. I will show you using a spring xml configuration file
but you can use the Apache CXF classes in your java code if you want
To activate the RM server, you simply needs to add the tags wsa:addressing and wsrm-mgr in the bus definition of Apache CXF. Different parameters are available like
retransmission interval, acknowledge interval. I will not digg into these ones and if you need information, I invite you to check Apache CXF javadoc and specifications. By example
ikt is possible to activate also the persistence manager of the RM server ;-)
If you use CXF in combination with the Routing engine Apache Camel, you don't need to do additional things as the Apache CXF endpoint who will consume the web servicesmessages
will be drived by the RM server of CXF.
Here is an example of Camel integration with CXF
// messages are consumed from CXF endpoint
// the body of the WS message is converted directly into a POJOI
// We call a POJO to save the reportincident in a DB
// We put the object in a queue
// We provide a feedback message as the WS is of type request/replyt
- C. Verify
If you use a java client using Apache CXF java classes, you can easily enable the logging of the IN/OUT WS messages exchanged with the RM server and the application.
The following trace shows that :
- a sequence has been started
- each message is identified '' with a UID
- Within a sequence, the messages send receive a messageID
- The server acknowledge the reception (= processing) of the messages
Awesome, isn'it. Even, if you continue to doubt about this specification, I'm pretty sure that in the future you will take it into account into your decision process regarding
to what has been developed here.