To create the definitions for the configurations required by the
Internet Banking Sample Application, the following guidelines were
followed:
- Use self-defined operations and self-defined processors.
- Avoid, as much as possible, dependencies between the self-defined
modules and the configuration file. This enables you to deploy new
functions without re-initializing the server. It also enables you
to update deployed functions without interfering with the rest of
the application. To avoid dependencies, do the following:
- Name files to match the names of the operations or processors.
With this approach, the name and path of the file containing the definitions
does not have to be specified, which isolates the definitions from
the configuration file (btt.xml).
- Use the implClass attribute when the class
is particular for a specific definition or when the implementation
class may change frequently.
- Use the tag/class relationships specified in the configuration
file when the implementation class is generic and does not change
frequently.
- Define generic types used by the application in the type.xml file.
- Define generic formatters used by the application in the format.xml file
(none for this sample).
- Define generic contexts used by the application in the context.xml file.
- Define generic services used by the application in the service.xml file.
- Define generic operations used by the application in the operation.xml file.
- Define generic processors used by the application in the processor.xml file.
- Define generic data elements belonging to the server context and
the session context in the data.xml file.
- Define non-typed data collections with typed data elements inside.
- Use transition contexts to limit the set of data elements expected
in each user event.
- Perform temporal validations without updating the process context
until the validation succeeds.
These guidelines were followed for this particular application,
but you are free to change the approach in a real environment.