第 3 回 Web サーバーと Socket.IO

各種の Web コンテナー、API、抽象化ライブラリーを使用する

Mathieu Carbou
配信 2011年 10月 07日

コンテンツシリーズ

このコンテンツは全#シリーズのパート#です：リバース Ajax

https://www.ibm.com/developerworks/jp/views/global/libraryview.jsp?series_title_by=リバース+ajax

このシリーズの続きに乞うご期待。

このコンテンツはシリーズの一部分です：リバース Ajax

このシリーズの続きに乞うご期待。

はじめに

私たちは最近では、高速で動的なアプリケーションに Web からアクセスすることを期待します。リバース Ajax 手法を適用したイベント駆動型 Web アプリケーションの開発方法を探るこの連載では、第 1 回でリバース Ajax、ポーリング、ストリーミング、Comet、そしてロング･ポーリングを紹介しました。そのなかで学んだように、リバース Ajax を確実に実装するには、今やすべてのブラウザーがサポートを提供している HTTP ロング・ポーリングを使用した Comet が最善の手段となります。第 2 回ではもう 1 つのリバース Ajax 手法として、WebSocket を使用してリバース Ajax を実装する方法を紹介し、サンプル・コードを使用して、WebSocket、FlashSocket、サーバー・サイドの制約、リクエスト・スコープ・サービス、そして長期間存続するリクエストを一時停止する方法を説明しました。

今回の記事では、各種の Web コンテナーおよび API (Servlet 3.0 および Jetty の Continuation) を対象に、Web アプリケーションで Comet と WebSocket を使用する方法について詳しく探ります。そのなかで、Socket.IO のような抽象化ライブラリーを利用して、Comet と WebSocket をトランスペアレントに使用する方法を学んでください。Socket.IO は機能の検出によって、WebSocket、Ajax ロング・ポーリング、Flash など、どの手段を使って接続を確立するかを判断します。

記事で使用するソース・コードは、ここからダウンロードすることができます。

前提条件

この記事を最大限活用するには、JavaScript および Java の知識があると理想的です。記事のサンプル・コードは、Java で作成された依存性注入フレームワークである Google Guice を使って作成されています。記事の内容を理解するには、依存性注入フレームワーク (Guice、Spring、Pico など) の概念を理解している必要があります。

この記事のサンプルを実行するには、最新バージョンの Maven および JDK も必要です (「参考文献」を参照)。

Comet および WebSocket のサーバー・ソリューション

第 1 回では、Comet (ロング・ポーリングまたはストリーミング) では、サーバーがリクエストを一時停止し、長期間にわたることもある遅延の後にリクエストを再開または完了する必要があることを学びました。第 2 回では、サーバーが多数の接続を処理するためにはノンブロッキング I/O (NIO) 機能を使用する必要があること、そしてサーバーはスレッドだけを使用してリクエストに対応する仕組み (thread-per-request モデル) を説明しました。また、WebSocket を使用できるかどうかはサーバーによって異なり、すべてのサーバーが WebSocket をサポートするわけではないことも学びました。

このセクションでは、Jetty、Tomcat、および Grizzly といった Web サーバーで Comet および (適用可能な場合には) WebSocket を使用する方法を紹介します。この記事に付属のソース・コードには、Jetty および Tomcat 対応のサンプル・チャット Web アプリケーションが含まれています。このセクションではまた、JBoss、Glassfish、WebSphere の各 Web アプリケーション・サーバーでサポートされる API についても説明します。

Jetty

Jetty は、Java Servlet 仕様 3.0 と WebSocket、そしてその他多くの統合仕様をサポートする Web サーバーです。Jetty には以下の特徴があります。

強力かつ柔軟です。
簡単に組み込むことができます。
仮想ホスト、セッション・クラスタリング、そして Java コードまたは XML で簡単に構成できる多数の機能をサポートします。
Google App Engine がホストするサービスに使用されています。

コア Jetty プロジェクトは、Eclipse Foundation によってホストされています。

