DE102004035498A1

DE102004035498A1 - Telekommunikationsdienstprogramm

Info

Publication number: DE102004035498A1
Application number: DE102004035498A
Authority: DE
Inventors: James H. Lake Kiowa VanGilder
Original assignee: Hewlett Packard Development Co LP
Current assignee: Hewlett Packard Development Co LP
Priority date: 2003-10-30
Filing date: 2004-07-22
Publication date: 2005-06-02
Also published as: CN1612582A; US20050097512A1

Abstract

Ein Verfahren zum Entwickeln eines Telekommunikationsdienstprogramms unter Verwendung einer Mehrzahl dienstunabhängiger Bausteine umfasst ein Entwickeln zumindest eines Dienstlogikteilroutinengraphen unter Verwendung einer Graphikschnittstelle. Jeder Teilroutinengraph wird in einen Dienstgraphen eingefügt und wie erforderlich mit weiteren Teilroutinengraphen und/oder dienstunabhängigen Bausteinen in dem Dienstgraphen verbunden, um einen Dienstgraphen zu bilden, der einen Gesamtdienstlogikprozess aufweist. Jedem Teilroutinengraph kann ein Icon zugewiesen sein, wobei das Icon in den Dienstgraphen eingefügt und wie erforderlich mit weiteren Teilroutine-Icons und/oder dienstunabhängigen Bausteinen verbunden wird.

Description

Die vorliegende Erfindung bezieht sich allgemein auf Telekommunikationsnetze und insbesondere auf eine Software zum Bereitstellen erwünschter Dienste auf derartigen Netzen.

Moderne Telekommunikationsnetze bieten Telefonbenutzern unzählig viele Merkmale zusätzlich zu einer Durchführung ihrer primären Funktion eines Platzierens von Anrufen zwischen Benutzern. Merkmale, wie z. B. Anklopfen, Anruferidentifizierung und Anruferrückruf, sind heute Standardmerkmale, die durch die meisten Telefondienstanbieter angeboten werden, und so müssen die Telekommunikationsnetze dieser Dienstanbieter konfiguriert sein, um diese und weitere Merkmale, wie z. B. Handhaben von Anrufen von drahtlosen Benutzern, zu unterstützen.

1 ist ein Funktionsblockdiagramm eines herkömmlichen Telekommunikationsnetzes 100, das einen globalen Telekommunikationsstandard verwendet, der als „SS7" bekannt ist, was für „Zentralkanal-Signalisierungssystem Nr. 7" steht. Der SS7-Standard definiert Protokolle zum Definieren, wie Netzelemente in dem öffentlichen Fernsprechnetz (PSTN) über digitale Kommunikationsnetze kommunizieren, um einen Anrufaufbau, eine -führung und eine -steuerung verdrahtet und drahtlos bereitzustellen. Das PSTN ist das internationale Telefonsystem, das Kupferdrähte und analoge Signale verwendet, um Sprachdaten darzustellen und Anrufe zwischen Benutzern zu platzieren, und der durch dieses System bereitgestellte Telefondienst ist als herkömmlicher Telefondienst (POTS) bekannt. So verwendet das Netz 100 Netzelemente des PSTN zusätzlich zu Digitalkommunikationsnetzen, um Anrufe zu platzieren und verschiedene hchentwickelte Merkmale für Benutzer bereitzustellen.

Das Netz 100 umfasst Dienstschaltpunkte (SSPs) 102 und 104, die arbeiten, um als Ursprung oder Abschluss von Anrufen zwischen Benutzern zu dienen, die durch Telefone 106, 108 dargestellt sind. Jeder SSP 102 und 104 kommuniziert SS7-Signalisierungsnachrichten gemäß dem SS7-Standard an andere SSPs in dem Netz 100, um Sprechschaltungen in dem PSTN einzurichten, zu verwalten und freizugeben, die zum Abschluss eines Anrufs benötigt werden. Das Netz 100 umfasst ferner Signalübertragungspunkte (STPs) 110, 112, die SS7-Signalisierungsnachrichten basierend auf Führungsinformationen, die in der Nachricht enthalten sind, an einen geeigneten Punkt in dem Netz 100 führen. Auf diese Weise fungiert jeder STP 110, 112 als eine Netz-Zentralstation bzw. einen -Hub und beseitigt dadurch den Bedarf nach direkten Verbindungen zwischen Punkten in dem Netz 100. Das Netz 100 umfasst ferner Dienststeuerpunkte (SCPs) 114 und 116, wobei jeder derselben als eine zentralisierte Datenbank fungiert, die bestimmt, wie bestimmte Anrufe zu führen sind, wie z. B. Anrufe, die eine Vorwahl 800 oder 888 aufweisen. Im Betrieb bringt einer der SSPs 102 und 104 eine Abfragenachricht hervor, die an einen der SCPs 114 und 116 kommuniziert wird. Ansprechend auf diese Abfragenachricht kommuniziert der SCP 114 und 116, der die Abfragenachricht empfängt, eine Antwortnachricht an den ursprünglichen SSP 102 und 104, die dem Anruf zugeordnete Führungsinformationen enthält.

Eine Anzahl von Dienstanbietern liefert üblicherweise einen Dienst durch das Netz 100 und diese Dienstanbieter versuchen immerzu, die Leistung des Netzes zu verbessern und neue Merkmale für ihre Kunden hinzuzufügen oder existierende Merkmale zu verbessern. Um derartige Modifizierungen durchzuführen, muss üblicherweise ein Dienstanbieter eine Software, die auf verschiedenen Punkten in dem Netz läuft, modifizieren. Die Software, die auf den SSPs 114 und 116 läuft, liefert üblicherweise die meisten der hochentwickelten Merkmale, die durch einen Dienstanbieter angeboten und durch das Netz 100 unterstützt werden, wobei so ein Dienst anbieter diese Software modifizieren muss, um derartige Merkmale hinzuzufügen oder zu verändern. Im Namen eines Dienstanbieters greift ein Dienstentwickler 118 üblicherweise auf Computersysteme (nicht gezeigt) zu, die die SSPs 114 und 116 bilden, um die geeignete Software zu modifizieren und dadurch die durch diese Software ausgeführten Dienste zu modifizieren.

Jeder Dienst ist ein Programm auf dem SSP 114 und 116, das einen bestimmten Dienstlogikfluss ausführt. Während diese Dienstprogramme in einer Vielzahl unterschiedlicher Sprachen geschrieben sein können, basieren viele auf einem Modell, das als das dienstunabhängige Baustein- (SIB-) Modell bekannt ist, wobei SIB ein Ausdruck ist, der durch den Telekommunikationsstandardisierungssektor der internationalen Fernmeldeunion (ITU-T) definiert ist. Mit diesem Modell ist ein SIB eine Einheit einer Dienstlogik, die eine einfache Funktion durchführt, wie z. B. Abspielen einer Ansage oder Inkrementieren eines Zählers, und Programme werden durch ein Verbinden einer Anzahl von SIBs gebildet. Bibliotheken von SIBs wurden definiert und die SIBs untereinander in diesen Bibliotheken sind untereinander verbunden, um das erwünschte Dienstprogramm zu bilden und dadurch den erwünschten Dienst bereitzustellen. Jedem SIB zugeordnet sind Eingänge, Ausgänge und Ereignisse und die SIBs sind unter Verwendung ihrer Ereignisse untereinander verbunden. Wenn z. B. drei SIBs vorliegen, die SIB1, SIB2 und SIB3 bezeichnet sind, und der SIB1 Ereignisse A, B und C erzeugt, kann der SIB1 für ein Ereignis A mit SIB2 verbunden sein und für Ereignisse B und C mit SIB3.

