続・企業ポータルの行方
本日も、過去に書いたブログからの再掲です。原著は2006/6/17です。
過去のログを再掲するのは、自分の考えてたことはどんなことだったかなぁ、というチェックのつもりですが、この論考は細目に入りすぎて全体感を見失った感が否めません。
====================================
前回の論考（企業ポータルの行方）http://d.hatena.ne.jp/tekitoubook/20060613/1150202371では、グループウェア概念から離れてポータル（企業内ポータル）の要件や見通しについて考えてみました。それ以前の論考からひきつづき、Webアプリケーション開発を行うことも前提においています。
この論考中、以下の４つの要件をあげました。
１．通信プロトコルとしてはHTTP（HTTPS）を使用する
２．使用するサービスのUIに統一感があること。（これは、ユーザビリティという面につながります。）
３．利用するサービスを個人が選択し、パーソナライズ可能であること。
４．各サービスへの認証が統一されていること（複数サーバーを使用する場合、シングルサインオン環境にあること）
しかしながら、論考中にもうひとつの要件
５．既存のアプリケーションの統合
という要件を加えるべきであることに気が付き、考察が中途半端になってしまった感がありました。
前回の論考では、
（１）．Web2.0に基づくポータル（Ajax+Feed）
（２）．Javaに基づくポータル（Feedを含むportlet群）
（３）．仮想デスクトップによるポータル
の３種類のポータルをあげておりました。
Notes/Dominoやサイボーズといった切り口で考察を行わないのは、一般的な技術論（ベンダーに固有の実装ではない）を展開したかったためと、オープンソースの興隆やナレッジマネージメントの（一般的な）挫折を背景にして、商用ツールのライセンスコストといったものが、経営面から見て、今後大きく問題視されると思っているためです。
したがいまして、Ajaxであるとかシンジケーションといったこと、また、オープンソースでの実装（Apache portal project や x-Desktopなど）については、考察の対象とします。
また、４については基本的にHttpサーバーによる認証を前提に考えると、あまり重要ではないということにも気が付きました。apacheを前提に考えると、１サーバーをreverse proxyにして基本認証を引き継ぐこともできますし、LDAP認証を採用すれば自ずとSSOということになります。また、フォーム認証を採用した既存モジュールについても、HttpClientがPHPやJavaのモジュール（PEARやJakarta-commons）として提供されていますので、これらを間に挟むことで技術的には解消可能です（古いアプリケーションで、フォーム認証が認証が使われているケースがよくありますが、これは機構やセキュリティー的な対処というよりも、「閉じたユーザーマスタテーブル」を作った方が楽という安易な実装によるものが多いように思います。こういった場合であれば、基本認証やLDAP認証に変えてしまうことも可能でしょう）。
まず、誤解をさけるために申しますと、これらは補完的な技術群であってどれが優位であるかという議論は無意味であるということです。
これらのうち、まず、もっとも歴史的に早く注目を集めたのは（２）のJava Portletではなかったかと思います。
ですが、雑誌などで、CMS（コンテンツ・マネージメント・システム）という括りで、XoopsやPloneといったものと同列で紹介されたりしました。
前回にも書きましたが、仕事で一度JetSpeedの（たしか）1.5をつかったことがありますが、かなり完成度の高いプロダクトであったと記憶しています。
タブやメニューといったレイアウトの切り替え、スキンの切り替えが管理UIから可能であったり、パーソナライズ化もデフォルト、ロールベース、個人ベースで可能でした。
ですが、惜しむらくは「時代を先取りしすぎていた」という点であったのではないかと思います。
といいますのも、ポートレットという形でJavaプログラムを作成する際にJetSpeed固有の特殊なスーパークラスを作らなければならなかったり、ポートレットという「小さい画面」での提供するような情報とは「どういったものなのか？」といった部分で、それが創造できない部分がありました（シンジケーションといったことが。注目される以前の話ですので）。
IFRAMEポートレットというのがありまして、これはその名の通りポートレットとしてIFRAMEタグを使うという簡単な発想のものですしたが、これには「機能の統合」という面で大変重宝しました（似たポートレットにBasicAuthenticateIFrameというのがありましたが、これはMS社のセキュリティーパッチによって使えないという残念な部分もありました）。
仕事では、JetSpeedにXoopsを抱き合わせた形でポータルを構築しましたが、完全な冗長化構成をとって現在も稼動しています。
JSR168の参照実装がPluteという（当時はどんなツールかすら分かりませんでした）ものとなった理由は分かりませんが、やはり、完成度が高すぎたせいでしょうか？
現在はJetSpeed2となっており、（インストールしかしてませんが）だいぶ様相が違ったものになっているような感じです。
シンジケーションがWeb2.0として注目されている現在、Java言語の汎用性とあわせるとポータルとしては、再度注目すべきプロダクトだと思っています。
また、（３）のx-Desktopは非常に秀逸なツールだと思っています。
現在、V1.5をつかってパーソナライズ化の追加実装を試していますが、それなりによい感触を得ています。
Ajaxで、PHP＋MySQLと連動させるように実装しているのですが、メニューのパーソナライズ化についてはほぼ問題なく追加できそうです。
唯一気になるのは、ブラウザーの「更新ボタン」で、これを押すと「すべてのサブ画面に」影響が及んでしまいます。「戻るボタン」は、きちんとz-indexによって制御されていますので、きちんと機能するようです。
これは、ブラウザーというHttpクライアントの特性ですので、仮想デスクトップの全体的な問題なのかもしれません。（他は知りません）
それでは（１）のAjax＋Feed技術はどうでしょうか？
まず思うのが、これだけではポータルとはなりえないということだということです。
とくに２の要件にフォーカスされたパターンですが、この組み合わせだけですと、あくまで「新しいニュースリーダー」程度の役割しか果たせません（つまり、パーソナライズ＝購読紙の選択という意味で、現在のGoogleのパーソナライズなどはこういったイメージです）。
また、Web2.0という軸でマッシュアップという言葉を耳にすることが多くなりましたが、基本的にはWebサービスを使った統合というようなことで、既存のアプリを移行するとなると、かなりのコストがかかります。Webサービスが注目を集めてから久しいというのに、なぜ、マッシュアップであるとか、SOAであるとか言う言葉ばかりでてくるのか理解できません（特に後者はIBMを筆頭とするベンダー主導型の概念という印象が強いですね）。
Webサービスも規格の統一化やセキュリティ、分散トランザクション管理など細目の数と規格が大きくなりすぎて、いずれCALSのようになってしまうのではと危惧しています。
（１）については、Web2.0という概念によって、「小さい画面での情報提供の一般フォーマットが、シンジケーション（RSS）という形で標準化された」と捉えるのが無難だと思います。
こうした理解の上で、好みによって（２）、（３）などを実装してみるのが、現時点では、もっとも無難な選択であるように思います。
