Applied_MATSUDA Masaaki
m.mat****@appli*****
2007年 1月 22日 (月) 13:56:15 JST
TigerCatですー． >現在、J2 に Remote Portlet Application Deployer(RPAD) を >実装中なのですが、これによって、PALab のサイトから J2 に >ポートレットを直接配備できるようになります。ただ、現状、 要はポータルサーバのインストール後にオンラインでアプリを 導入してゆくかたちですね． >＃これで PALポータルも CMS ポートレット以外はバンドルしないで >＃済むので、ポートレットパックは廃止の方向で・・・ うーむ，オンラインでとれるからポートレットパックは不要かと いうと・・・普通はオフラインでもインストール時に導入でき るものが欲しい，というニーズはあるような気がします・・・ (例えばWindowsXP SP2のサービスパックがWindowsUpdateから オンラインでとれるんだけれども，パッチとしても実行可能な ものが配布されていたり，まぁCD-ROMでの配布もありますが.) といいつつも，個別のwarファイルは，各ポートレットのリリー スでそれぞれ配布されているわけですから，サイズのでかい ポートレットパックを維持管理していくのは確かに馬鹿らしい ですな・・・ RPADの仕組みや要件的に，想定外かも知れませんが，以下の 提案が盛り込まれてはいかがだろうかと思います． ・ RPAD的にPALで提供されているポートレット一覧のメタ データを取得し，そのポートレットをまとめてダウンロー ド＆アーカイブできる仕組みを用意する． これで出来たアーカイブが「ポートレットパック」です． なので，いわゆるクライアント側のダウンローダになっちまう のか，それともCGI等でこの機能を実装し結局ユーザからは普通 にブラウザからアーカイブ状態でダウンロードできたりするの かも知れませんけれど，企業等でポータルサーバとポートレット パックをCDに焼いたものを導入するような場合は，ダウンロード するときの担当者がポートレットパックを手配できるようにし， ポータルサーバのインストーラが今までみたいにポートレット パックを導入できるようになってるとばっちりそうです・・・ ていうか，いきなり話かわって， なんか今おもいついたんだけど， オンラインでポートレットを取れるようにするということは， ・バージョン管理 ・アップグレードインストール ・(ポートレット同士の依存性確認) あたりが心配になってしまいますが(えっと，LinuxのRPMみたい に)，どうなってしまうのでしょうかね． 特に，PAL的にはDBもポートレットに内蔵ですから，アップグレ ードでどっかんと，既存のポートレットDBがクリアされて ガカーリとか・・・，あと以前の話題にもあった，テーブル構造 がかわったときのいわゆるデータ移行をどうするか，なんてのも 思い出してしまう具合です． はい．
