 developerWorks > SOA and Web services | XML >  Introduction to Web Services for Remote PortletsUse WSRP in a Service-Oriented Architecture  |  |
 |
Level: Intermediate Bryan Castle (castle_bryan@bah.com), Senior Consultant, Booz Allen Hamilton 15 Apr 2005 Get an introduction to Web Services for Remote Portlets (WSRP), a specification which defines how to leverage SOAP-based Web services that generate mark-up fragments within a portal application. By defining a set of common interfaces, WSRP allows portals to display remotely-running portlets inside their pages without requiring any additional programming by the portal developers. To the end-user, it appears that the portlet is running locally within their portal, but in reality the portlet resides in a remotely-running portlet container, and interaction occurs through the exchange of SOAP messages. Leveraging WSRP within a Service-Oriented Architecture provides a powerful combination whereby presentation-oriented portlet applications can be discovered and reused without engaging in additional development or deployment activities. Looking at WSRP and related technologies Over the past couple of years, the term Service Oriented Architecture (SOA) has become a pervasive buzz word, although fundamentally there is nothing new about the concept. While SOA is often talked about within the technical community, how does SOA impact an end-user? Is an end-user going query a service directory to find a Web service that meets their needs? And then how would an end-user communicate with a Web service, even if he was aware of its existence? Is he going to write a client or a UI to interact with a Web service? Probably not. So, does a SOA provide any direct advantages to the end service user? Again, probably not -- that is, until now. WSRP is an emerging technology which has recently begun to garner industry support from all of the portal market‘s major players, including IBM®, BEA, Oracle, and Microsoft®. The ultimate goal of WSRP is to bring Web services and the benefits of Service-Oriented Architecture to the end-user. The WSRP Specification is a product of the Organization for the Advancement of Structured Information Standards (OASIS), which is a consortium that facilitates the adoption of technical standards. Version 1.0 of the WSRP Specification was finalized in August of 2003, and work is currently underway on version 2.0, which is due out in the middle of 2005. Since all of the major players in the portal market are represented on OASIS‘ WSRP Technical Committee, the technology should continue to enjoy broad acceptance in the industry. The OASIS WSRP specification defines a common, well-defined interface for communicating with pluggable, presentation-oriented Web services. These services process user interactions and provide mark-up fragments for aggregation by portals. A couple of the most important terms in the above definition warrant special attention. First, the services are presentation-oriented which means that they provide a user interface that allows an end-user to interact directly with the service. This is starkly different from a traditional Web service which focuses on processing a request and generating a response at a more programmatic level. Second, the specification defines a common, well-defined interface governing how a portal communicates with the service and collects the mark-up fragments it needs to present a page to the end-user. It is precisely this common interface which allows portal applications to generically consume portlets running in remotely-running containers. It is worth noting that WSRP is built upon existing Web services standards like SOAP, WSDL, and UDDI (see Resources). Although this paper focuses on the most common WSRP usage scenario -- the generation of HTML mark-up fragments to be consumed within a portal -- there is nothing to prevent WSRP from transporting other mark-up languages as well. Figure 1 shows how WSRP fits into the technology stack. Figure 1. WSRP relies on existing Web services technologies  Before delving into the world of WSRP, I should first clarify what exactly is meant by the terms portal and portlet. The definition of a portal is subject to interpretation; a survey of ten software engineers would likely elicit ten different definitions. For the purposes of this paper, a portal can be thought of as a Web-based application that is customizable by the end-user both in the look and feel of the portal and in the available content and applications which the portal contains. A portal, furthermore, can be thought of as an aggregator of content and applications or a single point of entry to a user‘s set of tools and applications. Now that you know what a portal is, what exactly is a portlet? A portlet can be thought of as a miniature Web application that is running inside of a portal page along side any number of similar entities. A portlet is a Web component which is managed by a container and can process requests and generate dynamic content. Portlets come in many flavors -- some are standards-based, while others are proprietary to the portal which hosts them. The Java Portlet Specification (JSR-168), approved in October of 2003, defines a standard API for J2EE-based portal platforms. The goal of JSR-168 is to provide a set of standards so that any compliant portlet can be deployed on any portal which supports the specification. Figure 2 shows a traditional portal model where the portal has a portlet container which hosts any number of discrete portlets. Each of these portlets generates fragments of mark-up which the portal ultimately pieces together to create a complete page that is presented to the user. Figure 2. A portal aggregating mark-up from local portlets If Web services offer a mechanism to create platform-independent services, and JSR-168 defines a standard by which to develop portlets, why do you need WSRP? The answer is simple. While Web services give you the ability to reuse back-end services, WSRP lets you reuse the entire user interface! For example, you might want to provide end-users of a portal the ability to look-up the price of a stock by entering a ticker symbol. You know that there is likely already a Web service which provides precisely this capability. You could search for stock-quote services in UDDI registries for a Web service that performs this service. Upon finding such a service, you would next need to code a client to bind to and consume the Web service, as well as develop a portlet to allow portal users to interact with the service. Using a Web service toolkit might make developing the Web service client relatively painless; however, developing the user interface might not be such a trivial endeavor. Additionally, you must go through the process of deploying the newly developed portlet and Web services client on your portal server. By the end of the day, you‘ve been forced to develop, compile, and deploy a substantial amount of new code to bring the stock quote service functionality to the end-user. While leveraging a stock quote service developed by a third-party does cut down on development time, the process of developing and deploying the front-end application needed to make the functionality usable by a portal user is tedious and time-consuming. Building on this same example with WSRP in the mix, you could much more easily integrate a stock quote portlet into your portal. You could browse the UDDI directory for portlets themselves or alternatively provide end-users with the ability to browse a registry of portlets. Once the Stock Quote Portlet has been discovered, the process of adding it to the portal takes just a few clicks of the mouse and you are done. You don‘t need to perform any custom coding or deployment activities since the portlet is being consumed through WSRP. The end-user doesn‘t need to understand anything about WSRP or even that their portlet is actually being hosted by a remote producer! The end-user only knows that they have a directory of available portlets from which they can pick and choose. What could be easier?
Before digging in to how WSRP actually works, let‘s briefly investigate the different moving parts within a WSRP architecture. Figure 3 below illustrates each of the primary actors within a WSRP architecture and the role a portal plays in aggregating the mark-up fragments. Although this diagram shows a portal consuming WSRP portlets from only a single producer, there is no reason why a portal couldn‘t consume portlets from any number of WSRP producers. The WSRP Specification defines the following actors within a WSRP architecture:
Figure 3. A portal acting as a WSRP Consumer to aggregate mark-up from remote portlets As alluded to previously, WSRP defines a set of common interfaces that all WSRP Producers are required to implement and which WSRP Consumers must use to interact with remotely-running portlets. Standardizing these interfaces allows a portal to interact with remotely-running portlets generically, since it has a well-defined mechanism for communicating with any WSRP-compliant producer. The WSRP Specification requires that every producer implement two required interfaces, while allowing them to optionally implement two others as well:
Listing 1 shows an example WSDL definition of a service which supports both the required and optional interfaces" Listing 1. Sample WSDL definition for a WSRP service
Discover portlets using a UDDI registry One of the primary benefits of using a portal is that a portal user can customize the set of applications (portlets) that are available to him. The user can create his own pages and add in new portlets as he sees fit. However, to customize the portal in such a manner, he must first be aware of what portlets are available. If there is a central registry (or potentially several registries), portal users can dynamically discover and bind to new portlets, thus creating a work environment tailored to their specific needs. From the portlet providers‘ point of view, a centralized registry is equally important since it allows them to publish and describe the portlets which they offer. Providers can provide textual descriptions, categorizations, and other meaningful metadata which richly describe their portlets so that consumers can more effectively discover these services. After all, what is the point of offering portlets to a community if no one knows that they exist? Universal Description Discovery Interface (UDDI) provides just such a mechanism to bring together WSRP producers who have portlet services to share and WSRP consumers who are seeking to leverage new applications within their work environment. Since UDDI has become the standard for Web services discovery, it is only natural that UDDI also serves as the backbone for portlet discovery. Portlet discovery, however, does throw a few quirks into the mix -- a portlet is not a true Web service after all. As mentioned above, in the WSRP world there are WSRP producers which are true Web services and WSRP portlets which can only be accessed through the API provided by their producer. While a WSRP portlet can be logically thought of as a service, it is not a true Web service since it does not offer an API by which a consumer could invoke it directly. However, the most common use case when dealing with portlet discovery would involve an end-user looking to find a portlet to add into one of his portal pages. The end-user has no concept of a WSRP producer, nor should he have any reason to understand the underpinnings of WSRP. However, since a portlet can be only be accessed through its producer, both the WSRP portlet and the WSRP producer must be published in the registry. It should be noted that once a consumer has discovered a portlet service within the registry, the portlet‘s metadata will contain all of the information necessary for the consumer to directly contact the producer and consume the portlet. Portlet discovery strictly acts as a mechanism to allow producers to describe their portlet services in a central location where potential consumers can discover them. Figure 4. A typical publish-find-bind usage scenario involving WSRP Figure 4 shows a typical usage scenario, which normally has the following steps:
This paper introduced Web Services for Remote Portlets (WSRP) and showed how you can utilize the power of WSRP to easily integrate a new application into an existing portal. The advent of WSRP means that you are no longer limited to being able to reuse only back-end services, but can instead reuse presentation-oriented services as well. Imagine how WSRP could be used to facilitate the development of an entire network of presentation-oriented Web services. Once in place, portal users can easily discover and use any number of these services. There is no need to have a developer create custom adapters, build client code, or spend time locally deploying the portlets. Adding portlets to a portal work environment is simply just a couple of mouse-clicks away. While this paper just touched the surface of the technical details behind WSRP, hopefully you now have a general idea of how WSRP could become a powerful mechanism to foster sharing and reuse of front-end applications. For more information on WSRP please refer to the resources below.
| |||||||||||||||||||||||||||||||||||||||||||||||||||
聯(lián)系客服
