過去5年間に出現したWebフレームワークすべての中で、Jakarta Struts はJava™開発者に最も人気があるものの一つです。ですから、その後継の登場は、注目すべき出来事と言えます。Shaleは、まだあまり人気のあるフレームワークとは言えず、それほど知られてもいませんが、その系図を見ると素晴らしさが分かります。それ以上に興奮すべきことは、Shaleが単なるStrutsの重要アップグレードや新バージョンのリリースではなく、Strutsの中核部分の多くが、Web開発における新しい考え方を採り入れた上で完全に作り直されている、という事実です。

そして、この5回のシリーズで学ぶように、Strutsから分かれたという事実は両刃の剣です。Shaleは一面で、Strutsの後継として非常によく考えられています。Shaleを開発した人達は、Strutsの強みと弱みの両方を考慮に入れながら、後継としてふさわしい、次世代のフレームワークを考え出しました。その一方、このシリーズですぐに明らかになるように、ShaleはStrutsとは全く異なるフレームワークであり、まったく新しい開発が行われているのです。

Shaleは単にStrutsを手直ししたものではなく、Strutsを大幅に上回るものです。ShaleはJSTL（JSP Standard Tag Library）やJSF（JavaServer Faces）など、Java Webプログラミングにおける最近の最も重要な開発成果を網羅し、そしてその上に構築されています。Shaleは、Strutsとはまったく異なるフレームワークとして考えるべきであり、このシリーズでは、そうした視点で見て行きます。今回は、ShaleとStrutsの違いの概要と、Shaleのインストール方法、インストールのテスト方法などについて解説します。そして最後に、オープンソースであるShaleプロジェクトに参加するためのヒントと、そのための実際についても触れることにします。このシリーズでは全体を通して、Strutsフレームワークには可能な限り触れずに、Shaleのインストールやビルド、開発などの方法を説明することにします。

Shaleを評価する

新しいWeb開発フレームワークは、今やぎっしりと詰まった空間の中に入り込める必要があり、しかも厳しい評価に耐えられる必要があります。幸いShaleは、実際にプロジェクトの中で厳しい評価が行われており、それに充分耐えています。その一方、困ったこととして（多分、困ったことだと思いますが）、ShaleはStrutsを完全に作り直しています。そのためShaleを実装するためには、Strutsのコードをすべて作り直し、テストし直し、書き直さなければなりません。新しいShaleアプリケーションを書くための作業量は、あるいはStrutsアプリケーションをShale用に変換するのための作業量は、まるでShaleとStrutsがまったく無関係に思えるほど大量なものとなります。

そうすると当然の疑問として、なぜShaleを採用すべきなのか、という疑問が湧いてきます。その答えとして、最初に、なぜShaleが素晴らしいのかを説明しましょう。Strutsの遺産を中心に説明しますが、それに限定はしません。次に、なぜStrutsフレームワークの主要改訂としてリリース『されていない』のか、2つの理由を挙げます。これらによって、Shaleから実際に何が得られるかを明確に理解できるでしょう。またこの記事は、この次世代フレームワークが飛び込むだけの価値があるかを判断する上でも役に立つはずです。

Strutsの遺産

ShaleはStrutsコードベースの多くを使用しており、Strutsを、自分の「親」フレームワークと呼んでいます。ですからShaleの価値を信ずるためには、まずStrutsの価値に納得していなければなりません。何よりもまず、Strutsは最初の真のWeb開発フレームワークとして、大きな価値を持っています。ShaleとStrutsのWebサイトによれば、最初のコードがStruts CVSリポジトリーにコミットされたのは2000年の6月だとされています。多くの開発者が、JSP（JavaServer Pages）や発展中のサーブレット仕様と格闘していた頃、StrutsはサーブレットやJSPベースのWebアプリケーション構築用に、使いやすいModel 2手法を提供していたのです。言い方を変えると、Web開発者はロギングや分散コンピューティング、JDBC、サーブレット、JSP、JNDI、RMI、その他様々なAPIや略語に習熟しなくても、Strutsによって堅牢なWebアプリケーションを構築できたのです。

Strutsのもう一つの価値は、その地位が安定していることです。最初のコード行が書かれてから約6年間、Strutsは最も一般的なWeb開発フレームワークの1つとして、地位を保ってきました。今でもStrutsに関して活発な議論が行われ、記事が書かれ、そして通常、Strutsは新しい競争相手と同じくらい頻繁に使われています。その人気と、長く使われていることから、Strutsは完全機能となり、よくドキュメント化され、よくサポートされ、使いやすくなり、多くの開発や管理の土台となっています。何千人もの開発者がStrutsメーリング・リスト上の問い合わせに反応し、そして何万人もの開発者がStrutsを実際に試して問題を報告しているため、問題は容易に解決できるようになっています。

最後に、Strutsは進化してきました。多くのフレームワークが、強力なものとして始まりながら足踏みしてしまう場合がほとんど（これは商用製品でもオープンソースの製品でも同じです）であるのに対して、Strutsは新しい機能を提供し続けてきました。Strutsをダウンロードすると、コア・ディストリビューションの一部として堅牢な検証エンジンが付いてきます。さらにJavaServer Facesとの容易な統合も可能であり、充実したタグ・ライブラリーや、分散n階層アプリケーション領域に対する新しい考え方を反映した、進化するModel 2アーキテクチャーなども入手することができます。そして念のために言うと、StrutsはIoC（Inversion of Control）など、新しい仕組みのプログラミングも採り入れています。またStrutsは、WebWorkやSpringフレームワークとも自然な形で統合することができます（どちらも、Web開発の新しい手法を手軽に利用するための最高のフレームワークです）。

