ニュース
2004/05/19 19:15 更新


「J2EEによる開発真意とは」──多くの来場者を集めたJavaテクノロジーをひも解く講演

Javaテクノロジーの在り方を知れば、先に登場する技術にも応用が利く。日ごろ何気なく使っているかもしれないJSP、EJBなどには、歴史を重ね、進化してきた理由がある。

 「IBM Software World 2004」の2日目、5月19日にはテクノロジーDAYと題し開発者向けの講演が連なった。午後からのセッションでは、日本アイ・ビー・エム、ソフトウェア事業部テクノロジー・エバンジェリストの米持幸寿氏からJavaアプリケーション開発真意を知らしめるべく、個々のテクノロジーをひも解く講演が行われた。会場には幅広い層の来場者が集い、これからJavaに取り組みたい、日ごろから取り組んでいるが復習をしたいといった層からも関心の高さがうかがえる。

05190076.jpg

多くのメディア、セミナーなどでJ2EEの啓蒙活動も行う米持幸寿氏。その分かりやすい語り口は定評だ


 冒頭で米持氏からこのセッションを企画した理由は、「多くのメディアによる情報は、技術先導で語られることが多い。なぜ? 個々のJavaテクノロジーが目的を持って位置づけられているのか、という点が理解できなければ、先に応用が利かなくなってしまう」と語られた。この点は、報道であれば思い当たる節があり……、冒頭から釘付けにしてくれる。

 また、Javaの意義は何なのか? というシンプルな問いについて米持氏は、2004年3月に開催された「IBM Software Solution 2004」でエグゼクティブ向けとして紹介した「アプリケーション寿命」「ヘテロジーニアス環境での利用」「特定ベンダーにコントロールされない」「完全なオブジェクト指向である」を挙げた(関連記事)。今回は、開発者向け講演ということもあり、それぞれの詳細は省かれた。

 以降、米持氏の言葉を借りて、個々のJavaテクノロジーの在り方をひも解いてみよう。

初期の技術「サーブレット」の登場

 初期におけるJavaアプリケーション開発は、サーブレット(Servlet)によってCGIを置き換えていく目的で始まった。サーブレットは、オブジェクト指向的な差分開発が特徴であり、現在王道なフレームワーク開発とはひと味異なるものだ。

 この時期は、CGIに勝るパフォーマンスを実現すべく(注:現在では、CGIでもオブジェクト指向なアプローチがある)、サーブレットによってオブジェクト指向であること、HTTPとWebアプリケーション層が分かれていることがビジネスアプリケーションとして利用可能という実証となった。日本アイ・ビー・エムでは、長野オリンピックの公式サイトをサーブレットで構築し、その効果を業界へ知らしめることになる。

サーブレットとデザイナーの作業を分業、それがMVC型のJSPに進化した

 サーブレットの利用が増すにつれ、さまざまな要求が増していった。なかでも多かったのは、ビジネスアプリケーションにおける画面を多数作らなければならないというもの。そして、この背後には、JSPが登場する要因が秘められていた。

 いちばんの理由は、画面デザインとコード開発を分けることにある。サーブレットを記述するプログラマと画面を作るデザイナーとで同じソースコードを共有するには無理があり、JSPは、各専門家が担当する個所は分けるべきという需要から生まれた。単独開発ならば必要はないが、チーム開発が背景にあるわけだ。

 米持氏自身、「当時を思い出してみれば、JSPが面倒だと思っていた頃がある」とコメントする。しかし、最近の開発統合環境(IDE)では、開発生産性を意識したものが多くこの時期の開発では、一般的に多々無駄な作業を行っていたのも事実だと語る。

 その無駄とも思える作業の一端を具体的に挙げれば、JSPコードにはタグの中に属性が入る。例えば、画面要項の変更があり、いざ変えるとなるとかなり高度な処理が必要になっていく。

 「JSPは、言ってみれば分離し過ぎてしまったテクノロジー」と米持氏。結果的には、JSPベースの開発ソフトウェアも作りづらいという図式になってしまった。

