What is the significance of WSRP and what are its goals?
With earlier portal vendors or organizations running portals, application integrators had to write special adapters to enable communication with applications and content providers using a variety of different interfaces and protocols. However, with this standard the entire approach is changed. Some of the WSRP features are:

• Remote Invocation - Can be used to include the remote applications as it is, which follows WSRP specification i.e., it delivers both data and that data's presentation logic.
• Business Enablement - Designed to enable businesses to provide content or applications in a form that does not require any manual content or application-specific adaptation by consuming applications.
• Plug 'n' Play - Easy to aggregate and can be invoked through a common interface using generic portlet-independent code that is built into the portal.

Some of the WSRP goals are:

• To provide interoperability, portability, and options for deployment
• To decouple the deployment and delivery of applications
• To remove duplication of functionality from otherwise discrete applications
• To enable interactive, presentation-oriented Web services to be easily plugged into standards-compliant portals
• To ensure concepts and data exchanged are aligned with other standards in both the portal and Web service arenas
• To make the Internet a marketplace of visual Web services, ready to be integrated into portals

How can we provide the support for WSRP?
Now we know what WSRP is and what its benefits and goals are. Now let's understand the inside story of WSRP from a WSRP implementer (producer and consumer) perspective in the context of the end user. In this section we will discuss the following:

• Layered architecture (which includes the end user also)
• Remote portlets publishing and access mechanism
• List of interfaces (API) (and their brief descriptions) implemented by producers and consumers
• Sequence of flows of interaction between the end user, consumer, and producer

A portal can be accessed through HTTP protocol directly or indirectly i.e., a client using the handheld devices uses portal via WAP gateways and a client using telephone uses it via Voice Gateways. Based on the user agent (client devices), accordingly the appropriate markup language is used.

To better understand how to design the application that supports disparate clients I would suggest you read the "Building Internationalized J2EE Web Applications for Disparate Clients" article (www.devx.com/DevX/Article/9778/0/page/1).

The portal page that the end user sees is an aggregation of different set of portlets. Table 1 shows how WSRP portlets can be categorized into two types and shows the difference between them as well.

Local portlets can be accessed as remote portlets by some other portals, if our portal sever supports the WSRP producer specifications and WSRP services can be integrated into portals by wrapping them in adapter code written to the local portlet API. JSR 168 defines the standard API for this in Java programming language.

See Figure 7

As we know Registry (UDDI), SOAP protocol, and markup languages are the backbone for any Web service architecture. Here it's also the same. The process of engaging a WSRP is shown in Figure 8.

Publishing Web Services for Remote Portals - The WSRP producer must publish WSRP to a Registry (UDDI directory). All WSRP must follow the WSDL interface and behavioral contracts standards.

Finding and Binding WSRP Services - A WSRP consumer can find the WSRP by querying the directory for registry (UDDI directories). During binding the WSRP consumer will typically store WSRP information for administrative purposes and in order to keep information on how to invoke the service. During this time the WSRP consumer creates/uses the generic proxy portlet.

Invoking WSRP Services - The WSRP consumer passes the information about the user's request and portlet handle (a unique identifier for portlet) to the WSRP service and returns to end user the response it receives from the WSRP producer.

Now let's understand implementation process of WSRP. Since we are a technical people we should also understand how the features have been implemented as well as the major sequence flow(s) for a clear view and better understanding.

As we know WSRP producers are modeled as containers of portlets. The producer provides a set of Web service interfaces and by implementing these interfaces, and agreeing to conform to WSRP, both producers and consumer can use a standard mechanism to offer and consume portlets. The following are the WSRP interfaces defined in the WSRP specification (See Figure 9):

• Service Description Interface: This is a required interface and it must be implemented by a WSRP producer to provide metadata of itself and the list of portlets it offers.
• Registration Interface: This is an optional interface. It is used to establish a relationship between a WSRP producer and a WSRP consumer. This interface provides the mechanism for a WSRP consumer to register with a WSRP producer and lets the producer customize its behavior for each WSRP consumer based on the registration information.
• Markup Interface: This is a required interface and it must be implemented by a WSRP producer to generate markup and to process interaction requests.
• Portlet Management Interface: This is an optional interface and it is implemented to grant access to the life cycle of the hosted portlets. This interface also includes property management, which enables programmatic access to a portlet's persistent state. In addition to this it also allows WSRP consumers to clone/destroy portlets, and also to customize portlets by changing any associated properties.

In order to understand the significance and usage of these interfaces, let's have a look at the sequence of basic flow (see Figure 10). We will be discussing the very basic and minimal basic sequence flow and some key points. For more details such as the method signatures, attributes, data structures to be used, etc., refer to the WSRP specifications. In the sequence diagram every sequence arrow in between consumer and producer has two parts:

1. First (shown above the arrow) - represents the functionality/activity
2. Second (shown below the arrow) - represents the method name/XML attribute name that comes into the picture while actually performing the activity defined above the arrow

• Figure 11
• Figure 12
• Figure 13