Good-bye EJB, Hello CDI – Java EE Advent Calendar 2015

This is for the “Java EE Advent Calendar 2016” event material among Japan. Thanks for using auto translator for English. 

Java EE アドベントカレンダー2015の12月23日分です。寺田さんの記事からの続きになります。

※注: 内容がエンタープライズ開発の中核方面に寄っているので難度高かなという気がします。

今年のJavaOne 2015ではキーノート発表に日本人として超久しぶりに登壇させてもらったり去年に引き続きセッションを一枠喋ったりとなかなかのプレッシャーでしたが、なんとか無事終わりほっと一息、なんて余裕が全くないのですが、そんなことより個人的にショックなことがあったのでそれを書きます。

こういう記事が雑誌(そもそも消えてしまった)や日本語商用技術サイトに載らなくなったってのが、多分日本全体の技術力の低下&乗り遅れの証なんだろうなと思いつつ、日本語で情報発信しなくなった私も元凶の一人かもしれないですね。が、個人的に日本語で発信する意味が全くない(私はSIerでもベンダーでもない)ので、逆に来年のAdvent Calendarは多分英語で書いてる気がしています。

さよならIIOP

ショックだったのがこれ。JCPに加入しているので仕様策定の状況を見てた訳ですが、IIOPが遂にJava EE 8からオプショナル扱いになるかもしれない、という話題が急遽入ってきた訳です。で、最近使ってないからいいんじゃねパーフェクト、みたいなノリでガンガン話が進んでいくわけです。

で、Java EEを丸17年間ほぼフルで使ってる私としては、おいおいちょっと待った、と。使ってない輩が勝手に仕様を削るなよと。使ってる側の話を聞いたのかよと。とまあそんな感じをまとめて私も投稿するわけですが焼け石に水。一人で世界は変えられないのでした。

で、多分IIOP (アイアイオーピー)って何よ?とほぼ10人に9人が謎に思うと思うので改めて。ざっくり言うとIIOPはCORBA仕様の通信部分のGIOPをTCP/IP互換にしたものなんですが、それはどうでも良くて、最も重要な部分はXAに対応してるJava EE内唯一の汎用通信プロトコルなわけです。RMIとの互換性を持たせてるのでRMI-IIOP (アールエムアイ・オーバー・アイアイオーピー)という仕様になってます。WebLogicではそれを更にラップしてT3 (ティースリー)という高機能プロトコルが提供されてます

で、次にXAって何よ?の回答なんですが、JDBCにXA対応、ってのがあるのでそれで気付く人が居たら嬉しいのですが、分散トランザクションの標準プロトコル、ってのがざっくり回答でしょうか。要は、複数のシステムに跨がってACIDトランザクションを制御できるってものです(ACIDはぐぐってね)。複数システムで処理する内容があったとして、どこかでエラーが起きたら複数台丸ごとロールバックできるという素敵仕様です。金融系処理には欠かせない処理、と言えばなんとなく想像付くでしょうか。お金情報が壊れたら嫌ですよね。ある日突然増えてたりとか減ってたりとか。

このXAはTuxedoや日立のOpenTP1などで1990年代後半に一世を風靡するのですが、まあそれをWebLogicがサポートして、J2EE 1.2の標準仕様に盛り込まれ、金融系システムに2000年代前半に広まっていくというサクセスストーリーな訳です。私もだいぶお手伝いさせて頂きました。

で、IIOPをオプショナルにするとなると、アプリケーションサーバーとしては標準としてサポートしなくても良くなるわけで、三大Java EE商用アプリケーションサーバーであるWebLogic, WebSphere, JBossのどれかが将来にサポートを外してくる恐れがあるわけですね。こいつぁ困った。ということでJavaOneで直談判に行ってきました。

さよならEJB

でまあいろんな偉い人とディスカッションしていくわけですが(仔細は割愛。言えないこととかも沢山出てきた気がするので)、そこで追加で分かったのは、やっぱりEJBも将来無くなりそう、ということでした。あーやっぱり・・・時代はCDIなのです。

個人的にはEJBこそがJ2EE–>Java EEの華であり中核であり、WebLogic 3.0からEJBを使ってきた身からすると大変寂しい話ではあります。が、やはりEJBは機能がてんこもり過ぎて、必用な分だけ能動的に選択できるCDIは時代の要請でもあります。

で、Java EE 7のCDI仕様を見ると、EJBでサポートされてるけどCDIでサポートされてない機能がまあ沢山あります。どこからEJBでどこからCDIかさっぱり分からんというところもありますが、両方で使えるもの、という意味だとざっと考えて・・・

  • 既にサポートされてるもの(両方で使える)
    • 自動トランザクション制御 (@Transactional)
    • SOAP通信 (@WebServices)
    • REST通信 (@GET, @PUT)
    • JPA系制御
  • まだサポートされてないもの(EJBでしか使えない)
    • インスタンスプーリング
    • セキュリティー制御
    • 呼出のJNDI登録・参照
    • Message-Driven Bean (みたいなJMSサーバー側簡易機能)
    • Singleton Bean (みたいなSingletonパターン機能)
    • EJB Timer (みたいな時間制御)
    • IIOP通信 (EJB Remote) + XA制御 (with IIOP)

