WSRP, as I covered a few days ago, is an interoperability standard. It’s platform- and language-neutral. It’s all about requesting and transmitting chunks of HTML using SOAP. Today I’d like to weigh in on something usually uttered in the same breath as WSRP — namely, JSR168.
The fact that they’re uttered in the same breath is (a) a problem, and (b) no doubt fueled by some (not all) overzealous vendors who’d like you to believe you can’t have one without the other.
JSR168 is a standard for how to code portlets in Java. It’s a specific set of class definitions for authoring portlet code so it can be installed into multiple vendors’ Java-based portal products. That’s it. The WSRP connection comes from the fact that many Java-based portal vendors that can use JSR168 portlets also have code that can turn around and serve them up as WSRP producer Web services. My previous posting on WSRP already pointed out the potential issues of this approach for both network traffic management and for licensing, but that’s the connection.
If you want to compare apples to apples, JSR168 competes with Web Parts. Both have the potential to support WSRP. So let’s do that now…
If you’re only interested in Java-based products, and you’re planning to buy ready-to-use portlets from third parties, asking for JSR168 compliance increases the number of portlets from which you can choose. If you’re mostly building your own portlets, or you want to support a .NET or mixed environment, there are other ways that I think are smarter.
Smarter Way #1 is to use WSRP, but use it the final way I described it in my previous post. Create a portal UI staging tier consisting of WSRP producer Web services. Write them in .NET, in Java, or whatever you’d like. Render those WSRP producers using consumer code provided with any portal product. It’s service oriented architecture-friendly. It’s easier to deploy. It’s easier to modify.
Smarter Way #2 is even more fun. Reduce the need to code Web Parts altogether by relying on a great new tool that we’ll be introducing in Office “12” called the Business Data Catalog. We’ll auto-provision Web Parts based on known metadata about Web services and data sources. Conveniently, this will be the subject of my next post.
But I’ll close with one final thought, since I introduced the subject in the context of customers evaluating portal products. I really, really hope that people are coming to realize (and I know full well that many people get this already) that portals are much, much more than containers for portlets. It’s about the services behind those portlets at least as much, probably much moreso, than the portlets themselves.