2013年9月9日、日本Javaユーザグループとhtml5jえんぷら部で共同開催「業務システムのためのHTML5勉強会#04」は、GREE様の会場提供で六本木の森タワーにて開催されました。

テーマは「Web x Java⁠」⁠。WebとJavaを組み合わせたWebシステム開発が、どのような方向に向かっているのか、どういう技術により実現されるのかを探る目的で開催されたイベントです。

「Webの技術」では、jQueryの登場が、インタラクティブなフロントエンド実現を容易にし、HTML5の普及でさらに拍車を掛けます。フロントエンドの開発は、マルチデバイス対応、ポリフィル・シムから、ビルドプロセスにテストツールと、様々な技術要素が絡み合います。そして、数年前には想像もつかないほどの高い専門性と、複雑な課題を持つ技術領域に変化しました。

一方で「Javaの技術」も、Java EEと呼ばれる標準を通じて、サーバサイドからWebアプリケーション開発の高度化に貢献しています。最近では、HTML5対応機能を強化したJava EE 7がリリースされ、WebSocketなどのステートフルな通信への対応が注目を集めています。Java標準もまた、着実に進化を続けているのです。

Web標準とJava標準、エンタープライズの鉄板とも言える2つの技術。これらがどこへ向かおうとしているのか理解することは、エンタープライズシステムの未来を理解すると言っても過言では無いでしょう。

本記事の筆者は、Web技術者コミュニティ「html5jえんぷら部」の部長であり、本イベントの司会を担当している川田（@kawada_hiroshi）です。筆者の持つ、業務系Webシステムデベロッパの視点から、本イベントの講演内容を紹介します。

エンタープライズは「Next Struts」が必要

「業務系システムはNext Strutsが必要」そう語るのは、html5jえんぷら部のスタッフであり、業務系フロントエンドエンジニアとして活動する小川充氏（@mitsuruog）です。

本イベント企画の中心人物の一人でもある小川氏は、オープニングトークとして次のように語りました。

Webアプリケーションはしっかりとしたバックエンドがないと成り立たちませんが、2013年の今も、J2EE+Struts1.X+JSPの組み合わせが依然として多いという状況です。Struts1.Xという、サポート切れのフレームワークが使われているのです。

国内の多くの業務系WebアプリケーションがStrutsを脱却できず、それどころか、レガシーなJavaの技術の上で独自のフレームワークが構築されます。それはまるで、ミルフィールのような構造と化しているのではないでしょうか。

業務系Webアプリケーションは多くの場合、問題の改善のために新しい技術の力を借りるのでなく、レガシーな技術へフレームワーク・ライブラリを追加するという選択を行っているように思えます。それが結果として、業務系Webアプリケーションのガラパゴス化を進行させています。Java本来のコモディティ化の思想から外れ、特定の技術によるロックイン化が進んでいます。

この状況の脱出の鍵は、仕様の「標準化」ではないでしょうか。

例えば、Webブラウザはかつて独自実装に走っていましたが、HTML5で状況は変わり、独自機能が標準化によりコモディティ化されつつあります。そして、Webアプリケーションはポータビリティを獲得しつつあります。

Javaも同じく、サードパーティ・フレームワークの機能が、Java自体の標準へ組み込まれつつあります。StrutsやSpringが解決した課題を、標準化されたAPIで解決しようとしているのです。また最近は、Scalaのような革新的な技術も生れており、別のアプローチも試みています。

本日は、これらJava/Scala技術の専門家の方に、Web技術の視点から情報を共有していただけることになりました。私はこの勉強会が、「⁠Next Struts」のきっかけになると期待しています。

Strutsをやめる理由? エンドユーザの視点から?

「Strutsをやめて、標準技術であるJava EEを利用すべきだ」そう語るのは、日本Oracleのエバンジェリスト寺田佳央氏（@yoshioterada）です。

寺田氏はJava標準利用のメリットを「エンドユーザの視点」から次のように語りました。

Java EEは、Javaの標準技術の一つです。Java EEは標準技術であるため、製品間の移植性の高い、ポータビリティに優れたアプリケーションを開発できるというメリットがあります。

