-Mayaの前提

mayaa

突っ込みよろしく〜。

■ Strutsの普及
Strutsは(この世界に限れば)説明のいらない、人気のJava製WEB開発フレームワークです。リクエストをコントロールサーブレットで受けることや、WEB開発でMVCモデルを実現することのメリットなどのStrutsがうたっているアーキテクチャは、大量に出版されているStruts入門本に説明されているのでとかく触れませんが、是非はともかく、Strutsは世界的に受け入れられています。
StrutsがWEBアプリケーション開発において、主に担当するのはビュー層とドメイン層のつなぎの部分および、ビューのフローコントロールです。特にStrutsはビューのフローコントロールに力が入っています。メカニズムとしては、まずコントロールサーブレットでリクエストを受け付け、設定XMLの記述とリクエストのURIよりフローコントロールを行うアクションを選択し実行します。アクションはビジネスロジックの実行を行い、その最後に表示ページを決定します。ページを表示する前にビジネスロジックの実行を挟み込むことで、フローコントロールの余地をつくってるわけですね。その基本概念の延長で、リクエストプロセス中にユーザー入力値の検証を行う機能を開発するためのフレームワークを用意していたり、自動でユーザー入力値をドメインモデルにインジェクトする機能を提供したりしています。
ビューのフローコントロールおよびビュー層とドメイン層のつなぎは、経験あるサーバーサイドJava技術者であれば多くの方が実装の度に開発してきた要件です。Strutsの偉大なところは、逆説的には、「誰もが書かなければならない」＝「キラー技術不在」の領域に、ひとつの実装を打ち立てたことになるでしょう。その証左か、Struts派生のコーポレートオリジナルフレームワークは巷間にあまたあります。それだけStrutsが企業を中心に現在のWEBアプリケーション開発の現場に浸透しているのは間違いありません。Strutsベースのフレームワークだけならず、アプリケーションやライブラリ、実稼動システムもたくさんあります。

■　JSFの登場
最近は、ポストStrutsという風評でJSFも無視できない（この世界に限れば）存在になってきました。大づかみには両者ともWEBアプリケーションにおいて同じような役割を分担してます（もしくは分担「できます」）。しかし、StrutsとJSFも実はその立ち位置は微妙に違い、JSFのほうをStrutsよりもフロント寄りに入れて、両者併用するソリューションも考えられます。JSFの策定にStruts作者のCraig McClanahanが参画しているのですが、彼は次世代Struts=JSFとは定義しませんでした。彼はJSFをベターStrutsではなく、別のアプローチを行うWEBアプリケーション開発フレームワークと位置づけているようです。JSFはStrutsの特徴であるビューのフローコントロールには力をいれず、ビュー層とドメイン層のつなぎの部分に力の入ったフレームワーク仕様です。そのリクエストプロセス中の動作にはSwingなどによるクライアントGUIアプリケーションに考えの近いイベントモデルがあり、実際の開発アプリケーションが開発者にとって直感的な構造になるように設計されています。JSFの一番すばらしいところは、新技術としての傲慢なところが無く、他の様々な技術との融和性が高いところかもしれません。JSFはこれからやっと普及期にはいるところですが、JCP（Java　Community　Process）による公開された仕様策定経過の中、標準化されました。そのためか、先に言及したStrutsとの併用の可能性のみならず、様々な既存技術との組み合わせの余地があるような仕様になっています。おそらく、JSFはStrutsのようにそれ単体で普及していくのではなく、他のキラー技術と組み合わせられ、個性豊かな形で提供され、浸透していくことになるように思います。
JSFはこれからの技術ということもあって、その正体はよく誤解されているように思われます。おそらくその犯人はJSFタグの存在でしょう。JSFは標準のビュー構築方法としてJSPを採用し、そのJSPカスタムタグのフレームワーク上でGUI部品を構築しています。技術書等でもJSFの紹介ではまずこれらタグライブラリの使い方から入ってくるので、JSFはベターJSPなのかと誤解されがちです。技術書でビューの作成に続いて説明される、JSFコンポーネントツリーの解説のあたりで多くの方が難しく感じ敬遠していることが多いのではないでしょうか？しかし、そのJSFコンポーネントツリーはJSFの実装が管理するところであって、ユーザーコードで直接にアクセスする部分ではありません。JSFはビューの表層とビジネスロジックを記述するドメイン層のみユーザーに負担させ、JSFはその間のつなぎをやってるのです。ビューとドメインモデルとの接続は簡便なEL式でスクリプトライクに行い、ドメインモデルはManagedBeanとしてfaces-config.xmlに定義記述します。実はJSFの守備範囲は結構狭いのですね。でも、WEBアプリケーション開発の全部をカバーするかのように誤解してしまうような説明が大概の場合されているように思います。

