Core components

The toolkit provides an architecture and a class library that facilitate the structuring and development of teller applications, by promoting reuse of transactions and providing the services required to process them. The toolkit is based on the following base core entities (operations, flows, data elements, formatters, CHA (contexts), services, and invokers), the Event Manager, Element Factory (IoC container) and Initialization Manager which loads UDTT components in a configurable way.

For more information, see Core component interaction.

Data elements are what the toolkit uses to hold data in a structure that enables toolkit entities, processes, and services to add, update, and delete the data during runtime. Formatters provide a way of transforming the data from one format to another so that various entities, processes, and services can use it.

For more information, see Data elements.

A context is an object that defines and encapsulates data for a functional or business organization entity. In the presentation layer of UDTT, contexts are used as basic data model entities in the data model. Examples of contexts for a banking organization are branch context, workstation context, user context, and customer session context.

For more information, see Contexts.

The btt.xml file is the definition file for all UDTT components. This file stores the required information of each UDTT component. In each application, you can have only one btt.xml file.

For more information, see UDTT definition description.

Typed data elements represent business objects such as Date, ProductNumber, and Money. They differ from non-typed data elements because they contain information about the type of business objects they represent and conform to the object's business rules. For example, a typed data element identifies how the toolkit displays the business object it represents and it also identifies what validation must occur when the toolkit changes an attribute value. To hold this information, typed data elements have one or more property descriptors. Non-typed data elements do not have a property descriptor.

For more information, see Typed data.

Formatters are what the toolkit uses to exchange data between toolkit entities such as operations, contexts, and services.

For more information, see Formatters.

An operation is the entity responsible for performing the set of tasks needed to complete a basic financial operation, including data input and validation, interaction with external services, and management of the results and data received. An operation has a requester that requests its execution, provides input data, and eventually receives the results. The operation requester can be a Java application, an applet, a batch command processor, another more general operation, and so on. Since an operation is completely separate from the requester (the entity that launches an operation), different requesters can run the same operation.

For more information, see Operations.

A flow is a representation of a particular route through a business process or business operation. The flow reflects the results of performing different actions and responding to system-generated events within the business process. The Automaton is a state machine-based mechanism that the toolkit uses to handle the various flows that can occur within a business process or presentation sequence. The Automaton is particularly useful for complex flows that have many branches with compound and complex conditions. These complex flows often, for example, occur with HTML client-based applications. A flow processor is the implementation of the Automaton for a particular process.

For more information, see Flows.

An event is the mechanism that the UDTT uses to communicate among a client, a server, an external server (for example, distributed business logic server), or among the various parts in the toolkit within the application presentation layer. Event notification consists of defined structures for sending a toolkit-specific event (signaled by an event notifier) and for receiving the event (processed by an event handler.)

For more information, see Events.

Initialization manager is used to initialize the UDTT components. Using initialization manager, you can initialize the components you want, and leave the other components uninitialized.

For more information, see Initialization manager.

Externalizers are object factories that use definitions in external files to initialize defined objects. This enables you to configure and customize these defined objects (or implement new ones) using the CHA Editor or something as simple as a basic text editor. The externalizer creates a structure of tags in memory, which it uses to store object definitions, from the tags in the generic file.

For more information, see Externalizers.

In UDTT definition files, you can use an <import> tag to reuse the elements defined in reusable definition files.

For more information, see Importing predefined elements.

UDTT provides ElementFactory as a Container for Dependency Injection, you can also call it IoC (Inversion of Control) Container.

For more information, see ElementFactory.

The Web services access component consists of a set of infrastructure modules that enables applications to interact with Web services.

For more information, see Web services access.

UDTT commands provide a generalized navigation framework to maximize the reusage of businesses and transactions.

For more information, see Commands.

UDTT follows the standard Java mechanism for exception handling, but incorporates some additional behavior to facilitate how applications can access exception information. Each component defines and manages the toolkit and standard Java exceptions that it can raise.

For more information, see Exceptions.

Timezone indicates where the time is set. The date/time (we can call it timestamp) could not be understood by the other side when there are not enough information.