3 Anwendungsgebiet: Telefonie
Das folgende Kapitel soll einen Überblick über das Anwendungsgebiet der Computer-Telefonie geben. Zunächst werden die Einsatzbereiche für Telefonie-Systeme vorgestellt und danach das Telefonie-System der Fa. Micrologica, an dessen Entwicklung ich im Rahmen dieser Diplomarbeit maßgeblich mitgewirkt habe. Anhand der verschiedenen Hardware-Konfigurationen und Programmierschnittstellen werden die Probleme der Computer-Telefonie erläutert, die zur Entscheidung geführt haben, ein Framework für die Tk-Anlagen-Steuerung zu entwickeln.
Der Begriff Telefonie bezeichnet alle Arten von Systemen zur Unterstützung des Telefonierens.
Heutzutage wird diese Unterstützung meist durch den Einsatz von EDV erreicht, daher spricht man häufig auch von CTI (engl. computer telephony integration).Definition 18: Telefonie
Systeme, deren Ziel die Unterstützung des Telefonierens ist, werden als Telefonie-Systeme bezeichnet.
Unter dem Begriff Telefonie werden oft auch neuartige Dienste wie Voicemail und Spracherkennung o.ä. gefaßt. Ich möchte mich bei der Diskussion hier auf das reine Vermitteln von Telefonverbindungen beschränken. Welche Art von Anwendung über diese Verbindungen betrieben wird, ist dabei sekundär.
3.1 Anwendungsgebiete für Telefonie-Systeme
Für Telefonie-Systeme gibt es drei Haupteinsatzbereiche: die schwerpunktmäßige Bearbeitung von eingehenden Gesprächen (sog. Inbound-Bereich), das schwerpunktmäßige Führen von ausgehenden Gesprächen (sog. Outbound-Bereich) und die Erleichterung von ein- und ausgehenden Gesprächen für Mitarbeiter, die für ihre eigentliche Tätigkeit nur gelegentlich telefonieren. Je nach Anwendungsfall und eingesetztem Telefonie-System sind fast beliebige Mischformen denkbar.
Von einem Call-Center spricht man, wenn die dort arbeitenden Personen mind. 90% ihrer Arbeit mit dem Telefon verrichten. Typische Anwendungsgebiete für Call-Center sind Bestellannahmen von Versandhäusern, Auskunfts- oder Hotline-Dienste und Direktmarketing. Es sind jedoch auch hoch qualifiziertere Tätigkeiten denkbar, die ebensoviel mit dem Telefon arbeiten und eine ähnlich mächtige Telefonie-Unterstützung benötigen.
Ausgehend von einer automatischen Anrufverteilung (engl. automatic call distribution, ACD), wie sie in gängigen Telefonanlagen z.B. für Sammelanschlüsse enthalten oder auch als etwas flexiblere Softwarelösung zu erwerben ist, geht die Entwicklung immer mehr zum Incoming-Call-Management (ICM), das eine sehr viel intelligentere Verteilung der Anrufe beinhaltet. Mit einer flexiblen Anrufverteilung läßt sich oft die Einrichtung von großen Call-Centern zugunsten von kleineren, dezentralen Call-Centern vermeiden, bzw. es können Spezialisten direkt an ihrem Arbeitsplatz erreicht werden, die nur gelegentlich z.B. mit Hotline-Aufgaben betraut werden sollen.
Ein wesentliches Ziel von Telefonie-Systemen ist es, die Produktivität der telefonierenden Mitarbeiter zu steigern. Wenn sich ohne Unterstützung eines Telefonie-Systems ca. 5-8 ausgehende Gespräche pro Stunde aufbauen und führen lassen, kann sich diese Zahl bei Einsatz eines sog. "Power Dialers" auf ca. 15-23 Verbindungen pro Stunde erhöhen (vgl. [Schneegans 96]). Der Grund für die deutlich höhere Gesprächszahl liegt zum einen am schnelleren Auffinden und Wählen der nächsten Nummer, mehr aber noch daran, daß der Mitarbeiter nur noch Gespräche mit erreichbaren Kunden führen muß. Alle besetzten bzw. nicht erreichbaren Verbindungen werden vom System gar nicht erst zum Mitarbeiter durchgestellt.
Bei eingehenden Anrufen ist eine Steuerung der Zahl der Gespräche durch das System naturbedingt nicht möglich. Da es z.B. nach Fernsehspots zu extremen Gesprächsvolumen kommen kann, gilt es, hier Lösungen zu finden, um möglichst viele Anrufe bedienen zu können, damit kein Kundenkontakt verloren geht. Dies kann z.B. durch das Zuschalten weiterer Call-Center bzw. das Anbieten von Rückrufen geschehen, wenn kein Mitarbeiter erreichbar ist (sog. Recall-Management). Alternativ kann der Kunde auch mit einem Spracherkennungssystem (engl. interactive voice response, IVR) bedient werden, was jedoch nicht von allen Kundenkreisen genutzt wird.
Beim Kontakt mit bekannten Kunden ist eine deutliche Serviceverbesserung dadurch zu erreichen, daß das Telefonie-System die Telefonnummer des Anrufers bereitstellt (sofern diese z.B. bei ISDN-Teilnehmern zur Verfügung steht) und dadurch der Anruf zu einem für diesen Kunden zuständigen Mitarbeiter geleitet wird bzw. beim Mitarbeiter sofort eine Maske mit allen notwendigen Kundeninformationen erscheint, sobald sein Telefon klingelt.
3.2 Das Micrologica Communication Center (MCC)
Das Micrologica Communication Center (MCC) ist eine Telefonielösung, die einen großen Teil der Anwendungsbereiche von Telefonie-Systemen abdecken kann. Es werden sowohl der Inbound- als auch der Outbound-Bereich unterstützt. Mehrere MCC-Systeme können standortübergreifend zu einem sog. "virtuellen Call-Center" zusammengeschaltet werden (vgl. [Kuhn 96]).
Um eine möglichst gleichmäßige Auslastung der Mitarbeiter zu erreichen, wird eine flexible Zuordnung der Mitarbeiter zwischen Inbound- und Outbound-Bereich unterstützt (sog. Call-Blending). Bei Überlastung der jeweils anderen Gruppe werden nach vordefinierten Regeln Mitarbeiter der jeweils anderen Gruppe mit einbezogen (vgl. [van Dahle 95]).
Das MCC arbeitet mit einer LAN-zentrierten Telefonie-Konfiguration (siehe Kapitel 3.3) und kann daher ohne weitere Hardwareanschaffungen eingesetzt werden, sobald ein CTI-Link (Verbindung eines Servers im LAN zur Tk-Anlage) vorhanden ist. Für jeden Tk-Anlagen-Typ wird jedoch ein spezieller Treiber im MCC benötigt. Da es sehr viele Tk-Anlagen mit unterschiedlicher Ansteuerung auf dem Markt gibt, muß eine ganze Reihe dieser Treiber, die (historisch bedingt) als TSERV bezeichnet werden, erstellt werden.
Um je nach Installationsgröße skalierbar zu sein, ist das MCC in eine Reihe von kommunizierenden Prozessen aufgeteilt, die entweder alle auf einem Server oder verteilt auf mehrere Server arbeiten können. Zusätzlich gehört auf dem PC eines jeden Mitarbeiters (sog. Agenten) ein "Agentenmonitor" zum MCC-System, mit dem sich der Mitarbeiter beim System an- und abmeldet. Zusätzlich gibt es noch eine Reihe von Administrations- und Statistik-Komponenten, auf die ich an dieser Stelle aber nicht weiter eingehen möchte.
Aufgrund seiner modularen und daher skalierbaren Architektur eignet sich das MCC insbesondere für große bis sehr große Installationen. Bei der Börseneinführung der deutschen Telekom wurden beispielsweise in drei mit dem MCC ausgestatteten Call-Centern in Kooperation mit dem Intelligenten Netz der Telekom zusammen bis zu 70.000 Anrufe pro Stunde verarbeitet (vgl. [Welt 96], [Kuhn 97b]).
3.3 Hardware-Konfigurationen für Computer-Telefonie
Man kann Konfigurationen von Telefonie-Systemen danach klassifizieren, wie die Kopplung von Computer und Telefon bewerkstelligt wird. In [Burton 95] wird u.a. unterschieden in
· LAN- bzw. Server-zentriert
Die PCs sind wie üblich in einem LAN miteinander verbunden, und nur ein Server wird über einen sog. CTI-Link mit der Tk-Anlage verbunden. Ein vorhandenes LAN kann verwendet werden, ebenso meist auch die vorhandene Tk-Anlage. Dadurch ist diese Lösung oft mit geringen Investitionen in neue Hardware verbunden (nur für den CTI-Link).
Abbildung 12: LAN- bzw. Server-zentrierte Konfiguration [Burton 95]
Da der Server immer "für andere" steuernd eingreift, spricht man hier von 3rd-Party Call Control. Im Gegensatz dazu spricht man bei Steuerung "für sich selbst" von 1st-Party Call Control. Dieser Ansatz wird sowohl vom Micrologica Communication Center als auch z.B. von Novell mit dem TSAPI-Standard (siehe Kapitel 3.4) verfolgt.
Die Telefone sind weiterhin direkt mit der Tk-Anlage verbunden und können somit nach wie vor auch unabhängig vom PC benutzt werden.
· PC-zentriert
Jeder PC ist direkt mit einer Tk-Anlage verbunden. Die Telefone werden direkt an den PC angeschlossen. Der PC hat hierdurch einen exklusiven Zugriff auf sein Telefon. Durch diese direkte Kopplung ist auch eine Manipulation der über die Telefonleitung übertragenen Informationen durch den PC möglich. Der PC-zentrierte Ansatz ist jedoch mit höheren Kosten für die notwendige Spezialhardware verbunden.
Abbildung 13: PC-zentrierte Konfiguration [Burton 95]
Im praktischen Einsatz wird die Hardware-Konfiguration je nach Einsatzumfeld ausgewählt. Bei großen Installationen überwiegen die LAN-zentrierten Konfigurationen, da sie besser skaliert und zentral administriert werden können.
3.4 Telefonie-APIs
Seit der Einführung der Computer-Telefonie besteht Bedarf an Tk-Anlagen-unabhängiger Steuerung und entsprechenden Standards, um Anwendungen und Hardware unterschiedlicher Hersteller zusammen zu verwenden.
Die ECMA (European Computer-Manufacturers Association) hat im CSTA Standard (engl. computer supported telecommunications applications standard) eine Reihe von Telefonie-Diensten definiert und ein konzeptionelles Modell zur Darstellung der beteiligten "Objekte" bereitgestellt, das sog. Half-Call-Modell (siehe Kapitel 3.4.1). Der CSTA Standard verwendet durchgängig 3rd-Party Call Control.
Dieser CSTA-Standard ist jedoch nicht so detailliert, daß er zur Erstellung von Anwendungen bzw. für die Programmierung der Firmware von Tk-Anlagen ausreicht. Er definiert nur das Protokoll, nicht das konkrete API (application programming interface). Die Firmen Novell und AT&T haben 1993 mit TSAPI (telephony services API) ein CSTA-konformes API definiert, anhand dessen Telefonie-Anwendungen hardwareunabhängig erstellt werden können [Cronin 96].
TSAPI definiert Funktionsaufrufe und Datenstrukturen zur Übergabe von Parametern bzw. Events. Neben der Spezifikation des API umfaßt TSAPI auch eine Reihe von Bibliotheken und Modulen zur Installation auf einem Telefonie-Server. Mitte 1996 waren für ca. 30 Tk-Anlagen TSAPI-Treiber verfügbar [Greenfield 96].
Das zweite wichtige Telefonie-API ist TAPI (telephony API) von Microsoft / Intel, das ebenfalls 1993 auf den Markt kam und heute einigen Versionen von MS-Windows bzw. Windows NT beiliegt und auch nur für Microsoft-Betriebssysteme verfügbar ist [Udell 94]. Im Gegensatz zum CSTA-Standard wird hier eine Mischung aus 1st-Party und 3rd-Party Call Control und ein anderes konzeptionelles Modell verwendet [Nixon 96].
Abbildung 14: Position des Tk-Anlagen-Treibers
Um den Herstellern von Tk-Anlagen die Erstellung eines Tk-Anlagen-Treibers für ein spezielles API zu erleichtern, bieten sowohl TSAPI als auch TAPI einen generischen Treiber an, der aber noch um einen anlagenspezifischen Treiber erweitert werden muß. Abbildung 14 veranschaulicht die Plazierung und den Aufbau eines Tk-Anlagen-Treibers.
Der generische Treiber des API-Definierers (Novell bzw. Microsoft) enthält die zentrale Koordination bzw. den hauptsächlichen Kontrollfluß. Der anlagenspezifische Treiber kommuniziert mit dem generischen Treiber über das sog. Switch Driver Interface.
Nicht alle Tk-Anlagen unterstützen alle Dienste des jeweiligen Telefonie-APIs. Daher sind im API sondierende Funktionen enthalten, über die der aktuelle Treiber befragt werden kann, welche Dienste unterstützt werden und welche nicht.
Beiden APIs ist gemeinsam, daß sie lediglich eine Reihe von Funktionen zur Verfügung stellen. Bei der Benutzung dieser Funktionen sind vom Anwendungsprogrammierer viele Reihenfolgebedingungen einzuhalten, die er der Dokumentation entnehmen muß. Die Telefonie-APIs stellen kein Framework im Sinn von Definition 2 zur Verfügung.
Aufgrund ihrer unterschiedlichen Herangehensweise bei der Call Control (1st-Party bzw. 3rd-Party Call Control) eignen sich die verschiedenen Telefonie-APIs unterschiedlich gut für die verschiedenen Konfigurationstypen. Während sich 1st-Party Call Control besonders für PC-zentrierte Konfigurationen eignet, wird in LAN-zentrierten Konfigurationen meist 3rd-Party Call Control verwendet.
3.4.1 Kommunikation zwischen Anwendung und Tk-Anlage
Um eine Tk-Anlage zu steuern, ruft die Anwendung eine oder mehrere Funktionen des jeweiligen Telefonie-APIs auf und erhält vom Anlagen-Treiber Zustandsmeldung über den aktuellen Anlagenzustand.
Auf einer konzeptionellen Ebene werden die Aufträge an die Tk-Anlage (z.B. "baue eine Verbindung zwischen Telefon 123 und 456 auf") als Requests bezeichnet. Um dem Tk-Anlagen-Treiber ein Request mitzuteilen, sind je nach API ein oder mehrere Funktionsaufrufe notwendig. Meist muß auch der aktuelle Zustand der Tk-Anlage verfolgt werden, um festzustellen, wann der nächste Funktionsaufruf möglich ist.
Um beispielsweise eine Verbindung zwischen zwei Telefonen aufzubauen, kann folgender Ablauf notwendig sein:
1. Funktion aufrufen, um die Verbindung von der Tk-Anlage zum ersten Telefon herzustellen
2. warten, bis die Verbindung hergestellt ist
3. Funktion aufrufen, um die Verbindung von der Tk-Anlage zum zweiten Telefon herzustellen
4. warten, bis die Verbindung hergestellt ist
5. Funktion aufrufen, um beide Verbindungen miteinander zu verknüpfen
6. warten, bis die Verknüpfung durchgeführt ist
Erst nach Erledigung des letzten Schritts ist das Request erfolgreich verarbeitet.
Definition 19: Request
Ein Auftrag an eine Tk-Anlage wird als Request bezeichnet. Diese Aufträge sind meist auf einem höheren Niveau, als die Tk-Anlage in einem Schritt abarbeiten kann.
Um den Zustand der Tk-Anlage zu verfolgen, registriert sich die Anwendung für bestimmte Ereignismeldungen. Diese Ereignismeldungen werden als Events bezeichnet. Die Events sind asynchron und beinhalten alle notwendigen Kontext-Informationen über den neuen Zustand, denn im Gegensatz zu computerinternen Events sind sie meist mit einer nicht vernachlässigbaren Zeitverzögerung verbunden, so daß eine Nachfrage nach mehr Details nicht möglich ist. Der Zustand könnte sich bereits schon wieder verändert haben. Insbesondere bei LAN-zentrierten Konfigurationen ergibt sich eine beträchtliche Zeitverzögerung. Diese Tatsache muß von einem Tk-Anlagen-Treiber berücksichtigt werden.
Definition 20: Event
Ein Event ist eine asynchrone Ereignismeldung über Zustandsänderungen in der Tk-Anlage. Es enthält alle verfügbaren Informationen über den neuen Zustand.
3.4.2 Das Half-Call-Modell
Das Half-Call-Modell ist ein konzeptionelles Modell, um die an einer Telefonverbindung beteiligten "Objekte" unabhängig von einer konkreten Tk-Anlage darzustellen. Es ist Teil des CSTA-Standard. Es besteht aus den Basisobjekten Device, Call und Connection. Devices symbolisieren dabei "Telefongerätschaften" aller Art - vom handelsüblichen Telefonapparat bis zum Sammelanschluß. Man kann Devices weiter unterteilen in physikalische Devices (z.B. Telefonen) und logische Devices (z.B. Sammelanschlüssen). Das Call-Objekt drückt die Kommunikationsbeziehung zwischen Devices aus. Die Verbindung von einem Device zu einem Call wird immer über eine Connection realisiert. Abbildung 15 zeigt eine einfache 1‑zu‑1 Verbindung zwischen zwei Devices.
Abbildung 15: Das Half-Call-Modell einer einfachen Verbindung
Während das Connection-Objekt immer eine 1-zu-1-Beziehung zwischen einem Device und einem Call darstellt, kann ein Call, beispielsweise bei einer Konferenzschaltung, eine ganze Reihe von Connections zu anderen Devices haben (siehe Abbildung 16).
Abbildung 16: Das Modell einer Konferenzschaltung
Andererseits kann ein Device mit mehreren Calls verbunden sein, z.B. wenn ein Teilnehmer während des Gesprächs in Rückfrage geht und eine neue Verbindung zu einem anderen Device aufbaut, während die alte Verbindung weiter gehalten wird (siehe Abbildung 17).
Abbildung 17: Das Modell einer Rückfrage
Alle Basisobjekte im Half-Call-Modell haben einen Zustand:
Der Zustand eines Device ergibt sich aus der Summe seiner Connection-Zustände. Ebenso ergibt sich der Zustand eines Call aus der Summe seiner Connection-Zustände. Der Zustand einer Connection spiegelt den Verbindungszustand im Bezug auf genau ein Device und einen Call wieder.
Häufig werden Verbindungen über Tk-Anlagen-Grenzen hinaus geführt. Dadurch ist der Zugriff auf den Zustand der nicht-lokalen Devices nur sehr begrenzt möglich. Ich unterscheide daher bei meiner Modellierung zwischen lokalen Devices, deren Zustand man immer in Erfahrung bringen kann, und anderen Devices (OtherDevices), über deren Zustand möglicherweise nur begrenzte Informationen vorliegen.
Abbildung 18: Meine Modellierung des Half-Call-Modells
Um den Zustand der Tk-Anlage verfolgen zu können, gibt es die Möglichkeit des Monitoring: Man fordert von der Tk-Anlage Informationen über die Zustandsänderungen der Basisobjekte (Device, Connection und Call) an. (Man sagt "ein Monitorpunkt wird gesetzt".) Dies ist für Devices oder für Calls möglich. Daraufhin wird man über alle Zustandsänderungen der mit dem beobachteten Objekt in Zusammenhang stehenden Connections informiert - die Zustände der Objekte selbst ergeben sich aus den Zuständen der Connections.
Der Name „Half-Call-Modell“ bezieht sich darauf, daß sich alle von der Tk-Anlage gemeldeten Zustandsänderungen immer auf das beobachtete ("gemonitorte") Device beziehen. Bei einer normalen Verbindung zwischen zwei Devices werden (sofern beide Devices beobachtet werden) also zwei „Stränge“ in der Art von Abbildung 18 gehalten, wobei jeweils ein Device als OtherDevice repräsentiert ist. Ein „Strang“ ist also die Hälfte der über einen Call vorliegenden Informationen.
3.5 Probleme der Computer-Telefonie
Im folgenden sollen nur kurz einige Kernprobleme bei der Steuerung von Tk-Anlagen aufgezählt werden. Sie sind bei Micrologica beim Umgang mit der bisher eingesetzten Software erkannt worden und haben als Grundlage für die Definition von hot spots in unserem neu erstellten Framework gedient.
3.5.1 Vielfältige Hardware-Landschaft
Das größte Problem für Computer-Telefonie-Anwendungen ist die Hardwareansteuerung, da es eine große Zahl von Tk-Anlagen (und noch mehr Modelle) auf dem Markt gibt und sich diese in Art, Anzahl und Implementation ihrer Fähigkeiten z.T. deutlich unterscheiden. Um nicht auf eine kleine Zahl unterstützter Modell festgelegt zu sein, ist eine hardwareunabhängige Programmierung von großer Wichtigkeit.
Diese Situation könnte sich in der Zukunft einerseits durch die stärkere Verbreitung von CSTA-konformen Hardware-Implementierungen etwas entschärfen, aber es ist zu erwarten, daß dies durch die starke Dynamik des Marktes mit dem Erscheinen von neuen Tk-Anlagen bzw. Modellen kompensiert wird.
3.5.2 Keine exklusive Steuerung bei LAN-zentrierten Konfigurationen
Durch die Verwendung einer LAN-zentrierten Hardware-Konfiguration kommt es dazu, daß weder die Telefonie-Anwendung noch der Tk-Anlagen-Treiber eine exklusive Kontrolle über den Zustand und das Verhalten der Tk-Anlage haben. Ein Treiber kann bei keinem Kommando an die Tk-Anlage sicher sein, daß diese es ausführen kann, da sich ihr Zustand bereits verändert haben könnte.
Der Treiber ist auf den Event-Strom mit Zustandsmeldungen angewiesen, um ein internes Modell des realen Zustands zu führen und immer wieder zu aktualisieren. Je höher das Anrufvolumen ist und je langsamer der CTI-Link arbeitet, desto größer wird die zeitliche Verzögerung, mit der der Treiber sein internes Modell aktualisieren kann, und um so höher ist die Wahrscheinlichkeit, daß der Treiber Kommandos abschickt, die nicht bearbeitet werden können.
Diese Tatsache muß im Programmiermodell für Telefonie-Anwendungen unbedingt berücksichtigt werden. Einerseits geschieht dies dadurch, daß die Events immer alle vorhandenen Informationen beinhalten - eine Nachfrage ist ja nicht möglich. Andererseits kann der Tk-Anlagen-Treiber bei keinem Kommando an die Tk-Anlage davon ausgehen, daß es auf jeden Fall erfolgreich verarbeitet werden kann, sondern muß immer eine intensive Fehlerüberprüfung vorsehen.
Zur Illustration sei auf Abbildung 12 (LAN- bzw. Server-zentrierte Konfiguration [Burton 95]) verwiesen: Man überlege sich, wie ein Tk-Anlagen-Treiber reagieren sollte, der versucht, ein Gespräch auf einen Telefonapparat zu vermitteln, den der Benutzer gerade abgehoben hat, wobei das Event über das Abheben den Treiber noch nicht erreicht hat.
3.5.3 Verlorene Events
Die Erfahrung beim Umgang mit Tk-Anlagen hat außerdem gezeigt, daß diese unter starker Last (großes zu vermittelndes Anrufvolumen) z.T. Events verlieren. Bei einem Tk-Anlagen-Treiber, der dies nicht berücksichtigt, divergiert in solchen Situationen sehr schnell sein internes Modell vom realen Tk-Anlagen Zustand.
Bei Kenntnis der verwendeten Tk-Anlage kann jedoch oft mit einer guten Wahrscheinlichkeit gesagt werden, welches Event verloren gegangen sein könnte, so daß dieses fehlende Event vom Tk-Anlagen-Treiber simuliert werden kann.
3.5.4 Unzureichende Standardisierung
Die mehrjährige Erfahrung bei Micrologica zeigt, daß die bisherigen Standards nicht eindeutig genug sind, um eine hardwareunabhängige Programmierung zu ermöglichen. So müssen bisher z.T. auch für Tk-Anlagen, für die ein TSAPI-Treiber vorliegt, unterschiedliche Programmversionen erstellt werden.
Folgende Eigenschaften von TSAPI haben sich dabei als besonders problematisch erwiesen:
· Aufgrund der unterschiedlichen Implementationen der Zustände bzw. Zustandsübergänge von Connections in den Tk-Anlagen definiert TSAPI kein verbindliches Modell der Connection-Zustände. So gibt es keine abschließende Liste aller möglichen Zustände, und auch die möglichen Zustandsübergänge sind nicht definiert. Es wird lediglich ein Beispiel eines möglichen Modells angegeben (siehe Abbildung 19), das von Anlagen-Herstellern jedoch beliebig verändert werden kann.
Abbildung 19: Zustandsmodell für Connections [Novell 95, S. 3-13]
· Es sind zwar alle nötigen Event-Typen zur Ablaufverfolgung definiert, ihr Auftreten bzw. die Reihenfolge des Auftretens ist jedoch nicht garantiert. Es wäre wünschenswert, wenn der Tk-Anlagen-Treiber diese Unterschiede zwischen den Tk-Anlagen ausgleichen würde und fehlende Events soweit möglich simulieren könnte. Dieser Vorgang wird im Telefonie-Bereich als Event-Normalisierung bezeichnet.
Definition 21: Event-Normalisierung
Die Konvertierung des anlagenspezifischen Event-Stroms in eine anlagenunabhängige Reihenfolge und Darstellung wird als Event-Normalisierung bezeichnet. Es dient dem Ausgleich herstellerspezifischer Anlagen-Eigenschaften.
3.6 Ausgangspunkt zur Framework-Entwicklung
Trotz aller Probleme bei der hardwareunabhängigen Programmierung hat sich andererseits gezeigt, daß für die vom MCC benötigten Funktionen der Tk-Anlagen durchaus eine hardwareunabhängige Programmierung möglich sein müßte. Diese Erfahrungen haben uns als Grundlage gedient für die Entwicklung eines Frameworks für Tk-Anlagen-Treiber, des "Micrologica-Telefonie-Frameworks". Dieses Framework soll es ermöglichen, mit vertretbarem Aufwand Treiber für alle zu unterstützenden Tk-Anlagen zu erstellen.
Im folgenden Kapitel wird dieses Framework und seine Entstehung vorgestellt. Die in diesem Kapitel aufgezeigten Grundlagen und Probleme der Telefonie finden sich dort wieder als Kriterien zur Framework-Gestaltung, aber auch als Faktoren, die zu einer Evolution des Frameworks geführt haben.