読めない時流のWebSocket

このようなタイトルで執筆させていただきます、シンメトリックの新入社員の青木です。先週の記事の始まりに記述した通り、引き続き研修の一環ということで、オセロの制作過程を記していきます。

1. 今週の目標
2. 行ったアプローチ
3. 作業結果
4. 課題

今週の目標

通信対戦型オセロということで、重要な機能として、ブラウザAが送信したものがブラウザBにいかに反映させるかが肝であると目星を付けました。そのような機能とはつまり何かと調べてみると、サーバーからプッシュする技術とのことなのですが、これにはAjax、Comet、WebSocketといった種類の技術がありました。

ではこれらの中で何を選択するかですが、まず、私の心のうちで漠然とですが通信についてのソースをJAVAに寄せたいという気持ちがありました。調べてみるとAjaxはJavaScriptに寄っている雰囲気があったのでここで除外しました。ではCometかWebSocketのどちらかというと、WebSocketのほうが新しい技術らしく、さらに接続の手法的に軽快なのでよしとする論調のWebサイトが多く見受けられたので、WebSocketを選択しました。ということで今週の目標として、WebSocket技術を用いてブラウザ間での送信を即時反映させるということを設定しました。

行ったアプローチ

技術とは言いましたが技術ってなんなんでしょうというところから始まりました。まあ当然の選択肢として検索エンジン攻めしてみると、どうやらサーバーサイドのJAVAコードにて用意されているクラスを主に記述してブラウザ側には数行だけ記述すれば求められる動作をしてくれるらしいのはわかりました。なんだかお手軽に見えます。

この調べる過程で参考になるようなコードを見てみると、90%のWebサイトでWebSocketを用いたチャットを作っていました。私が今回のオセロ制作でほしい機能というのはクリックし次第その情報が反映される程度ですので、ではこれらのWebサイトを参考にして1ブラウザがボタンを押したら別ブラウザにも即時反映する程度のプログラムを作ることにしました。今もJAVAの細かい部分の意味はわからないですが、参考コードの見た目の文字列の意味と一致具合で構造を把握すればできそうという印象です。

というわけで、とりあえず参考コード各種を適当にeclipseに張り付けて実際の動作を見てみることを始めます。とりあえずWebSocketとその関連ワードで検索して出てきたので参考にさせていただこうとしたWebページ群を並べてみます。

これらのページをそのまま動作させてみようととしたのですが……まずEclipseにおけるTomcatプロジェクトのディレクトリ構成をわかってないことに気づきました。各種Webサイトにはたいてい「サーバーサイド」「ブラウザサイド」という言葉が散見されるのですが、わざわざディレクトリ構成を掲載しているパターンにあまり遭遇しませんでした。やっとのことでディレクトリ構成について理解しつつも各種ファイルの紐づけがなっておらず動かないなどと苦戦していました。

せっかくなのでEclipseにおけるTomcatプロジェクトのディレクトリ構成について、記憶の整理名目で画像としてここに記しておきます。

WEB-INFの中がEclipse上の表記だとだとわかりにくかったので、エクスプローラーで開いた時の画像が次です。

web.xmlというのを記述してWEB-INFの中には絶対に入れなければならない風潮が昔はあったらしいのですが、今アノテーションといってクラスファイルのほうに組み込める仕組みがあるということで今回はそれを利用しました。（画像ではweb.xmlを残してあります。）

この部分を理解する段階でこじれて時間を食ったのですが、そもそも、間違っているのがディレクトリ構成だけならばそれほど時間使わなかったのに、と今思います。同じタイミングで、JAVAコードの頭でimport宣言するべきクラスが盛大に間違っていました。とはいっても参考サイト先が間違っていたわけではありません。WebSocketという技術を使うためのパッケージは古いものと新しいものがあるらしく、今や古いとされるコードを掲載した参考サイトのSEOが強かったがために古いパッケージの自己主張も強かったのでつい使ってしまいました。古くて使用を推奨されないものですので、Eclipseの機能として認識を拒否するために動作しませんでした。ここにそのパッケージを記しておきます。

org.apache.catalina.websocket

古くて推奨されないことが原因とはいえ、検索エンジン利用ではその時系列が原因で動作しないという認識に至るのが困難でした。今使用しているEclipseの初期設定でそのようなパッケージの認識を拒否する機能があるとは思わなかったので、今週はこの段階ででこじれにこじれました。複数の要因があり動作しない原因の認識に遅れが出たのですが、このようについには突き止めることができました。ついでなので新しいほうのパッケージを記しておきます。

javax.websocket

こちらを使用しているコードを参考にして目標のコードを作りました。

作業結果

ボタンを押すと押した回数の分だけ数字が増えて、その数字が別のブラウザ上でも同様に増えたうえでその別ブラウザから押しても元の数を引き継いで増えるといったような形で組みました。画像で恐縮ですがそのような動作をしました。アプローチにて述べたような問題をクリアしてしまえばチャットの構造をそのまま軽く変えるというのは簡単でした。

課題

今回学んだこととして、パッケージなどには古い新しいがあるということがあります。このプログラムを動かしてみたのはローカルの上ですので、本番環境とは違います。つまり、本番環境を今のローカルの環境に寄せることができなければ、バージョン違いによって何かが動作しない可能性が大いにあるということです。ですので課題としてはその乖離を押し込められるかどうかというところになります。

とはいえ、サーバーブラウザ間の通信面での目標はここで一段落として、次週よりDBについての感覚を養ったりブラウザで走らせる実際のオセロのプログラムのロジックに関して考えるつもりです。次週よりとは書きましたがゴールデンウィークという存在があるため、次回更新は再来週になりますのでよろしくお願いします。