This package facilitates development of XML messaging applications using HTTP(S) POST requests. It consists of a servlet, used to accept the incoming messages in Java-enabled web application servers, and a client side class which may be used in a variety of environments including applets, servlets, and "applications". Both the servlet and the client side "proxy" class may be subclassed to add application specific behaviors, such as handling specific kinds of request and response XML documents.

Because the message formats and protocols are standard, there is no absolute requirement that the client or server in such a system use Java. PERL, C/C++, or other languages could also be used to develop components in such system frameworks.

HTTP/HTTPS for Messaging

Using XML over the HTTP/HTTPS set of protocols is only one of the many ways to do request/response (synchronous) protocols. Advantages of this approach over more traditional RPC frameworks include:
Web-Ready
This advantage almost goes without saying, but it's important. The Internet and RPC systems have been around for decades, but it's HTTP/HTTPS based tools which brought those kinds of technologies to widespread attention and finally caused the level of explosive growth that had been anticipated for years.
Simpler Debugging
Many developers who work at the applications level value messages in readable text, which can be easily debugged. Even the simplest binary protocols (such as XDR) are awkward to debug, and most of them (CDR, ASN.1/BER, NDR, etc) are much worse.
Selective Firewall Tunneling
There is widely available support for selectively tunneling HTTP/HTTPS through firewalls, which is generally unavailable with other messaging protocols. Firewalls are a fact of life in today's extranet environments, used when building systems that connect businesses to other businesses, because they are needed protect each organization's precious information resources. Such firewalls could examine XML documents and selectively pass them through.
Open Systems Development Process
XML can support a much more open development style than most RPC systems, since you are not forced to use any single vendor's framework or tools. (Most RPC systems do not live up to their promise of being fully open and multivendor frameworks!) The requirement is only to provide valid XML documents for the task at hand ... not to use any particular "Brand X" products.
Recipient-Controlled Decoding Options
The focus of XML is on the data in the message. The recipient controls how data in the message maps to code, such as Java classes, representing business objects. Of course, the sender can provide suggestions on that topic, but the recipient is free to ignore them for reasons of self-protection. Using XML Namespaces, one can easily create generic message forwarding "hubs" that understand enough of the content to handle messages appropriately.
World-Wide Security is Available Today
HTTPS is by far the most widely deployed secure protocol in the world, helping manage the risks associated with wiretapping attacks. Also, of major significance, it works with world wide Public Key Infrastructure (PKI) systems which can already be used to authenticate businesses to each other anywhere in the world, rather than relying on smaller scale systems usable only within companies.

The primary downsides relate to potential performance issues. Specifically,

Despite these potential disadvantages, many organizations are now designing systems which exchange XML documents using HTTP/HTTPS due to the compelling advantages of such frameworks.

Designing with XML Messaging

Clients and servers normally work with XML documents as represented by DOM objects; these are transformed to XML text format while they are sent as part of an HTTP(S) POST request or response. These documents will often be valid standalone documents, which do not refer to external entities; or else they will be valid documents using specific DTD files which will be efficiently cached by both clients and servers.

In this particular implementation of an XML Messaging framework, clients pass DOM documents into an XmlRpcClient.call() method, implicitly directed to a given URL, and receive documents back. Servlets receive such a DOM document in their XmlRpcServlet.rpc() method, along with the URL identifying the object to which the request was sent. Then they return another DOM document.

That is, to design using XML Messaging you need to: