Skip navigation
2005

Julien Viet's Blog

July 2005 Previous month Next month

The recurring interportlet communication dilemna

First the we need to shorten the name "interportlet communication", I propose IPC.

Often people on our forums talk about IPC. The thing is that this is always ambigous in the sense that they are not talking about the same thing. After all what is the exact meaning of the term ? It loosely means that portlets communicate between themselves. Well if you read the JSR 168 specification it is obvious that the component model they have built works isolated, meaning that a portlet has access to information about itself or can trigger events that will affect itself.

So you can see on our forums conversations that looks like : 

- we absolutely need IPC
- what if you put the object in the application scope of the session
- what do you mean ? I want to provide a link to another portlet
- ahhh.... ok sorry


It shows that people need IPC, because in the real world portlet never work alone and they need to exchange some kind of information. But before IPC, before all they need names to have non ambiguous conversations. Even internally we have the same issues, for instance here is an excerpt of my IM conversation with Roy : 

julien: why do we need to talk with Ben ?
julien: I don't see the reason
roy: we should tap him for ipc too, no?
julien: IPC ?
roy: no
julien: it should be possible to do it without JBoss Cache using some tricks with the HTTP session replication (which uses JBoss Cache under the cover)
roy: then we dont talk to Ben
roy: most vendors have their own api for ipc
julien: it depends what you call IPC
julien: they have IPC API for events
julien: not attribute session sharing
roy: this seems to be the ipc that people want... not the session hack
julien: or for do cross linking
julien: so what do you call IPC ?
julien: at the end perhaps we don't speak the same language
roy: portlet A action triggers reponse in portlet B
julien: yes
roy: yes. i speak spanish, u speak french.
julien: JBoss Cache is not going to help you doing cross linking
julien: JBoss Cache replicates object
roy: implementing cache, couldnt you get all the above forms of IPC to work?
julien: it does not make linking
julien: we really need to define a language
julien: let's define
roy: we need to define ipc
julien: IPC/xlink
julien: IPC/event
julien: IPC/session


You see what I mean ? I am a big fan of naming concepts, so then people can refer to it with a simple name. It is how we started to put names on those concepts.

 

So far from my personnal experience, I have seen three forms of IPC :

  • IPC/session : portlet sharing objects, this is possible today by using the PortletSession provided during the request and using the application scope. However there are limitations in the sense that the portlet need to be bundled in the same application to be capable to share objects.
  • IPC/xlink : A portlet provides a link to another portlet : this is not possible today. I have a hack in mind to resolve that but this is really an hack that should work with any container :-) .
  • IPC/event : A portlet is capable to create events that are consummed by other portlets.
I don't pretend to know all the form of communication between portlet, perhaps I am missing some others.

 

Finally in our case the firts conversion could have looked like : 

- We need IPC/xlink
- ok, why don't you try IPC/session rather ?
- no it is not what I need
- ahhh... ok sorry
Ok the conversation ended up the same but at least the second guy did not look stupid.

 

My colleague Tom Bayens, project lead of jBPM, asked me questions regarding the web frameworks and the portlet specification. This has been debated at Javaone with the web frameworks smackdown and Stan Silvert presented a session on JSF and portlets.

 

The questions Tom asked were :

 

 

  • what is your take on portlet versus webframework ? if it takes some time for the webframeworks to support portlets, there must be some gap or mismatch between them.
  • do portlets need a separate framework or do you think that plain webframeworks can add satisfactory support for portlets ?
  • another question is how limiting is writing a webapp to a bridge so that the same webapp can be used as webapp and as portlet. will this become mainstream ? or will this never be possible without serious limitations

 

 

 

I am not capable to give a full comparison matrix of all the frameworks, however I can talk about what I know : interraction with a portal and I can extend on JSF and struts.

 

If the web frameworks want to evolve in the portlet market, they must adapt to the portlet environment and there are mismatches :

  • protocol mismatch : how the interractions occurs, the portlet defines a two step protocol with a clean separation between the phase where you perform an action and the phase where you render the portlet. In my opinion it is one of the best thing of the portlet specification.
  • API mismatch : it is different from the servlet API and less hacks are possible, like the deadly usage of HTTPServletRequest#getRequestURI()
  • invocation mismatch : needs to use a PortletURL to perform invocation to itself and not create URLs directly
  • context mismatch : portlet have portlet mode, window state and preferences which influence the markup of the producer
  • markup : a portlet is capable to produce markup adapted to a specific device (cellphone for instance)


 

