IBMは「文脈依存のコラボレーション（contextual collaboration）」と呼ばれる新たな業務パラダイムが現れ、そこでは社員がさまざまな業務プロセスの「文脈に応じて（in context）」互いに協働作業を行なうようになると考えている。孤立して稼動するコラボレーション・ツールをばらばらに使うのではなく、ユーザはどこで働こうとすぐに協働作業のための機能を手に入れることができる。その機能は場合によってはポータル・アプリケーションにあるかもしれないし、ウィンドウズ・アプリケーションやWebアプリケーション、携帯端末にあるかもしれない。

このビジョンを実現すべく、IBMロータスはロータス製品相互の統合、および、サードパーティー製品や特製のアプリケーションとの統合をより容易にするためのモジュール化された協働作業サービスを出荷する予定である。その実現方法は技術的にはドミノサーバを含む全ロータス社サーバ製品用のサービス指向インターフェースの集合体となる。今日、ロータス製品のAPIは製品ごとに大きく異なっており、統合作業をかなり複雑にしている。ロータスソフトウェアは全製品にわたって共通なスキームとデータモデルを導入することで統合作業を単純化し、製品間でAPIが統一されるようにする。これらのAPIはあなたの企業がより容易に複数の製品を横断する統合アプリケーションを構築できるようにする。ロータスはまずJavaインターフェースを作成する予定だが、Webサービス技術の成熟に応じてWebサービスへ移行する。

ロータス製品で構築されたあなたの企業の既存アプリケーションが影響を受けることはなく、そのアプリケーションへの投資をさらに活用できるようになるだろう。将来的にはあなたのアプリケーションは次世代こらボレーションサービスの恩恵を受けることができる。たとえばドミノの受信ボックスやカレンダーは、ひとつのサービスとして、Webサービスを利用できるどんなアプリケーションとも統合できるようになり、あなたの企業のシステム開発者はさまざまなタイプの業務アプリケーションにこれらの機能を容易に組み込むことができる。

こうした戦略を完全に理解し、ドミノアプリケーションとその開発作業に応用するためには、３つの車線がある高速道路を想像してみるとよい。一つはロータスドミノの車線、もう一つはWebSphereの車線、そして最後に次世代製品（next gen）の車線だ。ロータスドミノの車線は地の果てまで続いており、WebSphereの車線と並行して走っている。WebSphereの車線もまた地の果てまで続いている。そして次世代製品の車線はこれら２車線と将来のある地点で合流している。

ロータスドミノの車線にはドミノの協働作業アプリケーションを開発・配置するための環境がある。それによってアプリケーションを素早く開発することができ、それらのアプリケーションをオフラインにすることで、人々・業務プロセス・データをひとつにまとめてe−ビジネスの生産性と迅速な意思決定を容易にする。ロータスは現在のドミノアプリケーション開発モデルとデータストア（NSFファイル）を維持し、将来的には顧客や開発者の要求を満たすべく機能拡張する予定だ。IBM社の伝統にしたがってロータスノーツ／ドミノの顧客も予見可能な将来にわたって包括的なサポートを受けることができる。さらにドミノはJ2EE、Java Server Pageのタグ、Java API、LDAP、RDB統合など標準基盤技術に対するサポートを拡大し、ドミノとWebSphere両方の「車線」に興味をもつ開発者を支援する。

WebSphereの車線ではJ2EEの機能をアプリケーション開発プラットフォームとしててこ入れしている。J2EEは一般的にプレゼンテーション層、ロジック層、データ層に分離される多階層アプリケーションを開発・配置・管理するための詳細なアーキテクチャを提供する。このアーキテクチャは拡張性、柔軟性、運用性を提供するために設計されたものだ。J2EEは機能豊富なアプリケーションの開発プラットフォームだが、協働作業を支援する機能はほとんど持っていない。したがってロータスドミノに豊富な協働作業支援の機能を提供してもらうことで恩恵をうける。ロータスドミノとWebSphereを使って設計されたアプリケーションは強力な協働作業機能と強大な業務処理の拡張性をブレンドしたものとなり、幅広いe−ビジネスソリューションを提供することができる。

近い将来、第３の車線である次世代コラボレーションサービスがロータスドミノとWebSphereと合流することになるだろう。次世代の「車線」はロータスドミノとWebSphereの両方の開発者コミュニティーに、統合された協働作業ソリューションを構築するためのモジュール化アーキテクチャを提供する。ドミノの開発者はWebSphereと次世代製品の両方において持てる技術を活用し、アプリケーションの機能拡張を行なうことができるようになる。WebSphereとJ2EEの開発者はロータスドミノの協働作業機能や他のロータス製品の機能をWebサービスを通じて統合することができる。どちらの場合も協働作業ソリューションの統合がより容易に、標準的な開発スキルによって実現できることになる。

ロータスの役割は新しいことをより容易に、安価で実現できるソフトウェアを開発することだ。次世代戦略を一言で表現するなら、協働作業のためのソリューションを企業のいたるところで統合することができ、それによって事業の全領域で生産性とコミュニケーションを高めることができるような次世代コラボレーションの新たなアーキテクチャということになる。

ロータスドミノはデータとアプリケーションへの接続・非接続を問わずその要求を処理する協働作業のための包括的なアプリケーション・プラットフォームである。ほとんどの顧客ははじめロータスドミノを企業用電子メールシステムとカレンダー、スケジュール管理のためのソフトウェアとして購入するため、この種のアプリケーションは協働作業アプリケーションでもっとも広く利用されている。しかしほとんどの顧客は「電子メール以上の」機能を利用して基幹業務プロセスを支援し、社員どうしが効率的かつ安全に協働作業できるようにしている。ロータスドミノはシステム開発、テスト、利用、運用管理、セキュリティー、接続性、Webサーバ、電子メールサーバ、スケジュール管理エンジンなどなど、すべての機能に必要な完全なインフラを一つにおさめて提供しているからこそ、包括的と言われているのだ。

