レベル: 中級 Nicholas Chase (nicholas@nicholaschase.com), President, Chase and Chase, Inc.
2007年 2月 06日 前回「Geronimo への転向」を書いたとき、私は Spring のどこがそんなに素晴らしいのか不思議でしたが、その謎が解けたとき、今度はJSF (JavaServer Faces) の人気の理由を教えてくれる人が必要だと冗談にしました。その後どうなったかと言うと、JSF の実装に焦点を当てたApache Geronimo と Apache MyFaces の共通部分に関する記事を書いて欲しいというリクエストが寄せられました。この話題を取り上げたのは正解でした。Geronimoと MyFaces の統合に取り組んでいる IBM® の Tim McConnell から話を聞いた私は、このような仕様が実際はどのように実装されるかについて期待以上のことを学んだのです。
Apache MyFaces とは何か
最初に知りたかったのは、そもそもなぜ Apache Geronimo が Apache MyFaces に関係しているかということです。Timの説明によると、これは J2EE (Java™ 2 Platform, Enterprise Edition) 1.4 から JavaEE (Java Platform, Enterprise Edition) 5 への移行の一環だということです。「Geronimo はすでにJ2EE 1.4 準拠のアプリケーション・サーバーですが、1.5 仕様の一部として JSF がサポートされなければなりません。私たちはその方法として、ApacheMyFaces を使用しているのです」。
早速、興味をそそられました。非常に重要だと考えられている技術があって、すでに Java EE 仕様には追加されているというのですが、その技術とは一体どんなものなのでしょう。Timの説明はこうです。「JSF の背後にある意図は、Web アプリケーション開発を簡易化することです。JSF はモデル・ビュー・コントローラー (MVC)パラダイムにちなんでモデル化されています。実際は MVC の実装とほとんど同じことで、これがまさに JSF の意図です。Web 開発を経験したことがない人でもMVC には馴染みがあるので、JSF を取り上げて短時間で効率的に習得して Web アプリケーションを開発できるようになります」。
もっともな理由に聞こえますが、それだけではないはずです。そこで腰を据えて JSF の実態を調査することにしました。その結果わかったのは、私はJSF を避けるためにかなりの苦労を自分に強いてきたということです。
Java での Web を開発したことがあるなら、JSP (avaServer Pages) についてはもうご存知でしょう。JSP は、Javaコードを HTML 内に直接組み込んで実行させることができるページです。でもそれより重要なのは、JSP では Java コードを表すカスタム・タグを作成できるという点です。これはサーバー・パフォーマンスの点で効率的であるだけではなく、保守性にも非常に優れ、技術分野以外の人でもページを編集できるようになります。
JSF では JSP のプロセスがさらに拡張されています。JSF は Web ページにプログラミングしなければならない共通のもの (大部分はフォーム)を調べ、あらかじめ作られたコンポーネント (さっき話題にしたカスタム・タグ) を組み込んでおき、Web ページのプログラミングの手助けをしてくれます(MyFaces も数百の追加コンポーネントを組み込んで機能を拡張します)。例えば、リスト 1 の JSF フォームを見てください。
リスト 1. JSF
<%@ taglib uri="http://java.sun.com/jsf/html" prefix="h" %>
<%@ taglib uri="http://java.sun.com/jsf/core" prefix="f" %>
<html>
<head>
<title>JSF Sample Page</title>
</head>
<body>
<f:view>
<h1>
<h:outputText value="Login"/>
</h1>
<h:form id="loginForm">
<h:outputText value="Username: "/>
<h:inputText value="#{userBean.username}" />
<br />
<h:outputText value="Password: "/>
<h:inputText value="#{userBean.password}" />
<h:commandButton action="login" value="Log In" />
<h:commandButton action="register" value="Register a new account" />
</h:form>
</f:view>
</body>
</html>
|
純粋な HTML と 2 つのタグ・ライブラリーからのタグが混在している点に注目してください。それぞれのタグは、接頭辞にエイリアスされた URI(名前空間を表す) として指定されています。これらのタグには特定の振る舞いがあり、上記の例では特定 HTML を出力します。一方、inputText 要素にはちょっとした違いがあります。この要素は特定の Java Bean を参照しているため、リスト 2 に示すようなクラスがあるはずです。
リスト 2. Java Bean
package com.backstop.renegade;
public class UserBean {
String username;
String password;
public String getUsername() {
return this.username;
}
public void setUsername(String username) {
this.username = username;
}
public String getPassword() {
return this.Password;
}
public void setPassword(String password) {
this.password = password;
}
...
}
|
上記の Bean は、作成しているフォームのデータ構造を表します。これをつなぎ合わせるには、faces-config.xml ファイルを使用します(リスト 3 を参照)。
リスト 3. faces-config.xml ファイルのオープン・ソース・コード
<?xml version="1.0"?>
<!DOCTYPE faces-config PUBLIC
"-//Sun Microsystems, Inc.//DTD JavaServer Faces Config 1.1//EN"
"http://java.sun.com/dtd/web-facesconfig_1_1.dtd">
<faces-config>
<managed-bean>
<managed-bean-name>userBean</managed-bean-name>
<managed-bean-class>com.backstop.renegade.UserBean</managed-bean-class>
<managed-bean-scope>request</managed-bean-scope>
</managed-bean>
</faces-config>
|
セットアップ方法については「参考文献」のリンクにアクセスして詳細を調べてもらうことにして、ここではとりあえず、フォームで使用しているオブジェクト名 (userBean) をクラス (com.backstop.renegade.UserBean) にリンクし、参照範囲を単一の Web リクエストに指定していることに着目してください。
JSF には、ひそかにもう 1 つの芸当があります。フォームの送信がまだ必要ですが、どこに送信すればいいかわかりますか? 従来の HTML ページでは、ボタンごとにさまざまなアクションを設定するのはどんなに控えめに言っても面倒な作業ですが、JSFでは faces-config.xml ファイルに含まれるナビゲーション・ルールを使って、この問題を処理できます (リスト 4 を参照)。
リスト 4. faces-config.xml にナビゲーション・ルールを追加するためのオープン・ソース・コード
<?xml version="1.0"?>
<!DOCTYPE faces-config PUBLIC
"-//Sun Microsystems, Inc.//DTD JavaServer Faces Config 1.1//EN"
"http://java.sun.com/dtd/web-facesconfig_1_1.dtd">
<faces-config>
<navigation-rule>
<from-view-id>/pages/login.jsp</from-view-id>
<navigation-case>
<from-outcome>login</from-outcome>
<to-view-id>/pages/processlogin.jsp</to-view-id>
</navigation-case>
<navigation-case>
<from-outcome>register</from-outcome>
<to-view-id>/pages/registration.jsp</to-view-id>
</navigation-case>
</navigation-rule>
<managed-bean>
<managed-bean-name>personBean</managed-bean-name>
<managed-bean-class>jsfks.PersonBean</managed-bean-class>
<managed-bean-scope>request</managed-bean-scope>
</managed-bean>
</faces-config>
|
このように from-outcome で、ボタンに指定したアクションに応じたログイン・ページからのサーバーの移動先を指定することができます。移動をトリガーする方法はもちろん他にもありますが、この記事では触れません。
肝心な点は、JSF が Web 開発を大幅に簡易化するということです。それが、Tim McConnell の「ToDo リスト」に JSF が載った理由です。
Java EE (以前の J2EE 1.5) への移行
Tim いわく、「J2EE 1.4 要件には JSF 仕様はなかったので、これは新しいことです。これはオープン・ソースであるため具体的な計画ではありませんが、来年にはApache Geronimo が [Java EE] 5 準拠になって JSF 1.2 仕様を組み込むことになると見込んでいます。私たちはその実現に向けて、J2EE1.4 を完成させたときよりずっと効率的に作業しているところです」。
Geronimo のようなプロジェクトでの内部作業にはいつも興味をそそられるので、今回はどこが違うのか Tim に質問してみました。
彼の考えは、「今回は IBM の関与が大きいので、準拠に一層迫られています。準拠していなければ使用しないという企業顧客はたくさんいますからね。」というものでした。Timは Java EE 5 には多くの新しい仕様が含まれていると指摘しました。「そのため、やらなければならないことがたくさんあります」。
ここで私は、彼が前に言ったことに興味が沸きました。「モデル・ビュー・コントローラー・パターンの実装とほとんど同じだということですが、どうして「ほとんど」なのですか」。
彼の答えはこうです。「Web 開発であるという点が違います。制約がほとんどないため、この仕様には高度な機能が追加されています。例えば、仕様が指定している内容の1 つで興味深いのは、この仕様にはイベントの概念があることです。これらのイベントはフォームが変更されると起動されます。変更されたのが Web画面上のフォームの要素であっても同じことです。そのため、インプリメンターが該当フィールドへの事実上の変更であるイベントをリッスンするように登録できます。つまり、プログラマーは該当フィールドでのイベントをリッスンするように登録しさえすれば変更が通知されるようになるため、そのフィールドが変更されたかどうかをチェックする必要がなくなります。実際これはかなり巧妙な方法です。私が思うに、イベントを公開するためのかなりの作業をプログラマーが行うのではなく、実装で行うという点で非常に洗練されています。プログラマーはただ変更の対象を登録するだけでいいのです。ここに、開発を簡易化するという意図が表れています」。
Tim は続いて、これが Geronimo での JSF 実装にとってどのような意味があるかを説明してくれました。「この仕様では、サーバーに課せられていることがいくつかあります。その1 つが、API のサポートです。API のサポートは、Web アプリケーションではなくサーバーで行わなければなりません。例えば MyFaces1.1 では、Web アプリケーションを開発するプログラマーは JAR ファイルを組み込むだけで済むので、1.2 ではこれを無効にして、[JavaEE] 5 スタックの JAR ファイルであることを確実にする必要があります。Geronimo が [Java EE] 5 に準拠すれば、Geronimoに JAR ファイルが含まれるようになるため、プログラマーが JAR ファイルを組み込む必要がなくなるという考え方です。プログラマーが提供しなければならないのはアプリケーション自体だけです。私たちは、この仕様に従うためのコード、そして1.2 を使用するアプリケーションを有効にするためのコードを開発しなければなりません。また、この仕様はアプリケーションが JSF を使用しているかどうかを判断する方法を提供するので、その類の作業は要りません」。
仕様の実装
以上の話を聞いて考えさせられました。このような仕様を実際に実装するのはどんな感じなのだろう。つまり、仕様を手に入れてそれが上手く機能すれば万々歳ですが、それまでの過程はどのようなものなのだろうという疑問です。例えて言うなら妻のマヨネーズ作りの日のようで、完成品が魔法のように現れるのではなく、誰かが一つひとつの作業を積み重ねていかなければなりません(卵とレモンジュースを混ぜ合わせて作るわけですが、何を言わんとしているかはおわかりですよね)。
「現在、私が実装しているのは JSR 88 仕様で、これはデプロイメントの仕様です」。Tim は言いました。「JSR 88 は完成度が高く理解しやすいので、それほど厄介ではありません。JSFが理解しにくいというわけではなく、JSR88 の仕様が公開 API の体裁をより詳細に記述しているのです。どんな仕様でもそうですが、他より勝ったところはあるものです」。
もう少し詳しく説明してくれるよう Tim にお願いしました。そして、彼が指摘するパッケージの定義と記述を聞いているうちに、これらの仕様は開発者が毎日扱っている仕様とそれほど違ったものではないことがわかってきました。JSF1.2 を定義する JSR-252 仕様は、関連するパッケージを定義するもので、サポートしなければならない文書の XML スキーマを提供するものです。この仕様の本文には、それぞれのコンポーネントに課せられた役目が定義されています。
つまり、JSR 仕様の実装は他の仕様の実装と同様で、違う点と言えば、その内容が基本的に決定事項として書かれていることです。その理由は、変更にはJava コミュニティ・プロセスが関与するため、単に上司のところに行って交渉するというように簡単には行かないからです。
オープン・ソースと非オープン・ソースでの開発の違い
Tim は Apache Geronimo への取り組みを「夢の仕事」と呼んでいるので、オープン・ソースでの作業のどこがそれほど特別なことなのか聞いてみました。
「オープン・ソース開発を行うということは、コードを実際に開発して貢献するということです。Geronimo や私が知っている他のオープン・ソースでコミッターになるには、Javaや一般的なコーディングの技能レベルを証明して、コードを寄与しなければなりません。ある意味、「コードがものを言う」世界です。私にとって、これにはいい面も悪い面もありますが、オープン・ソースはとにかくそうやって発展してきました」。
Tim は Geronimo だけに取り組んでいるのではなく、IBM プロパーのソフトウェア・エンジニアです。そこで、オープン・ソースは商用の製品開発とどのように違うのかを聞いてみました。「オープン・ソース(開発) では、コードを寄与するとコミュニティーがそれを検討します。そのため誰もがコードを目にして検討し、フィードバックするチャンスがあります。それがオープン・ソースのプロセスです。IBMでの製品開発はそれよりもかなり厳しいルールがあります。開発手順が決められていて、分析、計画、設計、実装、ユニット・テスト、機能テストとシステム・テストという明確に区別された段階を踏まなければなりません」。
彼はさらに続けました。「オープン・ソース (開発) でも作業内容は同じですが、多少その手順は簡潔で、明確な段階というものはありません。Geronimoでは完全にコミュニティーが主導する一方、製品開発での作業は通常、製品のアーキテクチャーによって決まります。オープン・ソースでは、コミュニティーがある作業を行うことに同意します。[JavaEE] 5 準拠がその一例です。オープン・ソースの素晴らしい点は、誰でも希望する仕事に取り組めることです。例えば、あなたは JSF と JSR88 デプロイメント仕様に取り組みたいと思っているとします。そこで、その案を公表し、コミュニティーからフィードバックを受けます。コミュニティーがその案を認めたら、今度は作業計画を提出します。するとコミュニティーがレビューして同意します。あるいは何もしない場合もありますが、それは暗黙的同意のようなものです。自分にその能力があることを示しさえすれば、ほとんどどんな作業内容でも選べてコミッターになれるため、オープン・ソースには自由があります。開発者として当然ユニット・テストは行いますが、レビュー・プロセスはコードのコミット作業の一環となっています。コードをコミットすれば、全員が作業の成果をレビューし、コメントをくれるためです。明確なスケジュールはなく、だいたい2 週間ほどで私たちはこの段階に入ります。一方、IBM 製品開発の場合は特にそうですが、私の経験からすると確固とした手順によって良質のソフトウェアが生まれます。オープン・ソースのソフトウェアも非常に優れていますが、手順が異なるだけの話です」。
ただ、Tim にはもう 1 つ、オープン・ソースと商用製品の開発を差別化する点がありました。「面白さで言ったら、オープン・ソースのほうが断然上です」。
まとめ
Tim は私にさまざまなことを考えさせてくれました。とりわけ、私の武器庫に JSF、具体的には Apache MyFaces という新しい武器が増えたことは収穫です。私は何年もJSP を使っていますが、アプリケーション開発を簡易化するには素晴らしい方法だと思います。ナビゲーション・ルールだけでも開発を簡易化できるため、この記事では触れる余裕がなかった他のすべてのフィーチャーを加えたら、開発の簡易化で大成功を収められるはずです。
Tim はまた、仕様の実装とコミュニティーとの連携プロセスをわかりやすく説明してくれたので、現実のオープン・ソース・プロジェクトへの貢献について深く理解することができました。
参考文献 学ぶために
製品や技術を入手するために
議論するために
著者について  | 
| | Nicholas Chase は、Lucent Technologies や Sun Microsystems、Oracle、the Tampa Bay Buccaneers などの会社で Web 開発に携わってきました。彼は高校の物理の先生であり、低レベル放射性廃棄物施設の管理者であり、オンライン SF 雑誌の編集者であり、マルチメディアのエンジニアであり、Oracle インストラクターであり、あるインタラクティブ・コミュニケーション会社の最高技術責任者でもあります。『XML Primer Plus』(Sams 刊) を含めて、何冊かの著作があります。 |
記事の評価
| 
