Portlets and Remote Scripting

Question

My questions center around whether Portlets that adhere to the WSRP or JSR 168 specifications can also employ technologies like remote scripting without causing the Portal to rebuild the entire page. I've already had some discussion with the JSR-168 group and it seems that JSR-168 and Remote Scripting don't play well together. However, I haven't received a fully satisfactory response from the Sun folks and am hoping the Plumtree Portlet folks can shed some light on this issue.
I'm using the term "remote scripting" in the broadest possible sense to include technologies where a sub-section of a markup fragment (<span> or <div>) is dynamically updated via an asynchronous, background call to the server.
The point of "remote scripting" is to avoid reloading the entire Web page in order to provide a richer user experience than a typical Web page. This is the technology behind the "rich internet application" movement a la Macromedia, Laszlo Systems, etc. where single-page experience is the foundation.
I have two specific examples of Remote Scripting in mind:
a) JavaScript remote scripting (JSRS) is a JavaScript framework that uses a hidden IFRAME embedded into the Portlet markup fragment to make asynchronous calls to the server to dynamically update sections of the Portlet without reloading the entire Portlet. Briefly, JSRS works as follows: 1. JSRS uses a hidden IFRAME to make background calls to the Server 2. JSRS sets the URL for the IFRAME's src to invoke a Servlet; updating the SRC in JavaScript triggers a call to the Server. 3. The response written by the Servlet is just HTML that uses an onLoad JavaScript event handler to callback into the JSRS framework 4. The onLoad event is fired when the browser loads the new page for the hidden IFRAME, this triggers the JSRS callback mechanism that allows my Portlet to update a section (using a SPAN or DIV) on the Portlet in a dynamic, asynchronous manner. (see Brent Ashley's JSRS site: www.ashleyit.com/rs)
b) Flash Remoting. If my Portlet is a Flash Movie (the HTML fragment generated by the Portlet uses a Object/Embed tags to include an SWF), then the Flash Movie could use an XMLSocket object in ActionScript or the Flash Remoting API to talk to a Web service to dynamically update sub-sections of the Portlet, such as dynamically populating a ListBox in response to some user action.
I have three (3) questions:
1) From a cursory reading of the JSR-168 specification, it seems that all action-oriented URLs embedded in a Portlet must be Action URLs that have been re-written by the Portlet Container to force all traffic from Portlets back through the container. Is this a true statement?
In other words, is a Portlet allowed to make any server requests that do not use a re-written Action/Render URL? For example, POST to a Servlet running in another Web application in the same WebLogic instance? I understand there are single sign-on issues that need to be addressed, but assuming you configure the application server so that security credentials propagate from the Portlet to this other Servlet, can you do this?
2) Is there a way to update sub-sections of a Portlet without having the Portlet Container reload the entire page? In other words, does the JSR-168 specification have any provisions for using remote scripting inside a Portlet?
My sense is that the two techologies "standard portlets (JSR-168 or WSRP)" and "remote scripting" are incompatible at this time. This is a shame because it means that providing a rich Internet application experience in a portal will require developer's to abandon these specifications in favor or Portal Server specific approaches.
3) Lastly, does Plumtree have a solution to address this problem--i.e. if I build a Plumtree specific Portlet using your SDK, can I use remote scripting?

Answer 1

A few issues:
1. The idea of remote scripting runs counter to the idea of processAction. That is, processAction is blocking and expects other portlets on the same page to redraw after processAction is completed for the target portlet. Remote scripting means refreshing in place with no impact on other portlets. So it's difficult to see how remote scripting could be integrated into the specification.
See PLT.5.2.4:
If the client request is triggered by an action URL, the portal/portlet-container must first
trigger the action request by invoking the processAction method of the targeted
portlet. The portal/portlet-container must wait until the action request finishes. Then, the
portal/portlet-container must trigger the render request by invoking the render method
for all the portlets in the portal page with the possible exception of portlets for which
their content is being cached.The render requests may be executed sequentially or in
parallel without any guaranteed order.
2. Plumtree specifically does not use the servlet container for the values of getRemoteUser() and isUserInRole(). This is because:
(a) our users expect to get the authenticated Plumtree user.
(b) The ways that users can be authenticated in a servlet container is specific to that vendor and version. For example, Tomcat returns whether the user is authenticated as well as the roles when the user logs in. BEA sets the roles in a weblogic.xml file. In other words, there is no uniform api for all servlet container vendors at this time. As a result, many web application authors will use their own mechanism (e.g. authenticate against LDAP), rather than release multiple versions of their product for each app server and version.
3. To reference another servlet, make sure that the url to the servlet is in the gateway space, and then use the EDK to get the remote user name. This will return the same value as getRemoteUser in the jsr-168 portlet. If you just call getRemoteUser() on the servlet, it will return null, as we did not authenticate against the servlet application, we authenticated against the portal.
Hope this helps.