ドミノ開発者はノーツクライアント、Webブラウザ、携帯電話、携帯端末のためのアプリケーションを開発することができる。ほとんどの場合ユーザは様々なタイプのクライアントを組み合わせたハイブリッドな利用のしかたをしている。ハイブリッドなクライアントのドミノアプリケーションは安全なデータ同期アプリケーション実現のために複製やオフラインサービス機能を活用しており、これらの機能に非接続の状態でもネットワーク経由でサーバにアクセスしている状態でも稼動することができる。複製機能によってユーザはドミノアプリケーションとファイルシステム上のデータを自分のパソコンにコピーして保存し、定期的にデータを同期することができる。したがってユーザはネットワークから切断されているときでも生産性の高い効率的な業務を行なうことができる。ドミノ・オフラインサービス（DOLS）がブラウザに追加インストールされていれば、ユーザはドミノWebアプリケーションにおいても切断された状態のまま同様の生産性を実現することができる。

ドミノソリューションの実例としては、プロジェクト用のチームルームなど文書中心のワークフロープロセス、文書管理、電子会議室、営業支援、社員向けのセルフサービス・アプリケーションなどがある。あらゆる規模の企業がドミノアプリケーションから恩恵をうけている。

米国海軍はロータスドミノを軍艦どうしの安全な協働作業のために利用している。このシステムはたった数ヶ月で導入されたが、海軍の「Collaboration @ Sea」プロジェクトはWebブラウザの手軽さと同時に複製された分散データベースの利点も活用し、関係者全員がネットワーク帯域を気にすることなくデータを同期することができる。

またニューヨーク市での2001年9月11日の悲劇のあと、たった数時間でグラウンド・ゼロ周辺の建造物の状態や行方不明者の分散データベースを管理するためのドミノ・アプリケーションが構築された。ロータスドミノのオープン・プラットフォームは収集されたデータを多くの支援団体で共有できるようにするための手助けとなった。ロータスドミノはアプリケーション開発・仕様のための成熟した製品として広く利用されているが、次のリリースで６番目のバージョンとなる。

包括的なアプリケーション・プラットフォームとして、ロータスドミノは迅速なアプリケーション開発（RAD）のためのツール、文書ベースのオブジェクトモデル、特製の協働作業アプリケーションを構築するための広範なプログラミング言語のサポートなどを含んでいる。これらの機能を選択することで、あなたの会社は多くの開発者スキルを活用し、ドミノ・アプリケーションを開発することができる。例えば最小限のプログラミング経験があれば、電子会議室や文書ライブラリなどの協働作業アプリケーションが必要とされている場合、すぐに使えるテンプレートからまったくプログラムを書かずに容易にドミノ・アプリケーションを開発できる。

もし役割をベースに定義されたワークフローに文書回覧のためのワークフロー機能を追加したいなら、オリジナルのテンプレートにマクロや式を追加すればよい。文書の内容やデータの外観にしたがって通知メールを発信するための条件分岐ロジックを追加する場合は、基本的なプログラミング・スキルのある開発者ならアプリケーションの機能拡張が可能だ。典型的なドミノのカスタム・アプリケーションは非常に基本的なプログラミング・スキルがあれば大部分の作業は十分である。

もっと進んだソリューションのためには、開発者はJavaやマイクロソフトのCOM，C／C＋＋、CORBAなどを利用できる。ロータス・ドミノは単一のオブジェクトモデルに対して複数のインターフェースを持っており、それによって開発者は作業に最適なプログラミング言語を選択し、新しいアプリケーションやソリューションにおいても自分のスキルを再利用することができる。

ソリューションの中にはノーツ以外のデータや多言語のサポートを必要とするものもある。ロータスドミノのRAD機能はそのようなソリューションを容易にする。視覚的にわかりやすいデータマッピング技術を使って開発者は容易に、かつ迅速に関係データベースのデータとノーツのデータを統合することができる。ロータス・コネクター（※訳者註：ノーツと関係データベースを連携するための製品。日本では「ノーツ・ポンプ」という名前でよく知られている）として知られている技術を使うのにプログラミングの知識はいらない。世界中での利用が要求されるドミノ・アプリケーションならごく単純な方法ですべての設計要素をさまざまな言語に翻訳することができる。これらRAD機能を利用したすべての作業がドミノ・デザイナーと呼ばれる統合開発環境の中で行なわれる。

ドミノ６におけるドミノ・アプリケーション開発の特徴を活用すれば、チームによる開発が単純化され、リリース５に対してさまざまな機能拡張や改善も提供されることで、あなたの会社はさらに多くのコードや設計要素を再利用できるようになり、これらすべてのことが開発者の生産性を向上させる手助けとなる。主要な新機能には次のようなものがある。

ご覧のようにロータスはノーツとドミノのアプリケーションモデルに顧客から要求された新機能を拡張しつづける予定だ。ロータスノーツ／ドミノの次リリースでもロータスがオープンで標準的なプラットフォーム戦略を一貫してとりつづけることを期待してよい。例えばモバイルや無線アプリケーション開発機能を追加したり、Webサービスの利用をより容易にしたり、XMLの機能拡張をおこなうなどだ。

