What can you do with Web services? Quite a lot, it seems, if you pay attention to the many analyst reports and media articles on the topic. But much of the talk about Web services assumes that all corporate IT developers have A) a deep understanding of Web services and B) a lot of time on their hands. For the more typical developer working in the real world, however, Web services hasn't seemed like a terribly practical, or at least useable, concept.
But there is a very real way to make practical use of Web services -- right in your WebSphere portal. That's because WebSphere supports the use of both syndicated content from commercial providers via Web services, as well as the Web Services for Remote Portals (WSRP). WSRP is a standard developed by the Organization for the Advancement of Structured Information Standards (OASIS) which makes it possible to create one portlet in one location and have it accessible from different geographic locations in the company -- all without having to do additional programming.
- Syndicated Content. One of the first practical uses people have made of Web services is to send syndicated data, such as stock quotes, news and weather reports, to subscribers, who often subscribe via a corporate portal. Companies such as Factiva provide the technology and the content partnerships to make content-rich portals. For instance, Factiva has 120 newswires, as well as magazines such as Time. To access the content, a portlet sends a request and receives the text or data, via Web services. The local portlet then provides the display logic for the local portal.
- WRSP for Remote Portlets. WSRP is new standard that is presently a technology preview only in WebSphere 5.0.2, which means that it is not officially released and supported by IBM. WSRP makes use of Web services to create portlet proxies which access portlets on a remote portal server. Unlike syndication, in which the portlet serves up content via Web services, a remote portlet proxy is accessing remote logic as well as content. The logical processing is done on the main portal, with the results being sent via a SOAP XML message. That saves developers time (they don't have to deploy one portlet at all locations), and bandwidth, since you're not sending a series of application execution requests across the network, but a simple XML request for whatever data the remote portlet is programmed to provide, along with the presentation of that data, in the form of .html markup embedded in the response.
Hence, there is no need to build a portlet to display the data from the remote Web service. Instead, the develop needs only to incorporate a generic WSRP portlet proxy into the portal. The proxy is used to bind to the desired WSRP portlet. The presentation logic is, of course, dictated by the provider of the remote portlet.
A WSRP Example
Here's an example: Lets imagine a global company that is headquartered in New York. All of the major business systems are in New York. The company deploys WebSphere Portal and creates portlets that bring those back-end applications into the portal. So far, this is a standard portal installation. Because this is a global company, we also deploy WebSphere portal in Europe and Asia Pacific. These portals provide location-specific portlets, but also need to provide access to the business systems in New York. WSRP can be used to make the portlet (the logic and the content it accesses) on the New York portal easily accessible to the other portals. Once WSRP-ized, all we need to do is create a proxy portlet on the Europe and Asia Pacific portals, which uses Web services in the background to access the actual portlet in New York. The end user sees the same portlet on all three portals, WSRP is the magic that makes the portlet in New York distributable.
While it's possible to deploy portlets on multiple portals without using WSRP, accessing back-end systems from remote locations may result in poor performance, not to mention the challenge of creating a secure connection over a wide area network, and getting through corporate firewalls to those back-end systems. WSRP, with its Web services underpinnings, is designed to resolve those issues, making it relatively painless to create a remote instance of any portlet. Another benefit of WSRP is that if the logic or presentation changes in the remote portlet, those changes will immediately be reflected by all portlets which use it.
To use a WSRP-supporting portlet available at a remote location, a developer must:
- Search the appropriate UDDI registry to identify the portlet he wants to access.
- Use the Web services manager to create a portlet proxy for it, and add the portlet project to the portal page on which he wants it to display. No coding is needed to do this.
The portlet proxy communicates with the remote portal by sending a SOAP request and invoking the remote portal, which in turn locates the requested portlet on its server, invokes it, and sends the portlet's response -- the content -- back to the requesting portlet proxy.
Whether to deploy the same portlet in multiple locations, or use WSRP to create a remote proxy for the same portlet is a question that should be carefully considered during the design phase of the portal. If the content or application that the portlet needs is also present in the same geographical location as each portal instance, then it's a good candidate for simply deploying the same portlet in multiple locations. However, if the content or application is in a single location, it's likely to be a good candidate for using WSRP to access the portlet remotely.
But portal developers in large or distributed enterprises should always consider using WSRP, rather than automatically attempting to deploy a local portlet in multiple portal locations. The use of WSRP minimizes load on the WAN and maximizes the performance of the portal and virtually eliminates the challenge of creating a secure communications channel across the public Internet and through corporate firewalls (a command issue that is often difficult to resolve).
In Conclusion: Web Services ARE Practical
As you can see, Web services do have practical, valuable uses within portals -- either by serving up syndicated content to make for a more information-rich portal, or in the form of Web Services for Remote Portals -- WSRP -- proxies, which enable remote logic to be accessed and displayed by local portals.
Thanks to WSRP and WebSphere, organizations can both publish local portlets as Web services so that other portals or organizations can use them remotely, and can easily find and use remote Web services as portlets in their own enterprise portal. WSRP not only simplifies the portal developer's job but also enables users to have access to a wider range of services.
Tony Higham is the chief solutions officer at FatWire Software and an expert on Lotus, WebSphere and Java technologies. He can be reached at tony.higham@FatWire.com.
Sue Hildreth is a contributing writer and editor based in Waltham, Mass. She can be reached at Sue.Hildreth@comcast.net.
Do you have comments on this tip? Let us know.
Please let others know how useful it is via the rating scale at the end of the tip. Do you have a useful Notes/Domino tip or code to share? Submit it to our monthly tip contest and you could win a prize and a spot in our Hall of Fame.
