Web Services for Remote Portlets, or WSRP, was recently approved as a standard by OASIS. Although a number of Web services standards are being worked on by different OASIS technical committees (TCs) - around Web services orchestration, management, security, reliable messaging, and ebXML - WSRP is particularly interesting as it brings out the benefits of open standards-based Web standards to the world of enterprise portals.

To understand what WSRP is all about, it's important to understand portals. Consider a financial services company, for example your bank. You typically have a savings and/or checking account. Once you've developed a decent relationship with your bank, you usually end up using additional services such as credit cards, bill payment, mortgage/student/auto loans, and so on. With the advent of e-business computing, a number of these services are available online through your bank's Web site. Typically, since these applications serve an individual purpose, they stand alone and have their own user interfaces.

But wouldn't it be nice to have all the applications available in a single application as a bunch of modules, under a common look and feel, using the same user profile information (including user IDs and passwords)? Also, if the various applications were available as "pluggable modules," it would be really nice to be able to personalize your view of the bank. The three Ps - presentation, profile, and personalization - are where portal technology began.

A portal is a framework that allows a company to create a unified presentation mechanism that is used to deliver key applications in a personalized manner to its users. The users can be customers, employees, business partners, or investors. The mini-applications launched from a portal are specialized views of the main application, providing key information that would be of immediate interest to the user within a unified portal. These mini-applications, or views, are called portlets. (It is important to point out that some vendors call them Web parts, others gadgets.)

Following in the footsteps of the popular public customized/personalized portals such as My Yahoo, a set of "pure-play portal vendors," including Plumtree and Epicentric, quickly brought the portal to the enterprise. The term Enterprise Information Portal (EIP) was coined and an integrated set of technologies including the three Ps was integrated into a "portal server." Going forward, portals were further broadened to include other capabilities such as customization, content management, and collaboration. Quickly the platform vendors realized that portals were key aspects of their platform growth strategy. Through internal organic growth or through acquisitions, they established portal server strategies tightly integrated with their own applications and/or database servers. Today, the portal technology landscape is quite broad and includes platform, application, and pure-play vendors such as BEA, IBM, Microsoft, Oracle, PeopleSoft, Plumtree, SAP, Sun, and Vignette.

So how does WSRP fit into all this? Until now vendors didn't really have a standard architecture for developing portlets. Based on your vendor's technology, you ended up developing portlets using their proprietary SDK, and if for some reason you needed to support another portal architecture, you would end up rewriting it. Also, until now there wasn't a consistent architecture/methodology followed by the vendors to loosely separate the portlets from the portal server. Typically, enterprises would develop portlets to their own applications and install them right on top of the portal server. This was okay for initial deployment, but when you scale to the 10s (and even 100s) of applications typically available in a large corporation, the local portlet model doesn't really scale. Some of the vendors designed/implemented their own "remote portlet" architectures, but again these were very vendor-specific. How will WSRP benefit us? WSRP provides us with a standards-based architecture, where a portal can truly be implemented in a "shared services" mode and a common IT infrastructure/architecture group can initiate the portal-based application deployment strategy and other internal groups can rapidly build their own WSRP-compliant portlets and get "hooked-on" to the portal. The model will also be very interesting for scenarios in which cross-enterprise portlets are used.

You can get more information on the WSRP standard development, including the specification, at the OASIS Web site, www.oasis-open.org. Also, I plan to closely follow the standard development, tracking the support and implementations, portlets, etc., at http://wsrp.info.