Java門戶和Portlet

Question

Java世界有一個JSR-286 standard關於門戶和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。

This blog post (and the comments under it)已經提供了思考了很多食物，似乎證實了我的懷疑：

專業動手上述研究沿 經歷促使我 結論，即門戶 架構缺乏足夠的技術 好處和區別特徵 保證接受的增加。 在實踐中，很少有應用程序可以 約束自己孤立 和 portlet的不同功能，並且放棄這個 程度的建築控制在企業級 不現實 軟件...門戶網站架構的機會 窗口成爲 的主流技術已經不僅關閉了 ，而且關閉了相當一段時間 前。

因此，總結這是一個更連貫的問題：通過在此基礎上構建JSR-286，我可以獲得什麼實際價值？

Answer 1

我非常瞭解的唯一優點是，當企業軟件供應商在其功能清單上有「門戶集成」時，通常意味着他們已經根據JSR-168或JSR-286標準編寫了portlet。 SAP，Banner和Magnolia是我們在這裏使用的一些系統，它們以這種方式工作，並且一些組織在門戶方法中發現了價值。

但是，正如您正確指出的那樣，這會對應用程序作者造成一些令人沮喪的限制。我們還發現，在單點登錄系統旁邊，門戶的價值有點令人懷疑，這樣可以使用戶省去登錄多個應用程序的麻煩，但仍然允許每個應用程序充分利用瀏覽器環境。

FWIW，如果你決定分配你的工作作爲portlet的集合，也有現有的是自由/開源，你可以爲誰不已經有一個portlet容器鄉親門戶系統：

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

希望所有這些都有所幫助。