10年前のデファクト・スタンダードは、Struts + Spring + Hibernateでした。10年前は確かにこれが正しかったのですが、10年経った今もこれが本当に正しいでしょうか。

Struts1.Xはご存知の通りEOLを迎えました。オープンソースのフレームワークであるため、皆様自身がこれからも、Strutsをメンテナンスするという覚悟があるのであれば、利用しても良いでしょう。今後発生するバグ・脆弱性などの問題に対して、全て自分たちで対応していけるのであれば、利用を視野に入れても良いはずです。

しかし、フレームワークの世界のトレンド、例えばEclipseユーザは新規開発の際に、Struts1どころか2でさえも殆ど選択していないようです。そして、Strutsの世界シェアは現在1.3%にまで低下しました。何故でしょうか？

Struts + Spring + Hibernateの3重構成は、セキュリティの脆弱性への対応、ライブラリ間の相性、そしてバージョンアップ継続という問題を持ちます。瑕疵担保の期間中は、これらの問題を開発ベンダ側で対応すれば良いでしょう。しかし、瑕疵期間が終了すると、これらはエンドユーザがメンテナンスしなくてはいけません。

問題が起きたら、フレームワークに組み込まれたバラバラの製品を、全てエンドユーザ側でテストしなくてはいけません。セキュリティの問題、ライブラリ間の相性、バージョンアップ、そのリスクをエンドユーザが理解して使っているならば問題ありませんが、実態としてそうでないケースが多いという状況でしょう。そしてそれが、企業活動にとっての大きなダメージになることがあるのです。

そもそもエンドユーザは、こういったフレームワークを構成するバラバラの製品に絡んだ課題について、悩むことを望んでいないでしょう。しかし今は、フレームワークの機能がJava EEとして標準化され、アプリケーションサーバの中にオールインワンで入っています。

脆弱性や不具合対応のためのパッチが必要になった場合、アプリケーションサーバのベンダにより単一化されたサポートが行われるため、エンドユーザはこれまでのような問題に悩まされる必要はありません。フレームワーク内はベンダ側でテストされるため、エンドユーザ側でのテストコストも小さくなります。

─⁠─Strutsをやめる「技術面」でのメリットは何でしょうか。次頁ではいよいよ、本イベントのテーマである、Java標準と新しいWeb技術の接点について、ご紹介します。

Strutsをやめる理由? デベロッパの視点から?

前頁では、StrutsをやめてJava標準でWebアプリケーションを作らなくてはいけない理由について、「⁠エンドユーザの視点」で考えてみました。OSSによる独自技術でなくJavaの標準技術を使うことで、運用のリスクを最適化することができるという内容です。

本頁では見方を変えて、「⁠デベロッパの視点」から考えてみましょう。Oracleエバンジェリストの寺田氏は、Java標準によるWeb開発を、次世代型と従来型の2種類に分類しました。

1. 次世代型：クライアントとサーバ間をデータのみで通信し、画面の生成から表示までをクライアントで行う方式。
2. 従来型：サーバ側でデータを埋め込んだ画面を生成し、クライアントでは表示のみを行う方式。

1. 次世代型WebアプリケーションとJava標準「Java EE 7」

近年、JavaScriptを使って画面の生成を完全にクライアント側で行う方式が広がっています。Backbone.jsやAngularJSなどのクライアントサイドフレームワークを使うようなケースです。

Oracleの寺田氏は、このような次世代型のWebアプリケーション実現方法について「Java EE 7」からいくつかの機能を挙げ、次のように語りました。

Java EE 7は、HTML5、モバイル・アプリ開発の究極のプラットフォームです。ローンチイベントには、世界から1万超が参加しています。

以前のJava EEは、イベントを開いてもあまり注目されることはありませんでしたが、今では支持を得るようになり、様々な企業システムで活用されるようになりました。

Java EE 7でどの機能に興味があるかアンケートしたところ、WebSocket、バッチ、JAX-RS、JSON-P、並列処理と、多くがHTML5に関連した機能に関心を集めているようでした。