JSFによって統合開発ツールが開花し出す

 JSPの反省を基にJSFが登場する。従来(JSP)までは、いわば「コード生成ツール」とでも言えばよい状況にあったアプリケーション開発は、前述のように画面色調ひとつを変えるにも、生成し直す必要がある。つまり、反復開発ができないために生成後は二度とツールが使えない。生成を繰り返すわけだ。

 そのような背景から、JSFによって開発ツールで優れたものが登場し出すことになる。

ブラウザ上でもVBと同等な動作が実現できている

 Javaアプリケーションを評価するユーザーの中には、ブラウザアプリケーションの些細な動作にも導入をためらう要因があるという。ブラウザは使いづらいという見解だ。

 しかし、ブラウザ上でもVisual Basic(VB)と同等な動作が実現できている。例えば、従来ブラウザで実現しづらかったものとして、多数の入力フォームがある画面上で数値入力をする際、ひとつのフォームで数値入力上限値に達すると、次のフォームへ自動的にカーソル移動するという仕様がある。これは、ダム端末に慣れているユーザーには、作業効率化に欠かせない機能だ。

 ほかにもメインフレームに慣れているユーザーからは、同じくフォーム内で入力を終え、「Enter」キーを押すと次のフォームへカーソルが自動移動するなどは、これらも当たり前の仕様だという。実現できなければ、ブラウザアプリケーションは使いづらいとレッテルを貼られ、無理せずVBアプリケーションを使えばよいのだという展開になる。しかし、このような細かな動作も現在は実現されており、ブラウザ上は使いづらいと決めつけるのは浅はかだ。JSF登場により開花された。

EJBの真価はコンポーネント化ではない

 なぜEJBがあるのか。ユーザーによってはコンポーネント化だよね、難しいよね、などという意見が聞かれる。しかし、EJBの真価は、分散トランザクションをサポートするためのものであり、技術先行で判断してはならない。投資対効果は取り組んだ当初なかなか難しいが、必ずやEJBの真価が感じられるという。

 また、ある程度EJBによる開発を行っていると、「Namingサービス」が壁になる。なぜこんな難しいコードを記述しなければならないのか、と悩む人は多い。Namingサービスは、抽象レイヤーを作って分離するためにある。これは、ベンダーアプリケーションに依存しないため重要なものであり、抽象化することで穏健が受けられるというものだ。例えば、JDBCへのアクセスを行う場合、直接にアクセスせず、Namingサービスを利用することで抽象化が実現される。

 ビジネスアプリケーションにおいて、例えば10年後もDB2を利用し続けていると誰も決めつけられないだろう。その環境移行の際には、もちろんベンダー依存してしまうコード記述があってはならない。

 ほかにも幾つかのテクノロジーについて、米持氏からの見解が述べられた。日ごろ何気なく利用している個々のテクノロジーであっても、在り方を理解することで正しく使うことができるというメッセージが込められている。さらに「EJBはトランザクション実現、分散コンポーネントをWeb上で実用的に使える唯一のもの。いちど使い慣らせば手放せなくなる」と米持氏は強調する。

 なお、今回講演された内容と同等かは不明だが、6月3日に開催される大阪会場のIBM Software World 2004(B-4)でも米持氏が講演を行う予定だ。

関連記事
▼特集:WebSphereで始めるJ2EEプログラミング
▼「企業変革を支えるのはIT」──ますます高まるIT部門と柔軟なITインフラへの期待
▼「ソフトウェア開発にもオンデマンドを」──Eclipseを基盤とするIBMの統合化戦略
▼日本IBM、SOA関連のサービスとミドルウェアを発表
▼今さら人に聞けない「e-ビジネス・オンデマンド」
▼「オープンでなければIBMも生きていけない」と日本IBMのソフトウェア事業部長
▼オープン標準で企業に即応力をもたらすIBMのe-ビジネス・オンデマンド構想
▼特集:第1回 いまから始めるEclipse−Windows、Linux対応機能ガイド

関連リンク
▼IBM Softwareチャンネル
▼IBM Software World 2004|日本アイ・ビー・エム

[木田佳克,ITmedia]

Copyright © ITmedia, Inc. All Rights Reserved.