■　StrutsとJSFの標準ビューであるJSP
StrutsおよびJSFの機能本質はビュー構築ではないところにあると説明しましたが、そのビューは、両者ともJ２EE標準のビューエンジンに委譲しています。それはJSPです。ビューのフローコントロールやビュー層とドメインモデル層とのつなぎの部分を担当する一方、ビューそのものの構築はすべてJSPが行っています。StrutsやJSFはJSPカスタムタグによって、JSPプロセッサに委譲したビューへのエントリーを確保しています。StrutsタグおよびJSFタグがそれぞれビュー層のポイントカットとなっているのです。
StrutsもJSFも、GUI部品はJSPカスタムタグで構築されたもの以外には標準で提供していません（厳密に言うと、JSFは薄いJSPカスタムタグがファクトリー的に構築するJSFコンポーネントツリーの要素モデルと分離したレンダラー群がありますが、わき道にそれるので、ここでは議論を保留しておきます）。Strutsは結果的に、またJSFのほうは積極的に、JSPに限らない様々なフロントエンドを採用できるつくりになってはいますが、フレームワーク標準でついてくるビュー技術はJSPとなります。そこでやっとJSPの議論になります。StrutsもJSFもたしかにうれしい（人気がある）が、そのビューを担うJSPはどうか？と。

■ JSPアンチテーゼ
JSPはサーバーサイドJavaの基本技術の一つですが、あまり好かれていないようです。しかしWEBアプリケーションをサーブレットの基本技術の範囲内で開発するのも苦労が多いので、ベタなサーブレットによる開発のアンチテーゼとしてJSPが利用されているのではないでしょうか。すなわち、Javaのソースコード中にWEBデザイン（HTML）を書くか、WEBデザイン中（HTML）にJavaのソースコードを書くかの選択です。JSPは実行時にプリプロセス-コードジェネレート-コンパイルというワークフローを経て、ダイナミックに生成されるサーブレットがサービスします。そのため、配置時にはコンパイル済みである必要があるベタなサーブレットで構築されたアプリケーションでデザインの修正を行うよりも、JSPで構築されたアプリケーションにデザインの修正を行うほうが手間が少ないのでしょう。
JSPはその仕様が進化するにしたがって、よりJavaソースコードをページ内に記述しないでよいようになりました。JSPカスタムタグや、JSP2.0のTAGファイル、フラグメントなどの存在です。しかし、JSPは純粋なHTMLとは異なり、HTML中にXMLとJSPコードが混在する不条理な状態が強いられ、プログラマーとWEBデザイナーが平行で作業が行いにくい仕組みのまま、その問題をなかなか改善できずにいます。
この問題の解決に求められるパラダイムは、次に紹介するTapestryが解決してくれています。

■ Tapestryアンチテーゼ
TapestryはApache Jakartaプロジェクトから提供されている、Servletベースの開発フレームワークです。Tapestryはこっそりとものすごいパラダイムシフトを起こしました（TapestryというよりはWebObjectsなり、他の先達なのかもしれませんが）。ごく普通のHTMLをビューとして、設定XMLおよびJavaで記述するモデルクラスでWEBページをMVCモデルより開発します。デザイナーとプログラマーがそれぞれデザインフルなビューとそれ以外を分担し、かつ並行開発することを可能とするフレームワークです。実際にデザインが豪華なユーザー案件に投入し、その開発生産性でそうとうの手ごたえが感じられます。デザイナーが作るHTMLをテンプレート化するに際し、プログラマー記述のロジックはほとんど何もないのに近いところまで追求することがができます。これは途方もない開発生産性を向上させるパラダイムだと思われます。Tapestryの凄いところはHTMLのテンプレート技術に加え、HTMLテンプレートのコンポーネント化技術にもあります。HTMLテンプレートを再利用する技術はJSPのincludeの機能にも似てないことはないですが、より先進的かつ直感的です。WEBデザイナーが作成した豪華なビュー断片がそのまま配布や再利用がしやすいコンポーネントになるのです。
しかし、TapestryがStrutsやJSFほど世に受け入れられていないのは、ちょうどJSFやStrutsなどの人気のフレームワークが実現するところをTapestryも機能提供していてるところにあります。ビュー層とドメインモデル層とのつなぎの部分もTapestryは独自に用意していて他のフレームワークと併用を前提としておりません。しかもStrutsやJSFに比して難しいようです。使いこなすにはいくらかの内部知識が必要なのです（ここではこのドキュメントの本質ではないので、Tapestryのモデル層の難解さの論及は置いておきますが、他のフレームワークと併用できないということを繰り返し指摘しておきます）。使いこなせればTapestry作者であるHoward　Ship氏が設計思想の前提とされた、ビジュアルデザイン的に美しく、かつ完全にステートレスな大規模サーバー構築ができます。しかし、理解が中途では実装上の誤解からステートレス性がすぐに失われ、挙動にも開発者も腑におちない違和感が残りがちです。また、凄みあるHTMLテンプレートのコンポーネント化技術も独自な仕様のため、その再利用はTapestryの枠内にとどまり、サードパーティ等のコンポーネント提供は現在のところ、期待できません。
TapestryがJSFやStrutsに対応して、JSFコンポーネントツリーやStrutsアクションのフロント側だけのみを守備範囲にしたらいいのになと思うことがありました。そしてHTMLテンプレートのコンポーネント化技術のパラダイムはそのままに、より再利用性高く、たとえばJSPで開発した過去の資産の修正案件にも利用できる技術に変貌できたら拾いきれていない技術的なニーズが満たせるのではないかと思いついたのです。これがビューテンプレートエンジン「Maya」のスタートポイントでした。