つまりStrutsでは『できない』、あるいはサポート『していない』ものを見つける方が難しいのです。ですから当然の疑問として、ではなぜShaleはすべてを最初から作り直しているのか、という疑問が浮かんできます。なぜShaleは、単にStrutsの次期バージョンではないのでしょう。これには主に2つの理由があります。1つは、ソフトウェア・リリースに関して忘れられがちな重要な事実に関係しており、もう1つは、Strutsの基礎の持つ、よく知られた弱みと関係しています。では、この両方について調べてみましょう。

レビュー、改訂、再検討、再リリース

なぜShaleが単なるStrutsの新リリースではないかを理解するためには、まず新しいソフトウェアのリリースについて、幾つか理解する必要があります。大部分のユーザーは、新しいソフトウェア・リリースというものを、新しい機能の追加としてとらえます。前回のリリースからのバージョン変化が大きければ大きいほど、より多くの機能が追加されている、とユーザーは期待します。つまり、ソフトウェアが2.1から2.2になった場合の新機能の追加よりも、2.2から3.0になった場合の方が、ずっと多くの機能を持っているはずなのです。Microsoft Wordのような巨大な製品や、Windows、Mac OS XといったOSの新リリースが厳しくチェックされるのは、このためです。ユーザーは新しいリリース毎に、機能の数が増加することを要求するのです。

このように機能が注目されるため、ほとんどのユーザーは、最も重要なことが実は後位互換性であることに気が付きません。誰もがExcelに新しいオプションを望み、Pantherで iTunesとの統合が容易になり、GnomeでのXULサポートが改善されることを望みますが、もし突然、既存のプログラムやファイルが新しいバージョンで使えなくなったとしたら、彼らは烈火のごとく怒るでしょう。そんなことが起きたら、新しい機能はまったく価値がなくなります。

Strutsでもまったく同じことが言えます。ほとんどの場合、Strutsではバージョンが新しくなる毎に新しい機能が追加される一方、それまでのバージョンとの後位互換性は保たれていました。さらに、古いインストールは古いプラットフォーム上で実行するため、古いバージョンのJavaプラットフォームやサーブレット仕様をサポートすることが要求されていました。こうした要求、つまり後位互換性を保ち、古いバージョンのJava APIをサポートしようとしたのであれば、Shaleにとって深刻な制約となったはずです。特に、進化しつつあるWebにおいて（少なくともJavaプラットフォームに関しては）JSF APIが中心的なものとなりました。StrutsはJSFをサポートしていますが、Shaleは完全にJSFに依存しています。これを、後位互換性を維持しながら実現することは、とてもStrutsにできることではありません。

最後に、Strutsのような既存プロジェクトの開発を活発に継続する一方でShaleのような新しいプロジェクトを始めることには、大きな利点があります。もし、Strutsが単純に新しい2.0（あるいは3.0や4.0）に移行し、後位互換性を考えずにShaleの持つ機能を実装したとしたら、その移行は多くの人にとって痛みを伴うものとなり、また一部の人達は、単純にStrutsを使うこと自体を止めてしまうでしょう。たとえ古いコードベースが維持されたとしても、「使用しないように勧められている」あるいは「古い」バージョンのソフトウェアに対するバグ修正や、わずかな機能でも新規の追加作業に時間をかけることは、開発者にとって大きな負担となるでしょう。

こうした様々な理由から、Shaleがまったく新しいプロジェクトとなり、新しいコードベースの上に構築されていることは、意味のあることなのです。

Shaleのサービス指向アーキテクチャー

Shaleが単なるStrutsの新リリースではない理由の最後は、実際的な手間とは関係がありません。Shaleのフレームワークでは、Web開発に対する新しい手法を利用できるのです。Shaleは多くの重要な点でStrutsと異なっていますが、特に次の2点が大きく違っています。

• StrutsはJSFと統合しますが、ShaleはJSFの上に構築されています。
• Strutsは本質的に巨大で複雑なリクエスト・プロセッサーですが、Shaleは自由に組み合わせ可能な一連のサービスです。

ShaleがJSFに依存していることの意味合いは重要です。皆さんは驚かれるかも知れませんが、これは実は肯定的なことなのです。この点については今後の記事で詳細に説明する予定ですが、2点目の方は、先に進む前に少し詳しく説明すべきでしょう。

Strutsを何度も使ったことのある人であれば、Strutsがほとんどリクエスト・プロセッサーであること、そのためリクエストを受信でき、そうした各リクエストの処理方法をStrutsフレームワークに指示できることを理解しているでしょう。Strutsでは、あらゆるものをコンフィギュレーションできます。つまり、どのアクションを起こすのか、どのモデルを使うのか、どのビューをユーザーに表示するのか、どんな検証ルールを採用するのか、どんなフォームを表示するのか、すべてを指示できるのです。しかし、これらすべての中核ではリクエスト・プロセッサーが実行しており、各リクエストを処理しています。このプロセッサーは実質的にリクエスト処理のあらゆる部分を処理し、あるいは権限委譲処理を行う必要があるため、Strutsの中で最も重要であり、そして最も複雑なものです。リクエスト・プロセッサーが触らない、あるいはリクエスト・プロセッサーに影響を受けないコードベースは、Strutsの中にはほとんどありません。

