-
GEBIET DER
ERFINDUNG
-
Ausführungsformen
der vorliegenden Erfindung betreffen Telekommunikationsnetzwerke.
Insbesondere betreffen Ausführungsformen
der vorliegenden Erfindung Telekommunikationsnetzwerke, die API-Betriebsmittel
unterstützen.
-
BESCHREIBUNG
DES STANDES DER TECHNIK
-
Telekommunikationsnetzwerk-Betreiber
zögern
oft, ihre Netzwerke für
neue Gesellschaften zu öffnen,
die kommunikationsbasierte Anwendungen anbieten. Ihr Zögern ist
zumindest insofern etwas gerechtfertigt, als Netzwerkbetreiber riskieren,
ihre eigenen Anwendungen auszuschlachten, insbesondere wenn der
Preis zum Hauptunterschied zwischen ihren Anwendungen und denjenigen
wird, die von neuen Gesellschaften angeboten werden. Tatsächlich laufen
Telekommunikationsnetzwerk-Betreiber Gefahr, zu reinen "Bit-Transportern" zu werden, wenn
sie nicht mit Anwendungen konkurrieren können, die von neuen Gesellschaften
mit niedrigen Gemeinkosten angeboten werden.
-
Wenn
Telekommunikationsnetzwerk-Betreiber ihre Netzwerke für neue Anwendungen
und Gesellschaften öffnen,
müssen
Netzwerkbetreiber außerdem
damit rechnen, die Kontrolle über
ihre Netzwerke zu verlieren, indem sie Netzwerkanforderungen unterstützen müssen, die
durch Anwendungen hervorgerufen werden, die von Dritten geschrieben und
verwaltet werden, wie beispielsweise Dienstanbietern oder Software-Anbietern.
-
Obwohl
ihr Zögern,
die Netzwerke zu öffnen, gerechtfertigt
sein mag, riskieren Telekommunikationsnetzwerk-Betreiber, wenn sie es nicht tun, lukrative
Märkte
zu verlieren, die neue Gesellschaften und Anwendungen schaffen können. Da
die meisten Gesellschaften außer halb
der herkömmlichen
Telekommunikationsnetzwerk-Grenzen
operieren, können neue
Anwendungen vollkommen neue Dienste schaffen, die Kunden anziehen,
die das Netzwerk normalerweise nicht nutzen würden. Außerdem können staatliche Behörden, die
den Wettbewerb des Telekom-Markts erweitern möchten, Netzwerkbetreiber dazu
zwingen, ihre Netzwerke zu öffnen.
-
In
einem Szenario basieren Transaktionen zwischen einem Netzwerk und
Anwendungen vorteilhafterweise auf einem Set von Schnittstellen
und Datentypen, die Anwenderprogrammschnittstellen (APIs) bilden.
Wenn diese APIs standardisiert und weitgehend zur Nutzung verfügbar sind,
werden solche APIs als offene APIs bezeichnet. Offene APIs werden
typischerweise von Software-Organisationen erstellt, die bei der
Definition der APIs und der Bekanntmachung ihrer Verwendung sorgfältig vorgehen.
Es gibt viele Sets von offenen APIs, zum Beispiel die Parlay/OSA
APIs, die ursprünglich
in der Parlay-Gruppe definiert wurden und im Zusammenhang mit 3GPP
und ETSI standardisiert wurden. Die Parlay/OSA APIs, (wobei OSA
für Open
Service Architecture steht), bilden ein Set von neun orthogonalen
Dienstleistungsfähigkeits-Funktionen
(SCFs), von denen jede einen anderen Telekom-Bereich bearbeitet:
Verbindungssteuerung, Benutzerinteraktion, Mobilität, Endgerätefähigkeiten,
Datensitzungssteuerung, generische Mitteilungsübermittlung, Konnektivitäts-Management,
Präsenz/Verfügbarkeit
und Abrechnung.
-
Daher
umfasst ein API-basiertes System des bisherigen Stands der Technik
ein Set von offenen APIs, eine Gruppe von Benutzern, die Informationen über Server
senden und empfangen, ein Telekommunikationsnetzwerk, das die Informationen
und Anwendungen im Besitz von Dritten, die Informationen über die
offenen APIs empfangen, transportiert, eine Anwendung basierend
auf diesen APIs ausführt
und antwortende Informationen über
die offenen APIs an das Netzwerk zurück sendet.
-
Obwohl
sie nützlich
sind, sind API-basierte Systeme des bisherigen Stands der Technik
bedeutenden Einschränkungen
unterworfen. Erstens ist in API-basierten Systemen des bisherigen
Stands der Technik eine Eins-zu-Eins-Beziehung
zwischen offenen API-Servern und Anwendungen vorhanden. Um diese
Einschränkung
zu überwinden,
haben API-basierte Systeme des bisherigen Stands der Technik eine
Registrierungs- und Ermittlungs-Einheit aufgenommen, die von den
offenen API-Servern
verwendet wird, um sich selbst anzumelden, und von den Anwendungen
verwendet wird, um zu ermitteln, welche APIs verfügbar sind.
Wenn mehrere Registrierungs- und Ermittlungs-Einheiten vorhanden
sind, besteht ein grundlegendes Problem darin, welche Registrierungs-
und Ermittlungs-Einheit ein offener API-Server verwenden soll. Um dieses Problem
zu vermeiden, könnte
sich ein offener API-Server selbst bei allen verfügbaren Registrierungs-
und Ermittlungs-Einheiten anmelden. Dies führt jedoch zu einem Problem,
da zum Zuweisen eines offenen API-Servers zu mehreren Registrierungs-
und Ermittlungs-Einheiten die Konfiguration des gesamten Systems
bekannt sein muss, und diese ist schwierig zu bestimmen.
-
Ein
weiteres Problem bei API-basierten Systemen des bisherigen Stands
der Technik ist, nachdem eine Anwendung ermittelt hat, welchen offenen API-Server
sie für
ihre Dienste nutzen kann, dass die Beziehung statisch ist. Obwohl
der ursprüngliche
offene API-Server zu einem gewissen Zeitpunkt von Vorteil gewesen
sein kann, könnte
ein anschließender
Vorfall, wie beispielsweise ein Ausfall eines offenen API-Servers,
riesige Probleme schaffen. In diesem Fall könnte die Anwendung, die einen
bestimmten Dienst bereitstellt, nicht mehr ohne eine Wiederherstellungssitzung
verwendet werden, die von der Anwendung initiiert wurde. Ein weiteres
Problem von offenen API-Systemen des bisherigen Stands der Technik
ist die Schwierigkeit, Dienstgüteverein barungen
durchzusetzen.
-
In
Anbetracht der vorhergehenden (und weiteren) Einschränkungen
wurde ein neues offenes API-basiertes System vorgeschlagen. Dieses
System umfasst offene Anwendungen und offene API-Server, doch fügt das Telekommunikationsnetzwerk
eine Proxy-Vorrichtung zwischen die offenen Anwendungen und die
offenen API-Server ein. Dieser Proxy kann das Hochfahren zum Vermeiden
von Überlappung
abwickeln, bestimmen, welcher offene API-Server (bzw. welche) ein bestimmtes
API-Ereignis oder einen Verfahrensaufruf abwickelt, Kommunikationslasten
zwischen den verschiedenen offenen Anwendungen und offenen API-Servern
im Gleichgewicht halten und Ereignisse zwischen den offenen Anwendungen
und offenen API-Servern
abfertigen.
-
Obwohl
der Proxy ein vielversprechender Zusatz zu offenen API-basierten
Systemen ist, scheitert der vorgeschlagene Proxy daran, andere vorhersehbare
Probleme in erfolgreichen Systemen zu bearbeiten. Daher wäre ein Proxy,
der andere Probleme in einem System auf offener API-Basis bearbeitet, von
Vorteil. Ebenso vorteilhaft wäre
ein Telekommunikationsnetzwerk mit einem Proxy, das andere Probleme
eines offenen API-basierten
Systems bearbeitet. Des Weiteren wäre ein Verfahren zum Betreiben eines
Proxy vorteilhaft, das andere Probleme eines offenen API-basierten
Systems bearbeitet. Ein computerlesbares Medium, das ein Computerprogramm speichert,
welches einen Proxy betreibt, der andere Probleme eines offenen
API-basierten Systems bearbeitet, wäre ebenfalls von Vorteil.
-
Die
internationale Patentanmeldungsveröffentlichung WO 03/017619 A1
von Telefonaktiebolaget L.M. Ericsson und Ard-Jan Moerdijk offenbart
einen sicheren Netzübergang
mit Proxy-Dienstleistungsfähigkeits-Servern
für Dienstgütevereinbarungsprüfungen.
Insbesondere führt
ein Framework Sicherheitsprüfungen
an den Anforderungen von Anwendungen durch, auf einen oder mehrere
externe Dienstleistungsfähigkeits-Server
unter Verwendung von Dienstgütevereinbarungen
zuzugreifen.
-
Der
Artikel mit dem Titel "Design
OSA/PARLAY Application Frameworks Using a Pattern of Language" von Wei Wu und anderen
(International Conference on Communication Technology Proceedings (ICCT)
2003; Institute of Electrical and Electronics Engineers (IEEE),
Band. 2, 9. April 2003, S. 1558–1561,
XP010644263) offenbart Techniken für eine verbesserte Anwendungsentwicklung
unter Verwendung von Open Service Access (OSA)/Parlay. Insbesondere
offenbart das Papier die Verwendung von Software-Muster- und -Framework-Technologien zum
Aufbauen von OSA/Parlay-Anwendungs-Frameworks für den Einsatz bei einer einfacheren
Anwendungsentwicklung.
-
Die
US-amerikanische Patentanmeldungsveröffentlichung US 2002/0026473
A1 von Gourraud, die am 28. Februar 2002 veröffentlicht wurde, offenbart
die Übertragung
von Triggern, die auf einer Anwenderprogrammschnittstelle (API)
basieren, auf einen Dienst-Manager bei Auftreten von vorbestimmten
Ereignissen während
Verbindungen. Insbesondere werden Informationen über Benutzer, die mit spezifischen
Triggern verknüpft
sind, von einer Benutzerprofil-Datenbank zur Verwendung während Verbindungen
heruntergeladen. Der Dienst-Manager,
der als Proxy zwischen den Anwendungen und den Netzwerkeinheiten
dient, führt
das Dienstinteraktions-Management
in Reaktion auf die Trigger durch.
-
KURZDARSTELLUNG
DER ERFINDUNG
-
Ein
Verfahren und eine Vorrichtung gemäß der vorliegenden Erfindung
werden in den selbstständigen
Ansprüchen
dargelegt, auf die der Leser im Folgenden verwiesen wird. Bevorzugte
Merkmale werden in den Unteransprüchen dargelegt.
-
Die
vorher genannten Nachteile, die mit dem bisherigen Stand der Technik
verbunden sind, werden durch einen neuartigen Proxy bearbeitet und
ein Telekommunikationsnetzwerk mit einem solchen Proxy, das die
Einschränkungen
von offenen API-basierten Systemen bearbeitet.
-
Die
vorher genannten Nachteile, die mit dem bisherigen Stand der Technik
verbunden sind, werden durch ein computerlesbares Medium bearbeitet, das
ein Computerprogramm speichert, das einen Proxy betreibt und damit
ein Telekommunikationsnetzwerk, so dass Einschränkungen von offenen API-basierten
Systemen bearbeitet werden.
-
KURZE BESCHREIBUNG
DER ZEICHNUNGEN
-
Die
Lehren der vorliegenden Erfindung lassen sich problemlos unter Berücksichtigung
der folgenden ausführlichen
Beschreibung in Verbindung mit den folgenden begleitenden Zeichnungen
verstehen:
-
1 stellt
eine Übersicht über ein
API-basiertes System dar, das sich nicht in Übereinstimmung mit den Prinzipien
der vorliegenden Erfindung befindet;
-
2 stellt
eine allgemeine Ansicht eines Proxy dar;
-
3A stellt
ein System zum Implementieren einer Dienstleistungsvertragssteuerung
dar;
-
3B stellt
ein Ablaufdiagramm der Implementierung einer Dienstleistungsvertragssteuerung dar;
-
4A stellt
ein geografisch verteiltes offenes API-basiertes System dar;
-
4B stellt
die Registrierung von offenen API-Einheiten dar;
-
4C stellt
einen Proxy dar, der ein offenes API-System überwacht; und
-
5 stellt
ein alternatives API-basiertes System dar, das sich in Übereinstimmung
mit den Prinzipien der vorliegenden Erfindung befindet.
-
Zur
Erleichterung des Verständnisses
wurden, wo möglich,
identische Bezugszeichen verwendet, um identische Elemente zu bezeichnen,
die den Figuren gemeinsam sind.
-
AUSFÜHRLICHE
BESCHREIBUNG
-
Die
vorliegende Erfindung betrifft neuartige API-basierte Verfahren,
Vorrichtungen, computerlesbare Medien und Systeme, die einen Proxy
zwischen Anwendungen und offenen API-Server integrieren. Offene
API-Systeme in Übereinstimmung
mit der vorliegenden Erfindung können
zwei Typen von Informationsströmen
bearbeiten, diejenigen, die in dem Netzwerk ihren Ursprung haben
und an die Anwendung weitergeleitet werden, und diejenigen, die
von den Anwendungen zu dem Netzwerk fließen. Obwohl beide Ströme durch
die APIs übermittelt
werden, wird der erste Typ im Folgenden als ein Ereignis bezeichnet
und der zweite wird als ein Verfahrensaufruf bezeichnet.
-
1 stellt
ein offenes API-basiertes System 100 dar, das sich in Übereinstimmung
mit den Prinzipien der vorliegenden Erfindung befindet. Das System 100 umfasst
Anwendungen 102 und offene API-Server 104, die
Informationen über
offene Anwenderprogrammschnittstellen weitergeben. Die Anwendung 102 kann
ein Programm (bzw. Programme), Unternehmensanwendungssysteme oder
ein anderes Betriebsmittel sein, das unter Verwendung von APIs arbeitet,
die auf Netzwerkbetriebsmittel zugreifen. Die offenen API-Server 104 sind
Kommunikationsknoten, die mit jeder von einer umfangreichen Bandbreite
von Benutzervorrichtungen verbunden sind, wie beispielsweise Computern 106,
Handapparaten 108 oder Telefonsystemen 110. Demzufolge sollten
Benutzervorrichtungen als jede Vorrichtung verstanden werden, die
eine Anwendung 102 auszuführen sucht. Von einer Anwendung 102 angebotene Dienste
werden implementiert, wenn eine der Benutzervorrichtungen einen
offenen API-Server 104 kontaktiert,
der dann in der im Folgenden beschriebenen Weise Informationen an
die Anwendung 102 übergibt.
-
Wie
gezeigt, befindet sich zwischen den offenen API-Servern 104 und den Anwendungen 102 ein Proxy 700.
Die offenen API-Server 104 und der Proxy 700 könnten Bestandteil
eines gemeinsamen Netzwerks 103 sein. Des Weiteren, wobei
die Anwendungen 102 auf einer Anwendungsebene gezeigt sind, ist
es möglich,
dass eine oder mehrere Anwendungen 102 sich auch im Besitz
des Besitzers des Netzwerks 103 befinden oder von diesem
betrieben werden. Wie im Folgenden ausführlicher beschrieben wird,
bearbeitet der Proxy 700 Kommunikationen zwischen den offenen
API-Servern 104 und den Anwendungen 102 transparent.
Zu diesem Zweck authentifizieren die Anwendungen 102 ihre
Anwesenheit zunächst
an dem Proxy 700 und registrieren sie dann, was durch die
Anwendungen 102 vorgenommen wird, die mit einer Registrierungs-
und Ermittlungs-Vorrichtung 114 Kontakt aufnehmen, welche die
Registrierungsinformationen, (wie beispielsweise IP-Adressen, Startbedingungen,
geografische Standorte, zulässige
APIs usw.), empfängt, – oder von
einem Authentifikationsmechanismus aus bestimmen kann, – die von
dem Proxy 700 angefordert werden, um die Anwendung 102 zu
identifizieren, zu akzeptieren und zu verwenden.
-
Die
Registrierung von Anwendungen 102 findet primär statt,
wenn die Anwendungen 102 ihre Startbedingungen anmelden.
Nachdem eine Anwendung 102 authentifiziert worden ist,
kann sie die Dienste ermitteln, auswählen und zu nutzen beginnen,
die von den offenen API-Servern 104 angeboten werden. Durch
die Registrierung bestimmt der Proxy 700 die Fähigkeiten
aller offenen API-Server 104 und kombiniert diese Fähigkeiten
anschließend,
um ein übergeordnetes
Set von Fähigkeiten
zu bilden. Der Proxy 700 registriert anschließend die
Fähigkeiten des übergeordneten
Sets in der Registrierungs- und Ermittlungs-Vorrichtung 114,
wodurch es der Registrierungs- und Ermittlungs-Vorrichtung 114 ermöglicht wird,
ein generischeres Set von Diensten für authentifizierte Anwendungen 102 anzubieten,
die Dienste ermitteln. Dies bietet auch den offenen API-Servern 104 die
Möglichkeit,
sich nur an einem einzigen Standort zu registrieren, und bietet
auch eine zentrale Stelle zum Überwachen
und Verwalten des offenen API-Netzwerks,
das im Folgenden ausführlicher
beschrieben wird.
-
2 stellt
ein Blockschaltbild höchster
Ebene einer Ausführungsform
eines Proxy 700 dar. Der Proxy 700 umfasst einen
Prozessor 710 sowie einen Computerspeicher 720 zum
Speichern von Steuerprogrammen 725 und Datenstrukturen 727.
Der Prozessor 710 wirkt mit einer herkömmlichen Unterstützungsschaltung 730,
wie beispielsweise Stromversorgungen, Taktschaltkreisen, Cache-Speicher
und dergleichen sowie Schaltkreisen zusammen, die das Ausführen der
Software-Routinen unterstützen,
die in dem Speicher 720 gespeichert sind. Daher wird in
Erwägung
gezogen, dass einige der Prozessschritte, die hierin als Software-Prozesse
erläutert
werden, in Hardware implementiert werden können, zum Beispiel als Schaltung,
die mit dem Prozessor 710 zum Durchführen verschiedener Schritte
zusammenwirkt. Der Proxy 700 enthält ebenfalls die Eingabe-Ausgabe-Schaltung 740,
die eine Schnittstelle zu dem gesamten Telekommunikationsnetzwerk,
den Anwendungen 102 und den offenen API-Servern 104 bildet.
-
Obwohl
der Proxy 700 als ein Mehrzweck-Computer dargestellt ist,
der so programmiert ist, dass er verschiedene Steuerfunktionen in Übereinstimmung
mit der vorliegenden Erfindung durchführt, kann die Erfindung in
Hardware implementiert werden, zum Beispiel als eine anwendungsspezifische
integrierte Schaltung (ASIC). Daher sollen die hierin beschriebenen
Prozessschritte allgemein so interpretiert werden, dass sie äquivalent
von Software, Hardware oder einer Kombination davon durchgeführt werden.
Des Weiteren umfasst der Proxy 700, wenn er in Software
oder Firmware implementiert ist, ein computerlesbares Medium 750,
das Informationen speichert, die von dem Prozessor 710 ausgeführt werden
können
und/oder auf die dieser zugreifen kann. Gleichgültig, ob er in Hardware oder
Software oder in einer Kombination aus Hardware/Software implementiert
ist, arbeitet der Proxy 700, um die im Folgenden beschriebenen
Funktionen zu erfüllen.
-
Eine
erste Funktion, die vom Proxy 700 erfüllt wird, besteht darin, Dienstverträge zwischen zwei
oder mehreren der offenen API-Server 104, den Benutzern,
den Anwendungen 102 und den Telekommunikationsnetzwerk-Betreibern durchzusetzen. Beispiele
für die
Parameter, die Teil eines Dienstvertrags sein könnten, umfassen die Betriebsmittelnutzung,
die durch einen offenen API-Server 104 gestattet
wird, z.B. die maximale Anzahl von Verbindungen, die maximale Anzahl
von Verbindungs-Streckenabschnitten,
die pro Verbindung zulässig
sind, die maximale Anzahl von offenen Briefkästen, Abrechnung, Zeitbegrenzungen
und APIs, die zulässig
sind. In einigen Ausführungsformen
verteilt der Proxy 700 Dienstverträge dynamisch auf die offenen
API-Server 104.
-
3A stellt
ein System 200 zum Implementieren einer Dienstvertragssteuerung über den
Proxy 700 dar, während 3B ein
Ablaufdiagramm des Betriebs des Systems 200 darstellt.
Im Folgenden wird auf beide dieser Figuren verwiesen. Das System 200 umfasst
eine Registrierungs- und Ermittlungs-Vorrichtung 114, die
betriebsfähig
mit einer Unternehmens-Benutzeroberfläche 202 und mit dem Proxy 700 über eine
Datenbank 204 verbunden ist. Es sollte jedoch klar sein,
dass die Datenbank 204 optional ist: in einigen Ausführungsformen
ist die Datenbank 204 nicht integriert. Unter folgender
Bezugnahme auf 3B beginnt ein Verfahren 245 einer Dienstvertragssteuerung
in Schritt 247 und fährt
mit Schritt 248 fort, indem Dienstvertragssteuerungs-Informationen
erhalten und registriert werden. Dazu stellt die Unternehmens-Benutzeroberfläche 202 die Bedingungen
eines Dienstvertrags als ein Set von Steuerparametern für die Registrierungs-
und Ermittlungs-Vorrichtung 114 bereit, welche in Schritt 250 die
Steuerparameter in der Datenbank 204 speichert. Als Nächstes ruft
der Proxy 700 in Schritt 251 die Steuerparameter
ab und berechnet in Schritt 252, wie die globalen Vertragsinformationen
als lokale Verträge
zu den relevanten offenen API-Servern 104, (denjenigen,
die von den Bedingungen des Dienstvertrags betroffen sind), zugewiesen
werden sollen. Dann werden in Schritt 253 die lokalen Verträge zu den
offenen API-Servern 104 gesendet, indem der Proxy 700 in
Schritt 254 einzelnen offenen API-Servern 104 ihre
Implementierungsparameter sendet.
-
Nachdem
die offenen API-Server 104 ihre Implementierungsparameter
haben, kann ein Trigger in Schritt 255 veranlassen, dass
ein lokaler offener API-Server 104 bestimmt, dass sein
lokaler Dienstvertrag fehlerhaft ist. Wenn zum Beispiel ein lokaler offener
API-Server 104 auf
10 Verbindungen beschränkt
ist, kann dieser offene API-Server 104, wenn er 8 Verbindungen
bearbeitet, einen Trigger setzen, um anzugeben, dass er unter Umständen eine
Berechtigung benötigt,
mehr als 10 Verbindungen zu bearbeiten. In diesem Fall sendet der
lokale offene API-Server 104 in Schritt 256 eine
Anforderung an den Proxy 700 und fordert eine Modifizierung seines
Dienstvertrags an. Indessen hat der Proxy 700 in Schritt 257 die
offenen API-Server 104 überwacht,
um solche Anforderungen zu identifizieren. Nachdem in Schritt 258 eine
Anforderung für
eine Modifizierung empfangen worden ist, fragt der Proxy 700 in
Schritt 258 die relevanten offenen API-Server nach ihrer
gegenwärtigen
lokalen Nutzung ab. Sobald diese Nutzung bestimmt worden ist, wird
zur erneuten Berechnung der lokalen Verträge der relevanten offenen API-Server
eine Schleife zurück
zum Schritt 252 gebildet. Auf diese Weise kann der Proxy 700 Betriebsmittel
auf der Basis der gegenwärtigen Nutzung
zuweisen, wobei er innerhalb des Dienstvertrags bleibt.
-
Es
sollte klar sein, dass jede Einheit unterschiedlich auf Dienstvertragsbedingungen
reagieren kann. Zum Beispiel kann der Dienstvertrag für den offenen
API-Server 104c spezifizieren,
dass keine zeitkritischen Informationen zu dem oder von dem offenen
API-Server 104c übergeben
werden sollen. Demzufolge kann der Proxy 700 APIs für die anderen offenen
API-Server 104a und 104b eine höhere Priorität einräumen.
-
Nachdem
die Einheiten mit Implementierungsparametern versorgt worden sind,
implementieren die verschiedenen Einheiten in Schritt 255 ihre Teile
der Vertragsbedingungen. Wenn der offene API-Server 104 bestimmt,
dass für
seinen lokalen Dienstvertrag für
ein bestimmtes Set von Anwendungen eine Aktualisierung erforderlich
ist, kann dieser offene API-Server 104 den Proxy abfragen
und im Verfahren 256 eine Aktualisierung des Vertrags anfordern.
Wenn der Dienstvertrag für
das Set von Anwendungen endet, dann endet das Verfahren in Schritt 257.
Wenn zum Beispiel ein Benutzer einen offenen API-Server 104 kontaktiert,
sucht dieser Server seine Dienstvertragsparameter und bestimmt,
ob er die bestimmte Verbindung oder den Dienst bearbeiten kann,
der von dem Benutzer 206 angefordert worden ist. Wenn der
offene API-Server 104a zum Beispiel eine maximale Anzahl
von Verbindungen hat, können
alle diese Anzahl übersteigenden
Verbindungen zurückgewiesen
oder zu einem anderen offenen API-Server 104 umgeleitet
werden.
-
Da
das offene API-Modell immer beliebter wird, wird sich die Anzahl
der offenen API-Einheiten erhöhen.
Dadurch entstehen für
das Modell Verwaltungs- und Integrationsprobleme. Dies stellt eine
besondere Herausforderung dar, da ein offenes API-System aus verschiedenen
Einheiten bestehen kann, die sich an äußerst verschiedenen geografischen
Standorten befinden können.
Da das Verhalten einer offenen API-Einheit überwacht werden muss, um eine
systemübergreifende Übereinstimmung
sicherzustellen, und im Bedarfsfall entsprechende Korrekturmaßnahmen
ergriffen werden müssen,
stellen verschiedene geografische Standorte ein Problem dar. Korrekturmaßnahmen
sind ein Hauptproblem, da systemübergreifende Änderungen
in einem großen
Netzwerk äußerst schwierig,
zeitaufwändig
und teuer sein können.
Der Proxy 700 stellt eine effektive Lösung für solche Probleme bereit. Des Weiteren
kann der Proxy 700 dies auf eine transparente Weise tun.
-
4A stellt
eine geografische Abbildung von Europa dar, in der verschiedene
offene API-Server 104 über
den Kontinent verteilt sind. Alle diese offenen API-Server werden
von dem gleichen Proxy 700 verwaltet. Es sollte klar sein,
dass der Proxy 700 keine einzelne Einheit sein muss, sondern
aus einem Netzwerk von untereinander verbundenen Vorrichtungen,
Systemen und Netzwerken bestehen kann, die zusammenwirkend den Proxy 700 bilden.
Die zentrale Verwaltung dieses Proxy 700 vereinfacht systemübergreifende Änderungen
in hohem Maße, da
diese Änderungen
durch den Proxy 700 verbreitet werden können.
-
4B stellt
dar, wie der Proxy 700 zur zentralen Einheit wird. In Schritt 505 akzeptiert
der Proxy 700 Registrierungen und Registrierungs-Aufhebungen
von den offenen API-Servern 104. In Schritt 507 bestimmt
der Proxy 700 die Dienstleistungsfähigkeiten aller offenen API-Server 104 und
bestimmt dann ein übergeordnetes
Set dieser Fähigkeiten.
Der Proxy 700 registriert anschließend dieses übergeordnete Set
bei allen bekannten Registrierungs- und Ermittlungs-Vorrichtungen 114.
Indem er als ein zentraler Registrierungspunkt arbeitet, erfährt der
Proxy 700 den Status aller offenen API-Server 104,
Registrierungs- und Ermittlungs-Vorrichtungen 114 und Anwendungen
in dem offenen API-Netzwerk.
Dies ermöglicht
es dem Proxy 700, als Verwaltungs- und Integrations-Einrichtung
des gesamten Systems zu arbeiten.
-
4C stellt
ein Verfahren 301 dar, wie der Proxy 700 das System
verwalten und integrieren kann. Wie gezeigt, beginnt das Verfahren 301 in Schritt 303 und
fährt mit
Schritt 315 fort, indem der Betrieb des gesamten offenen
API-Systems überwacht
wird. Wenn in Schritt 317 bestimmt wird, dass das offene
API-System 200 korrekt funktioniert, kehrt das Verfahren
zu Schritt 315 zurück,
wobei die Überwachung
des gesamten Betriebs weiterhin fortgesetzt wird. Wenn in Schritt 317 jedoch
eine Abweichung erfasst wird, fährt
der Proxy 700 mit Schritt 319 fort, in dem eine
geeignete Korrekturmaßnahme
ergriffen wird. Geeignete Maßnahmen
können
das erneute Starten einer Registrierungs- und Ermittlungs-Vorrichtung 114,
das Informieren von Anwendungen 102 über Probleme, die im Netzwerk
erfasst wurden, und/oder das erneute Zuweisen von Startbedingungen
zu offenen API-Servern 104 umfassen, wenn sie wieder aktiv
werden. Es ist zu beachten, dass das Informieren der Anwendungen 102 über Abweichungen
verzögert
oder nicht ausgeführt
werden kann, wenn der Proxy alternative offene API-Server 104 findet,
um die Integrität
des offenen API-Systems 200 zu gewähr leisten.
-
Eine
wichtige Korrekturmaßnahme,
die der Proxy ergreifen kann, besteht darin, als eine Firewall zu
arbeiten, um ungeeignete oder gefährliche APIs daran zu hindern,
sich über
das offene API-System zu verbreiten. Dies gilt insbesondere dann,
wenn eine Registrierungs- und
Ermittlungs-Vorrichtung 114 innerhalb der Domäne eines
fremden Netzwerkbetreibers arbeitet, der seine Netzwerk-Betriebsmittel für Dritte öffnen möchte, die
APIs entwickeln könnten,
die lokale oder systemweite Zusammenbrüche verursachen könnten. Den
Proxy 700 als ein Filter arbeiten zu lassen, um solche
APIs zu sperren, ist besonders vorteilhaft.
-
Wie
oben erläutert,
erkennt der Proxy 700 die anderen offenen API-Systemeinheiten
und kann einen speziellen offenen API-Server 104 direkt
zu einer speziellen Anwendung 102 zuweisen, nicht nur anfänglich,
sondern dynamisch. Zuweisungen können
geändert
werden, um Netzwerkbedingungen widerzuspiegeln, wie beispielsweise
Hinzufügen
von Anwendungen 102 und offenen API-Servern 104, oder
als ein Ergebnis von Systemausfällen.
Diese dynamische Zuweisungsfähigkeit
erhöht
die Netzwerkverfügbarkeit
beträchtlich.
-
Obwohl
das Vorgenannte vermuten lässt, dass
alle Kommunikationen zwischen den Anwendungen 102 und den
offenen API-Servern 104 durch den Proxy 700 verlaufen,
ist solches nicht erforderlich. 5 stellt
ein offenes API-System 400 dar, in welchem gewisse API-Verbindungen
den Proxy 700 umgehen und direkt zwischen dem offenen API-Server 104b und
der Anwendung 102b verlaufen. Wie gezeigt, wird eine spezielle
Verbindung, die als IpCall bezeichnet wird, direkt auf Leitungen 401 übertragen. Andere
API-Verbindungen werden jedoch vom Proxy 700 bearbeitet.
Eine direkte Weiterleitung kann verhindern, dass der Proxy 700 zum
Leistungsengpass wird.
-
5 zeigt
des Weiteren Software- (oder Hardware-) Prozesse, die von dem Proxy 700 durchgeführt werden.
Solches umfasst Dienstvertrags-Software 402, welche die
vorher beschriebenen Dienstverträge
bearbeitet, Lastausgleichs-Software 404, die ein Gleichgewicht
der Kommunikationslasten zwischen den offenen API-Servern 104 und
den verschiedenen Anwendungen 102 herstellt, Verwaltungs-Software 406,
welche die offenen API-Einheiten wie vorher beschrieben verwaltet,
und einen Ereignis-Verteiler 408, der die Abfertigung der verschiedenen
API-Verbindungen zwischen den offenen API-Servern 104 und den Anwendungen
steuert. Der Vollständigkeit
halber zeigt 5 auch die Registrierungs- und
Ermittlungs-Vorrichtung 114 und die Datenbank 204.
-
Wenn
er richtig konfiguriert ist, ist der Proxy 700 transparent:
ein offener API-Server 104 muss nicht wissen, dass er über den
Proxy 700 kommuniziert, und eine Anwendung 102 muss
nicht wissen, dass sie über
den Proxy 700 kommuniziert, außer eventuell während der
ersten Registrierung. Der Proxy 700 kann die richtigen
Hochfahrbedingungen bereitstellen, entscheiden, welche konkurrierende
Anwendung ein Ereignis empfängt,
wenn mehrere Anwendungen verfügbar
sind, (als Verkehrspolizist arbeiten), Verzögerungen in Weiterleitungs-Ereignisse einfügen, um
potenzielle Probleme zu vermeiden, zentrale Verwaltungsfunktionen
bereitstellen, Dienstverträge
implementieren, das Netzwerk verbergen, es vorziehen, ausstehende
oder neue Anforderungen zu anderen Betriebsmitteln weiterzuleiten,
(wodurch die Netzwerkverfügbarkeit
erhöht
wird), als eine Firewall arbeiten, um die Integrität des Systems aufrecht
zu erhalten, Informationen von mehreren Betriebsmitteln sammeln
und die Informationen nach Erfordernis und/oder zum richtigen Zeitpunkt
verteilen, systemübergreifende Änderungen
und ihre Integration erleichtern, und Anwendungen 102 und
offene API-Server 104 zentral überwachen.
-
Obwohl
sich das Vorgenannte auf Ausführungsformen
der vorliegenden Erfindung bezieht, sind andere und weitere Ausführungsformen
der Erfindung vorstellbar, ohne von ihrem Grund legenden Umfang
abzuweichen, und ihr Grund legender Umfang wird durch die folgenden
Ansprüche
bestimmt.