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 :
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
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.