※ WebLogicだけ書いておくのも何なので、その他の商用Java EEサーバーもこちらでまとめてみました(2013/12/08 22:20)
https://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以外のサーバーを補足しました。
https://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
インストーラーは、ダウンロードしたJARファイルを「java -jar wls_121200.jar」と実行するだけです。下記のようなビジュアルなインストーラーが出てきますので、これを進めるだけです(多少面倒なところあり)。無論、CUI版でもOKですので、Xが起動できない現実の本番サーバーでも普通に作業可能です。
開発環境は是非NetBeansを使いましょう。GlassFishと同じく、サービスタブから追加します。
サーバーを追加したら、プロジェクトでWebLogic Serverに指定を切り替えます。
あとは普通通りアプリケーションを「実行」すると、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さんの回です。宜しくお願いします!