その結果、どういう方法であれ、Strutsを根本から変えることは難しくなっています。リクエストの処理方法や、リクエストの一部の処理順序を動的に変更したい場合には、途方もない大仕事になります。つまり実質的に、Strutsのコードベースを書き換えなければなりません。リクエスト・プロセッサーの振る舞いを変更することは、多少は可能ですが、リクエスト・プロセッサーはほとんど閉じたシステムなのです。そしてこれは、（少なくともそうした柔軟性レベルをWebフレームワークに要求する場合には）Shaleが解決しようとしている問題の1つなのです。

Strutsのリクエスト・プロセッサーのような中心コンポーネントを持つ代わりに、Shaleは単純に、サービスを大量に集めたものとなっています。こうしたサービスは、ほとんど任意に組み合わせができ、しかも各サービスは互いに疎結合なのです。よく定義された一連のインターフェース（実際のJavaインターフェース・クラスの場合もあれば、単純にコンポーネント同士が特定な方法で動作することを規定した契約である場合もあります）を使うことによって、Shaleの振る舞いを容易にコンフィギュレーションし直すことができます。そのためShaleは拡張可能であり、柔軟であり、そして俊敏です。またShaleは容易に変更でき、苦労なく拡張でき、新しいプログラミング手法に素早く適応することができます。このように、コンポーネントやサービスが緩く組み合わされているアーキテクチャーは、よくサービス指向アーキテクチャー、あるいはSOA（service-oriented architecture）と呼ばれます。確かにSOAはちょっとした流行語ですが、それがShaleと敵対するものと考えるべきではありません。

上に戻る

Shaleをインストールする

実際的な面と概念的な面から見たShaleとStrutsとの違いは理解できたと思いますが、この2つの偉大なフレームワークの違いを本当に理解するためには、実際に手を動かして触ってみる必要があります。どのWebフレームワークも、（あまり興奮するような作業ではありませんが）まずはダウンロードとインストールから始まります。幸い、このプロセスから学べることが幾つもあるのです。インストールや設定が難しいプロジェクトや製品は、多くの場合、コンフィギュレーションもデプロイも難しく、そして（何よりも）順調に実行することも難しいものです。インストール・プロセスのみでWebフレームワークの評価を決定すべきではありませんが、評価基準の一部にはなりうるものです。このセクションでは、Shaleを手動でインストールする方法を学びながら、まだ不な点を実感し、システム上でShaleを実行させるために具体的に何が必要かを学びます。

注意： この記事では、Shaleを少し 楽にインストールする方法 についても説明しますが、Shaleが提供する情報の奥深さを理解するために、少なくとも手動インストールを学ぶことだけはするように、強くお勧めします。

前提条件

Shaleが要求する前提条件や要求事項のリストは、非常に多岐に渡っています。他のApacheやJakarta関連のプロジェクトと同様、Shaleのインストールは、他の幾つかのJakartaプロジェクトに依存しています。Shaleを実行するために必要なものの完全なリストを下記に示します。

• JRE（Java Runtime Environment）とJDK（Java Development Kit）1.4以上
• Java Servlet API 2.4以上
• JSP 2.0以上
• JSF 1.1以上
• JSTL（JSP Standard Tag Library）1.1以上
• Jakarta Commons BeanUtils 1.7以上
• Jakarta Commons Chain 1.0以上
• Jakarta Commons Digester 1.7以上
• Apache Logging 1.0.4以上
• Apache Ant 1.6.3以上

Apache AntはShaleをビルドするためだけに使われていますが、Java開発を大量に行う場合には、いずれにせよ、あるバージョンのAntがシステム上に必要です（既に持っている人も多いでしょう）。またShaleでバグ追跡をしたい場合には、FindBugs 0.8.5以上、あるいはJUnit 3.8.1以上が必要です。この第1回ではShaleのインストールと使い方を中心に説明しているので、とにかく早いうちからFindBugsやJUnitを追加しておきたいのでない限り、今はこれらを気にする必要はありません。

アドオンと、その依存関係

Strutsの場合と同様、独自の依存関係を持つ、幾つかのアドオン（Shaleの世界では多くの場合、オプションShaleコンポーネントと呼ばれます）があります。これを次に示します。

• Jakarta Commons Validator 1.2以上
• The Spring Framework 1.2.2以上
• Strutsのタイル・フレームワーク（スタンドアローン版）

このリストは少しばかり長すぎ、気が遠くなりそうに思うかもしれませんが、正にそうなのです。Shaleは、下位レベルのライブラリーやヘルパー・クラス、ユーティリティー・コンポーネント、他のプロジェクトからのクラスなどを大量に使用するのです。これらのコンポーネントを1つ1つダウンロードし、Shaleで動作するようにコンフィギュレーションし、すべてを組み合わせてデプロイする必要があるとしたら、本当にShaleに入れ込んだ開発者しかShaleに注目しないでしょう。さらに、Shaleはまだ開発サイクルの非常に初期段階にあるため、こうした依存関係を入手し、コンフィギュレーションするための作業は、「生煮え」の状態です。しかし、何とかなるレベルであり、想像するほど大量の追加作業が必要なわけではありません。

