HTTPトランスポート上でのGZIPエンコーディングは、Webアプリケーションのパフォーマンスを向上させるよく知られた手法です。トラフィックの多いWebサイトでは、ユーザーへの応答を高速化するためにGZIPが使用されています。また圧縮は、ファイルのダウンロードや交換のためにファイルのサイズをより小さくする目的で広く使用されています。実際、XMLに関して言えば、GZIPの使用は最新の素晴らしい手法というわけでもありません。ATTのXMillなどの新しいテクノロジーでは、ほぼ同じ時間でZGIPの2倍の圧縮が可能だとされています。しかし、GZIPはJavaプラットフォームの中核的なコンポーネントであり、多くのWebサーバーは自身が提供するファイルやアプリケーションに関係なくコンテンツを圧縮することができます。このような理由から、この記事では、GZIPをAxis SOAPの実装と組み合わせて使用する方法について考察します。Axis SOAPとGZIPの組み合わせは、次のようなプロジェクトやソリューションに役立つと証明されています。すなわち、現在さらに高いパフォーマンスを必要とし、将来的に今後リリースされるSOAP実装と時間をかけて統合する予定のあるものです。さらに、この記事では、サーブレット・レベルでのエンコーディングについても考察します。これにより、別のコンテンツのエンコーディング・スキーム (符号化手法) を実装することも可能になります。

はじめに

これから説明する変更を実行するには、Apache Axisのソース・コードが必要です。しかし、ここで紹介する変更は、これ以外のSOAP実装に対してもほぼ同じように実行できるはずです。ここでは、基本となるHTTPSenderおよびAxisServletのコードを変更します。使用するサーバーが自動的に圧縮を処理する場合、サーブレットは不要ですが、サーブレットを変更することで、別のエンコーディング・ソリューションを組み込むためのフレームワークが用意されます。

ここでの目標は、基本となるSOAP実装を機能面で変更することなく、GZIPによる圧縮機能を追加することです。java.util.zipはストリームを基にしていますので、これは比較的簡単です。また、Axisやその他のソリューションでHTTP接続を作成する基本的なコードもストリームを基にしています。

上に戻る

JavaテクノロジーとGZIPの概要

この記事では、java.util.zipパッケージの使用について詳細に説明することはしません。このパッケージの内容に関しては、Sunを始めとして、その他の多くの場所で提供されています (参考文献を参照してください)。

java.util.zipパッケージには、他のストリームをエンコードするために必要なすべてのものが用意されています。具体的には、GZIPInputStream およびGZIPOutputStream オブジェクトを使用します。どちらのオブジェクトもストリームを引数に取ります。コンテンツのエンコーディングを確認できれば、ストリームを適切にラップすることができます。圧縮と解凍の複雑な処理自体は、これらのオブジェクトが実行します。もちろん別のフォーマットでエンコードとデコードを実行する場合は、入出力ストリームを展開してください。

サーバー側では、2つの方法でコンテンツのエンコーディングを処理できます。第1の、そして望ましい方法は、アプリケーション・サーバーの前面にあるWebサーバーで圧縮を処理することです。Webサーバーを構築し、圧縮されたコンテンツのエンコーディングをサポートするクライアントを識別し、要求された出力コンテンツをそのフォーマットにエンコードすることができます。Webサーバーでは、この動作のほとんどが動的に実行されるため、現在あるハードウェアでこれを実行すると、わずかながらオーバーヘッドが生じます。第2の方法は、アプリケーション自身でコンテンツをエンコードすることです。この方法は、パフォーマンス、必要なコード量、および必要なメンテナンスにおいて、最初の方法よりも高くつきます。しかしCGIやサーブレットを使用して、クライアントが受け付けるエンコーディングの種類を簡単に判別し、適切にエンコードされた応答を返すことができます。この方法は、Webサーバーで一般に使用されていない種類のエンコーディングを使用している場合に便利です。最終的には、負荷はネットワークからサーバーおよびクライアントへ移っていきます。しかし、約半分の量にしたデータをネットワークで転送することによって得られるパフォーマンスがこの負荷を補うほどのものであるかどうかについては、まだ議論の余地があります。

とにかく、目標は透過的な処理の実現、すなわち、入出力ストリームをインターセプトして、適切なGZIPストリームに送り込むことです。いたって単純な目標です。それではさっそく始めることにしましょう。

上に戻る

サーバー側の改造: AxisServletの変更

このセクションでは、AxisServletを変更して圧縮を可能にする方法を説明します。HTTPサーバーの設定にアクセスできない場合や、サーバーが圧縮をサポートしない場合には、この方法を使用する必要があります。この技術は、異なる方式のエンコーディングを可能にする最初のステップにもなります。