バージョン 6 以降の Jetty には、Jetty Continuations という非同期 API が組み込まれています。Jetty Continuations では、リクエストを一時停止し、後から再開することができます。表 1 に、Jetty ファミリーの主なバージョンと、サポートされる仕様および API の対応を示します。

表 1. Jetty のバージョンとサポートされる仕様および API

サポートされる仕様および API	Jetty 6	Jetty 7	Jetty 8
ノンブロッキング I/O	X	X	X
Servlet 2.5	X	X	X
Servlet 3.0		X	X
Jetty Continuations (Comet)	X	X	X
WebSocket		X	X

Comet によってリバース Ajax を実装するには、Jetty の Continuation API を使用することができます (リスト 1 を参照)。

リスト 1. Comet に対応する Jetty Continuation API

// Pausing a request from a servlet's method (get, post, ...):

protected void doGet(HttpServletRequest req, HttpServletResponse resp) 
        throws ServletException, IOException { 

Continuation continuation = ContinuationSupport.getContinuation(req); 
// optionally set a timeout to avoid suspending requests for too long 
continuation.setTimeout(0); 
// suspend the request 
continuation.suspend(); 
// then hold a reference for future usage from another thread 
continuations.offer(continuation); 

}

// Then, from another thread which wants to send an event to the client:

while (!continuations.isEmpty()) { 
    Continuation continuation = continuations.poll(); 
    HttpServletResponse response = 
        (HttpServletResponse) continuation.getServletResponse(); 
    // write to the response 
    continuation.complete(); 
}

完全な Web アプリケーションは、記事に付属のソース・コードに含まれています。Jetty Continuation は JAR アーカイブにバンドルされています。この JAR ファイルを Web アプリケーションの WEB-INF/lib フォルダーに配置すると、Jetty の Comet 機能を使用できるようになります。Jetty Continuation は、Jetty 6、7、および 8 で機能します。

Jetty 7 からは、WebSocket 機能も使用できようになっています。Jetty の WebSocket API にアクセスするには、Jetty の WebSocket JAR ファイルを Web アプリケーションの WEB-INF/lib フォルダーに配置してください (リスト 2 を参照)。

リスト 2. Jetty の WebSocket API

// Implement the  doWebSocketConnect and returns an implementation of
//  WebSocket:

public final class ReverseAjaxServlet extends WebSocketServlet { 
    @Override 
    protected WebSocket doWebSocketConnect(HttpServletRequest request,
                                           String protocol) { 
        return [...] 
    } 
}

// Sample implementation of  WebSocket:

class Endpoint implements WebSocket { 
    Outbound outbound; 
    public void onConnect(Outbound outbound) { 
        this.outbound = outbound;    
    } 
    public void onMessage(byte opcode, String data) { 
        outbound.sendMessage("Echo: " + data);
        if("close".equals(data)) 
             outbound.disconnect();
    } 
    public void onFragment(boolean more, byte opcode, 
                           byte[] data, int offset, int length) { 
    } 
    public void onMessage(byte opcode, byte[] data, 
                          int offset, int length) { 
        onMessage(opcode, new String(data, offset, length)); 
    } 
    public void onDisconnect() { 
        outbound = null; 
    } 
}

この記事からダウンロード可能なソース・コードには、jetty-websocket フォルダー内にサンプル・チャット・アプリケーションが用意されています。このサンプルに、Jetty の WebSocket API を使用する方法が示されています。

Tomcat

Tomcat はおそらく最も広く知られている Web サーバーでしょう。Tomcat は長年使用されていて、JBoss アプリケーション・サーバーの初期のバージョンには Web コンテナーとして組み込まれていました。Tomcat はサーブレット仕様のリファレンス実装としても使用されていましたが、人々がノンブロッキング I/O をベースとした代替手段 (Jetty など) に目を向けるようになったことから、Tomcat によるリファレンス実装は Servlet 2.5 API で廃止されました。表 2 に、最新の 2 つの Tomcat ファミリーのバージョンでサポートされる仕様と API を記載します。

