Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs
As the Simple Object Access Protocol (SOAP) and other XML remote procedure calls (RPCs) continue to grow in popularity, posting to a URL will become a more common and more important operation -- it is the method for sending the SOAP or RPC request to the respective server.
While implementing a standalone SOAP server, I stumbled upon multiple pitfalls associated with posting to a URL, starting
with the nonintuitive design of the URL-related classes and ending with specific usability pitfalls in the
HttpClient class would be the most direct way to perform an HTTP post operation on a URL, but after scanning the
java.net package, you'll come up empty. Some open source HTTP clients are available, but I have not tested them. (If you have tested those
clients, drop me an email regarding their utility and stability.) Interestingly, there is an
HttpClient in the
sun.net.www.http package that is shipped with the JDK (and used by
HttpURLConnection), but it is not part of the public API. Instead, the
java.net URL classes were designed to be extremely generic and take advantage of dynamic class-loading of both protocols and content
handlers. Before we jump into the specific problems with posting, let's examine the overall structure of the classes we will
use (either directly or indirectly).
This UML diagram of the URL-related classes in the
java.net package illustrates the classes' interrelatedness. (The diagram was created with
ArgoUML -- see Resources for a link.) For brevity's sake, the diagram shows only key methods and no data members.
Pitfall 5 centers on the main class:
URLConnection. However, you cannot instantiate that class directly -- it is abstract. Instead, you will receive a reference to a specific
URLConnection via the
Admittedly, the figure above is complex. The general sequence of events works like this: A static URL commonly specifies the
location of some content and the protocol needed to access it. The first time the
URL class is used, a
URLStreamHandlerFactory singleton is created. That factory generates an
URLStreamHandler that understands the access protocol specified in the URL. The
URLStreamHandler instantiates the appropriate
URLConnection class, which opens a connection to the URL and instantiates the appropriate
ContentHandler to handle the content at the URL.
So what is the problem? Because of the classes' overly generic design, they lack a clear conceptual model. In his book, The Design of Everyday Things (Doubleday, 1990), Donald Norman states that one of the primary principles of good design is a sound conceptual model that
allows us to "predict the effects of our actions." Some problems with the
URL classes' conceptual model include: