warning: this page needs to be completed with detailed info on how to set up and maintain DBs (Oracle and Fulcrum), and with references to the use of WebLogic.

Informations stored in data bases are being published on web servers more and more often. The main advantage of using data bases to publish information on the web is the possibility to create information dynamically in a way that is better suited to the needs of the individual users. Sometimes, however, the advantages do not outweigh the overhead (development, maintenance, system and network resources). In other cases using data bases is the best, or only possible, choice due to the complexity of the information.

An important factor when choosing between dynamic data, generated on the fly, and static data is the visibility of your data. Data that is generated on the fly will not be indexed by (most) search engines and will therefore not be visible to users trying to locate information using those search engines.

Two types of data bases can be published: Oracle and Fulcrum DBs.
At this moment we are running Oracle 8i, and Fulcrum SearchServer V4, both on dedicated servers. A more complete description of our environment can be found in the chapter on configuration related issues. Please note that all data that are to be published through one of the web servers at Admin-DI-DC-D must reside at the Admin-DI-DC premises.

We strongly urge you to contact the Admin-DI-DC-D web team and DG PRESS before starting new developments. It can save you a lot of future trouble and resources (external contractors do not rewrite applications for free, do they?).

Preferred architecture

A multi-tiered architecture has been put in place to allow the publication of database contents on EUROPA and IntraComm:

All access to the EUROPA and IntraComm contents is transparently channeled through reverse proxy servers. The reverse proxy servers map incoming HTTP requests to the appropriate web servers. This is described in more detail in a dedicated chapter.

In our standard architecture most of the requests will be mapped to the main contents web servers. Each of these servers have been configured to run with a ColdFusion Enterprise server that is located on the same platform.
Oracle DBs for which a 'data source' has been defined in the ColdFusion servers can be accessed using the standard native Oracle drivers.

The described architecture should be followed when possible. Because the ColdFusion applications reside on the same platforms as the 'static' contents we believe this model allows for easier maintenance of the application logic, and for easier integration with the related web pages and images.

Unfortunately, access to Fulcrum DBs doesn't seem to fit in this picture at this moment. Access to Fulcrum DBs via ColdFusion and ODBC is being investigated, and will be integrated into this architecture when possible.

Alternative solutions are available or can be investigated if necessary.

How to set up a new data base

Here we will describe the procedure to get a new data base published on EUROPA or IntraComm within the boundaries of the described 'preferred architecture'.

Notify web site management

The first step, as with all data that are being published on EUROPA, is to contact the EUROPA team (DG Press). We (Data Centre) only make data bases available through the web servers, both in staging and production, after the acceptance by the EUROPA team. For IntraComm the same applies: contact the IntraComm team (DG Admin) first.
They will provide you with, or eventually agree with, a URL path under which the data base will be published.

When this is done you can contact the Data Centre webteam (dcdiffusion.europa@cec.eu.int) via e-mail. This e-mail message should contain a description of the application: the URL path provided by the web site managers, disk space required, contact person(s), and other useful information.

ColdFusion application

As indicated in the chapter on using ColdFusion, the cfm pages can be uploaded on the staging server using the existing FTP access. If necessary a dedicated FTP userid can be created.

The purpose of the staging server is to allow verification of web contents before they are copied onto to public web servers. Here you can verify links and ColdFusion pages in an environment that is as close as possible the real, publicly accessible, environment.
The staging server allows the editorial committee to view new contents before publication and verify conformance to the respective information provider guides. After acceptance by the editorial committee, then the web site managers (the resp. EUROPA and IntraComm teams) will request that we (Data Centre webteam) make the contents available to the public.

Oracle DB creation

information to be added

• CF dsn
• upload of new/updated data bases
• ...

Alternative architecture

For cases where it is absolutely impossible to apply the preferred architecture we propose to use dedicated web servers.

The HTTP daemon can be an iPlanet Web server. For the CGI scripts Perl V5.6 can be used with the DBI and DBD modules.

Where possible, the related static files (HTML pages and images) should be located on the main contents web server.

As indicated before, the database web servers are accessed via reverse proxy servers. This will have an influence on how the web interface to a database will need to be programmed.

In order to reduce integration problems with the rest of the web site we propose to set up each database environment and web interface so that it is located completely under one URL path. An example with (almost) real configuration statements for our iPlanet Enterprise and Netscape Proxy servers might clarify this:

• suppose the database scripts are located on the database server in /some/database/cgi-bin and the pages and images are located under /some/database.
• the database web server will be configured to recognize /some/database/cgi-bin as a CGI directory with URL path http://databasehost:port/database/cgi-bin/, and the directory /some/database/ will be known by the database web server as an additional directory corresponding to URL path http://databasehost:port/database/:
  NameTrans fn="pfx2dir" from="/database/cgi-bin" dir="/some/database/cgi-bin" name="cgi"
NameTrans fn="pfx2dir" from="/database" dir="/some/database"
• the reverse proxy server will make the database available through one mapping from http://www.cc.cec/some/path/database/ to http://databasehost:port/database/:
  NameTrans fn="reverse-map" from="http://databasehost:port/database" to="http://www.cc.cec/some/path/database"
NameTrans fn="map" from="/some/path/database" to="http://databasehost:port/database"

The most important consequence is that you cannot use hyper links like "/database/cgi-bin/script.pl" in your pages. A link like this would only work on the database web server itself but not on the reverse proxy server.
In other words: use relative links, or it might not work.

To simplify things for those 'programmers' that have problems with relative links we might consider using the same URL path on both the database web server and the reverse proxy server. However, this is not always possible as the relative location of the database to the web site might change.
In other words: use relative links, or it might stop working later.

Testing does help

Some developers have major problems understanding how to work with reverse proxy servers. A few times this lack of understanding has lead to postponing the publication of a new application on our web servers. One way to prevent bumping into these problems when going live is to reserve some time to try the application first in our staging environment. Sounds obvious, doesn't it?