Previous: Using ColdFusion Contents and Introduction Next: Uploading Data

Weblogic Infrastructure

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

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:

Some other directories will be found if required, although their use should be avoided:

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

Useful links

http://java.sun.com/j2ee
http://edocs.bea.com

Data Centre