[gatein-dev] Application registry (& co) design and WSRP support.

[Christophe Laprun]

Hi,

In the process of trying to integrate the WSRP consumer within GateIn,  
I found things that I find rather concerning design-wise. It might be  
a reflection of me not understanding the overall design so please  
humor me for a second.

In JBoss Portal, the integration of the WSRP consumer was rather  
seamless: a FederatingPortletInvoker (implementing the Composite  
design pattern) allowed us to register additional PortletInvokers  
(which is what WSRP consumers are) and present a single, unified  
interface to the portal. In essence, from the portal point of view  
there wasn't much of a difference between a local or a remote portlet.

GateIn does use the FederatingPortletInvoker concept and the WSRP  
consumers are properly registered with it. However, bridging over to  
Portal, it seems currently rather complicated to support WSRP portlets  
in a seamless fashion. The integration between the Application/ 
ApplicationCategory concepts and the Portlet Container is currently  
exposing internal details of the PC (the portlet id format) in rather  
crude way: hardcoded string parsing repeated in different spots.

This is bad for several reasons:
- This tightly ties the portal to the *implementation* of the portlet  
container instead of its API.
- This has performance impact as the bridge is done by extracting  
specific components from a String which might end up being parsed  
several times.
- The parsing code is not encapsulated and is repeated in several  
different spots.

More to the point, the whole Application concept is not adapted to  
supporting WSRP as it requires a portlet application name and portlet  
name to work. This can be emulated in WSRP (and I actually have  
working code to do just so). However, invocations do not work because  
the invocation code of the Portal hardcodes (again) specific knowledge  
of the internal PC implementation (specifically, the format of portlet  
ids). Moreover, this break of encapsulation also prevents the  
FederatingPortletInvoker to do its job properly as the portlet ids are  
improperly recreated from the formerly extracted application and  
portlet names, hardcoding the invoker id of the local invoker.
This is embodied particularly in the ApplicationState.update method:
producerOfferedPortletContext = PortletContext.createPortletContext 
("local./" + applicationName + "." + portletName);

So to sum up:
- Application concept is not appropriated to supporting remote portlets.
- Information specific to the portlet container implementation is  
extracted from String versions of PortletContexts only so that said  
PortletContexts can then be recreated in a way that prevents proper  
dispatch of requests to WSRP consumers.

Solutions:
Get away from solutions that require knowledge of internal  
implementation and require multiple String operations by using the  
PortletContext everywhere application name / portlet name is used.

Cordialement / Best,
Chris

==
Principal Software Engineer / JBoss Enterprise Middleware Red Hat, Inc.
Follow JBoss Portal: http://jbossportal.blogspot.com / http://twitter.com/jbossportal
Follow me: http://metacosm.codepuccino.com / http://twitter.com/metacosm