JSF is slightly different in the sense that it is agnostic of the execution context (servlet of portlet). JSF is designed to run from the beginning with portlets and servlets whereas other framework not (cf. Stan's presentation).

 

It seems that if you need to run your apps in those two contexts, today JSF is the framework to use :

  • it has a spec
  • it is integrated in JEE 5
  • it should have decent tools
  • it can adapt its markup because it has renderers, this is a great asset for JSF to have skinnable components and have the behaviour of the component decoupled from the markup used


 

But I think that there is a gap for a simple framework for portlets. As said we have JSF but it is complicated. I will change my mind if someone can explain me in 1 hours how JSF works (not how to write an hello world application).

 

Also JSF does not care about the execution context. For instance if the window state is MAXIMIZE, MINIMIZED or NORMAL it will render the same markup.

 

Then we have Struts Shale a web framework that is based on JSF. I don't know if it makes sense or not. If it exists, does this mean that JSF is not sufficient by itself ? Or people want to have a Struts like programming model (Model 2) rather than of component model ? So I don't know yet what to think of that effort.

 

For other frameworks, I don't know them much so I will not critisize but try to comment anyway :

  • Tapestry has a similar model to JSF, so it cannot compete, except with technological innovation. It seems that Tapestry has always been a techonology innovator, however it has always been complicated to use it. I know that Howard simplified Tapestry a lot since the 3.x series after an constructive discussion with another colleage of mine
  • Struts will finish his life peacefully as it is planned, yet it should be continued to be used imho because it has lot of momentum
  • Webwork : I don't know it
  • Wicket : I haven't looked at it yet

  •  

    To conclude, JSF has a satisfactory support for portlets so you can invest your resources here. However there is a place for a specific portlet framework that would leverage portlet features that are not used by othe frameworks like portlet modes and window states.

What architecture changes will you see in JBoss Portal 2.2 ?

Module overview

 

First let me give you a overview of the different functional modules we have in JBoss Portal 2.2 :

 

The base module is the server. The server goal is to provide the middleware infrastructure that is leveraged by other modules. By that we mean all the low level services of the server, like :

  • Deployment : this service is integrated with the JBoss microkernel deployment layer in order to intercept war files and create containers based on the deployment descriptor it can find in web archives. The other responsability task is to instrument web containers in order to introduce servlets that will provide the server a way to invoke portlets deployed in the war files. The current implementation of the deployment service is totally transparent and does not require any modification of the war files you deploy in the directory /deploy of JBoss application server.
  • Invocation : defines how we perform invocation at different levels and most importantly how the layers communicate and exchange information. This is going to be discussed later in this article.
  • Container : simply an abstract notion of container that is reused in the server for different purposes.

 

Then we have the portlet module which implements the portlet container API contracts defined by the JSR 168 specification and depends on the server, the theme module which defines our theme framework.

 

Finally the core reuse all the above modules and provide our business implementation of the portal based on additional services like user management and content management.

Changes since 2.0

 

After having introduced the different modules of the whole portal, we can concentrate now on the server. I will describe now in detail the pipeline used during the rendering of a portal page.

 

For the 2.2 release keep the same aspect based approach but we introduce a little bit more flexibility in the stack. The approach we chose for 2.0 is based on a unique stack, the main changes we added are :

  1.  

    Separate the invocation stacks

     

    one global stack invoked at each request that apply request scoped aspect, for instance :

    • Retrieve user
    • Determine the content type
    • Determine the locale


     

    one local stack per portlet where aspects focus on the request to a single portlet, for instance :

    • navigational state
    • compute preferences
    • request dispatching


  2.  

    Introduce a controller between the two stacks

     

    The controller goal is to let the server implement a specific behavior when a request is done to the portal. For instance, in order to test the portlet container we have a very simple controller that does nothing but aggregate portlet and invoke them. The controller has total freedom on what it does as it is placed between the server stack and the component stacks. In fact it is really up to the controller to decide what components are involved in a request, perform the interractions and aggregates the results in the response sent to the client.

     

    The core portal in JBoss Portal is built on top of this server + component framework and leverages a more complete controller that is based on pages to tie portlet together, therefore we provide a specific implementation of the controller.

  3.  

    As you can see on the picture, the invocation stack reuse a generic invocation API that is well adapted for the portal environment The calling layer creates a detyped Invocation object which contains the Request and Response. When doing such it must implement a service provider interface (spi) in order to provide services to the layer it is calling, these are symbolised by the RequestContext and the ResponseContext interfaces.

     

    Once the calling layer has created an Invocation, it uses it to call the layer it is targetting and between the calling and the called layer we apply a set of Interceptor that create step by step the context into which the called layer will operate. For instance, deciding the content type for the life time of the request is done at this places.

     

    This approach gives the opportunity to have a very flexible approach for the implementation as it is possible to fully customize the invocation stacks.

Conclusion
We have seen how JBoss Portal is organized as functionnal modules and how the server module invocation pipeline works. This is still a work in progress and JBoss Portal 2.2 will see new features and modules like the WSRP specification which is being implemented as a separate module. If you are willing to help on this effort you are welcome to contribute by visiting our forums which is the main place to start and the JIRA tracker.