I would say that WSRP is "theoretically" transport-agnostic. However, as I pointed in the topic linked to in Anil's message, some methods of WSRP are not. Plus, WSRP is used a portal environment most of the time so HTTP is the preferred transport by default. I am not aware of WSRP use cases over other transports...
my humble opinion is that :
1/ wsrp is transport agnostic.
2/ there is a mismatch between specifications : the Servlet specification and the Portlet specification.
The way to solve it would be to develop or have a tomcat connector that the portal could use to perform a request dispatch in the right servlet container using provided request/response. I believe it exists (I discussed with Remy one time).
However there is no J2EE / JEE5 portable solution to that today.
and I add that the current solution we have based on the servlet filter is the most portable we have accross servlet containers.
A blog entry from Subbu (BEA representative on Portlet 2.0 and probably architect of BEA Portal) : http://www.subbu.org/weblogs/welcome/2006/04/angle_brackets.html at the end he drops a few lines on the debate wether WS client can be transport agnostic or not. He explains why this is not the case with WSRP : "For starters, a WSRP producer is a web service that can be used to view/invoke portlets. In the J2EE world, portlets mostly run on top of the servlet container. For a WSRP producer to be able to interact with the servlet runtime, it needs access to servlet request and servlet response. So, most WSRP producer implementations out there use some internal/proprietary APIs to get hodl of these objects from the servlet container."