Java Portals and Portlets

Java 世界有一个 JSR-286 标准，用于说明门户和 Portlet 应如何互操作：共享统一网页的软件组件。

似乎有许多门户实现。但是，是否存在可在其中运行的可互换 Portlet 的实时“市场”？从我在网上找到的内容来看，它看起来非常不平衡 - 所有门户都没有portlet。这就像有几十部Android手机而没有应用程序一样。

如果一个产品基于 JSR-286（或其某些实现），那么企业客户拥有一堆想要添加到门户中的 Portlet 的可能性有多大？

令我印象深刻的是，大多数企业已经拥有一个类似门户的页面，基于他们选择的ERP或CRM产品，他们的业务运行，甚至可能只是MS Outlook的“今天”页面。那么，如果我发布了一个面向企业客户的新产品，并且我使其成为一个门户（而不是一组 Portlet），那么我的客户放弃其现有的 IBM/SAP/Oracle 门户并使用我的门户作为新主页的可能性有多大？（我猜：不是很好。如果我把它变成一组符合 JSR-286 标准的 Portlet，我的客户会有没有办法托管主机 Portlet？（我猜：也不是很好）。

最后，JSR-286 似乎对 HTML+JavaScript 非常沉默，即门户和 Portlet 如何在浏览器中进行互操作。这一切都是关于基于Java的服务器端的东西，定义了一种在使用URL方面进行合作的方式，以便每次整页刷新都可以路由到正确的portlet。它似乎不承认现代的，丰富的AJAX方法。它只是顺便提到AJAX。

这篇博客文章（以及它下面的评论）提供了很多思考的食粮，似乎证实了我的怀疑：

专业的实践经验以及上述研究使我得出结论，门户架构缺乏足够的技术优势和显着功能，无法保证增加接受度。在实践中，很少有应用程序可以将自己限制在 Portlet 的孤立和不同的功能上，在企业级软件中放弃这种程度的体系结构控制是不现实的...门户架构成为主流技术的机会之窗不仅已经关闭，而且在很久以前就关闭了。

因此，总结一下这是一个更连贯的问题：在这一点上，通过在JSR-286上进行构建，我将获得什么实际价值？