iDempiereがZKバージョンアップ対応で使用しているAtmosphereというライブラリ。
これは、いったい何なのか？
少し調べてみると、どうやら非同期通信のためのライブラリのようで
特にAjaxでは実現できないサーバ側からのイベント発生、いわゆるサーバからのPUSHをサポートするようだ。
HTTPアーキテクチャの歴史を整理すると、その位置づけはわかりやすく、
現在の2015年は、Ajaxの問題点が顕在化し、新たなアーキテクチャが求められている時期にあるといえるようだ。
Atmosphereも、そんな中、必要とされるであろうライブラリのようだ。
＜HTTPアーキテクチャの歴史概略とAtomosphere＞
①Webウェブページは、かつてページを丸ごと更新するのが主流。
スタンドアローンアプリケーションのように、特定のラベルだけを書き換えるなどの処理が難しく
ボタンを押下すると、ページを丸ごと更新する必要があった。
②2006年ごろからAjaxの流行、ページ上の一部だけを更新することが可能になり
リッチなWebページが増えていった。
Ajaxの技術はもともとJavaScriptに存在したもので新しいものではなかったが、
この時期まで使われることはほとんどなかった。
しかし、ネットワークのスピードが速くなったなどの外部要因とのマッチもあり、この時期から急に使われるようになった。
同時にJavascriptの重要性が増したり、Javascriptコードが複雑化してきたことを機に、jQueryを筆頭にJavaScriptのライブラリが充実していくこととなる。
③Ajaxの問題点が顕在化。新たなアーキテクチャが求められる。
Ajaxを使ったウェブページへのバージョンアップが一段落し、その問題点が顕在化してくる。
中でも、HTTPのコネクションのアーキテクチャ上、サーバからイベント発生ができないため、
たとえば、他のユーザの更新情報などをサーバからクライアントへ直接PUSHすることができず、
その代替として、ブラウザ側からサーバの更新を定期的にチェックするなどのコーディングが必要というのは大きな問題として認識された。（ネットワーク負荷やサーバ負荷の増大）
この問題への解決策として以下のようなアーキテクチャが生まれてきた。
・Cometを利用したWebSocket
とにかく接続をひらきっぱなしのストリーミング状態にして、サーバはこの接続を使ってクライアントへのイベントを発生させる。
接続がひらっきぱなしのため、リソースを非常に使ってしまうという問題がある。
CometというアーキテクチャをWebSocketという標準仕様で定義しようとしたが、
このWebSocketのAPI自体が各WebServerのAPIに依存してしまい、ベンダーロックインを引き起こす可能性があるようだ。
・Atmosphere
上記のような問題を解決するべく、WebSocketなどをベンダーロックインにならないように抽象化したりして
非同期通信のライブラリをまとめている。
具体的なコーディング方法や詳細は、これからまた調べていきたいと思う。
