On 7/23/07, Kevin Brown <[EMAIL PROTECTED]> wrote:
I'm hoping to modify my existing xml-rpc interface to use a JMS transport rather than HTTP. I want the reliable delivery of JMS and am losing a small percentage of messages using http. Is there a good reason for me not to attempt to add a JMS transport to apache xml-rpc? i.e., because maybe everyone just uses Mule to do this, or JMS is not suitable for xml rpc (despite that people use it for soap), etc. Any comments appreciated.
Funny idea. The only problem I can think of, is that with JMS you cannot work synchronously. In other words, you've got to implement some kind of listener for the incoming replies, because JMS is a one-way transport. Apart from that, it should work fine. The XmlRpcStreamTransport is an abstract class, which was explicitly designed for use beyond HTTP. I suggest taking it as a starting point. Jochen -- "Besides, manipulating elections is under penalty of law, resulting in a preventative effect against manipulating elections. The german government justifying the use of electronic voting machines and obviously believing that we don't need a police, because all illegal actions are forbidden. http://dip.bundestag.de/btd/16/051/1605194.pdf --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
