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

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

On the other hand, we have some ideas in mind that will get some more concrete form in the future, these include:

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:

  1. 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.
  2. 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.
  3. 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:
    1. Configure login-config.xml with a DataBaseServerLoginModule, this will be your realm
    2. Configure this realm to be your security domain (jboss.xml and jboss-web.xml)
    3. Setup method level permissions on the beans
    4. Setup security constraints and web resources in web.xml
    5. Use form-based login to authenticate the user
    6. Setup users and roles in the data source
    At this point this allows us to avoid a separate webserver customization/configuration.

Conclusion:
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 standards, final.

The presentation layer is designed by using the Struts 1.1 framework. This framework is based on the MVC (Model-View-Control) model where: