DE60203303T2

DE60203303T2 - Migrationsstützmechanismus im offenen dienst und offene mobilarchitektur

Info

Publication number: DE60203303T2
Application number: DE60203303T
Authority: DE
Inventors: Ard-Jan Moerdijk; Hans-Erik Van Elburg
Original assignee: Telefonaktiebolaget LM Ericsson AB
Current assignee: Telefonaktiebolaget LM Ericsson AB
Priority date: 2001-08-31
Filing date: 2002-08-29
Publication date: 2006-03-16
Anticipated expiration: 2022-08-30
Also published as: CN1550093A; US20030061268A1; CN100566329C; US7246349B2; WO2003021904A2; EP1421764B1; JP2005502145A; ES2237709T3; WO2003021904A3; JP4335676B2; CA2463050A1; EP1421764A2; AU2002333753A1; ATE291320T1; DE60203303D1; CA2463050C

Description

Gebiet der Erfindung
Die vorliegende Erfindung bezieht sich auf die offene Dienstarchitektur, und genauer auf ein Verfahren zum Helfen, Anwendungen von einem Dienstermöglicher (service enabler) zu einem anderen Dienstermöglicher in der offenen Dienstarchitektur zu migrieren.
Hintergrund der Erfindung
In einem heutigen Netz sind Anwendungen und Dienste ein Teil der Domäne des Netzbetreibers und sind unter Verwendung intelligenter Netztechnologie aufgebaut. Dieser Ansatz ist für einfache Anwendungen für den Massenmarkt ausgezeichnet, aber mit der Entstehung von Mobilität und dem Internetprotokoll wird eine rasche Aufstellung von innovativen Anwendungen, die unterschiedliche Merkmale und kritische Unternehmensdaten kombinieren, eine Herausforderung.
Eine Reihe von industriellen Foren und Standardisierungsgremien, wie etwa Parlay und 3GPP, haben diese Herausforderung angesprochen und APIs (Anwendungsprogrammschnittstellen) spezifiziert, die als eine Schnittstelle zwischen den Anwendungen und Kernnetzen dienen. Der Begriff offene Dienstarchitektur (Open Service Architecture) verweist auf die Menge von APIs, die durch Parlay, 3GPP und ETSI entwickelt wurden. Innerhalb der offenen Dienstarchitektur existiert ein Basismechanismus, den eine Anwendung innerhalb der OSA abonnieren kann, um benachrichtigt zu werden, wenn ein neues Dienstfä higkeitsmerkmal (SCF, service capability feature) verfügbar wird. EP 1,120,979 legt ein Verfahren zum Ausführen einer Dienstvereinbarung offen, die Zugriff durch eine Dienstanwendung auf mindestens einen Dienstknoten gestattet, der angeforderte Dienstressourcen vorsieht, die in einem Dienstknoten verfügbar sind, der mit einem Kommunikationsnetz verbunden ist. Dieser Mechanismus sieht jedoch keine Angabe bezüglich des Umfangs vor, zu dem das neue SCF mit existierenden SCFs rückwärts kompatibel ist, die die Anwendung gegenwärtig verwendet. Somit existiert ein Bedarf innerhalb der offenen Dienstarchitektur nach einem Mechanismus zum Informieren einer Anwendung über die Kompatibilität von neuen SCFs mit existierenden SCFs.
Zusammenfassung der Erfindung
Die vorliegende Erfindung überwindet die vorangehenden und andere Probleme mit einem System und einem Verfahren zum Migrieren zwischen einem ersten und einem zweiten Dienst in einer offenen Dienstarchitektur. Ein zweiter Dienst registriert sich mit einem offenen Dienstarchitekturrahmen und reagierend darauf wird ein Vergleich zwischen den Eigenschaften des zweiten Dienstes und den Eigenschaften des ersten Dienstes durchgeführt um zu bestimmen, ob der zweite Dienst mit dem ersten Dienst rückwärts kompatibel ist. Information bezüglich dessen, ob der zweite Dienst mit dem ersten Dienst rückwärts kompatibel ist, wird nach dem Vergleich zu mindestens einer Anwendung weitergeleitet, die den ersten Dienst verwendet.
Kurze Beschreibung der Zeichnungen
Ein vollständigeres Verständnis des Verfahrens und der Vorrichtung der vorliegenden Erfindung kann durch Verweis auf die folgende detaillierte Beschreibung erhalten werden, wenn in Verbindung mit den begleitenden Zeichnungen aufgenommen, worin:
1 eine logische Netzarchitektur dritter Generation veranschaulicht;
2 einen Überblick über die offene Dienstarchitektur veranschaulicht;
3 verschiedene Funktionalitäten des OSA-Rahmens veranschaulicht;
4 eine Dienstregistrierung durch eine Anwendung innerhalb der offenen Dienstarchitektur veranschaulicht; und
5 ein Flussdiagramm ist, das das Verfahren der vorliegenden Erfindung für eine Hilfe veranschaulicht, um Anwendungen zu einem neuen SCF migrieren.
Detaillierte Beschreibung der Ausführungsformen
Bezug nehmend nun auf 1 basiert die Netzarchitektur von Netzen dritter Generation auf horizontalen Schichtungsprinzipien, wo Anwendungen 40 und Anwendungsserver 45 logisch in der oberen Schicht gefunden werden, die die Anwendungs- oder Dienstnetz 10 genannt wird. Der Begriff Dienstnetz wird verwendet, um es von dem Kernnetz 15 zu unterscheiden, das sich in den unteren Schichten befindet. Das Dienstnetz 10 basiert auf offener verteilter Technologie (JAVA, CORBA) und Anwendungen, die in der Lage sind, auf Kernnetzfunktionalität mittels offener und standardisierter Anwendungsprogrammschnittstellen (APIs) 20 zuzugreifen, durch die sie mit einem oder mehr Dienstfähigkeitsservern (SCS, service capability server) 50 kommunizieren können. SCS 50 können sich mit verschiedenen Netzen verbinden, wie etwa Mobilnetzen 5, IP-Netzen 6 und/oder Festnetzen 7.
In der geschichteten Architektur, die in 2 gezeigt wird, umfasst die offene Dienststruktur (OSA) eine Anwendungsprogrammschnittstelle zwischen dem Dienstnetz 10 und dem Kernnetz 15. Während die Erfindung mit Bezug auf die offene Dienstarchitektur beschrieben wird, wie durch Parlay, 3GPP und ETSI definiert, ist die Erfindung auch für webdienst-basierte Ansätze anwendbar, wo die spezifischen Implementierungsdetails etwas unterschiedlich als in OSA sein können. Anwendungen 40, die auf Anwendungsservern 45 aufgestellt sind, nutzen Dienstfähigkeitsmerkmale, die durch Dienstfähigkeitsserver (SCSs) 50 bereitgestellt werden. Dienstfähigkeitsserver 50 sind logische Entitäten, die die Dienstfähigkeitsmerkmale (SCFs) 35 implementieren und mit dem Kernnetz 15 interagieren. Die Anwendungen 40 und Anwendungsserver 45 befinden sich innerhalb der Dienstnetzschicht 10, wie zuvor beschrieben. Somit kann gesehen werden, dass die offene Dienstarchitektur 30 als eine API zwischen der Dienstnetzschicht 10 und der Kernnetzschicht 15 agiert.
Der OSA-Rahmen 55 ist ein Registrations- und Offenlegungsserver, der die Offenheit der offenen Systemarchitektur ermöglicht und es möglich macht, über IN (intelligente Netze) hinaus zu gehen, wenn es zu Offenheit, Offenlegung und Integration von neuen Merkmalen kommt, wie nachstehend beschrieben. Der OSA-Rahmen 55 benachrichtigt auch Anwendungen über die Hinzufügung von neuen Dienstfähigkeitsmerkmalen innerhalb der offenen Dienstarchitektur 30. Der OSA-Rahmen 55 sieht auch gesteuerten Zugriff auf die SCSs 50 vor, was in Kombination mit der verteilten Technologie Flexibilität in Anwendungsstandorten und Geschäftsszenarien unterstützt. Des weiteren erlaubt er Mehrfachanbieterschaft und sogar Erweiterung der Menge von APIs.
Wie in 3 gezeigt, ist der OSA-Rahmen 55 tatsächlich eine Familie von Dienstfähigkeitsmerkmalen 35 mit dem Kernabschnitt, der aus Vertrauens- und Sicherheitsmanagement 60 besteht, was die Authentifizierung einer Domäne ermöglicht; Dienstoffenlegung 65, die die Offenlegung eines neuen SCF ermöglicht, das durch den Betreiber bereitgestellt wird; Dienstregistrierung 70, die die Registrierung von neuen SCFs mit dem Rahmen vorsieht; und Dienstfabrik 75, die die Erstellung von neuen SCF-Instanzen ermöglicht. Zusätzlich sind APIs für Integritätsmanagement 80, wie etwa Lastausgleich, Störungsmanagement und Herzschlag- und Ereignisbenachrichtigung 85, was Benachrichtigungen für spezifische Ereignisse vorsieht, vorgesehen.
Bezug nehmend nun auf 4 wird die Art und Weise veranschaulicht, auf die eine Anwendung eine Verwendung eines SCF 35 beginnen kann, das durch einen neuen Dienstfähigkeitsserver (SCS) 50 bereitgestellt wird. In einer ersten Stufe wird ein SCS 50 den OSA-Rahmen 55 kontaktieren und eine Authentifizierung und Registrierungsschnittstelle in Schritten 90 und 95 anfordern. Als Nächstes verwendet der SCS 50 die Registrierungsschnittstelle, um in Schritt 100 seine Fähigkeiten zu veröffentlichen und einen Verweis auf seine Dienstfabriken hinzuzufügen. Das Fabrikmuster ist ein allgemeines Gestaltungsmuster und erlaubt dem OSA-Rahmen 55, den SCS 50 aufzufordern, eine SCF-35-Schnittstelle zu erstellen. In diesem Moment kennen der OSA-Rahmen 55 und der SCS 50 einander.
Die Anwendung 40 kontaktiert den OSA-Rahmen 55 und wird in Schritt 105 authentifiziert. Die Anwendung 40 fordert in Schritt 110 eine Offenlegungsschnittstelle an. Der OSA-Rahmen 55 gibt einen Verweis oder Zeiger zu der Offenlegungsschnittstelle zurück, wonach die Anwendung 40 diese Schnittstelle verwendet, um in Schritt 115 den Typ von SCF 35 und spezielle Fähigkeiten anzufordern, die durch die Anwendung 40 benötigt werden. Zu dieser Zeit verfolgt der OSA-Rahmen 55, ob der Anwendung 40 erlaubt ist, das SCF 35 zu verwenden und unter welchen Bedingungen. Dies wird in der Dienstebenenübereinkunft (SLA, service level agreement) zwischen dem Netzbetreiber und dem Dienstanbieter abgefangen. Falls der Anwendung erlaubt ist, das SCF 35 zu verwenden, gibt der OSA-Rahmen 55 alle IDs von SCFs 35 zurück, die die Bedürfnisse der Anwendung erfüllen könnten.
Als Nächstes wählt die Anwendung 40 in Schritt 120 eines der SCFs 35 und signiert die so genannte Dienstübereinkunft. Der OSA-Rahmen 55 kontaktiert die Dienstfabrik des SCS 50 und leitet in Schritt 125 die Bedingungen weiter, unter denen der Anwendung erlaubt ist, die SCFs 35 zu verwenden. Der SCS 50 erstellt eine SCF-35-Instanz, die durch diese Anwendung zu verwenden ist, und ist auch in der Lage, die Bedingungen in Schritt 130 zu prüfen, und der Rahmen gibt den Verweis oder Zeiger auf die Anwendung in Schritt 135 zurück. Von diesem Punkt an ist die Anwendung autorisiert, das SCF 35 zu verwenden. Während dieser beschriebene Registrierungs- und Offenlegungsprozess dem Rahmen erlaubt, eine Anwendung über verschiedenartig verfügbare SCFs 35 und über die Benachrichtigungsschnittstelle die potenzielle Verfügbarkeit eines neuen SCS 50 zu informieren, existiert kein Mechanismus zum Benachrichtigen einer Anwendung über Rückwärtskompatibilität eines neuen SCF 35 mit zuvor existierenden SCFs 35. Anwendungen können die Ereignisbenachrichtigungs-API in dem Rahmen 55 verwenden, um Ereignisse zu abonnieren. Ein Beispiel eines Ereignisses ist, wenn ein neues SCF verfügbar gemacht wird.
Bezug nehmend nun auf 5 wird ein Verfahren zum Bestimmen von Rückwärtskompatibilität für ein SCF veranschaulicht. Wenn ein neues SCF verfügbar gemacht wird, muss sich das SCF zuerst in Schritt 150 mit dem OSA-Rahmen 55 registrieren, wie zuvor mit Bezug auf 4 beschrieben. Während dieses Prozesses versorgt das SCF den OSA-Rahmen 55 in Schritt 155 mit den Eigenschaften, die durch diese Implementierung des SCF unterstützt werden. Der OSA-Rahmen 55 hat Information über jede der existierenden SCF-Implementierungen, die innerhalb einer spezifischen Netzbetreiberdomäne verfügbar sind, Information über die Anwendungen, die sie verwenden, und die Einschränkungen, die auf die Verwendung der SCFs durch die Dienstebenenübereinkünfte angewendet werden. Unter Verwendung dieser Information ist der OSA-Rahmen in der Lage, in Schritt 160 eine Prüfung der Eigenschaften der neuen SCF-Implementierung gegenüber zuvor existierenden Versionen durchzuführen. In dieser Prüfung wird eine Angabe bezüglich des Grades erhalten, zu dem die neue SCF-Implementierung mit anderen Versionen von SCFs rückwärts kompatibel ist, die durch das Netz verwendet werden. Diese Information wird in Schritt 165 zu den Anwendungen, die frühere Versionen des SCF verwenden, gemeinsam mit optionalen Verweisen auf die Schnittstelle des neuen SCS weitergeleitet. Um Verweise auf die Schnittstellen vorzusehen, würde eine Erweiterung des aktuellen Rahmenbenachrichtigungsmechanismus genutzt werden. Der Rahmenbenachrichtigungsmechanismus kann durch dedizierte Diensteigenschaften geleitet werden, die spezifizieren, dass die SCF-Implementierung eine spezifizierte ältere SCF-Implementierung ersetzt oder überholt, oder eine Migrationsstrategie spezifizieren. Die Information über den Grad von Rückwärtskompatibilität, die Tatsache, dass die SCF-Implementierung ein älteres SCF ersetzt oder überholt, Migrationsstrategie etc. können entweder durch den neuen SCS zugeführt und zu der Anwendung über den Rahmen gesendet werden oder durch den Rahmen nach Analyse der Eigenschaften des neuen SCS, wenn er sich registriert, oder durch beides in Verbindung.
Durch Implementierung dieser beschriebenen Erweiterung können nahtlose Migrationen oder Anwendungen zwischen älteren und neueren Versionen von SCF-Implementierungen ermöglicht werden. Dies würde einem Betreiber erlauben, ein SCF nahezu automatisch zu überholen oder zu aktualisieren. Es würde ferner einem Betreiber erlauben, ein SCF für Wartungsaktivitäten durch Lenken der Anwendungen auf ein Sicherungs-SCF außer Dienst zu nehmen.
Die vorherige Beschreibung ist für eine bevorzugte Ausführungsform zum Implementieren der Erfindung, und der Bereich der Erfindung sollte nicht notwendigerweise durch diese Beschreibung begrenzt werden. Stattdessen wird der Bereich der vorliegenden Erfindung durch die folgenden Ansprüche definiert.

