Enterprise JavaFX for EUC

この記事はJavaFX Advent Calendar 18日目です。昨日はぺこ @peko_kun さんの「JavaFXで画面遷移がしたい」でした。この記事の英語版も準備中です。昨年の「JavaFX導入騒動記」に続き、JavaFX導入に関する政治的なことをお話しします。


1. はじめに

昨年の今頃と比べて、JavaFXの存在感は大幅に増してきているように思えます。日本企業の取り組みはまだ十分とは言えませんが、JavaFXにはこれまでのどのJavaテクノロジーもなし得なかった、エンタープライズ分野のある問題点を解決する可能性を秘めています。それは「Officeレガシー」の刷新です。

「Officeレガシー」は西暦2000年前後に登場した、Microsoft OfficeによるEUC(エンド・ユーザー・コンピューティング)の枯れた姿です。企業の全社システムから取り残された部門単位の事務処理の自動化を、部門自ら、時にはベンダーに発注する形でシステム化したもので、コストを抑えるため全社的に導入されているMicrosoft Officeをプラットフォームにしているのが特徴です。Office EUCは決して悪いことではなく、実業務に直結する重要なエリアを部門の限られたリソースで効率化する有効な手段です。特にEUCに高い精度が求められる金融機関では、OfficeによるEUCであっても信頼できるベンダーに開発を発注し、保守契約も行っているケースが多く見られます。

筆者らが所属する部署は金融機関のOffice EUCを数多く提案・開発・保守・運用してきた、いわば「Officeレガシー」のスペシャリスト集団です。一方でJ2EEによる巨大EUCの開発・保守実績もあり、JavaFXの研究を進めています(日本語のみ注:JavaFXの研究成果をもとに小規模なパッケージ製品を開発し、完成した機能から販売を開始しました)。今回は筆者の実務の立場から話を展開してゆきたいと思います。

2. 「Officeレガシー」が抱える問題点

「Officeレガシー」には課題があります。わが国における「Officeレガシー」の多くはMicrosoft Office 2003によって構築されていますが、ご存知のように2014年4月をもってMicrosoft Office 2003の延長サポートが終了します。Officeのマクロ言語であるVBA(Visual Basic for Applications)は、次バージョン以降ではセキュリティ上の理由でその機能が大きく制限されており、そのままではアプリケーションが動作しないケースが少なからずあります。特にVBAのフルスクラッチで開発した高度なEUCの場合は大規模な改修を必要とします。そのようなEUCはAccessベースで構築されているケースが多いのですが、Accessがそれまでの個人向けデータベースを脱却しSharePointSQL Serverのフロントエンドへ方向転換を始めたため、移行をさらに困難にしています。

VBAが使いづらくなる反面、最新のOfficeではSharePointとの連携を強め、特別なプログラミングを行わなくても高度なEUCを実現できます。さらにカスタムのアプリケーション開発が必要な場合に備えて、.NET Frameworkベースのアプリケーション実行環境を持っています。しかし、既存の高度なEUCを.NET Frameworkで再構築するのはコストがかかり過ぎます。そこでやむを得ずベンダーに対して新バージョンへ移行するための改修を依頼することになるのですが、これはベンダーにとっても難題なのです。そもそも新Officeへの移行ノウハウが不足している状況であり、元のシステム要求によっては新しいVBAの制限により実現できないことさえあります。以降が不可能と判断した場合、ベンダーは代替システムの提案を行うことになりますが、その提案はWebシステムであることが多く、目に見える開発コスト(端的に言うとソフトウェアのライセンス費用)を抑えるためにJavaを選択する傾向にあります。少し前であればStrutsベースのWebシステムを提案するのが常でしたが、Webベースの貧相なユーザー・インタフェースは、それまでOfficeのリッチ・インタフェースに慣れたユーザーには極めて不評でした。この傾向はJavaServer Facesが主流となりつつある現在においても変わっていません。結局のところ、現在のEUCにWebシステムは馴染まないのです。

3. JavaFXによる「Officeレガシー」刷新プラン