次世代型のWebアプリケーションでは、基本的にはJavaScriptで多くの処理を行い、以下のような通信技術を利用して、データのみをサーバとやり取りします。

• JSON 1.0
• JAX-RS 2.0
• WebSocket 1.0

WebSocketとは、HTTPを使って接続をし、HTTPをアップグレードしたWebSocketプロトコルを使って通信を行います。簡単に言うなら、HTTPの中に独自のクライアント-サーバのソケットを作り上げることができるメカニズムです。

通信の技術として、WebSocketもしくはJAX-RSを利用できますが、サーバ側とクライアント側でぞれぞれ簡単に実装できるようになっています。データ・フォーマットも、JSONを使うことができます。

WebSocketとJAX-RSのどちらを使えば良いのかという問いに対しては、私はケースバイケースとしか答えられません。ただ、JAX-RSは基本的にはHTTPです。データ通信には、HTTPヘッダなどが含まれた状態で送受信が行われます。

対して、WebSocket通信は一度クライアントとサーバ間でセッションが確立されると、HTTPヘッダが無い分データ量が少なくなります。JAX-RSよりもWebSocketの方が、パフォーマンスが高いというデータもあります。また、WebSocketは双方向通信を行うことができます。このあたりを踏まえて、どちらを使うか選択していただければと思います。

Java EEの本格導入のためには学ばなくてはいけないことも多いでしょう。まずはJava EE 6を学んでから、Java EE 7を学習するのも手です。

Java EE 6から7、8へのアップグレードは、差分で追加されます。どこか一つのバージョンをしっかりと勉強すれば、他のバージョンにもスムーズに取り組めます。

2. 従来型WebアプリケーションとJava標準「JSF2.0」

画面生成をサーバサイドで行わせる、従来型のWebアプリケーション開発を改善するJava標準には、JSF（Java Server Faces）が挙げられます。

グロースエクスパートナーズ所属でJJUG幹事である久保智氏は、JSFについて次のように語りました。

エンタープライズでは、先ほど寺田氏の説明にもあった通り、いきなりJava EE 7を利用することは現実的でないでしょう。Java EE 6の利用が安全で、これに含まれるJSF2.0が有益です。

JSF2.0は、Ajaxの使用を前提に設計されており、近年の広がっているリッチなUI開発に向いています。Strutsと骨子が似ているためStrutsからの移行しやすく、またJava EE標準であるためベンダサポートが受けやすいというメリットがあります。

JSFを使えば、JavaScriptレスにAjaxを使用したリッチなUIを作ることができます。f:ajaxを使えば、部分描画変更がサポートされます。よりリッチなUIを作りたいのであれば、Prime Faces、Rich FacesといったJSFの拡張ライブラリも有用です。Prime Facesには有償でないとパッチのサポートが受けられないという制約がありますが、これらの利用は小さなJavaScriptボリュームでリッチなUIを実現することが可能とします。

拡張ライブラリの注意点としては、基本的には最新のWebブラウザしかサポートされない点です。素のJSFはIE8ぐらいから動きますが、拡張ライブラリを使う場合はより新しいバージョンのIEが必要となり、エンタープライズでの活用では制約となることもあるでしょう。

Java EE6（JSF2.0）の範囲で説明すると、Strutsは以下の機能へ移行されます。

JSF利用時の注意点としては、JSF1.X（Java EE 5以前）とJSF2.X（Java EE 6以降）は別物と言えるほど仕様に違いがあり、1.Xの実装はあまり出来がよくありません。Java EE 5までの場合は、Strutsを使い続けたほうが良いでしょう。

また、JSFにはデザイナーとの協業向け機能があります。XHTMLにjsfc属性を埋め込むと、HTMLがそのままJSFとして認識されます。したがって、Webブラウザから直接確認しながら開発が行えます。ただし、Java EEの6と7で属性の名前が変わっており互換性が無いため、開発時には注意が必要です。

昨今のフレームワークはリッチなUIを実現するために、セッション機能を多様する傾向にあります。このため、セッション管理機能を独自に作るのは避けるべきでしょう。