※Entity Beanは?とか聞かないで下さいね・・・もう無いです

と見ていくと、「まだサポートされてない」ものの中で落とされていくものがなんとなく色分けされていきます。どれが落とされるか分かりませんけど、少なくともIIOP+XAは当確な感じになって参りました。あーあ。

でまあ、そんなに後ろ向きだと生きるのが辛くなるし代替技術も無いので、しゃーないですなと気持ちを切り替え、XA使わないアーキテクチャーに変えていけばいいんじゃね?という方向にシフトしていく訳です。そもそもXAは完璧ではない(in-doubt windowとかあるし)ので、この方向もアリはアリです。

但し、現在動いているシステム群は一体どうするのよ?という疑問も当然あります。Webスタートアップ系の単一システムならまだしも、例えば金融系はアホみたいにシステムがある(数百から数千規模)のが普通なので、それをひとつにしていくというのも何となく無謀な感じもします。書いてると絶望感しか沸いてこない・・・で、唯一の方策というのは、製品利用企業が正しく声を上げてベンダーにIIOPをサポートさせ続けるということでしょう。プレッシャーかけていきましょう。

こんにちはCDI

さて、悩み深いリアル金融系システムはさておき、大半の利用側はCDIバンザイな気がします。配備時に実装クラスを自動生成&コンパイルして動作するEJBに対して、単純に機能がインジェクトされて動作するCDIの方が、エラー発生時も分かりやすいですし、何せテストがやりやすい。

あとは現在EJBから移行されてない機能が恐らくJava EE 8〜9で追加されていくはずなので、それを待てばEJBがこの世から消える算段ができ、初学者はCDIだけ勉強すればあとはJSFもJPAもOKな幸せな世界になると思います。そう考えてCDIに仕様を移してきているので当然です。

CDIそのものの説明は既に大量にあるので省きますが、EJB特にSession BeanからCDIに移行するために何が必用か、というところだけ補足しておきます。

Session BeanからCDIへの移行はアノテーションの一括置換で概ね行けます。ざっくりとこんな感じと考えればいいでしょうか。

EJB Session Bean CDI
Class宣言箇所 @Stateless @Named
@Dependent
@Transactional
EJB呼出し箇所 @EJB @Inject

他を言い出すとあれやこれやありますし、EJB Remoteどうすんの(=移行先が無いので削ってアーキテクチャー変更)とか沢山有りますけど、こんな感じでの基本移行パターンを考えておく必要があるかと思います。

さてそろそろ長くなってきたので結論ですが、次の世代のEJB (特にSession Bean)は以下の書き方になっていくことでしょう。ただ、現在のJava EE 7だと機能が足りなさすぎる気もするので、ご自身のソフトウェア特性に応じて使いこなしましょう。ツールに踊らされるのは本末転倒です。

@Named
@Dependent
@Transactional
@Path
public class AnBusinessLogic {

    @Inject
    private NextBusinessLogic theLogic;

    @Inject
    private ThirdBusinessLogic thirdLogic;

    @POST
    @Consumes("application/json")
    @Produces("application/json")
    public AnReturnValue theMethod(AnParam param) throws BusinessException {
        // Check param values.
        AnReturnValue result = new AnReturnValue();

        // Call other logics to operate.
        result.theResult = this.theLogic.businessMethod(param);

        result.thirdResult = this.thirdLogic.otherBusinessMethod(param);

        return result;
    }

    ....
}

明日12/24の回はhondaYoshitakaさんの番です。Merry christmas and a happy new year!

Welcome Rakuten Technology Conference 2015 (Fukuoka Location)

New seats where added and tickets registration is available. Please, register as soon as possible before is too late. 

ご盛況により当初想定よりお申し込みが多くなっていました。
新たに増席し、現在、申し込みが可能となっています。
ご興味がある方は、ぜひお早めにお申し込みください!

We are very proud to inform that this year Fukuoka Technology Conference has a lot of interesting presentations about the current trend on e-business from Rakuten Ichiba, Rakuten Travel and Rakuten Card in Fukuoka.

If you want to hear how our business are implementing the current technology, come to see our conference. We will be very happy in explain our services.

Also, come to talk with our employees in our Happy Hour. This is a place that you can enjoy food & drinks and talk with us. Please, feel free to have a nice conversation with us.

今年も福岡でやります!! 楽天テクノロジーカンファレンス2015です。