アプリケーション開発に対するドミノのロードマップはロータスドミノがXMLによって示されるような柔軟性のあるオープンなプラットフォームであり、幅広いプログラミング言語をサポートするという前提に立っている。柔軟性とオープン性はJ2EEを活用するドミノアプリケーションの機能にとって鍵となる点で、上述の高速道路の例えで、もう一つの「車線」にもまたがっている。あなたのドミノアプリケーションのデータやアプリケーションロジックへの投資を拡張することができ、（LotusScriptやJavaを通じた）WebサービスやJSPタグの利用によって適切なアプリケーションやデータを表示し、次世代製品やWebSphereを使ったアプリケーションと統合することができる。

ロータスがドミノデザイナーやドミノのプログラミングモデルに徐々に機能追加しているのと並行して、WebSphere Studioとの統合も続けられている。この統合はドミノデザイナーを置き換えるためのものではなく、開発者チームが開発環境の内部でドミノとWebSphereアプリケーション・サーバの両方を容易に使えるようにするためのものである。そのような開発チームはアプリケーション構築でそれぞれのシステムの強みを活用することで恩恵をうけるだろう。今後ドミノデザイナーとWebSphere Studio間のアプリケーション開発・統合でどのような点が重要かについて、さらに情報を入手したい場合は、このホワイトペーパーの「RADの未来」の項をご覧頂きたい。

ドミノアプリケーションとWebサービス

Webサービスは最近登場した技術標準で、シンプル・オブジェクト・アクセス・プロトコル（SOAP）として知られる標準化されたアクセス手順を提供することでアプリケーションの統合を単純化するものだ。開発者はXMLを使ってアプリケーションのインターフェースを表現することができる。現在ドミノ開発者は約３５行のLotusScriptかJavaのコードを使うだけで、どのプラットフォームであってもWebサービスのインターフェースを既存のドミノR５のアプリケーションに追加することができる。あなたのドミノアプリケーションでWebサービスを使うために必要なツールは、ドミノサーバとドミノデザイナーだけだ。サンプルプログラムはhttp://advisor.com/Articles.nsf/aid/DEVEG02で入手でき、ツールキットをhttp://www.alphaworks.ibm.comからダウンロードできる。

ロータスドミノはドミノのデータや機能を提供するJavaベースのWebサービスを稼動させることができる。WebSphereのようなJ2EEサーバ、適切なSOAPクラス群、そしてドミノのJavaオブジェクトを組み合わせることで、開発者は既存のドミノアプリケーションの好きな部分をWebサービス化することができる。それにはJavaの開発スキルとドミノのオブジェクトモデルについての知識が必要になる。IBMのWebSphereアプリケーションサーバは必要なSOAPクラスとともに出荷されており、WebSphere Studioの開発環境はWebサービスを作成、流用、管理、稼動させるためのウィザードを持っている。これによって開発者の生産性は向上し、開発者はWebアプリケーションとしてのドミノアプリケーションの本質的な部分の開発に集中することができる。

従来、J2EEアプリケーションは階層化アプリケーションモデルを利用してきた。一つのアプリケーションの主な要素はいくつかの構成要素に分割され、それぞれが別個の環境の中で独自の機能を実行する。もっとも単純な階層化モデルはプレゼンテーション・ロジック、アプリケーション・ロジック、データ蓄積の３つに分割される。それぞれの階層がアプリケーションの中の特定の機能を実行し、１つ以上のシステムに分散している。企業はアプリケーションの個々の要素をどんなタイプのハードウェアでも、また、どんな場所でも運用でき、業務に最大限の効果をもたらすことができる。

このような階層化モデルはアプリケーションを構築、稼動、再利用するときに価値のある柔軟性を提供します。このタイプのアーキテクチャに基づいてアプリケーションのプレゼンテーション・ロジック層は物理的にユーザに近い安価なハードウェア上に、アプリケーション・ロジック層は本社のより強力で高価なシステム上に、データベース層は数十年にわたって業務を運営してきたメインフレーム・システム上に置かれるかもしれない。これは極端な例だが、J2EEによる階層化モデルを利用したシステムではありうる例である。このモデルのもう一つの利点はアプリケーションの各要素を業務のほかの部分で活用するために容易に再利用できることだ。

ひとつの例を考えてみよう。在庫管理アプリケーションがこのモデルにもとづいて構築されており、倉庫にいくつの部品があるか、売上予測によれば製品を何個生産しなければならないかを生産ラインに知らせているとする。営業部門も倉庫にいくつの部品があるか、生産スケジュールはどうなっているのかを知る機能をこのアプリケーションに要求している。そうすれば営業部門は注文を満たすための顧客からの納期要求を設定できるからだ。生産管理アプリケーションの機能をコピーして新しい販売管理アプリケーションを開発するかわりに、生産管理アプリケーションのロジックを再利用し、新しい販売管理アプリケーションにつなげることができる。

J2EEアプリケーションサーバ

企業がJ2EEサーバ・プラットフォームに投資するとき、自社の環境に最適な製品を選択することはなかなか難しい。しかし選択肢はたくさんあってもすべてのJ2EEサーバの中核機能はどれも同じようなものである。これらJ2EEアプリケーション・サーバ・モデルの中核要素はJ2EEの仕様書で定義され、膨大なサービス群が提供されている。そのモデル上で稼動するアプリケーションはそれらのサービスを受けることもあるし、それらのサービスによって操作されることもある。サーバはさまざまなアプリケーション要素のライフサイクルを管理し、それらの要素の現況、文脈情報、現在のユーザにかんする認証情報、高度な複雑性をもつアプリケーションではデータ処理の文脈などを提供する。