また、リッチなUIの実現のためには、セッション上に業務用途以外にも多くのデータを持つ必要があり、メモリを大量に積む必要があります。メモリは安価になりましたので、StrutsのレガシーUIの時代よりも、2倍～10倍ぐらい積むことが推奨されます。

─⁠─次頁では、少し方向性を変え、Scalaのような別のJava系技術でWebをどのように扱おうとしているのか、探ってみましょう。

Scalaから見たWeb技術

前頁まではJava技術を中心に解説を進めてきました。しかし本頁では方向性を少し変え、同じJVMで動作するScala言語で、Web技術をどのように扱うのか取り上げてみましょう。

ストーンシステム代表の石黒尚久氏からは、Scala言語の入門レベルの解説が行われました。JavaプログラマからScalaプログラマへの知識体系の差分を、詳しく説明していただきました。

Web開発としてのScalaについての説明は、NTTデータ先端技術の竹添直樹氏（@takezoen）に解説していただきました。

• ステートレス
  • HTTPもステートレス。
  • クライアント側で頑張る流れになってきている。
  • 関数型言語のステートレスな性質と相性が良い。
• コレクション操作
  • Webアプリは基本的にデータを加工して表示する。
  • 強力なコレクションAPIはこのような処理と相性が良い
• フレームワーク
  • ノンブロッキングI/Oを活用。
  • アクセス数の多いシステムのバックエンドに適している。

B2Cのようなアクセスが一気に殺到するようなWebシステムに適していること、生産性、スクリプト言語のような柔軟性とJavaのようなTypeSafeさの両方を兼ね備えていることが、Scalaのメリットです。

ScalaのWebフレームワークとしては、Play2やScalatraが挙げられます。

Play2は、ノンブロッキングで、1台で処理できるリクエスト数を上げ、 非同期も簡単に書けるという特徴を持ちますが、この場合、DBアクセスが集中してボトルネックとなってしまうケースが多いです。

最近では、postgresql-asyncのようなDBアクセスを非同期処理するライブラリが出現していますが、本来であればJDBCレイヤーで解決するべきであり、標準技術で対応して欲しいところです。

また、Play2はタイプセーフです。Javaのテンプレートはタイプセーフさを活かせていないこともありましたが、Play2は改善されています。HTML5的なネタとしては、WebSocketにも対応しています。

既存Java資産のポーティングという観点では、Play2はServletコンテナ上での動作させることが困難です。Tomcatなどで動いている既存のシステムを移行するのであれば、Scalatraの方が向いています。ルーティングがタイプセーフに記述できないという弱点もありますが、Scalatraにはひと通りのライブラリが実装されています。

• Play2：B2Cなコンテンツの制作に向け。
• Scalatra：業務系など既存のJavaのシステムの移植に向け。

Scalaの欠点としては、書き方の統一性が低く、コンパイルも遅く、またIDEもJavaと比べると成熟していません。

しかしこういった弱点は、かつてのJavaも持っていたはずです。Javaも改善を繰り返して今の姿になりました。

Javaが10年前、J2EEをアンチテーゼに様々なOSSが出てくるなど、熱気が強かったように思えます。それが今、お客様の瑕疵担保を強く意識するようになるなど、保守的になり、新しいものを生み出すことが難しい状況になってしまったと思います。

Scalaには、かつてJavaにあったような熱気があります。Scalaは業務でも十分に使える言語だと考えています。未熟な部分もありますが、エンジニアと共に成長していきましょう！

議論は一部懇親会へ、そしてライトニングトーク

竹添氏の講演の終盤で、寺田氏と突発的に議論が開始。その後、懇親会へ持ち越されました。JavaとScala、この2つを"Web"という共通のテーマの上で議論させたのが、良いきっかけになったのかもしれません。競争は素晴らしいことです。

懇親会のLTでは、わたなべ氏（@nabedge）により、JavaによるWebアプリのためのテンプレートエンジン「Mixer2」が紹介されました。JSFと同様、デザイナー協業が意識されている点に、時代の流れを感じます。エンタープライズでも、GUI専門のデザイナーを雇うことが多くなりました。