Webサーバー層ではなく、アプリケーション層でエンコーディングを実行するのは非常に簡単です。この方法は、一般に使用されているサーバーやモジュールではサポートされていないエンコーディング方式を使用する計画がある場合に特に便利です。この記事で紹介するすべてのコード変更と同様に、これらの変更もいくつかの方法で実装できます。たとえば、AxisServletを継承してHTTPServletResponse を実装することにより、出力ストリームをインターセプトできます。

まず最初にAccept-Encoding ヘッダーを調べるため、doPostメソッドを変更します。クライアントがGZIPエンコーディングを受け付けると示していれば、それを信頼することにします。ユーザー・エージェント・ヘッダーを確認し、圧縮を処理できるクライアントに対してのみ圧縮が実行されるようにしてください。ただし、ほとんどのブラウザーはRPCRouterを使用しないため、これを気にする必要は極めて低いはずです。クライアントがGZIPエンコーディングを受け付ける場合は、GZIPサポートを示すBooleanをtrueに設定します。リスト1 のコードを確認してください。

                
String encoding = req.getHeader("Accept-Encoding"); 
if (encoding != null) {
if (encoding.toLowerCase().indexOf("gzip") > -1){supportsGzip = true;}
}

次にsendResponseメソッドへ移ります。現在の接続がGZIPをサポートしているかどうかを確認するためのコードをいくつか追加します。GZIPがサポートされている場合は、応答ヘッダーContent-Encoding をgzipに設定し、応答の出力ストリームをGZIP出力ストリームでラップします。これ以降は、出力ストリームをフラッシュする必要があることや、ストリーム・バッファーの最後のビットが送信されない可能性があることを除けば、すべて元と同じようなコーディングになります。この修正により、呼び出している根本的なWebサービスが何であるかを問わず、GZIPエンコーディングが可能になります。このことから考えて、特殊なコンテンツ・エンコーディングを有効にすることも非常に簡単なはずです。リスト2 のコードを参照してください。

                
if (supportsGzip == true) {

// Set the response header.
// Note that response is an HttpResponse instance.

        res.setHeader("Content-Encoding", "gzip");
    GZIPOutputStream gzos = new GZIPOutputStream(res.getOutputStream());
            responseMsg.writeTo(gzos);
        gzos.flush();
        gzos.close();
            //gzip code end             
} else {
            	
        res.setContentType(contentType);
        /* My understand of Content-Length
         * HTTP 1.0
         *   -Required for requests, but optional for responses.
         * HTTP 1.1
         *  - Either Content-Length or HTTP Chunking is required.
         *   Most servlet engines will do chunking if content-length is not specified.
         */
                responseMsg.writeTo(res.getOutputStream());         
}

上に戻る

クライアント側の改造: HTTPSenderの変更

Axisのソース・コードを見慣れていないユーザーがコードを見て気付くことは、単に他のHTTPクライアント・オブジェクトを継承しているだけではないということだと思います。コードでは、実際にはHTTPクライアントがソケット・レベルで独自に実装されています。このようにする理由はさまざまですが、明白な理由の1つは、私がこれから説明するような変更を行うためです。ここではwriteToSocketとreadFromSocketの2つのメソッドに注目します。

GZIP対応の通知

最初にすべきことは、クライアントを変更して、そのクライアントが圧縮を処理できることをサーバーに示すことです。ここで注意しなければならないのは、すべてのWebクライアントが、自身が宣言したとおりにエンコーディングを処理できるとは限らないということです。サーバーが使用するエンコーディング規則を検証できない場合は、アプリケーション・レベルでエンコーディングを行うサーブレットを用いて、エンコーディング規則を検査することをお勧めします。サーバーが特定のユーザー・クライアントに対応するよう設定されている可能性は十分にあります。その場合、別途エンコーディングを用意すると重複した作業になってしまします。アクセスが可能であれば、サーバーが目的のユーザー・エージェントに対してエンコーディングを提供しているかどうかを確認してください。ログやSOAPのトレース情報を簡単に参照することによって、ユーザー・エージェント・ヘッダーが設定されているかどうかを確認できると思います。問題を簡単にするためにも、そうであってほしいところです。とにかく、この件については読者におまかせするしかありません。

