So I’m listening to Vishveshwara Vasa talk about SOA and Portal. (He used to work for my company Perficient btw). He hit upon the WSRP topic and I thought it worthy of a very short discussion. WSRP stands for Web Services Remote Portlet. The idea is that you call the portlet by passing on some information, you get in return a completely formatted set of html. it can be pretty cool. It’s like web services on steroids because I don’t even have to do the formatting. Lately, we’ve seen a number of companies get jazzed on WSRP. they think it’s going to simplify their lives. It has the capacity to do so. However, you need to keep some things in mind. IBM really like WSRP. Liferay has stated in their forums that they aren’t the biggest fans of it. It’s over-engineered. Microsoft just released WSRP support. We don’t see much around WSRP from Oracle with their set of portals. So here are some pros and cons.
Update: So I spoke to Vasa about whether or not he’s actually implemented WSRP and his answer was yes, he has done it and used it successfully. He’s become a big fan of the approach and believes it will become more used over time. Especially since SSO has become easier. He just passed a couple LTPA tokens between servers and it worked out well.
When I should use WSRP
- When I have a tool that can easily make a WSRP producer. For example, WAS 7 supports WSRP 2 and lets you make an app into a producer. Microsoft has WSRP services as well. There is a PHP producer out there. I don’t know much about it but if is at least kind of “easy” then maybe you should consider it.
- When you don’t have to make a huge amount of changes to the UI. If you make a producer of an existing web app but it contains it’s own navigation, then you need to think about what will change once you surface it in a portal.
- When SSO is easy. WSRP 2.0 has much better support for passing tokens I’m told. If you can pass an LTPA token in the IBM world or you have a proxy like TAM, OAM, OpenSSO, or Siteminder then life is good. If something in your app is going to make it hard then think it through.
- When not putting your load on the portal server makes sense. Even drawing a page takes CPU cycles.
When you should be careful with WSRP
- When you think it’s going to make your administrative life easier when launching new functionality. If you are going to use WSRP, you are not losing admin time. someone still needs to configure a WSRP consumer on your portal, test it, and launch it. That’s about the same effort as importing a portlet, testing it, and launching it. You don’t gain much from that perspective.
- When SSO is hard. If for some reason, you cannot figure it out, then be careful. It may be harder with WSRP than with other approaches.
- When your server that hosts the WSRP producer doesn’t support high availability (HA)requirements. If the server is a single server and your users tell you 24X7 support, you have a problem. Most portals we deploy have some level of HA.
- If you are going to have formatting issues where the WSRP portlet will display with a separate style (font, font size, other formatting). Just surfacing it on a portal can make it look ugly. I’ve seen plenty of users that have major issues.
So, there are plenty of reasons to use or not use WSRP. I think it has some possibilities. ……………….just be careful before diving in deep.
