JSR-168 and WSRP work at different levels. JSR-168 specifies the interfaces for local portlets into their container (e.g. Jetspeed, uPortal) whilst WSRP specifies the interfaces for accessing portlets across portal frameworks. These have to be aligned using the same notion of the objects and ability to instantiate portlets locally and remotely. Details of the portlet API have to be exposed via WSRP in order to do this. The use of WSRP and JSR-168 in a typical portal architecture is shown in Figure 2.
It is important to note that you don't need a portal framework to serve WSRP compliant content. It can be served as any Web service would be (e.g. using Apache with C gSOAP, Perl SOAP::Lite, etc.). This avoids content providers having to tackle issues of installing additional software like Tomcat. This is also an important aspect of wrapping more traditional applications for presentation via a portal framework. For Java programmers, WSRP4J  can act as a bridge either to publish a JSR-168 compliant portlet as a Web service or to ingest the WSDL referring to a WSRP service and produce the required JSR-168 interface to plug into a portlet container such as uPortal, Jetspeed or LifeRay.