Um einen existierenden Dienst zu modifizieren, muss der Dienstentwickler 118 den Dienstlogikfluss, der durch die untereinander verbundenen SIBs definiert ist, die das entsprechende Programm bilden, modifiziert werden. Ähnlich muss zur Entwicklung eines neuen Dienstes der Dienstentwickler 118 SIBs untereinander verbinden, um den erwünschten Dienstlogikfluss durchzuführen. Gegenwärtige Programme, die durch den Dienstentwickler 118 zur Implementierung erwünschter Modifizierungen an einem existierenden Dienst oder zur Entwicklung eines neuen Dienstes verwendet werden können, machen den Vorgang aus einer Vielzahl von Gründen schwierig. Erstens liefern gegenwärtige Programme keine hochentwickelte graphische Benutzerschnittstelle, die es dem Entwickler 118 erlaubt, ohne weiteres existierende Dienstprogramme zu modifizieren und neue zu erzeugen. Ebenso liefern gegenwärtige Programme für den Entwickler 118 keine einfache Art und Weise zur Wiederverwendung wiederholter Teilprozesse einer Dienstlogik innerhalb eines bestimmten Dienstprogramms und unter anderen Dienstprogrammen. Eine Gruppe von SIBs kann z. B. auf die gleiche Art und Weise an mehreren unterschiedlichen Orten innerhalb des gleichen Dienstprogramms untereinander verbunden sein und kann eine Anzahl unterschiedlicher Male in unterschiedlichen Dienstprogrammen verwendet werden. Der Entwickler 118 muss unabhängig diese Gruppe von SIBs jedes Mal, wenn dies erforderlich ist, eingeben und jedes Vorkommnis testen und bereinigen, um zu gewährleisten, dass dieselben ordnungsgemäß eingegeben wurden.

Ein weiteres Problem, das gegenwärtig bei dem SIB-Modell entsteht, beinhaltet eine Beibehaltung von Firmeneigentumsrechten in Dienstprogrammen. Die untereinander verbundenen SIBs, die kollektiv ein Dienstprogramm bilden, werden als ein Dienstgraph bezeichnet und dieser Dienstgraph ist mit dem Quellencode des Dienstprogramms verwandt. Der Dienstentwickler 118 ist unter Umständen nicht dem Dienstanbieter zugeordnet und kann das Dienstprogramm zum Verkauf an eine Anzahl unterschiedlicher Dienstanbieter entwickeln. In dieser Situation möchte der Dienstentwickler 118 idealerweise dem Dienstanbieter keinen Zugriff auf den Dienstgraphen bieten, der das Schlüsselstück geistigen Eigentums darstellt, das durch den Entwickler 118 erzeugt wir und ihm gehört. Gegenwärtige Programme bieten dem Entwickler 118 jedoch keine einfache Art und Weise zum Herunterladen oder „Einsetzen" eines entwickelten Dienstprogramms auf dem SCP 114 und 116, ohne dem Dienstanbieter Zugriff auf den Dienstgraphen zu bieten.

Es besteht ein Bedarf nach einem Programm und einem System zum leichten und effizienten Entwerfen und Einsetzen von Dienstprogrammen, die unter Verwendung des SIB-Modells geschrieben sind.

Es ist die Aufgabe der vorliegenden Erfindung, ein Verfahren, ein computerlesbares Medium, ein Client-Computersystem oder ein Server-Computersystem mit verbesserten Charakteristika zu schaffen.

Diese Aufgabe wird durch ein Verfahren gemäß Anspruch 1, 7, 17 oder 19, ein computerlesbares Medium gemäß Anspruch 14, ein Client-Computersystem gemäß Anspruch 22 oder ein Server-Computersystem gemäß Anspruch 24 gelöst.

Gemäß einem Aspekt der vorliegenden Erfindung umfasst ein Verfahren zum Entwickeln eines Telekommunikationsdienstprogramms unter Verwendung einer Mehrzahl dienstunabhängiger Bausteine ein Entwickeln zumindest eines Dienstlogikteilroutinengraphen unter Verwendung einer Graphikschnittstelle. Jeder Teilroutinengraph wird in einen Dienstgraphen eingefügt und mit weiteren Teilroutinengraphen und/oder dienstunabhängigen Bausteinen in dem Dienstgraphen verbunden, um einen Dienstgraphen zu bilden, der einen Gesamtdienstlogikprozess aufweist. Jedem Teilroutinengraph kann ein Icon zugewiesen sein, wobei das Icon in den Dienstgraphen eingefügt wird und wie erforderlich mit weiteren Teilroutine-Icons und/oder dienstunabhängigen Bausteinen verbunden wird.

