5.1.5 Die SOM-Frameworks

Neben DSOM enthält SOMobjects mehrere Frameworks, die die Implementierung von objektorientierten Anwendungen in wichtigen Punkten unterstützen. Es sind Klassenbibliotheken, die Objekte für bestimmte Aufgaben zur Verfügung stellen. Die Frameworks werden in der folgenden Aufzählung beschrieben:

Metaclass Framework:

Dieses Framework kann eingesetzt werden, um Anwendungsklassen oder Metaklassen zu definieren. Dabei kann auf folgenden Metaklassen aufgebaut werden:

• SOMMBeforAfter metaclass: Oftmals ist es erwünscht, daß vor und/oder nach einem Methodenaufruf auf einem Objekt automatisch bestimmte Methoden ausgeführt werden. Mit der Metaklasse SOMMBeforAfter kann eine Klasse dieses Objektes (zusammen mit den automatisch aufzurufenden Methoden) definiert werden.
• SOMMSingleInstance metaclass: Klassen, die von dieser Klasse abgeleitet werden, können nur einmal instantiiert werden.
• SOMMTraced metaclass: Methoden von Klassenobjekten dieser Metaklasse geben vor und nach ihrer Ausführung Meldungen mit den Parametern bzw. den Rückgabewerten (auf die Standardausgabe) aus. Damit lassen sich Methodenaufrufe zurückverfolgen.
• In SOMobjects 3.0 neu hinzugekommen ist die Metaklasse SOMMProxyFor. Die Erzeugung von Proxy-Objekten und Proxy-Objektklassen erfolgt bei SOM/DSOM automatisch. Es ist aber oft notwendig, zu anwendungsspezifischen Objekten spezielle Proxy-Objekte bzw. -klassen zu definieren. Proxy-Objektklassen werden von der Metaklasse SOMMOProxyFor abgeleitet.

Collection Class Framework:

Diese Klassenbibliothek stellt dem Anwendungsprogrammierer viele hilfreiche Klassen zur Verfügung. Es handelt sich um häufig benötigte Datenstrukturen wie Hash-Tabellen, Dictionaries, Mengen, Linked Lists, Sortierte Listen, Warteschlangen, und Priority-Queues.

Event Management Framework:

Dieses Framework definiert Klassen für das Versenden und Empfangen von asynchronen Ereignismeldungen. Mit ihm können Ereignismeldungen zentral verwaltet werden. Im Gegensatz zum Event Service sind Ereignismeldungen dabei eigene Objekte. Es gibt Client Events (anwendungsspezifische Events), Timer Events, Sink Events (Meldungen über Ein- und Ausgabeaktivitäten auf Event Sinks wie z. B. Sockets oder Dateideskriptoren) und WorkProc Events. Die Weiterverarbeitung der Events erfolgt durch Callback-Prozeduren. Eine Anwendung muß für jede Eventart, die sie empfangen will, einen Callback definieren. Für den Empfang von Ereignismeldungen kann sich eine Anwendung bei einem Event-Manager-Object anmelden (und auch abmelden). Auch wenn diesbezüglich eine Ähnlichkeit zu einem Event Channel besteht, so ist das Event Management Framework nicht CORBA-konform.

Emitter Framework:

In Zusammenhang mit dem SOM Compiler stehen sogenannte Emitter, welche die Ausgabe des Compilers in einem bestimmten Format abspeichern. Von SOMobjects mitgeliefert werden zwei Emitter, der C- und der C++-Emitter, welche Header-Dateien und die Programmskelette in C bzw. C++ erzeugen. Mit dem Emitter Framework können spezielle Emitter entwickelt werden, z. B. solche, welche für die Erzeugung von Dokumentationsdateien verwendet werden können.

Interface Repository Framework:

Bei SOM wird das Interface Repository -- eigentlich ein integrales Teil der CORBA-Architektur -- als eigenes Framework betrachtet. Dies ändert nichts an der Tatsache, daß das SOM Interface Repository CORBA-konform ist. Zusätzlich können im SOM Interface Repository allerdings SOM-IDL-spezifische Informationen abgelegt werden (in Form von Modifikatoren, modifiers). Beispiele hierfür sind Versionnummern und Kurzbeschreibungen von Klassen oder Compilerdirektiven für die Erzeugung der Programmskelette.