Java in der Telekommunikation - Telemangement Forum und OSS/J

Wie im ersten Beitrag dieser Serie versprochen, werden wir nun das Telemanagement Forum (TMF) und OSS/J näher beleuchten. Dieser Beitrag wird ein wenig theoretisch sein, aber ich verspreche, dass der nächste Beitrag praktischer sein wird ;-)

Das Telemanagement Forum ist eine Organisation, die sich mit ihrem Programm New Generation Operations Systems and Software (NGOSS) um die Verbesserung der Interoperabilität in der Branche der Kommunikationsdienstleister (CSP) bemüht. Zu den Mitgliedern des TMF gehören nicht nur die Telekommunikationsunternehmen, sondern auch Anbieter von Netzwerkausrüstung und Systemintegratoren. Sie alle leisten einen Beitrag zum NGOSS-Programm

NGOSS besteht aus:

• >Enhanced Telecom Operation Map (eTOM). Beschreibt die Geschäftsprozesse, die jeder CSP typischerweise hat, um sein Geschäft zu betreiben. Die Prozesse sind in Domänen gruppiert (Produkt, Kunde, Service, Ressourcen usw.), wie in der Abbildung rechts dargestellt. Wenn Sie einen CSP besuchen, werden Sie oft eine detailliertere Version dieses Modells als Hintergrundbild sehen.

• Gemeinsames Informations-/Datenmodell (SID) Stellt ein Informationsmodell bereit, das aus sogenannten Aggregate Business Entities (ABE) und den Beziehungen zwischen ihnen besteht. Die ABEs enthalten nicht alle relevanten Attribute, es ist ein abstraktes Modell. Obwohl es abstrakt ist, hat es sich als sehr nützlich erwiesen, um die Kommunikation zu erleichtern, und es wird als Grundlage für OSS/J verwendet. Das SID-Modell ist in Domänen (eTOM-Domänen) organisiert, wobei die Entitäten in einer Domäne ein hohes Maß an Kohäsion aufweisen und die Kopplung zwischen den Domänen lose ist.

• Technologieneutrale Architektur (TNA): Sie befindet sich noch in der Entwicklung, soll aber die strukturellen Grundlagen und Konstrukte zur Unterstützung der Analyse, des Designs, der Implementierung und des Einsatzes von NGOSS Open Distributed Computing-Lösungen beschreiben .

• NGOSS-Konformitätstest Eine Reihe von Tests zur Überprüfung der Konformität mit den NGOSS-Standards

Die Idee hinter der Anwendung von eTOM, SID und TNA ist natürlich, schlanke Unternehmen zu schaffen, die sich schnell an neue Marktbedingungen anpassen und ihren Kunden einen hervorragenden Mehrwert bieten können.

Sowohl eTOM als auch SID erleichtern die Kommunikation (sowohl von Mensch zu Mensch als auch von Maschine zu Maschine) durch die Definition eines gemeinsamen Vokabulars für die CSP-Branche. Wenn Sie beispielsweise mit Anbietern sprechen, können beide auf eTOM-Domänen oder SID-ABEs verweisen, um anzugeben, wonach sie suchen (CSP) und was ihre Produkte abdecken (Anbieter).

Ich persönlich habe das SID-Modell schon mehrmals für die Domänenmodellierung verwendet. Ursprünglich habe ich mit meinem eigenen Modell begonnen, das ich nach dem gesunden Menschenverstand erstellt habe. Dabei habe ich festgestellt, dass mein Modell weniger flexibel und weniger vollständig war als das SID-Modell. Deshalb beginne ich jetzt immer mit dem SID-Modell und prüfe, ob es Aspekte gibt, die weggelassen werden können oder hinzugefügt werden müssen, um die Geschäftsanforderungen zu erfüllen.

Die OSS/J APIs konzentrieren sich auf Operations Support Systems (OSS) wie Trouble Ticketing, Inventory Management und Order Management. Das Hauptziel der OSS/J APIs ist die Senkung der Integrationskosten, die mit der Integration von Operations Support Systems verbunden sind. Ursprünglich war die OSS/J-Community eine separate Organisation, aber seit Sommer 2006 ist sie ein integraler Bestandteil der TMF. Die TMF erklärte, dass OSS/J der bevorzugte Weg ist, um die in der SID der TMF dargelegten Konzepte umzusetzen. Seit dem Beginn der OSS/J-Initiative wurde der Java Community Process zur Entwicklung der Spezifikationen verwendet.

OSS/J lässt sich wie folgt zusammenfassen:

