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…

• Language:  JSR168 portlets must be coded in Java.  Web Parts can be coded in any .NET language.
• Cross-Product:  JSR168 portlets can, in theory, be written originally to be used in one vendor’s Java-based portal product but can be deployed in another vendor’s Java-based portal product later.  In reality, the usual cautionary tale about “write once, debug everywhere” is very likely to warrant attention.  Web Parts, — today — admittedly only run in one portal product of which I’m personally aware:  SharePoint Portal Server.
• Cross-Application:  JSR168 portlets are just that — portlets.  They’re only designed to work in portal products.  Web Parts, on the other hand, can run in many, many different kinds of applications.  They originated in SharePoint Portal Server, but Windows SharePoint Services allows you to use them in collaborative workspaces, many WSS-based solutions do the same thing, and with the release of ASP.NET 2.0 and its newer Web Part control set, any ASP.NET application can make use of Web Parts — not just portals.  We at Microsoft think that a user-customizable modular interface should be a basic right.
• Consuming WSRP:  Depending on the vendor, some portal products directly consumer WSRP Web services.  Others opt to provide a JSR168 portlet designed to consume a WSRP Web service.  In the successor to SharePoint Portal Server due out later this year, we’ll take the latter approach, including a fully-supported, robust Web Part that can consume WSRP Web services.  A proof-of-concept that was tested against several vendors’ WSRP implementations was posted to GotDotNet last year, with source code, if you can’t wait for the successor to SPS 2003.
• Producing WSRP:  Most vendors with portals supporting JSR168 include code to emit them as WSRP producer Web services.  I’ll admit that we don’t do something this with Web Parts today.  Then again, .NET is great for authoring Web services and NetUnity Software has tools for building WSRP producers on .NET.

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.