表 2. Tomcat のサポート

サポートされる仕様および API	Tomcat 6	Tomcat 7
ノンブロッキング I/O	X	X
Servlet 2.5	X	X
Servlet 3.0		X
Advanced I/O (Comet)	X	X
WebSocket

表 2 に示されているように、Tomcat は WebSocket をサポートしませんが、Comet をサポートするために、Jetty の Continuation に相当する Advanced I/O という API を備えています。Advanced I/O は、Comet を使いやすくするための優れた API というよりは、NIO をラップする下位レベルのラッパーに近いものです。Advanced I/O のドキュメントは乏しく、この API を使用したアプリケーションはわずか数例しかありません。リスト 3 に、チャット Web アプリケーションでリクエストを中断および再開するために使用するサンプル・サーブレットを記載します。完全な Web アプリケーションは、記事に付属のソース・コードに含まれています。

リスト 3. Comet に対応する Tomcat API

public final class ChatServlet extends HttpServlet 
                               implements CometProcessor { 

    private final BlockingQueue<CometEvent> events = 
         new LinkedBlockingQueue<CometEvent>(); 

    public void event(CometEvent evt) 
        throws IOException, ServletException { 

        HttpServletRequest request = evt.getHttpServletRequest(); 
        String user = 
            (String) request.getSession().getAttribute("user"); 
        switch (evt.getEventType()) { 
            case BEGIN: { 
                if ("GET".equals(request.getMethod())) { 
                    evt.setTimeout(Integer.MAX_VALUE); 
                    events.offer(evt); 
                } else { 
                    String message = request.getParameter("message"); 
                    if ("/disconnect".equals(message)) { 
                        broadcast(user + " disconnected"); 
                        request.getSession().removeAttribute("user"); 
                        events.remove(evt); 
                    } else if (message != null) { 
                        broadcast("[" + user + "]" + message); 
                    } 
                    evt.close(); 
                } 
            } 
        } 
    } 

    void broadcast(String message) throws IOException { 
        Queue<CometEvent> q = new LinkedList<CometEvent>(); 
        events.drainTo(q); 
        while (!q.isEmpty()) { 
            CometEvent event = q.poll(); 
            HttpServletResponse resp = event.getHttpServletResponse();
            resp.setStatus(HttpServletResponse.SC_OK);
            resp.setContentType("text/html");
            resp.getWriter().write(message);
            event.close(); 
        } 
    } 
}

Tomcat では、非同期サーブレットが CometProcessor を実装する必要があります。非同期サーブレットの場合、Tomcat は標準の HTTP メソッド (doGet、doPost など) を呼び出しません。代わりに、event(CometdEvent) メソッドにイベントが送信されます。上記のサンプル・コードでは、リクエストが最初に到着した時点で、それが GET リクエストであるかどうかを調べ、該当する場合にはリクエストを中断します。この場合、evt.close() は呼び出されません。リクエストが POST の場合には、ユーザーがメッセージを送信したことを意味するため、リクエストは別の CometEvent にブロードキャストされます。そしてこの POST リクエストを完了するために、evt.close() が呼び出されます。クライアント・サイドでは、ブロードキャストによってすべてのロング・ポーリング・リクエストが送信メッセージを完了することになります。その直後に、次のイベントを受信するために別のロング・ポーリング・リクエストが送信されます。

Grizzly と Glassfish

Grizzlyは Web コンテナーではなく、むしろ開発者がスケーラブルなアプリケーションを構築できるようにするための NIO フレームワークです。Grizzly は Glassfish プロジェクトの一部として開発されましたが、スタンドアロンまたは組み込みベースで使用することもできます。Grizzly は HTTP/HTTPS サーバーとして機能するコンポーネントと、Bayeux Protocol、Servlet、HttpService OSGi、および Comet などに対応するコンポーネントを提供します。Glassfish では、WebSocket をサポートする Grizzly を使用して、Comet および WebSocket のサポートを提供します。

