Java 门户和 Portlet
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 上构建我会获得什么实际价值？
The Java world has a JSR-286 standard for how portals and portlets should interoperate: software components sharing a unified web page.
There seem to be a number of portal implementations. But is there a live "marketplace" of interchangeable portlets that will run in them? From what I can find searching the web, it looks very lopsided - all portals and no portlets. It's like if there were dozens of Android phones and no apps.
If a product were to base itself on JSR-286 (or some implementation thereof), what's the likelihood of a corporate customer having a bunch of portlets that it might want to add to the portal?
It strikes me that most corporates will already have a portal-like page based on their choice of ERP or CRM product that their business runs on, or maybe even just MS Outlook's "Today" page. So if I ship a new product intended for corporate customers, and I make it a portal (rather than a set of portlets) what is the likelihood of my customers abandoning their existing IBM/SAP/Oracle portal and using my portal as their new homepage? (I'm guessing: not great.) And if I make it a set of JSR-286 compliant portlets, are my customers going to have a way to host host portlets? (I'm guessing: also not great).
Finally, JSR-286 seems quite mute about HTML+JavaScript, i.e. how portals and portlets would interoperate inside the browser. It's all about Java-based server-side stuff, defining a way to cooperate in the use of URLs so that each full-page-refresh can be routed to the correct portlet. It doesn't seem to acknowledge the modern, rich AJAX approach. It mentions AJAX only in passing.
This blog post (and the comments under it) have provided a lot of food for thought and seem to confirm my suspicions:
Professional hands-on experience along
with the above research led me to the
conclusion that the portal
architecture lacks enough technical
advantages and distinguishing features
to warrant an increase in acceptance.
In practice, few applications can
constrain themselves to the isolated
and disparate functionality of
portlets, and relinquishing this
degree of architectural control is
unrealistic in enterprise-level
software... the portal architecture's
window of opportunity to become a
mainstream technology has not only
closed, but closed quite some time
ago.
So to summarise this as a more coherent question: what actual value would I get by building on JSR-286 at this point?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我所知道的唯一优势是，当企业软件供应商的功能清单上有“门户集成”时，通常意味着他们已经根据 JSR-168 或 JSR-286 标准编写了 portlet。 SAP、Banner 和 Magnolia 是我们在这里使用的一些以这种方式工作的系统，一些组织发现了门户方法的价值。
然而，正如您正确指出的那样，这给应用程序作者带来了一些令人沮丧的限制。我们还发现，当将门户放在单点登录系统旁边时，它的价值有些可疑，该系统可以为用户省去登录多个应用程序的麻烦，但仍然允许每个应用程序充分享受浏览器环境的好处。
FWIW，如果您决定将您的工作作为 portlet 集合进行分发，那么您可以为还没有 portlet 容器的人们提供免费/开源的现有门户系统：
http://java-source.net/open-source/portals
希望所有这些有所帮助。
The only advantage I know of offhand is that when vendors of enterprise software have "portal integration" on their feature checklist, it usually means they've written portlets according to the JSR-168 or JSR-286 standards. SAP, Banner, and Magnolia are some of the systems that we use here that work this way, and some organizations find value in the portal approach.
However, as you correctly point out, this imposes some frustrating limitations on the application author. We've also found the value of portals to be somewhat dubious when put up next to a Single Sign On system that saves the user the hassle of signing into multiple applications, but which still allows each application the full benefits of the browser environment.
FWIW, if you do decide to distribute your work as a collection of portlets, there are existing portal systems that are free/open source which you could provide for folks who didn't already have a portlet container:
http://java-source.net/open-source/portals
Hope all of that helps a bit.