IBM のシニア・テクニカル・スタッフ・メンバーとして、主に Domino 6 における Web テクノロジーを担当するジェフ・カーロウは、全体の調和を図るためにグループ間での開発の調整に当たると同時に、彼自身も開発作業の一端を担っています。Domino 6 Pre-release 1 の公開に当たり改めて行われたこのインタビューで、ジェフは Domino 6 の Web テクノロジーについて、そしてこれらが J2EE などの標準テクノロジーとどのように連携するのかについて説明しています。
まず、Notes/Domino 6 の新しい Web テクノロジーについてお聞かせください。
Notes/Domino 6 は、Web の開発と展開の作業効率を上げるためにかなり手が加えられています。Notes/Domino 6 には、R5 サーブレット・エンジンをはじめとする R5 の機能がすべて搭載されています。そして、開発者向けに、Web アプリケーションの機能、特長、およびパフォーマンスをさらに向上する数多くの機能が追加され、ドミノ・デザイナーと Web アプリケーション・サーバーの改良が図られています。
まず、デザイナーにはカラー・コーディングと HTML タグのオート・コンプリート機能を備えた HTML エディターを追加しました。また、デザイナーとサード・パーティー Web オーサリング・ツール間で開発作業を共有する能力を高めるために、WebDAV サポートを追加しました。さらに、チーム開発を容易にするために設計ロック機能もサポートしました。ブラウザーとして Internet Explorer を使用する人のために、アプレットの代わりに Internet Explorer の組み込みリッチ・テキスト・コントロール（iノーツ Web アクセスでも利用）を使えるようにして、リッチ・テキスト編集の作業効率を上げました。レイヤー、CSS（Cascading Style Sheet）、JavaScript ライブラリ、HTML コードの「断片」共有、さらにオプションとしてセクションごとの DHTML/JavaScript 生成もサポートし、サーバーと通信せずにセクションの表示／非表示を制御できるようにしました。また、ACL を参照せずに Web から NSF が開かれるのを制限できる新しいデータベース・プロパティーも追加しました。
サード・パーティー Web サーバー・プラグインについて、もう少し詳しくお聞かせください。
私たちが WebSphere チームとの関係を活用している分野の1つが、サード・パーティー Web サーバー・プラグインの再利用です。プラグインにより、IIS や Apache のようなサード・パーティー Web サーバーにブラウザーへの「対応」と（サード・パーティー Web サーバーが得意とする）静的コンテンツ処理を任せ、NSF 要求はすべてドミノ Web サーバーに転送することが可能になります。プラグインは HTTP を利用してサーバーと通信するため、サード・パーティーの HTTP サーバーを DMZ に配置し、プラグインによってファイアウォールの内側に置かれたドミノ サーバーと通信することができます。アーキテクチャーとコーディングは、すべての WebSphere プラグインを利用できるように構築されており、これらはいずれ認定する予定です。「ドット0」ではIIS に対して認定し、将来のメンテナンス・リリースで他の Web サーバー・プラグインに対して認定する予定です。
ただし、ここで1つ申し上げたいのは、ドミノ開発者が J2EE に移行する必要はないということです。ドミノ Web アプリケーション・サーバーは今後も存続し、拡張が続けられます。今のところ、データ中心のサイトをおそらく最も速く簡単に開発できる方法でしょう。ドミノの Web プログラミング・モデルを利用して開発できる機能豊富なアプリケーションの一例としては、Domino 6 Web Administrator が挙げられます。しかし、この開発の容易さのために犠牲になる点もあります。埋め込み HTML を除くほとんどの HTML の生成と処理の大部分がドミノによって管理されるため、ドミノのモデルに制約されることになり、生成 HTML それ自体を制御する能力が犠牲になります。完全な制御が必要な一部の Web デザイナーなら、その制御能力を得る代償としてアプリケーションが複雑になることをいとわないでしょう。結局、すべて選択の自由ということになります。そして、この選択は、各自の状況に合わせて行うことができます。
なるほど。それは J2EE のホスティング側のお話ですね。アプリケーション開発についてはどうですか？
先ほど申し上げたとおり、J2EE アプリケーションの開発を容易にする数々のサード・パーティー・ツールがあり、IBM や Borland、Sun、WebGain、Macromedia などがツールを提供しています。私個人は、プログラマーのエディターを使ってすべての開発をしています。デバッグには IBM WebSphere Studio Application Developer か、System.out.println() を使っています。Application Developer では、JSP コードと Java コードを同時にデバッグできるため、アプリケーションをすべてのレベルで容易に管理できます。
短期的には、これらツールのいずれを使っても、何らかのウィザードによる基本的なプログラミングが可能です。中長期的には、何と言ってもアル・ゾラーが Lotusphere で発表した現在開発中の RAD J2EE ツールでしょう。私たちは、本当に胸を躍らせながらこの新しい RAD 環境の開発に取り組んでいますが、詳細を明らかにするにはまだ時期尚早です。ただし、「オープン・ソース・プロジェクト Eclipse のフレームワークをもとに構築され、他の WebSphere Studio ツール・オファリングと密接に統合される」とだけ申し上げておきましょう。主な目標の1つは、既存のドミノ開発者が大量のコーディングを行わなくても簡単に J2EE アプリケーションを開発できるようにすることです。
ドミノ・カスタム・タグとはどういうものですか？
HTML は知っていても、Java プログラミングには必ずしも詳しくないテンプレート開発者を支援するために、JSP はカスタム・タグと呼ばれるこの機能を備えています。これは、HTML タグよりもむしろ XML タグによく似たタグで、HTML の中に埋め込んで使います。このタグの処理はサーバー側で実行され、タグの意味が何であろうと、サーバーは HTML を生成してクライアントに送ります。
たとえば、ドミノ・カスタム・タグ・ライブラリーーはビュー全体を串刺しできるため、ビューに含まれるすべてのエントリーを調べ、ビュー内の各明細エントリーごとに表示したい内容を本体や明細行に表示することが可能です。あらゆる種類のタグが用意されています。セキュリティタグも、フォームを作成するためのタグもあるため、ドミノ・フォームの作成方法と同じように、同様のフォームを HTML で作成できます。JSP の主な特徴の1つは、カスタム・タグをサポートすることです。他のサード・パーティーから別のカスタム・タグを手に入れた場合も、同様に JSP 内で使えます。つまり、JSP では、任意の数のカスタム・タグ・ライブラリーを同一ページ上で使えるのです。
まず、正確な HTML フォームのようなものを作成します。すると、その結果、データの更新や表示をサポートするものが得られます。これは、表示モードと編集モードの両方をサポートします。緩やかなモデルとしてノーツを利用しているため、ノーツと同様の結果が得られます。ノーツとの完全な互換性を目指すのではなく、単にモデルとして利用するのです。というのも、アプリケーションはそのように作成するものだという考えがユーザーにすでにあるからです。LotusScript を扱ったことがあり、ノーツタイプの開発経験がある人がターゲットであることはわかっていましたので、スキルを確実に応用できるようにする必要があると考えたのです。
また、HTML の大量生成を避ける方針との兼ね合いから、「マジック」HTML はそれほど多く生成されません。たとえばページング用タグのように、ちょっとしたマジックを使うタグも中にはありますが、ほとんどのタグは基本的に1つの HTML タグになるか、HTML 以外のタグになるかのいずれかです。そして、最終的には単なるデータに変換され、画面表示されます。
これで、アプリケーション開発の選択肢が新たに増えたわけですが、ドミノ・アプリケーションと J2EE（JSP およびサーブレット）アプリケーションのどちらを選ぶかは、どのようにして決めたらいいのでしょうか？
結局、アプリケーション作成にどれぐらいの時間をかけるのか、そして結果の HTML をどの程度正確に制御したいのかによって決まります。ドミノ Web アプリケーションは、データ中心サイトの迅速立ち上げに適していますが、ドミノによって生じる境界の範囲内で作業を行う必要があります。多くのアプリケーションの場合、これは悪くないトレード・オフです。ノーツのフォームとビューを使えば、ごくわずかのコーディングで多くの機能を提供できます。ドミノの優位点としては、階層構造のカテゴリ別のビュー、ビルトイン検索機能、リッチ・テキスト編集、ビルト・イン・セキュリティーなどが挙げられます。まだまだありますが、これ以上説明する必要はないでしょう。
現在 Web エージェントまたは R5 サーブレットを使って Web アプリケーションを開発している人なら、おそらくより新しい標準をサポートしたサーブレット・コンテナの JSP やサーブレットに移行したいと考えるでしょう。数十万人のユーザーを同時にサポートする企業規模の Web アプリケーションを開発している人なら、おそらく市販の J2EE アプリケーション・サーバーを検討したいと考えるはずです。
お客様が Domino 6 の機能を利用したアプリケーションの開発計画を立てる際の指針をいくつか示していただけますか？
Lotusphere や、Notes.net の Notes/Domino 6 Pre-release feedback forum でたくさんのお客様と話をしましたが、お客様が開発しているアプリケーションの種類は非常に多岐にわたります。ほとんどの人は従来どおりノーツ Web アプリケーションを開発しており、JSP の簡単なチェックを行っているのは一部の人にすぎません。
あるお客様からは、カスタム・タグ・ライブラリーを使って、IBM Voice Server 上で VoiceML ページを構築していると聞きました。また、JSP とタグを使ってコンサルタント・ナレッジベースを公開しているお客様もいました。さらには、カスタム・タグとドミノ Web サーバーの両方を使ってハイブリッド・ナレッジマネジメント・アプリケーションを構築しているお客様もいました。IBM の社内アプリケーションのアーキテクトから今日聞いたばかりの話ですが、彼は、ノーツ・クライアント・アプリケーションを使って承認ワークフローでコンテンツ編集を行い、XML ツールキットでコンテンツを抽出し、XSLT を使ってそれを HTML に変換した上で、それを JSP とサーブレットをベースとする Web アプリケーションでエンド・ユーザーに提供しているそうです。そして、コンテンツの添付ファイルをすべて NSF データベースに入れたまま、すべての処理を行っているとのことでした。
ドミノの今後について何かコメントは？
ドミノは、消えることも、WebSphere に「変化する」こともありません。Notes/Domino 7 は計画済みで、今後も電子メール・メッセージング・プラットフォームとしてのレベル向上を図っていきます。同時に、ドミノ Web アプリケーションの機能を向上するための様々な拡張のアイデアもあります。今後の戦略としては、まず Web サービスを介してドミノや他のロータス製品のコラボレーション機能を利用できるようにし、ソリューション内でそれらサービスを組み合わせたり、調和させたりできるように「コンポーネント化」を進めます（社内では、これをコンテクスチュアル・コラボレーションへの移行と呼んでいます）。さらに、これらのサービスをベースにした新しいロータス・アプリケーションを開発する計画もあります。明確な戦略的ロードマップも決定済みで、この構想を実現する計画に取り組んでいるところです。