まず、何らかのWeb開発を行おうとするのであれば、（使用するフレームワークによらず）皆さんはこうした依存関係の幾つかを既に持っているはずです。ですからこのリストは、最初の見た目ほどには大層なものではありません。例えば、Web開発者であれば、既にJREやJDK、それにサーブレット・エンジン（Jakarta Tomcatなど）を持っているはずです。また、サーブレット・エンジンを持っていれば、サーブレットAPIやJSPエンジンも持っているはずです。その上、（少なくとも最新のバージョンでは）大部分のサーブレット・エンジンにはJSTLのコピーが含まれており、今やJSFが含まれているものも多くなっています。そして最後に、ほとんどの開発者のマシンには、既にAntがインストールされているはずです。ですから上のリストは、すぐに下記のように小さくなるはずです。

• JSF 1.1以上（場合によると、サーブレット・エンジンに含まれているかも知れません）
• JSTL 1.1以上（場合によると、サーブレット・エンジンに含まれているかも知れません）
• Jakarta Commons BeanUtils 1.7以上
• Jakarta Commons Chain 1.0以上
• Jakarta Commons Digester 1.7以上
• Apache Logging 1.0.4以上

実際、Tapestryでは依存関係をすべて追加ダウンロードとして入手することを考えると、「依存関係が多すぎる」という問題は、実は大した問題ではありません。

これで全体像は分かったので、Shaleとその依存関係をダウンロードし、インストールし、コンフィギュレーションするための手順を説明しましょう。

1. Shaleをダウンロードする

Shaleをダウンロードするには、Shaleプロジェクトのホームページに行きます。「Shale Download」セクションを見ると、Shaleフレームワークの夜間ビルド（nightly build）へのリンクがあります。このリンクをクリックすると、図1のようなサイトに行きます。

Shaleを動くようにするためには、「framework」ファイルと「dependencies（依存関係）」ファイルの両方をダウンロードする必要があります。例えば、この記事の執筆時点で、私は次の2つのファイルをダウンロードしました。

• shale-framework-20060204.zip
• shale-dependencies-20060204.zip

当然ですが、.tar.gzバージョンが必要な場合、あるいは好きな場合には、.zipバージョンではなく.tar.gzバージョンを選択します。Shaleでは作業が継続されており、リリースされたビルドは無いため、最新の夜間ビルド（日付が最新のもの）をダウンロードするようにします。

これら2つのファイルをダウンロードしたら、両方のアーカイブを解凍します。コア・フレームワークに関しては、shale-framework-20060204/というような名前のフォルダーができ、依存関係のアーカイブに関しては、lib/という名前のフォルダーができます。コア・フレームワークのディレクトリー（shale-framework-20060204/）を、Javaプロジェクトを置きたいディレクトリーに移動します。例えば私のシステムでは、shale-framework-20060204/を、/usr/local/javaディレクトリーに移動しました。

次に、lib/ディレクトリーをShaleディレクトリーに移動します。ですから、shale-framework-20060204/lib/のようになります。

2. ShaleライブラリーをWebアプリケーションに追加する

次に、すべてのShale JARファイルとライブラリーを、Webアプリケーションからアクセスでき、利用できる場所に追加します。そのための手順を下記に示します。

1. サーブレット・エンジンにJSFインストールが無い場合には、shale-framework-20060204/lib/jsf-ri/jsf-api.jarとshale-framework-20060204/lib/jsf-ri/jsf-impl.jarを、アプリケーションのWEB-INF/libディレクトリーにコピーします。
2. shale-framework-20060204/dist/ディレクトリーのshale-core.jarとshale-clay.jar、shale-tiles.jar、tiles-core.jarを、WebアプリケーションのWEB-INF/libディレクトリーにコピーします。
3. 次のShale依存関係を、WebアプリケーションのWEB-INF/libディレクトリーにコピーします。
   • shale-framework-20060204/lib/commons-beanutils/commons-beanutils.jar
   • shale-framework-20060204/lib/commons-chain/commons-chain.jar
   • shale-framework-20060204/lib/commons-digester/commons-digester.jar
   • shale-framework-20060204/lib/commons-logging/commons-logging.jar
   • shale-framework-20060204/lib/commons-validator/commons-validator.jar
4. ShaleのSpring統合機能を使いたい場合には、shale-framework-20060204/dist/のshale-spring.jarを、WebアプリケーションのWEB-INF/ディレクトリーにコピーします。この手順に従う場合には、全てが一つになったSpring JARファイルも、WebアプリケーションのWEB-INF/libディレクトリーにあることを確認します。この、spring.jarと呼ばれるJARファイルは、（もしまだ皆さんが持っていない場合には）shale-framework-20060204/lib/shaleframework/ディレクトリーの中にあります。
5. Java 5.0を実行している場合には、shale-framework-20060204/dist/のshale-tiger.jarをWebアプリケーションのWEB-INF/libディレクトリーにコピーします。このステップを行うのは、Java 5.0を実行している場合のみです。このステップをJava 5.0以外で行うと、Shaleを使うサーブレット・エンジンやWebアプリケーションに問題が発生します。

