How Portal Standards Enable Reuse, Page 3
Guidelines For Using Standard and Non-Standard Approaches
If your organization is utilizing a portal framework to improve user experience, simplify development, and enable reuse of front end web application assets across customer, partner, and employee user experiences, you will need to establish guidelines for using JSR 168, WSRP, and non-standard approaches to build out your portlet catalog. The following set of questions is a starting point to guide you in defining the strategy for your organization.
- Do you have a notion of a portlet catalog? More important than your reuse mechanism is whether you have the notion of a portlet catalog in the first place. You should always consider what you want to reuse before you determine how you are going to reuse it. In most organizations, there is a compelling reuse story and a portlet catalog can help guide reuse efforts.
- Does your ecosystem include vendors and open source providers that offer portlets? Many vendors and open source providers of content management, business process management, business intelligence, CRM, and other software systems provide JSR 168 portlets. This is an ideal situation for incorporating functionality from these systems into the overall consumer, partner, or employee user experience. Deployment and release concerns are less of an issue for these components that do not frequently change.
- Do you have multiple teams contributing to the portal? If multiple teams contribute to the portal, which is often the case, WSRP can simplify release management because there is a single deployment of the portlet application, separate from the portal deployment. This allows teams to be on different release schedules. In addition, a single set of scalable infrastructure can be designed for the producer portlet and its multiple consuming portals.
Use of a common portal framework can work well when portions of development are outsourced to other teams, with the remote teams adding portlets to the catalog which plug into the common portal framework and set of common services.
- Do you have heterogeneous portal frameworks? In large organizations, multiple portal frameworks may be in use. If teams want to share assets across portals, either WSRP or JSR 168 might be employed. As noted above, WSRP often can simplify release management, particularly for assets that change regularly.
- Is portal provider lock in a concern? Proprietary portlets may offer additional functionality or developer productivity improvements. You will need to weigh the potential benefits versus vendor lock in. As long as the proprietary portlets can be WSRP enabled, they will be able to be leveraged if a different portal provider is used in the future.
- Does your organization utilize .NET? A pure .NET shop is going to choose a proprietary technology for its pluggable components called web parts. It may potentially consume some WSRP assets within or outside of the organization. In many portal implementations, a portlet is URL addressable and also may be consumed into a .NET application with simple Ajax. Similarly, a .NET application may be exposed through WSRP if required by an external organization. A shop with .NET teams that will contribute assets to its J2EE portal will need an architecture for making their .NET applications WSRP producers. Another approach to leverage existing .NET applications would be one of the "poor man's" WSRP approaches discussed earlier. Finally, adapters to SharePoint assets are available in many portal frameworks, allowing development of a custom portlet which leverages SharePoint content.
- Does your organization have high security requirements? If you have multiple teams and perhaps sourcing providers contributing to the portal in a high security environment, you would do well to stick with standard WSRP or JSR 168 implementations and not venture into non-standard approaches.
- Do you have applications that may be leveraged by IFrames or Web Clipping? If you have existing assets that you want to leverage through the portal, IFrames and Web Clipping should be considered. The limitations of these approaches in the user experience and integration with the portal should be weighed versus the speed and cost of initial deployment. IFrames and Web Clipping might be phase 1 of an incremental approach to re-write these applications as standards based portlets.
A portlet catalog is comprised of a set of portlets or interactive application components that can be plugged into the portal framework. These portlets may be obtained from third parties or custom built by multiple teams, and may be configured for use across consumer, partner, or employee user experiences.
JSR 168 is a Java standard that specifies the interfaces by which local portlets plug into their portal containers. WSRP is a complementary standard that specifies the interfaces through which remotely running portlets plug into portal containers. Each of these standards enables reuse of portlets in the portlet catalog. JSR 168 provides a component level reuse mechanism, whereas WSRP is a form of service level reuse.
You reviewed the difference between these two complementary portlet standards to understand how each might be used as part of an overall reuse strategy. You also considered many non-standard approaches such as proprietary portlets and their pragmatic use. Finally, you perused a list of starter questions to guide you in development of your portlet catalog reuse strategy.
Have you defined a portlet catalog as part of your portal reuse strategy? Have you developed guidelines for building out portlet catalog assets using standard and non standard approaches? If not, consider how portal standards might help your organization attain higher levels of front end web application asset reuse. The rest is up to you!
- JSR 168: Portlet Specification: http://jcp.org/en/jsr/detail?id=168
- JSR 286: Portlet Specification: http://jcp.org/en/jsr/detail?id=286
- Web Services for Remote Portlets Specification: http://www.oasis-open.org/committees/download.php/3343/oasis-200304-wsrp-specification-1.0.pdf
- Web Services for Remote Portlets Specification v2.0: http://docs.oasis-open.org/wsrp/v2/wsrp-2.0-spec.html
About the Author
|Jeff Ryan is an enterprise architect with twenty-four years experience architecting and implementing thoughtful solutions to business problems. Jeff uses the concept of the portal onion and portlet catalog described in this article to explain how portal standards enable reuse to business and IT stakeholders. Click here to browse Jeff's catalog of articles on enterprise architecture, front end architecture, portal, SOA, Java, XML, and XSLT.|