櫻庭祐一氏（@skrb）のLTは、Web技術でGUIのJavaアプリケーションを開発できる「JavaFX⁠」⁠。WebKitをJava側から操作する様子に感動し、重度なWeb信者である私たちスタッフは、待ってましたと言わんばかりに目を輝かせます。JavaFXは、古くはXULRunner、最近であればSenchaやPhoneGapに代表される、マルチプラットフォームGUIアプリ用途としてのWeb技術の好例と言えるでしょう。

寺田氏から寄付された「Java EE 6」の本は、じゃんけん大会の景品になりました。こともあろうか、運営スタッフがジャンケンに優勝、ちゃっかり本を貰って帰っていました。今回は殆どのスタッフが、講演内容を見れていません。まさに、頑張った人へのご褒美です。

フロントエンド系エンジニア中心のいつもの懇親会とはやや異なる空気の中、最後は盛大な拍手の中、JJUGとの初の共催イベントが幕を閉じました。Java+Web技術はもはやエンタープライズ鉄板な組み合わせなので、今後もまたどこかで機会があるでしょう。会場提供に協力いただいたGREE様にも、大変感謝します。

最後に

Web技術者コミュニティ「html5jえんぷら部」では、エンタープライズのWeb技術を取り巻く、Microsoft Internet Explorer、Oracle Javaの2つのプラットフォームについて、2回のイベントに分けて情報を発信してきました。いかがでしたでしょうか。

IEもJavaも、進化するWeb技術へ追いつこうと様々なアプローチを行っています。そして両者ともに、エンタープライズを担ぐことがネックとなり、技術の進化に対し比較的ゆっくりとしたスピード感で進行しているようです。歯がゆく感じます。

最近になって急激に注目を集めているオープンなWeb技術によるアプリ開発は、Javaに比べるとまだヨチヨチ歩きです。標準化されていない技術の扱い方、相互運用性の考え方、性能の考え方など、知識体系もサーバサイドほど普及も成熟もしているとは言い難い状況でしょう。

瑕疵担保の問題もあるかもしれない、多くのリスクを孕んでいるかもしれない。しかし竹添氏の言う通り、こういう分野こそエンジニアと共に成長できるチャンスがあるのではないでしょうか。

Web技術の進化により、業務システムとそれを取り巻くプラットフォームは再び、多様性・差別化の材料を獲得しようとしています。モバイルやクラウドなど様々なテクノロジーの中核にインターネット技術とWeb技術があり、今まさに変化しようとしているのです。

今まで考えもしなかった領域にITが入るかもしれない、今まで考えもしなかった方法でITが活用されるのかもしれない、そういう可能性を秘めている。最近では、WebデザイナがSI領域へ自分たちの価値を売り込むなど、Webという共通言語を通じて、異なる業種間でそれぞれの強みを売り込むという道も開けているように思えます。

いよいよ、その進化が全くもって予想できない状況です。

次回予告

Web技術者コミュニティ「html5jえんぷら部」では、今後もWeb技術とエンタープライズの関わり方を、最前線から発信していきます。私たちの活動のモチベーションは、HTML5という新しいWeb標準が、エンタープライズ・産業向けのシステムをどのように変えようとしているのか国内で最も早く知ること、そして普及・推進を行うことです。

これまで隔月程度しか活動していませんでしたが、10月は17日以降、毎週どこかでhtml5jえんぷら部企画な何かが起こります。

10月17・24日は、Web技術の開発環境を扱った小規模なハンズオンのイベントを開催する予定です。また31日は、エンタープライズ分野でHTML5やJavaScriptフレームワークを扱った適用事例をテーマに、大きめの勉強会イベントを開催する予定です。

どのイベントも、業務系システムのデベロッパ・デザイナで、HTML5や新しいWeb技術を扱いたいと考えている方にオススメします。イベント告知は、こちらで行っています。スタッフとして、イベントの運営や講師という形で参加していただける方も大歓迎です。

今後の活動に、ご期待ください。