WebSphere Portal Server - PortletSession vs. HttpSession w/ AJAX

Author

PortletSession vs. HttpSession w/ AJAX

Brian J. Sayatovic

2005-09-26, 6:04 pm

We've been doing some tinkering with AJAX. We're also adopting WebSphere
Portal (v5 right now, v5.1 very soon). What we've found so far is that
we're unabale to share information from the user's PortletSession with the
AJAX code on the server. Our AJAX requests are going to an HttpServlet
because a Portlet can only be reached as part of a PortalPage, which has a
lot of HTML decoration around it. But as an HttpServlet, the AJAX code can
only reach the HttpSession. Meanwhile, our Portal-Struts portlet have been
storing everythign in the PortletSession.

What this means is that we've had to either (a) parameterize the data so
that the Portlet writes state information into the HTML so that the
XmlHttpRequest can pass the information back to the AJAX servlet or (b)
transiently pull up as much info about the user into the servlet on the fly
via an authentication cookie.

Solution A is flawed because it exposes too much information and state
control to the client which becomes a security liability. Solution B only
gets us to certain amounts of information about the user, but not the state
of what they were doing in said portlet.

Has anyone tackled this problem yet?

Regards,
Brian.

George Daswani

2005-09-26, 8:50 pm

The portlet session is actually stored in the httpsession except the keys
are namespaced.
List all the parameters in the HttpSession and you'll notice that the
portlet session name/value pairs are indeed in there..

We do something similar (being able to pass variables between servlets and
portlets in different war files) through the use of Tangosol Coherence.
We initialize a shared cache (Custom WAS Service) then we wrote some simple
utils that allows our developers to easily use said cache for session info.
Said container can easily be created/cleanedup by writing a SessionListener
(or implementing your own LoginUserAuth, LogoutUserAuth) using the
HttpSessionID as the key (httpsession id and portlet session id are the
same)

Shouldn't be too hard to implement the same thing as a HashMap of some sort
(it won't be clustered, neverthleess different war files can share info as
long as
they reside in the same server).

"Brian J. Sayatovic" <bsayatovic@amig.com> wrote in message
news:dh97t8$4nc2$1@news.boulder.ibm.com...
> We've been doing some tinkering with AJAX. We're also adopting WebSphere
> Portal (v5 right now, v5.1 very soon). What we've found so far is that
> we're unabale to share information from the user's PortletSession with the
> AJAX code on the server. Our AJAX requests are going to an HttpServlet
> because a Portlet can only be reached as part of a PortalPage, which has a
> lot of HTML decoration around it. But as an HttpServlet, the AJAX code
> can
> only reach the HttpSession. Meanwhile, our Portal-Struts portlet have
> been
> storing everythign in the PortletSession.
>
> What this means is that we've had to either (a) parameterize the data so
> that the Portlet writes state information into the HTML so that the
> XmlHttpRequest can pass the information back to the AJAX servlet or (b)
> transiently pull up as much info about the user into the servlet on the
> fly
> via an authentication cookie.
>
> Solution A is flawed because it exposes too much information and state
> control to the client which becomes a security liability. Solution B only
> gets us to certain amounts of information about the user, but not the
> state
> of what they were doing in said portlet.
>
> Has anyone tackled this problem yet?
>
> Regards,
> Brian.
>
>

Brian J. Sayatovic

2005-09-27, 5:57 pm

I am pleased to see a reply since previous Google searches have been
fruitless. But I was afraid this is the answer I would get.

What worries me is relying upon IBM's present implementation of how they're
shoving PortletSession data into the HttpSession. In the future, they could
entirely change how that's done and break any implementation I build on top
of that. But, this is the best I've found, and you're comfirmation that it
works.

Did you guys ever consider any alternatives? For example, maybe posting the
AJAX request back to a portal page, but setting that page up to have one
AJAX portlet. The returned response would have a bunch of HTML, but you
could zero in on the data in the portlet and extract/parse only that.

Regards,
Brian.