ここまで来ると、だいぶ面倒になってきます（そう、上記の色々なコピー作業は簡単なのです）。しかし、すべてを最も困難な方法で続けるよりも、少なくとも多少は楽ができる選択肢があることを皆さんに知らせるべきでしょう。実のところ、システム上でShaleを動くようにするためには、もっと容易な方法があるのです。手動でShaleを設定することにまつわる複雑さは多少理解できたはずなので、この「ショートカット」を検討する価値はあると言えるでしょう。

上に戻る

少し楽な方法

Shaleのダウンロード・サイトを再度訪れ、「starter」アプリケーションをダウンロードし、それにshale-starter-20060204.zipのような名前を付けます。このアーカイブを解凍すると、shale-starter/というディレクトリーが作られます。これは、ほとんどコンフィギュレーションを終えたShale Webアプリケーションであり、上のセクションで詳述したコピーやコンフィギュレーションをしなくて済むように考えられています。最初に、shale-starter/ディレクトリーをリネームし、Webアプリケーションに付けたい名前（例えばfirst-shale/など）に変更します。first-shale/ディレクトリーに行くと、幾つかのファイルとサブディレクトリーがあることが分かります。

first-shale/ディレクトリーの中で、build.propertiesという新しいファイルを作成します。このファイルによって、Shaleスターター・アプリケーションのビルド方法をカスタム化でき、このアプリケーションを確実に環境に合わせて設定することができます、リスト1は、容易に環境をカスタム化するための、基本的なbuild.propertiesファイルを示しています。

                
# Basic project information
project.copyright=My project, Copyright c 2006
project.name=My First Shale Application
project.vendor=IBM DeveloperWorks
project.vendor.id=com.ibm.dw

# Java package and context path for servlet engine
project.package=com.ibm.dw.firstShale
project.path=first-shale

# Directory for Shale distribution - change this for your system
shale.dir=/usr/local/java/shale-framework-20060204

# Directory for all your libraries - change this for your system
lib.dir=/usr/local/java/shale-framework-20060204/lib

システムに対して、こうしたプロパティーを設定したら、単純にantを実行します。Shaleスターター・アプリケーションがビルドを開始し、そして（パスが正しく設定されていれば）サンプル・アプリケーションを作成してくれます。もし問題がある場合には、ビルド・スクリプトがエラー・メッセージを出力します。エラー・メッセージは非常に分かりやすいため、問題なくエラー修正できるはずです。

ビルド・プロセスが終わると、target/という新しいディレクトリーが作られます。このディレクトリーを見ると、first-appという名前（あるいはbuild.propertiesの中でプロジェクト名として規定した名前）のサブディレクトリーがあるはずです。ほとんどのサーブレット・エンジンでは、このディレクトリー構造全体を、そのサーブレット・エンジン用のwebapps/ディレクトリーにコピーすることができます。例えば私はTomcatを使っているので、ビルド・スクリプトが作成したfirst-shaleディレクトリー全体を/usr/local/java/tomcat/webappsにコピーしました。

WARファイルをビルドする

WARファイルを提供するように要求するサーブレット・エンジンを使っている場合には、少し修正を加えるだけで、同じShaleスターター・アプリケーションのビルド・ファイルを使うことができます。このShaleアプリケーション用にはまだ何もJavaファイルが書かれていないため、WARファイルを要求すると（build.xml の中のJavaScriptコマンドはファイルを探しますが、何も見つけられないため）ビルド・スクリプト・エラーが発生します。この問題を修正するためには、build.xmlを開き、次のような「javadoc」で始まるラインを探します。

<!-- ===================== Generate Documentation ======================== -->


  <target         name="javadocs" depends="compile"
           description="Create JavaDocs">

    <mkdir         dir="${build.docs.dir}"/>

    <javadoc
            sourcepath="${src.java.dir}"
               destdir="${build.docs.dir}"
                author="false"
               private="true"
               version="true"
                source="${project.source}"
          packagenames="${project.package}.*"
           windowtitle="${project.name} (Version ${project.version})"
              doctitle="${project.name} (Version ${project.version})"
                bottom="${project.copyright}">
      <classpath refid="compile.classpath"/>
    </javadoc>

    <copy        todir="${build.docs.dir}">
      <fileset     dir="${src.java.dir}"
              includes="**/*.gif"/>
    </copy>

  </target>

そして、javadocタスクを単純にコメントアウトします（下記）。

  <!-- ===================== Generate Documentation ======================== -->


  <target         name="javadocs" depends="compile"
           description="Create JavaDocs">

    <mkdir         dir="${build.docs.dir}"/>
<
    <javadoc
            sourcepath="${src.java.dir}"
               destdir="${build.docs.dir}"
                author="false"
               private="true"
               version="true"
                source="${project.source}"
          packagenames="${project.package}.*"
           windowtitle="${project.name} (Version ${project.version})"
              doctitle="${project.name} (Version ${project.version})"
                bottom="${project.copyright}">
      <classpath refid="compile.classpath"/>
    </javadoc>
-->
    <copy        todir="${build.docs.dir}">
      <fileset     dir="${src.java.dir}"
              includes="**/*.gif"/>
    </copy>

  </target>
            

