I will give a BOF at JavaOne 2006 entitled "Portlet development best practices".
The Portlet specification allows people to create portable components for portals. It offers an API that allows developers to create personalized content for end users. This session aims to teach about how to develop a portlet that is a good citizen of a portal and how to leverage the Portlet API at its best.
In order to prepare and promote this event I am gathering input from the Portlet community and I would like to know what people would like to learn and talk about. The most appropriate places to discuss about this are the group that I created on the JavaOne Conference site and that topic on our forums for those who don't go at JavaOne but still wants to discuss about it.
Thanks our numerous contributors we have been able to release the first release candidate of JBoss Portal 2.0.1 which is the first maintenance release of the 2.0 branch. This release adds new new features and fixes a few bug.
A lot of work has been made here :
The Content Management System of JBoss Portal uses Slide as a back end storage. The Slide service then delegates to something called store the responsability of storing nodes. The default implementation uses a file system and has some drawbacks. The first one is the very poor scalability in a concurrent environment, the second one is that it simply does not work in a clustered environment (don't tell me to use a shared file system), the last one is that it uses the file system itself and not a database.
So I tried to use the JDBC or J2EE store implementation that delegates to a database and here again I am not happy with it. While it solved the scalability problem it raises the portability issues. The store implementations are specific to databases, for instance you have one for MySQL, one for Postgresql, etc... The other issue I have with it is that the way it gets the datasource in a J2EE environment assumes that you are running it from a servlet thread. While it may be true most of the time sometimes the store is called from a service thread.
We solved the previous points by developing our own store implementation based on hibernate which is highly configurable and provide portability accross many databases. Also we did a standalone release that I call JBoss Slide that integrates Slide in JBoss in the best way possible and provide also an implementation of cache invalidation which uses JBoss clustering under the hood featuring things like auto discovery (in the default Slide clustering, you have to hardcode the list of the other cluster nodes in each node) and configurable invalidation transport (JMS or IP multicast).
By the way if someone has access to the Slide Wiki, that would be a good idea to put a link to the JBoss Slide page.
Every release has its bugfixes, it's boring to list them all so please consult jira for more infos.
In conclusion, this is an important release, yet we are working very hard on releasing JBoss Portal 2.2 (scheduled for November 05) which will add more exciting features (I coded over the weekend an implementation for Portlet session replication for instance). To hear more about JBoss Portal 2.2 and how we implement it, I will give a talk at JBoss World Barcelona, October 10-12. I would be pleased to meet anybody to talk about portals.STAY LETHAL!!!
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 ?
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
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
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 :
Finally in our case the firts conversion could have looked like :
Ok the conversation ended up the same but at least the second guy did not look stupid.
- We need IPC/xlink
- ok, why don't you try IPC/session rather ?
- no it is not what I need
- ahhh... ok sorry
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 :
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 :
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 :
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 :
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.
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 :
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.
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 :
Separate the invocation stacks
one global stack invoked at each request that apply request scoped aspect, for instance :
one local stack per portlet where aspects focus on the request to a single portlet, for instance :
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.
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.