Implementierung einer Service-orientierten Architektur für die Telekommunikationsindustrie am Beispiel Integriertes Service Management

Transkript

1 Implementierung einer -orientierten Architektur für die Telekommunikationsindustrie am Beispiel Integriertes Management Roland Volk Hubert Blankenberg Ekhard Konrath IP VALUE GmbH, Dortmund Zusammenfassung Das integrierte Management ist eine zwingend erforderliche Voraussetzung für Communication 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 Management Lösung voranzutreiben. Dieses Papier diskutiert die technologischen Aspekte eines kombinierten NGOSS-OSS/J Ansatzes. Stichworte B/OSS, etom, Integration, NGOSS, OSS/J, Management, SID, SoA, Web 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

2 B/OSS, etom, Integration, NGOSS, OSS/J, Management, SID, SoA, Web 1. Einführung Communication 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 Management (ISM) der Schlüssel für die Bereitstellung, Aktivierung und den Betrieb konkurrenzfähiger Dienste wie z.b. IP- Telefonie (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 orientierte B/OSS Architekturen folgt. Eine orientierte 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

3 jeweils zugehörigen Aufgaben: - Fulfillment (Management der Auftragseingabe, schnelle Modifizierung von Diensten, rasche Dienstaktivierung und Lieferung, Verfolgung und Management des Inventars) - Assurance (Sicherstellung der Dienstverfügbarkeit, Überwachung des Leistungsverhaltens, Minimierung von Reparaturzeiten, Management von Dienstgütevereinbarungen) - 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 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 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.

4 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 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 -orientierte Architektur Der derzeitige Industrietrend in Richtung einer Komponentenbasierten, orientierten Architektur wird unterstützt durch die jüngsten Fortschritte im Bereich der

5 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 s, 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 s zur Unterstützung von Interaktionsmustern zwischen Komponenten (Naming, Repositories, Registration s, Location s). 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

6 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 s 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 Java TM 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 Process sm (JCP) Programm standardisiert. JCP liefert als Ergebnis für jeden Anwendungsbereich eine Spezifikation, eine Referenzimplementierung (RI) und einen Technology Compatibility Kit (TCK).

7 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 s 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

8 - Sicherheitsmechanismen und -grundsätze ISO Grundsätze (Policy) - Business-Prozesse (Business Process (etom)) - OSS-Applikationen - OSS-Framework-Dienste (OSS Framework s) - Grundlegende Framework-Dienste (Basic Framework s) - 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: - Activation API [9]: Behandelt jede Art von Auftrag und Dienst - Quality of 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,, Ressource) Die für ein integriertes Management relevanten APIs werden inklusive der vorläufigen Quality Management API [14] detaillierter im Abschnitt 5

9 diskutiert. Bild 1 zeigt wie die OSS/J Core APIs den TMF etom Prozessen zugeordnet sind. Sales Customer Interface Management Prozess Order Handling Customer Care - Prozesse Planning Develop. Config. Problem Handling Problem Resolution Customer OoS Mgmt Quality Mgmt Development und Operation - Prozesse Network Planning Develop. Network Provision. Network Inventory Mgmt OSS/J SQM API Network Maintnce. Restoration Network und Systems Management - Prozesse Element Management / Physical Network Invoicing/ Collection Rating & Discount. Network Data Mgmt OSS/J Activation API OSS/J Quality of API OSS/J Trouble Ticket API OSS/ Billing Mediation API OSS/J Inventory API 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. Client Anwendung OSS-A (COTS/legacy) OSS-A Adapter OSS/J Schnittstelle Attribute Mapping OSS-A OSS/J J2EE OSS/J API Implementierung In Unkenntnis über OSS-A & -B, Daten und OSS-B Adapter Attribute Mapping OSS/J OSS-B Adapter benötigt nur geringes Wissen über OSS/J API Server Anwendung OSS-A & -B wissen nichts von der jeweils anderen Schnittstelle Abbildung 2: Allgemeine OSS/J Komponenten Architektur OSS-B (COTS/legacy) Die entsprechenden OSS/J API- Komponenten bieten allgemeingültige, funktionale Geschäftsobjekte und Methoden, die von globalen, industriespezifischen Fokusgruppen vereinbart wurden. Die 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

