This document explains the gateway's configuration system in detail. After reading this document you will know how the configuration system works and how to determine if an option should be made configurable or not.
Before explaining how it works, it is helpful to have an understanding of the problem trying to be solved. We will use an example throughout this section to help explain things. The example is the e-mail address used for e-mail notifications. When something important happens to the gateway, it sends an e-mail to an administrator.
The easiest way to specify an admin e-mail address directly in the program itself. This has its drawbacks. A user has to manually edit the source code, recompile, and re-deploy when changing an e-mail address. This is too much work and has the potential to be painful for non-programmers. So this solution is not good.
Since building and deploying are not good options, the e-mail address needs to be changeable at runtime. To ensure that the address is persistent across application server crashes and reboots, it needs to be stored in a database. This has its drawbacks too. When the database is down, the program doesn't know what to do because it can't access its own configuration.
The solution is a 3 level fail over system. The first level is the database. Options are stored there and easily changeable at runtime. If the database is down, corrupted, or deleted, the configuration system fails over to the second level. The second level is a properties file that exists within the application archive. It contains settings for a specific deployment. If the file is missing, incomplete, or corrupted, the configuration system fails over to the third level. The third level is a set of hard coded default values in the program source code.
There are a lot of constant values used throughout the gateway. It is sometimes difficult to determine if the value should be a configuration option or just left in the source code as a constant. What follows are some criterion for determining if a value should be made a constants or a configurable option.
If changing the value requires a repackaging and/or recompile, then the value should be a constant. For example, the schema version "2007V01" should be a constant. The no other schema versions are available in the EAR, so a repackaging would be required. Different schema versions make require code changes (the rules, ack factory, receipt factory, transmission generator, etc), so a compile would be required. Another example is an XSL path. A user may want to use a different transform in the portal because he/she might want a page to look different. It shouldn't be configurable because the user can't add new XSL files without re-packaging the EAR.
If changing the value violates the schema, then it should be a constant. For example, the length of the UserId should remain a constant because using a UserId with a length other than 9 violates the schema.
If changing the value breaks the program, then it should be a constant. For example, the database product name for MySQL should never be changed because doing so makes our MySQL specific code fail.