This chapter is from the book
This chapter is from the book
This chapter is from the book
ElectricXML
The Mind Electric's ElectricXML [http://www.themindelectric.com/exml/] is yet another tree-based API for processing XML documents with Java. It has a reputation for being particularly easy to use. It's also small. The JAR archive for ElectricXML 4.0 is about 10 percent the size of the JAR archive for dom4j 1.3.
Finally, the Mind Electric has claimed in the past that ElectricXML is much faster and more memory efficient than DOM and JDOM. However, their benchmarks were a little too scant and a little too contrived to convince me.
Example 5.9 shows this chapter's standard example program implemented in ElectricXML. As with the previous examples, the input number is read from the command line. This is wrapped up in an XML request document built in memory using the ElectricXML API, which is then serialized onto an output stream connected to the server. Finally the server's response document is read and parsed.
Example 5.9 An ElectricXML-Based Client for the Fibonacci XML-RPC Server
import java.net.*;
import java.io.*;
import electric.xml.*;
public class FibonacciElectricXMLClient {
private static String defaultServer
= "http://www.elharo.com/fibonacci/XML-RPC";
public static void main(String[] args) {
if (args.length <= 0) {
System.out.println(
"Usage: java FibonacciElectricXMLClient number url"
);
return;
}
String server = defaultServer;
if (args.length >= 2) server = args[1];
try {
// Build request document
Document request = new Document();
request.setRoot("methodCall");
Element methodCall = request.getRoot();
Element methodName = methodCall.addElement("methodName");
methodName.setText("calculateFibonacci");
Element params = methodCall.addElement("params");
Element param = params.addElement("param");
Element value = param.addElement("value");
// Had to break the naming convention here because of a
// conflict with the Java keyword int
Element intElement = value.addElement("int");
intElement.setText(args[0]);
// Transmit the request documentf
URL u = new URL(server);
URLConnection uc = u.openConnection();
HttpURLConnection connection = (HttpURLConnection) uc;
connection.setDoOutput(true);
connection.setDoInput(true);
connection.setRequestMethod("POST");
OutputStream out = connection.getOutputStream();
request.write(out);
out.flush();
out.close();
// Read the response
InputStream in = connection.getInputStream();
Document response = new Document(in);
in.close();
connection.disconnect();
// Walk down the tree
String result = response.getRoot()
.getElement("params")
.getElement("param")
.getElement("value")
.getElement("double")
.getTextString();
System.out.println(result);
}
catch (Exception e) {
System.err.println(e);
}
}
}
By this point, you should be experiencing a sense of déjà vu. The creation of the XML-RPC request document is very similar to the way it's done in dom4j. Navigation of the response document to locate the double element is very similar to the way it's done in JDOM. There are only so many plausible ways to design a tree-based API for processing XML. The most original part of the ElectricXML API is that no separate serializer class is used to write the document onto the OutputStream. Instead the Document, Element and other classes have a write() method. The OutputStream onto which the node will be serialized is passed to this method. Each node takes responsibility for its own serialization.
My major technical concern about ElectricXML is that it has achieved its reputation for ease of use primarily by catering to developers' preconceptions and prejudices about XML. In other words, the API is designed around what developers think the XML specification says, rather than what it actually does say. For example, ElectricXML routinely deletes white space in element content (sometimes mistakenly called ignorable white space), even though the XML specification explicitly states, “An XML processor must always pass all characters in a document that are not markup through to the application.” The client application is free to ignore white space characters if it doesn't need them, just as it is free to ignore anything else it doesn't need; but the parser is not free to make that decision for the client application. Worse yet, the ElectricXML namespace model focuses on namespace prefixes rather than namespace URIs. This certainly matches how most developers expect namespaces to work, but it is not in fact how they do work. I agree that the XML's namespace syntax is needlessly complicated and confusing. Nonetheless, an XML API cannot fix the problem by pretending that namespaces are less complicated than they really are. ElectricXML may feel easier at first than more XML-compatible APIs such as SAX, DOM, and JDOM, but it's bound to cause more pain in the long run.
I also have one major nontechnical concern about ElectricXML. Whereas all of the other APIs discussed here are released as various forms of open source, ElectricXML is not. The license [http://www.themindelectric.com/products/xml/licensing.html] limits what you're allowed to do with the software, including preventing you from competing with it, thereby prohibiting necessary forks. Still, ElectricXML is free beer, and source code is provided.