Oracle のアプリケーション・サーバーである Glassfish は、J2EE 6 仕様のリファレンス実装です。Glassfish は WebSphere や JBoss と同じくすべてを完備したスイートで、Grizzly を使用して NIO、WebSocket、および Comet をサポートします。OSGI をベースとしたそのモジュール式アーキテクチャーにより、実に柔軟にコンポーネントを変更できるようになっています。表 3 に、Comet および WebSocket に対する Glassfish のサポート状況を示します。

表 3. Glassfish のサポート

サポートされる仕様および API	Glassfish 2	Glassfish 3
ノンブロッキング I/O	X	X
Servlet 2.5	X	X
Servlet 3.0		X
Comet	X	X
WebSocket		X

Grizzly は組み込みベースまたは Java コードから直接使用するように意図されているため、その使用法は簡単なものではありません。Grizzly はComet および WebSocket のサポート・フレームワークとして広範に使用されており、Web デプロイメント機能および Servlet 仕様 API を提供する Glassfish のような大規模なアプリケーションに組み込むことができます。

Grizzly または Glassfish での WebSocket および Comet のサンプル･コードについては、「参考文献」に記載されているリンクにアクセスしてください。Glassfish は Grizzly を使用することから、これらのサンプル･コードはこの両方で機能するはずです。WebSocket API は、Jetty での WebSocket API と非常によく似ていますが、Comet API は Jetty よりも複雑です。

JBoss

JBoss は、Tomcat をベースとしたアプリケーション・サーバーです。バージョン 5 以降、JBoss は Comet および NIO をサポートするようになっています。JBoss 7 は現在開発中ですが、以下の表 4 に記載しておきます。

表 4. JBoss のサポート

サポートされる仕様および API	Jboss 5	Jboss 6	Jboss 7
ノンブロッキング I/O	X	X	X
Servlet 2.5	X	X	X
Servlet 3.0		X	X
Comet	X	X	X
WebSocket

WebSphere

WebSphere は IBM のアプリケーション・サーバーです。Servlet 3 API (Comet 用に標準化された非同期 API が含まれます) のサポートは、WebSphere バージョン 8 で追加されました (発表レターを読むには、「参考文献」を参照)。

表 5. WebSphere のサポート

サポートされる仕様および API	WebSphere 8
ノンブロッキング I/O	X
Servlet 2.5	X
Servlet 3.0	X
Comet	X
WebSocket

共通の API を持つことの意味

各サーバーは、Comet および WebSocket にそれぞれ独自の API で対応しています。ご想像のとおり、このことが、移植可能な Web アプリケーションの作成を困難にする場合があります。Servlet 3.0 仕様では、この仕様をサポートするすべての Web コンテナーが Comet のロング・ポーリング・リクエストをサポートできるように、リクエストを一時停止して後で再開するためのメソッドを追加しています。

Jetty チームが提供している Jetty Continuation というライブラリーは、Jetty コンテナーからは独立しています。Jetty Continuation ライブラリーは、使用可能なコンテナーまたは仕様を検出できるだけの賢さを備えていて、Jetty サーバーで実行した場合にはネイティブ Jetty API が使用され、Servlet 3.0 仕様をサポートするコンテナーで実行した場合には、この共通 API が使用されます。それ以外の場合には、非スケーラブルな実装が使用されます。

WebSocket に関しては、Java にはまだ標準がありません。したがって、WebSocket を使用する必要がある場合には、Web アプリケーション内でコンテナー・ベンダーの API を使用する必要があります。

表 6 に、各種のサーバーでサポートされている手法を要約します。

表 6. 各サーバーがサポートする手法

