Modular Web application - portlet? native? Something else?
I am struggling with how to create a modular web application. To wit, I am building a Web-based application that consists of modules. There is obviously a Core module, which contains the main login that every instance gets. However, I would like it to be modular. In other words, it should be possible to load and unload Modules in the future. The reasons for this are:
- reliability: I do not have to retest the entire application for each component upgrade
- extensibility: If a new feature is desired, I can add the feature as a Module, rather than rewriting the entire webapp
- licensing: if customer A has licensed modules Core, A, B then I only need him/her to load Core,A,B
Since the Core contains the primary data model, the Core will never need to know about the objects (persistent and otherwise) in other modules, but the other ones will need to know about and access (if read-only) Core objects.
As an example, let us assume that the application is an employee management system. The Core contains information about the employees and basic personnel manipulation pages and logic. Module A might contain performance reviews (UI, logic and data model). I can load Module A in, license it, and now it is possible to select "Performance Management." The Core knows nothing about the A features, but Amust know about Core to get the list of employees. Further, Core and A must both be able to persist, likely using JPA. Core persists employee information, A persists performance information referring to the employees (but never modifying employee information itself).
What is a reasonable way to go about doing this? I considered portlets, but then each "module" is a portlet application, and getting one portlet application to know about others, let alone share information and DataSources or EntityManagers, is difficult. I could go full EJB, but then I need to deploy the module to both the Web container (for UI, etc.) and to the EJB container.
Is there some sane way to do this, effectively a "plugin" oriented Web architecture?
Thanks to all who help.
[2131 byte] By [
deitcha] at [2007-10-2 20:33:53]
Moduler or Non Moduler an application is just a bunch of Java classes/Servlets/Jsps/EJBs but to make it module all you have to do is properly organize the functionallty of the application in to modules.
Basically you will have to follow the following rules
1. Closly related activities will come under one module.
2. Each modules will have an associated level, A higher level modules can access services in lower level modules (Ex:- Your base module will be the lowest level one). But rule 3 should apply
3. Higher level modules can have dependancies on lower level modules. If module A depends on the module B thee who ever use module A will need module B too.
So you will have to build a dependancy tree based on the functionality you going to cover.
Rest is just programming..
LRMKa at 2007-7-13 23:17:02 >
LRMK,
Thank you for the suggestions. I like the tree concept, although in my case I will grossly oversimplify it. There will just be 2 levels: the core, and the second tier.
My problem is the management and deployment. The second (higher) tier needs the following functionality:
- persistence: the datasource is managed by the lower core tier, so the higher tier needs to either access an EntityManager or DataSource that is either retrieved somehow of injected. The second tier module is not responsible for storing/retrieving anything but its own persistent beans (let us say @Entity, for argument's sake), but it must be able to do that. However, the lower (core) tier is not responsible for managing any persistent data from the higher tier.
- access: much of the data in the lower core tier needs to be accessed by the higher tier. How, exactly, will this tier get access to those beans that contain data? Injection? Something else?
Deployment is the other issue. Assuming I package up lots of classes, EJBs, servlets, JSFs, HTML, whatever you want in a jar. I then need to have this new jar:
a) be recognized by the framework as a new lower tier module
b) know what it is called so that it can be accessed via the UI
c) have its contained UI components (JSF pages, JSP, HTML, img, whatever) be made visible to the already running container
d) have the class components (controller, business logic, EJBs, etc.) be loaded correctly.
e) have its dependencies properly injected (data source management, etc.; see above). Need to ensure that @EntityManager or @EJB resolves to the right thing.
As far as I understand, the EE (EJB and servlets) paradigm and portlet paradigm don't really support this. Each war or ear is deployed once. Adding components in real-time doesn't play in. Even JSR168 portals, which support dynamically adding portlet applications, are just adding a new war under a new context, in other words unconnected to the first, which makes it not very useful in this case. Here I want dynamicity not of adding portlet applications, but of adding and removing portlets within a single portlet application.
Thanks
