The entire basic sequence flow is divided into three sections.

1. Initialization Section - Discusses the sequence of events that occurs between consumer and producer for handshaking/registration process for opening a communication channel
2. Interaction Section - Discusses the sequence of events that occurs between end user, consumer, and producer
3. Termination Section - Discusses the sequence of events that occurs between consumer and producer for termination/deregistration of the communication channel

Initialization Section
1.  The WSRP consumer obtains a description of the producer, and the list of portlets that the producer offers in order to aggregate portlets offered by a producer. For this the WSRP consumer sends a request for the getServiceDescription operation of the service description interface.

2.  The WSRP producer looks up its repository and sends back a response (getServiceDescriptionResponse) to the WSRP consumer. This response holds the information such as whether registration is required or not, Locales supported, list of offered portlets, supported MIME types, and Window and Modes supported.

3.  If the registration is required then WSRP consumer sends a request for the register operation of registration interface to the WSRP producer. Currently WSRP 1.0 supports two types of registration:

• In-band registration. Here consumer provides all of the required information to the producer using the Registration Interface (also shown in sequence diagram).
• Out-of-band registration. To establish registration, in this case both parties follows the business process that they mutually agreed upon such as Web applications or e-mail, etc. It is not standardized in the WSRP specification.

For registration, the consumer provides DUNS (Data Universal Numbering System) and Service ID, which they received as a part of getServiceDescriptionResponse. In addition to this the consumer name, version, and Method GET supported information are also sent to the producer.

4.  The WSRP producer validates this request for registration, creates a registration context, and sends back registerResponse to the WSRP consumer. The registration context contains a unique registrationHandle, which is valid for a lifetime of WSRP consumer's registration, and registrationState (optional).

Note: It is advisable that the WSRP consumer should store this registrationContext as it is required to provide this with all subsequent requests to the WSRP producer.

After this Generic proxy portlet is used for each end-user request. The generic proxy portlet is stateless in nature and it gets instantiated either when the first portlet is registered or at the first time a request comes for any of the portlets and it is dependent upon the WSRP consumer implementation.

Generic proxy portlets are generic portlets that eliminate the need to develop specific portlets for each Web service to plug into the portal. Because of these types of portlets, remote Web service portlets get included into the portal and the user accesses them as a local portlet. All user requests for any operation on any portlet of any WSRP producer go through generic proxy portlets. Basically a generic portlet does the same thing that HttpServlet does for us because it routes the request to the corresponding WSRP producer for a requested portlet.

From an implementation point of view, the generic proxy portlet in the WSRP consumer can be implemented in different ways. Some of the scenarios described below.

• Many to Many: There is only one instance of a generic proxy portlet that is being shared among all end users and the WSRP producer
• One to Many: There would be one instance of a generic proxy portlet that corresponds to each end user
• Many To One: There is only one instance of a generic proxy portlet corresponding to each WSRP producer

Each of these approaches has its own benefits and limitations in terms of performance, handling requests, etc., and although it depends on the WSRP consumer implementation, in most cases the WSRP consumer follows "many to many" approach.

Interaction Section
Now by this time the WSRP consumer has established the communication with the WSRP producer and has gathered all of the information about services. Now in order to display an aggregated view to end users, it is required that the WSRP consumer must first obtain the markup of each portlet from each WSRP producer.

1.  When end users access the portlets on the WSRP consumer portal/Web site, the WSRP consumer sends the request for the getMarkup operation of markup interface to the WSRP producer. While making the request along with registerationContext, the WSRP consumer needs to send information like end-user preferences, the locale and MIME types supported, user agent information (i.e., PDA, WEB, etc.) and protocol used (e.g., HTTP, HTTPS).

2.  The WSRP producer sends back getMarkupResponse to the WSRP consumer. This response contains markup information (MIME type, locale, title, etc.) and session information (i.e., sessionID), and finally WSRP consumer sends the proper response to the end user for its request.

3.  Now consider a scenario in which the end user does some processing information (i.e., form submission). For this WSRP consumers can send the request for performBlockingInteraction operation of markup interface, the submitting end user's form data to WSRP producer. During this time the portlet can perform various activities such as:

• It can access and process the request data. It can change its navigational state and can make persistent changes to its state.
• It can change its own current mode and/or window state.
• The WSRP producer can choose to generate and return the portlet's markup as an optimization.
• It can request the WSRP consumer for redirectURL.

If there is a need, or it's required, or there is a chance to make changes in portlet state, then the WSRP consumer sends 'cloneBeforeWrite' as a value for the portletStateChange element in the performBlockingInteractionRequest to the WSRP producer for creating the clone of a portlet. The WSRP producer creates a clone and returns a portletContext with a new portletHandle and/or portletState.

4.  The WSRP producers send back PerformBlockingInteractionResponse based on the processing. This response contains sessionContext (i.e., new sessionID), markupConext, redirectURL (absolute URL)/updatedResponse (i.e., new navigationalState or we can say expected response), and finally the WSRP consumer sends back an appropriate response to the end user.

• Figure 11
• Figure 12
• Figure 13