隨筆 - 19, 文章 - 93, 評論 - 17, 引用 - 0

          導航

          <2025年6月>
          25262728293031
          1234567
          891011121314
          15161718192021
          22232425262728
          293012345

          常用鏈接

          留言簿(6)

          隨筆分類(22)

          隨筆檔案(19)

          文章分類(107)

          文章檔案(93)

          信息安全

          商業

          工作流同行

          心情朋友

          搜索引擎

          智能化商業應用

          規則引擎

          軟件系統設計學友

          軟安全技術同盟會

          搜索

          •  

          最新評論

          Portlet技術發展的思考

          ??????Portal 這個概念出現很長的時間了,然而Portal應用是直到最近這兩三年才蓬勃發展起來,這跟原來缺乏相關的規范有一定的關系。目前關于Portal方面存在兩個重要的標準,均是2003年下半年正式通過的,分別為:?
          ????????????1、Java Portlet Specification 1.0 (JSR168), 2003年10月27日?
          ????????????2、Web Services for Remote Portlets 1.0, 2003年9月3日?

          ??????這兩個規范發布之后,得到各個Portal產商的支持,特別是JSR168標準更是得到OpenSource界的大力支持。許多開源項目都聲稱支持JSR168標準,具體項目列表可以參考:Open Source Portal in Java。?

          ??????不過在對這些標準學習之后,我認識到除了實現一個支持標準的服務器之外,還有很多空間是值得我們去努力的。如果有人正在進行Portal方面的研究、實現,希望我的想法能夠有所幫助。

          Java Web Framework -> JSR168?
          ??????我學習JSR168這個規范后,我就認識到開始一個JSR168 Portlet不會是一件愉快的事情。JSR168 Portlet十分類似于Servlet,現在還有誰愿意只是基于Servlet來開發Web應用呢?更進一步的問題是:開發人員需要直接編寫JSR168 Portlet么?答案是不需要!?

          ??????所謂Portlet本身來說就是一個Web應用,只是運行在Portal才被稱為Portlet。業界已經有大量熟練的Java Web應用開發人員,讓他們去重新學習一種新的Web應用模式、并且只能運行在在Portal中是不現實的,正確的方式應該是能夠把普通的Java Web應用包裝成JSR168 Portlet。這樣開發人員依然按照原來的模式開發Web應用,只是在部署到Portal之前才包裝成JSR168 Portlet。目前許多Java Web應用都是基于某些Web Framework(例如Struts)來實現,因此可以考慮基于這些Web Framework的包裝方法。?

          ??????對于這個包裝器,我目前想到需要注意的地方有:
          1、URL轉換。Web應用中使用普通的URL,然而訪問一個Portlet的URL有其特殊的格式,因此需要把指向自身的URL全部轉換為Portlet格式。這些URL主要是HTML FORM中的ACTION屬性。

          2、Session范圍。Session在Portlet中分為PORTLET_SCOPE和APPLICATION_SCOPE兩種,為了避免沖突缺省情況下應該把Web應用中的Seesion變量都設置為PORTLET_SCOPE。

          3、開發人員透明。Web應用是否包裝為Portlet對Web應用本身不做更改,這樣即使被包裝為Portlet后,開發人員仍可當作普通的Web應用繼續開發。

          4、可選的Portlet特性。使得開發人員能夠在Web應用中使用Portlet特性,當Web應用獨立部署運行時這些特性自動失效,當部署到Portal中就可以利用到Portlet特性了。

          Common Web Application -> WSRP?

          ?????????WSRP規范致力于定義一個面向表示(presentation-oriented)的Web Services協議以及相應的接口集,面向表示的Web Services協議不僅提供商業邏輯還提供界面表示,應用程序可以容易的通過代理工具集成面向表示的Web Services。?

          ?????????在Portal應用中,經常有將現存的某個應用在Portal界面中顯示的需求,而且該應用是運行在與Portal服務器不同的機器上的。這種需求在Portal項目中使極為常見的,解決的方法主要有:1、如果應用提供java接口,可以建立JSR168 Portlet使用該接口;2、如果應用存在Web界面,則可通過Web裁減(Web Clipping)技術來集成,Kapow公司是這一技術的領先者;或者通過HTML IFRAME技術作簡單的集成。?

          ?????????WSRP規范出現后,我們有了更加方便的新選擇,如果應用本身支持WSRP,那么Portal服務器可以直接集成該應用無需額外開發。但是目前支持WSRP的應用還太少,而且期待現存的應用自身增加WSRP支持也是不現實的。例如對一個現存的部署在Apapche Http Server上的PHP應用,用戶當然希望無需對該應用進行任何更改就能夠支持WSRP。?

          ?????????我曾寫過一篇短文“WSRP實踐&想法”闡述這方面的想法。我最希望看到這樣的WSRP工具出現,安裝在Web服務器上后,通過配置就能夠將部署在該Web服務器上的應用以WSRP協議發布。

          這樣的工具主要的是兩部分的功能:?

          ??????1、當然是WSRP協議支持。可以參考已有的開源實現,我想其中的初期的重點是URL Wirting和Stateful Information,即URL的雙向轉換和狀態信息的處理。?

          ??????2、與現有應用的交互,可以從兩個方向來實現:?
          ?????????2.1 利用服務器功能,例如Java Servlet Server提供javax.servlet.RequestDispatcher接口實現來完成對本服務器上的資源調用。這樣做的優點的性能高效,缺點是不同的服務器要開發不同的版本;?

          ?????????2.2 采用類似HTTP Porxy的方式實現。優點是適應性強,不必理睬Web應用的具體實現、部署技術,缺點是性能會有影響。

          以上就是我的一些想法,希望盡快看到相關的產品出現,這些開發Portal應用就會輕松很多。

          posted on 2006-12-05 10:19 BPM 閱讀(497) 評論(0)  編輯  收藏 所屬分類: Portal

          主站蜘蛛池模板: 班戈县| 泰兴市| 石泉县| 乌恰县| 丹东市| 永仁县| 永新县| 微山县| 江津市| 攀枝花市| 闽清县| 石渠县| 龙陵县| 边坝县| 南开区| 留坝县| 永靖县| 澄迈县| 南木林县| 礼泉县| 桃源县| 长汀县| 津南区| 瑞丽市| 乐陵市| 杭锦后旗| 临猗县| 陕西省| 新巴尔虎右旗| 桐庐县| 错那县| 姜堰市| 竹北市| 平利县| 如东县| 巨野县| 施秉县| 佛坪县| 伊宁市| 青浦区| 绥化市|