WSRP non-normative Conformance: Use Profiles

The Web Services for Remote Portlets Specification, V1.0 [PDF], from August 2003, does not have any profiling or conformance requirements above what's mandated by the specification it self. Since the specification contains several optional features interoperability is in jeopardy.

The specification is aware of this as in section "1.2.2 Producer":

In order to allow different levels of sophistication for both the Producer and Consumer, parts of this functionality are optional. Various examples of how a Producer might implement particular functionality for varying levels of sophistication and with regards to implementing some of the optional portions of the protocol are contained throughout this document.

A the XML Conference in 2003 a couple of IBM guys did a presentation on WSRP called Enabling Interactive, Presentation-Oriented Content Services Through the WSRP Standard [HTML] and in the Future Work section there's a first hint: ...the TC works on use profile definitions and conformance assertions to help guide both the production and marketing of those implementations....

The Web Services for Remote Portlets 1.0 Primer [HTML], Committee Draft 1.01 from 25 January 2005, is a newer document and has a reference to the WSRP Conformance Test Kit on from IBM's AlphaWorks site. It was lat updated June 30 2004, that's more the 3 years ago. In the text it says In this release of the test kit, not all conformance statements are tested. Additional test cases will be added as they become available. This certainly is the smell of an abandoned project that was never completed. In the description on how it works is goes:

The architecture of the WSRP Conformance Test Kit includes a monitor process for non-invasively collecting Web service messages between a client and a server. Once the messages are logged, an offline analyzer process examines the log, determines if the messages conform to the specification, and produces a conformance report. An XML file describing the test cases is read by the analyzer at run time. This XML file is called the WSRPProfileTestAssertions.xml.

A post to the forum by Konrad touches on the same from a more technical perspektive called WSRP Conformance Toolkit outdated?.

So this is strict conformance to the requirements found in the specification and has nothing to do whit profiles. There's also a link to a Microsoft formatted spreadsheet called WSRP Conformance Statements

In section 7 Use Profiles it finally turns up:

The purpose of use profiles is to provide a well-defined palette of functionality for Producers and Consumers. By qualifying a Producer or a Consumer implementation with a use profile palette, implementers can indicate the level of functionality supported. WSRP use profiles are non-normative, and should be regarded as general guidelines. Implementers will likely compose their implementations by selecting from a “palette” of functionality, and this section provides some guidance on how to map these use profiles across several functional axes. Refer to [9] for a complete description of use profiles.

WSRP use profiles declare following levels for Producers:

1. Base Level: The Producer implements just the required elements of the WSRP Specification.
2. Simple Level: The Producer implements certain optional/advanced features in addition to whatever is required at the base level.
3. Complex Level: Complex level Producers implement most of the optional/advanced features of the WSRP specification.

The following are the use profiles for Consumers:

1. Base Level: The Consumer implements just the required elements of the WSRP Specification.
2. Simple Level: The Consumer implements certain optional/advanced features in addition to whatever is required at the base level.
3. Medium Level: Medium level Consumers may implement a larger set of the optional/advanced features of the WSRP specification.
4. Complex Level: Complex level Consumers provide extended features (such as custom modes and window states).

The use profiles are intended to simplify the possible combinations of support for optional areas of the WSRP specification. Each profile specifies a certain set of functionality as supported. While an implementation may also support other optional functions, specifying the supported use profile helps customers to compare the support offered by implementations.

A Consumer and Producer have different motivations in achieving higher levels. A Producer need only implement the functionality required by the portlets it is offering. Unless a Consumer knows that it will only be consuming portlets from a Producer of a given level, it should provide all levels so that any portlet can function properly. The Consumer should not assume that there is graceful degradation of functionality if it does not implement certain functionality. For example, if a Consumer does not provide, say, registration, a portlet from a Producer requiring registration will not function at all.

Also note that there is not a one-to one correspondence with Producer Levels and Consumer levels; e.g. the base consumer level is expected to handle the initCookie operation, while the base Producer level does not require this operation.

This is all based upon a document called WSRP Use Profile [DOC]. The document is quite old, 31 july 2003, and written by Alan Kropp. It's very unformal and there's not a link on the TC homepage. Under "Functional Areas" theres a hint to which concerns have been put into this work (my bold):

An overriding concern in describing the different levels is to maximize basic interoperability, regardless of the implementation choices made. Certainly some combinations of Consumer and Producer implementation may not yield optimal results for the end-user; this is to be expected, particularly when dealing with minimal implementations. However, even base implementations should be capable of interacting with their more sophisticated counterparts, at a sufficient level of functionality, to provide even the most rudimentary result (i.e., not a fault message) to the end-user.

The following functional areas has been identified:

• Caching
• Cookie Handling
• Modes/Window States
• CSS/Markup
• Extensions
• Handles
• Metadata
• Properties
• User Categories
• User Profile
• Namespacing
• Registration
• Portlet Management
• Session Management
• Miscellaneous
• URL Processing
• URL Rewriting

I haven't the needed insight into WSRP V1.0 feature set to have any qualified opinion about it.

WSRP V2.0 Conformance

Public Review Draft 03 of Web Services for Remote Portlets Specification v2.0, from 22 June 2007, has what's called Conformance Statements in Chapter 15. Its not profiles like the ones suggested for version 1.0 nor the way it's done in SAMl V2.0. It's a summary of requirements and maybe they'll later produce real profiles, since this just gives one level of granularity know for the terms REQUIRED, SHOULD, RECOMMENDED etc.