Java世界对于门户和portlet应如何互操作有一个JSR-286 standard：共享统一网页的软件组件。
似乎有许多门户网站实施。但是，是否存在可互换的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。
This blog post (and the comments under it)提供了许多值得思考的东西，似乎证实了我的怀疑：
专业的实践经验 通过上述研究引领我走向了 结论是门户网站 建筑缺乏足够的技术 优点和特色 保证接受度增加。 实际上，很少有应用程序可以 限制自己孤立 和不同的功能 portlet，放弃这个 建筑控制程度 企业级的不切实际的 软件......门户架构 成为一个机会的窗口 主流技术不仅仅是 关闭，但关闭了一段时间 前。
所以总结一下这是一个更连贯的问题：我现在在JSR-286的基础上获得了什么实际价值？
答案 0 :(得分：5)
我所知道的唯一优势是，当企业软件供应商在其功能清单上有“门户集成”时，通常意味着他们根据JSR-168或JSR-286标准编写了portlet。 SAP，Banner和Magnolia是我们在这里以这种方式工作的一些系统，有些组织在门户网站方法中找到了价值。
但是，正如您正确指出的那样，这对应用程序作者施加了一些令人沮丧的限制。我们还发现门户网站的价值在单点登录系统旁边有些可疑，这可以为用户节省签名到多个应用程序的麻烦，但仍然允许每个应用程序充分利用浏览器环境。< / p>
FWIW，如果你决定将你的工作分发为portlet的集合，那么现有的门户系统是免费/开源的，你可以为那些还没有portlet容器的人提供这些系统：
http://java-source.net/open-source/portals
希望所有这一切都有所帮助。