Compressing Server Responses in Java Enterprise Applications
In modern enterprise Java development, there are many ways to develop client/server communication. On the lower level, most communication over the wire occurs via HTTP. On the higher level, however, numerous technologies and APIs enable developers to facilitate client/server communication, including servlets, AJAX calls, RPC, numerous web services toolkits and APIs (e.g., Axis, WebLogic, Apache CXF, Xfire), and many others.
If you are using any of these technologies, chances are some or all of your client/server interaction also employs XML. XML is very useful in defining the structure of data being transferred over the wire (especially when communication is between two software systems, not humans). All web services use XML wrapped in SOAP envelopes (also represented in XML). AJAX and servlets can also talk XML, although they are not required to.
If your enterprise project uses XML for B2B or P2B communications, it is most likely also validates server requests and responses per a specific definition or schema. The XSD schema tells the server what the XML request and response may look like, which elements they must contain, and which elements are optional. With modern tools, you often can easily auto-generate both schema and XML from the Java object model (and vice versa) and have responses and requests validated automatically.
This article discusses the implementation of compression for server responses in Java enterprise applications, covering the benefits and drawbacks and detailing the technology design choices that may benefit from compression. It shows two different implementations of compression and explains how to test the end result with soapUI. The discussion focuses only on JEE-based application servers and assumes a familiarity with JEE project structure and technology in general.
Benefits and DrawbacksSo why would you need to compress anything in the context of client/server communication? Suppose a project is using XML heavily for communication, remembering that XSD schema was developed to be as descriptive as possible, with long element names and very complex structure.
Here is example of the project's XML schema, which references other schema files and is based on the OAGIS standard:
<?xml version="1.0" encoding="UTF-8"?> <xsd:schema XMLns:xsd="http://www.w3.org/2001/XMLSchema"
attributeFormDefault="unqualified"> <xsd:include schemaLocation="BOD.xsd"/> <xsd:include schemaLocation="../Components/PersonSchemaType.xsd"/> <xsd:complexType name="PersonBODSchemaType"> <xsd:complexContent> <xsd:extension base="sp:BusinessObjectDocumentSchemaType"> <xsd:sequence> <xsd:element name="DataArea" type="sp:PersonDataAreaType"/> </xsd:sequence> </xsd:extension> </xsd:complexContent> </xsd:complexType> <xsd:complexType name="PersonDataAreaType"> <xsd:sequence> <xsd:element ref="sp:Name"/> <xsd:element ref="sp:Phone" minOccurs="0" maxOccurs="unbounded"/> </xsd:sequence> </xsd:complexType> <xsd:element name="PersonBOD" type="sp:PersonBODSchemaType"/> </xsd:schema>
On top of that, the project employs web services, which add even more XML in the form of SOAP. The project is global and its datawrapped in XML and in SOAPtravels around the world. The large XML payload creates performance issues and traffic bottlenecks for the application and clients. The data needs to be compressed to avoid network delays.
This is just one possible scenario, but in general any server response that is composed of large text or binary output can be compressed for performance and transferred over the wire. For small responses, compression will not be beneficial because it involves processing cycles (for decompression) on both the server and the client; it actually may decrease performance. If the communication is not over long distances, you also should use compression with care, because its benefits may be negligible or equal to the drawback of decompression time.
Page 1 of 3