J2EEの仕様はここまでだが、J2EEサーバ・ベンダーはサーバ製品を特定の顧客の環境にとってより魅力的で適切なものにすることもできる。したがってサーバベンダー各社はサーバが遵守しなければならない技術標準に影響を与えることなく、付加価値のある機能を開発することができる。したがってさまざまなベンダーのサーバ製品の開発モデルは類似しており、顧客はどのベンダーのJ2EEサーバからでも他のベンダーのサーバ製品に乗り換えて管理・開発スキルを活用することができる。

J2EEアプリケーション・サーバとドミノアプリケーション・サーバの主な違いはロータスドミノが完全に統合された環境を提供している点だ。アプリケーションの実行からユーザ認証、ディレクトリサービス、データ管理、プレゼンテーションのための表示機能などすべてを一つのシステムにおさめ、アプリケーション環境のほとんどすべての側面を取り扱っている。

J2EEモデルはまったく同じ情報をアプリケーションに提供するための要素をもっている点でドミノとは異なる。しかしJ2EEサーバはドミノサーバが満たしているすべての側面を満たすために存在しているわけではない。J2EEサーバは顧客の環境にある異なる部品を呼び出してデータやディレクトリ情報などの要求を満たす。例えばJ2EEの仕様はサーバがどのようにしてJDBCを使ってデータベースからデータをとってくるか、その概要を定めているが、J2EEはサーバ自身がデータベース管理機能を持っていることを要求してはいない。

アプリケーションとJ2EEの統合を可能にするドミノの機能

ドミノとJ2EEアプリケーションを組み合わせることでアプリケーションにとって数多くの利点を手に入れることができる。もっとも重要なのはJ2EE上に構築された拡張性のある業務アプリケーションに、社員どうしの協働作業を組み込むことである。ロータスドミノとJ2EEを基盤とするアプリケーションを統合するとき、ロータスドミノへの主なアクセス方法には次の２種類がある。

Java用ドミノ・オブジェクトは本質的はドミノのJava APIだ。これらのオブジェクトによって、作成・検索・更新・削除というCRUDとしてよく知られたデータベースの主要な処理のために、オブジェクトを基盤としてデータベースにアクセスすることができる。APIによってドミノのデータだけでなくユーザ登録、エージェント実行、メール送信その他主要なサービスも可能となる。

ドミノ６のカスタムJSPタグはJava Server Pageからしか利用できない。JSPタグはJSPに埋め込まれたXMLタグのことで、データへのアクセス、データ入力、処理の制御などの機能を提供する。これらのタグはJava用ドミノ・オブジェクトを抽象化し、ドミノのデータやサービスを利用するJ2EEアプリケーションを迅速に構築する機能を提供する。

ロータスドミノはまたJ2EEアプリケーションから利用可能な膨大なXML機能をもっている。J2EEアプリケーションは非定型のドミノ文書にアクセス可能なドミノのXMLインターフェースを利用することができる。そのインターフェースはロータスドミノに蓄積されているデータの仕様が分かっていなくてもよい。そしてJ2EEアプリケーションは結果として得られたXMLを処理し、アプリケーションに必要な特定のフォーマットに変換することもできる。アプリケーション側でロータスドミノのアップデートに対応する準備が整っているのであれば、その同じXMLインターフェースをXML経由でデータベースを更新するために再利用でき、そのようにしてロータスドミノのデータを出し入れする手段が提供される。

WebSphereアプリケーションサーバとドミノの統合

IBM社内ではドミノとWebSphereアプリケーションサーバのチームは顧客の要求する重要な統合ポイントを開発・出荷するために協調して努力している。これらの要素はそれぞれがシステムの使いやすさ、容易なシステム管理、情報基盤全体の統合といったニーズから派生している。JavaとJ2EEの技術標準によって散在したプリケーションをかなり広い範囲で統合できるのに対して、ロータスとWebSphereはドミノとWebSphereアプリケーションサーバでなければ利用できないような強力な統合ポイントを開発してきた。例えば．．．

この節ではIBMサーバ・プラットフォーム上で統合されたソリューションを立案するときに、考慮すべきさまざまな要素の理解を助けるための調査ツールとして使われることを意図して書かれた。この節はいろいろな機能領域を解説する部分にわかれている。各機能領域にはソリューションに最適なアーキテクチャ、つまりアプリケーションのどの部分にどの「車線」を選択して設計すればよいかを決定する要素を理解する手助けとなる質問があげられている。

この節は既存あるいは計画中のアプリケーションを思い描きつつ、以下の各質問に答えていくかたちで読み進めるとよい。

１．アプリケーションの目的と利用

アプリケーションの内容
アプリケーションに豊富な書式をもつコンテンツの編集、作成、表示がふくまれるか？

アプリケーション利用の大部分が、豊富な書式をもつテキストの作成・書き込み・更新・削除をふくむか、アプリケーションがマイクロソフト・オフィス文書の表示・蓄積・処理を必要とする場合、このようなアプリケーションはドミノの「車線」が最適である。さらに言えばロータスノーツをクライアントとして利用するのがもっとも適しているだろう。リッチテキスト編集機能とマイクロソフト・オフィスとの統合機能が組み込まれているからだ。

トランザクション処理
アプリケーションがトランザクション処理を行なうか？

トランザクション処理をおこなうアプリケーションはアプリケーション内で一連の処理段階が監視されており、必要ならその処理を完全にもとにもどすことができる。典型的な例が銀行のシステムだ。貸方の処理が完了しなかった場合は借方の処理はもとにもどす必要がある。トランザクション処理はWebSphereの「車線」が最適だ。業務上のトランザクションで起こる例外を解決するのに人間の関与が必要な場合は、協働作業サービスを提供するドミノアプリケーションと組み合わせるとよい。

