While Web services were initially conceived to execute as standalone pieces of software for interoperability purposes, their actual use has exploded into many application realms. From Web services designed to operate in the confines of an application server to those deployed on client side applications like spreadsheets, the list is extensive. In this article, we will explore yet another area in which Web services have popped onto: portlets.
Portlets are a popular choice for many Web-based applications. Among their many features are the following:
- Ability to be customized by end users once deployed as an application
- Capacity to target many user devices from the same design
- Ability to process messages and events once executed
These are just a few features, most of which are compelling enough by themselves to choose a portlet design over other alternatives. However, up until recently, most portlet deployments have been based on proprietary API's.
In the Java world, designs based around JSR-168 have the biggest share when it comes to portlet deployments -- since it's supported by most major application server vendors -- although there are other alternative like the IBM portlet solutionwhich competes in this same space. In the .NET camp, Web Parts is the closest incarnation to a portlet programming model.
But where does all this lead when trying to create interoprable portlet solutions? Enter Web services for Remote Portlets (WSRP), a vendor neutral specification developed under the auspices of OASIS, for the creation of portal-driven applications through Web services.
Given WSRP's foundations, the specification is naturally designed to integrate seamlessly around the full stack of specifications common to Web services such as SOAP, WSDL and UDDI, among others.WSRP also has provisions to integrate with its early portlet predecessor JSR-168, allowing you to migrate existing Java/JSR-168 portlets to WSRP.
The backbone for WSRP is divided into two parts: producers and consumers. A producer is charged with providing the Web services end point along with lifecycle management, registration and other administrative services.
A consumer, on the other hand, comprises the logic necessary to tap into the WSRP producer, along with any ancillary component necessary to deliver the portlet content either as a browser-based application or as a self-contained service to end users. The following diagram illustrates how portlet producers and consumers interact:
At the center is a server which serves as our portlet producer, The portlet producer, shown in the center of the diagram, can establish communication with third party portal servers – portal Consumers – via the standard Web services mechanisms UDDI/WSDL/SOAP. Once these consumers process the portlets producer's content, they can arrange the data in whatever manner is convenient, and send it off to client applications – browsers or fat client – which are completely abstracted away from the existence of a portlet architecture.
After this process (steps one and two), the client application can later return results back to its corresponding proxy server – the portlet Consumer – which can either end the sequence (step three), or redirect the obtained results back to the portlet producer (step four) .
As you can see, the use of WSRP provides for a very robust architecture for both consumers and producers of portlets. As a producer, you can publish WSRP designed services for consumption by either the intranet or third party portals, which are later bridged to end clients. As a consumer, you can create an application aggregated from various third party portlet producers, creating an easily maintainable deployment.
In order to achieve an actual production environment based on WSRP, there are various options at your disposal, since WSRP is based on a specification.
There are various vendors that provide a production environment for WSRP-based applications. However, this best of breed market requires a fair amount of due diligence on your part, since the maturity and extra functionalities provided by each vendor varies.
Among portal server vendors that offer support for WSRP are the following :
- BEA Web Logic Portal: http://www.bea.com/products/weblogic/portal/index.shtml
- Apache WSRP4J: http://portals.apache.org/
- IBM Websphere Portal: http://www-306.ibm.com/software/genservers/portal/
- PlumTree: http://www.plumtree.com/developers/standards.htm
- OracleAS Portal Server: http://portalstandards.oracle.com/
- Sun Portal Server : http://www.sun.com/software/products/portal_srvr/ds_portal6.xml
The actual complexity or ease with which a WSRP application can be rolled out in any of these products will depend heavily on your familiarity with similar portal tools from the same producer because most WSRP support is built upon earlier JSR-168 server implementations. If you have previously used Pluto –Apache's JSR-168 portal server – then Apache WSRP4J might be a good fit for you. On the other hand, if you organization is committed to the IBM product line, then Websphere Portal will surely be an obvious choice to test out WSRP deployments.
Like many Web services technologies out there, WSRP is not a panacea for every software project, but if you are contemplating deploying the same Web application repeatedly, WSRP may be the right solution for you. WSRP can abstract away the tedious deployment process, and at the same time, grant this access to other third parties using Web services standard.
About the author:
Daniel Rubio is an independent technology consultant specializing in enterprise and Web-based software, He blogs regularly on these and other software areas at : http://www.webforefront.com/.
