To create the definitions, perform the following actions are (though
they may not apply to your particular application and its environment) :
- Use self-defined operations and self-defined processors.
- Use Op as the ending to all operation names.
- Use Proc as the ending to all the processor names.
- 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 (dse.ini).
- 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 very often.
- Define generic types used by the application in the type.xml file.
- Define generic formatters used by the application in the format.xml file.
- 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
(none for this sample).
- Define generic data elements belonging to the server context and
the session context in the data.xml file.
- Define untyped data collections with typed data elements inside.
- Set input and output mapping formatters in the transitions, rather than in the
states. The mapping will thus be discriminated depending on the origin and destination transitions, which
provides more flexibility.
- Use Data Mapper Converter Format (which uses typed data converters)
to map the resulting data from the subflow to the parent flow instead
of using the format/unformat mechanism that builds intermediate strings. This approach improves the performance significantly.
- 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.
With the Multi-Channel Sample Application, the BTT provides three
sets of toolkit entity definition files, each of which contains definitions
for data, contexts, operations, formatters, operations, types, and
flow processors. The three sets are for client, server, and standalone environments. While the entity definition files for the stand-alone environment
include all the definitions required to execute the client and server processes of the sample application
on a standalone machine, the ,xml files for a pure client or server environment include
only those elements required for each case. These different sets of XML files are provided to help you to understand
what is uniquely required in each environment, and to define only
those elements that are really required on either the client or the server. This distinction will be useful in a real environment, where you will not want to have all the definitions in all the XML files.