The concept of Portal has a long time, but Portal applications are until the past two three years flourish, which has a certain relationship with the lack of relevant specifications. At present, there are two important standards in Portal, all of which are officially passed in the second half of 2003, respectively: 1, Java Portlet Specification 1.0 (JSR168), October 27, 2003 2, Web Services for Remote Portlets 1.0, 2003 After the two specification released on September 3, it was supported by various Portal manufacturers, especially JSR168 standards, more supported by the OpenSource. Many open source projects claim to support JSR168 standards, and specific items list can be referred to: Open Source Portal in Java. However, after learning these standards, I realized that in addition to achieving a standard server, there are still many spaces worthy of our efforts. If someone is performing research, implementation, I hope that my thoughts can help. Java Web Framework -> JSR168 I learned that JSR168 specification, I realize that a JSR168 portlet will not be a pleasant thing. JSR168 portlet is very similar to servlet, and who is willing to develop web applications based on servlet? Further problem is: Do developers need to write JSR168 portlets directly? The answer is not required! The so-called portlet itself is a web application, just running in Portal as a portlet. The industry has a large number of skilled Java web application developers, let them re-learn a new web application model, and can only run in Portal, correct, correct way should be able to apply ordinary Java web applications Packed in JSR168 portlet. This developers still develop web applications in accordance with the original model, just packaged into JSR168 portlets before deploying to Portal. Many Java web applications are implemented based on certain Web Framework (e.g., Struts), so the packaging method based on these Web Framework can be considered. For this wrapper, I don't think about what you need to pay attention to: 1, URL conversion. Using a normal URL in a web application, however, accesses a portlet's URL has its special format, so you need to convert all the URLs to the portlet format. These URLs are mainly an action attribute in the HTML Form. 2, session range. SESSION is divided into portlet_scope and application_scope in the portlet. To avoid conflicts default, the SEESInd variables in the web application should be set to portlet_scope. 3. Developers transparent. Whether the web application is packaged for portlet does not make changes to the web app itself, so that even after being packaged for portlet, developers can continue to develop as a normal web application. 4, optional portlet features. Make developers to use portlet features in web applications, which automatically invalidates when the web application is independently deployed, and the portlet feature can be utilized when deploying to Portal. CommON Web Application -> WSRP WSRP specification is committed to defining a Web Services protocol that represents Presentation-Oriented and the corresponding interface set, but-oriented Web Services protocols not only provide business logic, but also provide interface representations. Applications can be passed Agent tool integrates the representation of Web Services.