今年は、楽天市場、楽天トラベル、楽天カードなど、実際にドライブ中の最新トレンドについて、(東京からのサテライト込み込みですが) 福岡からも発信します! Web技術を中心として、主にJava EEやエンタープライズ系開発について、結構ディープにやっちゃいます。

また軽食・お飲物提供タイムも用意しました。現場で開発している社員も参加します。色々聞いてみて下さい。お気軽にご参加下さいませ。

2015110213312220151102133131

presentationBDF7C1B4-0509-407E-B8D0-5B9D49623535.jpg

FukuokaRTC

Date / 日時

Nov. 21st, 2015, Start 10:00

2015年11月21日(土)10:00〜:受付開始

Place/ 開催場所

Fukuoka Center Building 12F,
2-2-1 Hakataekimae, Hakata-ku, Fukuoka City,
Fukuoka, Japan

福岡県福岡市博多区博多駅前2丁目2番1号
福岡センタービル12F

http://tech.rakuten.co.jp/access.html#access-fukuoka

Registration / お申込み

https://www.eventbrite.com/e/rakuten-technology-conference-2015-tickets-18950765249

Procedure / お申込み手順

1. Push “REGISTER” button. / みどり色の「REGISTER」ボタンを押して・・・
2. Apply from “(Satellites) Fukuoka”. /「(Satellites) Fukuoka 福岡サテライト」からどうぞ!

20151102145410

 

Time Table /タイムテーブル

Time Location A
(Conference)
Location B
(Cafeteria)
11:00 Java EE Applications for Transaction Services by Kota Fujita [Track A]
Talk by Yutaka Matsuo by Yutaka Matsuo
12:00 [Track A]
Fun Research in Computer Vision : from robots, sports, face to medicine by Takeo Kanade
Lunch
13:00 [Track A]
Keynote by CEO by Hiroshi Mikitani
[Track A]
Keynote by CEO by Hiroshi Mikitani
14:00 Better working framework for smart device service by Shimizu Yosuke [Track B]
Rakuten Ichiba by Yoshihisa Onoue
15:00 About JavaEE and DevOPS by Nakada Hiroaki [Track E]
Rakuten Travel by Kazuhisa Naoi and Shinoda Takeshi
16:00 [Track B]
Rakuten Card by Hirofumi Iwasaki and Ameen Arshal
[Track B]
Rakuten Card by Hirofumi Iwasaki and Ameen Arshal
17:00 Closing
17:30 Lightning Talk & Happy Hour

 

Sessions in Fukuoka / 発表内容(福岡)

 

Java EE Applications for Transaction Services by Kota Fujita.

11:00〜    at Location A (Conference) in Fukuoka

Today’s e-businesses are changing very fast introducing new standards and new technologies every year. This session will explain why we selected Java EE as our platform and How we are implementing it to allow agile and safe transaction system.

 

Better working framework for smart device service by Yosuke Shimizu.

14:00〜    at Location A (Conference) in Fukuoka

We believe that promoting excellent synergy between business, development and operation; creating a working environment that support each area demands; and building multinational team; It is possible to have rapid and reliable development contributing for better user satisfaction and more revenue. Some of key concepts is to have 100% in house development on both the Client and Server side and to have high qualified engineers capable to do planning, development and operation. As a result, we could optimize our working framework providing better products with high quality and very good customer satisfaction.

 

About JavaEE and DevOPS by Hiroaki Nakada.

15:00〜    at Location A (Conference) in Fukuoka

Our system is continuing to grow and introducing new technologies is becoming our normal operation flow. This session will explain over view of our development and operation.

 

 

お申込みは、こちらから!

https://www.eventbrite.com/e/rakuten-technology-conference-2015-tickets-18950765249

My JavaOne 2015 Session: CON3339

Screen Shot 2015-09-26 at 10.50.10 AM

Happy programming weekend! I’m going to have a speaking session in JavaOne 2015 on Oct 28, 11:30 AM, with my colleague Arshal as below. See you on SF.

Real-World Batch Processing with Java EE [CON3339]

Arshal Ameen, Team Manager, Rakuten, Inc.
Hirofumi Iwasaki, Group Manager, Rakuten, Inc.

Batch processing plays a key role in most organizations, mainly because it doesn’t need much human intervention. This session explores various ways in which batch processing can implemented with Java EE. It includes SWOT analysis of batch implementation with JSR 352 and embedded EJB containers. By the end of the session, the attendees should be able to understand when to use JSR 352 and when not to, the benefits of using an embedded EJB container for batch processing, and the best practices to follow when designing batch processes.

Conference Session
Wednesday, Oct 28, 11:30 a.m. | Parc 55—Cyril Magnin II/III

最速で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さんの記事になります。最終回ですね。

My Interview of Nikkei Computer Aug 7th, 2014

