最速でJava EE 7 Webアプリを作る – 2014 Java EE Advent Calendar

Will be translated in English soon. Sorry for inconvenience.

この記事は2014 Java EE Advent Calendarの12月24日分になります。キリスト教徒ではないのですがメリークリスマス。

今年はJava EEに関する大きな発表が無かったのでネタ的に困る訳なのですが、個人的な「温故知新」ブームに乗っかり、こんなのをやってみることにします。

Slide1はい、超スタンダードなJava EEの使い方です。勿論、Java EE 7で。残念ながら商用サーバーのEE 7対応はまだですが、来年は対応するという話を聞きますので、今のうちに慣れておきましょうということで。

ただ作るだけでは面白くないので、できるだけ最速でイチから手順を追って作っていくことにします。勿論NetBeansの自動生成機能を駆使します。また、お仕事でもそのまま使えるようなコードで、という制約付きです。Java EEはめんどくさい、という意見を聞きますが、そんなことないよ、という事を証明するべく、こんな挑戦を敢えてクリスマスイブにやってみるわけです。暇人と呼ばないで(笑) ※ほんとは正直忙しすぎて死にそうです

さて、細かい前説は抜きにして、最速で順番にやっていきましょう。

今回の環境です。本番でもそこそこ使えるようなものを選んでみました。OSは何でもOKですね。わたしは普段使いのOS X Yosemiteを・・・と書いていたのですが、前の記事の通り個人PCをWindowsに戻してしまったので、途中まで出来ていたものをWindows 8.1 64-bitで再度やり直しました。Realforce 87Uが快適すぎるので助かりました。

なお、私は普段お仕事でも家庭でも英語環境で使っているのでスクリーンショットや用語は英語ですが、推測できる範囲だと思いますので適当に読み替えて下さいませ。

  • JDK: JDK 8 の最新版 (この記事では JDK 8u25)
  • IDE: NetBeans 8 の最新版 (この記事ではNetBeans 8.0.2)
  • App Server: GlassFish 4 の最新版 (この記事では GlassFish 4.1)
  • Database: MySQL 5.6 の最新版 + MySQL Workbench の最新版 (この記事では MySQL 5.6.22)

1. データベース

まともな企業システムをターゲットにしているので、データベースがあって然るべきでしょう。DB処理はJava EEの華です。ここをすっとばしたJEEの説明が多い気がするので、ここに改めてまとめておきます。

エンタープライズ系のプログラマーがデータベースのインストールすら出来ないというのは恥ずべき事なんじゃないかなと思うのですが、何となく日本のWeb系の流行がNoSQLとかBuzz方面に流れがちだ、ということで、特に若手の育成面を危惧しています。地に足をつけて物事を考えたいですね。流行は流行で別途追っかけるとして。

1-1. データベースの準備

こういうのは依存関係の深い場所から作っていくのが正しい在り方です。ですのでまず、データベースからですね。Oracle Databaseが所謂スタンダードかなと思いますが、フリーのXEがOS X用に出ていないので、ここでは涙を呑んでMySQLをインストールします。インストーラーを落としてぽいっと入れれば終わりです。

http://dev.mysql.com/downloads/mysql/

CUIで諸々やるのは面倒なので、MySQL Workbenchも入れてしまいましょう。Windows版だとDeveloper Defaultを選べばいいです。以下Windows版をメインに書きますので、OS XとかLinuxの方はユーザーアカウント等はインストール後にMySQL Workbench等で個別に設定する必要があります。

000001

インストール途中でアカウントを作成します。今回のアプリ用の「Advent」ユーザーを作りましょう。めんどくさいのでパスワードも同じにしましたが、外部から接続されると厄介なので接続元許可をlocalhostに制限しておきましょう。

000002

rootもここで設定しておきましょう。この辺はWindows版便利ですね。

000003

あとはデフォルト値でホイホイ進めれば、最後にMySQL Workbenchが起動します。rootの接続が出来ているので、これをクリックしましょう。

000004

最初にスキーマを作ります。「Create New Schema」を選択します(+の付いたデータベースアイコン)。名前は「advent」でいいですかね。CollationはServer Defaultで良いかと思います。

000005

「Users and Privileges」で「advent」を選択し、(開発用途なので)全権を「Select “ALL”」で選んでおきましょう。終わったらApply。※当然ですが本番運用でこんな事はしないで下さい。

000006

これでadventユーザーがadventスキーマを使えるようになりました。これでこのMySQL Workbenchの役目は終わりです。これ以降はNetBeansで作業することにします。そっちが楽です。

 1-2. スキーマの作成

さてNetBeansを起動して、Serversタブを開いて、今回作ったスキーマを接続しましょう。右クリックして「Register MySQL Server」を選択して登録しましょう。接続情報は上の通りですね。分からない方は以下を参考に。

000008

成功したら「advent」の接続が登場します。これでようやく全ての作業開始です。長い・・・

000009

では今回のテーブルを作りましょう。「Advent」スキーマをを開いて、Tablesで右クリックして「Create Table」。以下のような感じで。ぶっちゃけここはお任せなので、めんどくさい人は1カラムでもいいでしょう。

000010

  • Customer
  • ————-
  • CustomerID BIGINT PRIMARY KEY
  • Name VARCHAR(100) NOT NULL
  • PostalCode VARCAR(10) NOT NULL
  • Address VARCHAR(200) NOT NULL
  • Phone VARCHAR(30) NOT NULL
  • Note VARCHAR(1000)

