Introduction
The J2EE platform will help to develop highly available, secure, reliable, and scalable applications. The J2EE standardisation will also allow applications to be portable across platforms coming from different suppliers.
The DC provides access to this technology to DGs and makes available to them three types of environment, development, test and production to run applications on top of J2EE. These environments will allow DGs to develop their applications at DC and go into production knowing in advance that they will be conformant to the production environment.
These guidelines describe the J2EE environments at DC but they do not pretend to replace the published specifications of the platform. On the contrary they suppose that the main ideas about the different kinds of applications that can run on them are known, and the way they are packaged and deployed as well.
Although the DC has installed as J2EE server the WLS coming from BEA, we emphasise the importance of following the standards to achieve portability.
Environments
An environment consists basically of an instance of a J2EE server (server does not mean in this context a WLS server but the equivalent of a WLS domain) and a workspace. That instance is shared by applications belonging to the same DG. The workspace correspond to a directory where the applications are stored as well as the logs or any other element required by the server to run the applications.
Each DG will have by default access to three environments
- A development environment targeted to developers. They will have access to the workspace in order to update the applications, read the logs, update libraries, etc.This environment is hosted on beadev.cc.cec.eu.int
- A stress test environment that will contain stable versions for testing. This environment is hosted on j2eetest1.cc.cec.eu.int
- A production environment that will contain the running versions of the applications and where access to the workspace will not be allowed. This environment is hosted in j2eeprod1.cc.cec.eu.int
The environments are requested via the Central Help Desk that will pass the information to the Incident Management section of the DC. Once the request is approved URL will be provided and the group of users designated by the DG will be granted access to the workspace via FTP.
Access to the J2EE server
It is done via HTTP through a reverse proxy.
Workspace
The workspace corresponds to a directory that will mainly contain the application packages but also other information required by the application. It will be named after the DG with TEST appended to the name in the case of the test environment. Currently the access to the development and test environment is allowed via FTP to authorised LDAP logins of the Commission.
The subdirectories that will always be in the workspace are:
- applications. It contains the packages: ear, war and jar.
- logs. It contains the logs output by the server.
Some other directories will be found if required, although their use should be avoided:
- patches. It will contain the libraries that will appear first in the server CLASSPATH. Their use for reasons other that to patch the server should be avoided.
- classes. This directory will be added to the end of the server CLASSPATH but before anything in the lib directory (see below). It is supposed to contain classes or configuration files (accessible via the getResourceAsStream class).
- lib. It will contain the librarires required to be in the server CLASSPATH. They will be added at the end. As before their use is to be avoided.
- tmp. It will be use for temporary storaged.
The development environement will also contain a production directory intended to be a mirror of the workspace of the production environement.
Actors
The main actors from the DC point of view are the J2EE administrators (that belong to the DC), the end users of the applications and the application owners (this name covers developers, testers, deployers working for the DG).
The DC will ensure the role of administrator as described in the J2EE specifications and expect from the DGs to fullfill any other role including the deployer one. The specification has not been followed completely as in this regard we include in the administrator role any resource definition that requires the use of administration tools of the product (for instance definition of connection pools, data sources, etc.)
Update of applications
The DGs will be allowed to update the applications by simply overwriting the packages of the production environment of the workspace in the environments of development and test but will require the intervention of the J2EE administrators.
A copy of the production environment will be provided through the "production" directory in the development environment to allow the application owners to issue new releases of the production environment so that the J2EE administrators at DC can update the production environment.
Packaging of applications
The only accepted format of applications will be ear/war/jar packaged applications.
Some BEA specifics
Reduce to a minimum the use of product specific features as startup classe, as startup classes are proprietary features of Bea systems.
The development environment is started in autodeploy mode although this will change and we will supply authorised people with the rights to undeploy/deploy applications so that they can update them. This could be extended if justified to the possibility of starting/stopping the server.
Third parties libraries
Their use has to be documented. The type of license has to appear in the application form and the URL to get the library. Their use has to be formally approved by the DI.
Current version
- Weblogic 8 (JDK 1.4)