これはちょっと変則で、いったんShaleアプリケーション用のJavaコード開発を始めたら必要のない作業です。しかし、とりあえず進めるためには、これが一番です。修正されたbuild.xmlを保存し、ant distを実行します。Antがスターター・アプリケーションをコンパイルしてアセンブルし、dist/ディレクトリーの中に新しいWARファイルを作ります。例えば、私がant distを実行するとdist/first-shale-0.1.warが作られました。今度はこのWARファイルを、サーブレット・エンジンのwebapps/ディレクトリーにコピーします。

上に戻る

インストールをテストする

ここまで来れば、どんなインストール・パスを選択したにせよ、サーブレット・エンジンが開始でき、http://your.host.name/first-shaleにあるShaleアプリケーションにアクセスできるはずです。例えばローカル・マシンでTomcatを実行すると、http://localhost:8080/first-shaleになります。全てが順調に動作していれば、図2に示すような単純なページが見えるはずです。

得られるものに比べて作業が多すぎると思えるかも知れませんが、単純なbuild.propertiesファイルを開き、編集することによって、面倒な大量のコピーやコンフィギュレーションをせずに済んだことを考えてみてください。新しいShaleアプリケーション対する作業を始める場合には、ブランクのShaleスターター・アプリケーションから始めるのが最も容易である場合が多いのです。実際、次回の記事でShaleアプリケーションの開発を始める際には、出発点としてブランクのShaleスターター・アプリケーションを使用します。

上に戻る

Shaleのユースケース

これでダウンロードとインストールに関してはほとんど終わりですが、先に進む前に、Shaleのメイン・ダウンロード・サイトにあるShaleのユースケースWARアプリケーションをダウンロードしてみましょう。shale-usecases-20060204.warのような名前のファイルを探します。このWARファイルをダウンロードしてサーブレット・エンジンのwebapps/ディレクトリーの中に置き、次にこのWARにナビゲートします。私のシステムでは、http://localhost:8080/shale-usecases-20060204/に行くと、図3に示すような画面が得られました。

このユースケース・アプリケーションは、少し時間をかけて見る価値のあるものです。このアプリケーションには、Shaleの持つバリデーター機能やリモート・サポート機能に関するデモの他、単純なAjaxアプリケーションも含まれています。単純なShaleアプリケーションでさえ、こんなことまでできる、という一端が、こうしたユースケースを少し見るだけで理解できるはずです。

そう言った上で、警告もしておきましょう。こうしたユースケースの一部はまだ作成途中のため、いつ夜間ビルドをダウンロードするかによって、うまく動作しないユースケースもあるかも知れません。ユースケース・アプリケーションを後から再度ダウンロードし、何か修正されていないか確認した方がよいかも知れません。こうした小さな問題はありますが、Shaleがどのようなものかの基本を把握する上で、ユースケース・アプリケーションは非常に役に立つはずです。

上に戻る

Shaleに参加してください

ほとんどのWeb開発者は、既存のフレームワーク（ShaleやStrutsあるいはSpring）を使ってWebアプリケーションを開発する以上のことはしないものです。それは決して悪いことではありませんが、フレームワークを理解しようとする場合や、フレームワークに関わる技術を理解しようとする場合には、そのフレームワーク自体の中に深く入り込む以上に良い方法はありません。

Shale（そしてStrutsも）の場合は、実際にフレームワークの内部を詳しく調べることによって、サーブレットやWeb開発について、想像以上に深く学ぶことができます。これは、特に皆さん独自のプロジェクトの中でShaleの依存関係を使う上でも、非常に役立ちます。例えばJavaアプリケーションからのロギングに関心がある場合であれば、Shaleを学ぶことによって、どんな記事を読むよりも効率的にApache Loggingプロジェクトを理解することができます。同じことは、Jakarta CommonsのBeanUtilsプロジェクトやChainプロジェクト、Digesterプロジェクトなどについても言えます。これらはどれも、どんなWeb開発者にとっても素晴らしいツールであり、また有益なものです。ですから、そうした領域を学ぶ上で、数週間、あるいは数ヶ月の間Shaleをいじり回すことは、非常に効果的なのです。

この記事は、Shaleの詳細を解説するシリーズの第1回なので、Shaleプロジェクトに関わるための入り口（そして困難）についても触れておくべきでしょう。

まず、ソースに当たる（しかしソースはどこに？）

残念ながら、Shaleの開発プロセスに関するドキュメンテーションは、ほとんどありません。ですからShaleのソースコードを直接扱おうとする場合には、少しばかり工夫が必要です。私が先に詳述した、Shaleをフレームワークとして使う場合のダウンロード方法は、Shaleのソースコードをダウンロードする場合にも、ほとんどそのまま当てはまります。夜間ビルドにはShale用のソースコードが全て含まれ、各コード・ディレクトリーの中にはbuild.xmlファイルがあります。

そして、Shaleダウンロードのルートにあるbuild.properties.sampleファイルを、build.properties（オリジナルのファイル名の終わりにある「.sample」を削除します）というファイルにコピーし、このファイルをシステムに合わせて修正します。リスト2は、このファイルのサンプル版がどんなものかを示しています（簡単にするために、コメントの多くは除かれています）。

                
# This file contains example property settings that you would use to customize
# your build environment to build the Struts Shale Library from
# source code.  To use this file, make a copy of it in "build.properties" and
# customize the values as required.