ユーザ中心のフォーム駆動型ワークフロー
ワークフローのプロセスを完了するために、電子フォームを一連の定義済みステップにしたがって各ユーザに回覧する必要があるか？

具体例としては社員向けのセルフサービスのヘルプデスク・アプリケーションがある。社員は所定のフォームに自分で入力し、それを送信すると適切なヘルプデスクの専門家に電子メールが回送される。問題が解決すると完成された入力フォームは入力者に戻され、終了処理を行なう。終了処理の後入力フォームはヘルプデスクの履歴データベースにログとして蓄積される。これらのタイプのソリューションは比較的簡単にロータスドミノを使って構築することができる。電子メール用のAPIと、柔軟な役割ベースのユーザ定義、アクセス制御が組み込まれているためだ。さらに付加価値を高めたソリューションにはロータスドミノとWebSphereにIBMのMQシリーズを加えた構成となる。ロータスドミノをトランザクション処理のワークフローを支援するためのユーザ中心のフォーム駆動型ワークフローに利用する。WebSphereとMQシリーズはそのトランザクション処理の管理に最適である。このような社員から社員へのワークフロー・ソリューションは人間系の処理とシステムによるトランザクションを組み合わせたものであり、他のベンダーは単独でこのようなソリューションを提供することができない。

非接続（オフライン利用）
ネットワークから切断されたコンピュータからもアプリケーションの全機能を忠実に使う必要があるか？

アプリケーションの忠実性とは、オンラインでもオフラインでもデータの新規作成、編集、更新、削除を含めてすべての機能を忠実に再現できるということを示す。これはロータスドミノ特有の機能のひとつである。ドミノの複製機能だけがアプリケーションをオフラインにしながらもとの機能を忠実に再現でき、Webブラウザやロータスノーツ・クライアントからデータにアクセスすることができる。ユーザが再接続したとき、オフラインで行なった作業は完全にサーバと同期がとられる。これもロータスドミノにおいてだけ利用できる機能だ。

ノーツクライアントからのアクセス

ロータスノーツは電子メールやカレンダー、スケジュール管理、個人情報管理、そして独自の協働作業アプリケーションなど、協働作業を支援するアプリケーションにおいて、ユーザの熟練度を最大限に発揮できるデスクトップ環境を提供する。ロータスノーツはグラフィカルなウィンドウをもつユーザインターフェースと、協働作業や文書中心のアプリケーションを実行するための拡張性のあるクライアント・フレームワークを提供する。以下のリストはWebブラウザにはないロータスノーツ・クライアントの機能を示している。

アクセス制御
ユーザは自分の作業を誰かに代理させる必要があるか？

アプリケーションによっては、あるユーザに他のユーザのアクセス権を制御する権利を与える必要がある。これはあるユーザに他のユーザの代理として振舞わせる場合によく使われる方法で、同時に誰が何の代理をしたのか履歴を残しておく必要がある。典型的な例としてマネージャがアシスタントに責任を委譲する場合がある。アシスタントはマネージャとしてのアクセス権を持つことは許されないが、マネージャの代理としてのアクセス権を持つ必要がある。両者の違いは、業務監査の目的のために、アシスタントによる新規作成・編集・更新・削除の行為をマネージャによる行為とは別に記録する点にある。この機能はRDB本来のアクセス制御に依存しているため、WebSphereの「車線」ということになる。

ユーザのアクセス制御はフォーム内の表や項目の一部分に限定される必要があるか？

たとえばマネージャは「社員給与」表にアクセス権があるが、部下のデータしか見ることができない、などの場合である。同様にフォームを入力したユーザは一定の項目しか見ることができないが、マネージャは同じフォームを使いながらも追加の項目を見ることができるという場合もある。ロータスドミノは独自のセキュリティーモデルを持っており、アプリケーションやデータのごく小さな部分に対してもアクセス制御をかけることができる。アクセス制御はその場その場でプログラムによって変更することもでき、動的に変化する一連の条件にもとづいて誰が閲覧できるかを調整することができる。したがってこの機能はロータスドミノの「車線」に属しているが、WebSphereアプリケーションにも独自の価値を追加することができる。

動的に変化する役割ベースのユーザ定義が必要か？

ほとんどのアプリケーションはユーザ情報のグループ定義を利用する。しかし多くの場合グループ定義は個々のアプリケーションに固有のものだ。アプリケーション固有のグループ定義を全社のユーザ情報に蓄積するのは、管理が複雑になるため賢明ではない。したがってよりよいソリューションとして各ユーザの役割（ロール）をアプリケーションに組み込むことが考えられる。そしてその役割をアプリケーション用のデータの一部として蓄積し、現在ログイン中のユーザの役割を決定するロジックを書けばよいのだ。

役割を要求するアプリケーションの典型例は承認プロセスである。たとえば人事部の社員採用アプリケーションでは、給与の要求を承認するのは人事部長、経理部長、そして採用担当マネージャである。かれらのおのおのはユーザ定義上は異なるグループに属するが、給与承認権限をこれら各グループに与えるわけにはいかない。グループに属する人々は大人数になるためだ。だからといって新しく「給与承認グループ」を作成することはできない。採用担当マネージャは採用する人ごとに変わるからだ。したがってアプリケーション固有の役割（ロール）を作成し、ユーザをそのロールから出したり入れたりすることが問題解決法となる。役割に含まれるかどうかはアプリケーションのロジックによってその場その場で変わり、役割の管理はユーザ定義（システム）レベルではなくアプリケーション・レベルでなされる。したがってアプリケーション管理のオーバーヘッドを簡素化できる。このようなアプリケーション固有の動的な役割変更が必要なアプリケーションはロータスドミノの「車線」に最適だ。多くの人事ソリューションはJ2EEを基盤としているので、これはロータスドミノとWebSphereアプリケーションを統合するもう一つの長所となる。

