Package project
This package facilitates development of XML messaging applications using
HTTP(S) POST requests.
See:
Description
Class Summary |
ExampleClient |
This class is a sample XML messaging client, supporting simple "echo" and
"uppercase" messages that accept pure text messages to show mechanics
of sending and receiving valid XML documents as messages over HTTP(S). |
ExampleServlet |
This servlet echoes or uppercases its input text. |
ExampleServlet.Executable |
Base class for simple execution framework. |
ExampleServlet.Uppercase |
Simple which, when executed, "uppercases" text (according
to the rules used in the server's locale). |
XmlRpcClient |
This class facilitates development of XML messaging clients which use
HTTP(S) POSTing to synchronously exchange XML documents. |
XmlRpcServlet |
This servlet facilitates development of HTTP/HTTPS based XML messaging
services, which add application-specific behaviours and handle specific
kinds of request and response documents. |
Package project Description
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,
- XML descriptions of data will generally be larger than
the corresponding binary description. This is increasingly a
non-issue as Internet bandwidth grows, and as HTTP/1.1 support
for data compression becomes widespread.
- The CPU overhead of processing text is slightly higher than that for
processing binary data. However, the overhead of parsing messages is
generally not significant in most application performance profiles, so a
slight increase in that cost will rarely be significant.
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:
- Identify the high level workflow protocols. These involve
at least two parties, with defined roles, and sets of messages
they exchange to accomplish their work.
- Define the document types (DTDs) for the messages exchanged
between those parties. In this particular implementation, these
will be both request and response messages. You may well be able
to reuse pre-existing libraries of DTD components.
- Write client code, probably using
XmlRpcClient
if the
client is written in Java. Of course, the whole idea behind
interoperable systems is that the clients and servers will commonly
be provided by different vendors, and hence may be in different
languages.
- Write server code, probably subclassing
XmlRpcServlet
if the server is in Java.
Clearly, and just like with any other request/response protocol, the
important work is to define the data that goes in the request and
response. This needs to be negotiated between the parties who will be
communicating using that protocol. Examples would be purchase orders
producing acknowledgements or rejections, defined according to some industry
DTD; or similarly, shipment notices producing acknowledgements. While
industry standard agreements for such processing will be very important,
custom or semi-custom agreements are a good starting point.
Avoid "Fine Grained" Messaging!
One thing to keep in mind is that web protocols should not be used
for lots of "fine grained" requests. While it's possible to do such
things, they don't relate well to the nature of the Internet as a
world-wide network where latencies are high and throughput is
increasingly a non-issue in extranet systems. Send larger "document
sized" blobs of data, rather than small "procedure call sized" ones.
Also, don't make users wait for responses! Have a thread handle the
remote call; and think hard about whether the server should do more than
just send an acknowledgement. It's bad practice to have synchronous
requests be outstanding for more than a short period of time.
Consider using a messaging system (such as the Java Messaging
Service JMS) for explicitly asynchronous messaging, in cases such
as second-tier servers sending messages to other back-end systems.
(You will find some code in this example useful for working with JMS.)
With XML capturing the logical structure your messages, you have much
flexibility about how they are routed: directly via HTTP(S), or using
any of a variety of alternative message transport frameworks.