これでデータベース側は準備完了です。

  1. 2. サーバーサイドを作成する

さて、ようやくJava EEです。以下の大半の処理はデータベースを以下に効率的に処理するかという観点になってます。これはCOBOLシステムに代表される「コンテナー管理型システム」の現代版としてJava EEが元々設計されていることに由来します。超高額で場所を取るホストシステムが不要であり、家のPCで気軽に無料でプログラミングできるJava EEがある現代は恵まれた世界だなと思います。

今回作成するパッケージはは3つ。CRUDを行うDAOと、ビジネスロジックを記述するLogic、および、データベースの写像としてのEntityです。LogicとDAOをごっちゃにして作る人がいますがやめたほうがいいでしょう。自動生成がメインであり、JPQLやCriteria Queryの記述がメインのDAOはあくまでDAOとして分けておかないと、数年後に破綻する羽目に陥る気がします。

Slide2

なお、以下NetBeansを使っていますが、一点だけお勧めの設定変更があります。デフォルト設定ではフォントがMonospacedになっていて非常に見辛いので、Courier NewやConsolaなど英字等幅フォントにに変更すると非常に見やすくなります。Tool > Options > Fonts & Colorsからどうぞ。

2-1. サーバーサイドプロジェクトを作成する

NetBeansからプロジェクトの作成で、Maven > Web Application を選択します。ちなみにJava EE 6からWARにEJBを入れられるようになったので、今回もそれを活用します。必ずMavenのプロジェクトを選択して下さい。ここで間違って後で地獄を見る系の人が多いです。もうNetBeansのオリジナルプロジェクトファイルは廃止していいんじゃないかなと思うのですが・・・

000011

プロジェクトは適当に。「advent-jee7」としておきます。

000012

Application ServerにGlassFish Serverを、Java EE Versionには「Java EE Web」を選択します。ちなみにこれはWebプロファイルであり、Fullプロファイルをここで選択できないのはNetBeansのバグですね。

000013

ここで 一旦Finishして、生成されたプロジェクトファイルを手作業で修正します。プロジェクトのProject Files > pom.xmlを開き、「javaee-web-api」を「javaee-api」に変更して保存し、プロジェクトをビルドすれば完了です。

000014

これを・・・

000015

こんな感じに。これでEJBがWAR内でフルに使えるようになります。ここから開始しましょう。

2-2. 自動生成でJPA系クラスを作成する

DB接続系の処理ですが、Java EEだとJPA一択です。元ネタのHibernateと一緒なので、大体誰でも理解できると思いますが、要は「テーブルの1行=Javaクラスの1インスタンス」で処理するだけの単純明快な標準フレームワークです、と書けばいいでしょうか。

業務システム構築では、こういうところをセコセコ手作業してたらやってられないわけですので、Databaseのテーブルからちゃっちゃか自動生成してしまいます。

プロジェクトで「New > Other」から、「Persistence > Entity Classes from Database」を選択し、MySQLの接続を選択して、JNDIデータソース名「jdbc/advent」を指定して、上で作成した「Customer」テーブルを選択します。あとはデフォルト値で進めれば・・・

000016

000017

000018

000019

000020

はい、DB接続設定が含まれたpersistence.xmlと、「Customer」テーブルに対応付いた「Customer」クラスが作成されます。簡単ですね。これぞJava EE。このクラスだけではデータベースにCRUDできませんので、次にDAOを作成します。これをEJBで作るのがポイントです。ここで間違える人が多いですが、選択肢はこれしか無いと思った方が良いのではないでしょうか。

「New > Other」から「Enterprise JavaBeans > Session Beans For Entity Classes」を選択します。

000021

Entity Classesに上で作成したEntityが出てくるので、選択します。

000022

パッケージ名の後ろに「dao」をくっつけてあげましょう。

000023

完了するとEntity Managerを内包した「CustomerFacade.java」という名前のEJBが自動生成されます。これを使ってCRUDするわけです。なお、このEJBは「AbstractFacade」という名前のスーパークラスを継承しており、そこにCRUDの実装がありますので、基本処理を変更したい場合はここをいじります。ただ、二つ目以降のDAOを作成した場合、同じようにこのスーパークラスを継承するように自動生成されるので、注意が必要です。

000024

よく見たらEntityのクラスがプロジェクトパッケージの直下にありました。これは生成時のオプション指定忘れなので「entity」とおしりにくっつけます。各種処理はNetBeansがやってくれます。

000025

2-3. ビジネスロジックを作成する

はい、最後にビジネスロジックです。当然ながらEJBで作ります。

ビジネスロジックは自動生成なんかできないので、普通に作成します。「New > Other」から「Enterprise JavaBeans」、名前に「CustomerLogic」、パッケージを「advent.logic」にして生成。

000026

頭に「@Stateless」と書いてあるだけの普通のPOJOができます。これが今時のEJBですね。単純バンザイ。

000027

さて、とりあえず動かすためにはデータが必要ですので、今回はまずデータ登録系の処理をここに追加しましょう。こんな感じです。ここには普通にDAOクラスを@EJBでインジェクトし、そこで該当メソッドを呼び出すだけになります。

000028