２．拡張性の要求

ユーザ数
Webブラウザ経由の同時接続ユーザが5000人を超えているか？

Webアプリケーションの規模を決定するにはいくつかの要素がある。その一つがアクティブな同時接続ユーザ数だ。一般的な規則としてアクティブな同時接続ユーザ数が5000を超え、そのアプリケーションがロータスノーツ・クライアントではなくWebブラウザを使っているなら、WebSphereの「車線」に適しているということになる。

しかしもしそのアプリケーションがロータスノーツ・クライアントを使っている場合は、ロータスドミノを選択すること。ロータスノーツはクライアント／サーバ・アーキテクチャを利用しており、多くの処理がクライアント側で実行されるため、サーバにより大きな拡張性を許している。

拡張性のための基盤構成
水平方向の拡張性と垂直方向の拡張性のどちらが必要か？

適切なハードウェア構成はアプリケーションの拡張性と可用性を確保するための鍵となる。水平方向の拡張性とはアプリケーションを複数の物理的なサーバや、「ブレード」構成のサーバに分散させることを言う。垂直方向の拡張性とはより大規模なハードウェアや基本ソフト（OS）のプラットフォームにアップグレードすることを言う。現時点での拡張性と将来的な拡張性の両方を考慮しておく必要がある。WebSphereもロータスドミノも垂直方向の拡張性を利用できる。どちらも小型機のWindowsサーバから大型機のIBM eServer zシリーズまで、広範なハードウェアや基本ソフトをサポートしているためだ。

WebSphereについては水平方向の拡張性も持っている。WebSphereの主要な機能の一つとして、複数サーバに分散してアプリケーションを構成できる機能がある。これによって変化する稼働状況に合うように動的に負荷を調整することができる。

３．データの要求

データモデル
構造化されたデータモデルと構造化されないデータモデルのどちらが必要か？

データストレージにはいくつかのタイプがある。関係ストレージと階層化ストレージがこのホワイトペーパーに適用される２つのタイプである。関係ストレージは互いに「関連する」レコードどうしの多次元のリンクを維持する。階層化ストレージは比較的フラットな親子関係のモデルを使う。典型的には関係ストレージはレコード間に「多対多」の関係がある構造化されたデータにより適している。例えば顧客レコード、インボイス、発注データ、取引先レコードの間にあるリンクのようなものである。

階層化ストレージは文書、リスト、PowerPointによるプレゼンテーション、その他「自由な様式」の情報など、構造化されないデータにより適している。階層化データのもう一つの性質はデータ構造を変更できるという点である。例えばデータベースを再構築することなく項目を追加したり削除したりすることができる。階層化ストレージに固有なその他の性質には次のようなものがある。

多くのアプリケーションが関係データストレージと階層化データストレージの両方を必要としている。したがってこのことはおそらくロータスドミノとWebSphereの「車線」をまたがるアプリケーションを構築する最も強力な理由になる。ロータスドミノは構造化されないデータストアが組み込まれており、WebSphereは関係データベースシステムとの強力な接続性をもつ。

レコードシステムに直接アクセスする必要があるか？

レコードシステムとはレコードに唯一の値が存在するように強制する関係データベースの機能である。これは法律により規制を受ける業種、たとえば保険、医薬品などの業種で稼働する多くのアプリケーションに必要な機能である。この機能はWebSphereの「車線」に適する。ドミノの複製機能はレコードシステムと対立するためだ。

データ量
データ量は２GBを超えるか？

アプリケーションに必要なデータストレージの量はアーキテクチャを決定するための重要な要素である。ユーザが作成・編集・更新・削除（CRUD）処理にどれくらい関与するかや、検索機能に対する要求など、他のデータ関連の要素も関係してくる。ドミノR５の登場以来、もはやドミノデータベースのサイズに物理的な限界はなくなった。しかし大量のデータと高度なCRUD処理を管理するにはWebSphereの「車線」の方が適している。

しかし共通の例外として、文書などの構造化されないデータや、リッチテキストや高度な様式を持つ内容のデータをサポートする必要が出てくるが、それにはロータスドミノの「車線」が適している。この場合理想的なソリューションは統合されたソリューションを構築することだ。アプリケーションのデータを単一のデータベースに蓄積する必要がある場合は、ロータスEnterprise Integrator（LEI）でドミノのデータベースと関係データベースの同期をとることができる。

データ配布
アプリケーションのデータをWANやインターネット経由で複数のサーバに配布する必要があるか？

多くの場合、アプリケーションは分散した複数のサーバを横断して実行されるようなアーキテクチャを持つ。しかしデータだけはふつうデータの一貫性を保護する目的で中央に残される。しかしデータが配布される必要のある状況もある。特にアプリケーションがむらのある高価なネットワーク基盤のため、狭い通信帯域しかない地域で利用される場合だ。ときにデータの配布は分散データベース・キャッシングで実現されるが、これはデータの一貫性を損なう危険があり、とても高額で管理が複雑になる。ロータスドミノとロータスEnterprise Integratorはあらゆるタイプのデータをネットワーク経由で配布するのに理想的なソリューションを提供する。なぜならデータの一貫性、セキュリティー、そしてデータセットのすべてのインスタンスの同期を保証するからだ。構造化されないデータと関係データの両方をLEIを使って配布する方法は、ロータスドミノとWebSphereの「車線」をまたいでアプリケーションの要求を満たす典型的な例となる。