Bevorzugte Ausführungsbeispiele der vorliegenden Erfindung werden nachfolgend Bezug nehmend auf die beiliegenden Zeichnungen näher erläutert. Es zeigen:
1 ein Funktionsblockdiagramm eines herkömmlichen Telekommunikationsnetzes unter Verwendung des SS7-Standards;
2 ein Funktionsblockdiagramm eines Telekommunikationsdiensterzeugungssystems, das ein Graphikdienstentwurfsprogramm zum graphischen Definieren von Dienstlogikteilroutinen wiederholter Dienstlogikteilprozesse gemäß einem Ausführungsbeispiel der vorliegenden Erfindung umfasst;
3 ein Flussdiagramm, das ein Gesamtverfahren darstellt, das durch die Telekommunikationsdiensterzeugungsumgebung aus 1 beim Erzeugen und Einsetzen eines Telekommunikationsdienstes gemäß einem Ausführungsbeispiel der vorliegenden Erfindung ausgeführt wird;
4 ein Funktionsblockdiagramm eines Beispiels eines Dienstgraphen, der durch das Graphikdienstentwurfsprogramm aus 2 erzeugt wird, wobei der Dienstgraph eine graphische Darstellung eines Telekommunikationsdienstes ist, der durch ein flexibles Dienstlogikanwendungsprogramm ausgeführt wird, das auf einem Serversystem aus 2 läuft, gemäß einem Ausführungsbeispiel der vorliegenden Erfindung;
5 ein Funktionsblockdiagramm, das detaillierter die Komponenten eines dienstunabhängigen Bausteins aus 4 gemäß einem Ausführungsbeispiel der vorliegenden Erfindung darstellt;
6 ein Diagramm, das eine Anzeige, die durch das Graphikdienstentwurfsprogramm aus 2 vorgelegt wird, zum Konfigurieren eines dienstunabhängigen Probe-Bausteins zeigt;
6 ein Funktionsdiagramm, das das Verfahren, durch das dienstunabhängige Bausteine die Werte von Anrufvariablen setzen und dadurch die Werte von Informationselementen setzen, die in Nachrichten enthalten sind, die durch das flexible Dienstlogikanwendungsprogramm gesendet und empfangen werden, das auf dem Serversystem aus 2 läuft, gemäß einem Ausführungsbeispiel der vorliegenden Erfindung zeigt;
7 ein Funktionsblockdiagramm eines typischen Dienstgraphen, der mehrere wiederholte Dienstlogikteilprozesse umfasst, die über jeweilige Teilroutinen implementiert werden können, die durch das Graphikdienstentwurfsprogramm aus 2 erzeugt werden, gemäß einem Ausführungsbeispiel der vorliegenden Erfindung;
8 ein Funktionsblockdiagramm eines Teilroutinengraphen, der eine generische Teilroutine zeigt, die durch eine Anzahl untereinander verbundener dienstunabhängiger Bausteine gebildet ist, gemäß einem Ausführungsbeispiel der vorliegenden Erfindung;
9 einen exemplarischen Teilroutinengraphen einer Rückruf-Teilroutine, die bestimmt, ob eine Nummer eine Rückrufnummer ist, wie dies in Telefonsystemmerkmalen, wie z. B. Rückrufen der letzten Nummer, die einen angerufen hat, verwendet werden kann, gemäß einem Ausführungsbeispiel der vorliegenden Erfindung;
10 ein Diagramm, das eine Anzeige, die durch das Graphikdienstentwurfsprogramm aus 2 vorgelegt wird, zum Konfigurieren des dienstunabhängigen Bausteins in dem Teilroutinengraphen aus 9, der eine Telefonnummer in einer Datenbankta belle nachschlägt, gemäß einem Ausführungsbeispiel der vorliegenden Erfindung zeigt; und
11 ein Diagramm, das eine Anzeige, die durch das Graphikdienstentwurfsprogramm aus 2 vorgelegt wird, zum Konfigurieren eines exemplarischen dienstunabhängigen Bausteins gemäß einem Ausführungsbeispiel der vorliegenden Erfindung zeigt.
2 ist ein Funktionsblockdiagramm eines Telekommunikationsdiensterzeugungssystems 200, das ein Graphikdienstentwurfsprogramm 202 zum graphischen Definieren von Dienstlogikroutinen, die wiederholten Dienstlogikteilprozessen entsprechen, gemäß einem Ausführungsbeispiel der vorliegenden Erfindung umfasst. Das Graphikdienstentwurfsprogramm 202 ermöglicht es einem Dienstentwickler, ohne weiteres einen Dienstlogikteilroutinengraphen unter Verwendung einer graphischen Schnittstelle zu entwickeln, wobei ein Dienstlogikteilroutinengraph einer Anzahl dienstunabhängiger Bausteine (SIBs) entspricht, die untereinander verbunden sind, um einen wiederholt verwendeten Dienstlogikteilprozess auszuführen. Innerhalb eines einzelnen Telekommunikationsdienstprogramms z. B. kann eine Fehlerhandhabungsteilroutine an einer Anzahl unterschiedlicher Orte verwendet werden und wäre so für eine Implementierung über eine Teilroutine gut geeignet. Ein weiteres Beispiel einer Teilroutine, die in mehreren Dienstprogrammen verwendet werden kann, und so in mehreren Diensten, ist eine Teilroutine zum Validieren und Laden von Kontoinformationen von einer Dienstdatenbank. Auf diese Weise benötigt das Graphikdienstentwurfsprogramm 202 nur einen Teilroutinengraphen, der entwickelt und dann über ein entsprechendes Teilroutinen-Icon in einen einzelnen Dienstgraphen oder in mehrere Dienstgraphen an so vielen Orten, wie dies benötigt wird, eingefügt werden muss. Dies macht ein Entwickeln von Dienstprogrammen schneller und führt zu zuverlässigeren Programmen, was die Gesamtkosten eines Entwickelns neuer Dienstprogramme senkt. Das Graphikdienstentwurfsprogramm 202 sorgt auch für einen leich ten Einsatz eines neu entwickelten Dienstprogramms, ohne dass ein Dienstanbieter Zugriff auf den Dienstgraphen für das Dienstprogramm erhalten muss.
In der folgenden Beschreibung sind bestimmte Details in Verbindung mit den beschriebenen Ausführungsbeispielen der vorliegenden Erfindung dargelegt, um ein ausreichendes Verständnis der Erfindung bereitzustellen. Ein Fachmann auf diesem Gebiet wird jedoch erkennen, dass die Erfindung ohne diese bestimmten Details praktiziert werden kann. Ferner wird ein Fachmann auf diesem Gebiet erkennen, dass die unten beschriebenen exemplarischen Ausführungsbeispiele den Schutzbereich der vorliegenden Erfindung nicht einschränken, und wird ebenso erkennen, dass verschiedene Modifizierungen, Äquivalente und Kombinationen der offenbarten Ausführungsbeispiele innerhalb des Schutzbereichs der vorliegenden Erfindung liegen. Ausführungsbeispiele, die weniger als alle Komponenten eines beschriebenen Ausführungsbeispiels umfassen, sind ebenso innerhalb des Schutzbereichs der vorliegenden Erfindung. Schließlich wird die Funktionsweise bekannter Operationen unten nicht detailliert gezeigt oder beschrieben, um die vorliegende Erfindung nicht unnötig zu verschleiern.
In dem Telekommunikationsdiensterzeugungssystem 200 läuft das Graphikdienstentwurfsprogramm 202 auf einem Clientsystem 204, das üblicherweise ein Personalcomputer ist. Das Graphikdienstentwurfsprogramm 202 umfasst eine graphische Schnittstelle 206, die es einem Dienstentwickler erlaubt, neue Telekommunikationsdienste zu entwerfen, indem erwünschte SIBs aus einer SIB-Bibliothek 208 ausgewählt, die ausgewählten SIBs auf einem Arbeitsbereich oder „Kanvas" (Kanvas = Leinwand = Bereichsbilddaten) platziert und dann die ausgewählten SIBs wie benötigt untereinander verbunden werden, um einen erwünschten Dienstlogikprozess durchzuführen und dadurch einen Dienstgraphen 207 zu erzeugen, wie unten detailliert beschrieben ist. Der Dienstgraph 207 ist eine graphische Darstellung eines Telekommunikationsdiens tes und wird dann verarbeitet und an ein Serversystem 218 übertragen, auf dem ein flexibles Dienstlogik- (FLS-) Programm 226 den verarbeiteten Dienstgraphen ausführt, um dadurch den zugrundeliegenden Dienst bereitzustellen, wie auch unten detaillierter erläutert wird. Die SIB-Bibliothek 208 umfasst eine Anzahl von Standard-SIBs, die durch den Entwickler beim Erzeugen des Dienstgraphen eingesetzt werden können, wobei mehrere Standardbibliotheken von SIBs verfügbar sind, wie z. B. SIB-Bibliotheken CAMEL-3-CSCC (CAP), CAMEL-3-MAP, CS1, ETSI INAP UND TTNS, wobei jede derselben Fachleuten auf diesem Gebiet bekannt ist.
Das Graphikdienstentwurfsprogramm 202 umfasst ferner Dienstgraph- und Teilroutinengraphdateien 210, die Graphen entsprechen, die unter Verwendung des Programms erzeugt und gespeichert werden. Jeder unter Verwendung des Programms 202 erzeugte Dienst weist zugeordnete Dienstdatentabellen 212 auf, die zum Speichern derartiger Informationen, wie z. B. Teilnehmerinformationen, verwendet werden. Während einer Ausführung des Dienstes lesen die SIBs, die den Dienstgraphen 207 bilden, Daten von diesen Dienstdatentabellen 212 und schreiben Daten in dieselben. Eine Nachrichtendefinition oder ein „Nachrichtensatz" 214 ist ebenso Teil des Graphikdienstentwurfsprogramms 202 und ist eine Sammlung von Transaktionsfähigkeitsanwendungsteil- (TCAP-) Nachrichten, die in einem SS7-System verwendet werden, wie zuvor in 1 beschrieben wurde. Kommunikationen zwischen Dienstschaltpunkten (SSPs) 102 und 104 (1) und Dienststeuerpunkten (SCPs) 114 und 116 (1) treten durch TCAP-Nachrichten auf. Der SSP 102 kann z. B. eine TCAP-Nachricht an den SCP 114 senden, um eine Führungsnummer, die einer gewählten 800/888-Nummer zugeordnet ist, zu bestimmen und eine persönliche Identifizierungsnummer des anrufenden Kartenbenutzers zu prüfen. Jede Nachricht in dem Nachrichtensatz 214 umfasst eine Anzahl von Feldern oder Informationselementen IEL und die SIBs, die den Dienstgraphen 207 bilden, verwenden Anrufvariablen CV, um Daten in diese Informationselemente zu schreiben und Daten von den selben zu lesen, wie unten detaillierter beschrieben ist. Kurz gesagt definiert der Nachrichtensatz 214 Informationselemente IEL, die jede Nachricht in dem Nachrichtensatz bilden, und eine Gruppe von Anrufvariablen CV ist diesen Informationselementen zugeordnet und ist zur Verwendung mit dem Dienstgraphen 207 verfügbar, wobei jede Anrufvariable CV einem entsprechenden Informationselement zugeordnet ist. Dies ist unten Bezug nehmend auf 6 detaillierter beschrieben.
Das Telekommunikationsdiensterzeugungssystem 200 umfasst ferner ein Einsatzprogramm 216, das auf dem Clientsystem 204 enthalten ist. Das Einsatzprogramm 216 verarbeitet den unter Verwendung des Graphikschnittstellenprogramms 206 erzeugten Dienstgraphen 207, um Dateien zu erzeugen, die zur Übertragung an ein Serversystem 218 geeignet sind, das diese Dateien ausführt, um dadurch den zugrundeliegenden Telekommunikationsdienst bereitzustellen. Insbesondere wird, sobald ein Dienstgraph 207 mit dem Graphikschnittstellenprogramm 206 erzeugt wurde, der Dienstgraph unter Verwendung des Einsatzprogramms 216 „eingesetzt" oder an den Serversystem 218 „übergeben". Der Dienstentwickler steuert das Schnittstellenprogramm 206, um exportierte Dateien 220 von dem Dienstgraphen 207 zu erzeugen, wobei die exportierten Dateien ein Dienstskript gemeinsam mit weiteren Dateien umfassen, die zum Einsatz des Dienstgraphen nötig sind. Das Einsatzprogramm 216 verwendet nur die exportierten Dateien 220, die nützlich sein können, wenn der gleiche Dienst für mehrere Serversysteme 218 eingesetzt wird, oder wenn Dienste an Dienstanbieter bereitgestellt werden, ohne dass tatsächlich die entwickelten Dienstgraphen 207 an derartige Dienstanbieter geliefert werden. Auf diese Weise liefert das Einsatzprogramm 216 eine bequeme und sichere Art und Weise für einen Dienstentwickler, einen Dienst zu entwerfen und danach die Dateien, die dem entworfenen Dienst entsprechen, an Kunden zu verteilen, ohne firmeneigenes geistiges Eigentum, das in dem Dienstgraphen 208 enthalten ist, zu offenbaren. Das Entwicklungsprogramm 216 liefert außerdem eine bequeme und sichere Art und Weise für den Entwickler, den Dienst auf dem Serversystem 218 einzusetzen. Das Schnittstellenprogramm 206 kann auch direkt den Dienstgraphen 207 ohne eine Verwendung des Einsatzprogramms 216 an das Serversystem 218 übergeben.
Ein Bereitstellungsprogramm 222 auf dem Clientsystem 204 wird verwendet, um Daten zu Dienstdatentabellen hinzuzufügen, die auf dem Serversystem 218 enthalten sind, und die gemäß den Dienstdatentabellendefinitionen 212 erzeugt werden, die durch den Dienstgraphen 207 verwendet werden. Ebenso auf dem Clientsystem 204 enthalten ist ein Anwendungsaufbauerprogramm 224, das verwendet wird, um das FSL-Anwendungsprogramm 226 zu erzeugen, das, wie zuvor erwähnt wurde, ein ausführbares Programm ist, das auf dem Serversystem 218 läuft, um den zugrundeliegenden Telekommunikationsdienst auszuführen. Das Anwendungsaufbauerprogramm 224 ermöglicht es einem Dienstentwickler, aus dem Clientsystem 204 das FSL-Anwendungsprogramm 226 zu erzeugen, das auf dem Serversystem 218 laufen soll.
Auf dem Serversystem 218 arbeitet ein Aufbauserver 228, um mehrere Funktionen durchzuführen. Erstens arbeitet der Aufbauserver 228 in Verbindung mit dem Anwendungsaufbauer 224, um das FSL-Anwendungsprogramm 226 zu erzeugen. Insbesondere wird der Anwendungsaufbauer 224 verwendet, um bestimmte SIB-Bibliotheken 208 auszuwählen, und der Anwendungsaufbauer kommuniziert dann mit dem Aufbauerserver 228, um einen Anwendungsrahmen (nicht gezeigt), der sich auf dem Serversystem 218 befindet, an die ausgewählten SIB-Bibliotheken zu binden, um das FSL-Anwendungsprogramm 226 zu erzeugen, wie durch einen Pfeil 230 in 2 angezeigt wird. Das Serversystem 218 läuft auf einem SCP 114 und 116 in dem SS7-Netz 100 aus 1 und das Anwendungsprogramm 226 kommuniziert mit anderen Punkten (nicht gezeigt) in dem Netz durch TCAP-Nachrichten, wie in 2 angezeigt ist. Das Dienstbild 232 kommuniziert mit dem Anwendungsprogramm 226 durch Anrufvariablen CV, um den Wert eines entsprechen den Informationselements in einer TCAP-Nachricht zu setzen, wie unten detaillierter erläutert ist.
Der Aufbauserver 228 arbeitet außerdem, um entweder mit dem Graphikschnittstellenprogramm 226 oder dem Einsatzprogramm 216 zu kommunizieren, um das von einem dieser zwei Programme empfangene Dienstskript zu kompilieren. Während eines Einsatzes des Dienstgraphen 207 kommuniziert entweder das Graphikschnittstellenprogramm 206 oder das Einsatzprogramm 216 mit dem Aufbauserver 228 und überträgt das Dienstskript, das dem Dienstgraphen 207 entspricht, an den Aufbauserver. Der Aufbauserver 228 kompiliert das empfangene Dienstskript, um dadurch ein entsprechendes Dienstbild 232 zu erzeugen, das in einer Dienstbilddatenbank 234 auf dem Serversystem 218 gespeichert wird. Um den zugrundeliegenden Dienst auszuführen, führt die FSL-Anwendung 226 das Dienstbild 232 aus, wie durch die gepunkteten Linien angezeigt ist, die das Dienstbild in dem Anwendungsprogramm zeigen.
Das Serversystem 218 umfasst ferner einen offenen Datenbankserver 236, der während eines Übergebens des Dienstgraphen 207 arbeitet, um alle Dienstdatentabellen zu erzeugen, die für den zugeordneten Dienst benötigt werden, und speichert diese Dienstdatentabellen in einer Dienstdatentabellendatenbank 238. Sobald diese Dienstdatentabellen erzeugt und in der Dienstdatentabellendatenbank 238 auf dem Serversystem 218 gespeichert sind, kommuniziert das Bereitstellungsprogramm 222 mit dem offenen Datenbankserver 236, um Daten in diese Tabellen einzufügen. Das Bereitstellungsprogramm 222 kann auch verwendet werden, um unabhängig vor einem Übergeben die erforderlichen Dienstdatentabellen zu erzeugen und diese Tabellen in der Datenbank 238 zu speichern.
Das Gesamtverfahren, das durch das Telekommunikationsdiensterzeugungssystem 200 beim Erzeugen und Einsetzen eines Telekommunikationsdienstes ausgeführt wird, wird nun detaillierter Bezug nehmend auf 2 und das Flussdia gramm aus 3 beschrieben. Das Verfahren beginnt bei Schritt 300 und fährt unmittelbar mit Schritt 302 fort, bei dem das Graphikschnittstellenprogramm 206 verwendet wird, um den Dienstgraphen 207 zu entwickeln, der dem erwünschten Telekommunikationsdienst entspricht. Wie zuvor erwähnt wurde, wählt ein Dienstentwickler zur Erzeugung des Dienstgraphen 207 geeignete SIBs aus der SIB-Bibliothek 208 aus, platziert dieselben auf einem Bildschirm oder einem durch das Programm angezeigten Kanvas und verbindet die SIBs wie erforderlich untereinander, um den erwünschten Dienstlogikprozess auszuführen.
Sobald der Dienstgraph 207 in Schritt 302 erzeugt ist, wird das FLS-Anwendungsprogramm 226 in Schritt 304 auf dem Serversystem 218 unter Verwendung des Anwendungsaufbauers 224 und des Aufbauservers 228 erzeugt. Nachdem das FSL-Anwendungsprogramm 226 in Schritt 306 erzeugt wurde, wird der in Schritt 302 erzeugte Dienstgraph 207 entweder direkt unter Verwendung der Graphikschnittstelle 206 oder unter Verwendung des Einsatzprogramms 216 übergibt oder eingesetzt. Während des Einsatzverfahrens empfängt der Aufbauserver 228 ein Dienstskript, das dem entwickelten Dienstgraphen 207 entspricht, und kompiliert das empfangene Dienstskript, um das entsprechende Dienstbild 232 zu erzeugen, das in der Dienstbilddatenbank 234 auf dem Serversystem 218 gespeichert wird.
In Schritt 308 wird die Dienstdatentabellendatenbank 238 auf dem Serversystem 218 unter Verwendung des Bereitstellungsprogramms 222 auf dem Clientsystem 222 und des offenen Datenbankservers 236 auf dem Serversystem erzeugt. Das Bereitstellungsprogramm 222 kommuniziert mit dem offenen Datenbankserver 236, um Daten nach einem Einsatz des Dienstgraphen 207 in Schritt 306 in die Dienstdatentabellen einzufügen. Alternativ kann das Bereitstellungsprogramm 222 auch verwendet werden, um unabhängig vor einem Einsatz des Dienstgraphen 207 die erforderlichen Dienstdatentabellen zu erzeugen und diese Tabellen in der Datenbank 238 zu spei chern, wobei in diesem Fall Schritt 308 vor Schritt 306 auftreten würde.
Das Verfahren geht zu Schritt 310 und das FSL-Anwendungsprogramm 226 führt das Dienstbild 232 aus, um dadurch den entworfenen Dienst auszuführen. Während einer Ausführung des Dienstes kommunizieren das FSL-Anwendungsprogramm 226 und das Dienstbild 232 über Anrufvariablen CV, um Werte, die in den TCAP-Nachrichten enthalten sind, die durch das FSL-Anwendungsprogramm gesendet und empfangen werden, zu übertragen. Fachleute auf diesem Gebiet werden erkennen, dass die bestimmte Reihenfolge, in der die Schritte des Verfahrens aus 3 ausgeführt werden, variieren kann.
4 ist ein Beispiel des Dienstgraphen 207 und zeigt eine Anzahl von SIBs, die untereinander verbunden sind, um einen erwünschten Dienstlogikprozess zu bilden. Jedes Mal, wenn ein SIB auf dem Kanvas platziert wird, wird eine „Instanz" dieses SIB erzeugt und in dem Dienstgraphen 207 durch ein entsprechendes Icon dargestellt. Bei der vorliegenden Beschreibung wird der Ausdruck „SIB", wie er hierin verwendet wird, verwendet, um sich auf die Funktion zu beziehen, die durch den SIB durchgeführt wird, oder auf das Icon, das den SIB darstellt, oder beides.
In dem Beispiel aus 4 zeigt ein Anfangs-SIB 400 den Beginn des Dienstlogikprozesses an und ein Probe-SIB, als SIB1 bezeichnet, ist mit dem Anfangs-SIB 400 durch eine Verbindung 402 gekoppelt. Der SIB1 ist ebenso durch eine Verbindung 404 mit einem zweiten Probe-SIB, SIB2 genannt, und einer Teilroutine 406 gekoppelt, die durch ein entsprechendes Icon dargestellt ist. Ein Ende-SIB 408 ist mit dem SIB2 durch eine Verbindung 410 verbunden und ein dritter Probe-SIB, SIB3 genannt, und ein weiterer Ende-SIB 412 sind in Serie durch jeweilige Verbindungen 414, 416 mit der Teilroutine 406 gekoppelt, wie dies gezeigt ist. Die Teilroutine 406 ist eine Gruppe von SIBs (nicht gezeigt), die einen erwünschten Dienstlogikteilprozess ausführen, der wiederholt innerhalb eines bestimmten Dienstlogikprozesses oder unter unterschiedlichen Dienstlogikprozessen verwendet wird, wie unten detaillierter beschrieben ist.
5 ist ein Funktionsblockdiagramm, das die Komponenten eines typischen SIB 500, der einem der SIB1–SIB3 aus 4 entspricht, detaillierter darstellt. Der SIB 500 umfasst Eingänge 502, die an eine SIB-Logik angelegt werden, die die einfache Funktion des SIB ausführt, wobei jeder Eingang einer entsprechenden Anrufvariable zugeordnet ist. Wie zuvor erwähnt wurde, werden Anrufvariablen CV beim Kommunizieren von Informationen zwischen dem Dienst, der dem Dienstgraphen 207 entspricht, und TCAP-Nachrichten, die durch das FSL-Anwendungsprogramm 226 kommuniziert werden, verwendet. Der SIB 500 umfasst ferner Ausgänge 506, wobei jeder derselben ebenso einer entsprechenden Anrufvariable zugewiesen ist. Schließlich umfasst der SIB 500 Ereignisse, die Parameter sind, die über Verbindungen von einem SIB an einen anderen kommuniziert werden und die den Logikfluss innerhalb des Dienstgraphen 207 steuern. In 4 definiert z. B. die Verbindung 404 Ereignisse, die an den SIB2 und an die Teilroutine 406 kommuniziert werden, und die Werte dieser Ereignisse können z. B. bestimmen, ob die Teilroutine ausgeführt wird, um eine erste Funktion durchzuführen, oder ob der SIB2 ausgeführt wird, um eine zweite Funktion durchzuführen.
6 ist ein Funktionsdiagramm, das das Verfahren zeigt, durch das SIBs die Werte von Anrufvariablen CV setzen, die wiederum die Werte von Informationselementen IEL setzen, die in TCAP-Nachrichten enthalten sind, die durch das FSL-Anwendungsprogramm 226 gesendet und empfangen werden. Bei dem Beispiel aus 6 weist ein SIB 600 zwei Ausgänge auf und jeder Ausgang ist einer jeweiligen Anrufvariable CV1, CV2 zugewiesen. Um den Wert eines Informationselements IEL in einer TCAP-Nachricht zu setzen, setzt der SIB 600 die Werte der Anrufvariablen CV1, CV2. Wie zuvor erwähnt wurde, kommuniziert das Dienstbild 232, das eine kompilierte Version des Dienstgraphen 207 ist, der den SIB 600 enthält, mit dem FSL-Anwendungsprogramm 226 durch Anrufvariablen CV. Ansprechend auf die Anrufvariablen CV1, CV2 modifiziert die FSL-Anwendung 226 die Informationselemente IEL in der passenden Nachricht in dem Nachrichtensatz 214, der dem zugrundeliegenden Dienst zugeordnet ist. In 6 ist der Nachrichtensatz 214 gezeigt, um eine Anzahl einzelner Nachrichten MSG1–MSGN zu enthalten, wobei jede Nachricht eine Anzahl von Informationselementen IEL umfasst. Die Anrufvariablen CV1 und CV2 sind Informationselementen IEL1 und IEL2 in der Nachricht MSG2 zugeordnet und der SIB 600 setzt die Werte dieser Informationselemente durch die Verfahrensvariablen CV1 und CV2.
7 ist ein Funktionsblockdiagramm eines typischen Dienstgraphen 700, der mehrere Gruppen 702–706 von SIBs umfasst, wobei jede Gruppe von SIBs ein wiederholter Dienstlogikteilprozess ist, der über eine jeweilige Teilroutine implementiert werden kann, die durch das Graphikdienstentwurfsprogramm 202 erzeugt wird. Die Gruppe 702 könnte z. B. eine Gruppe von SIBs sein, die eine Fehlerhandhabungsroutine, die in mehreren Instanzen innerhalb des einzelnen Dienstgraphen 700 verwendet wird, ausführen. Diese Fehlerhandhabungsroutine ist gut geeignet, um durch eine Teilroutine implementiert zu sein. Die Gruppe 704 könnte z. B. eine Gruppe von SIBs sein, die eine Routine ausführen, um Kontoinformationen von der Dienstdatenbank 238 (2) zu validieren und zu laden. Diese Routine kann in einer Anzahl unterschiedlicher Dienstgraphen 700 verwendet werden, und ist so ähnlich gut geeignet, um durch eine Teilroutine implementiert zu sein.
Das Graphikschnittstellenprogramm 206 erzeugt Teilroutinen auf ziemlich die gleiche Art und Weise, wie der Dienstgraph 700 erzeugt wird, der einem Gesamtdienstverfahren entspricht. So wird zur Erzeugung einer Teilroutine das Graphikschnittstellenprogramm 206 verwendet, um einen Teilrou tinengraphen zu erzeugen, wobei ein Beispiel hierfür als ein Teilroutinengraph 800 in 8 gezeigt ist. Die in dem Teilroutinengraph 800 enthaltenen SIBs können ausgewählt und eingefügt werden, wie zuvor für den Dienstgraphen 207 aus 4 beschrieben wurde, oder können von Abschnitten anderer Dienstgraphen kopiert werden. In einem Dienstgraphen wird jede Teilroutine mit einem unterschiedlichen Icon dargestellt, das das Anrufteilroutinenicon bezeichnet wird, wobei ein Beispiel hierfür für die Teilroutine 406 in 4 gezeigt ist.
Der Teilroutinengraph 800 stellt einen Dienstlogikteilprozess dar, der dann durch den Dienstgraphen 207 oder 700 aufgerufen wird. In der folgenden Beschreibung wird zur Erleichterung einer Erläuterung nur der exemplarische Dienstgraph 207 erwähnt. Das Graphikschnittstellenprogramm 206 wird verwendet, um den Teilroutinengraphen 800 auf im großen und ganzen die gleiche Art und Weise zu erzeugen, wie der Dienstgraph 207 erzeugt würde. Eine neue Teilroutine wird ausgewählt, um einen neuen Teilroutinen-Kanvas zu öffnen, und SIBs werden dann ausgewählt und auf dem Kanvas platziert, um bestimmte Instanzen derartiger SIBs zu erzeugen. Diese SIBs werden danach durch Verbindungen, wie dies erforderlich ist, untereinander verbunden, um den erwünschten Dienstlogikteilprozess durchzuführen. Jeder Teilroutinengraph 800 umfasst spezielle SIBs, die nur Teilroutinengraphen zugeordnet sind, nämlich einen Teilroutine-Anfang-SIB 802, der den Beginn eines Teilroutinengraphen anzeigt, und einen oder mehrere Rückgabe-SIBs 804, 806, die das Ende eines bestimmten Logikflusses innerhalb des Teilroutinengraphen anzeigen, wo eine Steuerung an den Dienstgraphen 207 zurückgegeben wird, der den Teilroutinengraphen aufruft. Zusätzlich zu dem Teilroutine-Anfang-SIB 802 und den Rückgabe-SIBs 804, 806 werden die zur Durchführung des erwünschten Dienstlogikteilprozesses erforderlichen SIBs auch in den Teilroutinengraphen 800 eingefügt und sind als SIB1–SIB4 bezeichnet und untereinander verbunden, wie in diesem Beispiel gezeigt ist.
Zusätzlich zu einem Erzeugen von Instanzen der erforderlichen SIBs wird das Graphikschnittstellenprogramm 206 auch verwendet, um einen Namen, Eingänge, Ausgänge und Ereignisse für den Teilroutinengraphen 800 zu definieren. Es wird angemerkt, dass die Ausdrücke Teilroutine und Teilroutinengraph hier austauschbar verwendet werden können. Der dem Teilroutinengraph 800 zugewiesene Name wird in dem entsprechenden Icon angezeigt, das in dem Dienstgraphen 207 gezeigt ist. Die Eingänge sind alle Eingänge in den Teilroutinengraphen 800, die durch den anrufenden Dienstgraphen 207 gesetzt werden können, während die Ausgänge Parameter sind, die an den anrufenden Dienstgraphen zurückgegeben werden. Ähnlich sind Ereignisse eines Teilroutinengraphen 800 die Ereignisse, die an den anrufenden Dienstgraphen 207 zurückgegeben werden können, und werden durch die Rückgabe-SIBs 804, 806 an den anrufenden Dienstgraphen zurückgegeben. Jeder Rückgabe-SIB 804, 806 weist keine eigenen Ausgangsereignisse auf, sondern gibt statt dessen eines der Ereignisse, die für den Teilroutinengraphen 800 definiert sind, zurück. Wenn mehr als ein Rückgabe-SIB 804, 806 vorliegt, wie dies offensichtlich bei dem Graphen 800 der Fall ist, kann jeder Rückgabe-SIB das gleiche oder ein unterschiedliches Ereignis zurückgeben.
Sobald ein Teilroutinengraph 800 unter Verwendung des Graphikschnittstellenprogramms 206 definiert ist, zeigt das Programm einen Anrufteilroutinen-SIB oder ein -Icon an, der/das es einem Entwickler ermöglicht, Instanzen der Teilroutine, wo dies erwünscht wird, in den Dienstgraphen 207 zu erzeugen. Wie zuvor erwähnt wurde, ist ein Beispiel eines Anrufteilroutinen-SIB für die Teilroutine 406 aus 4 gezeigt. Instanzen der Teilroutine können so z. B. durch ein Klicken auf das entsprechende Icon, das auf einem Arbeitsmarkierungsbedienfeld angezeigt wird, das durch das Programm 206 angezeigt wird, und ein darauffolgendes Ziehen des Icons auf den durch das Programm angezeigten Kanvas erzeugt werden.
Bei einem Ausführungsbeispiel des Programms 202 ermöglicht es das Graphikschnittstellenprogramm 206, dass der Teilroutinengraph 800 von mehreren Dienstgraphen 207 angerufen werden kann, und ebenso von weiteren Teilroutinengraphen angerufen werden kann, erlaubt es jedoch nicht, dass ein Teilroutinengraph rekursiv angerufen werden kann (d. h. ein Teilroutinengraph kann selbst nicht anrufen), und ermöglicht es ebenso nicht, dass ein Teilroutinengraph durch einen weiteren Teilroutinengraph angerufen werden kann, um diesen ursprünglichen Teilroutinengraph anzurufen (d. h. wenn Teilroutine A Teilroutine B anruft, kann Teilroutine B Teilroutine A nicht anrufen).
Auf diese Weise erfordert es das Graphikdienstentwurfsprogramm 202, dass nur ein Teilroutinengraph 800 entwickelt und dann über ein entsprechendes Teilroutinenicon in einen einzelnen Dienstgraphen 207 oder in mehrere Dienstgraphen an so vielen Orten, wie dies erforderlich ist, eingesetzt werden muss. Telekommunikationsdienste können deshalb unter Verwendung des Programms 202 schneller entwickelt werden. Ferner macht die Verwendung von Teilroutinengraphen 800 neue Dienste zuverlässiger, da, sobald ein Teilroutinengraph entworfen und validiert ist, um ordnungsgemäß zu funktionieren, der durch den Teilroutinengraphen ausgeführte Dienstlogikteilprozess nicht wieder geprüft werden muss, wenn ein Gesamtdienstgraph, der die Teilroutine enthält, validiert wird.
9 ist ein exemplarischer Teilroutinengraph 900 einer Rückruf-Teilroutine, die bestimmt, ob eine Nummer eine Rückruf-Nummer ist, wie dies in Telefonsystemmerkmalen verwendet werden kann, wie z. B. Rückrufen der letzten Nummer, die den Anruf eingeleitet hat, und das üblicherweise als das „*69"-Merkmal bekannt ist. Der Teilroutinengraph 900 umfasst einen Teilroutine-Beginnen-SIB 902, der mit einem Rückruf-Lesen-SIB 904 verbunden ist. Der Rückruf-Lesen-SIB 904 bestimmt, ob die Nummer eine Rückruf-Nummer ist, und liefert einen Rückruf-Indikator, der einen Wert aufweist, der die Ergebnisse dieser Bestimmung anzeigt. Wenn der SIB 904 bestimmt, dass die Nummer eine Rückrufnummer ist, setzt der SIB den Rückruf-Indikator-Wert auf wahr, und ansprechend auf diesen Wahr-Indikator setzt ein „Ist Rückrufen"-SIB 906 ein wahres „Ist Rückrufen"-Ereignis. Ein Rückgabe-SIB 908 gibt das wahre „Ist Rückrufen"-Ereignis an den anrufenden Dienstgraphen (nicht gezeigt) zurück. Wenn der SIB 904 bestimmt, dass die Nummer keine Rückrufnummer ist, setzt der SIB den Rückruf-Indikator-Wert auf falsch und ansprechend auf diesen Falsch-Indikator setzt ein „Ist kein Rückrufen"-SIB 910 ein wahres „Ist kein Rückrufen"-Ereignis. Ein Rückgabe-SIB 912 gibt das wahre „Ist kein Rückrufen"-Ereignis an den anrufenden Dienstgraphen (nicht gezeigt) zurück.
10 ist ein Diagramm, das eine Anzeige 1000, die durch das Graphikschnittstellenprogramm 206 aus 2 vorgelegt wird, für den Rückrufen-Lesen-SIB 904 aus 9 zeigt. Die Anzeige 904 erlaubt es einem Dienstentwickler, den SIB 904 wie erforderlich zu konfigurieren. Die Anzeige zeigt, dass der SIB 904 eine Steuervariable „Nummer Zurückrufen" verwendet, um zu bestimmen, ob eine Nummer eine Rückrufnummer ist.
11 ist ein Diagramm, das eine Anzeige 1100, die durch das Graphikschnittstellenprogramm 206 aus 2 vorgelegt wird, für einen exemplarischen „Ansage-Abspielen"-SIB zeigt. Die Anzeige 1100 zeigt die dem SIB zugeordneten Eingangs- und Ausgangsparameter, jeder Eingangsparameter ist durch ein zugeordnetes „E" oder „O" in der ganz linken Spalte für den Parameter als erforderlichen oder optional angezeigt und Werte für die erforderlichen Eingangsparameter werden angezeigt. Drei Ausgangsparameter sind gezeigt und eine geeignete Anrufvariable CV kann jedem zugeordnet sein, obwohl in der Anzeige keine derartigen Anrufvariablen als zugewiesen gezeigt sind.
Ein Fachmann auf diesem Gebiet wird erkennen, dass, obwohl verschiedene Ausführungsbeispiele und Vorteile der vorliegenden Erfindung in der vorangegangenen Beschreibung dargelegt sind, die obige Offenbarung lediglich darstellend ist und Veränderungen an Details vorgenommen werden können, wobei dennoch innerhalb der breiten Prinzipien der Erfindung verblieben wird. Die oben beschriebene Folge von Operationen in den verschiedenen Prozessen z. B. kann variiert werden und das Client- und das Server-Computersystem können jeweils auf einem einzelnen Computer oder einem Netz geeignet verbundener Computer enthalten sein und können auch auf einer Vielzahl unterschiedlicher Typen von Computersystemen enthalten sein, auf denen eine Vielzahl unterschiedlicher Betriebssysteme läuft. Ferner können Konzepte und Prinzipien der vorliegenden Erfindung auf weitere Typen von Telekommunikationssystemen angewendet werden. Deshalb soll die vorliegende Erfindung nur durch die beigefügten Ansprüche eingeschränkt sein.