コンテナー	Comet	WebSocket
Jetty 6	Jetty Continuation	使用不可
Jetty 7	Servlet 3.0 Jetty Continuation	ネイティブ Jetty API
Jetty 8	Servlet 3.0 Jetty Continuation	ネイティブ Jetty API
Tomcat 6	Advanced I/O	使用不可
Tomcat 7	Servlet 3.0 Advanced I/O Jetty Continuation	使用不可
Glassfish 2	ネイティブ Grizzly API	使用不可
Glassfish 3	Servlet 3.0 ネイティブ Grizzly API Jetty Continuation	ネイティブ Grizzly API
JBoss 5	ネイティブ JBoss API	使用不可
JBoss 6	Servlet 3.0 ネイティブ JBoss API Jetty Continuation	使用不可
JBoss 7	Servlet 3.0 ネイティブ JBoss API Jetty Continuation	使用不可
WebSphere 8	Servlet 3.0 Jetty Continuations	使用不可

WebSocket の場合、コンテナー API を使用する以外に明らかなソリューションはありません。Comet に関しては、Servlet 3.0 仕様をサポートするコンテナーはいずれも Comet をサポートします。Jetty Continuation の利点は、これらのコンテナーのすべてで Comet サポートを提供することです。そのため、一部のリバース Ajax ライブラリー (次のセクション、およびこの連載の次回の記事で説明します) は、Jetty Continuation をサーバー・サイドの API として使用しています。

Jetty Continuation API は、この記事の Jetty サンプル・コードに示されています。Servlet 3.0 仕様は、この連載の第 1 回で説明した 2 つの Comet サンプル・コードで使用しました。

抽象化ライブラリー

主要なすべての API (Servlet 3.0 と Jetty Continuations) に加え、サーバー・サイドのすべてのネイティブ・サポート、そしてクライアント・サイドでの主な 2 つのリバース Ajax 手法 (Comet および WebSocket) を考え合わせると、これらを結び付ける独自の JavaScript および Java コードを作成するのは、難しい作業になる可能性があります。さらに、タイムアウト、接続失敗、確認応答、順序付け、バッファリングなども考慮に入れる必要があります。

この記事の残りでは Socket.IO の動作を説明し、連載の第 4 回で Atmosphere と CometD について詳しく探ります。この 3 つのオープンソースのライブラリーはいずれも、多くのサーバーで Comet と WebSocket をサポートします。

Socket.IO

Socket.IO は、リモート・サーバーに接続して非同期でメッセージを送受信する、WebSocket に似た単一の API を提供する JavaScript クライアント・ライブラリーです。共通の API を提供することによって、Socket.IO は複数のトランスポート、具体的には WebSocket、Flash Socket、ロング・ポーリング、ストリーミング、Forever Iframe (隠し iframe)、および JSONP ポーリングをサポートします。Socket.IO はブラウザーの機能を検出し、使用可能な最善のトランスポートの選択を試みます。Socket.IO ライブラリーは、ほぼすべてのブラウザー (IE 5.5 などの古いブラウザーも含む) に対応するだけでなく、モバイル・ブラウザーにも対応します。さらに、ハートビート、タイムアウト、切断、エラー処理などの機能も備えています。

Socket.IO の Webサイト (「参考文献」を参照) に、このライブラリーが機能する仕組み、そして使用されているブラウザーとリバース Ajax 手法に関する詳細が説明されています。基本的に、Socket.IO が使用する通信プロトコルにより、クライアント・ライブラリーは Socket.IO プロトコルを理解できるサーバー・サイドのエンドポイントと通信できるようになります。Socket.IO は当初、より高速なサーバーを作成するための JavaScript エンジンである Node.js のために開発されました。そして Java をはじめとする JavaScript 以外の言語のサポートが、多くのプロジェクトによって提供されました。

リスト 4 に、クライアント・サイドで Socket.IO JavaScript ライブラリーを使用するサンプル・コードを記載します。ドキュメントとその他のサンプル・コードについては、Socket.IO Web サイトを参照してください。

リスト 4. Socket.IO クライアント・ライブラリーの使用法