しかし、リッチ・インタフェースを実現できるJavaFXであれば状況が異なります。JavaFXのサンプルであるEnsembleを開けば一目瞭然ですが、Officeのフォームでサポートされているコントロールと同等のものは概ね揃っています。JDK8と統合されたJavaFX8であれば印刷などEUCで求められる機能も追加されています。ベンダーにとっても、ビューはVisual Basic等のRAD経験者、それ以外をJavaプログラマーでチームを編成することで巧く分業することが出来ます(Webベースでは簡単そうに見えて意外と難しかったのです)。これは自社でJavaFXでの開発を行った際にあるVisual Basicプログラマーが語ったことですが、JavaFX Scene BuilderがMac上で動くVisual Basicのように見え、Javaの経験は皆無に近かったにも関わらず違和感なく開発できたとのことです。JavaFXによる「Officeレガシー」のリプレースは、上手く行きそうではないでしょうか。

エンタープライズ分野におけるJavaFXの可能性は、EUCの刷新だけではありません。基幹システムのフロントエンドとしても有用です。バックエンドにJAX-RSおよびWebSocketのエンドポイントを設け、デスクトップまたはJNLPのJavaFXアプリケーションからアクセスすることで、Webベースのユーザー・インタフェースよりも応答速度の速いUIを実現可能です。サーバー側としても、StatelessなJAX-RSを中心にシステムを構築できるため、システムのアーキテクチャが非常に簡潔になります。もっとも、基幹システムではWeb化が進んでおり、EUCほどの効果は得られないかもしれません。

では、JavaFXによる「Officeレガシー」のリプレースについて、特に需要が高いと思われるAccessのケースを想定して考えてみます。以下の提案の一部は筆者らが実務で導入したり、あるいは顧客に提案中のものです。

Case 1. 単体のJavaFXアプリケーションとして構築する

Case 2. フロントエンドをJavaFX、バックエンドをWebアプリケーション(JAX-RSまたはWebSocket)とする

Case 3. JavaFXアプリケーションにJava EEサーバーを埋め込む

単にAccessの.mdbをリプレースするのであればCase 1、.mdbを複数のAccessで共有したり、あるいは外部のデータベースと接続しているようであれば規模に応じてCase 2またはCase 3を採用するのが妥当でしょう。特に中小規模のシステムではJava EEサーバーを個別に構築する余裕はないため、Case 3の埋め込みJava EEサーバーが有力な候補となります。

では、Caseごとに詳しく見てゆきましょう。

Case 1. 単体のJavaFXアプリケーションとして構築する

javafx-euc-1.png

構造的には最も簡単で、SQLiteJava DBApache Derby)などのファイルベースRDBを用いることで比較的簡単にデータベース・アプリケーションを構築できます。フロントエンドにJavaFXを用いるため、Accessのフォーム並みの表現が実現可能です。クエリーについてはさすがにAccessほど容易ではありませんが、JPA(Java Persistence API)はJava SE環境でも利用できるため、統合開発環境との組み合わせで開発生産性は一昔前よりも向上しています。実際のところ、高度なEUCではAccess上で直接SQLを記述しているので、開発工数自体は大きく変わらないでしょう。

データベースへの接続はJDBC経由でも、あるいは埋め込みデータベースを用いても構いません。筆者の経験では、開発中はJDBC経由でアプリケーション実行中もデータベースを参照できるようにしておき、実運用ではオーバーヘッドの少ない埋め込みデータベースを使用すると、最も問題の発生が少ないと感じています。

Case 2. フロントエンドをJavaFX、バックエンドをWebアプリケーション(JAX-RSまたはWebSocket)とする

javafx-euc-2.png

スタンダードなWebアプリケーションの代わりに、フロントエンドにJavaFXを用いるパターンです。適用範囲は3つの案の中では最も広く、小さなものから基幹系サブシステムに匹敵する大規模EUCまで対応できる構成です。GlassFishをはじめとするいくつかのアプリケーションサーバーはファイルベースのRDBを同梱しているため、別途データベースを用意することなくシステムを構築できます。もちろん、MySQLMariaDBPostgreSQLなど外部のデータベースを利用することも出来ます。フロントエンドを複数用意すれば、マルチユーザーでの利用も可能です。