• Durch die Definition separater OSS/J-APIs pro eTOM-Domäne wird eTOM verwendet, um Funktionen in APIs zu gruppieren. Derzeit sind 12 OSS/J-APIs definiert. Beispiele sind Bestandsverwaltung, Auftragsverwaltung, Trouble Ticketing, Billing Mediation. Eine der APIs ist die Common API. Diese API bildet die Grundlage für die anderen APIs und definiert die Elemente, die in mehr als 1 API verwendet werden. Beispiele für diese Elemente sind die 'Meta'-Operationen, die von Clients verwendet werden, um die Fähigkeiten einer API-Implementierung zu ermitteln, und die verwalteten Entitäten (siehe nächster Punkt), die von mehreren APIs verwendet werden. Abgesehen von der Gemeinsamen API kann jede API unabhängig von den anderen APIs verwendet werden, in einigen Geschäftsszenarien ist es jedoch sinnvoll, mehrere APIs zu verwenden.

• Nimmt die Aggregate Business Entities aus SID, um die OSS/J Managed Entities und ihre Beziehungen zu definieren. Beispiele für Managed Entities sind Customer, Role, Service, OrderItem. Im Vergleich zu den ABEs in SID sind die Managed Entities eine konkretere Darstellung. Bei der Implementierung einer OSS/J-API ist jedoch in der Regel eine Erweiterung dieser Managed Entities erforderlich, und es gibt strenge Richtlinien (OSS/J Design Guidelines), in denen festgelegt ist, wie die Managed Entities erweitert werden dürfen, um die Interoperabilität zu gewährleisten. Die Integrationskosten werden reduziert, da alle OSS/J-APIs ihre Managed Entities auf den SID-ABEs basieren und die Common API die Managed Entities definiert, die von mehreren OSS/J-APIs gemeinsam genutzt werden. Ein Beispiel: Ein Auftragsverwaltungsserver muss in der Regel mit einem Bestandsverwaltungssystem integriert werden, um den Bestand bei der Bearbeitung von Aufträgen abzufragen oder zu aktualisieren. Da sie dieselben (Basis-)Definitionen für ihre Managed Entities verwenden, ist diese Integration problemlos.

• Bietet 3 Integrationsprofile:

  • EJB: Enge Kopplung und Bindung an Java.

  • XML/JMS: Weniger eng gekoppelt, asynchron und kann mit anderen Sprachen verwendet werden.

  • WebServices: Lose gekoppelt und kann mit anderen Sprachen verwendet werden.

    Alle OSS/J APIs bieten dieselbe Funktionalität über die 3 Integrationsprofile. Sie können das Integrationsprofil auswählen, das Ihren Anforderungen am besten entspricht.

• Definiert die Interaktionsmuster. Im Wesentlichen gibt es zwei Hauptmuster:

  • Anfrage - Antwort (oder Ausnahme im Falle von Fehlern): synchron (oder asynchron im Falle des JMS-Integrationsprofils)

  • Ereignisse: Asynchron, wird verwendet, um Abonnenten über stattgefundene Aktionen zu informieren (z.B.: Bestellstatus geändert)

Zusätzlich zu diesen grundlegenden Mustern definiert jede OSS/J API, wie und in welcher Reihenfolge die in der API definierten Operationen verwendet werden sollten.

• Für jede API ist ein fester Satz von Operationen definiert. Diese Operationen werden zur Verwaltung und Abfrage der von der API verwendeten Managed Entities verwendet. Fest bedeutet, dass es nicht möglich ist, neue Operationen hinzuzufügen (im Gegensatz zur Erweiterung der Managed Entities, die erlaubt ist und oft benötigt wird). Es ist möglich, so genannte benannte Abfragen zu definieren, so dass Sie bei Bedarf spezifische Abfragen definieren können. APIs enthalten in der Regel bereits mehrere benannte Abfragen als Teil der API-Definition.

Klingt kompliziert? Nun, um ehrlich zu sein, ist die Lernkurve für die erste OSS/J-API, mit der Sie arbeiten, ein wenig steil. Sobald Sie jedoch eine kennen, sind die anderen ziemlich einfach und die anfänglichen Bemühungen beginnen sich auszuzahlen.

Die Nachfrage nach Produkten, die den OSS/J-Spezifikationen entsprechen, steigt. Dies veranlasst natürlich die Hersteller, ihre Produkte OSS/J-konform zu machen (siehe zertifizierte Produkte) und schafft auch einen Markt für Unternehmen, die Adapter bauen, die eine OSS/J-konforme Schnittstelle für nicht-konforme Produkte bieten können.

Der nächste Beitrag wird sich mit der Order Management API befassen. Dies ist die API, die Gegenstand der JavaOne und TelemanagementWorld-Sitzungen im Mai ist.