なんというか、拍子抜けですね。データベースを含むトランザクション処理はEJBコンテナー側が全自動でやってくれるので、これが正しい姿です。このメソッドが呼ばれた瞬間にJTAトランザクションが開始(BEGIN)され、正常終了するとトランザクションが完了(COMMIT)されます。例外が発生した場合は取り消し(ROLLBACK)ですね。エンタープライズ系処理はこうでなくてはいけません。COBOLの正統後継者たる所以です。

はい、バックエンド系処理は終わりです。データベース系設定作業がくそめんどくさい割に、バックエンド処理は爆速で終わったかと思います。

  1. 3. Web画面作成

最後に画面側です。バックエンドを呼び出す画面についても省エネ爆速で作りましょう。作るファイルは三つ。FaceletとBacking Beanは二つでひとつのセットです。あとは完了画面だけ作ります。最低限動く事を確認するだけの構成にします。

Slide3

3-1. JSFを使うためのプロジェクト設定

NetBeansでMaven WARプロジェクトを作った場合、初期設定でJSFが有効になってません。これでは困るのでちょいと設定します。プロジェクトを右クリックしてFrameworksからJavaServer Facesを選択します。

000029

また、JSFの画面ファイルであるXHTMLが簡単に起動するように、URL Patternも「*.xhtml」に変更しておいて下さい。じゃないと全てのリクエストに対して/faces/とかつけなければならず、実態のファイルの配置とずれてしまうという困ったことがおきます。

000030

JSFを有効にしたら、index.xhtmlファイルができます。こいつが新しいトップページになりますので、古いindex.htmlは削除して下さい。ここまで全自動でやって欲しいなぁ・・・余計な作業ですね。

000031

3-2. Backng Beanの作成

そろそろこれまで作ってきたものを一度動かしてみたい気になりますが、最速を目指すこの投稿ではスキップして、一気にBacking Beanを作ります。ASP.NETのコードビハインドみたいなやつです。画面と一対一で原則作ります。

普通にクラスを新規作成します。アノテーションで@Namedと、@ViewScopedをつけて下さい。要注意なのは、「import javax.faces.view.ViewScoped;」側を使って下さい、ということです。同じ名前のがjavax.faces.beanにもありますが、こちらを使うと動きません(こちらはJava EE 6以前(JSF 2.1以前)用)。

000035

残りはEntityに定義したものをそのままフィールドに定義してしまいましょう。あとはGetterおよびSetterを作る必要がありますが、そんなものはNetBeansに作らせましょう。右クリックして「Insert Codes…」で「Getter and Setter」ですね。日本語版だと妙な名前になってた気がしますが、こういうプログラミング系は英語版を使うと変な所で悩まなくとも済みます。

000036

最後にボタンを押したときのアクションメソッドを作ります。下記のような感じです。Entityに画面の中身を詰めてEJBに投げるだけ。簡単すぎる。

注意点としては、CustomerID列についてはデータベース側で自動採番されるのですが、EntityのBean Validationの関係上、NULLが許容されないため、とりあえずLong.MIN_VALUEを入れておきました。0でも何でもいいんですが、INSERT時に正しい値に置換されますので気にしないで下さい。

000046

ちなみにここでの考慮点としては、「EntityをそのままBacking Beanのフィールドに設定した方が早いのでは?」というFAQがあります。が、分けた方が良いでしょう。画面で入力する値は本質的に全て文字列ですが、DB設定の型は様々です。入力値のチェックも考慮した場合、すべてString型で定義したBacking Beanと、本質的な正しさを追求すべきEntityは分けた方が良いでしょう。

3-3. Faceletの準備

はい、では最後にFaceletをいじくりましょう。index.xhtmlを開きます。

000032

なんというか、丸ごとふるくさい構成になってますので、HTML5にちょいと書き換えて、不要なタグを削り、JSF 2.2で必要となるネームスペースを追加します。こんな感じです。「xmlns:jsf」というのを追加する必要があります。URLそのものはNetBeansが自動補完してくれます。これが無いとJSFの特殊タグが使えないのです。要注意。これもNetBeans側のテンプレートを更新して欲しい気がしてます。自分でContributeしろと云われそうですが。

000033

はい、とりあえず画面側はできましたので、ここで一回起動しておきましょう。メニューバーの右矢印ボタンを押すと、ブラウザーが起動するかと思います。下記の画面が出たら、バックエンド側のEJBやJPAも正常に動作しています。もう9合目です。もう一息。

000034

では最後にBacking Beanと結合していきます。当たり前ですがFaceletでもコード補完が動きますので、ホイホイやっていきましょう。

000038

完成版はこんな感じです。JSF 2.2からはHTML Friendly Tagsといって、ふつうのHTMLに対してjsf:valueやjsf:actionを追加で入れていく感じになっています。これならば誰でもできますね。昔のh:inputTextとかを忘れて思い出せずイライラするといった非生産的な状況とはおさらばです。

000047

注意点としては、form要素に対してjsf:idを(名前は何でも良いので)入れておかないと動かないという点だけでしょうか。まあめんどくさいのでformとか何とか入れておいて下さい。

最後に完了画面も作っておきましょう。index.xhtmlと同じ場所に「thanks.xhtml」をおいて下さい。index.xhtmlをコピーして削るのが良いかと思います。こんな感じ。

000040

終わったらもう一度実行ボタンを押しましょう。うまく行けばこんな画面が出てくるかと思います。

000041

テストをやらねばなので、とりあえず嘘情報をつらつらと・・・

000042

入力してボタンを押したら完了画面が出ておしまいです。そういう作りにしたので・・・

000043

