企業ポータルの行方
本日も、過去に書いたブログからの再掲です。原著は2006/6/13です。
====================================
ポータル（portal）は英語で「入り口」という意味です。
インターネットポータルといえば、yahooやgoogleが代名詞的な存在となっていますが(というよりも、yahooなどの企業の検索サービス画面をポータルと呼び始めたのだと記憶しています)、企業ポータルといえば、「社員が仕事を始める際にまず開く画面のこと」を意味していて、グループウェアと同義で用いられている場合が多いと思います。
グループウェアについては、先日の論考で取り上げましたので、Webアプリ開発における基本的な考え方を簡単にまとめておきたいと思います。
（１）「お知らせ」や「施設予約」といった（殆どカスタマイズ不要であるもの）は、全社共通。
（２）「スケジュール管理」、「ToDoリスト」、「ファイル共有」、「ワークフロー」といった「仕事に固有なもの」はプロジェクトで選択する。
また、現時点、Mailアカウントや従業員属性は、全社LDAPで管理するのが一般的かつベストプラクティスだと思いますが、企業間、国家間をまたがるプロジェクトを前提にする我々には、WANの中にあるというデメリットがあります。
したがって、前回までの論考で、ホスティングサービスをベースとしたネットワークトポロジーなどへの移行、ACLの決定権限のプロジェクト管理者への移行が時代の潮流にあうのではないか、と考察したわけです。
当たり前の話ですが、これは完全にWAN内の全社LDAPやメイルサーバーを否定しているものではなく、あくまで、プロジェクトの効率的遂行のために、主体をWANの外におくということです。（名刺に書かれるMail Addressのドメイン名が会社のものでないと信用問題になるかもしれませんし、また、ホスティングは、あくまでもプロジェクトがLiveの間だけ活用することを前提とすべきと考えるためです）
ホスティングサービスを活用する場合、（２）についてはホスティングサービスの提供するツールで十分間に合うこともありえます。DMZを中心としたトポロジーでは、ホスティングサービスが提供する以上のサービスを社内に構成する必要があります。
話が少しそれてしまった感がありますが、ポータルは「こういったネットワークトポロジーとグループウェア概念にマッチした入り口」である必要があると言えます。
企業ポータルについては、IBM社、サイボーズ社など（やはり、グループウェアベンダー）が商用のツール群を売り出していますが、とりあえず、上記以外の要件についても要件を考えてみましょう。
まず、最初に言えるのが、
１．通信プロトコルとしてはHTTP（HTTPS）を使用する
ということです。これは、インターネットを最大限に活用したコラボレーションを行うという、我々の基本姿勢から導かれます。今回の場合、特に企業内からインターネットへ出て行く際に、既存のproxy,FWをクリアできるといってもいいでしょう。
次に、
２．使用するサービスのUIに統一感があること。（これは、ユーザビリティという面につながります。）
３．利用するサービスを個人が選択し、パーソナライズ可能であること。
４．各サービスへの認証が統一されていること（複数サーバーを使用する場合、シングルサインオン環境にあること）
といったことも挙げられます。
それでは、どこにポータルサーバーをおくのか？
第一候補地は、DMZ（FWの裏側）と思われます。
なぜなら、そうすることで社外のサイトへのアクセス、社内の特定サーバーへのアクセスが最低限守られた状態で可能になるからです。
次に、これらを支える技術基盤をみてみましょう。
まず、Gooleのパーソナライズ、YahooのMy Yahooなどのように、Web2.0というカテゴリーで分類される技術を基盤としているポータルがあります。これらは、RSSによるFeed技術、Ajaxによるリッチクライアント技術、Webサービスによるマッシュアップといった要素が基盤になっています。
GoogleやYahooは無償でパーソナライズされたUIを提供してくれていますが、Feedされる情報もますますパーソナライズ化が進んでくると思われます。特に企業ポータルにおいては、（パーソナライズ化されたUIに対して）「個人宛のFeed」の利用がますます増えるでしょう。
これに対して、Javaの世界におけるポータル技術の状況について見てみると、JSR168においてポートレット（ポータルのためのJavaプログラム）の仕様が2003/10/16（つまり、4年近くも前に）にPublic Reviewが終了しています。
この仕様の参照実装はApacheプロジェクトのPlute（http://portals.apache.org/pluto/）というプロダクトとなっていますが、Apacheプロジェクトには古株のJetSpeed（http://portals.apache.org/jetspeed-2/）というポータルツールが存在します（JetSpeedもJSRへの準拠を表明しています）。
私も仕事でJetSpeed1.5（現在の最新版はJetSpeed2）を使ったことがありますが、既存のWebアプリを、簡単にタブつきのメニューに入れられるなど、既存アプリの統合ツールとしては非常に重宝でした。Web2.0でいう「Webサービスによるマッシュアップ」は、（SOAもまたそうであるように）導入に大変なコストのかかる技術であると思いますので、こういった「簡易な形式でのポータル」のメリットは十分あります。
また、プロダクトとしては、当然、個人別のUIの構築も可能ですし、apache + tomcat上のアプリケーションとして動作しますので、apache間で認証（基本認証）を連携することが可能です。
しかしながら、これらの技術は、残念ながら我々の目には本流と一致しないものに写ります。
JetSpeedに限って言えば、Feed用のポートレット（雛形）も予め用意されていますし、Javaの言語特性上、応用の可能性は無限に広いのですが、逆に広すぎるのかもしれません。
また、簡易に既存のWebアプリを統合する方法としては、最近Ajaxの関連で注目され始めた「ブラウザー上の仮想デスクトップ」を使用することも考えられます。
eGroupware（http://www.egroupware.org/）とx-desktop（http://x-desktop.org/）を組み合わせた、idots2(http://www.idots2.org/)のデモをご覧になって驚かれた方も多いと思います。これは極端な実装としても、ブラウザー上の仮想デスクトップについて、ある程度の成果があがっていることの明確な証拠となっています。
特に基盤となっているx-desktopは秀逸なソフトウェアで、「仮想的なブラウザーをブラウザー内に起動する」ことができます。筆者も試してみましたが、導入が簡単（Httpサーバーのドキュメントルートに展開するだけ）な上にデモアプリ（インストール後にすぐ実行可能）のカスタマイズも比較的容易です。
筆者は試していませんが、この仮想ブラウザーに対してFeedをすることも可能だろうと思われます。
また、この場合もapache間で認証（基本認証）を連携することも可能ですので、この技術によって入り口を統合するのも十分メリットがあると考えられます（難を言えば、立ち上げる仮想ブラウザーの数が多くなりすぎると、重たくなってしまいます）。
このように、Web2.0に基づくポータル（Ajax+Feed）、Javaに基づくポータル（Feedを含むportlet群）、仮想デスクトップによるポータルと、微妙に趣向の異なった技術のどれが優位にたつのか？
それとも、これらを混ぜ合わせたものになるのか？？
現時点では、（google、yahooの影響で）Web2.0が有望のように見えますが、既存資源活用の容易さの面で後者も捨てがたく、目が離せないところです。
