How Portal Standards Enable Reuse
Because WSRP is based upon web services, it has the notion of consumers and producers. A single producer can serve multiple consuming portals. A producer may be based upon either J2EE or .NET. Each consuming portal may configure the remote portlet according to its desired user experience. Consuming portals may also be either J2EE or .NET. Consuming portals may even consume portlets deployed outside the firewall.
WSRP 1.0 was released in 2003, and, like JSR 168, has been successful in enabling reuse and interoperability between remote portlets and consuming portals. As with JSR 168, functionality gaps in the specification required proprietary extensions. WSRP 2.0 was approved as a standard in 2008, and addresses key gaps such as inter-portlet communication as did its sister JSR 286 specification.
Many WSRP implementations make enablement of a web application or local portlet a trivial task. On this note, consider that a given portlet can be both JSR 168 and WSRP, although a WSRP portlet need not be JSR 168.
Although in general WSRP specifies the interfaces for remote portlets, note that there are some vendors that provide the option for local deployment to optimize performance.
JSR 168 and WSRP Compared
The following table shows some of the differences between the complementary JSR 168 and WSRP standards.
|Differentiator||JSR 168/286||WSRP 1.0/2.0|
|Reuse Mechanism||Java Component||Web Service|
|Deployment||Generally coupled with portal||Generally de-coupled from portal|
|Ability to obtain portlets from third parties||Yes||Rare|
|.NET Producer||No||Yes, with third-party software|
|Standards Body||Java Community Process||OASIS|
|Developer Friendly||In some implementations, JSR 168 portlets are akin to servlet programming and generally not as friendly as proprietary portlet development tools.||Often, developer friendly and a trivial effort to WSRP enable an application.|
|Infrastructure Friendly||Simple deployment model||More complex deployments for load balancing and fail over.|
|Release Management Friendly||
"Cut and paste" component reuse requires multiple deployments to release changes in each portal.
Different versions of the component may exist in each portal.
Service reuse and single deployment simplifies release process.
A single version of the component exists across all portals.
Non-Standard Approaches to Portlet Reuse
Although this article is about reuse through portal standards, a mention will be made in regards to non-standard approaches to portlet reuse. In developing your strategy for building out and reusing your portlet catalog assets, a balance needs to be struck between idealism and pragmatism. Often, a non standard approach may be the right thing to do due to time, budget, or other goals and constraints.
Proprietary portlets may be considered because of the developer productivity gains and because of limitation of certain capabilities with strictly adhering to standards. Often, proprietary portlets can still be exposed through WSRP, allowing interoperability with heterogeneous portal environments.
The Microsoft equivalent to a portlet is called a Web Part. Web Parts could arguably considered standards within the Microsoft ecosystem and a Microsoft-based portal would utilize them heavily.
Poor Man's WSRP: IFrames and Web Clipping
IFrames are HTML elements that allow an HTML document to be embedded within another document. IFrame portlets may be used to expose an existing application as a portlet, eliminating the need to re-write the application, at least in the short term.
Web Clipping is a technique to extract portions of a web page, eliminating extraneous graphics, headers, footers, and navigational elements. Web Clipping portlets may be used to leverage functionality embedded in existing applications and re-brand them per the portal.
Both IFrame and Web Clipping approaches expose remote applications as portlets and in a sense can be considered a poor man's WSRP consumer. Each approach limits the ability to fully integrate the portlet into the user experience by skinning it and sharing context through a standard inter-portlet communication mechanism.
In some portal implementations, portlets are URL addressable. This can be considered a poor man's WSRP producer because it allows portlets to be consumed by non-portal web applications through simple Ajax and an IFrame.
Rich Internet Applications (RIA) seek to create a more stateful client application in the browser that has features and functions, such as drag and drop, more typical to traditional desktop applications. RIA implementations are varied and may be based upon Ajax, Flash, Silverlight, Java applets, or other technologies. RIA-based portlets are another non-standard approach to consider in creating certain portlets in the portlet catalog to meet usability requirements.
Page 2 of 3