Javaの世界には、ポータルとポートレットの相互運用方法に関するJSR-286標準があります。つまり、統合されたWebページを共有するソフトウェアコンポーネントです。
ポータルの実装はたくさんあるようです。しかし、それらの中で実行される交換可能なポートレットのライブ「マーケットプレイス」はありますか？Webを検索すると、非常に偏ったように見えます。すべてのポータルがあり、ポートレットはありません。まるで数十台のAndroidスマートフォンがあり、アプリがないようなものです。
製品がJSR-286（またはその実装）に基づいている場合、企業顧客がポータルに追加したい一連のポートレットを持っている可能性はどのくらいありますか？
ほとんどの企業は、ビジネスを実行しているERPまたはCRM製品の選択に基づいたポータルのようなページ、あるいはMSOutlookの「今日」のページをすでに持っていることに気づきます。したがって、企業顧客向けの新製品を出荷し、それを（一連のポートレットではなく）ポータルにすると、顧客が既存のIBM / SAP / Oracleポータルを放棄し、ポータルを新しいホームページとして使用する可能性はどのくらいありますか。 ？（私は推測しています：素晴らしいことではありません。）そして、それをJSR-286準拠のポートレットのセットにすると、顧客はホストポートレットをホストする方法を利用できるようになりますか？（私は推測しています：これも素晴らしいことではありません）。
最後に、JSR-286は、HTML + JavaScript、つまり、ポータルとポートレットがブラウザー内でどのように相互運用するかについてはかなり無言のようです。これはすべてJavaベースのサーバー側のものであり、URLの使用に協力して、各ページ全体の更新を正しいポートレットにルーティングできるようにする方法を定義します。現代的でリッチなAJAXアプローチを認めていないようです。ちなみにAJAXについてのみ言及しています。
このブログ投稿（およびその下のコメント）は、多くの思考の糧を提供し、私の疑いを裏付けているようです。
上記の調査に加えて専門的な実務経験から、ポータルアーキテクチャには、受け入れの増加を保証するのに十分な技術的利点と際立った機能が欠けているという結論に至りました。実際には、ポートレットの分離された異種の機能に制約できるアプリケーションはほとんどなく、エンタープライズレベルのソフトウェアでは、この程度のアーキテクチャ制御を放棄することは非現実的です...ポータルアーキテクチャの主流テクノロジーになる機会は閉じられただけではありません。しかし、かなり前に閉鎖されました。
したがって、これをより一貫性のある質問として要約すると、この時点でJSR-286を構築することで実際にどのような価値が得られるでしょうか。