Claims

Verfahren umfassend die Schritte: Registrieren (150) eines zweiten Dienstes bei einem Registrierungs- und Discovery- bzw. Suchserver; Vergleichen (160) von Eigenschaften des zweiten Dienstes mit Eigenschaften mindestens eines ersten Dienstes, um zu bestimmen, ob der zweite Dienst mit dem mindestens einen ersten Dienst abwärtskompatibel ist; und Weiterleiten (165) von Information darüber, ob der zweite Dienst mit dem mindestens einen ersten Dienst abwärtskompatibel ist, an mindestens eine den mindestens einen ersten Dienst verwendende Applikation.
Verfahren nach Anspruch 1, wobei der Registrierungs- und Discovery- bzw. Suchserver ein Rahmenwerk für eine offene Dienstearchitektur umfasst.
Verfahren nach einem der vorhergehenden Ansprüche, ferner einen Schritt umfassend des Versehens des Rahmenwerks für eine offene Dienstearchitektur mit mindestens einer von dem zweiten Dienst unterstützten Eigenschaft.
Verfahren nach einem der vorhergehenden Ansprüche, wobei der Schritt des Weiterleitens ferner einen Schritt umfasst des Weiterleitens von Information darüber, ob der zweite Dienst abwärtskompatibel ist mit dem mindestens einen ersten Dienst, an eine Vielzahl von den mindestens einen ersten Dienst verwendende Applikationen.
Verfahren nach einem der vorhergehenden Ansprüche, wobei der zweite und mindestens ein erster Dienst ein Dienstfähigkeitsmerkmal umfassen.
Verfahren nach einem der vorhergehenden Ansprüche, wobei der Schritt des Weiterleitens ferner den Schritt umfasst des Weiterleitens von Pointers bzw. Zeigern zu mindestens einer Schnittstelle einer den Dienst bereitstellenden funktionalen Einheit.
Verfahren nach Anspruch 6, wobei die funktionale Einheit einen Dienstfähigkeitsserver umfasst.
Verfahren nach einem der vorhergehenden Ansprüche, wobei die Information angibt, ob der zweite Dienst den mindestens einen ersten Dienst ersetzt.
Verfahren nach einem der vorhergehenden Ansprüche, wobei die Information angibt, ob der zweite Dienst den mindestens einen ersten Dienst inaktuell werden lässt.
Verfahren nach einem der vorhergehenden Ansprüche, wobei die Information eine Migrationsstrategie von dem zweiten Dienst zu dem mindestens einen ersten Dienst angibt.
Verfahren nach einem der vorhergehenden Ansprüche, wobei die Information von dem zweiten Dienst bereitgestellt wird.
Verfahren nach einem der vorhergehenden Ansprüche 1–10, wobei die Information von dem Registrierungs- und Discovery- bzw. Suchdienst bereitgestellt wird.
Verfahren nach einem der vorhergehenden Ansprüche, ferner einen Schritt umfassend des Ersetzens des mindestens einen ersten Dienstes durch den zweiten Dienst.
Offene Systemarchitektur, umfassend: mindestens einen Dienstfähigkeitsserver (50), der mindestens ein erstes Dienstfähigkeitsmerkmal und ein zweites Dienstfähigkeitsmerkmal bereitstellt; und ein Rahmenwerk (55) für die offene Systemarchitektur, ausgebildet zum Registrieren des zweiten Dienstfähigkeitsmerkmals bei dem Rahmenwerk für die offene Dienstearchitektur, Vergleichen von Eigenschaften des zweiten Dienstfähigkeitsmerkmals mit Eigenschaften des ersten Dienstfähigkeitsmerkmals zum Bestimmen, ob das zweite Dienstfähigkeitsmerkmal abwärtskompatibel ist mit dem ersten Dienstfähigkeitsmerkmal, und Weiterleiten von Information darüber, ob das zweite Dienstfähigkeitsmerkmal abwärtskompatibel ist mit dem ersten Dienstfähigkeitsmerkmal, an mindestens eine das erste Dienstfähigkeitsmerkmal verwendende Applikation.
Offene Systemarchitektur nach Anspruch 14, wobei das Rahmenwerk für die offene Systemarchitektur ferner ausgebildet ist zum Bestimmen mindestens einer von dem zweiten Dienstfähigkeitsmerkmal unterstützten Eigenschaft.
Offene Systemarchitektur nach einem der Ansprüche 14 und 15, wobei das Rahmenwerk für die offene Systemarchitektur ferner ausgebildet ist zum Weiterleiten von Information darüber, ob das zweite Dienstfähigkeitsmerkmal mit dem ersten Dienstfähigkeitsmerkmal abwärtskompatibel ist, an eine Vielzahl von das erste Dienstfähigkeitsmerkmal verwendende Applikationen.
Offene Systemarchitektur nach einem der Ansprüche 14–16, wobei das Rahmenwerk für die offene Systemarchitektur ferner ausgebildet ist zum Weiterleiten von Pointers bzw. Zeigern an mindestens eine Schnittstelle des mindestens einen Dienstfähigkeitsservers, der das erste Dienstfähigkeitsmerkmal bereitstellt.
Offene Systemarchitektur nach einem der Ansprüche 14–17, wobei die Information angibt, ob das zweite Dienstfähigkeitsmerkmal das erste Dienstfähigkeitsmerkmal ersetzt.
Offene Systemarchitektur nach einem der Ansprüche 14–18, wobei die Information angibt, ob das zweite Dienstfähigkeitsmerkmal das erste Dienstfähigkeitsmerkmal inaktuell werden lässt.
Offene Systemarchitektur nach einem der Ansprüche 14–19, wobei die Information eine Migrationsstrategie von dem zweiten Dienstfähigkeitsmerkmal zu dem ersten Dienstfähigkeitsmerkmal angibt.