ここでは、ヘッダーをAccept-Encoding に設定します。このHTTPヘッダーは、文字列値 (多くの場合値のリスト) を格納します。リスト3 をご覧ください。ここでは値gzipを使用しています。ヘッダーを追加する場合は、HTTPSenderのコードを変更する必要があります。ここでヘッダーが処理されます。ざっと見ただけで、ヘッダーを追加するための枠組みがあることがわかると思います。ただし、この時点で処理されるヘッダーはAccept-Encoding ではありません。この記事では、エンコーディングをハード・コーディングしておきます。HTTPヘッダーの組み込みと設定の方法は、読者が決定してください。これには、多くの方法があります。ここでは、リスト4 のようなわずかなコードを挿入します。要求ヘッダーを取り出して、ハッシュ・テーブルにキャストしています。ここでは、サーバー側での圧縮を開始させるヘッダーを追加します。圧縮は、Webサーバーとアプリケーション・サーバーのどちらかで行われるものとします。

                
GET / HTTP/1.1
Accept: */*
Accept-Language: en-us
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; .NET CLR 1.0.3705)
Host: www.ibm.com:80
Connection: Keep-Alive

                
//process user defined headers for information.
Hashtable userHeaderTable = 
(Hashtable) msgContext.getProperty(HTTPConstants.REQUEST_HEADERS);
                
//Adding Accept-Encoding header to the hashtable.
if(userHeaderTable == null){userHeaderTable = 
new Hashtable();} userHeaderTable.put("Accept-Encoding", "gzip");

要求したものを取得する

gzipという値を持つAccept-Encoding ヘッダーを組み込むようにHTTP要求を変更したら、次はそのコンテンツの読み取りに使用するメソッドを変更する必要があります。また、HTTPヘッダーのコンテンツ・エンコーディングを確認して、サーバーがGZIPで応答したかどうかを確認する必要もあります。サーバーがGZIPで応答していれば、入力ストリームをGZIP 入力ストリームでラップします。GZIPエンコーディングが検出されない場合は、入力ストリームはそのままにします。Axis開発者が使用している現在のプロセスを妨げないようにするためにも、このコードを配置しておくことは重要です。入力ストリームは、HTTPメッセージの本文がデコードされる直前、かつヘッダーが解析された直後に変更する必要があります。ソケットをラップする前にコンテンツのエンコーディングを知る必要があることを忘れないでください。リスト5 のコードは、readFromSocketメソッドのどこにGZIPのコードが挿入されているかを示しています。このコードでInputStream が宣言されていることに注目してください。この変数は、GZIPInputStream か、パラメーターで渡されるInputStream のいずれかの型になります。この時点から、Axisは、圧縮されたストリームから読み取りを行っているのかどうか、それを読み取るべきかどうかを認識しなくなります。これで、根底にあるコードを意識することなくGZIPエンコーディングの要求と処理を実行するAxisクライアントができました。

                
if (null != transferEncoding && 
transferEncoding.trim().equals(HTTPConstants.HEADER_TRANSFER_ENCODING_CHUNKED)) {
	inp = new ChunkedInputStream(inp);
}

//Check the content encoding. If it is gzip then
//wrapper the input stream as a GZIPInputStream

   
String zip = (String)headers.get("content-encoding");
InputStream is = null;
if(zip.indexOf("gzip") != -1){
	GZIPInputStream zipIn = new GZIPInputStream(inp);
	is = zipIn;
} else {
      	is = inp;
}
//end gzip code
outMsg = 
new Message( new SocketInputStream(is, sock), false, contentType, contentLocation);

上に戻る

まとめ

HTTP上のGZIPエンコーディングは、ご存知のとおりWebテクノロジーの一部です。次のステップとしてGZIPエンコーディングを既存のWebサービス・フレームワークで使用することは、理にかなった努力です。しかし多くのソリューションが日々SOAPの実装上で設計、構築、および開発されています。SOAPエンベロープでGZIPエンコードを可能にすることにより、結果的には比較的少ないオーバーヘッドでトランザクションを高速化できるというケースがたくさんあります。このパフォーマンスの向上は、いくつかの簡単なコードの変更によって、今すぐ実現することができます。現在のSOAP環境でGZIPエンコーディングを有効にすることにより、望ましい実装形態への統合を待つこの瞬間にも、圧縮のメリットを享受することができるのです。

参考文献

• 以下の記事では、ここで取り上げたテクノロジーに関するさらに詳細な情報を入手できます。
  • HTTP Compression Speeds up the Web (webreference.com)
  • Compressing and Decompressing Data using Java APIs (java.sun.com、2002年2月)
  • XMLの論考: XMLと圧縮 (developerWorks、2001年9月)
  • A Comparison of Alternative Encoding Mechanisms for Web Services (Computer Science Dept., University of Southern California)
  
  
  
• Apache Axis については、apache.orgのWebサイトをご覧ください。
  
  
• SOAPのエンコーディングについてさらに詳しくお知りになりたい方は、Frank Cohen氏の記事「Discover SOAP encoding's impact on Web service performance」(developerWorks、2003年3月) を参照してください。
  
  

著者について

この記事を評価する

コメント

上に戻る

目次

• はじめに
• JavaテクノロジーとGZIPの概要
• サーバー側の改造: AxisServletの変更
• クライアント側の改造: HTTPSenderの変更
• まとめ
• 参考文献
• 著者について
• コメント