データベースの中身を見てみましょう。正常に登録されてるかな・・・? Servicesタブからcustomerテーブルを開いて、View Data…です。

000044

正常に登録されていました。一発で動いてホッとします(笑)。

000045

はい、これでおしまいです。完了。この記事はスクリーンショット等を取りつつ書きつつやったので2時間ちょい程度かかりましたが、そんなことをしなければここまで最速で10分から30分くらいでしょうか。データベースの設定を一度やっておけば、あとは上記2.以降をやればいいので、10分くらいでできるかな。Java EEも簡単になりましたね。初代J2EE 1.2時代のめんどくささと比較しても、雲泥の差です。最初からこうあってほしかった(笑)。

Java EEのこの安定感は素晴らしいですね。繰り返しになりますが、上記の作業手順や生成方法、生成されたファイル群は、本物のお仕事でもそのまま使えるものです。今回は画面遷移や入力値チェック等は省きましたが、その辺は別記事等でフォローしたいなぁと思っています。

なお、上記のコードについてダウンロード提供しようと思ったんですが、生成されたコード群がアホみたいに小さいので、是非ご自身でやっていただきたいなと考えまして一旦見送ります。自分でタイピングしないと覚えないので、30分時間を作って是非やってみてください。※ご要望があれば上げます。

次回の2014 Java EE Advent CalendarはArshal Ameenさんの記事になります。最終回ですね。

How to Move from J2EE from Java EE in Java Day Tokyo 2014

Last day I joined in Java Day Tokyo 2014 as a speaker and had this conference session “How to Move from J2EE from Java EE” as below. Uploaded in SlideShare.

The background of these slides and my presentation theme was for the poor enterprise systems which is not improved and keep going with J2EE 1.4 and many non-standard open source frameworks.

The big picture of Java EE – formerly J2EE is the standardization of the enterprise development API for any application servers, and the theme was not changed since the born of Java (2) platform, enterprise edition (J2EE). I strongly agreed these movement at the start of J2EE, and not changed in this time.

Many enterprise engineers still don’t know the latest version of JEE, due to the limitations of each company’s original standards – many standards are still based in J2EE 1.4. And the older standards applied systems are now turning into the “too old to migrate” systems.

As a fan of Java EE specifications, I want to share how to migrate to latest Java EE 7 standards from older ones. I hope these slides are for your system improvements and Java EE applied system increasing.

GlassFishの商用乗り換え先について(補足)

昨日のJava EE Advent Calendarの続きなんですが、前回はWebLogicをターゲットにしたんですけど、それだけだとちょっと物足りない感じもするし、何だかOracleの回し者のような気もする(笑)ので、とりあえず他の会社のも簡単に補足しておきたいと思います。

※「補足」の字が間違ってました(笑) 疲れてますねー (2013/12/09 09:35)
※ Interstageの選択について誤ったメッセージが伝わるといけないので、更に補足を追加しました(2013/12/09 14:39)

その他の会社のJava EE商用サーバー群について

今年の楽天テックカンファレンス2013でも語ったのですが、Java EEにはそれぞれ対応バージョンがあり、各社から下記のような形で出ています。

※英語のWikipediaでもかなりいい加減だったので、各社の発表やドキュメントを開き、必死に調べました(笑)

で、今回の商用製品(商用サポート付き)としてのGlassFishからの乗り換え先としては、繰り返しになりますがJava EE 7対応は残念ながらまだ出ていないです。恐らくJBossのオープンソース版であるWildFly(改名)が最初に出るのではないかな、とは思いますが、現時点では何とも言えませんね。

Java EE 6以前に関しては、概ね選り取り見取りと思ってもらっていいでしょう。最新版さえ選べば、対応しています。ベンダーによっては、最新版の提供は勧めない変な所もありますが、そういったところは品質に問題を抱えているか、もしくはサポート部隊が心許なくクレームを恐れているか、どちらかかなと思ってもらってもいいですし、何て石橋を叩いて渡る顧客思いの会社なんだ、と思ってもらっても良いと思います(笑)。

もちろん、個人的にはサポートライフサイクルが最長である最新版を選択することをお勧めしたいですが、まあそこはご自身で総合的に判断してもらった方が良いでしょう。

何を基準に決めればいいのか

さて、Java EEの商用サーバーシェアについては、いろんな調査会社があれこれ出しており、しかも会社によってバラバラの順位だったりするので眉に唾を付けて見る方がいいでしょうが(笑)、国際的にはWebLogic、WebSphereが二強、プラスJBossの三つ巴の戦いと考えてもらえれば良いかなと思います。国内を見た場合には、これに富士通のInterstageやCosminexus辺りがドカーンと参戦している形かなと思います。

わたし自身は過去これらのサーバーをだいたい使ったことがあるのですが、残念ながら最近のCosminexusを知らないというのと、WebOTXだけは実物を一度も見たことが無い、という制約はあります。

※使った(苦労した)or知ってるけど消えてしまったJava商用サーバーも多いです。Netscape Application Server (iPlanet AS)とかSilverstreamとかJRunとかOracle iAS (OC4J)とか・・・J2EE前後でかなりの興亡がありましたね・・・

で、このなかのどれがお勧めか、と問われると、どうかなぁ、と。どれも一長一短あり、なかには絶対使いたく無いものもありますが、そんなものをここで明け透けに発表したところで私自身には何の得も無いため、まあそこはオブラートに包むとしても、評価基準は幾つか持っておいた方が良いでしょう。