10 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. eng gekoppelte Integration Java EJB RMI IIOP J2EE, XML und Web s OSS/J lose gekoppelte Integration XML JMS B2B Integration XML Web s Während die OSS/J APIs einerseits CSPspezifische Semantik beschreiben und implementieren, müssen sie andererseits auch passende Kommunikations- Mechanismen für unterschiedliche 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 s 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 s 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

11 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-facto- Standard 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

12 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, s 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.

13 5.2 OSS/J Inventory API und Core Business Entities (CBE) Eine generelle Anforderung und ein Basisbaustein des integrierten 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üte- Erwartungen (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), Provisioning, Billing und Management sind unter den wichtigsten Bereichen. Sie haben die Notwendigkeit, die dazugehörigen Inventarinformationen, die oft über eine Vielzahl heterogener B/OSS Systeme Planning Assurance Discovery verteilt sind zu erstellen, zu lesen, zu aktualisieren, zu löschen und abzufragen. Activation Inventory API Integrierte Inventory Billing Abbildung 4: Typisches Produkt,, Ressource Inventory Akteure Ein integrierter Management Systemansatz muss das Navigieren durch das Inventar für eine von oben nach unten (Teilnehmer - Produkt Ressource) und eine von unten nach oben geführte Analyse mit Fragen zu Produkt/ 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

14 Die Inventory API bietet Schnittstellen für folgende Operationen: - Erstellung, Entfernung, Aktualisierung und Abfrage von Inventory Entities, Entity- Spezifikationen 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 Inventory Resource Inventory Abonnent Nutzer Besitzer Produkt Abbildung 5:OSS/J Inventory API Objekt Modell Produkt Spezifikation Spezifikation Spezifikation Ressource Spezifik. Ressource Spezifik. Ressource Ressource Ressource Ressource Reservierung, Überwachung und Aktualisierung von allen Ressourcen, Diensten und Produkten im Inventar. Beispiele der Inventory Entities, Spezifikationen und Assoziationen sind in den Core Models jeder Inventarfunktion im nebenstehenden Diagramm dargestellt. (siehe Bild 5). 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 Modell Ebene Produkt Ressource Beispiel Ebene Ressource 1 Ressource 2 Ressource 3 Abbildung 6: Meta Modell Konzepte eine Implementierungsvererbung der Core Model Entities, Spezifikationen oder Assoziationen. Als Ergebnis lassen sich die Charakteristika jeder komplexen Entity (z.b. Produktbündelungen, die mehrere Produkte beinhalten oder eine Produkthierarchie) durch Entities definieren, die in Assoziationen mit anderen Entities stehen. Das Inventory Metamodel erweitert hierbei das Unified Modeling Language (UML) Vokabular Modellierung als Grundbaustein des Integrierten Managements Das erweiterbare Objektmodell der OSS/J Inventory API kann implementiert werden, um den typischen Objektmodell-Anforderungen von Quality Management

15 Lösungen zu genügen. In einem derartigen Szenario ist es ratsam, separate Datenmodelle und Schnittstellenimplementierungen für 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 Quality Management Model als auch die Quality Management Schnittstellen zu realisieren. GUI GUI OSS/J Inventory API OSS/J allg. API Produkt SLA SLO Ressource KPI Abbildung 7: Anwendung der Inventory API für SQM Bild 7 zeigt auf einer hohen Ebene den vorgeschlagen Ansatz. Die grafische Benutzerschnittstelle (GUI) muss entsprechend den unterschiedlichen Rollen und funktionalen Anforderungen 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 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-, - oder Netzwerk Management Applikationen wie 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