■　JSPタグライブラリの再評価とMayaの機能
JSPタグライブラリは、JavaオブジェクトとTLDをJarアーカイブして配布されています。TLDにはカスタムタグの名前と実装クラスを結びつける定義と、ユーザーアプリケーションから利用するにあたっての設定パラメータの情報の定義が記述されていますが、実はJSPファイルにしか記述できないということではありません。このような使い方が過去にされてきたかは不明ですが、Javaソースコードから直接カスタムタグの実装クラスを生成して、適切なAPIを適切な順で呼び出してやることによって、JSPタグライブラリはその実装に従った動的生成結果を出力します。それはたいていの場合、HTMLもしくはXHTMLなどの断片であり、うまく組み合わせることによって、WEBアプリケーションのフロントエンドを生成することが可能です。Mayaは既存のJSPタグライブラリ、特にStrutsのそれとJSFのそれ、およびJSTLを再利用の基本ターゲットとして、軽量に製品ビジョンを実現します。
JSPタグライブラリ（含むJSFタグライブラリ＆JSTL）は膨大にありますしすでに世に出て長いものもあり、品質の高いものになってます。これらをすべてPlane Old HTML Page(以下POHP)中で使えるようにすることがMayaの担当する領域です。そして、POHPと付随的な設定XMLのどちらにもビュー層とビジネスモデル層をつなぐ、バインディング情報が書けるという機能を大前提にしました。デザイナーとプログラマーの分業の追及から、POHPに必要最小限の情報だけを残し、他は外部化すれば、WEBデザイナーにプログラミング知識がなくとも、黙ってうまいことやります。もしスパイラルな開発の過程の中で、プログラマーの記述した部分がWEBデザイナーに間違って削られてしまっても、その記述量が少なければ、ダメージも少ないはずです。

■ Maya
新しく提供する、このビューテンプレートエンジンの名前は「Maya」としました。由来は以下のとおりです。

  • 「Maya」は沖縄の言葉で「猫」ということから
  • JSPの立ち位置をその専門領域とするので、サーブレット/JSPコンテナで偉大なる「Tomcat」にあやかって
  • 内部の重要箇所に「NekoHTML」（Xerces開発のAndy　Clark氏の手による）というパーサーを用いるから

そして、何よりも、

  • そろそろ2歳になる、私の最愛の娘の名前が「Maya」だから

■ Struts/JSF/Tapestryのまとめ
まとめると、要はTapestryが良くできてるのです。しかし、Tapestryが守備範囲をひろげて難解なビューモデル層を強制するのだけがいただけない。JSPはWEBデザイナーとJavaプログラマーの平行作業を妨げます。また、Tapestryの弱点はコンポーネントモデルが独自なことです。プレビュー可能なHTMLがそのままコンポーネントになるというすばらしい技術ですが、独自仕様なためにTapestryユーザーしかコンポーネントを作りません。
そこでMayaはTapestryの表層部分のGOODアーキテクチャだけを取り出し、コンポーネントモデルはこの世界ではこれ以上の数の実装が無いだろうと思われるJSPタグライブラリを採用します。Mayaはあとのビュー層とドメイン層とのつなぎやビューフローのコントロールなどはまったくやりません。そこはStrutsやJSFに担当させるべき領域とします。
Maya＆Strutsの場合、ドメイン層とのつなぎはHTMLテンプレート中にインジェクトされたStrutsタグを通し、Strutsがやります。Maya＆JSFの場合、ドメイン層とのつなぎはHTMLテンプレート中にインジェクトされたJSFタグを通し、JSFコンポーネントツリーが構築され、JSFがつなぎます。