基準のひとつとして個人としてお勧めなのは、サポート力です。これは国内にどれだけのサポート部隊を抱えているか、バグなどが発覚した場合に、どのくらいのリードタイムでパッチ等を提供してもらえそうか、営業さんがどれだけ熱心に対応してくれるか、などなど、ここだけ見てもチェックすべき所は多数あります。これは勿論国内ベンダーが強い面もありますし、そうでない所もあります。

でも何が何でもGlassFishを商用サポート付きで使いたいたいんだ!という場合

さて、最終手段というか究極の話なんですが、でもGlassFishを愛してやまない、何とかして商用で使いたいんだ、という場合の話なんですけど、選択肢が無くは無いです。

実は、上記の製品のなかに、GlassFish互換品が含まれているんです。どれだと思いますか?

何と、富士通のInterstageの最新版なんです。Interstageといえば昔のバージョンはTomcatベースだったんですが、Java EE 5対応以降(つまり9.2以降辺り)で、GlassFish 2.xを丸ごと取り込みました。その後GlassFish 3系も取り込んだんですが、しばらく「本番用途サポート不可」という謎のステータスを経て、最新版でようやく正式に対応したようです。

勿論、GlassFish 4系ではなく3系なのでJava EE 6対応になってしまいますが、基本エンジン部分はだいたい同じであり、サーバーの乗り換えに際しての挙動変更を嫌う場合、実は良い選択肢かも知れません。

が、違う箇所もかなりあり、サポートOSの縛りがあるとか、インストーラーが独自すぎてわけわからんとか、管理コンソールとがGlassFishのと違うとか、周辺ライブラリーがごっそり違うとか、過去の遺産を引きずっているところも多分にあります。

まあ、なので勿論、決める前に実際に試用版を使ってみることをお勧めします。何とWindows XPや7などクライアントOSが非対応だったりするので、いきなり詰まる気もしますが(笑)、テスト用のWindows ServerやLinuxなどを用意してもらえれば良いかと思います。

※念のため更に補足しておきますが、Interstageが将来GlassFish 4.x系をそもそも採用するかどうか、また仮に採用したとしてもそれはいつなのか、というのは全く不明なので、もし気になる方は富士通の営業さんに実際に問い合わせてみましょう。ただ、富士通の場合、国内ベンダーらしく、サポート終了までの数年間は、ひたすら延々と黙々とサポートを続けてくれると思います。もちろん、GlassFish側も現時点では2.x系および3.x系のサポートについては一応続けています。なので、将来を見据えての乗り換え先としてはそもそも微妙でもありますし、とにかく「最終手段」です。

実は情報が少ないJava EEサーバーの選択

とまあ、一般に結構珍しいのではと思う観点でEE商用サーバーを私の視点で軽くまとめてみましたが、この辺りは意外にも公平な情報に欠ける点が多く、営業さんの営業力や技術者の趣味とか、はたまたお偉いさんによる星取表で決まってしまいがちな所でもありますけど、まあ何せプラットフォーム(土台)でもありますので、ちゃんと頭を使って選んだ方が良いですよ、という当たり前の話としてまとめておきましょう。

個人的には、どれが一番好きかって? うーん、一長一短だなぁ・・・(笑)

WebLogicをGlassFishの商用版として使う方法

※ WebLogicだけ書いておくのも何なので、その他の商用Java EEサーバーもこちらでまとめてみました(2013/12/08 22:20)
http://www.mushagaeshi.com/2013/12/08/from-glassfish-to-other-commercial/
※ GlassFish2系・3系のサポート継続について言葉が足りなかったので、念のため補足を入れました(2013/12/09 14:46)

こんにちは。Advent Calendarな時期になりましたね。この記事はJava EE Advent Calendar 2013の12/7の担当回です。12/6の回はwaritohutsuさんの http://d.hatena.ne.jp/waritohutsu/20131206 になります。

Java EE Advent Calendar 2013
http://www.adventar.org/calendars/152

ところで、先日Java EE界隈でプチ騒動が起きました。何とGlassFishの商用サポートが切られてしまったのです。大変残念な話です。

Java EE and GlassFish Server Roadmap Update (打ち切りの話が出てます)
https://blogs.oracle.com/theaquarium/entry/java_ee_and_glassfish_server

何故残念なのか? どうすればいいのか? そういった話を以下つらつらと続けてみます。Java EEは企業用途であり、商売が直接絡む話でもあって、こういった話はソフトウェア発売元もしづらいと思います。一方、困ってる所も結構多いと思いますので、ベンダー各社と全く無関係な筆者が私見をまとめてみました。

何故GlassFish商用版が必要だったのか?

この辺りに詳しくない方に一応説明だけしておきましょう。GlassFishは過去2.x系より「商用サポート」というSunおよびその買収会社であるOracleによって提供されてきた「パッチ」が存在します。Community Editionという一般公開版が3.1, 3.1.1, 3.1.2, 3.1.2.2, 4.0とバージョンを重ねてきましたが、この「商用サポート」には、何と、例えば3.1.2.2と4.0の間のバージョン、および4.0公開後に修正された一般未公開のバージョンが存在するのです。

これまでは、これを購入する場合にはOracleの営業さんに話をして、商用サポート権を購入していた訳ですね。知ってた人は知ってた話ですが、あんまり知らない人は全然知らないという系の話でしょう。