４．アプリケーションのライフサイクル

戦略と戦術
そのアプリケーションはどれくらい戦略性があるか？あるいは戦術的な、ピンポイントのソリューションか？

この質問はアプリケーションの目的とライフサイクルを評価するための質問だ。もしアプリケーションが５年以上にわたって利用できるライフサイクルを期待されているか、中核事業を支援するのに必要不可欠ならば、それは戦略的ということになる。

戦術的でピンポイントのソリューションとは、比較的短期間のプロジェクトや事業上の決断を支援するものである。短期的な戦術的ソリューションには、あまり使われないアプリケーションも含む。例えば１年に１回しか使われない人事管理の社員業績評価アプリケーションは、利用頻度が低く、中核事業の業務に直接の関係がないことから、戦術的なピンポイントのソリューションとされる。

ロータスドミノはその迅速なアプリケーション開発環境のために短期的な戦術的ソリューションに適している。なぜなら開発者は比較的短期間にアプリケーションを開発・配置することができるからだ。もしあなたの会社がロータスドミノ上でそのようなアプリケーションを稼働させているなら、それらのアプリケーションをJ2EE上で再設計することはお勧めできない。というのはその開発費用をまかなうだけの十分な効果が得られるとは考えにくいからだ。

一方、戦略的アプリケーションはつねにアプリケーションの全ライフサイクルを通じて最大限のリターンをもたらすように設計されるべきだ。したがってアプリケーションの寿命を注意深く調査し、このホワイトペーパーに書かれているさまざまな要素を考慮することが、戦略的なソリューションに最適な「車線」（複数の場合もある）を決定する手助けとなるはずだ。

開発期間
６か月以内に設計、機能拡張、開発、テスト、配置を行なう必要があるか？

たとえば社内監査の結果、ある部門が３か月でISO9000への対応を証明するためのチェンジマネージメントシステムを実装しなければならないとしよう。長期間にわたる開発サイクルを実施する時間はないが、そのソリューションなしにその部門はISO9000の認証を受けることができないとする。上述のようにロータスドミノの主要な利点の一つはそのRAD環境である。その他のアプリケーションサーバ・プラットフォームがアプリケーションの開発、テスト、配置に数ヶ月を要するのに対して、同じことを数週間のうちに実現できる。もちろんアプリケーションの複雑性によって必要な期間は変わってくるが、ロータスドミノに適したアプリケーションの多くは、特に開発者がロータスドミノに同梱される標準的なシステム・テンプレートを利用できる場合、比較的簡易にに構築することができる。

５．環境的な要素

企業におけるIT基盤の標準
IT戦略や企業統治の問題に従属したアプリケーションか？

多くのIT利用企業はシステム管理を簡素化し、サーバ統合により経費を削減するためにアプリケーション基盤に関して戦略的な意思決定を行なっている。ほとんどの企業がその戦略をアプリケーション・アーキテクチャとしてはJ2EE、ディレクトリサービスとしてはLDAP、データストレージとしては関係データベースという戦略にもとづいている。もりアプリケーション・アーキテクチャがそのような全社IT戦略に統治されているなら、おそらくWebSphereの「車線」に属するだろう。ただしロータスドミノはJ2EEプラットフォームではまだ利用できないさまざまな機能を実現するために必要とされるかもしれない。

注意すべきもう一つの要素はドミノディレクトリはLDAPディレクトリとしても設定できるということだ。したがって既存のドミノディレクトリはITポリシー、IT基盤、そしてそれらを支援する各種リソースの枠内にうまく適合するだろう。

すべてのITリソースが利用可能か？

アプリケーションの開発、配置、管理には、IT基盤（データベース、アプリケーションサーバ、ディレクトリ、セキュリティ）と、システム管理やディレクトリサービス、セキュリティー・アーキテクチャに必要な人的資源を含むオーバーヘッドがつねに発生する。

例えば、遠く離れた第三国の現場でアプリケーションを配置する必要があり、現地で十分なIT支援やWANの帯域を享受できない場合を考えてみよう。基盤上の制約に加えて、予算上の制約ももう一つの要素として存在する。例えばある事業部門が何らかのソリューションを必要としながら、ITに必要な経営資源に十分な資金を確保できない場合もある。これら２つの事例は、利用できるIT基盤や人的資源がないにもかかわらず、アプリケーションが事業上、正当な必要性がある場合の一例だ。

ロータスドミノが提供する完全に統合された（上記の「ドミノアプリケーションの価値」で述べたような）単独で稼動するアプリケーションサーバによって、これらの問題に対する最適なソリューションが得られるだろう。ロータスドミノはあなたの会社が多くのタイプのアプリケーションを構築、稼動、配置するのに必要なすべてを提供することができる。

アプリケーション開発スキル
ロータスノーツとJava開発運用スキルのどちらが利用可能か？

多くのアプリケーションは開発・保守のために開発者を必要とし、運用のためにシステム管理者を必要とする。アプリケーション・アーキテクチャは企業内で利用可能なスキルによって決定されることが多い。現時点で社員の採用や業者との契約を通じてどのような人的リソースを利用できるかの調査を行なうことは、どの「車線」を選択するかを決定するのに重要な要素になる。

J2EEアーキテクチャはもともとWebアプリケーションの開発全般、特にコラボレーション開発に性能の恩恵をもたらすものである。多くの顧客とアプリケーション提供企業はすでにこれらの恩恵を自社のシステムやソリューションに活用している。全体の傾向からするとJ2EEアーキテクチャの利用は膨大な成長をとげることが予想される。しかしこの急成長を容易にするためにはJ2EEアプリケーションやJ2EEサービスの開発がより広い開発者にアピールできるような特徴もつ必要がある。