# Root directory into which you have unpacked the Shale Framework release.
root.dir=${basedir}

# Fully qualified pathname of the directory into which you have unpacked
# a binary distribution of the JavaServer Faces Reference Implementation
jsfri.dir=/usr/local/jsf-1_1_01

findbugs.outputFile=${root.dir}/find-bugs.html
lib.dir=${root.dir}/lib
jsf.home = ${lib.dir}/myfaces
jsf-api.jar = ${jsf.home}/myfaces-api.jar
jsf-impl.jar = ${jsf.home}/myfaces-impl.jar

# The absolute or relative pathname of the Apache Struts 
# distribution
struts.home = /usr/local/jakarta-struts

spring.home=${lib.dir}/springframework
findbugs.home = /usr/local/findbugs-0.8.6

このビルド・ファイルの中にあるパスの大部分は、皆さんのシステムのsystem. ${basedir} デフォルトに合わせて、Antを実行するディレクトリーに変更する必要があるでしょう。ですから、Shaleダウンロードのルート・ディレクトリーからAntを実行しているのであれば、その点に関しては問題ありません。ただし他のパスについては、そのシステムに適切なものに置き換える必要があります。例えば、JSF基準実装がc:/java/jsf-1_1_02にある場合であれば、その値をjsfri.dirディレクトリーに使います。ほとんどのデフォルト・パスは、MyFacesを使うようになっています（囲み記事、「MyFacesかJavaServer Facesか」を見てください）が、もちろんSunのJSF実装を使うこともでき、その場合にはパスを適切に変更します。またStrutsや、Spring（コアShaleフレームワークではオプションであり、必ずしも必要ではありません）用のパスや、FindBugsプロジェクト用のパスも設定する必要があります。

Antが大活躍

このファイルを正しく設定できたら、ShaleダウンロードのルートでAntを実行します。ただし最初に、ant download-dependenciesを実行する必要があります。既に気付かれたと思いますが、Shaleには多くの依存関係があります。こうした依存関係のダウンロードの自動化にAntを使えば、時間も（苛立ちも）減らすことができます。またAntスクリプトは、こうした依存関係にShaleを接続するためのパスの設定も処理します。さらに、ant copy-jsf-riを実行してJSF特有のタスクを処理することもできます（詳細についてはAntが処理してくれるため、あまり詳細を気にする必要はありません）。

メインのShaleリリースをビルドする前にant cleanを実行して、既存のビルド・コードをすべて削除します。これによって全体的なビルド時間は長くなりますが、全てのコードについて一貫したビルドを保証できます。最後にant releaseを実行すると、まったくゼロからShaleがビルドされます。このAntスクリプトが終了すると（しばらく時間がかかります）、完全なShaleディストリビューションが、ソースからビルドできたことになります。

リストに関する一言

オープンソース・プロジェクトは、ほとんど完全にeメールで進められます（それにApacheバグ追跡データベース（参考文献）が加わります）。この点ではShaleも同じですが、Strutsのメーリング・リストも相変わらず使われています。Shaleの使い方に関して質問がある場合には、user@struts.apache.orgにメールを送ります。ただし実際にShale内部の開発を始めたら、メールはdev@struts.apache.orgに送るようにします。どちらの場合も、メールの標題欄は [shale] で始め、（Struts関連の質問ではなく）Shaleに関する質問であることが明確に分かるようにします。Shaleは独立のプロジェクトとして動き始めているため、数ヶ月先にはShale専用のメーリング・リストができると思った方がよいでしょう。

開発リストにメールを送る場合には、少しばかり注意が必要です。つまり、宿題をきちんとこなし、要点を明確にすることです。明確さに欠け、要点を絞らず、充分考慮されていないメールは歓迎されません。また、「Shaleを勉強したいので何かアプリケーション例を送ってください」というようなメールを送ってしまうと、辛辣な答えを受け取ることになるでしょう。これは馬鹿げた忠告に思えるかも知れませんが、現実的なことなのです。開発リストは、常にスパムや、そうした要求にさらされています。当然ならが、そうしたスパムや要求は『歓迎されません』。一般的な助言として、時間をかけて注意深く質問を整理し、使用しているプラットフォームとソフトウェアのバージョンを説明し、当然と思われるステップを既に試していることを明言すべきでしょう。そうすれば、質問は歓迎、尊重され、要求に対する回答も、それを反映したものとなるはずです。開発者リストは恐れるべきものではありませんが、敬意を持って扱うべきものなのです。

上に戻る

まとめ

この、Shaleに関するシリーズの第1回の中で私が最も言いたかったことは、Shaleは万人向きではない、ということです。多くの開発者はTapestryの時代ともなると、きちんと梱包され、整理されたドキュメンテーションを持ち、自動インストーラーや洗練された管理インターフェースを備え、充分にテストされた製品を期待するものですが、Shaleはとてもそんなものではありません。こうした期待事項は（「きちんと梱包されている」という点を除けば）、今後のShaleフレームワークでは実現されるはずですが、現在の（2006年初めの時点での）Shaleでは作業は進行中であり、Shaleのサイトでも、ほとんど「アルファ」状態のプロジェクトであると言っています。Shaleが使用しているコンポーネントの多くは安定して成熟していますが、Shaleそのものは、まだ非常に若い段階にあります。もし皆さんが、苦労したり混乱したりしながら作業することを嫌うのであれば、もう1年ほど待つべきかも知れません。

