Featured White Papers

• Measuring Risk to Improve Java Software Quality
• Do You Really Get Classloaders?
• Pragmatic Continuous Delivery with Jenkins, Nexus, and LiveRebel
• Your Next Java Web App: Less XML, No Long Restarts, Fewer Hassles
• Coding with JRebel, Java Forever Changed
• 2012 Developer Productivity Report: Java Tools, Tech, Devs, and Data

Sponsored Links

• Graph databases are 1000x faster than relational.

  Learn More!

• Career opportunities at Harman- Careers That'll Rock Your Socks Off.

  Learn More!

• Developer-friendly Java PDF libraries by Qoppa Software

  Live Demos

• Stop blaming your app! Diagnose Java performance issues.

  Free tool >

• UrbanCode: Go From Continuous Integration to
  Continuous Delivery

  Learn More!

Sponsored Links

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

Server-side Java: Build distributed applications with Java and XML

Use Xbeans to process your XML as DOM Documents

By Bruce Martin, JavaWorld.com, 02/21/00

Page 3 of 5

Analysis

Table 1 summarizes the advantages (+) and disadvantages (-) of each approach. The description of each follows.

Table 1. Summary of three approaches to communicating XML

Space and time

Surprisingly, the performance results presented below indicate that a textual representation of XML is a far more efficient representation than a serialized DOM representation. Also, the time required to externalize a DOM representation and reparse the textual form is cheaper than the direct Java serialization and deserialization of the DOM. See the "Performance results" section below for more details.

Ubiquity of infrastructure

The advantage of the standard Web-server approach is that the infrastructure to support it is ubiquitous. The CGI script can be executed from most Web servers. Further, the receiver is easily identified through a URL. The naming infrastructure is already in place. The RMI solution, on the other hand, requires the RMI registry.

The CORBA solution requires the installation of a CORBA Object Request Broker on the server. Further, the CORBA implementation of the sender uses a URL naming scheme whereby the CORBA object reference of the receiver, represented as a string, is associated with a URL and translated at the client.

Programming and execution model

CORBA and RMI support a natural Java-client-to-Java-server solution. There is no CGI script and no need to read encoded exceptions from standard input. Further, there is no need to start a Java Virtual Machine each time a sender wants to communicate some XML. Both CORBA and RMI support automatic activation of the receiver.

Interoperability

The Java RMI solution works only between Java code, while the Web server, and in theory the CORBA solution, can work between programming languages. (The CORBA solution, in theory, because adding XML support to the CORBA standard is in progress. Again, the code shown here uses Java serialization.)

But even if the requirement that both the client and the server must be in Java code were not a problem, another interoperability obstacle exists with Java serialization of the DOM. Java serialization requires that the same implementation of the DOM be running at both the client and the server.