この辺りを見れば掲載されています。3系の最新版(最終版?)は何と3.1.2.6なんですね。
https://blogs.oracle.com/GlassFishForBusiness/

※念のため補足しますと、2.x系および3.x系のサポートについては、まだ一応継続しています。あくまで、将来のバージョンのサポートが無くなるという話になります。

商用サポートは何故必要だったのでしょうか? 特定の機能がちゃんと動かないとか、緊急の脆弱性が発見された場合に、その一般未公開バージョンがリリースされ、契約者はそれを適用して動作させていたのです。Java EEを利用するメインターゲットはEnterprise Editionの名前の通りEnterprise (企業)であり、何が何でも安定運用することが使命付けられたサイトやシステムに使われる事が大前提となっているから、ですね。

例えば、脆弱性があるからって放置してたり、バグで落ちまくる有名サイトがあったら利用者は困るでしょ? 金融系だと、さらに厳しくて、サービスによっては監督省庁に報告せねばならなかったりします。お金のやりとりが止まったら困りますよね? だから、企業はお金を払って、バグ修正版をもらう権利を買っていたわけです。

自分で修正すればいいじゃないかって? まあ、それはそうですが、修正したことで他の正常に動いていた機能が動かなくなったらヤバいですよね。どうやって修正が正しいことを証明するのか? それと、その次の修正版が出た場合、自分で修正した内容と異なる対処がされていたらどうでしょう? 延々と新しいバージョンが出るたびに、自分が修正した差分を適用していく必要が出てきてしまいます。ここらへんはGitやSubversionのbranchの関係を考えてもらえれば良いでしょう。つまり、公式の修正版を買った方が安い・早い・安全なのです。

ここらへんはEnterprise Systemの独特な所なので責めないで下さいね。世界中どこでも、大規模サイト、特に金融系など落ちたら大変なことになる所は、同じ事をやっています。オープンソースだからと自前で改変して独自バージョンをひたすらメンテナンスしているところは、現実の世界では実は多くはありません。

GlassFishが使えなければ、WebLogicがあるじゃないか

さて、話を元に戻しましょう。GlassFishが商用サポートの未来が無くなってしまったということは、別の商用サポートされているJava EE準拠アプリケーションサーバーを選択する必要が出てくるでしょう。幸いJava EEはMicrosoftの.NET Frameworkとは異なり、多数のベンダーが多数のアプリケーションサーバーとその商用サポートを提供しています。

そしてGlassFishの開発元であるOracleは、商用版Java EE準拠サーバーとして、WebLogic (ウェブロジック)を販売し続けています。古くからJ2EEを触ってきた人にはご存じのサーバーであり、Java EEサーバーの世界シェアNo.1、デファクトスタンダードと言われているものです。

一応言い訳をしておくと、筆者はJ2EE仕様準拠前よりWebLogicを使い続けているので、最も詳しいということがあるので、この記事ではWebLogicとしているだけです。勿論、他にもWebSphere、JBoss、Interstage、Cosminexus、WebOTX等、商用サポートが提供されているJava EE 6準拠サーバーはありますので、よりどりみどりです。

※こちらにWebLogic以外のサーバーを補足しました。
http://www.mushagaeshi.com/2013/12/08/from-glassfish-to-other-commercial/

が、最近GlassFishからJava EE世代になって入ってきた人にとってJava EEはさておき、その元ネタであるWebLogicは馴染みが薄いと思いますので、こちらも簡単に説明しておきましょう。

WebLogicの過去・未来

WebLogicは1997年頃に誕生した、元々WebLogic Inc.という会社が開発していたJava上で動くアプリケーションサーバーでした。当時はアプリケーションサーバーという名前もあるのかないのか、微妙な時代でした。名前も一時期Tengah (テンガー)というものでした。勿論、J2EE仕様なんてものもありませんでしたし、その前の暫定仕様であるProject JPE (Java Professional Edition)よりもさらに前の話です。

WebLogicはT3というプロトコルを持ち、それを土台としたEJBという独自仕様を持っていました。これはCORBAのモデルを忠実に移植したものであり、現在のEJBとほぼ同じものでした。CORBAは当時、特に金融系のデファクト・スタンダードとして、Object Brokerと呼ばれる製品と一緒に利用されていました。有名なところとしてはTuxedoやOpenJP1などがあります。トランザクション処理が可能なリモート通信を既に実現していたんですね。

これを買収した会社がTuxedoをも買収していたBEA(ビー・イー・エー)というところで、BEA WebLogic Serverという名前になり、トランザクション処理が更に強化されていきました。もはや知らない人も多いかも知れないので、読み方も補足しておきます(笑)

その後、Sunが1998年のProject JPEを経て1999年末にJ2EE仕様の初版(1.2)を出し、そこにWebLogicからEJBが持ち込まれたという経緯があります。つまり、WebLogicはJ2EEよりも古い、恐らくJavaで現存する最古の歴史を持つアプリケーションサーバーとなります。勿論、Apahce Jakarta Tomcatの登場よりもずっと前です。まだApache JServとか別の名前でした。

その後2000年代にWebLogicが一世を風靡した後、J2EE仕様が普及するにつれ圧倒的な優位性を失い、2008年頃にOracleに買収され、現在Oracle WebLogic Serverとして販売されている現状となります。

