Dokument - Roland Volk Technology Consulting
Werbung
Implementierung einer Service-orientierten Architektur für die Telekommunikationsindustrie am Beispiel “Integriertes Service Management” Roland Volk Hubert Blankenberg Ekhard Konrath IP VALUE GmbH, Dortmund Zusammenfassung Das integrierte Service Management ist eine zwingend erforderliche Voraussetzung für Communication Service Provider (CSPs), um erfolgreich ein konkurrenzfähiges Diensteportfolio zu entwickeln und zu betreiben. Leider führte das Fehlen von offenen und standardisierten Integrationsansätzen zu proprietären Lösungen, die teuer hinsichtlich Investitions- und Betriebkosten sind. Mit dem Erscheinen von TMF NGOSS und den offenen Standards OSS/J Initiative haben CSPs jetzt die Möglichkeit, eine sanfte Migration hin zu Standardbasierten und integrierten Service Management Lösung voranzutreiben. Dieses Papier diskutiert die technologischen Aspekte eines kombinierten NGOSS-OSS/J Ansatzes. Stichworte B/OSS, eTOM, Integration, NGOSS, OSS/J, Service Management, SID, SoA, Web Service Synopsis Integrated service management is a mandatory prerequisite for communication service providers to successfully deploy and operate a competitive portfolio of customer services. Unfortunately, missing open and standardized integration approaches led to proprietary solutions expensive in terms of both capital and operational expenditures. With the advent of TMF’s NGOSS and OSS/J Initiative, CSPs have now the opportunity to migrate smoothly towards a standardized integrated service management solution. Key Words B/OSS, eTOM, Integration, NGOSS, OSS/J, Service Management, SID, SoA, Web Service 1. Einführung Communication Service Provider (CSPs) erweitern rasant ihr Diensteportfolio, um den wachsenden Bedarf nach individuellen, innovativen und besonders attraktiven Diensten zu adressieren. Gleichzeitig sind sie auch gefordert, ein hohes Niveau hinsichtlich Dienstqualität zu halten. Beide Aspekte sind wichtig für eine höhere Kundenbindung. Auf der anderen Seite erfordert die Wettbewerbssituation im Telekommunikationsmarkt die Reduktion von Betriebskosten und zwingt Telekommunikationsunternehmen daher zu einer Erhöhung des Automatisierungsgrades ihrer Kerngeschäftsprozesse, die eine Vielzahl von existierenden Operational und Business Support Systemen (B/OSS) umfassen. So ist insbesondere ein integriertes Service Management (ISM) der Schlüssel für die Bereitstellung, Aktivierung und den Betrieb konkurrenzfähiger Dienste wie z.B. IPTelefonie (VoIP). Neben einer wachsenden Zahl von Nutzern und Diensten ist dieser Bereich vor allem durch eine Fülle komplexer Netzwerktechnologien und -standards sowie durch eine große Zahl spezialisierter NM/SM Applikationen charakterisiert. Zusätzlich ist das Aufrechterhalten sehr guter Dienstgütegrade, hoher Netzwerkverfügbarkeit, -zuverlässigkeit und -sicherheit eine permanente Herausforderung. Dieses Papier beschreibt einen Ansatz zum Aufbau einer ISM-Lösung, die dem allgemeinen Trend der B/OSS Industrie in Richtung komponentenbasierte und Serviceorientierte B/OSS Architekturen folgt. Eine Serviceorientierte Architektur (SoA) wird auch vom TeleManagement Forum (TMF) in seinen NGOSS Spezifikationen (New Generation Operations Systems and Software) definiert. Der hier vorgestellte Ansatz basiert auf einer Palette offener und standardisierter B/OSS Application Programming Interfaces (APIs) der OSS through Java™ (OSS/J) Initiative. Der OSS/J-Ansatz ist außerdem die erste technologiespezifische Implementierung von NGOSS. Eine typische ISM-Lösung umfasst drei ausgeprägte Anwendungsgebiete mit den jeweils zugehörigen Aufgaben: - Service Fulfillment (Management der Auftragseingabe, schnelle Modifizierung von Diensten, rasche Dienstaktivierung und Lieferung, Verfolgung und Management des Inventars) - Service Assurance (Sicherstellung der Dienstverfügbarkeit, Überwachung des Leistungsverhaltens, Minimierung von Reparaturzeiten, Management von Dienstgütevereinbarungen) - Service Billing (Verbrauchsbasierte und Inhaltbasierte Abrechnung, Kapazitätsplanung und Analyse des Kundenverhaltens) Zur besseren Erläuterung des kombinierten NGOSS-OSS/J Ansatzes und seiner wesentlichen Ergebnisse konzentriert sich dieses Papier auf den Service Assurance Bereich. Dabei werden Nutzen und Vorteile der OSS/J-Technologie detailliert aufgezeigt. Dies erfolgt mit Hilfe eines kürzlich realisierten NM/SM Integrationsprojektes bei einem globalen Mobilfunkunternehmen und den dort gewonnenen Erfahrungen. 2. Integriertes Service Management – Eine syntaktische und semantische Herausforderung Die Integration vorhandener B/OSS-Systeme erfordert grundsätzlich die Lösung zweier Kernaufgaben, um Systemübergreifende Geschäftsprozesse automatisieren zu können: a) B/OSS-Systeme tauschen gewöhnlich Daten (Business Entities) unter Nutzung verschiedener proprietärer Schnittstellen aus (syntaktische Herausforderung) b) B/OSS-Systeme müssen die jeweiligen Daten “verstehen”, die sie von anderen IT Systemen empfangen (semantische Herausforderung). Während die Anstrengungen zur Lösung der syntaktischen Herausforderung schon zu einigen technologischen Evolutionsschritten (z.B. Integration auf Datenbankebene, Punkt-zu-Punkt Schnittstellenintegration, Message-oriented Middleware (MOM)) in der Enterprise Application Integration (EAI) geführt haben, sind offene und standardisierte Integrationsansätze erst kürzlich durch die Aktivitäten des TMF’s und insbesondere der OSS/J Initiative in das Rampenlicht getreten. Leider ist die semantische Herausforderung noch komplexer als die syntaktische Herausforderung. Dies ist in der Tatsache begründet, dass praktisch jedes B/OSS ein eigenes proprietäres Datenmodell und Business Entities (Datenobjekte) besitzt. Im Ergebnis umfasst die IT-Landschaft eines CSP’s eine große Zahl systemspezifischer (Sub-)Datenmodelle and Business Entities mit unterschiedlicher Semantik. Eine vereinheitlichte Datensemantik zwischen den beteiligten B/OSS ist jedoch der entscheidende Faktor für ein erfolgreiches Integrationsprojekt, das als Ziel die Systemübergreifende Automatisierung der Geschäftsprozesse hat. Einfache Fragen im Service Management Bereich wie beispielsweise - Welcher Dienst ist durch einen Netzwerkausfall beeinträchtigt oder in seinem Leistungsverhalten betroffen? - Welche Kunden oder welche Kundengruppen sind betroffen? - Sind Redundanzoptionen verfügbar? - Sind Ansprüche hinsichtlich Ausgleichszahlungen infolge von Verletzungen der Dienstgütevereinbarungen (SLAs) zu erwarten? sind im täglichen Betrieb des CSP’s nicht zu beantworten, es sei denn eine gemeinsame Datensemantik zwischen den involvierten NM/SM-spezifischen IT Systemen wurde geschaffen. Aus diesem Grund hat die TMF das ‘Shared Information/Data Model’ (SID) für die Telekommunikationsindustrie als Teil der jetzt zur Reife gelangten, umfassenden NGOSS Spezifikationen definiert. Die OSS/J Initiative leitete die Spezifikation der Datensemantik für ihre funktionalen APIs (siehe Abschnitt 4.3) direkt von den SID Definitionen ab (siehe [2] und [4] für detaillierte Spezifikationen). Jedoch beantwortet die pure Existenz eines allgemeinen (Meta-)Datenmodells nicht die Frage der Implementierung eines solchen Modells in der IT-Umgebung eines CSP’s bei gleichzeitig notwendiger Unterstützung der bestehenden systemspezifischen Datenmodelle und Datenbanken. 3. Der Ansatz des TMF’s für eine Service-orientierte Architektur Der derzeitige Industrietrend in Richtung einer Komponentenbasierten, Serviceorientierten Architektur wird unterstützt durch die jüngsten Fortschritte im Bereich der Standardisierung: Das TMF NGOSS Programm [1] ist ein Geschäftsorientiertes, technologieneutrales Rahmenwerk, das eine Methodik für die Entwicklung von OSS Komponenten liefert. Zusätzlich definiert die mit NGOSS verbundene Enhanced Telecom Operations Map (eTOM) [3] die grundlegenden OSS Konzepte und das Prozessgerüst, das bereits auf breiter Basis in der Telekommunikationsindustrie eingesetzt wird. Ein Strukturüberblick der NGOSS Architektur wird in [5] geliefert. Allgemein deckt die NGOSS Arbeit vier unterschiedliche Bereiche ab: - Systemanalyse und -design (Shared Information/Data Model SID) - Analyse und Design der Geschäftsprozesse (Enhanced Telecom Operations Map eTOM) - Analyse und Design der Lösung (Technology Neutral Architecture & Contract Interface) - Testen der Lösung (Compliance Tests) Neben anderen Punkten beinhalten die Charakteristika eines NGOSS Systems: - die Nutzung eines allgemeingültigen Informationsmodells, um Integration und Interoperabilität zu ermöglichen - die Trennung des fest programmierten Verhaltens der einzelnen Komponenten von der Software, die die Geschäftsprozesse systemübergreifend automatisiert (z.B. erfolgt der Aufbau eines NGOSS Systemen mit definierten Services, die dann über Scripting/Process Management Technologien orchestriert werden) - das ein Geschäftsprozessmodell untergeordnete Geschäftsprozessmodelle aufrufen kann - die Ansprechbarkeit der Funktionalität von Geschäftsanwendungen über NGOSS Contractual Interfaces - die Existenz von Distribution und Transparency Services zur Unterstützung von Interaktionsmustern zwischen Komponenten (Naming, Repositories, Registration Services, Service Location Services). Aufgrund der Fokussierung des NGOSS Programms auf Geschäftsaspekte liegt die Schwierigkeit in seiner allgemeinen Natur und Komplexität, die zu Fragen bei Implementierung und Interoperabilität führen. Deshalb hat die OSS/J Initiative einen anderen, aber ergänzenden Ansatz verfolgt. Dieser konzentriert sich auf die Implementierungsaspekte mit dem obersten Ziel, die Marktverfügbarkeit von wieder verwendbaren B/OSS Lösungen zu fördern. OSS/J ist ein wichtiger Schritt in der B/OSS Standardisierung, da es das TMF NGOSS Programm erweitert um die Implementierungsaspekte der Integration von B/OSS Systemen durch die Bereitstellung von funktionalen APIs und deren Implementierung mittels etablierter IT Technologie. OSS/J setzt Java™ und J2EE Technologie (Java 2 Enterprise Edition) wirksam als Basisintegrationsplattform ein. Damit kann die eng gekoppelte Systemsintegration für die Nutzung innerhalb eines Unternehmens ebenso wie die lose gekoppelte Systemsintegration mit XML und Web Services für die Nutzung in Unternehmen und für Busines-to-Business Anwendungen unterstützt werden. OSS/J ist die erste technologiespezifische Implementierung von NGOSS. Insbesondere mit seiner inhärenten Kapselungsmethode für B/OSS Altsysteme bietet OSS/J eine effiziente Migrationstrategie zu einer NGOSS-konformen Architektur. Eine detaillierte Studie, wie das OSS/J Programm die NGOSS Technology Neutral Architecture (TNA) hinsichtlich Architekturprinzipien, Contract Schemata und Modellierungstechniken für Informationen ergänzt, kann in [6] gefunden werden. 4. OSS through JavaTM Initiative (OSS/J) 4.1 Einführung und Überblick Aufbauend auf dem Erfolg der Java 2 Platform Enterprise Edition (J2EE™) Technologie in Unternehmensapplikationen und E-Commerce wurde die OSS/J Initiative gegründet. Sie entwickelt funktionale APIs für austauschbare, interoperable Komponenten, die rasch und kostenneffektiv zu Ende-zu-Ende Telekommunikationslösungen zusammengefügt werden können sowie leicht zu pflegen and anzupassen sind, um neue Funktionalität zu unterstützen. Die APIs der OSS/J Initiative werden unter dem aktuellen Java Community Processsm (JCP) Programm standardisiert. JCP liefert als Ergebnis für jeden Anwendungsbereich eine Spezifikation, eine Referenzimplementierung (RI) und einen Technology Compatibility Kit (TCK). Neben den funktionalen APIs sind weitere wichtige Arbeitsergebnisse der OSS/J Initiative die Common API [8] und die Design Guidelines (DG) [7], die eine schnelle und einheitliche Integration aller Anwendungen sicherstellen, die auf Basis der OSS/J Spezifikationen entwickelt werden. Die Nutzung der OSS/J DG und Common API Implementierung ermöglicht eine effiziente Implementierung weiterer zukunftssicherer Software-Komponenten. Diese Software-Komponenten sind konform zu den existierenden OSS/J Standards und können leicht an neu entstehende OSS/J Standards und APIs angepasst werden. OSS/J unterstützt weiterhin die stark aufkommenden Web Services Ansätze für Integrations- und Automatisierungsaufgaben (siehe 4.4). Der wesentliche Anwendungsnutzen der OSS/J APIs liegt einer signifikanten Kostenreduzierung bei der Integration bestehender Systeme und Applikationen sowie einer schnelleren Einführung neuer Dienste. Weitere Merkmale sind ein besserer Investitionsschutz, ein schnellerer Einsatz neuer B/OSS Lösungen und die Verfügbarkeit wieder verwendbarer Software-Komponenten für “Point-to-Multi-Point” Interfaces. 4.2 OSS/J als NGOSS-Implementierung Das TeleManagement Forum NGOSS Programm und die OSS through Java™ Initiative (OSS/J) API Spezifikationen definieren einen neuen Ansatz, um OSS Systeme unter Nutzung der J2EE Plattform zu entwickeln. Dem wird eine umfassende, auf die Telekommunikationsindustrie zugeschnittene Referenzarchitektur zugrunde gelegt. Das NGOSS Referenzmodell Das NGOSS Referenzmodell besitzt als wichtigsten Bestandteil ein gemeinsames Informations- und Daten-Modell (SID). Es ist ein standardisiertes Abbild der Telekommunikations-Domäne und definiert die Standard-Abstraktionen, wie Kunde, Bestellung und Netwerk-Dienst. Des Weiteren trifft das Modell klare Aussagen über die Bedeutung der Abstraktionen, ihr Verhalten und ihre Zusammenarbeit. Weitere Bestandteile des NGOSS Referenzmodells sind - Sicherheitsmechanismen und -grundsätze ISO17799 2001 - Grundsätze (Policy) - Business-Prozesse (Business Process (eTOM)) - OSS-Applikationen - OSS-Framework-Dienste (OSS Framework Services) - Grundlegende Framework-Dienste (Basic Framework Services) - Grundlegende Mechanismen (Basic Mechanisms) - NGOSS und RM-ODP OSS/J als NGOSS Implementierung Die NGOSS-Referenzarchitektur ist eine technologieneutrale Architektur. Diese muss für den jeweiligen Anwendungsfall auf konkrete Komponentenplattformen abgebildet werden. Aus diesem Grund wurde im Rahmen des Java Community Process (JCP) für die J2EE-Plattform die OSS through Java Initiative (OSS/J) von führenden Herstellern ins Leben gerufen, die die Prinzipien der NGOSS-Referenzarchitektur auf Basis von J2EE implementiert. Hierzu definiert die OSS/J-Initiative verschiedene Application Programming Interfaces (API), die auf eTOM basieren. Die API Spezifikationen spiegeln zum einen die benötigte Funktionalität und zum anderen die architektonisch relevanten Systembausteine wieder. 4.3 Funktionale OSS/J APIs für die B/OSS Integration Die Arbeitsergebnisse der OSS/J Initiative umfassen heute die folgenden direkt von TMF eTOM Prozessen [3] abgeleiteten, funktionalen APIs: - Service Activation API [9]: Behandelt jede Art von Auftrag und Dienst - Quality of Service API [10]: Leistungsverhalten, Schwellwerte sowie die Fehlerüberwachung aller ITK-Elemente - Trouble Ticket API [11]: Unterstützt den Störfall- und Fehlerbehebungsprozes - IP Billing Mediation API [12]: Unterstützt den Prozess zur Sammlung und Transformation von Abrechnungsinformationen - Inventory API [13]: Definiert den allgemeinen Zugang zu jeder Art von Inventardaten (Produkt, Service, Ressource) Die für ein integriertes Service Management relevanten APIs werden inklusive der vorläufigen Service Quality Management API [14] detaillierter im Abschnitt 5 diskutiert. Bild 1 zeigt wie die OSS/J Core APIs den TMF eTOM Prozessen zugeordnet sind. Customer Interface Management Prozess Sales Order Handling Problem Handling Customer Care - Prozesse Service Planning Develop. Service Config. Customer OoS Mgmt OSS/J Service Activation API Invoicing/ Collection OSS/J Quality of Service API OSS/J SQM API Service Problem Resolution Service Quality Mgmt Rating & Discount. OSS/J Trouble Ticket API Service Development und Operation - Prozesse Network Planning Develop. Network Provision. Network Inventory Mgmt Network Maintnce. Restoration Network Data Mgmt OSS/ Billing Mediation API OSS/J Inventory API Network und Systems Management - Prozesse Element Management / Physical Network Abbildung 1: eTOM Prozesse und OSS/J APIs 4.4 Prinzipien der OSS/J-basierten Integration Die OSS/J-basierte Integration folgt den Leitsätzen der funktionalen Aufteilung (klare Trennung von Modell, Workflow, Regeln und Code) zwischen B/OSS Systemen zur Steigerung der Flexibilität und Adaptierbarkeit ebenso wie einer Reduzierung der Wartungskosten und Systemabhängigkeiten. Die funktionale Aufteilung wird mit separaten OSS/J API- und Adapter-Komponenten erreicht, die eine Kapselung existierender und neuer (Nicht-OSS/J-konformer) Systeme ermöglichen. OSS/J Schnittstelle Client Anwendung OSS-A (COTS/legacy) Server Anwendung J2EE OSS-A Adapter OSS/J API Implementierung OSS-B Adapter OSS-B (COTS/legacy) Die entsprechenden OSS/J APIKomponenten bieten allgemeingültige, In Unkenntnis über OSS-A & -B, Daten und Service Attribute Mapping OSS-A OSS/J funktionale Geschäftsobjekte und Methoden, Attribute Mapping OSS/J OSS-B Adapter benötigt nur geringes Wissen über OSS/J API die von globalen, industriespezifischen Fokusgruppen vereinbart wurden. Die OSS-A & -B wissen nichts von der jeweils anderen Schnittstelle Abbildung 2: Allgemeine OSS/J Komponenten Architektur Adapter-Komponente ist dagegen verantwortlich für eine Zuordnung der proprietären Objekte und Funktionen der gekapselten Serveranwendung zu den entsprechenden Attributen und Funktionen der verwendeten OSS/J Schnittstelle. Dieser Ansatz führt dazu, dass mit Hilfe der vollständig wieder verwendbaren API Komponente eine Implementierung von “Pointto-Multi-Point” Integrationen mit minimiertem Anpassungsaufwand im dazugehörigen Adapter erfolgen kann. Da jeder Adapter nur die Kenntnis eines der B/OSS Systems erfordert (völlige Systemunabhängigkeit) erfolgt bei der Integration eines weiteren Systems nur noch ein Adapteraustausch. Bild 2 illustriert die OSS/J Integrationsprinzipien mit lokaler Attributzuordnung und vollständiger funktionaler Aufteilung zwischen den beiden B/OSS Systemen. Jede OSS/J API ist erweiterbar und unterstützt Metadaten mit einem entsprechendem Abfragemechanismus. Der Ausdruck “Metadaten” bezieht sich auf das OSS/J Core Information Model von Shareable Data Transfer Objects (Core Business Entities CBE, [4]) das direkt ausgerichtet ist am TMF SID. Tatsächlich ist die Erweiterbarkeit jeder OSS/J API der Schlüssel, um die in Abschnitt 2 beschriebene semantische Herausforderung zu lösen. Sie erlaubt die schrittweise Integration existierender B/OSS Systeme und der jeweiligen proprietären Datenmodelle. J2EE™, XML und Web Services Während die OSS/J APIs einerseits CSP- OSS/J eng gekoppelte Integration lose gekoppelte Integration B2B Integration spezifische Semantik beschreiben und implementieren, müssen sie andererseits auch passende KommunikationsMechanismen für unterschiedliche Java EJB RMI IIOP XML JMS XML Web Services Geschäftsszenarien liefern (siehe Bild 3). Abbildung 3: OSS/J Integrations-Konzepte Die Implementierung der Semantik wird durch CSP-spezifische Managed Entities (Trouble Ticket, Product, Order, SLA, Fault, …) und Methoden (Create, Read, Update, Delete, Query) festgelegt. B2B-Transaktionen werden heute mittels XML-Technologien wie electronic business XML (ebXML), durchgeführt. Deshalb hat die OSS/J die API Design Guidelines um das Web Services Profil erweitert. Damit stehen nun drei Interaktionstechnologien zur Verfügung. Für die enge Kopplung von Systemen steht das EJB/JVT, für die lose Kopplung über Message-oriented-Middleware das JMS/XVT und für die systemneutrale Kopplung die XML-basierten Web Services zur Verfügung. 5. Das TMF SID als Telco-Unternehmensdatenmodell 5.1 TMF eTOM, SID - Einführung Die „enhanced Telecom Operations Map“ (eTOM) und ist ein Standard des TMF. Ziel ist es, die Prozesse im Einzelnen und über die gesamte Perspektive vom Hersteller zum Abnehmer (Ende-zu-Ende) zu definieren. Der Ansatz des TMF besteht darin, in erster Linie eine Modellierung für ein idealtypisches Telekom-Unternehmen zu erarbeiten, um daraufhin zu bestimmen, welche Geschäftsobjekte in einem solchen Unternehmen vorliegen. Die Definition der Geschäftsobjekte erfolgt dabei im Rahmen des Shared Information/Data Modells (SID). Die Architektur der eTOM versteht sich also als ein Framework, der alle für ein Telekom- oder IT-Dienstleistungsunternehmen typischen Prozesse in einer strukturierten Art und Weise abbilden kann. Das SID Modell Die Eigenschaften der Architektur der eTOM werden als weltweiter De-factoStandard bezeichnet. Aus diesem Grund kann das TMF in den letzten Jahren stets wachsendes Interesse an den Referenzmodellen eTOM und SID verzeichnen. Das TMF entwickelt mit dem SID Modell Objektdefinitionen, die bewusst die Entwicklung von datenkompatiblen Softwaretools unterstützen sollen. Das SID Modell, als das NGOSS Informationsmodell, enthält ein Information und Data Reference Model und ein Common Information and Data Vocabulary für Business wie auch Systemperspektiven. Es wird UML verwendet, um Ausdrücke für den Gebrauch in den verschiedenen Perspektiven darzustellen. Das SID Modell enthält eine Common Language zur Kommunikation zwischen den verschiedenen Gruppen. Die Normierung der Objekte durch das SID Konzept schafft hier Abhilfe. Dadurch, dass der Standard nicht technologiespezifisch ist, können generische Implementierungen in beliebigen Technologien von Herstellern entworfen werden. Die Entwicklung von Adaptern, denen bislang das Hauptaugenmerk der Integratoren gegolten hat, wird nun zu einer deutlich leichter zu lösenden Angelegenheit. Zudem ist die Tendenz zu beobachten, dass zum Datenaustausch nicht mehr komplexe Standards sondern immer häufiger SOAP-Architekturen verwendet werden. Es ist zu erkennen, dass bereits namhafte Hersteller ihre Softwaresysteme auf komponentenorientierte Modelle umstellen, um damit einerseits die Modularisierung des Einsatzes ihrer Software zu ermöglichen, aber auch um den Aufbau von serviceorientierten Architekturen zu unterstützten. Die SID Konzepte Einige, die zentrale Idee des gemeinsamen Informations- und Datenmodells ergänzende Konstrukte sind: - TMF System and Information Map Framework - Business Entities und Attribute - UML Class Models für jede Business Entity Die Systems and Information Map (SIM) ist ein Framework, das eine Anzahl von Domains enthält sowie ihre Aufteilung in Business Entities. Die Domains innerhalb der SIM werden in Anwendungsfallspezifische Bereiche gruppiert. Diese Bereiche decken z.B. Kunden, Produkte, Services und Equipment Domains ab und enthalten die Daten und Funktionen, die relevant sind. Das Domain Konzept gruppiert die korporativen Daten eines CSP’s durch Affinitätsanalyse in ein Information Framework. Die Daten und die Funktionen, die auf diese Daten operieren, werden an diese Domain gebunden. Daraus ergibt sich ein hoher Grad an Zusammenhang innerhalb der Domain und eine lose Koppelung zwischen unterschiedlichen Domains. Dies wiederum ermöglicht die Segmentierung von Business Problemen und erlaubt, dass Ressourcen auf ein bestimmtes Gebiet gerichtet werden können. Die Business Entities und die Attribute, die die Entity weiter beschreiben, liefern eine Sicht (view) des Modells, das leicht von der Business Perspektive verstanden wird. Sie bilden die Grundlage des Modells und werden zusammen mit weiteren Details in den UML Klassenmodellen dargestellt. Die UML Klassenmodelle liefern eine Software-System-Architekturorientiertes Business Sicht der Business Entitäten, ihrer Attribute und Relationen zu anderen Business Entitäten. UML Design orientierte Klassenmodelle und Sequenzdiagramme liefern die zugehörige Systemsicht. 5.2 OSS/J Inventory API und Core Business Entities (CBE) Eine generelle Anforderung und ein Basisbaustein des integrierten Service Managements ist die Modellierung von Diensten inklusive der Inventarisierung. Die den Kunden angebotenen Produkte sind typischerweise aus elementaren technischen Diensten aufgebaut, die mit Hilfe von Infrastrukturelementen geliefert werden. Beispiele sind mobile Netzwerkdienste wie GSM, GPRS, UMTS und Serverbasierte Dienste wie VoIP oder WAP, SMS, MMS in der mobilen Kommunikationslandschaft. Diese Basisdienste werden konfiguriert, mit Qualitätsmerkmalen erweitert und gebündelt, um den Anforderungen der jeweiligen Kundensegmente (Privatkunden, Geschäftskunden, etc.) oder einzelnen Kunden (typischerweise Unternehmenskunden) mit ihren spezifischen DienstgüteErwartungen (Platin, Gold, Silber, etc.) gerecht zu werden. Die Informationen über die Kunden, die Produkte die sie jeweils nutzen, die Basisdienste aus denen diese Produkte aufgebaut werden und die Ressourcen, die von den Diensten belegt werden sind essentiell für viele verschiedene Business und Operations Support Bereiche. Produktmanagement, Customer Care (CRM), Service Provisioning, Billing und Service Management sind unter den wichtigsten Bereichen. Sie haben die Notwendigkeit, die dazugehörigen Inventarinformationen, die oft über eine Vielzahl heterogener B/OSS Systeme verteilt sind zu erstellen, zu lesen, zu Planning aktualisieren, zu löschen und abzufragen. Assurance Discovery Activation Billing Ein integrierter Service Management Inventory API Integrierte Inventory Abbildung 4: Typisches Produkt, Service, Ressource Inventory Akteure Systemansatz muss das Navigieren durch das Inventar für eine von oben nach unten (Teilnehmer - Produkt – Service – Ressource) und eine von unten nach oben geführte Analyse mit Fragen zu Produkt/Service oder Ressource unterstützen. Die OSS/J Inventory API bietet diese entscheidenden Methoden, um Operationen nach unten in Richtung Netzwerk genauso wie nach oben zu den Kundenzugewandten Systemen zu unterstützen. Bild 4 zeigt die typischen Akteure, die auf die betreffenden Inventardaten zugreifen. OSS/J Inventory API Die Inventory API bietet Schnittstellen für folgende Operationen: - Erstellung, Entfernung, Aktualisierung und Abfrage von Inventory Entities, EntitySpezifikationen und -Assoziationen - Durchführung von Metadatenabfragen - Empfang von Inventarereignissen mittels Benachrichtigungen - Überwachung der Ressourcenauslastung - Import und Export von Inventardaten Diese Grundoperationen ermöglichen Client Interaktionen zur Anfrage. Zuweisung, Product Inventory Service Inventory Nutzer Resource Inventory Reservierung, Überwachung und Abonnent Besitzer Produkt Spezifikation Produkt Aktualisierung von allen Ressourcen, Diensten und Produkten im Inventar. Service Service Spezifikation Spezifikation Service Spezifikationen und Assoziationen sind in Service Ressource Spezifik. Ressource Spezifik. Ressource Beispiele der Inventory Entities, Ressource Ressource den Core Models jeder Inventarfunktion im nebenstehenden Diagramm dargestellt. Ressource (siehe Bild 5). Abbildung 5:OSS/J Inventory API Objekt Modell Das System für die Modellierung der Inventardaten basiert auf einer dreischichtigen Architektur wie in Bild 6 abgebildet. Der bevorzugte Weg, das Model zu erweitern ist Meta Modell Ebene Entity EntitySpezifikation Association eine Implementierungsvererbung der Core Model Entities, Spezifikationen oder Modell Ebene Service Ressource Produkt Assoziationen. Als Ergebnis lassen sich die Charakteristika jeder komplexen Entity (z.B. Beispiel Ebene Produktbündelungen, die mehrere Produkte beinhalten oder eine Produkthierarchie) durch Ressource 1 Ressource 2 Abbildung 6: Meta Modell Konzepte Ressource 3 Entities definieren, die in Assoziationen mit anderen Entities stehen. Das Inventory Metamodel erweitert hierbei das Unified Modeling Language (UML) Vokabular. 5.3 Service-Modellierung als Grundbaustein des Integrierten Service Managements Das erweiterbare Objektmodell der OSS/J Inventory API kann implementiert werden, um den typischen Objektmodell-Anforderungen von Service Quality Management Lösungen zu genügen. In einem derartigen Szenario ist es ratsam, separate Datenmodelle und Schnittstellenimplementierungen für Service Quality Management und Inventory Management Aspekte zu nutzen. Eine Implementierung basierend auf der OSS/J Common API Spezifikation (solange die OSS/J SQM API Spezifikation noch nicht vollständig definiert ist) wird genutzt, um sowohl das Service Quality Management Model als auch die Service Quality Management Schnittstellen zu realisieren. Bild 7 zeigt auf einer hohen Ebene den GUI GUI vorgeschlagen Ansatz. Die grafische OSS/J Inventory API OSS/J allg. API Benutzerschnittstelle (GUI) muss entsprechend den unterschiedlichen Rollen Produkt SLA und funktionalen Anforderungen Service Ressource SLO KPI Abbildung 7: Anwendung der Inventory API für SQM implementiert werden. Das TMF SID sollte die Basis für das SQM Object Model und seine Assoziationen zum Inventory Model bilden. Die Nutzung der OSS/J Common API Spezifikation sichert die effiziente Migration zur geplanten OSS/J SQM API. 6. Weitere OSS/J APIs für Integriertes Service Management 6.1 OSS/J Trouble Ticketing API (TT) Die OSS/J Trouble Ticketing API bietet entsprechend den OSS/J Design Guidelines definierte Schnittstellen für die Erstellung, Verfolgung und Löschung von Trouble Tickets. Die TT API empfängt Trouble Ticket Informationen entweder von Kunden-, Service- oder Netzwerk Management Applikationen wie Service Impact Analysis, Root-Cause Alarm Analysis und Fault Monitoring. Dies ermöglicht die Verfolgung des Problems bis zur Auflösung sowie eine Benachrichtigung von Clients, wenn das Problem gelöst und das Trouble Ticket als erledigt eingestuft wurde. Die OSS/J TT API bietet Schnittstellen, die den Clients folgende Funktionen erlauben: - Erzeugung, Entfernung und Annullierung von Trouble Tickets - Änderung von Trouble Ticket Werten - Information bzgl. Trouble Ticket Änderungen mittels Benachrichtigungen 6.2 OSS/J Quality of Service API (QOS) OSS/J QoS Fault Monitoring API (QOS-FM) Die OSS/J Fault Monitoring API ist Teil der QOS API bietet Schnittstellen gemäß OSS/J Design Guidelines, um Clients die Sammlung und Quittierung von Alarmen zu ermöglichen. Die API ermöglicht den Empfang von Alarmen, Schwellwertalarmen und Statusänderungen vom Netzwerk sowie eine Pflege der Liste aktiver Alarme. Sie sichert damit auch den aktuellen Überblick über den Alarmzustand des gesamten Netzwerkes. Die OSS/J FM API unterstützt Schnittstellen, die Clients folgende Funktionen gewährt: - Alarme in einer Alarmliste quittieren oder nicht zu bestätigen - Abfrage einer Alarmliste - Abfrage der Alarmzähler einer Alarmliste - Empfang von Benachrichtigungen bzgl. neuer, veränderter und aufgehobener Alarme, Alarm ACK Statusänderungen sowie Ereignismeldungen für den Neuaufbau von Alarmlisten. OSS/J QoS Performance Monitoring API (QOS-PM) Die OSS/J Performance Monitoring API ist Teil der OSS/J QoS API und bietet Schnittstellen gemäß OSS/J Design Guidelines für die Erstellung und das Löschen von metrischen und Schwellwert-Objekten. Die API unterstützt die Sammlung von Performance-Daten vom Netzwerk, das Setzen von Schwellwerten sowie die Generierung/Weiterleitung von Ereignismeldungen bei einer Schwellwertüberschreitung. Daten können direkt von Systemeinheiten gesammelt werden (z.B. ein MIB Wert) oder eine Kombination von metrischen Werten sein, die zur Kalkulation von sinnvollen Daten zum Leistungsverhalten benutzt werden. Das gleiche Prinzip wird für die Schwellwerte angewendet. Das Performance Monitoring kann so konfiguriert werden, dass Gesamtschwellwerte aus Einzelschwellwerten erzeugt werden. 6.3 OSS/J Service Quality Management API (SQM) Die OSS/J Service Quality Management API (noch in der Spezifikationsphase innerhalb JCP) bietet Schnittstellen gemäß OSS/J Design Guidelines für die Abfrage, das Erstellen, Aktualisieren und Löschen von Service Level Specifications Objects, Service Quality Objective Objects, and Service Quality Report Objects. Weiterhin können Benachrichtigung zu Object Violation Events und Verfügbarkeit neuer Dienstgüteberichte abonniert werden. Die OSS/J SQM API erlaubt die Definition und Berechnung von dienstbezogenen Qualitätszielen gegenüber vordefinierten Metriken/Kennzahlen. Sie ermöglicht eine Korrelierung der Service Instance Informationen, der Service Alarme von Service Impact Analysis sowie den Netzwerk Performance Metriken vom Performance Monitoring. Damit können Verfügbarkeit und Qualitätskennzahlen beurteilt werden sowie dienstorientiert Ereignismeldungen bei Schwellwertüberschreitungen erzeugt werden. Dienstgütemessungen und Traffic Conditioning Agreements (Bandbreiten Management) sind verfügbar durch die API und werden vom Customer Service Level Agreement (SLA) Management verarbeitet, um SLA Verletzungen festzustellen. 7. Vorteile und Nutzen des OSS/J-Ansatzes als Service-orientierte Architektur Der wesentliche Nutzen in der Anwendung der OSS/J Technologie als komponentenbasierter Ansatz liegt in den folgenden Punkten: - Investionsschutz – eine größere Nutzung der existierenden B/OSS Anwendungen ist möglich. Es besteht keine Notwendigkeit für einen Systemaustausch - Schrittweise Umsetzung – Projekte lassen sich individuell rechtfertigen und liefern dennoch einen Beitrag zu einem übergeordneten, strategischen Integrationsansatz. - Der Integrationsaufwand kann aufgrund der Wiederverwendbarkeit von Komponenten und reduzierter Komplexität um bis zu 60 - 70% reduziert werden (nach [15]) - Keine Notwendigkeit für ein umfassendes proprietäres ‘Common Data Model’ für die Integration unterschiedlicher B/OSS Systems in verschiedenen Ländern. Statt dessen hilft ein standardisiertes Datenmodell in Kombination mit funktionaler Aufteilung die gewaltigen Anlaufkosten eines Projektes zu vermeiden - Time to market: Neue 3rd Party Applikationen (sobald die B/OSS Systeme OSS/J kompatibel sind) können innerhalb von “Tagen und Wochen” statt in “Monaten und Jahren”. Eine Reduzierung von Time to Market bis zu 30% ist möglich (laut [15]). 8. Integriertes Service Management mit OSS/J in der Praxis Ein globales Mobilfunkunternehmen hat sich für den Einsatz von OSS/J entschieden. Es setzt fortgeschrittene, verteilte, heterogene Informations- und Kommunikationstechnologien sowie Multi-vendor OSS Applikationen in seinem komplexen kunden- und diensteorientierten NM/SM Bereich ein. Um in diesem Bereich den Herausforderungen durch wachsende Märkte, permanent wechselnde Dienste und OSS Technologien gerecht zu werden, hat das Mobilfunkunternehmen ein Projekt initiiert, dass dessen NM/SM IT Architekturplan neu zeichnet, um einen kosteneffektiven Ansatz für eine geschäftorientierte, integrierte NM/SM Lösung zu erreichen Wesentliche Zielsetzungen dieser Initiative sind die Reduzierung der hohen Integrationskosten für existierende und neue Applikationen sowie der Einsatz wieder verwendbarer NM/SM Applikationen, Bausteine und standardisierter Schnittstellen. Damit sollen letztendlich rasch einsetzbare NM/SM Services aufgebaut werden. Vor dem Start der Implementierungsarbeiten verglich das Mobilfunkunternehmen einen traditionellen EAI-Ansatz mit dem neuen OSS/J-basierten Ansatz. Das Ergebnis war viel versprechend und das Unternehmen entschied sich, den inhärenten Nutzen einer OSS/J-basierenden Architektur zu überprüfen Dies erfolgte durch die Implementierung eines Proof of Concept (PoC) Szenarios für die Trouble Ticketing Management und Service Monitoring Systeme. Involvierte OSS waren NETeXPERT Module des Herstellers Agilent Technologies als Service-monitoring System sowie ein Remedy’s ARS™ basierendes TT System. Das Service-monitoring System sammelt Daten von verschiedenen Element Management und Probing Systemen und initiiert eine TT Erstellung. Dabei wird das Alarm Management des Service-monitoring Systems als TT Client genutzt. Die beiden Systeme wurden mittels einer Implementierung der OSS/J TT API und den dazugehörigen Adaptern verbunden. Der PoC deckt die verschiedenen Interaktionsszenarios zwischen den bestehenden OSS Systemen ab. Dies sind beispielsweise die Behandlung bei Verbindungsverlust während dem Senden von TT, die Ergänzung herstellerspezifischer Attributen zu TT und das Senden von TT über OSS Systeme und andere Systeme. Der PoC demonstrierte erfolgreich den Einsatz offener, standardisierter Schnittstellen zwischen unterschiedlichen OSS Anwendungen verschiedener Hersteller sowie die Fähigkeit der OSS/J Architektur eine “point to multi-point” Integrationslösung zu bieten. Zwischenzeitlich wurde der PoC in Betrieb genommen und läuft seit Frühjahr 2004 sehr erfolgreich in operativer Umgebung. Gleichzeitig wurden weitere OSS auf Basis OSS/J integriert. Allgemein waren die technischen Fähigkeiten und kommerziellen Vorteile der im PoC gezeigten OSS/J Systemintegration so überzeugend, dass das Mobilfunkunternehmen sich entschieden hat, diesen Ansatz zum Aufbau einer integrierten Service Management Architektur weiter zu verfolgen und diesen auch weltweit bei anderen internationalen Tochtergesellschaften einzusetzen. 9. Zusammenfassung und Ausblick Der Aufbau einer Service-orientierten Architektur für die Telekommunikationsindustrie auf Basis der NGOSS-Spezifikationen sowie unter Verwendung der OSS/J Implementierungsgrundsätze wurde erfolgreich bei einem globalen Mobilfunkunternehmen durchgeführt. Neben dem Nachweis der Praxistauglichkeit war eine weitere Erkenntnis, dass der Nachweis der OSS/JKonformität im Rahmen der Entwicklung und Bereitstellung von B/OSS Systemen der nächsten Generation für führende CSPs ein Schlüsselfaktor bei der Anbieterauswahl ist. Zur stärkeren Einbeziehung der CSPs hat die OSS/J Initiative das Service Provider Advisory Council gegründet, das dem Austausch von Geschäfts- und Betriebserfahrungen dient. Das Service Provider Advisory Council ist ein offenes Gremium, dass Service Providern einen Einfluss auf Steuerung und Strategieentwicklung der OSS/J Initiative ermöglicht. Ziel ist es, die Akzeptanz der OSS/J Technologie durch die Telekommunikationsindustrie zu beschleunigen und damit die Einführung von komponenten-basierten, Service-orientierten Architekturen zu forcieren.. 10. Literaturhinweise [1] TeleManagement Forum: The NGOSSTM Architecture Solution Suite, TMF053, Version 8.0 (Member Evaluation), January 2006 [2] TeleManagement Forum: Shared Information/Data (SID) Model, GB922, Version 6.3 (Member Evaluation), January 2006 [3] TeleManagement Forum: Enhanced Telecom Operations MapTM (eTOM), GB921, Version 6.0, January 2006 [4] OSS through JavaTM Initiative: Core Business Entities Model Interfaces, Version 2.1 final, May 2004 [5] Fleck, J.J.: Overview of the Structure of the NGOSS Architecture, HewlettPackard Company, May 2003 [6] OSS through JavaTM Initiative: OSS through Java as an Implementation of NGOSS - A White Paper, Version 1.0, April 2004 [7] OSS through JavaTM Initiative: OSS through Java J2EE Design Guidelines, Version 1.1, October 2001 [8] Java Specification Request 144: OSS Common API, Final Release, April 2002 [9] Java Specification Request 89: OSS Service Activation API, Final Release, April 2002 [10] Java Specification Request 90: OSS Quality of Service API, Final Release, November 2002 [11] Java Specification Request 91: OSS Trouble Ticket API, Final Release, February 2002 [12] Java Specification Request 130: OSS Billing Mediation API, Final Release 2, Febr. 2004 [13] Java Specification Request 142: OSS Inventory API, Final Release, March 2005 [14] Java Specification Request 210: OSS Service Quality Management API, Early Draft Review, August 2004 [15] Enrico Benni, Klemens Hjartar, and Jürgen Laartz: “The IT factor in mobile services”, The McKinsey Quarterly, 2003 Number 3 Autoren Roland Volk (Dipl.-Inform. (FH)) Geschäftsführer Email: [email protected] Hubert Blankenberg (Dipl.-Math.) Head of Professional Services Emails: [email protected] Ekhard Konrath (Dipl.-Inform.) Senior Telco Consultant Email: [email protected] IP VALUE GmbH Stockholmer Allee 24 D-44269 Dortmund Telefon: (02 31) 4 76 42 – 0 Fax: (02 31) 4 76 42 – 5 54 Email: [email protected] Internet: http://www.ip-value.de Glossar API Application Programming Interface B2B Business-to-Business BSS Business Support System CBE Core Business Entities CRM Customer Relationship Management CRUD&Q Create, Read, Update, Delete & Query CSP Communication Service Provider DG OSS/J Design Guidelines EAI Enterprise Application Integration ebXML electronic business XML EJB Enterprise Java Bean FM Fault Monitoring eTOM Enhanced Telecom Operations MapTM GPRS General Packet Radio Services GSM Global System for Mobile Communications GUI Graphical User Interface IIOP Internet Inter-Orb Protocol IP Internet Protocol IPDR Internet Protocol Detail Record ISM Integrated Service Management IT Information Technology ITU International Telecommunication Union J2EE™ Java™ 2 Platform, Enterprise Edition JCP Java Community ProcessSM JMS Java Messaging Service JSR Java Specification Request KQI Key Quality Indicators MOM Message-oriented Middleware MMS Multimedia Messaging Service NE Network Element NGOSSTM New Generation Operation System and Software NM/SM Network Management/Service Management NMF Network Management Forum OSS Operation Support System OSS/J OSS through JavaTM Initiative PM Performance Monitoring PoC Proof of Concept QoS Quality of Service RI Reference Implementation RMI Java Remote Method Invocation SID Shared Information/Data Model SLA Service Level Agreement SMS Short Messaging Service SOA Service Oriented Architecture SQM Service Quality Management TCA Traffic Conditioning Agreement TCK Technology Compatibility Kit TMF TeleManagement Forum TT Trouble Ticket UM Usage Monitoring UML Unified Modeling Language UMTS Universal Mobile Telecommunications System VoIP Voice over Internet Protocol WAP Wireless Application Protocol XML Extensible Markup Language