var socket = new io.Socket(document.domain, { 
    resource: 'chat' 
}); 
socket.on('connect', function() { 
    // Socket.IO is connected
}); 
socket.on('disconnect', function(disconnectReason, errorMessage) { 
    // Socket.IO disconnected
}); 
socket.on('message', function(mtype, data, error) { 
    // The server sent an event
});

// Now that the handlers are defined, establish the connection:
socket.connect();

Socket.IO JavaScript ライブラリーを使用するには、これに対応する Socket.IO Java という名前の Java パーツが必要です (「参考文献」を参照)。このプロジェクトは当初、WebSocket が使用可能になる前に Apache Wave チームによって開始されました。その目的は Wave にリバース Ajax のサポートをもたらすことです。その後、Socket.IO Java は分岐して Ovea (イベント駆動型 Web 開発を専門とする企業) によって保守されるようになり、やがて廃止されました。Socket.IO クライアント・ライブラリーをサポートするバックエンドを開発するのは、複数のトランスポートがサポート対象となることから複雑です。この連載の第 4 回でも説明するように、クライアント・ライブラリーで多数のトランスポートをサポートしても、必ずしもスケーラビリティーとブラウザーのサポートを改善することにはなりません。これは、ロング・ポーリングと WebSocket を使用すれば十分なためですが、WebSocket が使用できなかった頃は、Socket.IO は実に有効な選択肢でした。

Socket.IO Java は、Jetty Continuation API を使用して、リクエストを一時停止および再開します。WebSocket サポートには、ネイティブ Jetty WebSockets API を使用します。この点から、Socket.IO Java を使用した Web アプリケーションで、どのサーバーが正しく動作するのかを判断することができます。

以下に記載するリスト 5 は、サーバーで Socket.IO を使用する場合のサンプル・コードです。サーバーで Socket.IO を使用するには、SocketIOServlet を継承するサーブレットを定義し、ある種のエンドポイント表現を返すメソッドを実装する必要があります。この API は、WebSockets API と非常によく似ています。Socket.IO の利点は、クライアント・サイドでどのトランスポートが選ばれるかに関係なく、サーバー・サイドで使用できることです。これは、Socket.IO はサーバー・サイドで、すべてのトラスポート・タイプを同じ API に変換するためです。

リスト 5. サンプル・チャット・アプリケーションに使用した Socket.IO Java ライブラリー (サーブレット)

public final class ChatServlet extends SocketIOServlet { 
    private final BlockingQueue<Endpoint> endpoints = 
        new LinkedBlockingQueue<Endpoint>(); 
 
    @Override 
    protected SocketIOInbound doSocketIOConnect
                                        (HttpServletRequest request) { 
        String user = 
                (String) request.getSession().getAttribute("user"); 
        return user == null ? null : new Endpoint(this, user, request); 
    } 
 
    void broadcast(String data) { 
        for (Endpoint endpoint : endpoints) { 
            endpoint.send(data); 
        } 
    } 
 
    void add(Endpoint endpoint) { 
        endpoints.offer(endpoint); 
    } 
 
    void remove(Endpoint endpoint) { 
        endpoints.remove(endpoint); 
    } 
}

リスト 6 に、エンドポイントを返す方法を示します。

リスト 6. サンプル・チャット・アプリケーションに使用した Socket.IO Java ライブラリー (エンドポイント)

class Endpoint implements SocketIOInbound { 
 
    [...]
 
    private SocketIOOutbound outbound; 
 
    [...]

    @Override 
    public void onConnect(SocketIOOutbound outbound) { 
        this.outbound = outbound; 
        servlet.add(this); 
        servlet.broadcast(user + " connected"); 
    } 
 
    @Override 
    public void onDisconnect(DisconnectReason reason, 
                             String errorMessage) { 
        outbound = null; 
        request.getSession().removeAttribute("user"); 
        servlet.remove(this); 
        servlet.broadcast(user + " disconnected"); 
    } 
 
    @Override 
    public void onMessage(int messageType, String message) { 
        if ("/disconnect".equals(message)) { 
            outbound.close(); 
        } else { 
            servlet.broadcast("[" + user + "] " + message); 
        } 
    } 
 
