Oracle9iAS Portal Developer Kit (PDK)
Overview of WSRP and JSR168 Standards - An interview with Michael Freedman

JSR168 is the Portlet specification that would enable interoperability between Portlets and Portals. This specification will define a set of APIs for portal computing addressing the areas of aggregation, personalization, presentation and security.

The current goals of JSR168 are to:

• Define common Portal metaphor
• Define a standard Portlet Java API
• Ensure interoperability and portability
• Enable multiple markups support
• Maximize the leverage of existing Java APIs
• Ensure compatibility with other technologies

Let us find out from Michael Freedman, a little more about how the two initiatives relate to each other and how they relate to Oracle9iAS Portal.

Oracle9iAS Portal and Emerging Standards

A: To put it simply WSRP provides interoperability between differing vendors portals and remote portlets written to run in a web services environment. Specifically, WSRP is defining the web services standard for communicating between a portal and remote portlets.  Oracle9iAS Portal's web provider infrastructure currently relies on web service technology for this communication, however because there hasn't been a standard, it relies on its own proprietary protocol.  This means that portlets developed in Oracle9iAS Portal's web provider environment don't run in non-Oracle9iAS Portals.  Likewise, remote portlets developed for non-Oracle9iAS Portal remote environments don't run in Oracle9iAS.  The interoperability of a standard such as WSRP overcomes these limitations.

From an Oracle9iAS Portal architecture perspective, WSRP fits where the current web provider SOAP interface sits.  It defines the set of [SOAP] calls made from the portal to the remote portlet.  Like our current web provider SOAP interface, it is designed for efficiency and scalability vs. usability.  Again, like our current implementation, it expects developers interfaces to be layered on top of the SOAP service that implements this interface providing a simple, convenient, and usable portlet API to developers.  In this sense portlet developers should never see [or need to learn] about WSRP as they will be insulated from it by another API. 

Q: How does JSR168 fit into this relationship?

A: JSR168 defines the portlet interface Java developers will use to build portlets.  When used in a remote environment, it is the standard interface a Java based WSRP service exposes.  It is the equivalent of the current Oracle9iAS Portal's web provider Java API.  This means that of the two specifications developers should focus on JSR 168.  It will become the standard Java programming interface for portlets.  WSRP is more of a concern for Portal developers that want to support interoperable remote portlet development in various [language] runtimes.
 

Q: What are the benefits of having a standards-compliant container interface?

A: Interoperability is the biggest benefit. This is a benefit to both portlet re-sellers as well as enterprise customers. Portlet re-sellers will now be able to build their portlets with confidence that they will run in all portals that support the standards . This in turn will give enterprise customers a larger collection of portlets to choose from, in constructing their portal.

Another benefit of standards is that developer knowledge is no longer vendor specific.  In such a world, it commonly becomes easier to find knowledgeable developers and to train new developers as developer tools and communities come together in support of the standard.

Q: What is WSIA and how does it relate to WSRP?

A: Both Web Services for Interactive Applications (WSIA) and Web Services for Remote Portals (WSRP) are standards for visual, user-facing web services components. WSIA was initiated by OASIS before WSRP. It focuses on plug-and-play services that enable producer independent intermediary web applications. Portals are a specific type of such applications. The Portal is an intermediary web application that sits between the client [browser] and content [portlets].  So one way to look at the relationship is that WSIA intends to define the generic interface between any type of web application that utilizes independent content generators that run remotely from the application via the web services stack, while WSRP intends to define the specific interface when the web application is a portal. As these efforts overlap in many ways the two groups are joining together to define a common interface with the intent that WSIA components will be able to be used in portals and vice versa [WSRP components can be used in non-portal WSIA applications].

Q: What are the current schedules for WSRP and JSR 168?
 

A: Though still in the preliminary specification stage, current plans call for WSRP to be submitted for OASIS approval in December.  This would mean that WSRP could become an approved standard by early 2003.  JSR 168, though being conducted in a different standards body, has a similar timeline.  WSRP is being developed using an open process.  An interested party, though not in the expert group, can track the specification and comment on it by following the proceedings at  OASIS.  JSR 168, run under the rules of the Java Comunity Process (JCP), is more closed.  In the JCP, standards are prepared by the expert group prior to public debate.  Once ready, a community draft is published and a period of time is allowed for comments to be collected.  Currently, the JSR 168 expert group hopes to publish a community draft in October.

The Oracle 9iAS Portal development is tracking the progress of these standards with the intent that support for them will be provided as soon as possible once the standards are approved.

Q: How will WSRP and JSR 168 affect portlet development in Oracle 9iAS Portal?

A: It's a good question, but one that can't be adequately answered until the standards become firmer.  Currently, the standards are shaping up to be quite similar to our web provider framework.  However, the specific interfaces are different.  When the standards are approved, we intend to support the standards as well as continue our support of the existing web provider stack.  This allows our existing portlet developers to decide when to make the investment of standards-based portlet development.  Because of the functional similarities to our web provider framework, this transition should be relatively smooth and easy.
 

Revision History:

Revision No Last Update 1.0 July 12, 2002