Java门户和Portlet

内容来源于 Stack Overflow,并遵循CC BY-SA 3.0许可协议进行翻译与使用

  • 回答 (1)
  • 关注 (0)
  • 查看 (27)

Java世界有一个关于门户和portlet应该如何互操作的JSR-286标准:共享统一网页的软件组件。

似乎有一些门户实施。但是,有没有一个可以在其中运行的可互换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,我可以获得什么实际价值?

提问于
用户回答回答于

我所知道的唯一好处是,当企业软件供应商在其功能清单上有“portal integration”时,通常意味着他们已经根据JSR-168或JSR-286标准编写了portlet。SAP,Banner和Magnolia是我们在这里使用的一些系统,它们以这种方式工作,并且一些组织在门户方法中发现了价值。

但是,正如您正确指出的那样,这会对应用程序作者造成一些令人沮丧的限制。我们还发现,在单点登录系统旁边,门户的价值有点令人怀疑,这样可以让用户省去登录多个应用程序的麻烦,但仍然允许每个应用程序充分利用浏览器环境。

FWIW,如果您决定将您的工作作为一组portlet进行分发,那么现有的门户系统是免费/开源的,您可以为尚未拥有portlet容器的人员提供这些门户系统:

http://java-source.net/open-source/portals

扫码关注云+社区