All the real work of analysing texts in a GATE-based LE system is done by CREOLE modules or objects (we use the terms module and object rather loosely to mean interfaces to resources which may be predominantly algorithmic or predominantly data, or a mixture of both). Typically, a CREOLE object will be a wrapper around a pre-existing LE module or database - a tagger or parser, a lexicon or ngram index, for example. Alternatively objects may be developed from scratch for the architecture - in either case the object provides a standardised API to the underlying resources which allows access via GGI and I/O via GDM. The CREOLE APIs may also be used for programming new objects.
When the user initiates a particular CREOLE object via GGI (or when a programmer does the same via the GATE API when building an LE application) the object is run, obtaining the information it needs (document source, annotations from other objects) via calls to the GDM API. Its results are then stored in the GDM database and become available for examination via GGI or to be the input to other CREOLE objects.
There are two ways to provide the CREOLE wrapper functions. Packages written in C, or in languages which obey C linkage conventions, can be compiled into GATE directly as a Tcl package. This is tight coupling. Alternatively, the underlying implementation of services can be via an executable (loose coupling). This executable is then called by the CREOLE wrapper code. In either case the implementation of CREOLE services is completely transparent to GATE. Note that the loose coupling route means modules supplied either in source form or binary form can be integrated into GATE, the latter possibility reducing problems of redistributing LE software to third parties.
CREOLE wrappers encapsulate information about the preconditions for a module to run (data that must be present in the GDM database) and post-conditions (data that will result). This information is needed by GGI - see below. Aside from the information needed for GGI to provide access to a module, GATE compatibility equals TIPSTER compatibility - i.e. there will be very little overhead in making any TIPSTER module run in GATE.
In addition to the macro requirements on CREOLE integration described above, GDM imposes constraints on the I/O format of CREOLE objects, namely that all information must be associated with byte offsets and conform to the annotations model of the TIPSTER architecture. The principal overhead in this process is making the components being integrated use byte offsets, if they do not already do so.
As we noted above, CREOLE objects may be data-orientated. It is our intention to integrate as large a set of LE data resources as possible within GATE in order to reduce the overhead of installing and understanding the software interfaces of these resources. For example, the Wordnet thesaurus  will be given a CREOLE wrapper encapsulating the C API as a GATE service. Grammars, lexica, gazetteers - all are candidates for CREOLE integration, and as the set expands GATE can become a standard resource repository for LE data as well as LE processing modules.