Nikkei Computer 2014-08-07

http://itpro.nikkeibp.co.jp/atcl/ncd/14/072900011/

Today one of the most largest share of the Japan computer magazine “Nikkei Computer” Aug 7th, 2014 issue was published. Main theme of this issue is the EOL of each libraries and software.

This first special pages are edited by my interview, which was held on July. The discussion point is the Struts 1 EOL issue, which was  almost same theme as the my session of Java Day Tokyo 2014.

If you can see this issue, please check it. Unfortunately, this articles are written in Japanese only. Of course, the “Nikkei Computer” magazine is also for Japan only 🙁

My JavaOne 2014 and Oracle OpenWorld 2014 Sessions

Happily announced that my call for proposal for JavaOne 2014 and Oracle OpenWorld 2014 were approved successfully. Now I’m one of a session speaker of them. Amazing.

Java EE 6 Adoption in One of the World’s Largest Online Financial Systems [CON2789]
https://oracleus.activeevents.com/2014/connect/sessionDetail.ww?SESSION_ID=2789

Case Study of Financial Web System Development and Operations with Oracle WebLogic 12c [CON2820]
https://oracleus.activeevents.com/2014/connect/sessionDetail.ww?SESSION_ID=2820

My first time attendance for JavaOne conference was 2000. 14 years ago. Very huge conference, over 30000 people attended, held in Moscone north and south completely. The key note speech was held in all connected Moscone center south rooms. The surprise guest speaker was Steve Jobs, with performing not released Mac OS X 10.0 development version with J2SE 1.2 Swing application. I was so exited about the brilliant future of the Java programming language and enterprise usage.

At that time I learned many of the J2EE 1.2, which was renewed from Project JPE at the end of 1999. I’d already worked with BEA WebLogic 3.0 – 5.1 in Japan, and realized that the differences between the J2EE specs and the implementations. And one of my dream was to have a session as a speaker for J2EE technical information sharing here.

Now my dream come true.

In this sessions I’m going to share the details of my designed Java EE 6 applied financial enterprise systems in Rakuten in Japan. Java EE has huge potentials for the mission critical enterprise systems, and you can learn how to use the EE specs and WebLogic for it.

Now I’m happily making the slides for speaking right there. Come and join us. Happy programming.

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.

サンフランシスコの街角

Scan-131124-0002
(Click to large)

これまでの流れを考へると何となく場違いな(笑)コンピューターな話題が續いてしまったのだが、そろそろ年末であるため、今年の寫眞についてもゆるりとまとめておきたい。

今年の9月末にJavaOneカンファレンスの爲サンフランシスコにまたもや行ってしまったのだが、前回の教訓として「重い物はヤバい」といふのがあった。まあ、重いのを背負って一日中移動しまくると云ふのは確かに考へた方が良くて、去年はHASSELBLADと散々比較して悩んだ擧げ句、万能用途としてF6とAF-S VR 24-120mm(旧型)をリュックに突っ込んで行ったものの、デカいわ重いわで碌な想い出が無いといふ散々な結果に終はってしまったのであった。ハッセルを持っていかなかったのだけは、正解であった。

そのため、今年は思ひ切ってレンジファインダー至上最軽量のXAをポケットに突っ込んで行った。結果は大成功で、無限遠に固定して街角でパチ、ギーギー、何かあったらパチ、ギーギー、とまあスナップ用途としては確かに素晴らしい成果を挙げたのであった。

第一、この写ルンですの元ネタでもあるXAは端から見ても只の玩具であり、もしくは激安のデジカメ型落ち品のやうにも見える。このためクソ危險なサンフランシスコの街中でも、盗まれる恐れも、その爲に襲はれる恐れも少ないのである。絶対高値で賣れないであらうことは素人目にも明らかなのだ。iPhone 5Sで撮る方が100倍危ない。

XAのレンズは一応、瑞光の名前が入っているものの、まあツァイスのテッサーもどきな小型レンズの割に描寫は微妙といふものかなと思ふ。この寫眞のスキャン結果を見ても分かるとおり、今年の街角でもあら不思議、80年代の薫りが。要するに、逆光氣味で撮るとボワーンとなってしまうのである。順光だといいんだけどね。

ピントが合ってるところは流石にテッサー型であるためか、至って鋭い。ISO 400のフィルムの粒子の粗さも相まって、なかなかの雰圍氣である。

まあ、逆に云ふと變なコーティングやら何やらが無くて至って普通の何の変哲もないレンズだ、とも云へるだらう。

XAは持つ喜びと云ふ世界とは無縁のプラカメであるものの、かういふ用途には絶好である。同行の士に「それ何?」と何度も聞かれたが、「只の35mmフルサイズのカメラ」と應へておいた。殘念ながらこの洒落はほとんど通じなかったやうだ。

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さんの回です。宜しくお願いします!