Projektarbeit Entwurf und Implementierung eines

Projektarbeit
Entwurf und Implementierung eines
Callcenters für ein Web-Service-basiertes
VoIP-Framework
Aneta Kabzeva
Januar 2006
Betreuer: Prof. Dr. Paul Müller
Dipl.-Inform. Markus Hillenbrand
Fachbereich Informatik
AG Integrierte Kommunikationssysteme
Universität Kaiserslautern · Postfach 3049 · 67653 Kaiserslautern
Abstract
Callcenter sind im heutigen Informationszeitalter viel mehr als einfache
Anrufzentralen. Sie haben sich zu einem zentralen Dienst entwickelt, in dem
Computertechnik und Telekommunikation zusammenwachsen. Das Internet
spielt auch schon eine wichtige Rolle in der Telekommunikationsbranche.
Die Internettelefonie setzt sich immer mehr gegenüber der klassischen Telefonie durch. Sie ist kostengünstiger und bietet schon eine große Anzahl von
Funktionalitäten. Diese Projektarbeit beschäftigt sich mit dem Entwurf und
der Implementierung eines Callcenter-Dienstes für das Web-Service-basierte
VoIP-Framework Venice, welches an der TU Kaiserslautern entwickelt
wurde.
Inhaltsverzeichnis
Inhaltsverzeichnis
Kapitel 1:
Einleitung........................................................................................................ 5
Kapitel 2:
Grundlagen ..................................................................................................... 6
2.1
Callcenter............................................................................................................. 6
2.1.1
Callcenter-Arten.............................................................................................................. 6
2.1.2
Callcenter-Technik.......................................................................................................... 7
2.2
VoIP .................................................................................................................... 7
2.2.1
Funktionsprinzip ............................................................................................................. 8
2.2.2
Technische Standards...................................................................................................... 9
2.2.3
Erreichbarkeit ............................................................................................................... 10
2.2.4
Vor- und Nachteile von VoIP ........................................................................................ 11
2.3
Web Services ..................................................................................................... 12
2.3.1
Extensible Markup Language (XML) und XML Schema Definition (XSD) .................. 15
2.3.2
SOAP ........................................................................................................................... 17
2.3.3
Hyper Text Transfer Protocol (HTTP)........................................................................... 18
2.3.4
Web Service Description Language (WSDL) ................................................................ 18
2.3.5
Universal Description, Discovery and Integration (UDDI)............................................. 21
2.4
Das Venice-Framework...................................................................................... 23
2.4.1
Architektur des Venice-Frameworks ............................................................................. 25
2.4.2
Verarbeitung von Telefongesprächen ............................................................................ 27
2.4.3
Metering-, Accounting- und Billing............................................................................... 28
2.4.4
Leistungsmerkmale (Supplementary Services)............................................................... 28
2.5
Zusammenfassung.............................................................................................. 29
Kapitel 3:
Entwurf und Implementierung eines Callcenters ....................................... 32
3.1
Software-Pakete und Werkzeuge........................................................................ 32
3.2
Callcenter-Datenbankstruktur............................................................................. 33
3.3
Callcenter-XML-Schema ................................................................................... 34
3.4
Callcenter-Schnittstellen .................................................................................... 35
3.4.1
Administrationsschnittstelle .......................................................................................... 35
3.4.2
Agentenschnittstelle ...................................................................................................... 39
3.5
Callcenter-Funktionsprinzip ............................................................................... 40
Inhaltsverzeichnis
Kapitel 4:
Zusammenfassung und Ausblick ................................................................. 46
Literaturverzeichnis .......................................................................................................... 48
Abbildungsverzeichnis....................................................................................................... 50
Abkürzungen ..................................................................................................................... 51
Einleitung
5
Kapitel 1: Einleitung
In unserem heutigen Kommunikationszeitalter spielt das Telefon eine unersetzliche Funktion. Eine
Welt ohne die Telekommunikation ist heute undenkbar. Die Telekommunikation hat in den letzten
Jahren auch die Vorteile des Internets erkannt, und beide Technologien wachsen zusammen. Das
Telefonieren über das Internet (Voice Over IP) ist ein vielversprechendes Ergebnis dieser
Zusammenarbeit. Die rasante Verbreitung des Internet weltweit, die Einführung von Flatrates und
zeitunabhängigen Tarifen hat ein großes Interesse an der Internettelefonie geweckt. Eine
Internetverbindung ist in allen Firmen und fast allen privaten Haushalten verfügbar. Die IP-Telefonie
spart deshalb nicht nur Telefonkosten, sondern auch die Kosten für die Telefonleitung und den
doppelten Verkabelungsaufwand. Viele der Leistungsmerkmale der herkömmlichen Telefonie (z.B.
Gesprächsweiterleitung, Anrufbeantworter oder Dreierkonferenz) werden auch von den VoIPSystemen auf dem Markt angeboten. Die Kombination mit dem Internet ermöglicht sogar die
Einführung von neuen Leistungsmerkmalen wie z.B. die Aufzeichnung einer Nachricht als E-Mail.
Ein wichtiges Merkmal für große Firmen ist die Callcenter-Funktion eines Telefonsystems. Diese
Projektarbeit beschäftigt sich mit dem Entwurf und der Implementierung eines Callcenter-Dienstes für
ein Web-Service-basiertes VoIP-Framework, das an der Technische Universität Kaiserslautern von der
Arbeitsgruppe ICSY im Rahmen eines Projekts namens Venice entwickelt wurde.
Im nächsten Kapitel werden die Grundlagen erklärt, die für das Verständnis der Arbeit notwendig
sind. Zuerst wird der Begriff Callcenter definiert und die Callcenter-Arten werden vorgestellt. Dann
wird kurz beschrieben, wie die Technik in einem Callcenter aussieht. Im zweiten Unterkapitel wird
VoIP näher erläutert – wie es funktioniert, welche seine Vor- und Nachteile sind. Danach, im dritten
Unterkapitel, wird die Web-Services-Technologie mit den Basisstandards XML, SOAP, HTML,
WSDL und UDDI erklärt. Im letzten Teil des Kapitels wird das Venice-Framework vorgestellt, auf
dem diese Projektarbeit aufbaut. Es wird eine Architektur präsentiert, mit der VoIP über Web-Services
funktioniert.
Im dritten Kapitel wird gezeigt, wie das Venice-Framework um die Callcenter-Funktionalität erweitert
wird. Dabei wird zuerst die Aufgabe der Projektarbeit genau formuliert. Nachfolgend wird die
entwickelte Lösung vorgestellt. Im ersten Unterkapitel sind die verwendeten Software-Pakete und
Werkzeuge aufgezählt. Als nächstes wird die Struktur der benutzten Datenbank und das definierte
XML-Schema für die nötigen Datentypen in getrennten Unterkapiteln erklärt. Die Schnittstellen für
den Callcenter-Administrator und die Agenten sind im vierten Teil des Kapitels beschrieben. Der
letzte Teil erläutert das Callcenter-Funktionsprinzip nach einem Aufruf des Dienstes.
Daraufhin wird eine kurze Zusammenfassung der Projektarbeit angegeben, die die wichtigsten
Aspekte noch einmal hervorhebt. Im anschließenden Ausblick werden Ergänzungsvorschläge
gemacht, die den entwickelten Callcenter-Dienst verbessern können.
Grundlagen
6
Kapitel 2: Grundlagen
2.1 Callcenter
Die Geschichte der Callcenter begann um 1920, als die ersten Rufnummerauskunft-Zentralen der
Telefongesellschaften entstanden. Später, in den sechziger Jahren, wurde von den Versandhändlern
und Fluggesellschaften eine Organisationsform für die Optimierung des Kundenkontakts eingerichtet.
1973 erfand die Firma Rockwell das erste Anrufverteilsystem (ACD – Automatic Call Distributor)
und setzte so die heutige Form der Callcenter ein [CallCenter].
Heutzutage hat fast jeder den Begriff „Callcenter“ schon einmal gehört, aber nur wenige wissen, was
er genau bedeutet. Es gibt keine feste, wissenschaftliche Definition für Callcenter. Durch eine
Zusammenfassung der wichtigsten Eigenschaften kann ein Callcenter wie folgt definiert werden:
Ein Callcenter ist eine Organisationseinheit, die für die Bearbeitung von Kontakten optimiert ist. Sie
zeichnet sich durch eine hohe Serviceorientierung des Personals, einen spezifischen Arbeitsprozess
zur effizienten Bearbeitung von Kontakten und eine besondere technische Infrastruktur für die gezielte
Steuerung der Kommunikationsvorgänge aus [CallCenter].
Die sogenannte Callcenter-Branche ist sehr umfangreich. Callcenter werden für Informationszwecke
(Hotline oder Helpdesks), Kundenberatung und Dienstleistung, Bestellannahme (z.B. Versandhäuser
oder Ticket-Services), Beschwerdemanagement, Notfalldienste (z.B. ADAC) und auch für Markt- und
Meinungsforschung benutzt.
2.1.1 Callcenter-Arten
Callcenter unterscheiden sich in Hinsicht auf die Organisationsart (Inhouse-Callcenter und CallcenterDienstleister) und in Hinsicht auf die Kommunikationsrichtung (Inbound-Callcenter und OutboundCallcenter).
Das
Inhouse-Callcenter
ist
eine
unselbständige
Kommunikationsmanagement-
Organisationseinheit im Unternehmen selbst. Ein Callcenter-Dienstleister handelt dagegen rechtlich
selbständig im Auftrag verschiedener Firmen [CallCenter]. Als Inbound werden Callcenter bezeichnet,
die nur extern eingehende Anrufe entgegennehmen, d.h. der Kunde ruft das Callcenter an. Ein
Outbound-Callcenter wickelt ausschließlich ausgehende Telefonate ab, d.h. die Kunden bzw. potenzielle Kunden werden gezielt angerufen. In der Praxis gibt es auch Mischformen zwischen Inboundund Outbound-Callcenter [CaCe05].
Grundlagen
7
2.1.2 Callcenter-Technik
Die Telekommunikationsanlage (TK-Anlage) ist der Kern jedes Telefongesprächs. Sie verbindet die
anrufende und die angerufene Person miteinander. In einem Callcenter soll der anrufende Kunde mit
einem der Agenten – die Mitarbeiter des Callcenters – verbunden werden. Deswegen wird in diesen
Organisationseinheiten eine spezieller Typ von TK-Anlagen benutzt – die ACD. Sie ist zuständig für
die Weiterleitung der Anrufe an den Agenten.
Das ACD-System arbeitet oft mit der IT des Unternehmens zusammen. Dies wird durch die Computer
Technology Integration (CTI) ermöglicht. CTI bezeichnet die Integration von Datenbanken in
Telefonsysteme.
Oft verwenden Callcenter interaktive Sprachverarbeitungssysteme (IVR – Interactive Voice
Response). Das IVR-System dient dazu, die Agenten von Routineauskünften zu befreien. Der Anrufer
wird mit einem Sprachverarbeitungsgerät verbunden. Es werden verschiedene Möglichkeiten angeboten, die per Tonwahl, über die Tastatur oder per Sprache ausgewählt werden können [CallCenter].
Neben den klassischen Callcenter-Systemen setzt sich am Markt zunehmend eine neue Alternative ein
– die Voice over IP basierten Callcenter (VoIP-Callcenter). Anstatt die Sprache durch eine separate
Leitung zu übertragen, wie bei dem gewöhnlichen Telefonnetz, benutzt die IP-Telefonie das Internet
zum Transfer der Telefongespräche.
2.2 VoIP
Das Telefonnetz hat sich mehrmals seit der Erfindung des Telefons verändert. Am Anfang wurden die
Verbindungen mithilfe von Menschen aufgebaut. Später wurden die Menschen durch automatische
Wähler ersetzt. Die Signale wurden analog übertragen. Der nächsten Schritt in der Evolution des
Telefonnetzes (PTSN – Public Switched Telephone Network) war die Digitalisierung der Signale vor
ihrer Übertragung. Damit wurde ISDN (Integrated Services Digital Network) eingeführt [RuSi04]. Die
rasante Entwicklung des Internets als eines der wichtigsten Kommunikationsmedien in unserer Zeit
war der Auslöser der Idee für Internettelefonie. Den Anfang dieser neuen Technologie machte die
israelische Firma Vocaltec mit der Telefonsoftware „Internet Phone“ im Jahre 1995. Diese Software
funktionierte über IP, deswegen wurde die Technologie IP-Telefonie oder auch Voice over IP (VoIP)
genannt. Das Telefonieren mit „Internet Phone“ war nur zwischen zwei Computern mit Multimediaeinrichtung (Soundkarte, Mikrofon, Lautsprecher) möglich, die die gleiche Software benutzen. Die
Qualität der Sprachübertragung war schlecht. Die Verbindung war halbduplex, die Dialogteilnehmer
konnten also entweder sprechen oder zuhören [Dusc02]. Da die Verbindungsmöglichkeiten begrenzt
waren und Quality of Service nicht gewährleistet war, konnte sich VoIP noch nicht durchsetzen.
Erst durch die ersten Gateway-Produkte, die die Kommunikation zwischen dem Internet und dem
normalen Telefonnetz ermöglichten, gewann die Internettelefonie das Interesse der großen
Grundlagen
8
Telekommunikationsanbieter. Heute werden schon mehrere Internettelefonie-Programme von unterschiedlichen Softwarefirmen angeboten. Die Sprachqualität lässt sich sogar mit der in der klassischen
Telefonie vorhandenen vergleichen. Die schnelle Internetverbindungen, insbesondere die Verbreitung
von DSL (Digital Subscriber Line), bieten eine ausreichende Geschwindigkeit zur Datenübertragung,
was einer der entscheidenden Faktoren für die Qualität der Sprache ist. Außerdem benötigt man nicht
mehr unbedingt einen Computer, um über das Internet zu telefonieren. Es gibt auch schon IPTelefonapparate, die sich von den normalen Telefongeräten kaum unterscheiden.
2.2.1 Funktionsprinzip
Bei VoIP werden die analogen Signale, genau wie bei dem digitalen Telefonnetz, durch einen AnalogDigital-Umsetzer (A/D-Umsetzer) in digitale Form überführt und über Codecs (Coder/DecoderProgramme) in ein Binärformat umgewandelt (Abbildung 1). Je nach verwendetem Codec können die
Daten unterschiedlich stark komprimiert werden [IPT05]. Bei der Komprimierung gehen Informationen, die für das menschliche Ohr nicht wahrnehmbar sind, verloren. Damit wird die Datenmenge reduziert und die zur Übertragung benötigte Bandbreite wird entsprechend verringert. Nach der Übertragung werden die digitalen Signale durch einen Digital-Analog-Umsetzer (D/A-Umsetzer) wieder in
analoge Signale transformiert und über Lautsprecher ausgegeben (Abbildung 1).
Sprach-
A/D
Signale
Umsetze
Internet
D/A
Sprach-
Umsetze
Signale
Abbildung 1:Signalverarbeitung bei VoIP
Der wesentliche Unterschied zwischen dem herkömmlichen Telefonnetz und VoIP ist die
Vermittlungstechnik. Die Übermittlung beim PSTN ist verbindungsorientiert. Jedem Gespräch wird
eine freie Leitung mit fester Bandbreite zugeordnet. Diese Leitung steht für die Dauer des Gesprächs
ausschließlich zur Verfügung. Das hat den Vorteil, dass die Sprachqualität (QoS – Quality of Service)
sichergestellt wird. Der Nachteil ist, dass die Ressourcen des Systems ineffizient genutzt werden.
Wenn eine Nachrichtenverbindung aufgebaut wird, dann können über die belegte Leitung keine
andere Verbindungen bereitgestellt werden. Die Nachrichtenübertragung ist bei VoIP dagegen
verbindungslos. Die codierten Audiodaten werden in IP-Pakete aufgeteilt und über das Internet
transportiert. Beim Empfänger werden die Datenpakete in Audiosignale zurückgewandelt und
decodiert. Der Vorteil der Paketvermittlung ist, dass nicht genutzte Bandbreite für andere
Anwendungen zur Verfügung steht. So wird keine Leitung für die Dauer des Gesprächs blockiert und
Grundlagen
9
die Leitungskapazität effektiver ausgenutzt. Die Konkurrenz der Datenpakete mit Pakete anderer
Anwendungen ist der Grund, warum eine bevorzugte Weiterleitung der Sprachdaten notwendig ist.
Um eine Echtzeitübertragung und eine hohe Qualität der Sprachdaten (QoS) zu gewährleisten, dürfen
die Pakete der Nachricht nicht aufgehalten werden. Die Sprachdaten sollen eine höhere Priorität als
die anderen Daten im Netz haben. Alle Daten, die nicht in Echtzeit übertragen werden müssen, werden
ggf. gezielt verzögert, um die hoch priorisierten Sprachdaten passieren zu lassen. Trotz dieser
Priorisierungsmaßnahmen, kann das Netz durch eine hohe Anzahl an Sprachpaketen überlastet werden
und zu Übertragungsproblemen führen. Verzögerungen einzelner Datenpakete einer Nachricht führen
zu Tonstörungen auf Empfängerseite. Um große zeitliche Schwankungen (Jitter) zwischen dem Empfang von zwei Datenpaketen zu kompensieren, werden auf Empfängerseite sogenannte Pufferspeicher
(Buffer) eingesetzt, die mehrere Pakete für den Decoder zwischenspeichern. Der Einsatz des
Pufferspeichers verursacht aber eine Grundverzögerung (Delay), weil bei Gesprächsbeginn der Puffer
zuerst gefüllt werden muss [Nöll05]. Deswegen muss bei der Auswahl der Größe des Pufferspeichers
auch der daraus resultierende Delay beachtet werden.
Bei der Verbindung zwischen zwei Computer werden nun ein oder mehrere Router benötigt, die die
Daten an die Zieladresse richten [Dusc02]. Um Verbindungen zum klassischen Telefonnetz
herzustellen, verwendet man Vermittlungsrechner, die sogenannten Gateways. Diese Gateways
verbinden das Netzwerk des VoIP-Telefons mit dem üblichen Telefonnetz (Abbildung 2). Sie wandeln
Signale aus dem Computernetz in Signale für das Telefonnetz um (und umgekehrt) und leiten die
Anfragen in beide Richtungen weiter [Dusc02]. Diese Integration unterschiedlicher Netze wird
„Konvergenz der Netze“ genannt.
VoIP Netz
Gateway
Telefonnetz
Abbildung 2: Gateway als Vermittler zwischen VoIP-Netz und Telefonnetz
2.2.2 Technische Standards
Wie bei der klassischen Telefonie besteht ein VoIP-Telefongespräch aus zwei Vorgängen – dem
Verbindungsaufbau und der Datenübertragung. Der Verbindungsaufbau wird auch als Signalisierung
(Signaling) bezeichnet. Die Signalisierung dient dem Auf- und Abbau von Anrufen [RSL02] und
gescheht über Signalisierungsprotokolle. Die meistverbreiteten Signalisierungsprotokolle sind H.323
von der International Telecommunication Union (ITU) [ITU-H.323] und das Session Initiation Protokoll (SIP) der Internet Engineering Task Force (IETF) [HSSR02]. Das H.323 Protokoll entstand aus
dem ISDN-Bereich der Telefonie. Dieses Multimedia-Kommunikationsprotokoll der ITU garantiert
kein Quality of Service [RSL02] und ist schwer zu implementieren. Das SIP wurde dagegen speziell
Grundlagen
10
für den Verbindungsaufbau im Internet entwickelt. Es basiert auf das Hyper Text Transfer Protocol
(HTTP) und ist einfacher aufgebaut als H.323. Mittlerweile setzt sich SIP am Markt durch, weil es
eine große Anzahl von übergreifenden Diensten anbietet [RSL02].
Für die Datenübertragung wird - sowohl bei H.323-Systemen als auch für SIP-Systeme - das Real
Time Protokoll (RTP) verwendet. RTP wurde speziell für die Übertragung von Audio- und VideoDaten in Echtzeit entwickelt. Zu RTP gehören das Real Time Transport Protocol (RTTP) und das Real
Time Control Protocol (RTCP). Das RTTP ist zuständig für die Echtzeitübertragung der Daten. RTCP
wird für die Steuerung des Datentransports verwendet und sorgt für höheren QoS [Dusc02]. RTP
benutzt seinerseits das User Datagram Protocol (UDP) als Transportprotokoll, welches wiederum das
Internet Protocol (IP) als darunter liegende Protokollebene einsetzt (Abbildung 3).
RTP
TCP
RTCP
UDP
IPIP
IP
Abbildung 3: VoIP Protokoll Architektur
Grundsätzlich kann man auch das Transmission Control Protocol (TCP) verwenden. TCP bietet eine
zuverlässigere Datenübertragung als UDP, weil TCP bei der Vermittlung jedes einzelnen Paketes auf
positive (ACK) und negative (NAK) Empfangsbestätigungen wartet. Diese Wartezeiten führen oft zur
zeitlichen Verlängerung des Transports. Obwohl UDP keine gesicherte Datenübertragung garantiert,
ist bei ihm der Transport schneller, was wichtiger für die Echtzeitübertragung ist.
2.2.3 Erreichbarkeit
Für eine VoIP-Telefonverbindung ist eine eindeutige IP-Adresse und ein Port notwendig. Heute gibt
es aber viele Internet-Benutzer, die keine feste IP-Adresse haben, sondern eine dynamische IP-Adresse
verwenden, die sie bei jeder Netzverbindung zugewiesen bekommen. Ferner können sich mehrere
Benutzer eine IP-Adresse teilen, wenn sie einen Router mit Port Address Translation (PAT) oder mit
der etwas weiter verbreitete Network Address Translation (NAT) nutzen. Das SIP bietet eine Lösung
für dieses Problem. Die SIP-Endpunkte melden sich an einem SIP-Server. So können andere SIPEndpunkte den SIP-Server nach der gewünschten Adresse fragen. Der Server sendet die Adresse
zurück, und die Verbindung kann hergestellt werden. SIP bietet die Möglichkeit für eine E-Mail-artige
Adressierung. Das bedeutet, dass eine Adresse für das Telefonieren und als E-Mail benutzt werden
kann [IPT05].
Grundlagen
11
Es gibt aber auch Verfahren, die eine Rufnummerstruktur für die Internet-Telefonie anbieten, die den
herkömmlichen Rufnummern ähnlich ist. Ein solches Verfahren ist ENUM (Electronic Numbering)
der IETF [RSL02]. Bei ENUM werden die klassischen Telefonnummern umgekehrt aufgeschrieben
mit Punkten zwischen den einzelnen Ziffern. Die Nummern werden nach dem Schema der ITU-T
Empfehlung für internationale öffentliche Telefonnummern (E.164) dargestellt und werden an die
Internet-Infrastruktur-Domain „e164.arpa“ (Address and Routing Parameters Area) angehängt
[RSL02]. Somit wird z.B. die klassische Telefonnummer +49-631-1234 in 4.3.2.1.1.3.6.9.4.e164.arpa
umgewandelt.
Ein anderer Ansatz wurde von der Regulierungsbehörde für Telekommunikation und Post (RegTP)
vorgeschlagen. RegTP hat eine spezielle Vorwahl 032 für alle VoIP- Dienste eingeführt. Sie ist seit
Januar 2005 verfügbar [Nöll05]. Unter http://www.032auskunft.de wird sogar schon ein Telefonbuch
bereitgestellt.
2.2.4 Vor- und Nachteile von VoIP
VoIP bietet viele Vorteile. Die VoIP-Technologie ist kostengünstig. Das IP-Netz kann besser
ausgelastet werden als das Telefonnetz, weil die Gespräche nur einen Teil der Bandbreite benötigen,
und die Leitung kann so für verschiedene Diensten parallel benutzt werden. Die Gespräche über das
Internet sind billiger, denn es ist egal, ob sie Orts- oder Internationalgespräche sind. Außerdem sind
nicht mehr zwei getrennte Netzwerke für die Telefonie und die Datenübertragung nötig. Die
Konvergenz der Netze erspart doppelte Verkabelung, Technik und damit auch Personalaufwand für
die Instandhaltung und das Aufbauen der Netze. Heutzutage ist ein DSL-Anschluss in fast jeden
Haushalt vorhanden, was das Umsteigen auf Internet-Telefonie erleichtert.
Die Netzwerkkonvergenz ermöglicht auch viele neue Anwendungen. Vorstellbar sind Systeme, die
eine gesprochene Nachricht in Textmeldung transformieren und andersherum solche, die E-Mails in
Sprache umwandeln. Auch die Realisierung von E-Mail-Anwendungen mit Sprachübergabe oder Fax
over IP wäre möglich.
Das ENUM-Verfahren bietet ferner die Möglichkeit, dass die VoIP-Nutzer unter einer einzigen
Nummer weltweit erreichbar sind.
Das Telefonieren über das Internet hat aber auch Nachteile. Die Konvergenz der Netze bietet keine
Ausweichmöglichkeit bei einem Ausfall – fällt das IP-Netz aus, kann man auch nicht mehr
telefonieren. Da die VoIP-Telefonate günstig sind, kann die Verbreitung von unangenehmem Spam,
wie bei E-Mails, nicht ausgeschlossen werden. Für die lästigen Spam-Anrufe wird der Begriff SPIT –
Spam over Internet Telephony verwendet [Nöll05]. Auch kann die Überlastung des Netzes zu Denial
of Service Angriffe (DOS) führen. Bei direkter Verbindung kann man die IP-Adresse des
Gesprächpartners erfahren und Angriffe dagegen fahren. Zugleich können die Nachrichten durch
Manipulation der IP-Adresse gefälscht (IP Spoofing) oder auch abgehört werden (Sniffing). Trotz
Grundlagen
12
allem arbeitet das klassischen Telefonnetz auch nicht einwandfrei und dort gibt es ebenso
Sicherheitsprobleme [Fink04].
Viele VoIP-Softwaresysteme sind als Standalone-Software für Endgeräte realisiert. Das ist der Grund,
warum sich die Kunden mit aufwändigen Updates beschäftigen und sogar dafür extra zahlen müssen.
Außerdem kann ein Update in Client- und Serverbereich hohe Administrationskosten verursachen
[HMM04]. Es gibt also immer noch Aspekte, die Verbesserungen erfordern. Das Framework Venice
der TU Kaiserslautern, auf dem diese Projektarbeit basiert, hat sich als Ziel die Lösung dieses und
anderer mit VoIP verbundener Probleme gesetzt. Dafür ist im Projekt eine neue serviceorientierte
VoIP-Architektur entwickelt worden, die auf der Technologie der Web Services basiert.
2.3 Web Services
Web Services sind lose gekoppelte, wiederverwendbare Software-Komponenten, die auf
verschiedenen Netzwerkrechnern laufen. Sie kapseln Funktionalität zu logischen Einheiten und sind
über standardisierte Internet Protokolle zugreifbar [T-LAN]. Das Ziel der Web Services-Technologie
ist Daten- und Funktionalitätsaustausch zwischen Kommunikationspartnern in automatisierbarer
Weise, d.h. eine Maschine-zu-Maschine-Kommunikation [HaLö04]. Web Services sind also nichts
völlig Neues. Dieses Konzept wird auch in CORBA (Common Object Request Broker Architecture),
DCOM (Distributed Common Object Model) und Java RMI (Remote Method Invocation) umgesetzt
[WüBu02]. Keine dieser objektorientierten Architekturen kann aber eine vollständige Unabhängigkeit
von Betriebsystem (DCOM), Programmiersprache (Java RMI) und Übertragungsprotokoll (CORBA)
anbieten. Um die Integration von Daten und Funktionalitäten aus unterschiedlichen Quellen zu
ermöglichen, muss die Kommunikation auf einheitlichen Standards basieren, die für alle Teilnehmer
verständlich sind. Alle in Zusammenhang mit Web Services verwendeten Standards sind XML-basiert
(XML – Extensible Markup Language), und die Daten werden in XML-Format übertragen. Dadurch
ist die Web Services-Technologie unabhängig sowohl vom Betriebsystem, als auch von der
Programmiersprache und dem Übertragungsprotokoll.
Die Standards, auf der die Web Services-Technologie basiert, sind SOAP (ehemals: Simple Object
Access Protocol), WSDL (Web Service Description Language) und UDDI (Universal Description,
Discovery and Integration). Abbildung 4 zeigt, wie diese Standards die Web Services-Architektur
bilden.
Grundlagen
13
Service-Entdeckung und Veröffentlichung
UDDI
Service-Beschreibung
WSDL
Mitteilungsaustausch
SOAP, XML-RPC
Übertragung
HTTP, SMTP, FTP etc.
Abbildung 4: Protokoll-Stack eines Web-Service
Die Service-Anbieter veröffentlichen ihre Dienste in einem öffentlichen Verzeichnis (UDDI), und die
Service-Anwender benutzen dieses Verzeichnis, um nach vorhandenen Diensten zu suchen. Damit der
Service-Anwender weiß, was der Service ihm bietet, müssen der Service und seine Methoden
beschrieben werden. Für diese Beschreibung wird WSDL eingesetzt. Damit die Nachrichten für alle
Beteiligten verständlich sind, werden sie in XML-Format kodiert. Danach können sie mit SOAP oder
XML Remote Procedure Call (XML-RPC) übermittelt werden. In der Praxis hat sich mittlerweile
SOAP durchgesetzt. Für die Übertragung der Nahrichten über das Internet können unterschiedliche
Transport-Protokolle eingesetzt werden, wie z.B. HTTP (Hyper Text Transfer Protocol), SMTP
(Simple Mail Transport Protocol) oder FTP (File Transfer Protocol). In der Praxis wird fast
ausschließlich das HTTP verwendet, weil es den Vorteil hat, dass der zugehörige Port in der Regel
geöffnet ist. Somit wird die Übertragung nicht von Firewalls verhindert.
Die Web Service-Architektur basiert, technisch gesehen, auf einer serviceorientierten Architektur
(SOA). Nach [ChJe02] ist SOA definiert als „eine Architektur, die eine verteilte, entdeckungsbasierte
Ausführungsumgebung nutzt, und eine Sammlung von serviceorientierten Softwarekomponenten nach
außen verfügbar macht und verwaltet“. Bei SOA kommunizieren drei Entitäten miteinander – der
Service-Anbieter (Service Provider), der Service-Anwender (Service Requestor) und das ServiceVerzeichnis (Service Registry) [WüBu02]. Diese Kommunikation ist dargestellt in Abbildung 5.
Grundlagen
14
Service
Provider
bind
publish
Service
Registry
Service
search
Requestor
Abbildung 5: Service-orientierte Architektur (SOA)
Ein Service-Anbieter publiziert (publish) seine Dienste im Service-Verzeichnis. Das wird bei der Web
Services-Technologie mittels UDDI erreicht. Im Service-Verzeichnis stehen nur die Dienst- und
Schnittstellenbeschreibung, die Implementierung des Dienstes ist transparent für die Benutzer. Das
erlaubt es dem Anbieter die Funktionen zu verändern oder auch neue einzufügen, solange diese
Bearbeitungen die Schnittstelle nicht beeinflussen. Ein Service-Anwender kann entweder eine
Software-Anwendung sein oder eine natürliche Person, die über ein Web-Interface auf den Service
zugreift [WüBu02]. Der Anwender sucht (search) Dienste im Service-Verzeichnis. Der Anwender
kann den Dienst entweder mit einer Suchmaske von UDDI oder mit dem URI (Uniform Resource
Identifier) des Dienstes anfragen. Wenn der Dienst gefunden wird, bekommt der Service-Anwender
die Schnittstellenbeschreibung des Dienstes als WSDL-Dokument. Der Service-Anwender kann dann
den Service-Anbieter kontaktieren (mithilfe der Schnittstelleninformation aus dem WSDL-Dokument)
und den Service in sein Programm integrieren und nutzen (bind).
Das Bindungsprozess (bind) kann in drei unterschiedlichen Arten geschehen. Der Client (ServiceAnwender) kann über Stubs, Dynamic Proxy oder Dynamic Invocation Interface an einen Web Service
gebunden werden. Diese verschiedenen Arten des Bindings werden nachfolgend erklärt [ABB+03]:
Ø Stubsgenerierung (Static Stub): Bei dieser Technik wird ein lokales Objekt (Stub) auf der
Client-Seite zur Kompilierungszeit generiert. Das Stub-Code wird automatisch aus der
WSDL-Datei erzeugt und repräsentiert den Web Service lokal. Ein Methodenaufruf wird
vereinfachend als ein lokaler Methodenaufruf ausgeführt. Der Stub führt dabei eine
Serialisierung durch, damit er den Methodenaufruf in das richtige Format für den entfernten
Dienst-Server umwandelt, und leitet dann den Aufruf weiter an den Server. Da der Stub vor
Ausführungszeit generiert wurde wird er als Static Stub bezeichnet. Der Vorteil dieser
Bindungsmethode ist ihre Einfachheit.
Grundlagen
15
Ø Dynamic Proxy: Diese Technik generiert die lokale Repräsentation des Web Services zur
Ausführungszeit. Das hat den Vorteil, dass der Service sich ändern kann, ohne das sich das
auf die Generierung des Kodes auswirkt.
Ø Dynamic Invocation Interface (DII): Mit der Dynamic Invocation-Technik kann ein Web
Service-Aufruf völlig zur Ausführungszeit durchgeführt werden – eine Codegenerierung
davor ist nicht nötig. Diese Methode ist die schwierigste von allen, aber sie ermöglicht eine
lose Kopplung der Komponenten.
Die Standards, auf denen Web Services basieren, werden in den folgenden Unterkapiteln ausführlicher
beschrieben.
2.3.1 Extensible Markup Language (XML) und XML Schema Definition (XSD)
XML steht im Mittelpunkt der Web Services-Technologie. XML wird als Datenformat für die
Nachrichten und als Basis für alle Web Services-Standards (SOAP, WSDL und UDDI) in der Web
Services-Technologie eingesetzt. XML ist eine Beschreibungssprache (Metasprache) zur einfachen
und strukturierten Darstellung von maschinen- und menschenlesbaren Daten. Sie ist ein offener und
kostenloser Standard. XML ist außerdem unabhängig von Betriebsystemen, Programmiersprachen und
Übertragungsprotokollen und ermöglicht damit die Portabilität von Web Services. Eine Anpassung der
Daten an spezifische Formate ist nicht nötig, und die Kommunikation geht über Systemgrenzen
hinweg.
Eine XML-Datei ist eine einfache Textdatei und folgt eine wohldefinierte Struktur, die aus Kopf- und
Körper-Teil besteht (Abbildung 6). Die XML-Version und die in benutzte Zeichenkodierung
(encoding) in der Datei werden im Dateikopf (Header) definiert. Der Körper (Body) enthält den Inhalt
des Dokuments. Alle Elemente werden dabei in Klammernotation „<...>“ definiert. Die Namen der
Elemente können (in einem gewissen Rahmen) frei gewählt werden. Normalerweise definiert der
Entwickler Namen, die das Element beschreiben. Mehrere Namen können in einem Namensraum
(Namespace) zusammengefasst werden. Dieser Namensraum kann dann in weitere XML-Dokumente
importiert werden. Jeder Namensraum wird mittels eines URI spezifiziert und am Anfang einer XMLDatei eingeführt. Er ist für gültig für alle Subelemente, und seine Elemente können im aktuellen
Dokument frei verwendet werden.
Grundlagen
16
Header
<? xml version=“1.0“ encoding=“UTF-8“ ?>
Body
<schema targetNamespace=“http://www.icsy.de/kabzeva/callcenter“
xmlns=http://www.w3.org/2001/XMLSchema“
xmlns: …=..... >
Namespaces
<element name=“…” type=”…” />
<simpleType name=”…”>
<choice>
<element name=“...“ type=“...“/>
<element name=“...“ type=“...“/>
</choice>
</simpleType>
<complexType name=“.....“>
<sequence>
<element name=“...“ type=“...“/>
<element name=“...“ type=“...“/>
</sequence>
</complexType>
</schema>
Abbildung 6: Beispiel für XML Schema
Die Struktur der XML-Dokumente kann entweder durch eine DTD (Document Type Definition) oder
durch XSD beschrieben werden. In DTD und XSD sind die Datentypen definiert, die in einer XMLDatei verwendet werden können. XSD ist der neuere Ansatz und hat viele Vorteile im direkten
Vergleich mit einer DTD. An erster Stelle nutzt XSD selbst eine XML-Syntax. DTD muss dagegen in
einer eigenen Sprache abgefasst werden. Außerdem bietet XSD eine größere Menge von
Basisdatentypen als DTD und erlaubt die Definition eigener einfachen („element“ und „simpleType“
in Abb. 6) und komplexen („complexType“ in Abb. 6) Datentypen. Zusätzlich ermöglicht XSD
Modularisierung durch die Unterstützung von Namensräumen, die vorteilhaft für große und verteilte
Systeme sind. Wenn sich mehrere Kommunikationspartner auf ein XSD einigen, können erstellte
Dokumente einfach zwischen den Partnern ausgetauscht und verarbeitet werden.
Grundlagen
17
2.3.2 SOAP
SOAP wird bei der Nachrichtenübermittlung in der Web Services-Technologie eingesetzt. Früher
stand das Akronym SOAP für „Simple Object Access Protocol“, inzwischen ist SOAP aber ein
eigenständiger Begriff geworden. SOAP ist ein XML-basiertes Protokoll zum Austausch von
strukturierten Daten zwischen Anwendungen in verteilten Umgebungen wie dem Internet. SOAP hat
also die Aufgabe die auszutauschenden Informationen zwischen dem Service-Anbieter und dem
Service-Anwender in ein XML-Format zu verpacken und sie über Transportprotokolle wie HTTP,
FTP oder SMTP zu übertragen [WüBu02]. In der Praxis wird meistens SOAP über HTTP verwendet.
SOAP kann auf zwei unterschiedliche Arten verwendet werden – für Remote Procedure Calls (RPC)
und für dokumentbasierten Nachrichtenaustausch [WüBu02]. Man kann sich RPC als Frage/AntwortMechanismus vorstellen [HaLö04] - eine SOAP-fähige Applikation ruft Methoden auf (Frage), die
sich als Web Service auf anderen Servern befinden. Für den Methodenaufruf werden per SOAP nur
der Methodenname und die benötigten Parameter zum Service-Anbieter übertragen. Nach der
Methodenausführung wird das Resultat (Antwort) wieder per SOAP zum Nutzer übertragen. Beim
dokumentenbasierten Nachrichtenaustausch wird die Information nur in eine Richtung vermittelt
[HaLö04]. Es werden keine Methoden aufgerufen, sondern nur strukturierte Nachrichten gesendet.
Die SOAP-Nachrichten haben eine exakt festgelegte Struktur (Abbildung 7). Jede SOAP-Nachricht
enthält einen SOAP-Umschlag (SOAP Envelope) und optional zusätzliche Anhänge (Attachments).
Der SOAP-Umschlag besteht seinerseits aus einem optionalen Kopf (SOAP Header) und einem
notwendigen Körper (SOAP Body). Hier werden auch die XML Namespaces definiert. Der SOAP
Header enthält anwendungsspezifische Informationen wie eine eindeutige Nachrichten-ID,
Authentifizierungs- und Autorisierungsangaben oder Routing-Daten. Der SOAP Body muss immer
nach dem SOAP Header stehen, falls dieser vorhanden ist. Der Body enthält die eigentliche Nachricht,
die gesendet werden soll, in XML-Form, d.h. einen RPC oder ein strukturiertes Dokument.
Damit man die Möglichkeit hat, auch Anwendungsdaten (wie z.B. Bilddateien oder Berichte im PDFFormat) zu übertragen, können einer SOAP-Nachricht ein oder mehrere Anhänge (Attachments)
hinzugefügt werden.
SOAP ist nicht auf eine Punkt-zu-Punkt-Kommunikation beschränkt [Knut02]. Eine SOAP-Nachricht
kann auf ihrem Weg zum Empfänger mehrere intermediäre SOAP-Kommunikationspartner passieren,
die die Header-Informationen interpretieren und auch ändern können. Dieser sogenannte „Message
Path“ [HaLö04] führt über solche Knoten. Ein SOAP-Knoten kann in drei Formen auftreten:
Ø als der ursprüngliche Sender (SOAP sender), der die Nachricht verschickt,
Ø als Zwischenknoten (SOAP intermediate), der die Nachricht weiterleitet,
Ø oder als endgültiger Empfänger, der die Nachricht verarbeitet.
Grundlagen
18
<? xml version=“1.0“ encoding=“UTF-8“ ?>
<soapenv: Envelope
SOAP Envelope
xmlns: soapenv= “http://schemas.xmlsoap.org/soap/envelope/“
xmlns : xsd= “http://www.w3.org/2001/XMLSchema“
<soapenv: Header>
...
</soapenv: Header>
<soapenv: Body>
...
</soapenv: Body>
SOAP Header
(optional)
SOAP Body
Video.mpg (MIME kodiert)
Attachments
SOAP Nachricht
Abbildung 7: Struktur einer SOAP-Nachricht
2.3.3 Hyper Text Transfer Protocol (HTTP)
HTTP ist ein Protokoll zur Übertragung von Daten über ein Netzwerk und wird hauptsächlich für das
Laden von Webseiten und andere Daten aus dem World Wide Web (WWW) in einem Webbrowser
verwendet [HTTP05]. In der Web Services-Technologie wird HTTP für die Übertragung der SOAP Nachrichten zwischen dem Client und dem Dienst eingesetzt.
2.3.4 Web Service Description Language (WSDL)
WSDL ist ein plattform-, programmiersprachen- und protokollunabhängiger Standard für die
Definition und die Beschreibung von Web Services. Ein WSDL-Beschreibungsdokument ist im XMLFormat verfasst. Die XML-Auszeichnungselemente enthalten Informationen über die Adresse des
Dienstes (die URL), über die Funktionen des Services und wie er vom Service-Anwender benutzt
werden kann, d.h. Schnittstelleninformation, und welche Transportprotokolle für das Binding
verwendet werden [CCM+01].
Grundlagen
19
Es gibt zwei Möglichkeiten für die Erstellung eines WSDL-Dokuments. Die erste ist, das WSDLDokument von Hand zu verfassen. Daraus wird anschließend automatisch der Stubs- und SkeletonCode generiert und danach wird die Funktionalität implementiert. Ein Stub ist Stück Programmcode,
der anstelle eines anderen Programmcodes steht. Dieser andere Code ist entweder noch nicht
geschrieben, oder er ist im anderen Speicherbereich oder sogar auf einem anderen Rechner vorhanden.
In verteilten Systemen gilt der letzte Fall – die Funktionalität eines über das Netzwerk erreichbaren
Dienstes wird auf einem anderen System als Stub-Komponente dargestellt. So hat man den Eindruck,
dass die Funktionalität lokal in diesem zweiten System vorhanden ist. Was tatsächlich geschieht ist
aber, dass die Stub-Komponente die Anfragen zu dieser Funktionalität in Netzwerkaufrufe übersetzt,
mit der fernen Komponente kommuniziert – dem dortigen Skeleton – und alles dort ausgeführt wird.
Diese Vorgehensweise wird auch Top-Down-Ansatz genannt. Die zweite Möglichkeit, oder der
sogenannte Bottom-Up-Ansatz, implementiert zuerst die gewünschten Funktionalitäten in einer
Programmiersprache und generiert danach durch den Einsatz von Werkzeugen die Stubs, die
Skeletons und die WSDL-Datei.
Abbildung 8 zeigt die wichtigsten Elemente einer WSDL-Datei nach [HaLö04] und [RuSi04].
Ø Jede WSDL-Datei beginnt, genau wie eine XML-Datei, mit einer Definition der XMLVersion und der Kodierung.
Ø Das Definitions-Element (<definitions>) ist das sogenannte Wurzelelement (Root-Element)
des WSDL-Dokuments. Es enthält den Namen des Web Services im name-Attribut, der
Namespace für den Service im targetNamespace-Attribut, die Namespaces für die
verwendeten Standards in den xmlns-Attribute, und alle nachkommenden Elemente des
WSDL-Dokuments.
Ø Die Wiederverwendbarkeit von Dateien wird in WSDL durch das <import>-Element
ermöglicht. Es stellt die Referenz zwischen zwei Dateien her. Mittels <import> werden
WSDL-Elemente importiert, die in einer anderen Datei definiert sind oder auch XMLSchemata. Es wird die Adresse der zu importierenden Datei angegeben, wobei diese Adresse
mit einem Namespace verbunden wird.
Ø Das Datentyp-Element (<types>) enthält Definitionen von Datentypen. WDSL benutzt die
Standardtypen von XML, aber durch <types> können zusätzliche, komplexere Datentypen
definiert werden. Wenn das Dokument nur XML-Standardtypen verwendet, dann fehlt das
Datentyp-Element.
Ø Die Nachrichten-Elemente (<message>) enthalten die Nachrichten für die Kommunikation
zwischen den Partnern (Client und Service). Für jede Nachricht wird ein einzelnes Element
verwendet. Jedes Element hat einen Namen und einen oder mehrere Teile (<part>), die die
Nachricht zusammenstellen. Jedes <part>-Element hat zwei Attribute – Name (name) und
Typ (type). Das type-Attribut kann als Wert XML-Standarddatentypen annehmen oder
Typen, die unter <types> definiert sind. Wenn die Nachricht von Client zum Service gerichtet
Grundlagen
20
ist, enthält <part> die Parameter des Funktionsaufrufes. Wenn die Nachricht vom Service
zum Client geschickt wird, entspricht <part> dem Rückgabewert des Funktionsaufrufes.
Ø Die Operationen, die vom Web Service unterstützt werden, sind in dem Porttyp-Element
(<portType>) enthalten. Für die Definition jeder Operation (<operation>) werden die
entsprechenden Nachrichtendefinitionen aus den <message>-Elementen benutzt. Die
Operationen können Sende- oder Empfangs-Operationen sein. Das Empfangen einer
Nachricht wird durch das <input>-Element dargestellt, das Senden durch das <output>Element. Falls ein Fehler während der Bearbeitung der Nachrichten auftreten kann, wird das
mithilfe eines <fault>-Elements innerhalb des <operation>-Elements bekannt gegeben.
Ø Das Bindungs-Element (<binding>) gibt genauere Informationen darüber, wie die
Nachrichten ausgetauscht werden, welches Protokoll für die Kommunikation benutzt wird und
wie die Nachrichten auf dieses Transport-Protokoll abgebildet werden. Das <type>-Attribut
des Elements wird hier zu einem <portType> referenziert.
Ø Im Service-Element (<service>) befinden sich die eigentlichen Adressen (URLs), über die die
Services erreicht und aufgerufen werden können, in <port>-Elementen. In jedem <port> wird
nur eine Service-Adresse spezifiziert. Wenn mehrere URLs für einen Dienst existieren,
müssen sie in mehreren <port>-Elementen definiert werden.
Jedes Element kann eindeutig über das Attribut name identifiziert werden.
Die Informationen in einem WSDL-Datei kann man in zwei Gruppen aufteilen – abstrakte und
konkrete Informationen. Die abstrakten Angaben definieren die Datentypen, die Nachrichten und die
Operationen, d.h. sie werden von den <types>, <message> und <portType>-Elementen präsentiert.
In den konkreten Angaben wird über die tatsächliche Bindung und die Netzwerkadresse informiert,
dazu werden also die Elemente <binding> und <service> gezählt [Paap03].
Grundlagen
21
<? xml version=“1.0“ encoding=“UTF-8“ ?>
<definitions name=”CallCenter”
targetNamespace=”http://www.icsy.de/kabzeva/callcenter”
xmlns=”http://schemas.xmlsoap.org/wsdl/”>
xmlns: soap=”http://schemas.xmlsoap.org/wsdl/soap”
<import namespace= ”http://www.icsy.de/kabzeva/callcenter”
location= ”http://www.icsy.de/services/example.wsdl” />
<types>
...
</types>
<message name=”Message_addShift>
<part name=“sso“ type=“sso:...“/>
<part name=”sh” type=”cc:Shift”/>
</message>
<message name=”Message_addShiftResponce>
<part name=”boolean” type=”boolean”/>
</message>
<portType name=”…..PortType”>
<operation name=“addShift“ parameterOrder=“sso sh“>
<input message=“tns:Message_addShift“/>
<output message=“tns:Message_addShiftResponse“/>
</operation>
</portType>
<binding name=“CallCenterBinding” type=“tns:...PortType“>
...
</binding>
<service name=”CallCenterService”>
<port name=”CallCenterPort” binding=”tns: CallCenterBinding”>
<soap: address location=”http://localhost:6080/axis/services/…”/>
</port>
</service>
</definitions>
Abbildung 8: Struktur einer WSDL-Datei
2.3.5 Universal Description, Discovery and Integration (UDDI)
UDDI ist der Standard für das Web Services-Verzeichnis (Service Registry in Abbildung 5). UDDI ist
ein plattformunabhängiges, offenes Framework, das die Möglichkeit bietet, Web Services zu
Grundlagen
22
beschreiben (Description), sie aufzufinden (Discovery) und verschiedene Dienste miteinander zu
verbinden (Integration). Service-Anbieter können Informationen über sich und ihre angebotenen
Dienste publizieren. Diese Informationen können in drei Arten unterteilt werden, die in White, Yellow
und Green Pages zur Verfügung gestellt werden (Abbildung 9).
<businessEntry>
White
Grundlegende Informationen
Pages
eines Unternehmens
1
n
<publisherAssertion>
Beziehung zwischen zwei Firmen
n
n
<businessService>
Yellow
Beschreibung der Dienste,
Pages
die ein Unternehmen anbietet
1
1
Green
<bindingTemplate>
Pages
Technische Beschreibung
<tModel>
1
n
und Zugriffspunkt - URI
Abstrakte Beschreibung einer
Spezifikation; eines Verhaltens
Abbildung 9: Datenstrukturen einer UDDI-Registrierungsstelle nach [Braa05]
Die Seiten-Sicht ist nur eine abstrakte Repräsentation der Informationen in UDDI. Dahinter stehen
fünf Datenstrukturen, mit deren Hilfe die Veröffentlichung und das Auffinden organisiert werden. Die
weißen Seiten (White Pages) beinhalten grundlegende Informationen über das Unternehmen – Name,
Adresse, Telefonnummern, Ansprechpartner und weitere Kontaktinformationen. Die Datenstruktur,
die dahinter steht, ist die <businessEntry>. Die gelben Seiten (Yellow Pages) beschreiben die Dienste
anhand verschiedener Klassifizierungsmerkmale (Kategorisierung) und helfen so, einen Dienst anhand
dieser
Zuordnung
zu
finden.
Die
entsprechende
Datenstruktur
mit
der
Bezeichnung
<businessService> speichert diese Daten. Die grünen Seiten (Green Pages) enthalten technische
Details zur Kommunikation mit dem registrierten Dienst. Hier befinden sich die Netzwerkadresse des
Dienstes und weitere Anbindungsinformationen. Diese Daten werden in der Datenstruktur
<bindingTemplate>
gespeichert.
Die
restlichen
zwei
Datenstrukturen
sind
die
<publisherAssertion>, die Informationen über die Beziehungen zwischen zwei Unternehmen liefert,
und das <tModel> - eine Erweiterung der <bindingTemplate>-Datenstruktur, welches abstrakte
Informationen über eine Spezifikation oder das Verhalten des Dienstes anbietet.
Grundlagen
23
Die großen öffentlichen UDDI-Verzeichnisse werden regelmäßig untereinander synchronisiert, um auf
dem gleichen Stand zu bleiben. Das bis Ende vom Jahr 2005 bedeutendeste UDDI-Register war das
Universal Business Register (UBR), das von leitenden Firmen wie IBM, Microsoft und SAP geführt
wurde [HaLö04]. Das Hauptziel vom UBR war der Beweis der Interoperabilität und der Stabilität der
UDDI-Spezifikationen. Dieses Ziel wurde erreicht und somit wurde das UBR am 12.01.2006
geschlossen. Obwohl IBM und Microsoft eigene Services schließen, wird SAP weiter ein eigenes
UDDI-Verzeichnis anbieten [Tomi06].
Eine aus Web Services aufgebaute Applikation ist also ein verteiltes Software-System, auf das über
standardisierte Protokolle zugegriffen werden kann. Es “befindet“ sich im Internet und bietet eine
XML-basierte Schnittstellenbeschreibung an. Der Einsatz von XML als Basis für die
Datenübertragung und die verwendeten Standards in der Web Services-Technologie (SOAP, WSDL
und UDDI) macht Web Services unabhängig von Systemplattformen, Betriebsystemen und
Netzwerkprotokollen. Das Kommunikationsprotokoll SOAP nutzt die Portabilität von XML und
ermöglicht eine plattformunabhängige Interaktion zwischen Service-Anwender und -Anbieter. Mit
WSDL werden die Dienste beschrieben – wo man sie finden kann, welche ihre Funktionen sind und
wie sie benutzt werden. Die Dienste werden in einem UDDI-Verzeichnis registriert, wodurch das
dynamische Finden und Aufrufen der Web Services ermöglicht wird.
2.4 Das Venice-Framework
Heutzutage existieren zwei Formen von VoIP Systemen – Clientprogramme (Standalone-Software),
die direkt in den Endgeräten installiert sind, und Web-Applikationen, bei denen der Webbrowser für
den Aufruf der aktuellen Programmversion verantwortlich ist. Ein Clientprogramm übernimmt sowohl
die Signalisierung (Signaling), als auch die Medienverarbeitung der Daten. Demzufolge ist die
Standalone-Software sehr komplex und umfangreich. Da das Programm fest in den Endgerät installiert
ist, muss man bei der Einführung neuer Funktionalitäten, eines neuen GUI (Graphical User Interface)
oder einer neuen Version des Kommunikationsprotokolls immer ein Update auf allen Clients
durchführen. Das verlangt viel Aufwand und verursacht hohe Kosten. Zudem ist ein Clientprogramm
hardwareabhängig. Im schlimmsten Fall muss der Entwickler sogar schon existierende Funktionen bei
der Integration in neue Endgeräte komplett neu implementieren. Die zweite Art von VoIP Systemen –
die Web-Applikation, ist nicht so umfangreich wie ein Clientprogramm und erfordert keine lokalen
Updates bei Veränderungen der Software, weil diese zentral auf einem oder mehreren Servern
betrieben wird. Trotzdem bleibt der Nachteil, dass die Integration in eigene Applikationen schwer ist.
Ein
weiteres
Problem
Signalisierungsfunktionen
der
sind
VoIP-Systeme
ist
unterschiedlich
die Inkompatibilität
bei
den
beiden
der
zurzeit
Protokolle.
Die
meistverwendeten
Kommunikationsprotokollen in VoIP Systemen, H.323 und SIP. Die Protokolle können nur durch
Grundlagen
24
Gateways miteinander kommunizieren, die zwischen diesen übersetzen. Diese Probleme stehen der
globalen Durchsetzung von VoIP noch im Weg [HiZh04].
Damit die Internet-Telefonie den Durchbruch schaffen kann, muss eine Architektur entwickelt
werden, die heterogene Clients unterstützt und alle oben beschriebenen Probleme löst. Eine solche
Architektur wurde von der Arbeitsgruppe Integrierte Kommunikationssysteme (ICSY) des
Fachbereichs Informatik an der Technischen Universität Kaiserslautern in Zusammenarbeit mit der
Siemens AG im Rahmen des Forschungsprojekts Venice, das dieser Projektarbeit zugrunde liegt,
vorgeschlagen.
Venice
bietet
ein
offenes
Web-Service-basiertes
VoIP-Framework.
Die
angesprochenen Problembereiche werden mithilfe der Web-Service-Technologie bearbeitet. Die
enthaltenen Software-Komponenten werden lose über das Internet gekoppelt und als Web Services
realisiert. Das sichert, dass der Ausfall eines Dienstes keinen kompletten System-Ausfall verursacht.
Der kompletten Signalisierungsprozess wird von einem Web-Service übernommen. Der Client wendet
sich, wenn er einen neuen Anruf tätigen will, an den Service und dieser baut die Verbindung auf. Da
die Signalisierung nicht mehr eine Aufgabe des Clients ist, wird die Größe des Clientprogramms
reduziert – es ist viel einfacher und leichtgewichtiger. Aufgrund dieser Einfachheit wird der Client in
Venice Simple Client genannt. Zudem sind Web-Service-Clients leicht zu entwickeln und können
einfach auf unterschiedliche Endgeräte umgesetzt werden. Die Software wird über das Internet
konfiguriert, und Updates werden automatisch nach Veränderungen durchgeführt. Venice-Clients
können außerdem verschiedene Protokolle (H.323 und SIP) verwenden. Das ermöglicht Gespräche mit
Anbietern anderer VoIP-Systeme, die eines dieser Protokolle verwenden. Mittels des VeniceFrameworks wird also die Kommunikation zwischen Clients mit verschiedenen Protokollen
ermöglicht – ein SIP-Client kann problemlos Gespräche mit H.323-Clients führen und umgekehrt. Die
Auslagerung der Signalisierung an den VoIP-Anbieter spart dazu auf Client-Seite die Konfiguration
und Administration von zusätzlichen Hardwarekomponenten, wie z.B. Gateways. Die nötige
Hardware wird durch die Service-Anbieter bereitgestellt und administriert. Die Einführung von neuen
Leistungsmerkmalen (supplementary services) ist mit dem Framework auch einfacher umzusetzen
[HMM04].
Grundlagen
25
2.4.1 Architektur des Venice-Frameworks
Die Web-Services in Venice können in drei Kategorien aufgeteilt werden: Management Services,
Basic VoIP Services und Supplementary Services (Abbildung 10).
Abbildung 10: Architektur des Venice-Frameworks [HGM05]
Die Verwaltungsdienste (Management Services) werden für die Verwaltung und Nutzung des VoIPSystems verwendet. Sie sind nicht mit den VoIP-Diensten gekoppelt und können so auch in anderen
Grundlagen
26
serviceorientierten Anwendungen eingesetzt werden. Fünf Management Services werden derzeit in der
Architektur angeboten [HGM05]:
Ø Role-based Single Sign-on (SSO): Dieser Dienst kontrolliert die Anmeldung am System.
Bevor ein Benutzer telefonieren (oder allgemein gesagt, Dienste nutzen) kann, muss er sich
zuerst mit Login und Passwort ausweisen. Danach erhält er eine Marke (TGT – Ticket
Granting Token), mit der er seine Identität nachweisen kann. Wenn er einen Dienst benutzen
will, werden mithilfe der TGT Marke seine Rechte überprüft und es wird entschieden, ob er
berechtigt ist, den Dienst bzw. einzelne Funktionen des Dienstes zu benutzen, d.h. ob er eine
Marke (ST - Service Token) für den jeweiligen Dienst bekommt. Diese neue Marke enthält
dann die Rechte des Nutzers für den jeweiligen Dienst. Dieses Verfahren hat den Vorteil, dass
der Benutzer sich nur einmal am System anmelden muss. Das ist sehr hilfreich in einem VoIPSystem, weil bei der Betätigung eines Telefonanrufs mehrere Dienste beteiligt sein können.
Eine ausführliche Beschreibung von SSO findet sich in [HGMM05].
Ø Metering, Accounting, and Billing (MAB): Die Verwendung der Web-Services-Technologie
in Venice ermöglicht die Wahl zwischen Diensten, die die gleiche Aufgabe erfüllen, aber
unterschiedliche Eigenschaften, wie z.B. QoS, haben. Diese Dienste können von
verschiedenen VoIP- Providern angeboten werden. Damit die Provider die Kostenabrechnung
für die benutzten Ressourcen durchführen können, verfügt Venice über einen Metering-,
Accounting- und Billing-Service, der alle verwendeten Dienste vermerkt.
Ø Software Deployment (SDS): Die leichte Benutzung der Software wird mithilfe dieses
Dienstes erreicht. Der Benutzer muss sich nicht um Installation oder Updates kümmern, der
Software Deployment Service erledigt das für ihm. SDS ist auch für die Anbieter nützlich,
weil er viel Administrationsaufwand bei der Nachinstallation von Diensten und bei der
Wartung des Systems abnimmt. Eine ausführliche Beschreibung vom SDS findet sich in
[HMMi04].
Ø Information Brokering (IB): Aufgrund der vielen Informationen über die verschiedenen
Dienste, wird im System ein Information Brokering Service eingesetzt, der für die Suche und
das Auffinden der gewünschten Informationen verwendet wird. Um die Skalierbarkeit mit der
wachsenden Zahl von Diensten und Anbietern zu gewährleisten, nutzt der IB Peer-to-PeerTechnologien.
Ø Feature Interaction Manager (FIM): Dieser Manager überprüft die Forderung nach einem
Leistungsmerkmal. Das Ziel von FIM ist dafür zu sorgen, dass keine Seiteneffekte aufgrund
der aufeinander folgenden Benutzung von mehreren Leistungsmerkmalen auftreten.
Die Basisdienste (Basic VoIP Services) bilden den Kern der Venice-Architektur. Sie bieten alle
Basisfunktionen, die für die Durchführung eines Telefongesprächs nötig sind. Die Basic VoIP
Services sind für die Verbindungsaufbau, die Durchführung und das Beenden des Gesprächs
zuständig. Diese Komponente kommuniziert direkt mit dem Simple Client, wobei die unterliegende
Grundlagen
27
Technologie transparent für den Client bleibt. Die Brücke (WSBridge) ist verantwortlich für das
Auffinden der VoIP-Benutzer in anderen Domänen und das Routing des Gesprächs. Für den Simple
Client bleibt die Interaktion mit dem Kommunikationspartner - und damit, ob er ein H.323- oder SIPClient ist - verborgen. Die Basic VoIP Services dienen als Vermittler zwischen dem Simple Client und
allen anderen VoIP-Web-Services.
Die Leistungsmerkmale (Supplemantary Services) sorgen für Komfort beim Telefonieren. Sie sind in
Venice ebenfalls als separate Web-Services implementiert. Die Dienste können von verschiedenen
VoIP-Providern angeboten werden. Der Benutzer kann frei die Dienste auswählen, die er benutzen
will. Einige der von Venice angebotenen Leistungsmerkmale sind Rufumleitung (Call Deflection),
Anrufweiterschaltung
(Call
Forwarding),
Dreierkonferenz
(Three-Party),
Anrufbeantworter
(Answering Machine / Voice Mail) usw. Im Rahmen dieser Projektarbeit wurde ein Callcenter-Dienst
als Leistungsmerkmal entwickelt, der für größere Unternehmen von Interesse sein kann.
2.4.2 Verarbeitung von Telefongesprächen
Alle Methoden, die für die Durchführung eines VoIP-Telefongesprächs nötig sind, werden vom
Basisdienst zur Verfügung gestellt. Zuerst werden die Berechtigungen des Benutzers überprüft, der
telefonieren will. Wenn er für die Benutzung des Basisdienstes berechtigt ist, stehen ihm die folgenden
Funktionen zur Verfügung [HiZh04] [HMM04]:
Ø initCall(): Bereitet der Gespräch vor und überprüft, ob es genug freie Ressourcen gibt. Im Fall
einer Überlastung der Festplatte, des Hauptspeichers oder des Netzwerks kann der Aufbau
eines Gesprächs abgelehnt werden.
Ø makeCall(): Leitet den Anruf zum Gesprächspartner ein.
Ø acceptCall(): Wird aufgerufen, wenn ein Anruf angenommen wird. Der Angerufene ist mit
dem Gesprächsaufbau einverstanden, und die RTP-Verbindung kann hergestellt werden; die
Nachrichtenübertragung wird anschließend gestartet.
Ø denyCall(): Der Aufruf dieser Methode lehnt einen Anruf ab und befreit alle belegten
Ressourcen auf dem Server. Der Anrufende wird über die Ablehnung informiert. Optional
kann auch der Grund dafür angegeben werden.
Ø getCallInformation(): Liefert alle für das Gespräch notwendigen Informationen – IP-Adresse,
Portnummer und Codec.
Ø endCall(): Beendet das bestehende Gespräch und befreit alle belegten Ressourcen auf dem
Server.
Ø setClientConfiguration(): Diese Funktion wird für die Konfiguration der Daten benutzt, die
für eine Verbindungsaufbau von Bedeutung sind (IP-Adresse, Portnummer, mögliche
Codecs). Der Client hat die Möglichkeit, für jedes Gespräch unterschiedliche Konfiguration
einzustellen, damit er z.B. zwei Gespräche parallel führen kann.
Grundlagen
28
Bei jedem Gesprächsaufbau wird vom Basisdienst automatisch ein CallHandler erzeugt. Er verwaltet
die aufgebaute Verbindung und weist der Verbindung eine eindeutige CallID zu, die zur
Identifizierung eines Telefonats verwendet wird. Nach Beenden des Gesprächs wird der CallHandler
vernichtet, und alle benutzten Server-Ressourcen werden gelöst.
2.4.3 Metering-, Accounting- und Billing
Der Metering-, Accounting- und Billing-Dienst in der Venice Architektur ist ereignisgesteuert. Der
Dienst sammelt Informationen über alle Ereignisse, die im System geschehen (metering) und ordnet
sie zu den entsprechenden Service-Provider (accounting), damit sie die Abrechnung der Kosten
(billing) durchführen können. Die Informationen werden in einem Datenbank-Management-System
gespeichert. Sie werden dann für ein Accounting abgefragt und danach für Billing weitergeleitet. Die
Vermerkungen der Ereignisse „call established“ (Verbindung aufgebaut) und „call ended“ (Gespräch
beendet) mit dem entsprechenden Zeitpunkt werden z.B. für die Berechnung der Gesprächslänge
benutzt. Der Service-Anbieter kann die Kosten pro Zeiteinheit eingeben und die Kosten für das
Telefonat können danach berechnet werden [HiZh04].
2.4.4 Leistungsmerkmale (Supplementary Services)
Die dargestellte Architektur bietet eine einfache Integration von Leistungsmerkmalen an. Die
Leistungsmerkmale teilen sich in drei Gruppen auf [HiZh04]:
Ø built in supplementary services, die in der Client-Software integriert sind (z.B. Call Hold),
Ø Supplementary Services, die eine Unterstützung des Basisdienstes brauchen (z.B. Call
Forwarding) und
Ø Supplementary Services, die selbstständig benutzt werden können (z.B. ein Adressbuch).
Die Leistungsmerkmale in den letzten zwei Gruppen können als externe (external supplementary
services) bezeichnet werden. Der Client kann die externen Leistungsmerkmale über den Information
Broker finden. Er bekommt dann die WSDL-Datei des Dienstes, die ihm Auskunft darüber gibt, wo
der entsprechende Dienst zu finden ist, wie er aufgerufen wird und wo er im Client-GUI zu integrieren
ist. Zuerst muss sich aber der Client auf Seite des VoIP-Anbieters für den Dienst registrieren. Wenn
der Client dann eine Operation des Leistungsmerkmals aufruft und dieses zur zweiten Gruppe gehört,
kontaktiert das Leistungsmerkmal den VoIP-Basisdienst, der dann die gewünschte Operation im
Auftrag vom Client ausführt (durch den Aufruf der supp_execute()-Funktion des Supplementary
Services). Ist der aufgerufene Service dagegen von der dritte Gruppe, wird er direkt vom Client mittels
invoke() kontaktiert. Abbildung 11 veranschaulicht die beschriebene Kommunikation.
Grundlagen
29
SSO
Legend: Access Level of
Functionality
role = user
VoIP Service
Client
role = voip
role = admin
supp_execute()
invoke()
Supplementary Service
Abbildung 11: Supplementary Services in Venice nach [HGM05]
Jeder Web-Service im Venice-Framework hat drei potenzielle Zugriffspunkte, über dies er aufgerufen
werden kann. Wenn der Client ein einfacher Benutzer ist (role = user), kann er nur auf den
öffentlichen Teil des Dienstes zugreifen. Das Interface dieses Teil muss daher stabil bleiben, weil es
von allen in Betrieb befindlichen VoIP-Clients benutzt wird. Der zweite Teil der Dienst-Funktionalität
ist nur für andere im System existierende Web-Services zugänglich (role = voip). Alle
Administrationsfunktionen sind im dritten Teil enthalten und nur für die Administratoren des VoIPAnbieters erreichbar (role = admin). Der Single Sign-on Service (SSO) regelt die Berechtigung des
Clients und gibt ihm Zugriffsrechte nur auf die Dienste, die für seine Rolle (role) erreichbar sind
[HGM04].
2.5 Zusammenfassung
Dieses Kapitel beschäftigte sich mit den theoretischen Grundlagen und Technologien, die für das
Verständnis dieser Projektarbeit von Bedeutung sind. Der erste Teil befasste sich mit dem Begriff der
Callcenter. Ein Callcenter ist eine eigenständige Organisationseinheit in der eingehende und/oder
ausgehende Telefonate auf die Agenten – die Angestellten im Callcenter – verteilt werden. Wenn der
Callcenter nur extern eingehende Telefongespräche annimmt, wird er Inbound-Callcenter genannt.
Initiieren die Agenten dagegen selber ausgehende Anrufe, spricht man von Outbound-Callcenter. Ein
Grundlagen
30
Callcenter kann unternehmensintern verwaltet werden, dann wird er als Inhouse-Callcenter bezeichnet,
oder unternehmensextern mittels Beauftragung von Callcenter-Dienstleistern.
Aufgrund des gestiegenen Einsatzes von IP-basierten Callcentern in den letzten Jahren wurde als
nächstes die VoIP-Technologie dargestellt. Sie bietet viele Vorteile im Vergleich zum klassischen
Telefonnetz. Die Übertragung der Signale ist hier paketbasiert über das Internet Protokoll. Es wird
keine Leitung für die Dauer des Telefonats exklusiv belegt, und man kann parallel auch andere
Anwendungen benutzen. Die VoIP-Telefonie ist nicht nur kostengünstiger als PTSN und ISDN. Sie
spart auch Verkabelungs- und Personenaufwand für ihren Aufbau. Das VoIP-Netz kann besser
ausgelastet
werden.
Außerdem
werden
schon
viele
Leistungsmerkmale,
wie
z.B.
Gesprächweiterleitung oder Anrufbeantworter, angeboten. Die VoIP-Systeme sind teilweise schon mit
der herkömmlichen Telefonie vergleichbar.
Trotzdem existieren noch einige Probleme, die gelöst werden müssen. Die momentan am Markt
angebotenen VoIP-Ansätze sind schwer zu bedienen. Der Benutzer muss immer neue Updates
installieren, wenn das System neue Funktionalitäten anbietet. Die Kommunikation zwischen
Benutzern, die unterschiedliche Protokolle verwenden, ist nur schwer möglich, oft muss dafür
zusätzliche Hardware eingebaut werden. Die existierenden VoIP-Lösungen haben einige Nachteile
auch für die Service-Anbieter. Sie müssen meistens den Code verändern, wenn die Software an neue
Endgeräte angepasst werden muss, und die Einstellung von neuen Leistungsmerkmalen ist dabei auch
schwer. Eine Lösungsmöglichkeit für diese Probleme bietet die Web-Services-Technologie. Sie wurde
im dritten Teil des Kapitels betrachtet. Web-Services sind verteilte Softwaresysteme zur Maschine-zuMaschine-Kommunikation über das Internet. Der Aufbau eines Web-Services basiert auf der
serviceorientierten Architektur (SOA) und bietet eine lose Kopplung über das Netz. Alle in der WebServices-Technologie eingesetzte Standards (WSDDL, SOAP und UDDI) basieren auf der
Beschreibungssprache XML. Der Datenaustausch kann deswegen unabhängig von Plattform,
Programmiersprache und Betriebssystem durchgeführt werden. Die Datentypen werden dabei mittels
XSD definiert. Die strukturierten Daten werden mit SOAP übermittelt. Die Schnittstellen der Dienste
sind in XML-Format anhand WSDL beschrieben. Die Service-Anbieter publizieren ihre angebotenen
Dienste im UDDI-Verzeichnis und der Service-Nutzer kann über UDDI nach Web-Services suchen.
Der Service-Verzeichnis (UDDI) agiert also als Vermittler zwischen Anbieter und Nutzer. Nach dem
Auffinden eines gesuchten Dienstes kann der Nutzer anhand der Schnittstellenbeschreibung im
WSDL-Dokument mit dem Anbieter in Verbindung treten und den gewünschten Dienst benutzen.
Im letzten Unterkapitel wurde das Projekt Venice vorgestellt, in dessen Rahmen ein solches WebService-basiertes VoIP-Framework implementiert wurde. Es wurde eine neue Architektur entwickelt,
die die Interoperlabilität zwischen verschiedenen VoIP-Providern ermöglicht, ohne zusätzliche
Integration von Hardware. So können neue Leistungsmerkmale einfach und schnell im System
integriert werden. Die Client-Software ist einfach zu benutzen und kann in verschiedenen Endgeräten
Grundlagen
31
eingesetzt werden. Der Client muss außerdem keine Updates mehr durchführen, weil das dann
automatisch für ihn erledigt wird.
Entwurf und Implementierung eines Callcenters
32
Kapitel 3: Entwurf und Implementierung
eines Callcenters
Die Aufgabe dieser Projektarbeit besteht darin, das vorgestellte Venice-Framework mit einem
Callcenter-Leistungsmerkmal zu ergänzen. Dafür wird zunächst die Struktur des zu realisierenden
Inbound-Callcenters festgelegt. Es muss auch entschieden werden welche Funktionen dem
Administrator und den Mitarbeitern (Agenten) des Callcenters zur Verfügung stehen. Demzufolge
wird im letzten Unterkapitel das Funktionsprinzip erklärt.
3.1 Software-Pakete und Werkzeuge
Bevor die Struktur und die Funktionalitäten des Callcenters erläutert werden, werden die für die
Durchführung der Arbeit eingesetzte Datenbank und die verwenderen Softwarepakete kurz vorgestellt.
Für
die
Datenhaltung
wird
eine
PostgreSQL-Datenbank
genutzt.
PostgreSQL
ist
ein
objektrelationales Datenbank-Management-System (ORDBMS). Es ist besonders leistungsfähig,
unterstützt fast alle Standards der Definitions- und Abfragesprache für Datenbanken SQL (Structured
Query Language) und ist außerdem ein Open-Source-Produkt mit kostenloser Nutzung.
Wie das Venice-Framework basiert auch der im Rahmen dieser Projektarbeit entwickelte Callcenter Dienst auf Java (Version 1.5.0) [SunJ05]. Für die Realisierung der grafischen Komponenten wurden
Java Swing und eine Erweiterung der Swing-API – die Java GUI Programming Extensions (JavaGPE) [Hi-JGPE] – eingesetzt.
Für die Generierung der Java-Klassen für Server und Client aus der WSDL-Datei des Dienstes wurde
das Werkzeug WSDL2Java von Axis (Apache Extensible Interaction System) verwendet.
Zusätzlich zu den Standardbibliotheken von Java wurden Teile eine Erweiterung für die Web-ServiceEntwicklung verwendet – das Java Web Services Developer Pack (JWSDP). Dieses wird auch von
Sun angeboten [SunWS05]. Das JWSDP enthält das JAX-RPC-Package (Java API for XML based
Remote Procedure Calls), welches von Axis verwendet wird, um die Bindung eines Clients an den
Web-Service durchzuführen. Zur Realisierung des Callcenter-Dienstes wurde das Dynamic Invocation
Interface zum Aufrufen der entfernten Funktionen verwendet (siehe Kapitel 2.3).
Als Server wird Tomcat (Version 5.5) der Apache Foundation eingesetzt. In diesem Servlet-Container
befindet sich der Service und ist von dort aus entsprechend ausführbar.
Entwurf und Implementierung eines Callcenters
33
3.2 Callcenter-Datenbankstruktur
Das entwickelte Callcenter ist ein Inbound-Callcenter, das bedeutet nach der Definition in Kapitel
2.1.1, dass es ausschließlich eingehende Anrufe bedient. Wenn das Callcenter unter seiner
Telefonnummer angerufen wird, muss jedes Gespräch zu einem freien Agenten umgeleitet werden.
Für die Realisierung dieser Gesprächsumleitung werden drei Tabellen in einer PostgreSQL-Datenbank
angelegt (Abbildung 12).
Status
tel
WorkTime
status
shift
tel
end_time
FOREIGN_KEY
Shift
FOREIGN_KEY
start_time
day
shift
Abbildung 12: Datenbankschema des Callcenter Services
Die Tabelle mit dem Namen Status speichert die Nummern aller Agenten (tel) und ihren aktuellen
Status (status). Die Telefonnummern haben die folgende vom Venice-Framework vorgeschriebene
Form: „user@domäne“ (z.B. [email protected]). Jede Telefonnummer darf nur einmal in der Tabelle
vorkommen. Das Status-Feld jedes Eintrags kann nur einen der folgenden zwei Werte enthalten –
„available“, wenn der Agent an seinem Arbeitsplatz ist und „not available“ sonst.
In der WorkTime-Tabelle sind die möglichen Arbeitszeiten der Agenten eingegeben. Im Feld shift
werden die Schichtennummer aufbewahrt. Die Anfangs- und Endzeit der Schicht werden entsprechend
in start_time und end_time eingetragen. Die Schichtnummern sind eindeutig und die Eingabe
von Schichten mit der gleichen Start- (start_time) und Endzeit (end_time) ist nicht möglich.
Der Schicht-Plan der Agenten wird in der Shift-Tabelle eingetragen. Jeder Eintrag besteht aus der
Telefonnummer des Agenten, dem Datum (Werktag) und der Schichtnummer. Die Angaben in der
Telefonnummer-Spalte (tel) müssen in der Telefonnummer-Spalte der Status-Tabelle auch
vorhanden sein. Ein Arbeitstag in der Tag-Spalte (day) kann in zwei Formen eingegeben werden.
Erstens kann man das genaue Datum als Arbeitstag einfügen (z.B. 2005.12.03). Die zweite
Möglichkeit ist, die ersten drei Buchstaben des englischen Namens eines Wochentags einzutragen
(d.h. Mon, Tue, Wed, Thu, Fri, Sat und Sun für Montag bis Sonntag entsprechend). Diese gewählte
Konstruktion erleichtert die Arbeit des Callcenter-Administrators. Wenn ein Agent jeden Freitag z.B.
in der gleichen Schicht arbeitet, braucht der Administrator nicht immer das aktuelle Datum an jedem
Freitag einzutragen, sonst kann er einfach in der day-Spalte Fri eingeben. Sollte es danach eine
Veränderung der Schicht an einem Freitag geben, muss er nur einen neuen Eintrag für diesen
Entwurf und Implementierung eines Callcenters
34
bestimmten Freitag in der Datenbank hinzufügen, indem er das entsprechende Datum als day angibt.
Die Schichtennummern (shift) müssen aber auch mit den Nummern aus der shift-Spalte der
WorkTime-Tabelle übereinstimmen. In der Shift-Tabelle können natürlich mehrere Einträge für ein
und den selben Agent existieren. Die einzige Restriktion dabei ist nur, dass jedem Agenten an einem
Tag nur eine Schicht zugeteilt werden darf, d.h. die Tupel ([email protected], Fri, 1) und
([email protected], Fri, 2) können nicht beide in der Tabelle gleichzeitig vorhanden sein, sondern nur
eine davon1.
3.3 Callcenter-XML-Schema
Der nächste logische Schritt nach dem Erstellen des Datenbank-Schemas ist das Verfassen der XMLSchema mit allen Datentyp-Definitionen für eine einheitliche Syntax. Für jede Tabelle in der erstellten
Datenbank lässt sich ein entsprechender (komplexer) Datentyp definieren. Der komplexe Datentyp
„Status“ (Abbildung 13) enthält die Elemente „telephoneNumber“ und „availabilityStatus“ als
Sequenz. „telephoneNumber“ ist selbst eine herkömmlicher „string“ als Typ. „availabilityStatus“
hat einen definierten einfachen Typ namens „StatusType“ (Abbildung 13), der entweder den Wert
„A“ (für „available“) oder „N“ (für „not available“) annehmen kann.
<complexType name=“Status“>
<sequence>
<element name=”telephoneNumber” type=”string” />
<element name=”availabilityStatus” type=”tns:StatusType” />
</sequence>
</complexType>
<simpleType name=”StatusType”>
<restriction base=”string”>
<enumeration value=”A” />
<enumeration value=”N” />
</restriction>
</simpleType>
Abbildung 13: Auszug des XML-Schemas des Callcenter-Dienstes
1
Dies ist nur auf den ersten Blick eine Einschränkung durch die Datenbankstruktur. Prinzipiell ist es natürlich
möglich, dass ein Callcenter-Mitarbeiter mehrere Telefonnummern besitzt und so auch mehrere reale Schichten
durchführen kann.
Entwurf und Implementierung eines Callcenters
35
Für die WorkTime-Tabelle lässt sich der komplexe Datentyp „WorkTime“ definieren. Seine
Sequenz-Elemente sind „shiftNumber“ vom elementaren XML-Typ „int“, „shiftStart“ und
„shiftEnd“ – beide vom XML-Basistyp „time“.
Der komplexe Datentyp „Shift“ bestimmt entsprechend die Einträge in der Shift-Tabelle. Die
Elemente, die ihn aufbauen sind „telephoneNumber“ vom XML-Typ „string“, „day“ vom definierten
einfachen Datentyp „DayDate“ und „shiftNumber“ vom XML-Typ „int“. Der „DayDate“-Typ kann,
wie der Name schon sagt, einen Tag („day“) vom Typ „DayOfWeek“ oder ein Datum („date“) vom
XML-Typ „date“ sein. „DayOfWeek“ definiert genau wie StatusType (Abbildung 13) eine
Aufzählung, die die oben erwähnten Werte „Mon“, „Tue“, „Wed“, „ Thu“, „Fri“, „Sat“ und „Sun“
enthält.
Das Callcenter-XML-Schema wird in der WSDL-Datei des Dienstes importiert, und WSDL2Java
generiert automatisch für jeden der definierten Datentypen die entsprechende Java-Klasse, die
denselben Namen wie der Datentyp trägt. Diese Klassen werden in einem Paket gespeichert, das aus
dem Namensraum der Datentypen abgeleitet wird. Jede Klasse besitzt eine get()- und set()-Methode
für jedes Element, um seinen Wert entsprechend zu setzen oder zu bekommen.
3.4 Callcenter-Schnittstellen
Der Callcenter-Web-Service soll für die Kommunikation nach außen, mit dem CallcenterAdministrator und den Agenten entsprechende Schnittstellen bieten. Werden zunächst die
gewünschten Schnittstellen-Operationen in WSDL erstellt, lassen sich nach dem Top-Down-Ansatz
(siehe Kapitel 2.3.3) automatisch die Stubs und Skeletons mit WSDL2Java erzeugen. Auf Serverseite
lassen sich anschließend die Java-Klassen für die Erstellung der nötigen Datenbankeinträge und SQLAbfragen sowie die Callcenter-Logik implementieren.
Auf Nutzerseite erfolgt die Kommunikation über zwei grafische Schnittstellen – eine für den
Administrator und eine für die Agenten. Das Administrationsinterface ist eigenständig. Das GUI für
die Agenten ist dagegen im Simple Client eingebettet und erlaubt so die Benutzung anderer Dienste,
die der Client bietet und für die der Agent berechtigt ist, wie z.B. der Basisdienst Telefonieren.
Die Operationen, die dem Administrator und den Agenten zur Verfügung stehen, werden im
Folgenden präsentiert. Dabei wird zunächst die WSDL-Schnittstelle des Dienstes beschrieben und
gleichzeitig die dazugehörige grafische Benutzerschnittstelle als direkte Umsetzung.
3.4.1 Administrationsschnittstelle
Das grafische Interface für den Callcenter-Administrator besteht aus drei Unterbereichen, die er
verwalten kann – jeweils einen für jede Tabelle aus der Datendank. Die Daten in diesen drei Bereichen
können nur vom Administrator geändert werden.
Entwurf und Implementierung eines Callcenters
36
WorkTime Management
Im Work Time Panel (Abbildung 14) werden alle Arbeitszeiten aufgelistet mittels Aufruf der
getWorkTime() Methode, die alle Daten aus der WorkTime-Tabelle holt. Die möglichen Operationen
mit diesen Daten sind die folgenden:
Ø editWorkTime(): Durch den Aufruf dieser Funktion kann der Administrator die Start- und/oder
Endzeit einer ausgewählten Schicht ändern. Eine Änderung ist nur dann erlaubt, wenn keine
andere Schicht mit denselben Start- und Endzeiten existiert. Nach erfolgreicher Änderung
wird die Liste automatisch aktualisiert und die geänderten Zeiten sind auch zu sehen.
Ø addWorkTime(): Diese Funktion wird aufgerufen, wenn der Administrator eine neue
Arbeitszeit in der Datenbank eintragen will. Bevor der Eintrag in der Datenbank gespeichert
wird, wird überprüft, ob die eingegebene Schichtnummer schon vorhanden ist und ob die
gewünschten Start- und Endzeiten mit diesen von einer schon existierenden Schicht
übereinstimmen. Tritt eins dieser Fälle auf, wird der Eintrag fehlschlagen und nicht in der
Datenbank gespeichert. Bei einer erfolgreichen Speicherung wird die Liste automatisch
aktualisiert – sie zeigt danach die neu eingetragene Schicht an.
Ø deleteWorkTime(): Wenn der Administrator eine von ihm ausgewählte Schicht löschen will,
muss diese Methode aufgerufen werden. Nach dem Löschvorgang wird die Liste automatisch
aktualisiert und das gelöschte Objekt ist in der neuen Anzeige nicht mehr zu sehen. Das
Löschen einer Schicht aus der WorkTime-Tabelle führt, dem Datenbank-Schema
entsprechend,
zum Entfernen aller Einträge in der Shift-Tabelle, die die Nummer der
gelöschten Schicht enthalten.
Abbildung 14:Work Time Panel
Entwurf und Implementierung eines Callcenters
37
Die automatische Aktualisierung der Liste mit den Arbeitszeiten nach jeder Änderungsaktion
ermöglicht dem Administrator gleich einen Überblick über den neuen Zustand der Einträge.
Status Management
Der Agents’ Status Panel (Abbildung 15) zeigt die entsprechende Telefonnummer und den Status
aller im Callcenter arbeitenden Agenten. Für diese Anzeige wird die Funktion getStatus() ausgeführt,
die alle Einträge aus der Status-Tabelle der Datenbank holt. Für die Manipulation dieser Daten stehen
die folgenden Methoden zur Verfügung:
Ø editStatus(): Anhand dieser Funktion kann der Status eines ausgewählten Agents geändert
werden. Nach dem Editieren wird die Liste mit den Nummern und dem entsprechenden Status
automatisch erneut geladen und die aktuelle Information wird angezeigt.
Ø addStatus(): Wenn der Administrator einen neuen Agenten in den Callcenter eintragen will,
ruft er diese Methode auf. Die Information dieses Agenten wird nur dann in der Datenbank
gespeichert, wenn die eingegebene Telefonnummer eindeutig ist. Nach erfolgreicher
Speicherung wird die neue Liste der Agenten automatisch angezeigt.
Ø deleteStatus(): Diese Funktion wird ausgeführt, wenn einen Eintrag gelöscht werden soll. In
der gleich danach aktualisierten Liste ist der gelöschte Eintrag nicht mehr zu sehen. Nach dem
Datenbank-Schema führt das Löschen eines Agents zum Entfernen allen seinen Schichten aus
der Shift-Tabelle.
Abbildung 15: Status Panel
Entwurf und Implementierung eines Callcenters
38
Der Administrator hat hier auch die Möglichkeit, die Liste manuell erneut zu laden, damit er sehen
kann, wenn einer der Agenten seinen Status geändert hat. Dafür wird erneut die getStatus()-Methode
aufgerufen.
Shift Management
Für die Anzeige der Arbeitschichten der Agenten ist das Shift Panel (Abbildung 16) verantwortlich.
Die Funktion, die diese Daten auflistet ist getShift(). Sie liefert alle Einträge aus der Shift-Tabelle.
Eine Bearbeitung der Daten ist mit den folgenden Methoden möglich:
Ø editShift(): Durch den Aufruf dieser Funktion kann der Administrator die Schichtnummer
eines ausgewählten Agenten ändern. Dabei kann die Nummer nur auf einen schon in der
Datenbank existierenden Wert gesetzt werden. Diese Veränderung ist gleich nach
erfolgreicher Ausführung der Operation in der Liste zu sehen.
Ø addShift(): Für die neue Zuteilung von Schichten an den Agenten wird diese Methode
aufgerufen. Der Administrator kann den Agenten, für den er eine Arbeitschicht einfügen will,
aus einem Register der im Callcenter eingetragenen Telefonnummern wählen. Dann gibt er
den Tag als Datum oder die ersten drei Buchstaben des Wochentags ein. Die dazugehörige
Schichtnummer kann er auch aus der Aufzählung aller in der WorkTime-Tabelle enthaltenen
Nummern entnehmen. Vor der Speicherung der Daten in der Datenbank wird natürlich
überprüft, ob am angegebenen Tag dem ausgewählten Agenten keine andere Schichtnummer
schon zugeteilt wurde. Nach einer erfolgreichen Eintragung der neuen Arbeitschicht wird sie
in der Liste aufgenommen.
Abbildung 16: Shift Panel
Entwurf und Implementierung eines Callcenters
39
Ø deleteSingleShift(): Diese Methode wird für das Löschen einer ausgewählten Arbeitschicht
verwendet. In der automatisch neu geladenen Liste existiert der gelöschte Eintrag nicht mehr.
Weil das Löschen eines Agenten oder einer Schicht aus der Datenbank, wie schon oben beschrieben,
zu einen Löschvorgang auch in der Shift-Tabelle führt, hat der Administrator auch in diesem Panel die
Möglichkeit, die Arbeitschichten-Liste manuell neu zu laden, damit er den aktuellen Zustand dieser
Liste sehen kann. Dafür steht der Reload-Knopf zur Verfügung.
3.4.2 Agentenschnittstelle
Jeder Agent des Callcenters kann mittels einem sogenannten Agent Panel (Abbildung 17) mit dem
Web-Service kommunizieren. Dieser Panel ist im Venice Simple Client integriert. Er bietet dem Agent
Möglichkeiten, seinen Verfügbarkeitsstatus zu ändern, seine Arbeitschichten zu sehen und mit anderen
Agenten zu telefonieren. Die dafür angebotenen Funktionen sind:
Ø getWorkPlan(): Diese Methode liefert den Arbeitsplan des Agenten. Sie bekommt als
Parameter die Telefonnummer des Agenten und benutzt sie, um so von der Shift-Tabelle nur
diese Einträge zu wählen, die diese Nummer enthalten.
Ø getOwnStatus(): Wenn der Agent den AgentPanel öffnet, sieht er links oben eine CheckBox,
die seinen Verfügbarkeitsstatus anzeigt. Abhängig von seinem Status in der Datenbank ist
dieses Kästchen markiert, wenn in der Status-Tabelle der Wert „A“ für „available“ steht und
nicht markiert, wenn dort der Wert „N“ für „not available“ eingetragen ist. Die
getOwnStatus()-Funktion wird für die richtige Markierung dieser CheckBox aufgerufen.
Ø setStatus(): Seinen Status kann der Agent durch Aufruf der setStatus()-Funktion ändern. Eine
Änderung ist aber nicht immer erlaubt. Das Umschalten des Status von „not available“ auf
„available“ ist immer möglich. Wenn der Agent aber umgekehrt seinen Verfügbarkeitsstatus
von „available“ auf „not available“ setzen will, wird zuerst überprüft, ob seine Schicht zu
Ende ist. Wenn das der Fall ist, darf er die gewünschte Status-Änderung durchführen. Ist die
Schicht dagegen noch nicht abgelaufen, wird es überprüft ob es mindestens einen anderen
Agent gibt, der dieselbe Schichtnummer an diesem Tag besitzt und „available“ ist. Wenn
kein solcher Agent existiert, bedeutet dies, dass er an seinem Arbeitsplatz bleiben soll, damit
das Callcenter noch besetzt ist. Deswegen darf er auch seinen Status nicht auf „not available“
setzen.
Ø getStatus(): Der Agent sieht neben der Liste mit seinen Arbeitsschichten auch eine Liste mit
allen Agenten des Callcenters. Aus dieser Liste kann er einen seiner Kollegen auswählen und
mit ihm telefonieren. Damit er auch weißt ob dieser Kollege momentan an seinem
Arbeitsplatz ist wird auch der Status angezeigt. Diese Liste wird mithilfe der getStatus()Funktion angezeigt.
Entwurf und Implementierung eines Callcenters
40
Wenn der Agent einen Eintrag aus der Kollegen-Liste auswählt, muss er den Call-Button in der
unteren rechten Ecke drücken, um ihn anzurufen. Es kann passieren, dass der Kollege mit dem er
sprächen will im Moment nicht verfügbar ist (d.h. seinen Status ist auf „N“ gesetzt). Aus diesem
Grund hat der Agent die Möglichkeit, die Liste mittels eines Reload-Buttons erneut zu laden. So kann
er feststellen, wenn der gewünschte Gesprächspartner an seinen Arbeitsplatz zurückkommt (d.h.
seinen Status auf „A“ gesetzt hat).
Abbildung 17: Agent Panel
In diesem Unterkapitel wurde beschrieben, wie die Agenten (die Mitarbeiter des Callcenters) und der
Callcenter-Administrator mit dem Callcenter-Web-Service interagieren. Im folgenden Unterkapitel
wird erläutert, wie die Kommunikation zwischen einem Client, der das Callcenter anrufen will, und
dem Service abläuft.
3.5 Callcenter-Funktionsprinzip
Das Callcenter ist ein Leistungsmerkmal von Venice und gehört zur Gruppe der Dienste, die eine
Unterstützung durch den VoIP-Web-Service brauchen (siehe Kapitel 2.4.4). Aus diesem Grund wird
die Kommunikation zwischen einem Client, der das Callcenter anruft, und dem Callcenter indirekt
über den VoIP-Basisdienst durchgeführt (Abbildung 18).
Entwurf und Implementierung eines Callcenters
41
SSO
Agent 1
makeCall
Client
Agent 2
VoIP Service
Call denied
incoming
Call
.
.
.
Legend: Access Level
of Functionality
role = user
role = voip
Agent 3
denyCall()
supp_execute()
forwardCall()
Agent n
Callcenter Service
role = admin
Admin
Abbildung 18: Callcenter Supplementary Service
Der Client wählt die Nummer des Callcenters („makeCall“). Weil er ein einfacher Benutzer ist,
kommuniziert er mit dem öffentlichen Teil des VoIP-Dienstes. Der VoIP-Service ruft nach der
Analyse der Telefonnummer die supp_execute()-Funktion des Callcenter-Services auf. Der CallcenterService regelt dann, zu welchem Agent der Anruf weitergeleitet werden soll. Wenn kein Agent
gefunden werden kann, teilet der Callcenter dem VoIP-Service mit, dass das Gespräch abgelehnt wird
und gibt die Ursache für die Ablehnung („denyCall()“) an. Der VoIP-Service übergibt dann dem
Client die Information weiter („Call denied“). Wird dagegen vom Callcenter ein Agent ausgewählt,
wird das dem VoIP-Service mitgeteilt („forwardCall()“) und er leitet das Gespräch intern („role =
voip“) zu diesem Agenten weiter. Der Agent wird dann über das ankommende Telefonat
benachrichtigt („incoming Call“). Wenn der Callcenter eine Warteschlange und/oder einen
Anrufbeantworter als weitere Leistungsmerkmale besitzt, können sie auch als Agenten betrachtet
werden. Was genau nach dem Aufruf der supp_execute()-Methode des Callcenter Services passiert,
zeigt das in Abbildung 19 dargestellte Flussdiagramm.
Die Ausführung von supp_execute() beginnt mit Bestimmung des Zeitpunkts des Anrufs (Get call
time). Anhand dieser Zeit werden aus der WorkTime-Tabelle der Callcenter-Datenbank die
Nummern der Schichten ausgewählt, die zur Anrufszeit aktiv sind (Find active shifts). Bei der
Auswahl wird die aufgenommene Zeit mit den Start- und Endzeitwerten aller Schichten verglichen.
Wenn die Anrufzeit zwischen diesen beiden Werten einer Schicht liegt, wird ihre Nummer ausgewählt
Entwurf und Implementierung eines Callcenters
42
und in einem Vektor gespeichert. Nach dem Durchlauf aller Schichten aus der Tabelle wird die Länge
des Vektors überprüft (aktive shifts). Falls der Vektor leer ist, bedeutet dies, dass das Callcenter
momentan geschlossen ist. Folglich wird abgefragt, ob das Callcenter einen Anrufbeantworter zur
Verfügung stellt (answering machine). Wenn die Antwort negativ ist, wird das Telefonat abgelehnt
(Deny call). Der Anrufer wird informiert, dass das Callcenter geschlossen ist. Bei einer positiven
Antwort wird das Gespräch zum Anrufbeantworter weitergeleitet (Forward call to am). Der Client
kann eine Nachricht hinterlassen.
Enthält der Schichten-Vektor mindestens eine Schichtnummer, werden aus der Shift-Tabelle der
Datenbank alle Agenten ausgesucht, die am aktuellen Tag eine der im Vektor stehende Schichten
haben (Find working agents). In der Shift-Tabelle können, wie schon bekannt ist, mehrere Einträge
für einen Agent existieren. Einige dieser Einträge können als Tag ein exaktes Datum enthalten, andere
nur den Namen eines Wochentags. Damit nur die richtigen Einträge berücksichtigt werden, wird die
Suche wie folgt gestaltet. Zuerst werden die Einträge ausgewählt, die das aktuelle Datum und eine der
Schichtnummern aus dem Schichten-Vektor beinhalten. Danach wird der aktuelle Wochentagsname
bestimmt und die Einträge ausgesucht, wo diese Namen und eine der Schichtennummern aus dem
Schichten-Vektor auftaucht. Für einen Agenten können Einträge von den beiden Arten existieren. Z.B.
kann ein Agent Montags üblicherweise Schicht 2 haben, aber für den aktuellen Tag, der auch einen
Montag sein kann, wurde für ihn Schicht 3 eingetragen. Diese Schichten können sich so zeitlich
überlappen. Wenn der Anruf in einem Zeitpunkt kommt, in dem beide Schichten aktiv sind, werden
beide Nummern in den Schichten-Vektor aufgenommen. Beim ersten Durchsuchen der Tabelle wird
dann den zweiten Eintrag (der Schichtnummer 3 enthält) ausgewählt. Der erste muss aber nicht
während des zweiten Suchvorgangs ausgewählt werden, damit der Agent nicht zweimal in dem Vektor
mit den arbeitenden Agenten aufgenommen wird. Damit solche Fehler nicht passieren können, werden
die Einträge, die beim zweiten Durchsuchen ausgewählt werden, nur auf solche beschränkt, die keine
Telefonnummer enthalten, die schon in den gefundenen Einträgen aus dem ersten Suchlauf
auftauchen.
Es kann auch vorkommen, dass einem anderen Agenten die Montags-Schicht 3 zugeteilt ist, er aber
am aktuellen Tag in Schicht 5 arbeiten muss, die später als der Anrufzeitpunkt beginnt, also gar nicht
in dem Schichten-Vektor aufgenommen wird. In diesem Fall darf dieser Agent nicht als Arbeitender
ausgewählt werden. Das zweite Durchsuchen der Shift-Tabelle wird aber den ersten Eintrag (der
Schicht 3 enthält) auswählen, weil diese Schichtnummer im Schichten-Vektor enthalten sein wird.
Damit solche Fehler nicht vorkommen, überprüft man beim zweiten Suchlauf zusätzlich, ob dem
ausgewählten Agenten nicht bereits eine andere Schicht für das aktuelle Datum zugeteilt wurde.
Aus den gefundenen Einträgen werden nur die Telefonnummer der arbeitenden Agenten in einen
Vektor aufgenommen. Als nächstes wird die Länge dieses Vektors abgefragt (working agents). Eine
Länge von Null heißt, dass es keine Agenten gibt, die im Moment des Anrufs arbeiten. Das kann z.B.
an Feiertagen der Fall sein. In dieser Situation wird wieder nach einem Anrufbeantworter gefragt
Entwurf und Implementierung eines Callcenters
43
(answering machine) und entsprechend gehandelt. Im anderen Fall, wenn der Vektor mindestens
einen Agent enthält, müssen aus den arbeitenden Agenten nur diese ausgefiltert werden, die im
Moment auch verfügbar („available“) sind (Find available agents). Dafür wird der Anwesenheitsstatus der gefundenen arbeitenden Agenten aus der Status-Tabelle abgefragt (available agents).
Für jede Telefonnummer aus dem Vektor wird der entsprechende Eintrag in der Status-Tabelle
gesucht. Jedes Mal, wenn ein verfügbaren Agent gefunden wird, wird seine Nummer in einem neuen
Vektor gespeichert. Nach Überprüfung des jeweiligen Status aller arbeitenden Agenten wird der
nächste Schritt vom Wert der Vektorlänge bestimmt. Wenn dieser Wert Null ist, wird erneut nach dem
Anrufbeantworter gefragt (answering machine). Im Normalfall muss sich aber immer mindestens
einer der arbeitenden Agenten an seinem Arbeitsplatz befinden. Der Agent selbst kann seinen Status
auf „nicht Verfügbar“ („not available“) nämlich nur dann setzen, wenn mindestens ein anderer
Mitarbeiter verfügbar ist. Die einzige Möglichkeit, alle arbeitende Agenten als nicht verfügbar zu
markieren, wird nur dem Administrator angeboten. Der Wert des Zählers müsste also größer als Null
sein.
Dann
werden
alle verfügbare
Agenten aufsteigend
nach
der
Zeit
ihrer
letzten
Gesprächsweiterleitung sortiert (Sort agents), die vom Dienst bei jedem Telefonat gespeichert wird.
Solange die sortierte Liste nicht leer ist, werden die Telefonnummern nacheinander ausgewählt
(Choose agent) bis einer der Agenten das Gespräch annimmt. Das Ziel ist, das ankommende Gespräch
immer zu dem Agent weiterzuleiten, der am längsten nicht mehr telefoniert hat. Nachdem ein Agent
ausgewählt wurde, wird abgefragt, ob er im Moment ein Gespräch führt, d.h. ob sein Anschluss
besetzt ist (is busy). Wenn das der Fall ist, wird der nächste Agent aus der Liste geprüft, wenn nicht,
wird das Telefonat zu ihm weitergeleitet (Forward call to agent) und der Wert für die letzte
Weiterleitung zu ihm gespeichert. Die erfolgreiche Ausführung der forwardCall()-Funktion hängt aber
nicht nur davon ab ob der ausgewählte Agent „busy“ ist, sondern auch davon, ob er beim ServiceProvider registriert ist. Ist der Agent dem Dienstanbieter bekannt, so wird eine Verbindung zwischen
ihm und dem Anrufer aufgebaut. Ist er dagegen unbekannt, wird der Aufruf von forwardCall() eine
SOAP-Fehlermeldung produzieren. Der Callcenter fängt diese Ausnahme ab und speichert die
Nummer des Agenten, der den Ausnahmezustand verursacht hat, und den Zeitpunkt des Auftretens ab.
Danach wird mit Überprüfung des nächsten Agenten aus der sortierte Liste fortgefahren. Die
gespeicherten Einträge der auftretenden Ausnahmen werden für eine festgelegte Zeitspanne
gespeichert und vor Aufruf von forwardCall() durchgegangen (exists). Somit kann eine Weiterleitung
des Gesprächs zu einem Agenten, der nicht besetzt, aber auch nicht registriert ist, frühzeitig verhindert
werden. Wird der Agent vor Ablauf der Zeitspanne beim Dienstanbieter registriert, kann er als
Gesprächspartner beim nächsten Aufruf der supp_execute()-Funktion wieder ausgewählt werden.
Entwurf und Implementierung eines Callcenters
Abbildung 19: Flussdiagramm der supp_execute()-Funktion
44
Entwurf und Implementierung eines Callcenters
45
Wenn der Callcenter-Service die ganze sortierte Liste der verfügbaren Agenten durchläuft und keinen
findet, der sowohl nicht besetzt, als auch registriert ist, d.h. der das Gespräch annehmen kann, fragt er
nach einer Warteschlange (queue). Wird keine solche zur Verfügung gestellt, so wird das
ankommende Gespräch zum Anrufbeantworter geschickt. Wenn eine Warteschlange existiert, wird der
Anrufer an sie weitergeleitet. Dort wird er von einer aufgezeichneten Stimme darum gebeten, solange
zu warten, bis ein Mitarbeiter frei geworden ist.
Zusammenfassung und Ausblick
46
Kapitel 4: Zusammenfassung und Ausblick
In der vorliegenden Projektarbeit wurde ein Inbound-Callcenter entworfen. Das Callcenter sollte als
Leistungsmerkmal in einem Web-Service-basierten VoIP-Framework entwickelt werden. Zu diesem
Zweck wurden zunächst die grundlegenden Begriffe Callcenter, VoIP und Web-Services erläutert und
die Funktionsweise ihrer Technologien vorgestellt.
Bei einem Callcenter handelt es sich um eine Organisationseinheit oder ein Unternehmen, in dem
eingehende (inbound) oder ausgehende (outbound) Telefongespräche ähnlichen Charakters auf
Telefonarbeitsplätze verteilt werden. Callcenter werden in vielen Arbeitsbereichen eingesetzt, bei
denen eine telefonische Beratung, Unterstützung oder Verkauf möglich ist.
Anschließend wurde erklärt, wie die Internettelefonie, oder kurz VoIP, funktioniert und welche ihre
Vor- und Nachteile gegenüber dem klassischen Telefonnetz sind. Die VoIP-Technologie hat in den
letzten Jahren große Fortschritte gemacht und die Qualität der Gespräche über IP ist mittlerweile mit
der Qualität des herkömmlichen Netzes vergleichbar geworden.
Die Web-Services-Technologie spielt in der vorliegenden Arbeit auch eine große Rolle. Ein WebService ist eine Softwarekomponente, die lose über das Internet mit anderen Softwarekomponenten
interagiert, um gemeinsam Aufgaben zu erfüllen. Damit eine plattform-, programmiersprachen- und
protokollunabhängige Kommunikation zwischen den Web-Services ermöglicht wird, verwendet diese
Technologie die XML-basierten Standards SOAP, WSDL und UDDI.
Das UDDI-Verzeichnis dient der Registrierung und dem Suchen von Web-Services. WSDL beschreibt
die Schnittstelle des Web-Services und schreibt damit vor, wie der Service-Anwender mit dem WebService kommunizieren kann. Für die Übertragung der Daten zwischen dem Anbieter und dem Nutzer
des entsprechenden Services ist dann SOAP über HTTP verantwortlich.
Im letzten Teil des Grundlagen-Kapitels wurde das Framework Venice vorgestellt, wofür das
Callcenter entwickelt wurde. Venice kombiniert VoIP mit Web-Services und stellt eine neue
Architektur dar, die viele Vorteile für die Benutzer und Entwickler des VoIP-Systems anbietet.
Wie der Callcenter-Service entworfen und implementiert wurde, ist im dritten Kapitel dieser
Ausarbeitung präsentiert worden. Da das Callcenter als Web-Service realisiert wurde, kann es
problemlos mit anderen Softwaresystemen interagieren und von verschiedenen VoIP-Anbietern
verwendet werden. Das Callcenter kontrolliert die ankommenden Anrufe so, dass jedes Gespräch an
den Agenten weitergeleitet wird, der zum entsprechenden Zeitpunkt am längsten nicht telefoniert hat.
Damit versucht der Dienst eine möglichst gleichmäßige Verteilung der Anrufe zu erreichen.
Die Einsatzplanung des Personals von Hand ist eine Aufgabe, die viel Zeit in Anspruch nimmt. Die
Entwicklung eines Dienstes, der diese aufwändige Aufgabe löst, wäre eine hilfreiche Erweiterung des
implementierten Callcenter-Services. Dafür können Statistiken über die Anzahl der eingehenden
Gespräche und die Wartezeit der Anrufe in der Warteschlange gesammelt werden. Mit diesen
Zusammenfassung und Ausblick
47
Statistiken könnten dann Prognosen für die Zahl der zu erwartenden Anrufe gemacht werden. Auf
Basis dieser Vorhersagen könnten effiziente Personal- und Schicht-Pläne erstellt werden.
Eine andere mögliche Erweiterung des existierenden Callcenters wäre die Implementierung eines
IVR-Mechanismus, der die Agenten von Routineauskünften entlasten würde.
VoIP ist eine erfolgversprechende Technologie, die in den nächsten Jahren die klassische Telefonie
völlig ablösen kann. Dafür müssen die VoIP-Systeme aber die bekannten und üblichen
Leistungsmerkmale mit einer besseren Qualität und auch neue interessante Dienste anbieten. Das im
Rahmen dieser Projektarbeit erfolgreich entwickelte Callcenter ist ein solches Leistungsmerkmal, das
in Großunternehmen und Verkaufshäuser einwandfrei eingesetzt werden kann.
Literaturverzeichnis
48
Literaturverzeichnis
[ABB+03]
E. Armstrong, J. Ball, S. Bodoff, D. Bode Carson, I. Evans, M. Fisher, S. Fordin, D.
Green, K. Haase, E. Jendrock : The Java™ Web Services Tutorial, 17 December 2003
[Braa05]
J. de Braaf: Java Web Services, Ausarbeitung im Rahmen des Softwaretechnik
Seminars, WS 2004/05
[CallCenter]
Call Center - Ein Leitfaden für kleine und mittlere Unternehmen,
http://www.cca.nrw.de/docs/callcenterleitfaden_bmwi.pdf
[CaCe05]
Callcenter aus Wikipedia, der freien Enzyklopädie:
http://de.wikipedia.org/wiki/Callcenter, Stand 19. Aug 2005
[ChJe02]
D. A. Chappel, T. Jewell : Java Web Services, O’Reilly, 2002
[CCM+01]
E. Christensen, F. Cubera, G. Meredith, T. Berners-Lee, R. Fielding, S. Weerawarana:
Web Service Description Language (WSDL) 1.1, http://www.w3c.org/TR/wsdl, 2001
[Dusc02]
E. Dusch : Internet Telephonie – VoIP. ITA. 7, 2002
[Fink04]
F.- J. Fink : Integration eines SIP Stacks in eine Web-Service basierte VoIP-Lösung,
Projektarbeit im WS 2003/04
[HaLö04]
T. Hauser, U. M. Löwer : Web Services – Die Standards, Galileo Computing, 2004
[HGM05]
M. Hillenbrand, J. Götze, P. Müller: Voice over IP – Considerations for a Next
Generation Architecture, In Proceedings of 31st Euromicro Conference, (Porto,
Portugal), August 30th - September 3rd 2005
[HGMM05]
M. Hillenbrand, J. Götze, J. Müller, P. Müller: Rollen-basiertes AAA zur
Dienstnutzung in Föderationen, In Proceedings of 19. DFN Arbeitstagung
(Düsseldorf, Deutschland), Mai 2005
[Hi-JGPE]
M. Hillenbrand : Dokumentation der Java-GPE
http://www.markus-hillenbrand.de/javagpe
[HiZh04]
M. Hillenbrand, G. Zhang: A Web Service Based Framework for Voice over IP, In
Proceedings of the 30 th Euromicro Conference 2004 (Rennes, France), August 2004
[HMM04]
M. Hillenbrand, P. Müller, H. Müller: Voice over IP als Web Service, In Proceedings
of 18. DNF Arbeitstagung (Düsseldorf, Deutschland), Juni 2004.
[HMMi04]
M. Hillenbrand, P. Müller, K. Mihajloski: A Software Deployment Service for
Autonomous Computing Environments. Proceedings of International Conference on
Intelligent Agents, Web Technology and Internet Commerce - IAWTIC'2004 (Gold
Coast, Australia), 2004.
[HSSR02]
M. Handley, H. Schulzrinne, E. Scholer, J. Rosenberg: RFC 3261 – SIP: Session
initiation protocol, April 2002
Literaturverzeichnis
[HTTP05]
49
Hypertext Transfer Protocol aus Wikipedia, der freien Enzyklopädie:
http://de.wikipedia.org/wiki/http, Stand 30. Nov. 2005
[IPT05]
IP-Telefonie aus Wikipedia, der freien Enzyklopädie:
http://de.wikibooks.org/wiki/IP-Telefonie, Stand 23.Aug 2005
[ITU-H.323]
ITU, Recommendation H.323: Packet-based multimedia communications systems, Juli
2003, http://www.itu.int/rec/recommendation.asp?type=folders&lang=e&parent=TREC-H.323
[Knut02]
M. Knuth: Web Services – Einführung und Übersicht, Software & Support Verlag,
2002
[Nöll05]
J. Nölle: Voice over IP (VoIP) – Eine Einführung, verfügbar im World Wide Web:
http://www.voip-info.de/wissen/_Artikel_Allgemein_32.php
[Paap03]
S. Paape: Spezifikation von Webservices (WSDL/WSFL), Seminararbeit in
Programmierung verteilter Systeme, Christian-Albrechts-Universität zu Kiel, 2003
[RSL02]
S. Rupp, G. Sirgmund, W. Lautenschlager: SIP – Multimediale Dienste im Internet –
Grundlagen, Architektur, Anwendungen, dpunkt.verlag 2002
[RuSi04]
S. Rupp, G. Siegmund: Java in der Telekommunikation – Grundlagen, Konzepte,
Anwendungen, dpunkt.verlag 2004
[SunJ05]
http://java.sun.com/j2se
[SunWS05]
http://java.sun.com/webservices/jwsdp/index.jsp
[T-LAN]
T-LAN Glossar,
http://www.t-lan.de/GLOSSAR/
[Tomi06]
Damir Tomicic, IBM, Microsoft and SAP Close Down UDDI Business Registry,
http://tomicic.de/DevelopmentIBMMicrosoftAndSAPCloseDownUDDIBusinessRegis
try.aspx
[WüBu02]
E. Wüstner, P. Buxmann: SOAP für Web Services
Abbildungsverzeichnis
50
Abbildungsverzeichnis
Abbildung 1:Signalverarbeitung bei VoIP .......................................................................................... 8
Abbildung 2: Gateway als Vermittler zwischen VoIP-Netz und Telefonnetz....................................... 9
Abbildung 3: VoIP Protokoll Architektur ......................................................................................... 10
Abbildung 4: Protokoll-Stack eines Web-Service ............................................................................. 13
Abbildung 5: Service-orientierte Architektur (SOA) ......................................................................... 14
Abbildung 6: Beispiel für XML Schema........................................................................................... 16
Abbildung 7: Struktur einer SOAP-Nachricht ................................................................................... 18
Abbildung 8: Struktur einer WSDL-Datei......................................................................................... 21
Abbildung 9: Datenstrukturen einer UDDI-Registrierungsstelle nach [Braa05] ................................. 22
Abbildung 10: Architektur des Venice-Frameworks [HGM05] ......................................................... 25
Abbildung 11: Supplementary Services in Venice nach [HGM05] .................................................... 29
Abbildung 12: Datenbankschema des Callcenter Services................................................................. 33
Abbildung 13: Auszug des XML-Schemas des Callcenter-Dienstes .................................................. 34
Abbildung 14:Work Time Panel ....................................................................................................... 36
Abbildung 15: Status Panel .............................................................................................................. 37
Abbildung 16: Shift Panel ................................................................................................................ 38
Abbildung 17: Agent Panel .............................................................................................................. 40
Abbildung 18: Callcenter Supplementary Service ............................................................................. 41
Abbildung 19: Flussdiagramm der supp_execute()-Funktion............................................................. 44
Abkürzungen
51
Abkürzungen
ACD
Automatic Call Distribution
API
Application Programming Interface
arpa
Address and Routing Parameters Area
Axis
Apache Extensible Interaction System
CORBA
Common Object Request Broker Architecture
CTI
Computer Telephony Integration
DCOM
Distributed Common Object Model
DOS
Denial of Service
DTD
Document Type Definition
ENUM
Electronic Numbering
FIM
Feature Interaction Manager
GUI
Graphical User Interface
HTTP
Hypertext Transfer Protocol
IB
Information Brokering
IETF
Internet Engineering Task Force
ISDN
Integrated Services Digital Network
IT
Information Technology
ITU
International Telecommunication Union
IVR
Interactive Voice Response
Java-GPE
Java GUI Programming Extensions
MAB
Metering, Accounting, and Billing
ORDBMS
Objectrelational Database Management System
PAT
Port Address Translation
PSTN
Public Switched Telephone Network
QoS
Quality of Service
RegTP
Regulierungsbehörde für Telekommunikation und Post
RMI
Remote Method Invocation
RPC
Remote Procedure Calls
RTCP
Real Time Control Protocol
RTP
Real Time Protocol
RTTP
Real Time Transport Protocol
SDS
Software Deployment
SIP
Session Initiation Protocol
SMTP
Simple Mail Transport Protoco
Abkürzungen
52
SOA
Service-oriented Architecture
SOAP
Simple Object Access Protocol
SPIT
Spam over Internet Telephony
SQL
Structured Query Language
SSO
Single Sign-on
ST
Service Token
TCP
Transmission Control Protocol
TGT
Ticket Granting Token
UBR
Universal Business Register
UDDI
Universal Description, Discovery and Integration
UDP
User Datagram Protocol
URI
Uniform Resource Identifier
UUID
Universally Unique Identifier
VoIP
Voice over IP
WSDL
Web Service Description Language
WWW
World Wide Web
XML
Extensible Markup Language
XSD
XML Schema Definition