Inside WSRP
Pages: 1, 2, 3, 4, 5

Session Handling

Sessions are an important part of web application development, and the WSRP protocol allows Producers to manage sessions for Consumers. Just like the way browsers can participate in sessions with web servers, WSRP Consumers can participate in sessions with WSRP Producers.

In the above example, look at the first getMarkupResponse message again. This response included a sessionContext element as highlighted below:

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
   <soapenv:Body>
      <urn:getMarkupResponse xmlns:urn="urn:oasis:names:tc:wsrp:v1:types">
         <urn:markupContext>
            <!-- Snip --->         
         </urn:markupContext>
       
                        
  <urn:sessionContext>
            <urn:sessionID>
            B9Ml78JJyZNrMbzKnPxfyXZj511LL420BfKZGmLssNG02DbSJm3y!-1979539005
            </urn:sessionID>
            <urn:expires>3600</urn:expires>
         </urn:sessionContext>
      </urn:getMarkupResponse>
   </soapenv:Body>
</soapenv:Envelope>
                      

This element indicates that the Producer created a session for the portlet and that the session expires after 3600 seconds. When a Producer returns a sessionID, the Consumer is responsible for keeping track of the sessionID and supplying it with future requests to the Producer. The following performBlockingInteraction request shows this sessionID.

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
   <soapenv:Body>
      <urn:performBlockingInteraction xmlns:urn="urn:oasis:names:tc:wsrp:v1:types">
         <!-- Snip -->
         <urn:runtimeContext>
            <urn:userAuthentication>wsrp:none</urn:userAuthentication>
            <urn:portletInstanceKey>search_1</urn:portletInstanceKey>
            <urn:namespacePrefix>search_1</urn:namespacePrefix>
             
                        
<urn:sessionID>
               B9ZVFSbYrxv74C8pnsyspSp2hW1ZnnXkPvzXHxrX3kgTbTQ0Jp4C!-1979539005
               </urn:sessionID>
         </urn:runtimeContext>
         <!-- Snip -->
     </urn:performBlockingInteraction>
   </soapenv:Body>
</soapenv:Envelope>
                      

WebLogic Portal Consumer stores this sessionID in its user's HTTP session and supplies it with future getMarkup, performBlockingInteraction, and handleEvents requests. In a WebLogic Portal, all portlets in a given Producer web application share the session. So, for each user interacting with a Consumer, the Consumer maintains one session with each Producer. The Producer session remains accessible as long as the Consumer is able to supply the sessionID. If the user's session on the Consumer times out before the corresponding sessions on Producers time out, the Producer's session will be lost.

Tip: The Consumer's session timeout interval should be at least as long as the Producer's session timeout interval for users to be able to work without losing sessions for remote portlets.

Clustering Producers

WebLogic Portal Producer and Consumer implementations are designed to support clusters. Since the Consumer is just a web application, you can set up Consumer clusters as usual. You can also enable replication in a Consumer cluster, so that it can take advantage of Web Logic Server failover. WebLogic Portal Producer is also designed to support clustering and failover. However, it requires Consumer support for load-balancing, replication, and fail-over to function. In order to enable this support, WebLogic Portal Producer uses an operation called initCookie specified by the WSRP 1.0 protocol.

The initCookie operation allows a Producer to initialize cookies and return those over the HTTP response underlying the SOAP response. To see this in action, open the SOAP message monitor on any WebLogic Portal Producer web application. The URL for the monitor is http://<your-domain>:<your-port>/<producer-webapp-context-root>/monitor. When a user views a page containing a remote portlet for the first time, you will notice that the Consumer sends an initCookie request. Here is a sample request.

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
   <soapenv:Body>
      <urn:initCookie xmlns:urn="urn:oasis:names:tc:wsrp:v1:types">
         <urn:registrationContext xsi:nil="true" 
                 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"/>
      </urn:initCookie>
   </soapenv:Body>
</soapenv:Envelope>

In response, the Producer creates a cookie, sets it on the response, and returns the following response.

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
<soapenv:Body>
<urn:initCookieResponse xmlns:urn="urn:oasis:names:tc:wsrp:v1:types"/>
</soapenv:Body>
</soapenv:Envelope>

This response may seem unusual as the response body is almost empty. But if you view the underlying HTTP response, you will notice a Set-Cookie response header. The Consumer is supposed to supply this cookie with all future requests to the Producer.

To enable Producer clustering, WebLogic Portal Producer always requires Consumers to send an initCookie request once per user per Consumer. The Consumer is supposed to keep track of any returned cookies and supply those cookies with subsequent requests. WebLogic Portal Consumer stores these Cookies in its user's HTTP session.

Pages: 1, 2, 3, 4, 5

Next Page ยป