Claims

Verfahren zum Entwickeln eines Telekommunikationsdienstprogramms unter Verwendung einer Mehrzahl dienstunabhängiger Bausteine, wobei das Verfahren folgende Schritte aufweist: Entwickeln zumindest eines Dienstlogikteilroutinengraphen (800) unter Verwendung einer Graphikschnittstelle (206); Erzeugen eines Teilroutine-Icons (406), das jeden Dienstlogikteilroutinengraphen (800) darstellt; und Einfügen jedes Teilroutine-Icons (406) in einen Dienstgraphen (207) und Verbinden des Icons (406) mit weiteren Teilroutine-Icons (406) und/oder dienstunabhängigen Bausteinen in dem Dienstgraphen (207), um einen Dienstgraphen zu bilden, der einen Gesamtdienstlogikprozess aufweist.
Verfahren gemäß Anspruch 1, bei dem ein Teilroutinengraph (800) folgende Merkmale aufweist: einen dienstunabhängigen Teilroutinenanfang-Baustein (802), der den Anfang des Teilroutinengraphen (800) anzeigt; zumindest einen dienstunabhängigen Baustein, der mit dem Teilroutinenanfangsgraphen (802) verbunden ist; und zumindest einen dienstunabhängigen Teilroutinenrückgabe-Baustein (804, 806), wobei ein dienstunabhängiger Teilroutinenrückgabe-Baustein (804, 806) ein Ende eines entsprechenden Dienstlogikteilprozesses in dem Teilroutinengraph anzeigt und mit zumindest einem dienstunabhängigen Baustein verbunden ist.
Verfahren gemäß Anspruch 2, bei dem das Entwickeln zumindest eines Dienstlogikteilroutinengraphen (800) unter Verwendung einer Graphikschnittstelle (206) folgende Schritte aufweist: Öffnen eines neuen Dienstgraphenkanvas; Platzieren dienstunabhängiger Bausteine auf dem Kanvas und Verbinden der Blöcke untereinander; Platzieren des dienstunabhängigen Teilroutinenanfang-Bausteins (802) auf dem Kanvas und Verbinden desselben mit zumindest einem dienstunabhängigen Baustein; und Platzieren des dienstunabhängigen Teilroutinenrückgabe-Bausteins (804, 806) auf dem Kanvas und Verbinden desselben mit zumindest einem dienstunabhängigen Baustein.
Verfahren gemäß einem der Ansprüche 1 bis 3, bei dem ein Teilroutinengraph (800) folgende Merkmale aufweist: Eingangsparameter, die durch einen Dienstgraphen (207), der den Teilroutinengraph aufruft, gesetzt werden können; Ausgangsparameter, die an den Dienstgraphen, der den Teilroutinengraph aufruft, zurückgegeben werden können; und Ereignisparameter, die an den Dienstgraphen, der den Teilroutinengraph aufruft, zurückgegeben werden können.
Verfahren gemäß einem der Ansprüche 1 bis 4, bei dem das Entwickeln zumindest eines Dienstlogikteilrouti nengraphen (800) unter Verwendung einer Graphikschnittstelle (206) folgende Schritte aufweist: Auswählen einer neuen Teilroutinenmarkierung; Öffnen eines Teilroutinenkanvas ansprechend auf die Auswahl der neuen Teilroutinenmarkierung; und Platzieren dienstunabhängiger Bausteine auf dem Kanvas und Verbinden der Blöcke untereinander wie erforderlich, um einen Dienstlogikteilprozess auszuführen.
Verfahren gemäß Anspruch 5, bei dem das Platzieren dienstunabhängiger Bausteine auf dem Kanvas ein Kopieren einer Gruppe dienstunabhängiger Bausteine aus dem Dienstgraphen (207) und ein Einfügen derselben auf dem Teilroutinenkanvas aufweist.
Verfahren zum Entwickeln eines Telekommunikationsdienstprogramms unter Verwendung einer Mehrzahl dienstunabhängiger Bausteine, wobei das Verfahren folgende Schritte aufweist: Entwickeln zumindest eines Dienstlogikteilroutinengraphen (800) unter Verwendung einer Graphikschnittstelle (206) ; und Einfügen jedes Teilroutinengraphen in einen Dienstgraphen (207) und Verbinden des Teilroutinengraphen mit weiteren Teilroutinengraphen und/oder dienstunabhängigen Bausteinen in dem Dienstgraphen (207), um einen Dienstgraphen zu bilden, der einen Gesamtdienstlogikprozess aufweist.
Verfahren gemäß Anspruch 7, bei dem das Einfügen jedes Teilroutinengraphen in einen Dienstgraphen (207) und das Verbinden des Teilroutinengraphen folgende Schritte aufweisen: Zuweisen eines Icons (406) zu jedem Teilroutinengraphen; Einfügen des Icons in den Dienstgraphen (207); und Verbinden des Teilroutine-Icons wie erforderlich mit weiteren Teilroutine-Icons und/oder dienstunabhängigen Bausteinen.
Verfahren gemäß Anspruch 7 oder 8, bei dem ein Teilroutinengraph (800) folgende Merkmale aufweist: einen dienstunabhängigen Teilroutinenanfang-Baustein (802), der den Anfang des Teilroutinengraphen (800) anzeigt; zumindest einen dienstunabhängigen Baustein, der mit dem Teilroutinenanfangsgraphen (802) verbunden ist; und zumindest einen dienstunabhängigen Teilroutinenrückgabe-Baustein (804, 806), wobei ein dienstunabhängiger Teilroutinenrückgabe-Baustein (804, 806) ein Ende eines entsprechenden Dienstlogikteilprozesses in dem Teilroutinengraph anzeigt und mit zumindest einem dienstunabhängigen Baustein verbunden ist.
Verfahren gemäß Anspruch 9, bei dem das Entwickeln zumindest eines Dienstlogikteilroutinengraphen (800) unter Verwendung einer Graphikschnittstelle (206) folgende Schritte aufweist: Öffnen eines neuen Teilroutinendienstgraphenkanvas; Platzieren dienstunabhängiger Bausteine auf dem Kanvas und Verbinden der Blöcke untereinander; Platzieren des dienstunabhängigen Teilroutinenanfang-Bausteins (802) auf dem Kanvas und Verbinden desselben mit zumindest einem dienstunabhängigen Baustein; und Platzieren jedes dienstunabhängigen Teilroutinenrückgabe-Bausteins (804, 806) auf dem Kanvas und Verbinden desselben mit zumindest einem dienstunabhängigen Baustein.
Verfahren gemäß einem der Ansprüche 8 bis 10, bei dem ein Teilroutinengraph (800) folgende Merkmale aufweist: Eingangsparameter, die durch einen Dienstgraphen (207), der den Teilroutinengraph aufruft, gesetzt werden können; Ausgangsparameter, die an den Dienstgraphen, der den Teilroutinengraph aufruft, zurückgegeben werden können; und Ereignisparameter, die an den Dienstgraphen, der den Teilroutinengraph aufruft, zurückgegeben werden können.
Verfahren gemäß einem der Ansprüche 8 bis 11, bei dem das Entwickeln zumindest eines Dienstlogikteilroutinengraphen (800) unter Verwendung einer Graphikschnittstelle (206) folgende Schritte aufweist: Auswählen einer neuen Teilroutinenmarkierung; Öffnen eines Teilroutinenkanvas ansprechend auf die Auswahl der neuen Teilroutinenmarkierung; und Platzieren dienstunabhängiger Bausteine auf dem Kanvas und Verbinden der Blöcke untereinander wie erforderlich, um einen Dienstlogikteilprozess auszuführen.
Verfahren gemäß Anspruch 12, bei dem das Platzieren dienstunabhängiger Bausteine auf dem Kanvas ein Kopieren einer Gruppe dienstunabhängiger Bausteine aus dem Dienstgraphen (207) und ein Einfügen derselben auf dem Teilroutinenkanvas aufweist.
Computerlesbares Medium, dessen Inhalt bewirkt, dass ein Computer ein Telekommunikationsdienstprogramm unter Verwendung einer Mehrzahl dienstunabhängiger Bausteine entwickelt, indem die folgenden Operationen durchgeführt werden: Entwickeln zumindest eines Dienstlogikteilroutinengraphen (800) unter Verwendung einer Graphikschnittstelle (206); Erzeugen eines Teilroutine-Icons (406); das jeden Dienstlogikteilroutinengraphen (800) darstellt; und Einfügen jedes Teilroutine-Icons (406) in einen Dienstgraphen (207) und Verbinden des Icons (406) mit weiteren Teilroutine-Icons (406) und/oder dienstunabhängigen Bausteinen in dem Dienstgraphen (207), um einen Dienstgraphen zu bilden, der einen Gesamtdienstlogikprozess aufweist.
Computerlesbares Medium gemäß Anspruch 14, bei dem ein Teilroutinengraph (800) folgende Merkmale aufweist: einen dienstunabhängigen Teilroutinenanfang-Baustein (802), der den Anfang des Teilroutinengraphen (800) anzeigt; zumindest einen dienstunabhängigen Baustein, der mit dem Teilroutinenanfangsgraphen (802) verbunden ist; und zumindest einen dienstunabhängigen Teilroutinenrückgabe-Baustein (804, 806), wobei jeder dienstunabhängige Teilroutinenrückgabe-Baustein (804, 806) ein Ende eines entsprechenden Dienstlogikteilprozesses in dem Teilroutinengraphen anzeigt und mit zumindest einem dienstunabhängigen Baustein verbunden ist.
Computerlesbares Medium gemäß Anspruch 14 oder 15, bei dem das Entwickeln zumindest eines Dienstlogikteilroutinengraphen (800) unter Verwendung einer Graphikschnittstelle (206) folgende Schritte aufweist: Auswählen einer neuen Teilroutinenmarkierung; Öffnen eines Teilroutinenkanvas ansprechend auf die Auswahl der neuen Teilroutinenmarkierung; und Platzieren dienstunabhängiger Bausteine auf dem Kanvas und Verbinden der Blöcke untereinander wie erforderlich, um einen Dienstlogikteilprozess auszuführen.
Verfahren zum Ausführen eines Telekommunikationsdienstes, mit folgenden Schritten: Empfangen eines Dienstprogramms zum Ausführen des Telekommunikationsdienstes, wobei das Dienstprogramm durch folgende Schritte erzeugt wurde: Entwickeln zumindest eines Dienstlogikteilroutinengraphen (800) unter Verwendung einer Graphikschnittstelle (206); Erzeugen eines Teilroutine-Icons (406), das jeden Dienstlogikteilroutinengraphen (800) darstellt; und Einfügen jedes Teilroutine-Icons (406) in einen Dienstgraphen (207) und Verbinden des Icons (406) mit weiteren Teilroutine-Icons (406) und/oder dienstunabhängigen Bausteinen in dem Dienstgraphen (207), um einen Dienstgraphen zu bilden, der einen Gesamtdienstlogikprozess aufweist; und Laufen lassen des Dienstprogramms, um den Telekommunikationsdienst bereitzustellen.
Verfahren gemäß Anspruch 17, bei dem das Empfangen eines Dienstprogramms ein Empfangen eines Dienstskriptes, das aus dem Dienstgraphen (207) erzeugt wird, aufweist.
Verfahren zum Ausführen eines Telekommunikationsdienstes, mit folgenden Schritten: unter einer Steuerung eines Client-Systems, Entwickeln zumindest eines Dienstlogikteilroutinengraphen (800) unter Verwendung einer Graphikschnittstelle (206); Erzeugen eines Teilroutine-Icons (406), das jeden Dienstlogikteilroutinengraphen (800) darstellt; und Einfügen jedes Teilroutine-Icons (406) in einen Dienstgraphen (207) und Verbinden des Icons (406) mit weiteren Teilroutine-Icons (406) und/oder dienstunabhängigen Bausteinen in dem Dienstgraphen (207), um einen Dienstgraphen zu bilden, der einen Gesamtdienstlogikprozess aufweist; Übertragen des Dienstgraphen an ein Serversystem; und unter einer Steuerung des Serversystems, Laufen lassen des Dienstprogramms, um den Telekommunikationsdienst bereitzustellen.
Verfahren gemäß Anspruch 19, bei dem das Übertragen des Dienstgraphen an ein Serversystem ein Erzeugen, auf dem Client-System, eines Dienstskripts aus dem Dienstgraphen und ein Übertragen des Dienstskripts an das Serversystem aufweist.
Verfahren gemäß Anspruch 20, das ferner ein Entwickeln eines ausführbaren Anwendungsprogramms auf dem Serversystem aufweist, wobei das ausführbare Anwendungsprogramm unter einer Steuerung des Client-Systems entwickelt wird.
Client-Computersystem (204) mit folgendem Merkmal: einer Graphikschnittstellenkomponente (202), die ansprechend auf eine Benutzereingabe wirksam ist, um zumindest einen Dienstlogikteilroutinengraphen (800) unter Verwendung einer Graphikschnittstelle (206) zu entwickeln und ein Teilroutine-Icon (406), das jeden Dienstlogikteilroutinengraphen (800) darstellt, zu erzeugen, und ansprechend auf eine Benutzereingabe wirksam ist, um jedes Teilroutine-Icon (406) in einen Dienstgraphen (207) einzufügen und das Icon (406) mit weiteren Teilroutine-Icons (406) und/oder dienstunabhängigen Bausteinen in dem Dienstgraphen (207) zu verbinden, um einen Dienstgraphen zu bilden, der einen Gesamtdienstlogikprozess aufweist.
Client-Computersystem (204) gemäß Anspruch 22, das ferner folgende Merkmale aufweist: eine Anwendungsaufbaukomponente (224), die wirksam ist, um mit einem Serversystem (218) zu kommunizieren, um ein Anwendungsprogramm (226) auf dem Serversystem (218) zu erzeugen; eine Einsatzkomponente (216), die mit der Graphikschnittstellenkomponente (202) gekoppelt ist, um ein Dienstskript von der graphischen Schnittstellenkomponente (202) zu empfangen, und wirksam ist, um das Dienstskript zu verarbeiten, um Dateien zum Einsatz auf dem Serversystem (218) zu erzeugen; und eine Bereitstellungskomponente (222), die wirksam ist, um Dienstdatentabellen auf dem Serversystem (218) zur Verwendung während einer Ausführung des Dienstes, der dem Dienstskript entspricht, zu erzeugen.
Server-Computersystem mit folgenden Merkmalen: einem Aufbauserver (228), der angepasst ist, um ein Dienstskript zu empfangen, das einem Telekommunikationsdienst entspricht, wobei das Dienstskript aus einem Dienstgraphen (207), der aus einer Mehrzahl untereinander verbundener dienstunabhängiger Bausteine gebildet ist, und einem Teilroutine-Icon (406) erzeugt wurde, wobei jedes Teilroutine-Icon (406) einen Teilroutinengraphen (800) darstellt, und der Aufbauserver (228) wirksam ist, um das Dienstskript zu kompilieren, um ein Dienstbild (232) zu erzeugen; einem offenen Datenbankserver (236), der wirksam ist, um Dienstdatentabellen (238) zu erzeugen, die durch das Dienstbild (232) benötigt werden, und die Tabellen (238) in einer Tabellendatenbank (238) zu speichern; und einer Anwendungskomponente (226), die wirksam ist, um das Dienstbild (232) auszuführen, um den Telekommunikationsdienst bereitzustellen.
Serversystem gemäß Anspruch 24, wobei das Serversystem einen Dienststeuerpunkt in einem SS7-Netz (100) aufweist.
Serversystem gemäß Anspruch 24 oder 25, das ferner eine Dienstbilddatenbankkomponente aufweist, die eine Mehrzahl von Dienstbildern umfasst, die durch die Anwendungskomponente (226) ausgeführt werden.