4                  Das Micrologica-Telefonie-Framework Dieses Kapitel beschreibt das im Rahmen dieser Diplomarbeit erstellte Framework zur Steuerung von Tk-Anlagen. Wie in Kapitel 3.2 beschrieben, benötigt das Micrologica Communication Center (MCC) als Unterbau eine Reihe von Treibern für die verschiedenen Tk-Anlagen. Diese Treiber sind jeweils als eigene Prozesse realisiert. Die direkte Steuerung einer Tk-Anlage erfolgt durch den sog. TSERV-Prozeß. Micrologica hat bereits eine Reihe von Tk-Anlagen-Treibern in C programmiert und in den vergangenen Jahren eine beachtliche Erfahrung mit der Ansteuerung von Tk-Anlagen gesammelt. Mit der steigenden Zahl der zu unterstützenden Tk-Anlagen und der Erkenntnis, daß die realisierten Treiber große Ähnlichkeiten aufweisen, stieg der Bedarf an einem Konzept zur Erstellung von TSERV-Prozessen, das eine Code-Duplizierung vermeidet und es ermöglicht, schnell und effizient Treiber für neue Tk-Anlagen zu erstellen. Aus diesem Grund wurde beschlossen, ein objektorientiertes Framework für TSERV-Prozesse in C++ [Stroustrup 92] zu entwickeln, um die Erfahrungen im Telefonie-Bereich als Rahmen­architektur bereit­zustellen. Bei der Framework-Entwicklung konnten wir  auf die bereits gefundenen Abstraktionen aufbauen und diese objektorientiert umsetzen. 4.1          Bisherige Architektur Das Micrologica Communication Center besteht aus einer ganzen Reihe von Prozessen, die mittels Interprozeßkommunikation (IPC) miteinander in Verbindung stehen. Schichtenartig bauen Prozesse mit höheren Abstraktionen auf darunterliegenden Prozessen auf. Abbildung 20 zeigt einen Ausschnitt der beteiligten Prozesse. Bei den Kommunikations­beziehungen der Prozesse in der Abbildung wird zwischen dem Kommunikationsmedium (Transport der Information) und dem über dieses Medium realisierten Kommunikations­protokoll (Ablauf der Kommunikation) unterschieden. Der hier mit MCC bezeichnete Prozeß besteht, je nach Konfiguration, aus einer Reihe von Einzel-Prozessen, die die eigentliche Telefonie-Anwendung aus Sicht des Anwenders realisieren. Dies ist bei weitem der umfangreichste Teil der gesamten Konfiguration. Der ACD_TC-Prozeß bietet dem MCC eine vereinfachte und auf seine Bedürfnisse zugeschnittene (proprietäre) Schnittstelle zu den Tk-Anlagen. Weiterhin ist er für die Koordination von Tk-Anlagen-übergreifende Vermittlung von Anrufen zuständig, d.h. die Arbeit mit mehreren Tk-Anlagen gleichzeitig. Der ACD_TC-Prozeß kommuniziert mit dem MCC über das proprietäre ACD_TOP-Protokoll. Der TSERV-Prozeß übersetzt die Requests des Telefonie-Protokolls (TSAPI) in Tk-Anlagen-spezifische Befehle (siehe Kapitel 3.4) und steuert mit diesen die Anlage. Er benötigt hierzu ein Modell des aktuellen Zustandes der Tk-Anlage, die er steuert. Es gibt von diesem Prozeß verschiedene Ausprägungen, die jeweils an eine bestimmte Tk-Anlage angepaßt sind. Diese Prozesse wurden auf Basis des Micrologica-Telefonie-Frameworks neu implementiert. Um den TSERV-Prozeß beliebig im LAN plazieren zu können, steuert dieser nicht direkt die Tk-Anlage, sondern schickt die vorbereiteten Befehle an den (sehr einfachen) TM-Driver-Prozeß, der sie an die Tk-Anlage durchreicht. Hierdurch wird der TSERV auch von der direkten Hardwaresteuerung befreit, die im TM-Driver gekapselt ist. Abbildung 20: Telefonie-Prozesse Diese Architektur ist sehr flexibel skalierbar, da alle Prozesse per Interprozeßkommunikation (IPC) miteinander kommunizieren und je nach zu erwartender Last alle auf einer Workstation oder alle auf unterschiedlichen Workstations im LAN ablaufen können. 4.1.1      Probleme der bisherigen Architektur Es hat sich als sehr aufwendig herausgestellt, daß sowohl vom ACD_TC- als auch vom TSERV-Prozeß für jeden neu zu unterstützenden Tk-Anlagentyp eine neue Ausprägung erstellt werden mußte bzw. existierende Varianten modifiziert werden mußten. Die Erstellung neuer TM-Driver war weniger aufwendig. Diese Prozesse waren bisher in der Programmiersprache C realisiert und wurden angepaßt, indem der Quelltext kopiert und für den neuen Tk-Anlagentyp modifiziert wurde. Mit der Tatsache, daß der TSERV-Prozeß für jeden Tk-Anlagentyp modifiziert werden müßte, war gerechnet worden. Es stellte sich jedoch heraus, daß sich die verschiedenen Tk-Anlagen­typen innerhalb der Grenzen des Telefonie-Protokolls so stark unterschieden (siehe Kapitel 3.5.4), daß jeweils angepaßte ACD_TC-Prozesse nötig waren. 4.2          Ziele der Framework-Entwicklung Die Motivation zur Entwicklung eines Frameworks lag in dem Wunsch, größere Teile des TSERV-Prozesses bei der Erstellung neuer Ausprägungen wieder zu verwenden und eine Code-Duplizierung mit dem damit verbundenen erhöhten Wartungsaufwand zu vermeiden. Zusätzlich sollte nach Möglichkeiten gesucht werden, das Verhalten aller unterstützten Tk-Anlagen soweit zu vereinheitlichen, daß nur noch eine Ausprägung des ACD_TC-Prozesses benötigt wird, die unabhängig ist von der aktuell verwendeten Tk-Anlage. Die langjährige Erfahrung im Telefonie-Bereich, die sich einzelne Mitarbeiter erworben haben, sollte in Form einer Rahmenarchitektur allen, auch neuen, Mitarbeitern zur Verfügung gestellt werden. Als Fernziel wird es für möglich gehalten, daß einige der für den TSERV erstellten Abstraktionen auch in anderen Treiberprozessen verwendet werden können. Diese Möglichkeit habe ich im Rahmen meiner Diplomarbeit jedoch nicht untersucht. Durch die Prozeßarchitektur des MCC-Systems war es möglich, zunächst nur die TSERV-Prozesse auf ein objekt­orientiertes Framework umzustellen. Die Umstellung anderer Prozesse des MCC-Systems in ähnlicher Weise wird z.Z. erwogen. Konkret sollten durch die Framework-Entwicklung folgende Ziele vorrangig erreicht werden: ·      schnelle Erstellung von TSERV-Prozessen für weitere Tk-Anlagentypen ·      Kapselung des unterschiedlichen Verhaltens der Anlagentypen im TSERV-Prozeß ·      strengere Protokollspezifikation für die Telefonie-Protokolle, um eigene Anwendungs­entwicklung zu erleichtern (siehe Kapitel 3.5.4) ·      Möglichkeit zur Unterstützung mehrerer Telefonie-Protokolle, da die Entwicklung des Marktes bzw. der Kundenwünsche nach speziellen Protokollen nicht absehbar ist Wie diese Zielsetzung umgesetzt wurde, soll der nächste Abschnitt anhand der gewählten Architektur verdeutlichen. 4.3          Aufbau des Frameworks Das Design des Frameworks ist einerseits geprägt von dem technischen Anwendungsbereich und andererseits von den bisher bei Micrologica gemachten Erfahrungen mit der Entwicklung von Telefonie-Systemen. Da die Anwender des Frameworks Softwareentwickler sind, die oft bereits einiges Hintergrundwissen im Telefonie-Bereich haben, haben wir uns nicht gescheut, auf den bekannten technischen Abstraktionen aufzubauen. Die im Framework enthaltenen fachlichen Abstraktionen sind nur zu einem geringen Teil bei der Entwicklung des Frameworks entstanden. Fast immer sind sie das Ergebnis der bei der konventionellen Programmierung in C gemachten Erfahrungen. Wir haben die dort gefundenen Abstraktionen „lediglich“ objektorientiert modelliert und in Form eines Frame­works zur Spezialisierung für konkrete Anwendungsfälle zur Verfügung gestellt. Bei der Modellierung der hot spots des Frameworks haben wir uns auf die Erfahrung der Mit­arbeiter verlassen, die im Telefonie-Bereich über langjährige Erfahrung verfügen. Intern wird der vom Framework modellierte TSERV-Prozeß nicht in Schichten, sondern in Bereichen von fachlich zusammen­gehörigen Klassen strukturiert. Das Framework ist in 5 voneinander streng getrennte Bereiche gegliedert: ·      Ein abstraktes Modell eine Tk-Anlage, die sog. „Virtuelle Tk-Anlage“ ·      Das Telefonie-Protokoll ·      Das Tk-Anlagen-Protokoll ·      Die Telefonie-Basis-Objekte ·      Die softwaretechnische Basis Diese Bereiche sind streng voneinander getrennt und bauen aufeinander auf. Diese Struktur ist in Abbildung 21 dargestellt. Abbildung 21: Die Bereiche des Micrologica-Telefonie-Frameworks Die Pfeile zeigen an, in welcher Richtung die einzelnen Bereiche aufeinander aufbauen. Insbe­sondere im Fall von bidirektionalen Abhängigkeiten sind die Bereiche lediglich über allgemeine Oberklassen wie z.B. "Nachrichtenempfänger" miteinander gekoppelt, um ihre Unabhängigkeit voneinander zu gewährleisten. Implementierungen der Bereiche sind einzeln austauschbar. Dadurch lassen sich große Teile der Implementation in unter­schiedlichen Ausprägungen der TSERV-Prozesse wieder­verwenden. Somit wird die Entwicklungszeit für neue Ausprägungen drastisch reduziert, da oft nur ein Bereich neu implementiert werden muß. Im günstigsten Fall liegen bereits Implementationen für alle Bereiche im Framework vor, die nur noch kombiniert werden müssen. Auf der Ebene dieser Bereiche ist das Framework als Black-Box-Framework angelegt. Die interne Realisierung der Bereiche ist jedoch eher ein White-Box-Framework. Es wird angenommen, daß die Implementation des Tk-Anlagen-Protokolls die weitaus häufigste Veränderung ist, die für neue Ausprägungen des TSERVs notwendig sein wird. Die Zahl der existierenden Telefonie-Protokolle ist dagegen sehr gering (vgl. Kapitel 3.4). 4.3.1      Die Bereiche im Überblick An dieser Stelle möchte ich einen Überblick über die Aufgabenverteilung der einzelnen Bereiche geben. Eine detaillierte Beschreibung würde den Rahmen dieser Arbeit sprengen. Auf eine Reihe interessanter Aspekte werde ich jedoch in Kapitel 5 noch genauer eingehen. Zum Verständnis der folgenden Diskussionen ist jedoch ein grobes Verständnis des Zusammen­spiels der Bereiche notwendig. Die Virtuelle Tk-Anlage verkörpert eine abstrakte Tk-Anlage, die ein Modell der real zu steuernden Tk-Anlage enthält. Aufträge an die Tk-Anlage, sog. Requests, werden ihr zur Aus­führung übergeben. Die Requests selbst sind Teil der von uns modellierten Telefonie-Basis-Objekte. Die Virtuelle Tk-Anlage ihrerseits verschickt Meldungen über Zustandsänderungen in der Tk-Anlage (genauer: in ihrem Modell der Tk-Anlage), sog. Events. . Dieser Bereich wird durch eine einzige Klasse (ocVirtualPbx) nach außen vertreten. Alle Implementationsdetails dieses Bereichs sind hinter dieser Fassade verborgen. Der Bereich Telefonie-Protokoll enthält Konverter, die die Requests an die Tk-Anlage bzw. die Events von der Tk-Anlage zwischen einer internen Darstellung und der Darstellung des jeweiligen Protokolls konvertieren. Um ein anderes Telefonie-Protokoll zu unterstützen, würde dieser Bereich komplett ausgetauscht und durch eine, mit den Telefonie-Basis-Objekten erstellte, neue Implementierung ersetzt werden. Analog zum Telefonie-Protokoll enthält der Bereich Tk-Anlagen-Protokoll Konverter, um Events von der Tk-Anlage in die intern verwendete Darstellung zu konvertieren. Weiterhin enthält dieser Bereich spezielle Ableitungen der Requests, um diese auf der jeweiligen Tk-Anlage ausführen zu können. Die Telefonie-Basis-Objekte modellieren die Grundelemente, mit denen ein Tk-Anlagen-Treiber umgehen muß. So sind u.a. die "Objekte" des Half-Call-Modells (Call, Device, Connection) vorhanden, aber auch ein Modell für Aufträge an die Tk-Anlage, sog. Requests. Die Requests enthalten alle zu einem Auftrag gehörigen Daten sowie eine Zustandsmaschine (engl. finite state machine, FSM), die den Stand der Bearbeitung und die in jedem Zustand notwendigen Aktionen modelliert. Der Bereich Softwaretechnische Basis ist nicht telefonie-spezifisch. Er enthält z.B. Container­klassen, ein Meta-Object-Protocol oder eine generische Implementierung des Singleton-Musters (siehe Kapitel 5.3.2). Für die Erstellung von TSERV-Prozessen ist die Abtrennung der Telefonie-Basis-Objekte sowie der softwaretechnischen Basis nicht notwendig. Sie werden höchstwahrscheinlich immer in dieser Form verwendet werden und könnten daher Teil der Virtuellen Tk-Anlage sein. Es wäre jedoch denkbar, daß sie in anderen Prozessen getrennt von ihr verwendbar sind. 4.3.2      Aufträge an die Tk-Anlage: Requests Die konkrete Steuerung der Tk-Anlage erfolgt durch Requests (siehe Definition 19). Ein zentrales Problem bei der Aufteilung des TSERV-Prozesses in einzeln austauschbare Bereiche war die Behandlung der Requests. Mit ihnen muß in mehreren Bereichen umgegangen werden: Die Aufträge gehen in einem vom Telefonie-Protokoll abhängigen Format beim TSERV ein, und die Abarbeitung wird von der Virtuellen Tk-Anlage gesteuert, wobei die Befehle an die Tk-Anlage vom jeweiligen Anlagentyp abhängen. Es mußte also eine Modellierung gefunden werden, die die Unabhängigkeit der einzelnen Bereiche wahrt. Im Telefonie-Bereich ist es üblich, die Abläufe von Requests mit Zustandsmaschinen (engl. Finite State Machines, FSMs) zu modellieren, da die Abläufe vom aktuellen Zustand der beteiligten Geräte (bzw. der Objekte im Half-Call-Modell) abhängen. Die von uns modellierten Requests enthalten daher neben den zur Steuerung nötigen Daten (z.B. anzurufende Telefon­nummer) eine FSM, die den Ablauf des Requests steuert. Die gefundene Lösung zur Modellierung von Requests verwendet das State-Muster aus [GHJV 95, S. 305] zur Modellierung der FSMs. Sie erreicht über eine mehrstufige Vererbungs­hierarchie die Unabhängigkeit der einzelnen Bereiche. Dabei sind die unter­schiedlichen Hierarchieebenen verschiedenen Bereichen zugeordnet. Abbildung 22 zeigt diese Vererbungs­hierarchie am Beispiel eines MakeCall-Requests. Dabei hat jedes Request entsprechend dem State-Muster einen Zeiger auf ein Zustandsobjekt vom Typ RequestState. Dieses Zustandsobjekt ist typischerweise ein Singleton. Von der Klasse RequestState werden dann die konkreten Zustandsklassen abgeleitet. Beim Erreichen eines neuen Zustands wird automatisch die Methode ActionOnEnter ausgeführt. Alle eintreffenden Events werden zur Verarbeitung an das aktuelle Zustandsobjekt delegiert. Eine wesentliche Erweiterung des State-Musters besteht darin, daß bei unserer Modellierung sowohl die Request-Klassen als auch Zustandsklassen über mehrere Vererbungsstufen spezialisiert werden. Hierdurch wird es möglich, zum einen die Gemeinsamkeiten aller Requests abzubilden, z.B. daß sie alle am Ende der Verarbeitung entweder erfolgreich erledigt sind (DoneState) oder fehlschlugen (FailedState). Andererseits wird Vererbung eingesetzt, um die allgemeinen Teile von den anlagenspezifischen Teilen zu trennen.   Wieder-verwendung Klassen Framework-Bereich Abbildung 22: MakeCall-Klassen Um die Erzeugung der Tk-Anlagen-spezifischen Requests vom Telefonie-Protokoll unabhängig zu gestalten, werden die Requests im Telefonie-Protokoll-Bereich immer über eine abstrakte Fabrik-Klasse [GHJV 95, S. 87] erzeugt. 4.4          Benutzung des Telefonie-Frameworks Der Anwendungsentwickler, der einen neuen Tk-Anlagen-Treiber implementieren möchte, leitet eine Klasse von der Klasse ocTservProzess ab und muß die aufgeschobene Methode vConfig() implementieren. Danach kann der Prozeß mit der Methodenfolge vInit(), vRun(), vDone() gestartet werden (siehe Abbildung 23). Die Tatsache, daß die einzige in dieser Klasse implementierte Methode nicht direkt aufgerufen wird, ist ein typisches Beispiel für den invertierten Kontrollfluß in diesem Framework.   class ocNewTserv : public ocTservProcess { public:     virtual void vConfig(void)     {         // Erzeugen der Tk-Anlagen-spezifischen Objekte         poPbxEventConverter = new ocAclEventConverter;         poRequestFactory = new ocAclRequestFactory;           // Erzeugen der Telefonie-Protokoll-spezifischen Objekte         poTelephonyEventConverter = new ocTsapiEventConverter;         poTelephonyRequestConverter = new ocTsapiRequestConverter;           // Konfiguration         vSetPbxEventConverter(poPbxEventConverter);         vSetRequestFactory(poRequestFactory);         vSetTelephonyEventConverter(poTelephonyxEventConverter);         vSetTelephonyRequestConverter(poTelephonyRequestConverter);     }; };   int main() {     ocNewTserv oTserv;       oTserv.vInit();     oTserv.vRun();     oTserv.vDone();     return 0; } Abbildung 23: Typische Verwendung des Frameworks Wenn es zu allen verwendeten Bereichen bereits passende Implementationen gibt, beschränkt sich die Arbeit des Anwendungsentwicklers lediglich auf das Konfigurieren und Parametrisieren dieser Implementationen. Für eine neue Tk-Anlage muß der Bereich des Tk-Anlagen-Protokolls neu implementiert werden. Er besteht zum einen aus einem Event-Konverter, der die anlagenspezifischen Events in ein internes Format umwandelt, und zum anderen aus für die konkrete Anlage spezialisierten Requests. Die Requests werden durch Vererbung aus generischen Requests aus den Telefonie-Basis-Objekten abgeleitet. Außerdem muß eine Unterklasse der Fabrik-Klasse gebildet werden, die die anlagenspezifischen Requests erzeugt. 4.5          Vorgehensweise bei der Framework-Entwicklung Die Entwicklung des Telefonie-Frameworks begann mit einer Reihe von Interviews mit den bisher an der Entwicklung beteiligten Personen. In diesen Interviews wurden sog. "Kommunikations-­Szenarien" erstellt, die die Kommunikation zwischen den einzelnen Prozessen des MCC-Systems beschreiben. Das Design des bestehenden Systems wurde zunächst dokumentiert, wobei die Dokumente in mehreren Autor-Kritiker-Zyklen überarbeitet wurden. Bei der Besprechung unserer Entwicklungs­dokumente war es sehr hilfreich, daß unsere Gesprächs­partner ebenfalls Software-Entwickler waren und so leicht eine "gemeinsame Sprache" gefunden werden konnte. Sie hatten intensive Kenntnisse im Telefonie-Bereich. Da sie nicht aktiv am Design des Frame­works, sondern nur als Interviewpartner zum Erfahrungsaustausch an der Entwicklung beteiligt waren, gab es keine Probleme mit evtl. nicht vor­handenen Kenntnissen in objekt­orientierten Vorgehensweisen. Bei der Erstellung dieser Szenarien wurde viel Wert auf das Warum der einzelnen Kommunikations­schritte gelegt. Dies hat sich beim Design der Framework-Struktur als sehr hilfreich erwiesen. Da der Fokus nicht auf der Beschreibung des Kommunikationsprotokolls lag (das auch zur Disposition gestanden hätte, wären gravierende Probleme gefunden worden), wurden die Kommunikations-Szenarien nicht formalisiert (z.B. als Interaktionsdiagramme) erstellt, sondern in Prosa (Freitext) formuliert. Parallel zur Erstellung der Kommunikations-Szenarien wurde ein Glossar der bei Micrologica üblichen Terminologie im Telefonie-Bereich angelegt. Dies half, die einzelnen Begriffe schärfer gegen­einander abzugrenzen und die Grundlage für gemeinsames Verständnis aller Beteiligten zu legen. Weiterhin konnte das entstandene Glossar auch anderweitig zur Einarbeitung von neuen Mitarbeitern, die z.T. nicht einmal direkt an Entwicklungen im Telefonie-Bereich beteiligt sind, eingesetzt werden. Die bisherige Prozeßstruktur wurde in Diagrammen visualisiert. Bei diesem Vorgehen wurden bereits kleinere Ineffizienzen in der Kommunikation zwischen den Prozessen erkannt, die ohne größeren Aufwand im bestehenden System behoben werden konnten, so daß z.B. die erzeugte Netzlast im LAN reduziert wurde. Das erste Design des Telefonie-Frameworks wurde mit Hilfe von CRC-Karten [Beck 89] erstellt. Die Verwendung von CRC-Karten hat sich als sehr nützlich erwiesen, um das dynamische Verhalten des zu entwickelnden Systems zu entwerfen. Insbesondere die Flexibilität des Ansatzes und die Möglichkeit, mit mehreren Personen gleichzeitig an dem Entwurf arbeiten zu können, war hilfreich und hat zu einem gemeinsamen Verständnis beigetragen.