2013年末現在、このWebLogicの最新版は12c R2 (12.1.2)であり、これはJava EE 6準拠となります。残念ながらJava EE 7には現状未対応です。筆者の予測としては、来年辺りにはJava EE 7対応をしてくるのでは、と見立ててますが、残念ながら私はOracleの人ではないため、あくまで単なる推測になります。気になる方はOracleの営業さん辺りに聞いてみましょう。

GlassFish 2系・3系からWebLogicへ移行する

さて、またもや話が逸れてしまったので元に戻り、実際にWebLogicへGlassFishから移行するパターンを考えてみましょう。

まず、Java EEの対応バージョンです。WebLogicの最新版はEE 6対応なので、動作可能なアプリケーション仕様はEE 6, EE 5, J2EE 1.4の三つです。GlassFishはEE 5以降の仕様に準拠しているので、これは問題ありません。

次に、開発環境です。Java EEを開発する場合にはEclipseではなく是非NetBeansを使って頂きたいと日頃から言い続けている筆者ですが、NetBeansは幸いWebLogicにも当然ながら対応しています。サーバーのタブからWebLogicを追加すれば、GlassFishと全く同じように開発ができます。

更に有り難い話としては、WebLogicにはFaceletだけではなく、Backing BeanやEJBなどが、再配備せずとも自動的に画面に反映してくれる「Fast Swap」があります。例えば画面を書き換える場合、JSF Faceletを書き換えて、Backing Beanやその他Javaのファイルも書き換えると思うんですが、GlassFishの場合、Facelet以外を反映するためには再配備が必要になります。ところが、WebLogicのFast Swapはこれが必要ないんですね。NetBeansで書き換えて保存して再実行したら即時反映してくれます。実際の開発作業はこれが無いと結構やってられないので、現実の近代的なエンタープライズ開発現場には必須の機能です。GlassFishには残念ながらこういうプロ仕様の機能は無いので、ここはさすがに商用製品になります。

じゃあ開発にもコストがかかるか、というと、何と先日WebLogicの開発作業のためのライセンス費用が無料になりました。つまり、GlassFishと同じように、誰でもいつでもじゃんじゃん使えるわけです。但し、商用サポート締結時に入手可能な膨大なるパッチの入手はできませんので、まあそういう風に割り切って、ですね。

[WLS] WebLogic Application Server: free for developers!
http://orablogs-jp.blogspot.jp/2012/10/weblogic-application-server-free-for.html

勿論、入手はWebから普通にダウンロードできます。

http://www.oracle.com/technetwork/middleware/weblogic/downloads/index.html?ssSourceSiteId=ocomen

スクリーンショット 2013-11-17 21.30.55

インストーラーは、ダウンロードしたJARファイルを「java -jar wls_121200.jar」と実行するだけです。下記のようなビジュアルなインストーラーが出てきますので、これを進めるだけです(多少面倒なところあり)。無論、CUI版でもOKですので、Xが起動できない現実の本番サーバーでも普通に作業可能です。

スクリーンショット 2013-11-17 21.52.01

開発環境は是非NetBeansを使いましょう。GlassFishと同じく、サービスタブから追加します。

スクリーンショット 2013-11-17 22.10.41

サーバーを追加したら、プロジェクトでWebLogic Serverに指定を切り替えます。

Screen Shot 2013-12-06 at 10.25.36 PM

あとは普通通りアプリケーションを「実行」すると、WebLogicが起動してWeb画面が表示されます。

何だ、環境的にはほぼGlassFishと同じじゃん!!!

プログラムの修正は必要か?

基本的にWebLogicは、特に最近のものは、内部のコンポーネントがオープンソース主体にどんどんシフトしてきています。GlassFishと比較しても、特に新しい仕様であるJSF2は同じMojarraが使われていますし、JPAもEclipseLinkです。設定ファイルもJava EE仕様のweb.xmlなどの標準がそのまま動きますので、WARを作成して配備して終わり、だったりします。

では非互換面はあるのか、と問われると、残念ながら、はい、あります。同じにしてよ!! と言いたいところですが・・・

設定ファイルとしては、Web系の設定ファイルがGlsssFish側は「WEB-INF/glassfish-web.xml」、WebLogic側は「WEB-INF/weblogic.xml」、EJB系がGlassFishが「META-INF/glassfish-ejb-jar.xml」でWebLogicが「META-INF/weblogic-ejb-jar.xml」とファイル名も中身の構成も全く違います。元々の出自が違うのでしょうがない面もありますね。

※一応最新版でどっちでも動くようになってますが、そもそも設定できる項目自体が色々違うので、あくまで暫定利用目的と思った方が良いです。

挙動的な非互換面としては、古い系のものがあります。特に違うのが、EJB周りです。WebLogicのEJB周りの仕様は2001年-2004年辺りで実装されたものが延々と使われ続けている経緯があり、初期化タイミングからリモートインタフェースの挙動、あとはWebLogic独自の(WebLogicのWebLogicたる所以でもある)T3プロトコル周りまで含めて、結構GlassFishと異なります。なので、この辺りをGlassFishの挙動をアテにしていたら、結構裏切られることが多く、最悪プログラムの修正も必要でしょう。

サーバー内部の実装もOSGI準拠の近代的な後発のGlassFishと比較して、WebLogicはいかにも重厚で巨大であり、何とも古くさい感じがします。現バージョン12cのオリジナルが2001年初頭頃登場(だったと思う)のWebLogic 6.0であり、そこからディレクトリー構成、設定ファイルを含めあんまり変わってない所も、イケてないところとよく非難される所ではあります。

