Zum besseren Verständnis der einzelnen Komponenten und Aufgabenbereiche, die in diesem Handbuch beschrieben werden, ist ein grundlegendes Verständnis der DLE Architektur notwendig.

Hat ein Benutzer sich an einer Anwendung angemeldet, wird normalerweise in der Anwendung eine neue DLE Session erstellt, die so lange erhalten bleibt, bis der Anwender sich wieder von der Anwendung abmeldet.
Eine DLE Session wird jedoch nicht direkt erstellt, sondern indirekt über eine der API (APPLICATION PROGRAMMERS INTERFACE) Schnittstellen. Die DLE bietet verschiedene solcher APIs an. Neben einer direkten Java API, die die DLE innerhalb der lokalen JVM ausführt, existieren auch Remote Schnittstellen, die eine Verbindung zu einer serverbasierten DLE ermöglichen. Dort wird die DLE nicht in der lokalen JVM ausgeführt, sondern es existiert nur eine Kommunikationsschnittstelle zu einer auf einem Server laufenden DLE Session. Auch hier wird normalerweise diese Verbindung aufgebaut, wenn ein Anwender sich an einer Anwendung anmeldet und bleibt bestehen, bis der Anwender sich abmeldet.
Um eine optimale Ausführungsgeschwindigkeit und Resourcenausnutzung zu erreichen sollte es vermieden werden, für jede Logikausführung durch die DLE eine neue DLE Session zu erstellen, da sonst alle bestehenden Informationen wie Paketinformationen, Übersetzungen, Dienste und Datenbankverbindungen verloren gehen und neu erstellt werden müssen.
Die DLE selber definiert keine eigenen Anforderungen an die Ausführungsumgebung. Sie kann sowohl auf herkömmlichen Java Clients, als auch auf Web- EJB- oder anderen Serverarten laufen, die die Ausführung von Java Programmen erlauben.

Durch einen DLE Aufruf kann eine Anwendung so dynamisch auf Daten von verschiedenen Informationssystemen zugreifen, ohne deren Strukturen oder Funktionen direkt zu kennen.
Neue Pakete können einfach selber definiert werden, dabei muß ein Paket nicht ein komplettes Informationssystem abbilden. Es reicht, nur die benötigten Informationen zu definieren. Auch können Pakete definiert werden, die nur Kommandos oder nur Datendefinitionen enthalten, um so den Zugriff zu strukturieren.
Die DLE Pakete bieten so einen flexiblen und einfachen Plugin Mechanismus für den Informationszugriff innerhalb der DLE.

Wichtiger Teil einer Paketdefinition sind die Metadaten. Diese beschreiben die Datenstrukturen innerhalb eines Paketes. Dazu zählen:

• Welche Tabellen existieren.
• Welche Spalten diese Tabellen haben.
• Die Datentypen, Längen und Beschränkungen der Spalten.
• Wie Nachschlagetabellen für Tabellen aussehen.
• Welche Nachschlagetabellen für welche Spalten verwendet werden.
• Wie die einzelnen Tabellen in Verbindung stehen.
• Welche Einzelvariablen es gibt.
• Aliasnamen zu einfachen Handhabung oft verwendeter Ausdrücke.

Sowie viele weitere Möglichkeiten, deren Erklärung hier den Rahmen sprengen würde. Ausführlich sind all diese Möglichkeiten der Metadaten im technischen Handbuch mit Beispielen erläutert.

Aufgrund der Metadaten kennt die DLE die einem Paket zugrundeliegenden Daten und die nötigen Zugriffsmechanismen. Dies erlaubt der DLE die automatische Navigation über den gesamten Datenbestand, Daten können jederzeit nachgeladen werden, ohne dass diese explizit an die DLE übergeben wurden, solange bestimmte Grundinformationen vorliegen.

Eine Basis Applikation ruft bestimmte Funktionsbereiche direkt auf, und/oder benutzt die DLE zum Zugriff auf diese Funktionen.
Die DLE selber wird wiederum von einzelnen Funktionsbereichen (Engines) verwendet, um diese mit dynamischen Eigenschaften zu versehen. Die Datenzugriffsschicht und Funktionsschicht erlaubt es dabei der DLE verschiedene Anwendungen miteinander zu verknüpfen. Sei es, um Datenbestände zu synchronisieren, oder um Funktionalitäten aus den einzelnen Anwendungen mittels der DLE anderen Anwendungen zur Verfügung zu stellen.