Portal A portal is a Web-based application that provides personalization, single sign-on, and content aggregation from different sources, and hosts the presentation layer of information systems. Aggregation is the process of integrating content from different sources within a Webpage. A portal may have sophisticated personalization features to provide customized content to users. Portal pages may have different sets of portlets creating content for different users.
|Published (Last):||25 November 2013|
|PDF File Size:||1.23 Mb|
|ePub File Size:||10.76 Mb|
|Price:||Free* [*Free Regsitration Required]|
Section 2: Request 2. It will also address how the security and personalization is handled. Portlets are web components -like Servlets- specifically designed to be aggregated in the context of a composite page.
Usually, many Portlets are invoked to in the single request of a Portal page. Each Portlet produces a fragment of markup that it s combined with the markup of other Portlets, all within the Portal page markup. The Portlet specification will define the different components for Portal Computing, their interaction, lifecycle and semantics.
In addition, APIs for vendor extensions, APIs for security, user customization and layout management will be considered. Also, it will define the minimum set of possible window states for a Portlet such as normal, minimized, maximized, etc. This first version of the Portlet specification will concentrate in the following design goals: Client agnostic Support for multiple types of clients multi-device Simple Portlet API Support for Localization and Internationalization Hot deployment and re-deployment of Portal applications Declarative security same as to the mechanism found in Servlet and EJB specs Architected to support remote execution of Portlets The Portlet specification will be based on the Servlet specification.
The Portlet specification will restrict the use of functions provided by the Servlet API to a subset that makes sense for components providing fragments of a markup page. The API will provide a URL-rewriting mechanism for creating links to trigger actions within a Portlet without requiring knowledge on how URLs are structured in the particular web application.
Portlets would be grouped in a Portal Application by bundling them in a single WAR with a Portlet deployment descriptor file. Like the Servlet specification, the Portlet specification will allow access to Enterprise Information Systems without imposing restrictions on the type of protocols. It is an important goal that the design of the Portlet specification would allow implementations to support remote Portlet execution. This design would not address the transport protocol for the remote execution of Portlets, leaving to the specific Portal implementations the support for Portlet remote execution.
For example, a proxy Portlet could be used to invoke a remote Portlet. The Expert group will consider functionality such as support for, parallel execution of Portlets within a single user request, logging, security and personalization.
The Expert Group will evaluate defining a Credential mapping service to allow the Portal application to access resources in other applications not supporting the notion of distributed sessions- on behalf of user.
It is understood that the subject of this JSR is already being addressed by Open Source projects and products from different vendors. The expert group will ensure this specification draws appropriately from such projects and products and that it will be based on open standards.
A Java extension for the J2EE 1. This specification will establish a standard API for creating Portlets, thus avoiding locking in Portal developers in a specific implementation and allowing Portlets developers to reach a wider audience while reducing their development efforts.
The Portlet specification is required to achieve interoperability between Portlets and Java-based Portal servers or other web applications that implement the specification.
The goal is to allow Portlets to be packaged into WAR files and deployed in a standard way on any server implementing the specification. Furthermore, the Servlet specification does not define URL-rewriting functions to allow the creation of links and actions targeted to a specific form within the fragment of a page Portlet markup fragment.
However, it does not address aggregation, security and personalization. For a description of the Portlet technology, refer to section 2. APIs and descriptors to support internationalization and localization are a fundamental design goal of this JSR 2.
To be determined by the expert group, initial target is December We anticipate a mixture of mailing list and occasional face to face or teleconference meetings. It is expected that both specification leaders will fully share responsibilities associated with group leadership, including group communications, decision making, and agreeing to the business terms for the RI and TCK.
Exact details will be agreed early in the life of the JSR and communicated to expert group members. The TCK will be managed by Sun and will be available to independent implementors with no requirements to also license or use the RI.
There will be no shared code requirements. If this specification, or a future version of this specification, is included in a future version of a Java platform specification, this specification will remain available for use outside the platform specification, and will continue to be evolved outside the platform specification, unless both specification leads agree otherwise.
Section 3: Contributions 3. Please include links to the documents if they are publicly available. NOTE that this section has been updated since the original request. Different implementations are available today, the following list enumerates some of them: Apache Software Foundation: Jakarta JetSpeed 1. They will be useful for gathering features and evaluating the effectiveness and shortcoming of each implementation.
Introducing Java Portlet Specifications: JSR 168 and JSR 286
This section provides you with information that can help you decide which API to use when you develop portlets. Portlets that conform to the JSR specification are more portable and reusable, because they can be deployed to any JSR compliant portal. Rational tools supports portlet development based on the JSR specification. You can edit these new elements by clicking on the Portlet Deployment Descriptor that is created when you create a new portlet project. JSR leverages much of the functionality provided by the servlet specification, such as deployment, class loading, Web applications, Web application life cycle management, session management, and request dispatching. For new portlets, consider using JSR to take advantage of its additional capabilities. WSRP is another portal-based standard used to integrate the presentation of remote portlets provided as Web services into the local portal page.
Introducing the Portlet Specification, Part 1
For details, see a related blog. This sample provides the complete source code for the example that is described in the technical paper mentioned earlier. As its name implies, the Weather Portlet displays the current temperature in a U. To run the Weather Portlet: Unzip the weathersample. Open the project file in the NetBeans 5. Be sure to supply the appropriate environment- specific project files.