まあ、とはいえアプリを作る側からすると、ちゃんと動いてくれればぶっちゃけどっちでもいい話でもあるかもしれません。

ただ、これらはかなり細かい面でもあるので、「だいたいそのまま動くよ、但し追加の独自設定ファイル(weblogic.xmlやweblogic-ejb-jar.xml)が必要だよ(特に本番目的だと)」と憶えておいてもらえればと思います。

運用にあたっての違い

GlassFishの運用も結構細かい知識が必要ですが、WebLogicの運用知識はGlassFishのものとはかなり異なります。最も違う特徴的な面は、Production Redeploymentという、古いアプリを動かしながら新しいバージョンのアプリを再配備するという、アクロバティックな機能です。これは24時間ノンストップ運用のために必須でありますが、結構きわい挙動もたまにあり、常に安定して動作させるためには現場の知見の蓄積が必要です。無視すればまあ、GlassFishのようにも使えます(笑)

またWebLogicにはかなり多くのパッチが提供されており、定期的にマイナーアップデートも出ます。商用サポートに入っていれば専用サイトで提供されていますので、それらを定期的に適用していく作業も必要になります。つまり、専任の技術者を育てる必要があります。まあ、GlassFishについても本番運用する場合は同じ話ではありますが、WebLogicの方がより多くの(数倍の)項目を設定できるため、そこは注意が必要でしょう。

なので、まあ内部実装の古くささ等もまるっと含めて、オープンソースでドラスティックに改良を続けるMySQL・Maria DB辺りに対する、商用の王道・互換性命のOracle Databaseの関係みたいなもんだと思ってもらえれば良いかなと思います。WebLogicも最初から徹頭徹尾、商用製品なんですよね。

GlassFish 4系からWebLogicに移行する

さて、GlassFish 3系以前からの移行については上記の通り、やることをやればだいたい問題ないと思います。では4系はどうか? 前述の通りですが、残念ながらWebLogic 12cのEE 7対応待ちになります。いつ出るのか? 繰り返しになりますが、オラクルの営業さんに聞いて下さい(笑)。私も残念ながら正確なところは知りません。

では他社の場合どうか? 残念ながらEE 7対応の商用アプリケーションサーバーはどこからも出てません。つまり、移行先はこの2013年度末時点で、無いのです。2014年は? 出るといいなぁ。出してね!!

まとめ

凄く面白くないまとめになってしまいますが、当たり前のことはそれはそれで重要なので、まとめておきます。

  • GlssFish 3系の移行先は、Java EE 6対応アプリケーションサーバーになります。
  • Oracle社の場合、商用版Java EE 6対応アプリケーションサーバーはWebLogic Serverになります。(今はFusion Middlewareという分類になっているようです)
  • Java EE 6に準拠していれば、(当たり前ですが)基本的なところは互換性があり、動きます。
  • 但し互換性のないところもあり、特にEJB周りと設定ファイル周りは注意が必要です。
  • 更に本番運用に際しては便利な機能も多い判面、パッチ適用も含め注意の必要な箇所も多いため、専門の技術者を揃える方が賢明でしょう。
  • GlassFish 4系の移行先は、2013年末時点では、ありません

さてJava EE Advent Calendarの次回(明日)はNorito Agetsumaさんの回です。宜しくお願いします!

JavaOne 2013 報告会 at 福岡 技術編

今頃書くな、という話ではあるのですが、JavaOne 2013報告会の2回目を福岡でやってます。丁度いまやってるので、事後報告ではあります(´д`)

JavaOne 2013 報告会 at 福岡 技術編
http://atnd.org/events/45326

スクリーンショット 2013-11-15 19.10.45

数日前に日本Oracle本社で喋らせて頂いたのですが、今年の5月、去年同じ場所で喋らせてもらった時と比較して考えても、現場の熱がだいぶ上がってきたなぁという感じがしています。

いろんな方から伺うのは、いまJava EEが凄いですね、という話です。延々やってきた身としては、ああ、そうなんだ、という感じではあります。が、感じとして似ているのは、J2EE 1.3が出た頃辺りかなと。

要するに、これから盛り上がりますよー、という前兆が見える状況にようやく至ったと考えるわけです。

いつもどっちかというと煽る側に立つ身としては、使えるものじゃないと煽ってもしょうがないよね、というのもあります。が、そもそも使えないものを煽るって酷いよね、という事もあり、J2EE 1.4やJEE 5は放置してきた経緯があります。

で、Java EE 6で超まともに育ったこの仕様の最新版ということで、EE 7のローンチ前よりEE 6っていいよ、と言い続けてきた甲斐があったものというものです。

そんでもって、いろんな方と今回会話させて貰う機会が多くあり、そこで何となく理解したのは、Java EE仕様の部分部分の情報はある程度みなさん共有できているものの、こうやったら上手く作れる、という知見については、やはり日本語書籍がほぼゼロという状況もあり、これからという非常に悲しい状況ではあります。

そのため、この会議では、特に誰もが弄ることが多いJSF 2.2について、NetBeansを使ってウルトラ超簡単な作り方のコツを1ステップずつやってみるものを作ってみました。

資料は先ほどできたばっかりで、これから発表(オラクルの寺田さんが現在発表中)なのですが、後ほどSlide Shareに掲載しようかと思ってますので、興味のある方は後ほどご覧下さいませ。

※追記 21:18
Slide Shareに上げました。