使用Pluto與Maven2進行Portlet開發

昨天實作並整理出了一使用Maven2進行Portlets開發的文章，目前用於開發使用的是Pluto的Portal實作。

會基於這樣的實作其原因是，在目前業界所開發的系統來說除了部分產品外，其他不外乎是一些專案的開發，而在專案的開發中多數實作的都是客製化的系統，當然就會有客製化的權限控管、客製化的LayerOut…客製化的…反覆都開發這些東西，老實說…很煩。

而當企業有了許許多多的系統之後，將會發現，每一個系統都要進行一次的登入，每一個系統都是管理個自的權限，進入不同的系統都要再開啟一次瀏覽器，腦袋中要記錄不同的系統的連結網址…老實說也很煩。

為了解決這些混亂的狀況，有什麼解決的辦法，我想該是拿出Portal的時候了吧！
在一些比較知名的Open Source Portal Server上，都有實作了不錯的權限控管機制(也許開始會有人說，那些權限管理的機制不符合我們的需要)，不過試想一下，目前在業界中一些所謂的權限管理的分析是誰提出來的，通常來說是由使用者單位提出，然後由經驗不足，沒有OOA、OOD能力的SA或SD所設計出來的(抱歉！不是一竿子打翻一船人，而是大多數情況皆是如此)，而且大多數是由1~2個人就決定了權限的控管，那…各位覺得這樣的權限控管機制可靠嗎、彈性嗎、完完全全符合客戶需要嗎？

在開放原始碼的領域中，許多規格都是大家一起討論出來的，而在實作的Project上也進行了多次的進化，分析、分析再分析；抽象抽象再抽象。因此當我們真正認真去看這些看不懂程式碼的開放原始碼系統時將會發現，原來很多不了解的觀念都能得到解答，得到更佳的設計模式。

再 權限管理的部分亦是如此，經由多次進化的權限控管邏輯，在開放原始碼的社群中將演化成一種分析、設計模式，以應因未來各種不同的挑戰。因此這些權限控管機 制將會做到非常彈性，以符合大部分業界所需要，因此在我來說，我會建議，相關的分析、開發、設計人員盡其心力去了解這些設計理念，並將企業內部所需的權限 管理相關邏輯轉化為與其相近，你將會發現你得到的更多。而且還會發生一種有趣的狀況，以往當我們的企業邏輯做了修改(即便是小幅度的修正)，程式卻幾乎難以進行維護，因為程式大部分是由資淺人員所開發，而開發過程中幾近是寫死的，高度藕合性、低度內聚力。維護非常困難。使用了開放原始碼的權限控管系統將會發現，程式很少修改，甚至於只需進行簡單的設定或完全不需調整即可符合需要，非常不可思議。

而網頁的LayerOut呢？之前我們都使用Tiles或Sitemesh進行版面的設定與管理，但在Portal的使用上，LayerOut是由Portal進行統一的設定，不同的人登入可設定自定的版面設定，實際上的LayerOut應該來說…很少。將所有系統整合入Portal中只需登入一次即可使用各種不同的系統，這種夢想化的生活真是非常方便。

扯太多了，有時似乎文思泉湧就會扯出一大堆東西，回歸我所要表達的，Portal雖然方便，但開發Portlet並不容易，並且測試也不方便，每一次的測試都必須啟動一次Portal Server，Portal並不是小程式，每一次的啟動與關閉是非常花時間的，因此若有一個Portal平台啟動快速、方便測試相對的開發就會比較方便。而Pluto正符合我的需要，Pluto嚴格說並不能稱為Portal，只能稱為Portal最簡單的實作參考。但因為符合JSR-168的規範，我們可以將符合該規範的Portlet佈署在其上進行測試，當測試成功後再行佈署於所需的目的Portal Server上即可達成開發快速、測試方便的要求。

接著以下的觀念比較主觀，不認同的人可以不接受，就是事實上若使用不到所有的Portal的功能的話也可以將Portal降級使用，用來開發一般的系統，只是該系統中的所有程式基本上都是Portlet，因此未來當真正進入Portal時代時，程式只需小幅修正即可重用。

目前在我的王道中，Portal將會列入一個考量重點，並盡可能達到開發出的程式系統能符合下列要求：

1. 在一般系統中能正常執行。

2. 在Portal中加入相關繼承或Bridge即可在Portal上執行。

3. 能在一般系統與Portal系統中進行功能性測試。