Basic Concepts


Event Model

The basic idea of the whole framework is that a {@link Int.ecb.gesmescb.event.GESMESCBReader} reads GESMES/TS data and translates this into {@link Int.ecb.gesmescb.GESMESCBObject}s. These then are distributed using the framework in {@link Int.ecb.gesmescb.event} until they reach a {@link Int.ecb.gesmescb.event.GESMESCBWriter}, which writes them in its specific output format. As an example, an {@link Int.ecb.gesmescb.edifact.EDIFACTReader} could read data and distribute it to a {@link Int.ecb.gesmescb.famewriter.FameWriter}. Such an application would read GESMES/TS files in EDIFACT syntax to a FAME database.

Principle processing of GESMES/TS

Additional to this basic concept, the {@link Int.ecb.gesmescb.metabase.Metabase} singleton stores GESMES/TS structural definitions in memory. Then these definitions are accessible to all other components. For instance, the {@link Int.ecb.gesmescb.semanticchecker.SemanticChecker} uses them to perform several validation checks on GESMES/TS data. A SemanticChecker can be plugged into the data path between a GESMESCBReader and a GESMESCBWriter. Any negative check results found will be reported using {@link Int.ecb.gesmescb.event.ErrorEvent} to the GESMESCBWriter and also to the global {@link Int.ecb.logging} mechanism. The below sketch shows a setup with an {@link Int.ecb.gesmescb.edifact.EDIFACTReader} reading from a file and passing the infortmation on to a SemanticChecker. This checks against the structural definitions and reports the information and checking errors to a {@link Int.ecb.gesmescb.famewriter.FameWriter} and simultaneously to the Metabase in order to update it on the fly in case the input file contains structural definitions. All components get structural definitions from the Metabase when they need to.

Simultaneous checking and loading to FAME

Code to work with this setup could look like this:

final GESMESCBReader reader = new EDIFACTReader();
final Metabase metabase = Metabase.getMetabase();
final SemanticChecker checker = new SemanticChecker();
final GESMESCBWriter writer = new EDIFACTWriter();

reader.addListener( checker, true );
checker.addListener( metabase, false );
checker.addListener( writer, true );

reader.run();

reader.close();
checker.close();
writer.close();

Above all, the organisation of the data path layout and the reading and writing is done by the classes in {@link Int.ecb.gesmescb.application}. For configuration of these and also other classes the {@link Int.ecb.prefs} framework is used.

Logging

Since the Java logging API is ready only from Java version 1.4 onwards, logging facilities come within the package {@link Int.ecb.logging}. The intention is to replace them by the standard logging facilites once they are in sufficiently common use.

Like everything in the application, logging is configured using the package {@link Int.ecb.prefs}. See Preferences.

Configuration using Preferences

The packages {@link Int.ecb.logging} and {@link Int.ecb.prefs} will be replaced by the respective standard logging and preferences packages when these will have become part of Java.

Find here a description of the package hierarchy.