First, in just one paragraph, give me a quick introduction to WSRP?
“Web Services for Remote Portlets” (or WSRP) is the technology that prevents developers from having to repeatedly develop user interfaces for every consumer of a given web service. Remember - traditional web services don’t return user interfaces – they just return raw XML strings that your client program must interpret and then display. Suppose a web service returns information clearly intended to be displayed in a user interface, as a stock quote service might do. That same information might be needed on hundreds of different web pages across many different organizations and locations. Obviously it is inefficient for each of the web pages that need to display that same information to be altered so that the stock quote is converted into a nice-looking HTML display. Ideally, the web service would just return the information already encased in HTML so that it can easily be included into an existing web page. This is the purpose of WSRP – to be able to augment existing web pages with remote functionality easily and with no programming. It’s about providing the entire user interface for a given software capability to multiple consumers. It’s about code reuse.
So how does WSRP look on a web page?
Actually, WSRP services don’t quite just return raw HTML – they return that HTML in a “portlet” form. To understand why they do that, you really first have to understand what a portal is. A well-considered intelligent example can really help to understand what a portal is. Unfortunately, all we have is this one:
This is what a portal might look like. There are three portlets visible – the patient schedule portlet, the patient history portlet, and the test results portlet. Note how the task bar across the top of each of these three portlets provides functions that you might see on a PC desktop application. For example, by clicking on the “_” icon at the top of any portlet, the end user can minimize that portion of the web page. Portal web pages are essentially designed to replace the desktop experience with a web-based desktop.
What do I need to know about portlets?
Note that the portlets on this page can be added, deleted or moved very easily, with no coding changes to the web page. Portlets are added and deleted with a web-based configuration tool run by either the system administrator or by the end user. Users can just select what portlets they want to see on their desktops from a list of available portlets. (Each portlet really points to a remote URL like http://www.PracticeSafeTechs.com/ourPortlet.wsdl ). Some portal admin tools even allow portal administrators to serve out a local portlet as a WSRP service so it can be consumed by other remote Portals. That is, the portal administrator could optionally make the “Patient Schedule” portion of the portal shown above available in portals within other departments or other companies. The tool allows them to convert a portlet into a WSRP service.
So how does WSRP tie in with portlets?
So WSRP services return the HTML in portlet form. If only raw HTML was returned, the user’s web page HTML source would need a source code change every time the user wanted to customize their web page with some new portlet. But by putting the HTML in portlet form no web page customizations are required. The portal server knows how to create a new portlet from the HTML fragment that is returned by the WSRP service.
The remote portal server is called the “producer” and our local portal server is the “consumer”. WSRP establishes the standard for communication between these two. When a remote portlet is rendered in the local portal, the end user can not tell if it’s local or remote (unless the portlet has a name that shows something about where it is derived from). The fact that the information in the portlet is ultimately coming from a remote web service is completely transparent to the end user.
Note to reader – I know what you did last summer.
What are the common and serious mistakes that companies make with WSRP?
So what are the most common mistakes of projects that involve those three technologies? Why are so many WSRP projects over budget? What are the alternatives to these technologies that the portal proponents in your company are not telling you about (or not aware of)? Are WSRP interfaces likely to become more widespread? Don't just settle for the book excerpt on this web page - spend a few dollars today to avoid a project headache tomorrow. (Incidentally, the book is about the price of three or four bottles of ibuprofen.) Leverage off our experiences in the trenches of getting these technologies working in production at client sites. We have a different take on these technologies than the sales teams, that's for sure. Click the “Buy Now” button below and act to keep your career firm, erect, and moving upward!