はじめに
今日のエンタープライズJava開発でクライアント／サーバ間通信を実現する手段は数多く存在します。下層レベルの通信では、主としてHTTPが利用されます。しかし上層レベルでは、さまざまな技術やAPIを利用してクライアント／サーバ間通信を実現できます。例えば、サーブレット、AJAXコール、RPC、各種のWebサービスツールキットやAPI（例：Axis、WebLogic、Apache CXF、Xfire）などが利用できます。
これらの技術を利用する場合、クライアント／サーバ間通信の一部（あるいはすべて）においてXMLも利用する可能性があります。XMLはネットワーク上で伝送されるデータの構造を定義するのに非常に便利です（人間同士の通信ではなく、2つのソフトウェアシステム間で通信が行われる場合）。すべてのWebサービスは、XMLをSOAPエンベロープでラッピングして使用します（SOAPエンベロープ自体もXMLで記述されます）。AJAXおよびサーブレットでもXMLを使用できますが、使用しなくても構いません。
今日使われている多数のフレームワークやツールキット、例えばJava Springフレームワーク、HibernateやiBATISといったORMツールなども、内部の機能コンポーネントの構成や接続の部分でXMLに大きく依存しています。標準のJava EEコンテナも、配備記述子ファイルの解決とロードにXMLを利用しています。
エンタープライズプロジェクトでB2BあるいはP2B通信を実現するのにXMLを使用する場合、個々の定義あるいはスキーマごとにサーバのリクエストとレスポンスの検査が行われる可能性が高いと思われます。XSDスキーマは、XMLリクエスト／レスポンスの形式、それに含まれるべき要素、そしてどの要素が省略可能であるかをサーバに通知します。最近のツールの多くは、JavaオブジェクトモデルからスキーマとXMLを自動生成でき（その逆も可能）、レスポンスとリクエストの検査を自動的に実行する機能も備えています。
本稿では、Javaエンタープライズアプリケーションでサーバレスポンスを圧縮する方法、ならびにそのメリットとデメリットについて述べるとともに、圧縮によるメリットがある技術デザインの選択について解説します。また、2種類の圧縮実装方式を紹介し、soapUIを使って結果をテストする方法について説明します。本稿はJava EEベースのアプリケーションサーバだけを対象としており、読者がJava EEプロジェクトの構造および技術全般に関する知識を持っていることを前提としています。
メリットとデメリット
なぜクライアント／サーバ間通信でデータを圧縮する必要があるのでしょうか。仮に、あるプロジェクトの通信でXMLを多用しているとします。ここで注意してほしいのは、XSDスキーマはできる限り詳しい記述ができるように設計されたもののため、長い要素名と非常に複雑な構造を使用するという点です。
このプロジェクトのXMLスキーマの例を以下に示します。このスキーマは他のスキーマファイルを参照し、OAGIS標準に準拠しています。
<?xml version="1.0" encoding="UTF-8"?>
<xsd:schema XMLns:xsd="http://www.w3.org/2001/XMLSchema"
XMLns:sp="http://integration.standardandpoors.com/ServiceSchema/v3"
targetNamespace="http://some.com/ServiceSchema/v3" elementFormDefault="qualified"
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>
また、このプロジェクトはWebサービスを採用しているため、SOAPという形でさらにXMLを追加します。これはグローバルなプロジェクトであり、このデータ（つまりXMLとSOAPでラッピングされたデータ）は全世界を駆け巡ります。その大きなXMLペイロードは、アプリケーションやクライアントに対してパフォーマンス問題とトラフィックのボトルネックをもたらします。ネットワークの遅延を避けるには、データを圧縮する必要があります。
これは想定可能なシナリオの1つにすぎませんが、一般に、サーバレスポンスに大量のテキスト出力あるいはバイナリ出力が含まれる場合は、圧縮してからネットワークに送出した方がパフォーマンス向上につながります。データ量が少ないレスポンスの場合は、圧縮のメリットはあまり期待できません。サーバ側とクライアント側の双方で展開処理を行うため、そのぶんだけパフォーマンスが低下するからです。同様に、長距離間の通信ではない場合も、圧縮をすべきかどうかは慎重に検討した方がよいでしょう。展開処理の負荷によって圧縮のメリットがほとんど相殺されてしまうケースも考えられるからです。
