subbu.org

Having taken a positive spin on how WSRP addresses UI reuse questions in a previous post, I would like to comment on its current limitations in this post.

WSRP 1.0 does address the core UI-reuse and aggregation questions well, but being a 1.0 specification, it leaves a number of issues open. The WSRP TC has been working on these open questions ever since WSRP 1.0 was released last year. So, some of these limitations may not be true once WSRP2.0 is released.

There are several implementations (see WSRP TC Home Page for a list full/partial implementations of WSRP 1.0) available (including one from my employer), and there are several projects underway, either prototyping or moving towards deployment of portals using WSRP. Most of these implementations and projects are wary of the limitations and working around those limitations by way of custom extensions or other implementation-specific solutions.

Can WSRP Deliver Performance?

WSRP is built on other web services standards such as SOAP and WSDL, and therefore, performance is the first question to consider. Moreover, WSRP web services are userfacing and involve SOAP requests from WSRP Consumers (typically portal servers) to WSRP Producers (typically portlet containers) in response to users browsing a portal. Each user request is likely to generate one or several SOAP requests from Consumers to Producers. Before discussing performance issues any further, let us look at what gets exchanged with WSRP messages between a Consumer and a Producer.

UI Markup Fragments (such as snippets of HTML)

As the user starts to interact with a portlet, its UI changes, and the Consumer has to get new markup fragment reflecting the changed UI. WSRP 1.0 requires that this markup be encoded either as a string (XML-escaped or in a CDATA section) or as binary with base64 encoding and be embedded in a SOAP envelope. Here is an example.

<urn:getMarkupResponse xmlns:urn="urn:oasis:names:tc:wsrp:v1:types">
<urn:markupContext>
<urn:mimeType>text/html; charset=UTF-8</urn:mimeType>
<urn:markupString><![CDATA[<p>Hello World</p>]]></urn:markupString>
<urn:locale>en-US</urn:locale>
<urn:requiresUrlRewriting>true</urn:requiresUrlRewriting>
<urn:preferredTitle>Hello World</urn:preferredTitle>
</urn:markupContext>
</urn:getMarkupResponse>

For small markup fragments (for example, a 1k-2k markup fragment showing some HTML forms or search results), generating a SOAP envelope with markup inline may not translate to significant performance hit. But as the size of the markup fragment increases, performance may deteriorate.

a. Most portlets use JSPs or ASPs or something similar to generate markup fragments. Since the Producer is required to collect the complete markup, it cannot stream it directly to the response (unlike what most web/application servers do). Instead, the Producer will have to allocate byte buffers, the size of which depends on the size of the UI. The larger the UI the more memory the Producer must allocate.

b. Encoding this markup in a SOAP message is another issue. Depending on how a Producer chooses to embed the markup fragment in a SOAP message, there may be an additional cost for adding the markup to the SOAP message.

User Input

Consumer sends two kinds of data to the Producer in response to a user interacting with a portlet - form parameters and uploaded data. When a user submits a form with parameters or files, the browser sends a multipart request (for POST requests) to the Consumer. However, as per WSRP 1.0, this mutlipart data must be transported within a SOAP envelope and not as an attachment from the Consumer to the Producer. As a result, the Consumer cannot stream the input directly to the Producer. It must read the input into memory before creating the SOAP envelope. This approach poses additional memory as well as processing burden on the Consumer. For example, the Consumer may not be able to upload large files due to the amount of memory it must allocate in order to read the uploaded file into memory. The same is true for the Producer.

There are other kinds of data in WSRP 1.0 (such as persistent properties of portlets) that can bloat request and response messages. These are optional, and most implementations choose to persist such data wherever it gets used most (on the Producer, in most cases), and are of little/no concern in most implementations.

How does WSRP address these? There is really no answer at this time, partly because, the specs governing “binary data in XML” are in flux. Some of the current SOAP stacks support SOAP with Attachments and DIME. There is some hope for a unified interoperable answer from W3C in the form of MTOM and XOP. This leaves implementations to improvise for the time-being, possibly compromising interoperability.

Is WSRP Secure?

After performance, security is the biggest concern for most WSRP deployments today.

How should a Producer trust a Consumer? How to make sure requests and responses are transmitted securely? How to propagate end user identity from the Consumer to the Producer? How to propagate other security attributes such as security domain, roles etc? Apart from making some vague guidelines, WSRP 1.0 specification does not answer these questions. This was rightly done, because none of these questions actually belong to the WSRP layer, and should be addressed by the underlying web services transport layer.

Unfortunately, security standards governing web services came out only this year - not in time for WSRP 1.0 to make any useful guidance. In future, it is likely that WSRP implementations would take advantage of these standards by delegating security issues to the underlying transport layer, but in the meantime, implementors will have to resort to proprietary means that may not interoperate.

User Experience

Portals aggregate markup fragments from portlets most likely authored by different groups of developers. Given that all these fragments end up on a user’s browser, it is important to make sure that all portlets follow the same style/naming conventions. Otherwise, users will be “Submit”ting a form in a portlet, and “Proceed”ing with a similar form in another portlet. Entering MM/DD/YY may be acceptable in one portlet, but entering the same in another portlet may annoy the user with some client-side/server-side validation errors until the user figures out he/she should enter MM/DD/YYYY. Although less inconvenient for users, consistent choices of colors/fonts etc also help improve user experience.

WSRP 1.0 does address a part of this problem. It specifies a standard set of CSS style attributes that portlet developers can use in their portlets. The expectation is that Consumers provide CSS styles that define these attributes. As long as portlets use these attributes in their markup, we can expect some level of consistency between portlets in terms of colors, fonts, tables etc. However, it does not yet solve broader usability issues such as control naming (e.g. Submit vs Proceed), consistent user input validation, consistent placement of images, links etc.

Richness

Portlets aggregated from remote Producers do not enjoy the same benefits off all the things that web programming models (like JSPs, ASPs) can offer. It is rather straight-forward to weave together rich UI using JavaScript, DOM, XHTML, plugins and so on. But doing so with portlets deployed on remote servers is very tricky, if not impossible in some cases.

a. With WSRP 1.0, it is valid for portlets to include JavaScript within the markup, but you cannot include JavaScript outside the <body&gt of the aggregated page. XForms also belongs to the same category.

b. Portlets cannot ask the Consumer to use external style sheets.

c. Portlets cannot influence the behavior of other portlets in an interoperable way. For example, a portlet creating a purchase order cannot tell another portlet that it should refresh the list of pending purchase orders.

d. Browsers use the DOCTYPE to determine whether to render the page using the quirks mode or the standard mode. But portlets don’t have a clue of the DOCTYPE that the Consumer is using for the aggregated page. So, the markup generated by the portlet may not render very well in all browsers.

Concluding Thoughts

Despite these limitations, WSRP delivers on what it promises. For the first time, WSRP 1.0 provides a solid foundation for integrating and aggregating UI. Moreover, most of the current implementations do interoperate with each other. This is a good thing. But there is room for improvement. WSRP 2.0 will most likely address some of these limitations. For others, you may have to rely on vendor extensions for a littlle longer.