16 6.2 OSS/J Quality of 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 Quality Management API (SQM) Die OSS/J Quality Management API (noch in der Spezifikationsphase

17 innerhalb JCP) bietet Schnittstellen gemäß OSS/J Design Guidelines für die Abfrage, das Erstellen, Aktualisieren und Löschen von Level Specifications Objects, Quality Objective Objects, and 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 Instance Informationen, der Alarme von 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 Level Agreement (SLA) Management verarbeitet, um SLA Verletzungen festzustellen. 7. Vorteile und Nutzen des OSS/J-Ansatzes als -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]).

18 8. Integriertes 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 s 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 Monitoring Systeme. Involvierte OSS waren NETeXPERT Module des Herstellers Agilent Technologies als -monitoring System sowie ein Remedy s ARS basierendes TT System. Das -monitoring System sammelt Daten von verschiedenen Element Management und Probing Systemen und initiiert eine TT Erstellung. Dabei wird das Alarm Management des -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

19 ü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 Management Architektur weiter zu verfolgen und diesen auch weltweit bei anderen internationalen Tochtergesellschaften einzusetzen. 9. Zusammenfassung und Ausblick Der Aufbau einer -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/J- Konformitä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 Provider Advisory Council gegründet, das dem Austausch von Geschäfts- und Betriebserfahrungen dient. Das Provider Advisory Council ist ein offenes Gremium, dass 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, -orientierten Architekturen zu forcieren..

20 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, Hewlett- Packard 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 Activation API, Final Release, April 2002 [10] Java Specification Request 90: OSS Quality of 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 [13] Java Specification Request 142: OSS Inventory API, Final Release, March 2005 [14] Java Specification Request 210: OSS 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 Roland.Volk@ip-value.de

21 Hubert Blankenberg (Dipl.-Math.) Head of Professional s s: Hubert.Blankenberg@ip-value.de Ekhard Konrath (Dipl.-Inform.) Senior Telco Consultant Ekhard.Konrath@ip-value.de IP VALUE GmbH Stockholmer Allee 24 D Dortmund Telefon: (02 31) Fax: (02 31) info@ip-value.de Internet: Glossar API B2B BSS CBE CRM CRUD&Q CSP DG EAI ebxml EJB FM etom GPRS GSM GUI Application Programming Interface Business-to-Business Business Support System Core Business Entities Customer Relationship Management Create, Read, Update, Delete & Query Communication Provider OSS/J Design Guidelines Enterprise Application Integration electronic business XML Enterprise Java Bean Fault Monitoring Enhanced Telecom Operations Map TM General Packet Radio s Global System for Mobile Communications Graphical User Interface

22 IIOP IP IPDR ISM IT ITU J2EE JCP JMS JSR KQI MOM MMS NE NGOSS TM NM/SM NMF OSS OSS/J PM PoC QoS RI RMI SID SLA SMS SOA SQM TCA TCK TMF TT UM Internet Inter-Orb Protocol Internet Protocol Internet Protocol Detail Record Integrated Management Information Technology International Telecommunication Union Java 2 Platform, Enterprise Edition Java Community Process SM Java Messaging Java Specification Request Key Quality Indicators Message-oriented Middleware Multimedia Messaging Network Element New Generation Operation System and Software Network Management/ Management Network Management Forum Operation Support System OSS through Java TM Initiative Performance Monitoring Proof of Concept Quality of Reference Implementation Java Remote Method Invocation Shared Information/Data Model Level Agreement Short Messaging Oriented Architecture Quality Management Traffic Conditioning Agreement Technology Compatibility Kit TeleManagement Forum Trouble Ticket Usage Monitoring

23 UML UMTS VoIP WAP XML Unified Modeling Language Universal Mobile Telecommunications System Voice over Internet Protocol Wireless Application Protocol Extensible Markup Language