    void send(String data) { 
        try { 
            if (outbound != null 
    && outbound.getConnectionState() == ConnectionState.CONNECTED) { 
                outbound.sendMessage(data); 
            } 
        } catch (IOException e) { 
            outbound.close(); 
        } 
    } 
 
}

Socket.IO の完全なサンプル・コードは、ソース・コードの socketio フォルダーに含まれています。

まとめ

Comet は、すべての Web コンテナーでサポートされます。WebSocket にしても、ほぼすべてのWeb コンテナーでサポートされます。仕様が結果的に複数の異なるネイティブ実装になったとしても、共通の API (Servlet 3.0 または Jetty Continuations) によって、Comet を使用した Web アプリケーションを開発することができます。さらに良いことには、Socket.IO のようなライブラリーを使用すれば、Comet と WebSocket の力をトランスペアレントに利用することが可能になります。この連載の次回の記事では、さらに 2 つのライブラリー、Atmosphere と CometD について取り上げます。この 3 つのライブラリーはいずれも、マルチブラウザー・サポートと素晴らしいユーザー・エクスペリエンスを提供するだけでなく、エラー処理、簡易化された API、タイムアウト、そして再接続の利点ももたらします。

ダウンロード可能なリソース

このコンテンツのPDF
Article source code (reverse_ajaxpt3_source.zip | 21KB)

目次

第 3 回 Web サーバーと Socket.IO

コンテンツシリーズ

このコンテンツは全#シリーズのパート#です：リバース Ajax

このコンテンツはシリーズの一部分です：リバース Ajax

はじめに

前提条件

Comet および WebSocket のサーバー・ソリューション

Jetty

表 1. Jetty のバージョンとサポートされる仕様および API

リスト 1. Comet に対応する Jetty Continuation API

リスト 2. Jetty の WebSocket API

Tomcat

表 2. Tomcat のサポート

リスト 3. Comet に対応する Tomcat API

Grizzly と Glassfish

表 3. Glassfish のサポート

JBoss

表 4. JBoss のサポート

WebSphere

表 5. WebSphere のサポート

共通の API を持つことの意味

表 6. 各サーバーがサポートする手法

抽象化ライブラリー

Socket.IO

リスト 4. Socket.IO クライアント・ライブラリーの使用法

リスト 5. サンプル・チャット・アプリケーションに使用した Socket.IO Java ライブラリー (サーブレット)

リスト 6. サンプル・チャット・アプリケーションに使用した Socket.IO Java ライブラリー (エンドポイント)

まとめ

ダウンロード可能なリソース

関連トピック

コメント

目次

第 3 回 Web サーバーと Socket.IO

コンテンツシリーズ

このコンテンツは全#シリーズのパート#です： リバース Ajax

このコンテンツはシリーズの一部分です：リバース Ajax

はじめに

前提条件

Comet および WebSocket のサーバー・ソリューション

Jetty

表 1. Jetty のバージョンとサポートされる仕様および API

リスト 1. Comet に対応する Jetty Continuation API

リスト 2. Jetty の WebSocket API

Tomcat

表 2. Tomcat のサポート

リスト 3. Comet に対応する Tomcat API

Grizzly と Glassfish

表 3. Glassfish のサポート

JBoss

表 4. JBoss のサポート

WebSphere

表 5. WebSphere のサポート

共通の API を持つことの意味

表 6. 各サーバーがサポートする手法

抽象化ライブラリー

Socket.IO

リスト 4. Socket.IO クライアント・ライブラリーの使用法

リスト 5. サンプル・チャット・アプリケーションに使用した Socket.IO Java ライブラリー (サーブレット)

リスト 6. サンプル・チャット・アプリケーションに使用した Socket.IO Java ライブラリー (エンドポイント)

まとめ

ダウンロード可能なリソース

関連トピック

コメント

このコンテンツは全#シリーズのパート#です：リバース Ajax