:: Technical Requirements ::
The technical requirements were particularly hard to setup. There are many factors to
be taking into account, and they have to be carefully considered before making any big
- What are the performance requirements ?
- Should the application easily be portable over different application servers ?
- Are there any products of preference, such as an existing database ?
- Can we afford to use commercial products ?
- Which features that affect product selection are a must have ?
- etc ...
As we try to remain as portable as possible over different application servers
it is not always easy to do so. The most important example is the security layer
we will need to implement, in general it is a good practice to use
proprietary application and web server technologies as a security framework.
We also agreed on using open-source tools and not going for commercial solutions,
this project should be completely free, no exceptions. However, switching one of
the modules (such as the data-source vendor) should be optional.
For this reason the first releases will be built on a combination of the following
On the other hand, we have some ideas in mind that will get some more concrete form in the
future, these include:
- Using Hibernate (which is well integrated with AndroMDA) as a persistence layer
- Support for commercial products such as Orion, Weblogic
- Web Services
Let's elaborate some more on the issue with the security layer. As I already explained
the security should not be in the business but rather an independent module in the
complete system, some application server have very interesting features which allows
seemless integrating of a security implementation. Consider these two points:
JBoss supports an interceptor stack that intercepts calls to beans and allows
custom implementation anywhere in that stack.
This is a very useful feature since it only requires a piece of code in one
location and a configuration in another location (a custom interceptor and an
update of the jboss.xml respectively), as opposed to having to clutter business code
with security calls - while this is not really a big deal I find it more interesting
to apply security on the level of the application server directly - this is also
proven to be more stable, scalable and secure; security is not the main business
of Jeteam, so we decided to go into this direction.
The disadvantage, of course, is this solution ties to the application server;
on the other hand we are convinced support for other application servers is
straightforward, so we could add it aferwards anyway. Personally I agree with
Rod Johnson's point of view: which sacrifices are you willing to make for app server
portability (Expert one-on-one) ? In the case of Jeteam we have a non-commercial
application, so we do whatever we like since there are no hard technical requirements
in this context. If somebody really needs compatibility for another server we can
always do the work. This approach is both realistic and pragmatic and IMHO the best
one in the long run.
Security is also delicate issue on the web-server, if we want authentication
and authorization using our own data-source we must need to configure the web-server
accordingly, the Servlet specification allows form based user login, this is a
critical issue when using an application server since the principal is propagated all
the way into the EJB container (where our interceptor will handle it).
Unfortunately this cannot be done in the deployment descriptor (web.xml), at least
not to the required extent (eg. we need do define a realm in Tomcat's server.xml).
This means the application is a little heavier to install correctly, but changing
these features or extending the current set of features can be done in a
straightforward fashion. To make life easier for the end-user we could bundle all
configurations and deployment descriptors and have an installer ask the user which
products he prefers to use and then install only
support for those ones.
To avoid to have too many proprietary solutions there is an elegant implementation
in place: using a custom login module it is possible (on JBoss with embedded Jetty or
Tomcat) to have the login module fetch the required roles from the data source, these
roles will be known in the front-end as well as in the back-end. The steps to have this
in place are as follows:
At this point this allows us to avoid a separate webserver customization/configuration.
- Configure login-config.xml with a DataBaseServerLoginModule, this will be your realm
- Configure this realm to be your security domain (jboss.xml and jboss-web.xml)
- Setup method level permissions on the beans
- Setup security constraints and web resources in web.xml
- Use form-based login to authenticate the user
- Setup users and roles in the data source
In the first releases we will have support for JBoss 3.x with integrated Tomcat
and Hypersonic only, our first concern is to get the project business.
It still needs to be seen when exactly we will support other vendors, but eventually
it will happen.
Why ? Because it is impossible for a serious project to only stick to the current
The presentation layer is designed by using the
Struts 1.1 framework.
This framework is based on the MVC (Model-View-Control) model where:
- Model: represents the state of the application.
- View: represents all JSP pages that gather information from the model.
- Controller: handled by servlets that are automatically generated by the container.