この構成における鍵は言うまでもなくJAX-RSですが、それ以外にも悪名高いEJBと、最近話題のWebSocketは是非とも取り入れておきたい技術です。もちろん、Case 1同様JPAも外せないケースが大半でしょう。この構成では多くのJava EE APIを利用することが出来るため、従前以上の機能を持たせることも可能です。

少し前であれば.NET Frameworkで構築したフロントエンドとJavaのバックエンドをSOAPで繋ぐケースが多く見られましたが(SOAがもてはやされた時期とも重なります)、実際のところ成功例はあまり多くありません。特に中小規模のシステムにとってはSOAPのオーバーヘッドが負担となり、あまり望ましい結果にはなりませんでした。

EJBはとにかく悪いイメージが先行していますが、現在の仕様ではビジネスロジック向けのPOJOです。EJBそのものは多機能ですが、JPAとの連携に的を絞り、トランザクション管理を自動化する仕組みとして割り切って使うだけであれば、ハマりどころはほとんどありません(むしろ通常のPOJOだけで構築した方がハマります)。

WebSocketはサーバーからクライアントへの通知を実装するのに有効です。WebSocketを活用すれば、従来のようにクライアントからサーバー側へ定期的に問い合わせる必要がなくなります。「Officeレガシー」ではデータを取り込むと同時に図表や帳票等をリアルタイムに更新できますので、そのような機能を代替する上でWebSocketが役立ちます。JavaのWebSocket APIはJava SE/EE両対応の優れものです。

Case 3. JavaFXアプリケーションにJava EEサーバーを埋め込む

javafx-euc-3.png

Case 2はJava EEの強力なパワーを生かして広い範囲に適用できるというメリットがある反面、小規模システムではサーバーを別途構築・運用するという負荷がかかります。そこで、Case 2のメリットを生かしつつCase 1の簡潔さを求めるのがこの案です。

GlassFishをはじめとするいくつかのJava EEサーバーはライブラリの形でJava SEアプリケーションに埋め込むことが出来ます。そして、Java SEアプリケーションから任意のタイミングでサーバーを起動し、アプリケーションをデプロイして使用することが可能です。この仕組みを利用すると、Case 2とほぼ同じ機能を実現しつつ、システム構成をコンパクトにすることが出来ます。

では、どの案がベストなのか?

以上のプランを提示すると必ず尋ねられるのが「では、どの案がベストなのか?」ということですが、それはリプレース対象のシステム要求によって左右されるので一概には言えません。しかし、現在使われているAccess EUCの使われ方を見る限り、Case 3を第一選択肢としつつ、ユーザーの使用状況(同時使用ユーザー数など)を勘案してCase 2の選択も視野に入れる、というのが私の個人的な見解です。

AccessのJet Databaseエンジンが使用しているMDBは、シングルユーザーで使用されることを前提に設計されています。しかしAccess EUCでは、1つのMDBを複数のAccessで共有するケースが少なからずあり、厳密なトランザクション管理が必須となります。酷いケースになると、ネットワーク上の共有フォルダにMDBを配置し、それを複数のAccessで利用していることもあり、そうした環境ではMDBの破損事故が後を絶ちません。私たちの部署がJavaFXに注目したのは、Javaの強力なトランザクション管理を生かしつつAccess並みのUIを実現しうる技術であると考えたからです。特に前出のCase 2およびCase 3ではEJBを使用できるため、トランザクション管理のコーディングを大幅に削減することが出来ます。

4. 今後の展望

JavaFXは国内における実績が少なく、実際に使用してみても機能面で不足していると感じることがあります。しかし、そのポテンシャルは非常に高く、Java EEと組み合わせることでエンタープライズ領域でも十分に活用できると考えています。

とは言え、JavaFXをいきなり企業の基幹システムに組み込むというのは、特に保守的なことで知られる日本企業ではなかなか受け入れられないと思われます。まずは規模が少ないがユーザー要求と適合しやすいEUCへの導入で実績を積み重ねて行くことが重要ではないでしょうか。


明日は私の元助手、@yumix_h こと平岡由美が担当します。同日にエントリしているJava Advent Calendar 2013とあわせて何かをやらかすつもりでいるようです。ちなみに明日で彼女は23歳になりますので、お祝いのツイートなりコメントを送ってあげてください。