その一方、Web開発の最先端に追いつこうとするJava開発者であれば、本格的にShaleプロジェクトに取り組むべきでしょう。まだ雑なところが多く、設定して正しく動作させるには余計な努力が必要かも知れませんが、Shaleは格別な人気を持つWeb開発フレームワークとなる可能性を秘めています。真の意味でStrutsの遺産の上に構築されながら、まったく新しいものを提供しているのです。それだけでも、検討するだけの価値を持っています。また、オープンソース・プロジェクトに関心を持つ熟練した開発者や、冒険心を持った開発者にとっても、Shaleは時間や努力を投資する価値があります。

このシリーズでは、Shaleの中に飛び込もうとする人達のために、今回説明したインストールや基本ステップをはるかに上回る内容について解説して行きます。次回はShaleの背景にある原則と、そうした原則を、Shaleアプリケーションを書く際にどう適用すべきかについて説明します。また、Strutsスターター・アプリケーションの案内ツアーも行い、それを使って皆さん独自のアプリケーション開発を始める方法についても解説する予定です。腕まくりをして、次回の記事に期待してください。

参考文献

学ぶために

• 「;JSFを信じない人のために: JSFに関するFUDをクリアーする」（Richard Hightower著, developerWorks, 2005年1月）は、Shaleの基礎の1つであるJavaServer Facesの強みと弱みを詳細に調べています。
  
  
• 「Service-oriented modeling and architecture」（Ali Arsanjani著, developerWorks, 2004年11月）は、サービス指向アーキテクチャーの仕組みの概要を、あまり流行に流されずに解説しています。
  
  
• 2回シリーズの「In tune with Tapestry」（Brett McLaughlin著, developerWorks, 2006年1月）を読んで、ユーザーに使いやすいWeb開発フレームワークの新種の1つである、Tapestryについて学んでください。
  
  
• 「Struts、Tiles、JavaServer Facesを統合する」（Srikanth ShenoyとNithin Mallyaの共著、developerWorks, 2003年9月）は、Shale登場前の様相を興味深く捉えています。
  
  
• The Shale homepageには、Shaleに関するjavadocや、その他様々な情報が用意されています。
  
  
• The Struts homepageを見てください。Shaleに先立つStrutsは、それ自体が、よく使用され、また拡張可能なWeb開発フレームワークです。
  
  
• Shaleの特定なバグや機能の状況に関する最新情報が、Apacheバグ追跡用のWebサイト、Bugzillaで提供されています。
  
  
• Java technologyゾーンでは、Javaプログラミングのあらゆる面を網羅した記事が、他にも豊富に用意されています。
  
  

製品や技術を入手するために

• Apache JakartaのWebsiteでShaleを見つけてダウンロードし、すぐにでも使い始めてください。
  
  
• Apache Tomcatは、ShaleでもStrutsでも完璧に動作する、素晴らしいサーブレット・エンジンです。
  
  
• Jakarta Commons BeanUtilsは、JavaBeans命名フォーマットに従うクラスを扱うための手軽なユーティリティー・クラスを提供しています。
  
  
• Jakarta Chainは、Chain of Responsibility 設計パターンを実装したJavaベースのコンポーネント・セットです。これを利用すると、コマンドやコンポーネントを、お互いに依存させずに「鎖で連結する」ことができます。
  
  
• Jakarta Digesterを利用すると、XMLからJavaへのマッピングを容易に行うことができ、XMLとして表現されたコンフィギュレーション・ファイルやプロパティー・ファイルを単純に読むことができます。
  
  
• Apache Loggingは、C++やJava、Perl、PHP、PL/SQLなどを含む様々なプログラミング言語のためのロギング・サービスです。
  
  
• Apache Antは、Shaleをビルドするために使われるJavaベースのビルド・ツールです。
  
  

議論するために

• developerWorks blogsに参加して、developerWorksのコミュニティーに加わってください。
  
  

著者について

Brett McLaughlin氏は、Logo (小さな三角形を覚えていますか?) の時代からコンピューターの仕事をしています。現在の専門は、JavaおよびJava関連のテクノロジーを使ったアプリケーション・インフラストラクチャーの構築です。ここ数年は、Nextel Communications and Allegiance Telecom, Inc. でこれらのインフラストラクチャーの実装に携わっています。Brett氏は、Javaサーブレットを使ってWebアプリケーション開発のための再利用可能なコンポーネント・アーキテクチャーを構築するJava ApacheプロジェクトTurbineの共同設立者の1人です。同氏はまた、オープン・ソースのEJBアプリケーション・サーバーであるEJBossプロジェクトと、オープン・ソースのXML Web公開エンジンであるCocoonにも貢献しています。

この記事を評価する

コメント

上に戻る

目次

• Shaleを評価する
• Shaleをインストールする
• 少し楽な方法
• インストールをテストする
• Shaleのユースケース
• Shaleに参加してください
• まず、ソースに当たる（しかしソースはどこに？）
• まとめ
• 参考文献
• 著者について
• コメント