J2EEアプリケーション開発ツールはアプリケーションを開発するコミュニティーに対して、これまでのように（一義的には企業向けのアプリケーションのプログラミングに特化している）社内IT部門にいるJava好きの開発者を超えて、事業としてWebアプリケーションを開発している開発者たちにもアピールできるようになる必要がある。そうなるためにはWebアプリケーション開発者がプログラム部品、データ、アプリケーションの業務ロジックを接続し、組み立てる作業を支援するRADツールの開発が必要であり、同時に彼らからJ2EEアーキテクチャの複雑さを遮断する必要がある。ロータスはRADツール利用者のニーズに対する理解から、ドミノデザイナーの開発で得られた専門知識を利用して、まずはIBMのJ2EEプラットフォームを目標とした初のJ2EE用RADツールを開発している。このプロジェクトは現在進行中であり、ロータスのe-WorkplaceとIBMのWebSphere技術者チームの共同開発作業である。

このプロジェクトは企業向けのWebアプリケーション開発者を利用者として想定している。彼らWebアプリケーション開発者はシステムプログラマーや企業システム開発者と違って、一般的に業務を実行する（つまり特定の職務機能を遂行する）利用形態をもつシステムを開発する。彼らにとってアプリケーションを定義づけるのは、アプリケーションの外観や処理の流れ、そしてアプリケーションの振る舞いである。これらの開発者は一般的にユーザインターフェース部分から始める。なぜなら彼らはアプリケーションをまずその見た目から考え始めるからだ。そして次にユーザインターフェースの上に振る舞いが付け加えられ、ページどうしがリンクされてアプリケーションの形をとる。

このような未来のRADツールは、J2EE環境を活用した表示機能の豊富なWebアプリケーションを容易に、視覚的なやり方で開発する手段を提供するだろう。しかしRADツールは確かにアプリケーションの簡単な開発を支援するけれども、単純なアプリケーションの開発に限定されないということが重要だ。つまりそのRADツールはアプリケーションの基礎を構築する迅速な方法を提供し、WebSphere Studioのツールを使ってアプリケーションのすべての細部にアクセスできるようにすることで完全なカスタマイズを実現する。それによって独立して作業する開発者にとっても快適な開発環境を与えるだろう。最後にこの未来のRADツールはオープンソース・フレームワークであるEclipseに準拠しており、IBMのWebSphere Studioファミリーで利用可能なツール群を、ページのデザイン、スクリプト編集、デバッグ、ビーン作成などなど多くの機能を流用するために使うことができる。ロータスはドミノデザイナーをロータスドミノ向けの複合型クライアントアプリケーション開発環境として機能拡張しつづける予定であり、WebSphere系のツールとの相互接続を容易にするユーティリティーを追加していく。

下図は現在サポートされているロータスのアプリケーション開発モデルと将来のモデルを、それぞれに関連する開発ツールとともに示している。

ロータスノーツ用のアプリケーションは現在ロータス製品を使ったカスタムアプリケーションの大部分を占めている。これらのアプリケーションは主にロータス・スクリプトとロータスの式言語で構築されている。

次に大きいアプリケーションモデルはWebブラウザや、ロータスノーツをWebブラウザの複合型ドミノアプリケーションだ。ロータスは顧客がこれらのアプリケーションを使っている限り、予見可能な将来にわたってこれらの開発モデルもサポートしつづける。

ドミノデザイナーはロータスノーツとドミノアプリケーションを構築するための開発ツールである。ドミノデザイナーは今後、特に統合されたアプリケーション開発や次世代コラボレーション・サービスの利用を可能にする機能に焦点を当てながら機能拡張を継続する。ドミノデザイナーをWebSphereやEclipseに統合する計画はない。ロータスノーツとドミノに特化したRADツールとして残るだろう。ロータスノーツ／ドミノR５ではロータスはJavaとCOMのために新しいAPIを追加することで開発モデルを拡張した。それらの新しいAPIは外部アプリケーションとの相互接続性にとって重要である。ロータスドミノ６では、ドミノとJ2EEアプリケーションを統合したアプリケーションを、ドミノJSPタグや拡張されたJavaクラスを利用して構築する機能が提供される。

このアプリケーション開発モデルは未来への足がかりとなり、次の２つのメリットを顧客に提供する。

ロータスはWebSphereアプリケーションの機能をドミノアプリケーションと統合したがっている開発者が、それを実現できるようなプラグインをWebSphere Studio 5 に提供する計画だ。このプラグインはWebSphere Studioの開発者にドミノデータベース内部の設計要素をのぞいたり、ドミノデザイナーを起動して、設計要素を変更したり、フォームやビューなどの基本的な要素をロータスドミノ６で提供されるJSPカスタムタグを使ってJSPにコピーする機能を提供する。

最初の節でも述べたように、将来の戦略はすべてのロータス製品に一貫したサービス指向のインターフェースを提供するような新しいアプリケーション開発モデルを導入し、JavaとWebサービス標準技術を基盤とする。J2EE向けの新しいRADツールはロータスの協働作業支援サービスをJ2EEアプリケーションに統合するための最善の方法となるだろう。

J2EEに注目が集まるにつれて（つまり次世代の「車線」がロータスドミノやWebSphereの「車線」と融合するにつれて）ドミノからできるだけ多くのものを引き出せるように、次のようなことを準備しておく必要がある。