"George Daswani" <funks@socalsrt4.com> wrote in message
news:dha3vs$4lgq$1@news.boulder.ibm.com...
> The portlet session is actually stored in the httpsession except the keys
> are namespaced.
> List all the parameters in the HttpSession and you'll notice that the
> portlet session name/value pairs are indeed in there..
>
> We do something similar (being able to pass variables between servlets and
> portlets in different war files) through the use of Tangosol Coherence.
> We initialize a shared cache (Custom WAS Service) then we wrote some
simple
> utils that allows our developers to easily use said cache for session
info.
> Said container can easily be created/cleanedup by writing a
SessionListener
> (or implementing your own LoginUserAuth, LogoutUserAuth) using the
> HttpSessionID as the key (httpsession id and portlet session id are the
> same)
>
> Shouldn't be too hard to implement the same thing as a HashMap of some
sort
> (it won't be clustered, neverthleess different war files can share info as
> long as
> they reside in the same server).
>
> "Brian J. Sayatovic" <bsayatovic@amig.com> wrote in message
> news:dh97t8$4nc2$1@news.boulder.ibm.com...
WebSphere[vbcol=seagreen]
the[vbcol=seagreen]
a[vbcol=seagreen]
only[vbcol=seagreen]
>
>

2005-09-28, 2:51 am

I am looking for way to integrate AJAX into WebSphere Portal too.

I grow up your suggestion: We can create simple theme without any HTML decoration and assign it to pages with standalong AJAX portlets.

But i'am looking around for suggestion which uses same portlet without any hacks too.

George Daswani

2005-09-28, 2:51 am

I personally would not even want to use the Portlet as an AJAX datasource as
the portal theme/skin is applied to it. Forcing a portlet to use a specific
theme IMHO is a hack. Portlets are not meant to be used as a conduit for
data transfer (in Ajax apps) because in essence - they are just artifacts
of the whole page (hence you'll have to parse though dirty data)..

I see the the portlet/servlet approach in the same war file as a good
approach (yet, you'll have to do some work with the httpSession a bit if you
do not have a shared cache).. Try setting the content-type on a portlet

For example, try letting a user download a PDF report generated from a
portlet (on the fly) which is something that's easy to do on a servlet.

There's a couple of creative ways in converting Portlets that use the
PortletSession directly without requiring massive code changes - the
Delegator pattern is one such approach.

for example

public SomePortlet extends GenericPortlet {
public void doView(PortletRequest request, PortletResponse response){
PortletSession ps = new
ExtendedPortletSession(request.getPortletSession());
// the rest of the code uses the PortletSession like it normally
does
}
}

public class ExtendedPortletSession implements PortletSession {

private PortletSession portletSession = null;

public ExtendedPortletSession(PortletSession newPortletSession){
super();
portletSession = newPortletSession;
}

public void setAttribute(String name, Object object, int scope){
portletSession(name,object,scope);
// add some extra logic here to make the PortletRelated session
transparently available
// available to a Servlet in the same WAR file.
}

// other delegated methods here.
}

<romario13@gmail.com> wrote in message
news:1806111363.1127885267064.JavaMail.wassrvr@ltsgwas007.sby.ibm.com...
>I am looking for way to integrate AJAX into WebSphere Portal too.
>
> I grow up your suggestion: We can create simple theme without any HTML
> decoration and assign it to pages with standalong AJAX portlets.
>
> But i'am looking around for suggestion which uses same portlet without any
> hacks too.

2005-09-28, 2:51 am

(IMHO) AJAX is a hack for portal ideology

But suggestion must be in scope of declarated public IBM API. In the other hand we cannot to propose it for customers.

Why i have one's doubts to use portlet/servlet approach. Set of question:
- how can i use it in cluster environment?
- how can i access to original HttpSession from Portlet?
- how can i access to Portal Services and other Portal stuff which makes life easy?
- how can i receive portlet mode in secure way?
- and so on...

I think more of question has answer "it is impossible". If you knnow "how", please share your experience.

George Daswani

2005-09-28, 6:04 pm

<romario13@gmail.com> wrote in message
news:37163702.1127892987745.JavaMail.wassrvr@ltsgwas007.sby.ibm.com...
> (IMHO) AJAX is a hack for portal ideology

>
> But suggestion must be in scope of declarated public IBM API. In the other
> hand we cannot to propose it for customers.

That's the problem with developing portlets using the JSR-168 right now,
alot of required plumbing developers face in the real world are not defined
in the spec.

> Why i have one's doubts to use portlet/servlet approach. Set of question:
> - how can i use it in cluster environment?

If you are using the HttpSession explicitly, WAS server takes care of
replicating the HttpSession Info accross the cluster for you depending on
how you have it setup.

> - how can i access to original HttpSession from Portlet?

If you are using some sort of delegator pattern, on IBM JSR-168 portlets as
they are implemented right now uses the Pluto classes (WPS 5.1)

Hence the following

PortletSession ps = portletRequest.getPortletSession();
HttpSession httpSession =
(org.apache.pluto.core.impl.PortletSessionImpl)ps).getHttpSession();

then again, it's not a part of IBM's WPS public API and cannot be guaranteed
to exist on the next version.