DE102013212258A1

DE102013212258A1 - Herunterladbare einfügbare Dienste

Info

Publication number: DE102013212258A1
Application number: DE102013212258.6A
Authority: DE
Inventors: Kurt Haserodt; William T. Walker
Original assignee: Avaya Inc
Current assignee: Avaya Inc
Priority date: 2012-09-22
Filing date: 2013-06-26
Publication date: 2014-03-27
Also published as: GB2518535A; US20140089915A1; GB201311099D0; KR20140039124A; GB201418792D0; US9690559B2; GB2506232A; KR101481900B1

Abstract

Herunterladbare einfügbare Dienste und Verfahren zum Verteilen dieser werden beschrieben. Die herunterladbaren einfügbaren Dienste korrespondieren möglicherweise mit Kommunikationsdiensten, die heruntergeladen werden können, um für ein Kommunikationssystem ein Upgrade auszuführen. Die herunterladbaren einfügbaren Dienste beinhalten möglicherweise eine Anzahl von Komponententeilen, die unter verschiedenen Servern im Kommunikationssystem, für das ein Upgrade ausgeführt wird, verteilt werden können, nebst Befehlen, die ermöglichen, dass die Komponententeile jedem Server im Kommunikationssystem einen koordinierten Betrieb befehlen, um den heruntergeladenen Dienst zur Verfügung zu stellen.

Description

GEBIET DER OFFENBARUNG
Die vorliegende Offenbarung betrifft allgemein Kommunikationen und insbesondere Kommunikationssysteme und -verfahren.
ALLGEMEINER STAND DER TECHNIK
Kommunikationssysteme sind entwickelt worden, um modulare Anwendungen zu liefern, die im Rahmen der normalen Anrufsignalisierung sequenziert oder benannt werden. Das Versprechen für diese Systeme lautet, dass viele Anwendungen für verschiedene Suchräume geschrieben werden können. Bisher konnte ein Anwendungsserver nur eine einzige komplexe Anwendung mit Releases, die bestenfalls halbjährlich herauskommen, zur Verfügung stellen.
In den meisten Kommunikationssystemen werden Verbindungsbearbeitungsfeatures derzeit von einem einzelnen, monolithischen Featureserver zur Verfügung gestellt. Wenn auf einem Server ein neues Verbindungsbearbeitungsfeature hinzugefügt oder für ein bestehendes Verbindungsbearbeitungsfeature ein Upgrade ausgeführt wird, ist hierfür eine neue Softwareversion erforderlich und der Kunde muss für den gesamten Server ein Upgrade ausführen. Solche Upgrades können zu Betriebsstillstandzeiten führen und können Auswirkungen haben, die nicht auf Nutzer des neuen/Upgrade-Features beschränkt sind. Mit anderen Worten, derzeitige Kommunikationssysteme ermöglichen keine praktischen System-Upgrades und sie ermöglichen auch keine einfachen Upgrades für einzelne Nutzer/Nutzerinnen.
Um eine raschere Entwicklung herbeizuführen, ist eine Umgebung wünschenswert, welche eine unabhängige Entwicklung und Bereitstellung von Anwendungen gewährt.
KURZE DARSTELLUNG DER ERFINDUNG
Die hierin dargelegten Ausführungsformen wurden mit Bezug auf die obigen Aspekte und andere Probleme erarbeitet. Vor allem schlagen Ausführungsformen der vorliegenden Offenbarung die Möglichkeit vor, unter anderem zuzulassen, dass unterschiedliche Nutzer/Nutzerinnen desselben Kommunikationssystems unterschiedliche Dienste und unterschiedliche Versionen haben, die derselbe Dienst für sie verfügbar gemacht hat. Speziell können unterschiedliche Untermengen von Nutzern/Nutzerinnen unterschiedliche Dienste und/oder Dienstversionen haben, die für sie verfügbar gemacht wurden, wobei die Dienste beispielsweise einen Anrufverarbeitungsteil, einen Nutzerschnittstellenteil und einen Verwaltungsteil beinhalten.
In einigen Ausführungsformen wird dies dadurch ermöglicht, dass ein Kommunikationssystemadministrator einen neuen Dienst oder eine neue Version eines bestehenden Dienstes herunterladen kann und die notwendigen Abschnitte dieses Dienstes oder dieser Version an den entsprechenden Einrichtungen im Kommunikationssystem installiert werden. Der Administrator kann den neuen Dienst oder die neue Dienstversion daraufhin speziellen Nutzern/Nutzerinnen oder speziellen Gruppen von Nutzern/Nutzerinnen zuweisen, andere Nutzer/Nutzerinnen oder andere Gruppen von Nutzern/Nutzerinnen jedoch ausschließen.
Ein Vorteil der vorliegenden Offenbarung besteht darin, dass eine neue Version eines Dienstes eher an einem einzelnen Nutzer/einer einzelnen Nutzerin ausgetestet werden kann, statt die neue Version des Dienstes systemweit zu testen, wie derzeit erforderlich ist. Weil das Rollout der neuen Version des Dienstes langsam erfolgen kann (z. B. jeweils für nur einen Nutzer/eine Nutzerin), sind mit Dienst-Upgrades weitaus geringere Auswirkungen assoziiert. Ferner können die Bugs für eine kleine Gruppe von Nutzern/Nutzerinnen ermittelt werden, bevor für alle Nutzer/Nutzerinnen des Systems ein Upgrade ausgeführt wird.
Ein weiterer Aspekt der vorliegenden Offenbarung besteht darin, die Möglichkeit zur Verfügung zu stellen, dass eine neue Dienstversion oder ein vollkommen neuer Dienst im Hot Deployment (ohne Stillstandzeit während des Upgrades) bereitgestellt wird.
Ein Beispiel für ein Hot Deployment eines Dienstes besteht darin, dass einem Nutzer/einer Nutzerin, der/die ein Upgrade empfängt, dieses Upgrade möglicherweise während eines Anrufs zugewiesen und das Upgrade während des Anrufs im Hintergrund abgeschlossen wird, derart, dass der neue Dienst, sobald der Nutzer/die Nutzerin mit dem Anruf fertig ist, sofort verfügbar ist. Vor allem ermöglicht der Upgrade-Vorgang, dass jede Komponente des neuen Dienstes an die entsprechende Komponente verteilt und installiert wird, ohne dass die vorherige Version desselben Dienstes ersetzt wird. Falls der Dienst zufällig bereitgestellt wird, während ein betroffener Nutzer/eine betroffene Nutzerin gerade telefoniert, führt der betroffene Nutzer/die betroffene Nutzerin diesen Anruf deshalb unter Nutzung der alten Dienstversion fort. Nachdem der Nutzer/die Nutzerin den Anruf abgeschlossen hat, kann der Nutzer/die Nutzerin auf die neue Version des Dienstes zugreifen.
Ferner kann ein Dienst einer kleinen Menge von Nutzern/Nutzerinnen zugewiesen werden. Wenn es wünschenswert wird, den Dienst einer größeren Gruppe von Nutzern/Nutzerinnen zuzuordnen, ist nur erforderlich, die Berechtigungen für die neu zugewiesenen Personen zu ändern. Es ist nicht nötig, auf der Einrichtung jedes Nutzers/jeder Nutzerin irgendeine weitere Software bereitzustellen, und dies kann wiederum während der Laufzeit erfolgen.
Wie nachvollzogen werden kann, sollte ein neuer Dienst als Upgrade der bestehenden allgemeinen Gesamtfunktionalität angesehen werden. Deshalb schließen Ausführungsformen der vorliegenden Offenbarung Upgrades sowohl bestehender Dienste als auch neuer Dienste ein.
In einigen Ausführungsformen beinhaltet ein einfügbarer Dienst eine Anrufverarbeitungskomponente, eine Nutzerkomponente, eine Verwaltungskomponente und eine Vorlagenkomponente. In einigen Ausführungsformen ist die „Vorlagenkomponente” das, was basierend auf dem neuen Dienst/der neuen Version bestehenden Vorlagen hinzugefügt/in bestehende Vorlagen eingefügt wird. Wie hierin genutzt, umfasst eine Vorlage möglicherweise eine Mehrzahl von Vorlagenkomponenten, wobei jede Vorlagenkomponente mit einem anderen bereitgestellten Dienst oder einer anderen bereitgestellten Dienstversion korrespondiert. Administratoren erzeugen eine oder mehrere Vorlagen mit speziellen Diensten, die aktiviert werden, und speziellen Konfigurationseinstellungen für diese Dienste. Indem der Administrator diese Vorlage erzeugt und sie einem/einer oder mehreren Nutzern/Nutzerinnen zuweist, kann er genau steuern, welche Dienste und Einstellungen jeder Nutzer/jede Nutzerin empfängt. Deshalb kann der Administrator eine Dienstversion oder Gruppen von Dienstversionen im Auftrag des Nutzers/der Nutzerin auswählen.
Falls ein Administrator über die Vorlagen definiert, dass ein Nutzer/eine Nutzerin über eine einer Mehrzahl unterschiedlicher Dienstversionen verfügen darf, darf der Nutzer/die Nutzerin möglicherweise auswählen, welche Dienstversion er/sie nutzt. In diesem Beispiel lassen die Vorlagen zu, dass der Systemadministrator definiert, welche Versionen ein Nutzer/eine Nutzerin nutzen darf, und die Nutzer/Nutzerinnen können daraufhin auswählen, welche spezielle Version eines Dienstes sie über die Nutzerschnittstellenkomponente tatsächlich nutzen.
In einigen Ausführungsformen werden die unterschiedlichen Komponenten eines einfügbaren Dienstes möglicherweise in einem speziellen Dateiformat, etwa einer JAR- oder einer WAR-Datei, eingepackt. Beispielsweise beinhaltet ein ,Dienst'-Behälter für Dynamic Device Pairing (DDP) möglicherweise einen Anrufverarbeitungsteil, einen Dienstregelteil, einen Nutzerportal-/-schnittstellenteil, den Systemverwalter- oder -administratorteil und vielleicht noch andere Komponenten (z. B. landesspezifische Komponenten, Sprachkomponenten usw.). Statt alle möglichen Unterkomponenten (z. B. alle Skins, alle Sprachen) in den Gesamtdienstbehälter aufzunehmen, könnte der Nutzer/die Nutzerin diejenigen wählen, die er/sie haben möchte, woraus ein sehr spezialisierter Dienst resultiert. Falls der Nutzer/die Nutzerin für sein/ihr Nutzerportal beispielsweise ein schwedisches Erscheinungsbild wünscht, könnte er/sie dieses bei der Gesamtdienstbestellung festlegen, und die Entität, die den Dienst verteilt, würde den Dienst nur mit dieser Skin erstellen. Andere Teile könnten ebenfalls geändert werden, zum Beispiel die Dienstregel. Eine dynamische Anpassung lässt zu, dass ein Dienst eine Mehrzahl von Persönlichkeiten hat, die auf individuelle Kunden zugeschnitten werden können. Der Kunde könnte dieses Verhalten ebenfalls beeinflussen wollen.
Weitere Aspekte der vorliegenden Offenbarung beinhalten die Möglichkeit, dass eine unabhängige Partei Lokalisierungspakete für den Kunden zum Herunterladen sowie das Konzept einer einfügbaren Lizenzierung entwickelt.
Hier könnte der Kunde oder der Systemadministrator die Anpassung eines einfügbaren Dienstes zum Bestellzeitpunkt festlegen (z. B. wie viele Nutzer den Dienst nutzen können, welche Nutzer den Dienst nutzen werden usw.). Eventuell ist auch möglich, die Lizenz in den Dienst (oder unterschiedliche Unterkomponenten des Dienstes) aufzunehmen und das entsprechende Bündel zum Bestellzeitpunkt dynamisch zu erzeugen.
Ein weiterer Aspekt der vorliegenden Offenbarung besteht darin, dass durch oder für einen Dienst Datenattribute definiert werden. In einigen Ausführungsformen weist jedes Attribut die aufgelisteten Ebenen in der Hierarchie auf und eine Werkseinstellung kann genutzt werden. Administratoren und Nutzer/Nutzerinnen dürfen diese selben Daten konfigurieren. Allgemein überschreibt der vom Nutzer/von der Nutzerin konfigurierte Wert den Admin-Wert, jedoch kann der Administrator festlegen, dass bestimmte Daten nicht vom Nutzer/von der Nutzerin konfigurierbar oder nur innerhalb eines vorher bestimmten Bereichs vom Nutzer/von der Nutzerin konfigurierbar sind.
Noch ein weiterer Aspekt der vorliegenden Offenbarung besteht darin, dass die Notwendigkeit umgangen wird, HTML-Code in beträchtlichem Umfang zu nutzen, um einen Bildschirm für einen Nutzer/eine Nutzerin im Zusammenhang damit, dass ein Dienst zur Verfügung gestellt wird, zu gestalten oder zu rendern. Vor allem kann eine erweiterbare Auszeichnungssprache (eXtensible Markup Language, XML) genutzt werden, um die Daten zu definieren, die von einem Systemadministrator oder einem Nutzer/einer Nutzerin manipuliert werden. Der HTML-Code kann in einem Systemverwalter des Kommunikationssystems vorher gespeichert werden. Die durch einen einsetzbaren Dienst vorgesehenen Aktualisierungen müssen in einer abstrakten Sprache nur definieren, welche Daten der HTML-Code ansehen muss, woraufhin der HTML-Code genutzt wird, um die abstrakte Sprache anzusehen, um die definierten Funktionen durchzuführen.
Weil die Attributdefinitionen, die beschreiben, was angezeigt werden soll, weniger Codeplatz als der HTML-Code selbst erfordern, kann die Größe des einfügbaren Dienstes minimal gehalten werden. Ein weiterer Vorzug besteht in der Einfachheit des Entwickelns eines neuen Dienstes. Zum Beispiel müssen nur Datenelemente definiert werden, statt dass HTML-Code entwickelt, getestet und übermittelt wird.
Gemäß mindestens einigen Ausführungsformen der vorliegenden Offenbarung ist ein Verfahren vorgesehen, das allgemein Folgendes umfasst:
Empfangen einer Anforderung von einem Kunden zum Beziehen eines herunterladbaren einfügbaren Dienstes für ein Kommunikationssystem des Kunden;
als Reaktion auf Empfangen der Anforderung Vorbereiten des herunterladbaren einfügbaren Dienstes, wobei Vorbereiten des herunterladbaren einfügbaren Dienstes Beziehen einer ersten und einer zweiten Unterkomponente beinhaltet, die in ein einzelnes Objekt eingepackt werden, wobei die erste Unterkomponente Befehle zum Betreiben eines ersten Servers des Kommunikationssystems des Kunden beinhaltet und wobei die zweite Unterkomponente Befehle zum Betreiben eines zweiten Servers des Kommunikationssystems des Kunden beinhaltet; und
Übertragen des einzelnen Objekts an den Kunden.
Gemäß mindestens einigen Ausführungsformen der vorliegenden Offenbarung ist ein Verfahren vorgesehen, das allgemein Folgendes umfasst:
Zur-Verfügung-Stellen eines Kommunikationssystems für mehrere Nutzer/Nutzerinnen;
für einen ersten Nutzer/eine erste Nutzerin oder eine Gruppe von Nutzern/Nutzerinnen in den mehreren Nutzern/Nutzerinnen Definieren einer ersten Menge aktivierter Dienste, auf die der erste Nutzer/die erste Nutzerin oder die Gruppe von Nutzern/Nutzerinnen vom Kommunikationssystem aus zugreifen darf;
für einen zweiten Nutzer/eine zweite Nutzerin oder eine Gruppe von Nutzern/Nutzerinnen in den mehreren Nutzern/Nutzerinnen Definieren einer zweiten Menge aktivierter Dienste, auf die der zweite Nutzer/die zweite Nutzerin oder die Gruppe von Nutzern/Nutzerinnen vom Kommunikationssystem aus zugreifen darf, wobei sich die erste Menge aktivierter Dienste von der zweiten Menge aktivierter Dienste um mindestens einen Dienst unterscheidet; und
Erzwingen der ersten und der zweiten Menge aktivierter Dienste für den ersten und den zweiten Nutzer/die erste und die zweite Nutzerin oder die Gruppe von Nutzern/Nutzerinnen, Nutzen des Kommunikationssystems.
Gemäß mindestens einigen Ausführungsformen der vorliegenden Offenbarung ist ein Verfahren vorgesehen, das allgemein Folgendes umfasst:
Empfangen eines Dienstes für einen ersten Nutzer/eine erste Nutzerin; und
Laden des Dienstes für den ersten Nutzer/die erste Nutzerin auf einen oder mehrere Server, ohne zu erfordern, dass sich der erste Nutzer/die erste Nutzerin von einer Kommunikationssitzung abmeldet oder eine Kommunikationssitzung abbricht.
Wenngleich Ausführungsformen der vorliegenden Offenbarung in erster Linie im Zusammenhang mit Kommunikationsdiensten oder Kommunikationssystemen beschrieben werden, sollte es sich verstehen, dass „Dienste”, wie hierin genutzt, beliebige Typen von Features oder Featuremengen beinhalten können, die für einen Nutzer/eine Nutzerin oder eine Gruppe von Nutzern/Nutzerinnen entweder innerhalb eines einzelnen Unternehmens oder innerhalb einer Mehrzahl von Unternehmen verfügbar gemacht werden. Nicht beschränkende Beispiele für Dienste beinhalten Kommunikationsdienste (z. B. Rufweglenkungsdienste, Rufverbesserungsfeatures, Konferenzdienste, Sicherheits-/Verschlüsselungsdienste, Firewall-Dienste, Multimedia-Kommunikationsdienste, Zusammenarbeitsdienste usw.), Dienste in HTTP-Art (z. B. Dienste für Browsen im Internet, Dienste für Zusammenarbeit im Internet usw.), Mediendienste, Datenspeicherdienste und beliebige andere Dienste, die von einem Server oder einer Sammlung von Servern unterstützt oder zur Verfügung gestellt werden können, die Nutzern/Nutzerinnen oder Client-Einrichtungen Inhalte oder Features zur Verfügung stellen, um Abläufe der Client-Einrichtung oder von Systemen, die der Client-Einrichtung exponiert sind, zu verbessern.
Ferner sollte der Begriff „Server”, wie hierin genutzt, so verstanden werden, dass er beliebige Server, Sammlungen von Servern, Prozessoren innerhalb von Servern, Blades innerhalb von Servern, eine oder mehrere von einem Server ausgeführte virtuelle Maschinen, von einem Server ausgeführte Container oder Vorgänge usw. beinhaltet. Mit anderen Worten, „Server” sind nicht zwangsläufig auf individuelle Hardwarekomponenten mit dedizierten Prozessoren und einem dedizierten Arbeitsspeicher beschränkt. „Server” sind auch nicht beschränkt auf Container eines konkreten Typs, die von einem Server ausgeführt werden, etwa einem J2EE-Server oder einem Java-EE-Server in einer beliebigen anderen Version. Nicht beschränkende Beispiele für Container, die von einem Server ausgeführt werden oder die einen Server bilden können, beinhalten Anwendungscontainer (z. B. Java Virtual Machines), Appletcontainer (z. B. Webbrowser oder Applet-Betrachter), Enterprise-JavaBeans(EJB)-Container, Webcontainer, Anwendungsprogrammierschnittstellen (APIs) und dergleichen.
Die Wortverbindungen „mindestens ein/eine”, „ein/eine oder mehrere” und „und/oder” sind offene Ausdrücke, die in ihrer Wirkung sowohl konjunktiv als auch disjunktiv sein können. Zum Beispiel bedeutet jeder der Ausdrücke „A und/oder B und/oder C”, „mindestens einer von A, B oder C”, „einer oder mehrere von A, B und C”, „einer oder mehrere von A, B oder C” und „A, B und/oder C” A allein, B allein, C allein, A und B zusammen, A und C zusammen, B und C zusammen oder A, B und C zusammen.
Der Begriff „eine” Entität bezieht sich auf eine oder mehrere dieser Entität. Dementsprechend können die Begriffe „ein” (bzw. „eine”), „ein/eine oder mehrere” und „mindestens ein/eine” hierin synonym genutzt werden. Es sei auch angemerkt, dass die Begriffe „umfassen”, „beinhalten” und „aufweisen” synonym genutzt werden können.
Der Begriff „automatisch” und Variationen davon, wie hierin genutzt, beziehen sich auf beliebige Vorgänge oder Abläufe, die ohne wesentlichen menschlichen Eingriff erfolgen, wenn der Vorgang oder der Ablauf durchgeführt wird. Jedoch kann ein Vorgang oder ein Ablauf auch automatisch sein, wenn die Durchführung des Vorgangs oder des Ablaufs von einem wesentlichen oder unwesentlichen menschlichen Eingriff geprägt ist, falls der Eingriff vor der Durchführung des Vorgangs oder des Ablaufs empfangen wird. Ein menschlicher Eingriff gilt als wesentlich, wenn dieser Eingriff beeinflusst, wie der Vorgang oder der Ablauf durchgeführt wird. Ein menschlicher Eingriff, der die Durchführung des Vorgangs oder des Ablaufs zulässt, gilt nicht als „wesentlich”.
Der Begriff „computerlesbares Medium”, wie hierin genutzt, bezieht sich auf einen beliebigen physikalischen Speicher, der am Übermitteln von Befehlen an einen Prozessor zur Ausführung beteiligt ist. Ein solches Medium kann viele Formen annehmen, die unter anderem nicht flüchtige Medien, flüchtige Medien und Übertragungsmedien beinhalten. Nicht flüchtige Medien beinhalten zum Beispiel NVRAMs oder Magnet- oder Bildplatten. Flüchtige Medien beinhalten dynamische Arbeitsspeicher wie Hauptspeicher. Häufige Formen computerlesbarer Medien beinhalten zum Beispiel Floppy Disks, Disketten, Festplatten, Magnetbänder oder beliebige andere magnetische Medien, magneto-optische Medien, CD-ROMs, beliebige andere optische Medien, Lochkarten, Lochstreifen, beliebige andere physikalische Medien mit Lochmustern, RAMs, PROMs und EPROMs, FLASH-EPROMs, Festkörpermedien wie Speicherkarten, beliebige andere Speicherchips oder beliebige andere Speicherkassetten oder beliebige andere Medien, die ein Computer lesen kann. Wenn die computerlesbaren Medien als Datenbank konfiguriert sind, sollte es sich verstehen, dass die Datenbank eine Datenbank beliebiger Art sein kann, etwa relational, hierarchisch, objektorientiert und/oder dergleichen. Folglich wird davon ausgegangen, dass die Offenbarung ein physikalisches Speichermedium und als Stand der Technik anerkannte Äquivalente und Nachfolgemedien beinhaltet, in denen die Software-Implementierungen der vorliegenden Offenbarung gespeichert sind.
Die Begriffe „bestimmen”, „kalkulieren” und „berechnen” sowie Variationen davon, wie hierin genutzt, werden synonym genutzt und umfassen Methodiken, Vorgänge, mathematische Operationen oder Techniken beliebiger Art.
Der Begriff „Modul”, wie hierin genutzt, bezieht sich auf beliebige bekannte oder künftig entwickelte Hardware, Software, Firmware, künstliche Intelligenz, Fuzzylogik oder Kombinationen von Hardware und Software mit der Fähigkeit, die mit diesem Element assoziierte Funktionalität durchzuführen. Wenngleich die Offenbarung hinsichtlich Ausführungsbeispielen beschrieben wird, sollte es sich auch verstehen, dass individuelle Aspekte der Offenbarung getrennt beansprucht werden können.
KURZE BESCHREIBUNG DER ZEICHNUNGEN
Die vorliegende Offenbarung wird im Zusammenhang mit den beigefügten Figuren beschrieben:
1 ist ein Blockschema eines ersten Kommunikationssystems gemäß Ausführungsformen der vorliegenden Offenbarung;
2 ist ein Blockschema eines Dienstlagers gemäß Ausführungsformen der vorliegenden Offenbarung;
3 ist ein Blockschema eines zweiten Kommunikationssystems gemäß Ausführungsformen der vorliegenden Offenbarung;
4 ist ein Blockschema eines dritten Kommunikationssystems gemäß Ausführungsformen der vorliegenden Offenbarung;
5 ist ein Blockschema eines vierten Kommunikationssystems gemäß Ausführungsformen der vorliegenden Offenbarung;
6 ist ein Blockschema eines bereitstellbaren Objekts gemäß Ausführungsformen der vorliegenden Offenbarung;
7 ist ein Blockschema, das eine Dienstvorlage gemäß Ausführungsformen der vorliegenden Offenbarung abbildet;
8 ist ein Blockschema, das eine Datenstruktur abbildet, die im Zusammenhang mit dem Administrieren von Diensten gemäß Ausführungsformen der vorliegenden Offenbarung genutzt wird;
9 ist ein Ablaufschema, das ein Verfahren zum Übermitteln eines herunterladbaren Objekts gemäß Ausführungsformen der vorliegenden Offenbarung abbildet;
10 ist ein Ablaufschema, das ein Verfahren zum Bereitstellen und Installieren eines herunterladbaren Objekts gemäß Ausführungsformen der vorliegenden Offenbarung abbildet;
11 ist ein Ablaufschema, das ein Verfahren zum Anpassen eines herunterladbaren Objekts gemäß Ausführungsformen der vorliegenden Offenbarung abbildet;
12 ist ein Ablaufschema, das ein Verfahren zum Bereitstellen eines Dienstes während der Systemlaufzeit gemäß Ausführungsformen der vorliegenden Offenbarung abbildet;
13 ist ein Ablaufschema, das ein Verfahren zum Ausführen eines Upgrades für einen Dienst gemäß Ausführungsformen der vorliegenden Offenbarung abbildet; und
14 ist ein Ablaufschema, das ein Verfahren zum hierarchischen Strukturieren von Attributen für einen Dienst gemäß Ausführungsformen der vorliegenden Offenbarung abbildet.
AUSFÜHRLICHE BESCHREIBUNG
Die folgende Beschreibung legt nur Ausführungsformen dar und soll nicht den Schutzbereich, die Anwendbarkeit oder die Konfiguration der Ansprüche begrenzen. Vielmehr soll die folgende Beschreibung dem Fachmann eine Beschreibung an die Hand geben, die ihn dazu befähigt, die Ausführungsformen zu implementieren. Dabei versteht es sich, dass verschiedene Änderungen hinsichtlich der Funktion und der Anordnung von Elementen vorgenommen werden können, ohne vom Gedanken und vom Schutzbereich der beigefügten Ansprüche abzuweichen.
1 zeigt eine beispielhafte Ausführungsform eines Kommunikationssystems 100 gemäß mindestens einigen Ausführungsformen der vorliegenden Offenbarung. Das Kommunikationssystem 100 ist möglicherweise ein verteiltes System und umfasst in einigen Ausführungsformen ein oder mehrere Kommunikationsnetze 104, die Kommunikationen zwischen einem Dienstlager 108 und einem oder mehreren Kunden 112a–N oder einem oder mehreren Kundenstandorten 112a–N unterstützen.
Das Kommunikationsnetz 104 kann paketvermittelt und/oder leitungsvermittelt sein. Ein beispielhaftes Kommunikationsnetz 104 beinhaltet unter anderem ein Wide Area Network (WAN), etwa das Internet, ein Local Area Network (LAN), ein Personal Area Network (PAN), ein öffentliches Telefonwählnetz (Public Switched Telephone Network, PSTN), ein Plain-Old-Telephone-Service(POTS)-Netz, ein Zellularkommunikationsnetz, ein IP-Multimedia-Subsystem(IMS)-Netz, ein SIP-Netz, ein Voice-over-IP(VoIP)-Netz oder Kombinationen davon. In einer Konfiguration ist das Kommunikationsnetz 104 ein öffentliches Netz, das die TCP/IP-Protokollsuite unterstützt. Vom Kommunikationsnetz 104 unterstützte Kommunikationen beinhalten Echtzeit-, Beinahe-Echtzeit- und Nicht-Echtzeit-Kommunikationen. Beispielsweise unterstützt das Kommunikationsnetz 104 möglicherweise Sprache, Videos, Text, Webkonferenzen oder eine beliebige Kombination von Medien.
Das Dienstlager 108 sieht möglicherweise einen Ort vor, an dem Kunden 112a–N Dienste ansehen und schließlich kaufen können. Beispiele für Dienste, die vom Dienstlager 108 angeboten werden können, beinhalten Kommunikationsdienste, Mediendienste, Verwaltungsdienste, Datenspeicherdienste, Verarbeitungsdienste, Kombinationen davon und beliebige andere automatisierte oder computerimplementierte Dienste. In einigen Ausführungsformen gewährt das Dienstlager 108 möglicherweise über eine oder mehrere Webseiten, die von einem Webserver oder einer Gruppe von Webservern bedient werden, Zugriff auf seine Dienste. Das Dienstlager 108 kann Kunden 112a–N die Möglichkeit geben, verschiedene vom Dienstlager 108 angebotene Dienste durch bekannte webbasierte Kommunikationsprotokolle (z. B. HTTP, Secure HTTP usw.) anzusehen. Die Kunden 112a–N umfassen möglicherweise eine oder mehrere Client-Einrichtungen mit einer darauf ausgeführten Webbrowser-Anwendung, die zulässt, dass ein Nutzer/eine Nutzerin oder Systemadministratoren am Kundenstandort Dienste vom Dienstlager 108 ansehen und kaufen.
Wie hierin noch ausführlicher erörtert wird, umfasst das Dienstlager 108 möglicherweise die Funktionalität, um eine Bestellung eines oder mehrerer Dienste von einem Kunden 112a–N zu empfangen, einen oder mehrere herunterladbare einfügbare Dienste automatisch vorzubereiten und die herunterladbaren einfügbaren Dienste über das Kommunikationsnetz 104 an den bestellenden Kunden 112a–N zu senden. In einigen Ausführungsformen sieht das Dienstlager 108 den bestellten Dienst/die bestellten Dienste für den Kunden 112a–N möglicherweise über das vom Kunden 112a–N auch zum Bestellen des Dienstes/der Dienste genutzte oder ein ähnliches Protokoll vor. Eventuell ist auch möglich, dass das Dienstlager 108 dem Kunden 112a–N den bestellten Dienst/die bestellten Dienste in derselben Kommunikationssitzung, in der die Bestellung empfangen wurde, zur Verfügung stellt. Mit anderen Worten, das Dienstlager 108 übermittelt den bestellten Dienst/die bestellten Dienste möglicherweise über den während der webbasierten Kommunikationssitzung ausgehandelten Port, der auch zum Bestellen des Dienstes/der Dienste genutzt wurde. Dadurch wird eine einfache und effiziente Möglichkeit geschaffen, Dienste vom Dienstlager 108 an den Kunden 112a–N zu übermitteln.
Es sollte sich verstehen, dass das Dienstlager 108 verteilt sein kann. Auch wenn sich Ausführungsformen der vorliegenden Offenbarung auf ein einzelnes Dienstlager 108 als der Mechanismus beziehen, über den Dienste an Kunden übermittelt werden, sollte es sich verstehen, dass die hierin beanspruchten Ausführungsformen dadurch nicht beschränkt werden. Beispielsweise kann eine Mehrzahl von Dienstlagern 108 entweder autonom oder koordiniert von einer Mehrzahl unterschiedlicher Server ausgeführt werden. Ein Kunde kommuniziert möglicherweise mit einer Instanz des Dienstlagers 108, während ein anderer Kunde möglicherweise mit einer anderen Instanz des Dienstlagers 108 kommuniziert.
Nunmehr unter Bezugnahme auf 2 werden zusätzliche Einzelheiten eines Dienstlagers 108 gemäß Ausführungsformen der vorliegenden Offenbarung beschrieben. Ein Dienstlager 108 umfasst möglicherweise ein Kundenportal 208, eine Objektübermittlungsschnittstelle 212, einen Objektgenerator 216 und ein Objekt-Unterkomponenten-Bibliothek-Repository 220. Auch wenn das Kundenportal 208 und die Objektübermittlungsschnittstelle 212 als getrennte und unterschiedliche Komponenten abgebildet sind, die sie sein können, sollte es sich verstehen, dass einige Instanzen eines Dienstlagers 108 möglicherweise eine einzelne Komponente umfassen, die sowohl als Kundenportal 208 als auch als Objektübermittlungsschnittstelle 212 dient.
Das Kundenportal 208 stattet das Dienstlager 108 mit der Möglichkeit aus, Kunden 112a–N verfügbare Dienste zu exponieren sowie Bestellungen von Diensten von Kunden 112a–N zu empfangen. In einigen Ausführungsformen umfasst das Kundenportal 208 möglicherweise eine Webschnittstelle (z. B. eine oder mehrere Webseiten, die konfiguriert sind, um für den Kunden 112a–N zum Beispiel über eine Auszeichnungssprache zur Verfügung gestellt zu werden), einen Webserver, eine Gruppe von Webservern, einen Kommunikationsport, ein Kommunikationssocket oder beliebige andere Kombinationen von Hardware- und/oder Softwarekomponenten, die ermöglichen, dass ein Kunde 112a–N Inhalte des Dienstlagers 108 remote ansieht.
Insbesondere kann das Kundenportal 208 ermöglichen, dass ein Kunde 112a–N Inhalte des Objekt-Unterkomponenten-Bibliothek-Repositorys 220 oder eine Liste von Diensten ansieht, die für den Kunden 112a–N über Unterkomponenten 228, die innerhalb der Unterkomponentenbibliothek 224 aufgelistet und im Objekt-Unterkomponenten-Bibliothek-Repository 220 gespeichert sind, zur Verfügung gestellt werden können. Einige nicht beschränkende Beispiele für Dienste, die einem Kunden 112a–N über das Kundenportal 208 angezeigt und vom Kunden deshalb bestellt werden können, beinhalten einen oder mehrere Kommunikationsdienste, etwa einen Voicemail-Dienst, einen Anrufweiterleitungsdienst, einen Dynamic-Device-Pairing-Dienst, einen Rufweglenkungsdienst, einen Extension-to-Cellular-Dienst, einen Sprache-Text-Dienst, einen Text-Sprache-Dienst, einen Anrufaufzeichnungsdienst, eine Medienbibliothek, einen Interactive-Voice-Response(IVR)-Dienst, einen Konferenzdienst oder dergleichen.
Während das Kundenportal 208 ermöglicht, dass ein Kunde 112a–N Dienste ansieht und bestellt, ist der Objektgenerator 216 für die Ausführung von Dienstbestellungen zuständig. Speziell, falls ein Kunde 112a–N eine Bestellung eines konkreten Dienstes oder einer konkreten Menge von Diensten aufgibt, wird der Objektgenerator 216 dazu aufgerufen, die notwendigen Unterkomponenten 228 aus dem Objekt-Unterkomponenten-Bibliothek-Repository 220 zu erfassen und die Unterkomponenten 228 in einem Objekt zu bündeln, das über das Kommunikationsnetz 104 direkt an den Kunden 112a–N übermittelt werden kann. Insbesondere, wenn der Objektgenerator 216 eine Bestellung eines Dienstes empfängt, ist der Objektgenerator 216 konfiguriert, um den Typ des Dienstes, der bestellt wurde, zu bestimmen und auch um zu bestimmen, welche Unterkomponenten 228 erforderlich sein werden, um dem bestellenden Kunden den bestellten Dienst schließlich zur Verfügung zu stellen. Es sollte sich verstehen, dass die Anzahl und der Typ der Unterkomponenten 228, die erforderlich sind, um einem konkreten Kunden einen konkreten Dienst zur Verfügung zu stellen, möglicherweise vom Typ der vom Kunden genutzten Geräte, von der Beschaffenheit des bestellten Dienstes, der Anzahl der Lizenzen des Dienstes, die bestellt wurden (z. B. davon, wie viele Nutzer/Nutzerinnen am Kundenstandort den Dienst nutzen werden) und einer Anzahl anderer Faktoren abhängen.
In einigen Ausführungsformen wird ein Objekt vom Objektgenerator 216 möglicherweise individuell erstellt, um eine oder mehrere kundenspezifische Anforderungen hinsichtlich des Dienstes zu berücksichtigen. Um ein nicht beschränkendes Beispiel anzuführen, angenommen, ein Kunde hat gerade einen neuen Kommunikationsdienst bestellt, der eine Anzahl von Unterkomponenten aufweisen wird, etwa eine Nutzerportalunterkomponente, eine Anrufverarbeitungsunterkomponente, eine Administrations- oder Systemverwaltungsunterkomponente und eine Nutzerschnittstellenunterkomponente. Eine oder mehrere dieser Unterkomponenten werden vom Objektgenerator 216 möglicherweise angepasst, um die spezielle Version der Server (oder der Prozessoren) zu berücksichtigen, die schließlich jede Unterkomponente ausführen werden, sowie um eventuelle spezielle Anforderungen des bestellenden Kunden zu berücksichtigen (z. B. Sprachanforderungen, Erscheinungsbildanforderungen, Standardregeln/-einstellungen usw.). Der Objektgenerator 216 ist fähig, die entsprechenden Unterkomponenten 228 abzufragen, indem er auf die Unterkomponentenbibliothek 224 Bezug nimmt und anhand dieser Unterkomponentenbibliothek 224 bestimmt, welche Unterkomponenten 228 den Dienst, der vom Kunden bestellt wurde, passend zur Verfügung stellen werden.
Ein nicht beschränkendes Beispiel für ein Objekt 604, das möglicherweise vom Objektgenerator 216 generiert wird, ist in 6 abgebildet. Wie oben erörtert, umfasst das vom Objektgenerator 216 erzeugte Objekt 604 möglicherweise eine oder mehrere Unterkomponenten, die ermöglichen, dass verschiedene unterschiedliche Server in den Kundenräumlichkeiten koordiniert betrieben werden, um den bestellten Dienst zur Verfügung zu stellen. Einige Beispiele für Unterkomponenten, die in ein zum Übermitteln eines Kommunikationsdienstes genutztes Objekt 604 aufgenommen werden können, beinhalten unter anderem eine Nutzerportalunterkomponente 608, eine Anrufverarbeitungsunterkomponente 616 und eine Systemverwalterunterkomponente 620. Auch wenn das Objekt 604 nicht abgebildet ist, umfasst es möglicherweise ebenfalls eine Lizenzunterkomponente, welche die Rechte des Kunden auf die Nutzung des Dienstes definiert (z. B. die Anzahl der Nutzer/Nutzerinnen, denen der Dienst zugewiesen werden kann). Das vom Objektgenerator 216 generierte Objekt 604 beinhaltet möglicherweise auch Bereitstellungsbefehle 612, die, wenn sie befolgt werden, die erfolgreiche Bereitstellung des Objekts 604 in den Kundenräumlichkeiten durch Verteilen der Unterkomponenten an die entsprechenden Orte/Server ermöglichen.
Es sollte sich verstehen, dass die Unterkomponenten 228 als Dateien, ausführbare Dateien oder dergleichen im Speicher des Dienstlagers 108 gespeichert werden können und die Unterkomponentenbibliothek 224 möglicherweise einfach mit einer Liste oder einer Tabelle der verschiedenen im Speicher gespeicherten Unterkomponenten 228 korrespondiert. Die Unterkomponentenbibliothek 224 stellt möglicherweise auch Verknüpfungen oder Adressen zur Verfügung, die vom Objektgenerator 216 genutzt werden können, um die korrespondierenden Unterkomponenten 228 zu suchen und aus dem Arbeitsspeicher abzurufen. Mit anderen Worten, die Unterkomponentenbibliothek 224 beinhaltet möglicherweise eine Liste von Unterkomponenten 228 sowie Indizierungsmechanismen, die zum Suchen der Unterkomponenten im Speicher genutzt werden.
Die Objektübermittlungsschnittstelle 212 des Dienstlagers 108 stattet den Objektgenerator 216 mit der Möglichkeit aus, das Objekt 604 über das Kommunikationsnetz 104 an einen Kunden 112a–N zu übermitteln. In einigen Ausführungsformen belegt die Objektübermittlungsschnittstelle 212 möglicherweise dieselben Hardwarekomponenten (z. B. Socket, Port, Netzschnittstellenkarte usw.) wie das Kundenportal 208. In einigen Ausführungsformen unterscheidet sich die Objektübermittlungsschnittstelle 212 möglicherweise vom Kundenportal 208. In beiden Implementierungen kann die Objektübermittlungsschnittstelle 212 so konfiguriert sein, dass sie das vom Objektgenerator 216 generierte Objekt 604 in einem oder mehreren Kommunikationspaketen oder einer oder mehreren Kommunikationsdateien, die über das Kommunikationsnetz 104 übermittelt werden können, einschließt bzw. einpackt. Die Objektübermittlungsschnittstelle 212 umfasst möglicherweise auch die Fähigkeit zum Suchen nach dem Objekt 604 und zu dessen Übertragung an den bestellenden Kunden.
Nunmehr unter Bezugnahme auf 3 werden zusätzliche Einzelheiten beispielhafter Kundenräumlichkeiten 304 gemäß Ausführungsformen der vorliegenden Offenbarung beschrieben. Die Kundenräumlichkeiten 304 korrespondieren in einigen Ausführungsformen möglicherweise mit einem Unternehmensnetz im Eigentum eines einzelnen Kunden 112, der es betreibt. Mit anderen Worten, ein einzelner Kunde 112 kann die Kommunikationseinrichtungen, die innerhalb der Grenzen der Kundenräumlichkeiten 304 enthalten sind, als Eigentümer besitzen, leasen oder ansonsten allein über ihren Betrieb und/oder ihre Instandhaltung verfügen. Solche Kundenräumlichkeiten 304 werden allgemein als Unternehmensnetz bezeichnet. Das Unternehmensnetz ist möglicherweise verteilt (z. B. ein WAN) oder es kann auf einen einzigen Ort begrenzt sein (z. B. ein LAN). In anderen Ausführungsformen nutzt möglicherweise eine Mehrzahl von Kunden 112a–N einige oder alle der Komponenten der Kundenräumlichkeiten 304.
Die Räumlichkeiten 304 korrespondieren möglicherweise mit einem Unternehmensnetz und umfassen in einigen Ausführungsformen möglicherweise eine Netzgrenzeinrichtung 308, die eine Servertabelle 312 beinhaltet, einen Kommunikationsserver 316, einen oder mehrere Server 336 (z. B. Anwendungsserver, Featureserver usw.), die fähig sind, Nutzern/Nutzerinnen einen oder eine Mehrzahl von Diensten zur Verfügung zu stellen, eine oder mehrere interne Kommunikationseinrichtungen 348, einen Datenspeicher 352, einen oder mehrere Nutzerportalserver 356, einen oder mehrere Systemverwalterserver 364 und einen oder eine Mehrzahl anderer Server 372. Einige oder alle der Komponenten der Räumlichkeiten 304 sind möglicherweise über ein (vertrauenswürdiges oder sicheres oder privates) Local Area Network (LAN) 344 miteinander verbunden. Einige oder alle der in 3 abgebildeten Funktionen werden möglicherweise auf einem einzelnen Server zusammen gehostet und/oder liegen zusammen auf einem einzelnen Server. Die Abbildung der Komponenten in 3 und die anderen hierin enthaltenen Figuren sollen allgemein eine logische Abbildung der Komponenten des Systems darstellen. Es sollte sich verstehen, dass ein Unternehmensnetz oder eine Mehrzahl von Unternehmensnetzen möglicherweise eine Mehrzahl von über ein WAN, wie das Kommunikationsnetz 104, verbundenen LANs 344 umfassen. Zum leichteren Verständnis und der Einfachheit halber wird in 3 ein einzelnes Unternehmenskommunikationsnetz 304 abgebildet und hierin beschrieben und soll in keiner Hinsicht Ausführungsformen der vorliegenden Erfindung auf ein einziges Unternehmensnetz 304 beschränken.
Das LAN 344 kann durch ein Gateway und/oder eine Firewall, das bzw. die sich zwischen dem LAN 344 und dem Kommunikationsnetz 104 befindet, vor einem Eindringen nicht vertrauenswürdiger Parteien geschützt werden. In einigen Ausführungsformen beinhaltet die Grenzeinrichtung 308 möglicherweise die Funktionalität des Gateways und/oder der Firewall. In einigen Ausführungsformen ist zwischen der Grenzeinrichtung 308 und dem Kommunikationsnetz 104 möglicherweise ein getrenntes Gateway oder eine getrennte Firewall vorgesehen.
Auch wenn in 3 nur eine einzelne Instanz jedes Servers (z. B. ein einzelner Kommunikationsserver 316, ein einzelner Anwendungsserver 336, ein einzelnes Nutzerportal 356 und ein einzelner Systemverwalter 364) abgebildet ist, können in einem einzelnen Unternehmensnetz 304 oder über eine Mehrzahl getrennter LANs 344 im Eigentum eines einzelnen Unternehmens, das solche Netze betreibt, die jedoch vom Kommunikationsnetz 104 getrennt werden, möglicherweise zwei oder mehr Instanzen eines Servers eines beliebigen Typs vorgesehen sein. In Konfigurationen, in denen ein Unternehmen oder ein Unternehmensnetz 304 zwei oder mehr Server eines einzigen Typs (z. B. eine Mehrzahl von Kommunikationsservern 316) beinhaltet, umfasst jeder Server möglicherweise eine ähnliche Funktionalität, kann jedoch eingeführt werden, damit er seine Features nur einer Untermenge aller Unternehmensnutzer/-nutzerinnen zur Verfügung stellt. Vor allem, wobei dies ein nicht beschränkendes Beispiel ist, ist ein erster Kommunikationsserver 316 möglicherweise autoritativ für und bedient eine erste Untermenge von Unternehmensnutzern/-nutzerinnen, während ein zweiter Kommunikationsserver 316 möglicherweise für eine zweite Untermenge von Unternehmensnutzern/-nutzerinnen autoritativ ist und diese bedient, wobei die erste und die zweite Untermenge von Nutzern/Nutzerinnen allgemein keinen gemeinsamen Nutzer haben. Dies ist ein Grund, weshalb die Netzgrenzeinrichtung 308 möglicherweise mit einer Servertabelle 312 ausgestattet ist – die Servertabelle 312 umfasst möglicherweise die Informationen, die einen Nutzer seinem autoritativen Kommunikationsserver 316 zuordnen.
Zusätzlich kann eine Mehrzahl von Servern eine Community gemeinsamer Nutzer/Nutzerinnen unterstützen. Zum Beispiel gibt es in georedundanten und anderen Anwendungen, bei denen Nutzer/Nutzerinnen nicht zwangsläufig an einen einzigen Anwendungsserver gebunden sind, möglicherweise einen Cluster äquivalenter Server, wobei ein Nutzer/eine Nutzerin von einem beliebigen Server im Cluster bedient werden kann.
Der Kommunikationsserver 316 kann eine Nebenstellenanlage (PBX), einen Unternehmensnetzknoten, einen Unternehmensserver, innerhalb eines Servers ausgeführte Komponenten oder Anwendungen, eine von einem Server zur Verfügung gestellte Maschine, Kombinationen davon oder einen Telekommunikationssystemnetzknoten oder -server eines anderen Typs beinhalten. Der Kommunikationsserver 316 ist in einigen Ausführungsformen so konfiguriert, dass er die Ausführung von Telekommunikationsfunktionen ermöglicht, etwa der Suite von Anwendungen und Diensten, die über die Avaya-Aura^TM-Plattform der Avaya Inc. verfügbar gemacht werden, einschließlich Communication Manager^TM, Avaya Aura Communication Manager^TM, Avaya IP Office^TM, Communication Manager Branch^TM, Session Manager^TM, MultiVantage Express^TM und Kombinationen davon.
Gemäß mindestens einigen Ausführungsformen der vorliegenden Offenbarung muss die Zuordnung von Nutzeridentitäten innerhalb einer Kommunikationsanforderung nicht zwangsläufig an der Netzgrenzeinrichtung 308 erfolgen. Beispielsweise kann die Zuordnung zwischen einem autoritativen Kommunikationsserver 316 und einem Nutzer/einer Nutzerin „hinter” der Netzgrenzeinrichtung 308 innerhalb des Unternehmensnetzes 304 erfolgen. In einigen Ausführungsformen beinhaltet die Netzgrenzeinrichtung 308 möglicherweise eine Funktionalität mit Ähnlichkeit zu einem Session Border Controller (SBC), einer Firewall, einem Gateway oder einer beliebigen anderen Einrichtung, die Sicherheits- und/oder Übersetzungsfähigkeiten zur Verfügung stellt.
In einigen Ausführungsformen ist die Netzgrenzeinrichtung 308 dafür zuständig, Kommunikationen innerhalb des Unternehmensnetzes 304 anfänglich an den Kommunikationsserver 316 zu routen, der für die Bedienung eines konkreten Nutzers/einer konkreten Nutzerin, der/die an einer Kommunikationssitzung beteiligt ist, zuständig ist. Falls zum Beispiel ein erster Unternehmensnutzer/eine erste Unternehmensnutzerin von einer externen Kommunikationseinrichtung angerufen wird, kann die Netzgrenzeinrichtung 308 den ankommenden Anruf anfänglich empfangen, bestimmen, dass der Anruf zum ersten Unternehmensnutzer/zur ersten Unternehmensnutzerin hin geleitet wird, Bezug auf die Servertabelle 312 nehmen, um den autoritativen Kommunikationsserver 316 für den ersten Unternehmensnutzer/die erste Unternehmensnutzerin zu identifizieren, und den ankommenden Anruf an den autoritativen Kommunikationsserver 316 routen. Zudem können Kommunikationen zwischen internen Unternehmensnutzern/-nutzerinnen (z. B. internen Kommunikationseinrichtungen 348) zuerst vom autoritativen Kommunikationsserver 316 des rufenden Nutzers/der rufenden Nutzerin während der Erzeugungsphase des Kommunikationsaufbaus bedient werden. Sobald die Erzeugungsphase abgeschlossen ist, kann der autoritative Kommunikationsserver 316 des gerufenen Nutzers/der gerufenen Nutzerin (bei dem/der die Kommunikation ankommt) dazu aufgerufen werden, die Endphase des Kommunikationsaufbaus abzuschließen. In einigen Ausführungsformen kann der Kommunikationsserver 316 für den rufenden und den gerufenen Nutzer/die rufende und die gerufene Nutzerin derselbe sein, jedoch ist dies nicht zwangsläufig erforderlich. In Situationen, in denen mehr als zwei Unternehmensnutzer/-nutzerinnen an einer Kommunikationssitzung beteiligt sind, können für jeden/jede der beteiligten Nutzer/Nutzerinnen autoritative Kommunikationsserver 316 gebraucht werden, ohne vom Schutzbereich der vorliegenden Erfindung abzuweichen. Zusätzlich befinden sich die autoritativen Kommunikationsserver 316 für jeden Nutzer/jede Nutzerin möglicherweise in demselben Unternehmensnetz 304 oder in unterschiedlichen Unternehmensnetzen 304, die im Eigentum eines einzigen Unternehmens stehen, jedoch durch das Kommunikationsnetz 104 getrennt werden.
Jeder Kommunikationsserver 316 beinhaltet möglicherweise einen Dienstauswähler 320, Nutzereinstellungen 324, einen Objektentpacker 328 und einen Objektverteiler 332. Wie ersichtlich ist, müssen verschiedene Module des Kommunikationsservers 316 nicht zwangsläufig auf demselben Server implementiert sein. Vielmehr können die Module des Kommunikationsservers 316 in einem oder mehreren unterschiedlichen Servern oder in unterschiedlichen Prozessoren innerhalb desselben Servers implementiert sein.
Der Dienstauswähler 320 stattet den Kommunikationsserver 316 mit der Möglichkeit aus, Nutzeranforderungen an die entsprechenden Server 336, 356, 364, 372 innerhalb des Netzes 304 zu routen. Speziell kann der Dienstauswähler 320 als Reaktion auf Empfangen einer Anforderung zum Einleiten einer Kommunikationssitzung (z. B. einer INVITE-Nachricht in einer SIP-Umgebung, einer HTTP-GET-Anforderung, eines ankommenden oder abgehenden Telefonanrufs, einer E-Mail-Nachricht, einer Short-Message-Service(SMS)-Nachricht usw.) oder einer Anforderung von Informationen irgendeines anderen Typs (z. B. einer Anforderung von Präsenzinformationen, etwa über eine SUBSCRIBE-Nachricht, einer Datenbankabfrage usw.) aufgerufen werden. Sobald der Dienstauswähler 320 aufgerufen wurde, kann er so konfiguriert werden, dass er auf die Nutzereinstellungen 324 Bezug nimmt, um zu bestimmen, welcher Server als Nächstes aktiviert werden soll. Zum Beispiel empfängt der Kommunikationsserver 316 möglicherweise eine SIP-Nachricht und der Dienstauswähler 320 nimmt möglicherweise auf die Nutzereinstellungen 324 Bezug, um zu bestimmen, welcher Server 336, 356, 364, 372 die SIP-Nachricht als Nächstes empfangen soll. Insbesondere kann der Kommunikationsserver 316 so konfiguriert sein, dass er in einem Daten- und/oder einem Medienpfad einer Kommunikationssitzung eine Kette von Back-to-Back User Agents (B2BUAs) aufbaut, indem er alle B2BUAs in eine Anwendungssequenz nacheinander sequenziert, bis die gesamte Anwendungssequenz konstruiert worden ist.
Die Nutzereinstellungen 324 für einen Kommunikationsserver 316 enthalten die Diensteinstellungen für jeden Nutzer/jede Nutzerin, für den/die er autoritativ ist. Im Beispiel eines Kommunikationsdienstes definieren die Nutzereinstellungen 324 möglicherweise, welche Anwendungen vom Anwendungsserver 336 für die Anwendungssequenz eines konkreten Nutzers/einer konkreten Nutzerin aufgerufen werden sollen. Andere Typen von Nutzereinstellungen 324 beinhalten möglicherweise Nutzerschnittstelleneinstellungen, Datenabrufeinstellungen, Präsenzinformationen und Datenschutzeinstellungen und dergleichen. In einigen Ausführungsformen haben die Nutzereinstellungen 324 möglicherweise ein Tabellenformat und werden möglicherweise von Nutzern/Nutzerinnen und/oder vom Administrationspersonal eingeführt. Der Dienstauswähler 320 nimmt Bezug auf die Nutzereinstellungen 324 für einen konkreten Nutzer/eine konkrete Nutzerin, um zu bestimmen, welche Dienste und welche Komponenten dieses Dienstes (z. B. die Unterkomponenten 340, 360, 368, 376) ggf. für den Nutzer/die Nutzerin aufgerufen werden sollen. Erneut unter Bezugnahme auf den Dienst vom Kommunikationstyp kann der Dienstauswähler 320 so konfiguriert sein, dass er Kommunikationsfeatures direkt in die Kommunikationssitzung einführt oder eine Anwendungssequenz bestimmt, die während des Aufbaus aufgerufen und während der Kommunikationssitzung genutzt wird.
Der Objektentpacker 328 und der Objektverteiler 332 können vom Kommunikationsserver 316 genutzt werden, um Objekte zu bearbeiten, die vom Dienstlager 108 her empfangen werden. Es sollte sich verstehen, dass der Objektentpacker 328 und der Objektverteiler 332 nicht zwangsläufig auf demselben Server, etwa dem Kommunikationsserver 316, liegen müssen. Beispielsweise können sowohl der Objektentpacker 328 als auch der Objektverteiler 332 im Systemverwalter 364 liegen. Um ein weiteres Beispiel anzuführen, der Objektverteiler 332 wird möglicherweise im Systemverwalter 364 zur Verfügung gestellt, und jeder Server, der eine Unterkomponente (z. B. 336, 356, 372) empfängt, verfügt möglicherweise über einen eigenen Objektentpacker 328.
In einigen Ausführungsformen routet die Grenzeinrichtung 308, wenn das Dienstlager 108 ein Objekt generiert und an das Unternehmen 304 sendet, die das Objekt enthaltende(n) Nachricht(en) möglicherweise an den Kommunikationsserver 316. Wie aus 6 hervorgeht, umfasst ein Objekt 604 möglicherweise eine Mehrzahl von Bestandteilen, etwa eine Nutzerportalunterkomponente 608, eine Menge von Bereitstellungsbefehlen 612, eine Anrufverarbeitungsunterkomponente 616 und eine Systemverwalterunterkomponente 620. Jede dieser Unterkomponenten ist möglicherweise speziell dafür bestimmt, an einen anderen Server gesendet und von diesem ausgeführt zu werden.
Folglich ist der Objektentpacker 328, sobald sie am Kommunikationsserver 316 empfangen wurde, so konfiguriert, dass er die verschiedenen Bestandteile des Objekts 604 identifiziert und aus dem Objekt 604 extrahiert. In einigen Ausführungsformen korrespondiert jede Unterkomponente des Objekts 604 möglicherweise mit einer anderen Datei, einer anderen ausführbaren Datei (z. B. einem Befehlssatz), einem anderen Satz von Dateien oder einem anderen Satz ausführbarer Dateien. Das Entpacken des Objekts 604 korrespondiert möglicherweise einfach damit, dass der Objektentpacker 328 jede Datei/ausführbare Datei, die mit jeder Unterkomponente korrespondiert, extrahiert und die extrahierte Datei/ausführbare Datei vorübergehend am Arbeitsspeicher im Kommunikationsserver 316 ablegt.
Der Objektentpacker 328 ruft daraufhin möglicherweise den Objektverteiler 332 dazu auf, die verschiedenen Unterkomponenten gemäß den innerhalb des Objekts 604 enthaltenen Bereitstellungsbefehlen 612 an die entsprechenden Server 336, 356, 364, 372 zu verteilen. Insbesondere kann der Objektverteiler 332 auf die Bereitstellungsbefehle 612 Bezug nehmen und bewirken, dass die Anrufverarbeitungsunterkomponente 616 für entweder den Anwendungsserver 336 (z. B. als Anwendungsunterkomponente 340) oder einen anderen Teil des Kommunikationsservers 316 bereitgestellt wird. Die Nutzerportalunterkomponente 608 kann für das Nutzerportal 356 (z. B. als Nutzerportalunterkomponente 360) bereitgestellt werden. Die Systemverwalterunterkomponente 620 kann für den Systemverwalterserver 364 (z. B. als Systemverwalterunterkomponente 368) bereitgestellt werden. Jede Unterkomponente des nun bereitgestellten Objekts 604 kann, sobald sie vom Objektverteiler 332 bereitgestellt wurde, von ihrem korrespondierenden Server ausgeführt werden. In einigen Ausführungsformen können die bereitgestellten Unterkomponenten zusammenwirkend zusammenarbeiten, um die volle Funktionalität eines Dienstes zur Verfügung zu stellen.
Um ein nicht beschränkendes Beispiel anzuführen, falls das heruntergeladene Objekt 604 mit einer neuen Kommunikationsanwendung (z. B. einem Anrufaufzeichnungsdienst, einem Dynamic-Device-Pairing-Dienst, einem Anrufweiterleitungsdienst, einem Voicemail-Dienst, einem Anrufprotokolldienst, einem Anruferkennungsdienst, einem Verschlüsselungsdienst usw.) korrespondiert, wenn ein solcher Dienst für einen Nutzer/eine Nutzerin während einer Kommunikationssitzung benötigt wird, wird dem Nutzer/der Nutzerin der Dienst möglicherweise durch die gemeinsame Ausführung jeder Unterkomponente auf jedem Server 316, 336, 356, 364, 372 zur Verfügung gestellt. Insbesondere ist die auf dem Anwendungsserver 336 gespeicherte und vom Anwendungsserver 336 ausgeführte Anrufverarbeitungsunterkomponente 340 möglicherweise die Unterkomponente 340, die in die Kommunikationssitzung als ein B2BUA sequenziert wird. Die Nutzerportalunterkomponente 360 kann ermöglichen, dass ein Nutzer/eine Nutzerin den konkreten Dienst und seine/ihre Einstellungen für den Dienst ansieht und/oder konfiguriert und andere den Dienst betreffende Funktionen (z. B. über eine webbasierte Nutzerschnittstelle) durchführt. Die Systemverwalterunterkomponente 368 kann ermöglichen, dass der Nutzer/die Nutzerin und/oder ein Systemadministrator (z. B. ein Administrator des Unternehmensnetzes 304) Berechtigungen und/oder Nutzerzugriffe auf den Dienst steuert. Ähnlich wie die Nutzerportalunterkomponente 360 wird die Systemverwalterunterkomponente 368 möglicherweise auch über eine webbasierte Nutzerschnittstelle oder dergleichen verfügbar gemacht.
Wie hierin noch ausführlicher beschrieben wird, ist es eventuell möglich zu beschränken, welche Nutzer/Nutzerinnen auf den Dienst oder die Dienstversion zugreifen und ihn/sie nutzen dürfen, selbst wenn das Objekt 604 im ganzen Netz 304 (z. B. für einen Kunden 112) bereitgestellt wird. Mit anderen Worten, die Nutzer/Nutzerinnen des Netzes 304 haben eventuell nicht zwangsläufig Zugriff auf jeden im Netz 304 bereitgestellten Dienst und einige Nutzer/Nutzerinnen haben eventuell Zugriff auf andere Dienste oder Dienstversionen als andere Nutzer/Nutzerinnen.
Wenngleich nur ein Kommunikationsserver 316, zwei Anwendungsserver 336, ein Nutzerportalserver 356 und ein Systemverwalterserver 364 abgebildet sind, ist für den Fachmann ersichtlich, dass ein, zwei, drei oder mehr Server eines beliebigen Typs zur Verfügung gestellt werden können und jeder Server möglicherweise so konfiguriert ist, dass er eine oder mehrere der hierin erörterten Funktionen zur Verfügung stellt.
Die Anwendungen, die in eine konkrete Anwendungssequenz (z. B. über den Kommunikationsserver 316 und den Anwendungsserver 336) aufgenommen werden können, werden allgemein aufgenommen, um die Nutzereinstellungen 324 zu berücksichtigen und demgemäß Kommunikationsdienste zur Verfügung zu stellen. Es sollte sich jedoch verstehen, dass die Nutzereinstellungen in einigen Ausführungsformen nur innerhalb der Grenzen der Dienste gelten, die vom Systemadministrator für den Nutzer/die Nutzerin aktiviert werden. Ferner können einige vom Administrator zugewiesene Dienste vom Nutzer/von der Nutzerin basierend auf Nutzereinstellungen eventuell nicht deaktiviert werden (z. B. können verbindliche Rufaufzeichnungsdienste, die dem Nutzer/der Nutzerin vom Administrator zugewiesen wurden, eventuell nicht deaktiviert werden).
Anwendungen können je nach Medientyp, Funktion und dergleichen variieren. Beispielhafte Typen von Anwendungen, die über die Unterkomponenten 340 zur Verfügung gestellt werden können, beinhalten unter anderem eine EC-500-Anwendung, eine Rufaufbauanwendung, eine Voicemail-Anwendung, eine E-Mail-Anwendung, eine Sprachanwendung, eine Videoanwendung, eine Textanwendung, eine Konferenzanwendung, eine Rufaufzeichnungsanwendung, einen Kommunikationsprotokolldienst, eine Sicherheitsanwendung, eine Verschlüsselungsanwendung, eine Zusammenarbeitsanwendung, eine Whiteboard-Anwendung, Mobilitätsanwendungen, Präsenzanwendungen, Medienanwendungen, Messaging-Anwendungen, Bridging-Anwendungen und Anwendungen beliebiger anderer Art, die Kommunikationen ergänzen oder erweitern können. Zusätzlich können eine, zwei, drei oder mehr Anwendungen einer vorgegebenen Art in eine einzelne Anwendungssequenz aufgenommen werden, ohne vom Schutzbereich der vorliegenden Erfindung abzuweichen.
Der Kommunikationsserver 316, der Anwendungsserver 336, der Nutzerportalserver 356 und der Systemverwalterserver 364 können nur mit einigen Servertypen korrespondieren, die im Netz 304 bereitgestellt werden können. Es können noch andere Server 372, die andere Unterkomponententypen 376 beinhalten, zur Verfügung gestellt werden. Geeignete Beispiele für solche Server 372 und/oder Unterkomponententypen 376 beinhalten unter anderem Verwaltungs-Server/-Agents, vom Nutzer/von der Nutzerin eingeführte Datenspeicher, Serviceability-Server/-Agents, Medienverarbeitungs-Server/-Agents, Voice-eXtensible-Markup-Language(VXML)-Speicher, Inhaltsspeicher, E-Mail-Server, Voicemail-Server, Kalenderserver, Konferenzserver, Präsenzserver und andere Servertypen, von denen bekannt ist, dass sie Client-Einrichtungen konkrete Dienste zur Verfügung stellen. In einigen Ausführungsformen werden die anderen Server 372 möglicherweise auch als Anwendungsserver 336 angesehen, welche eine oder mehrere Anwendungen zur Nutzung in einer Kommunikationssitzung zur Verfügung stellen.
Die internen Kommunikationseinrichtungen 348 können Kommunikationseinrichtungen außerhalb des Netzes 304 ähneln oder mit ihnen identisch sein, mit der Ausnahme, dass die internen Kommunikationseinrichtungen 348 vom das Netz 304 administrierenden Unternehmen eingeführt werden und sich oft in dessen Eigentum befinden. Beispielhafte Typen von Kommunikationseinrichtungen 348 beinhalten unter anderem Handys, Smartphones, Laptops, Personal Computer (PCs), Personal Digital Assistants (PDAs), Digitaltelefone, Analogtelefone und/oder beliebige andere Typen von mit Fähigkeiten ausgestatteten Telefonen, Softphones oder Digitaltelefonen. Beispiele für geeignete Telefone beinhalten das 1600^TM, das 2400^TM, das 4600^TM, das 5400^TM, das 5600^TM, das 9600^TM, das 9620^TM, das 9630^TM, das 9640^TM, das 9640G^TM, das 9650^TM, das 9608^TM, das 9611^TM, das 9621^TM, das 9641^TM und die Quick-Edition^TM-Telefone, IP-Wireless-Telefone (etwa die IP-DECT-TM-Telefone der Avaya Inc.), Videotelefone (etwa das Videophone^TM der Avaya Inc.) und Softphones wie das Avaya Flare^TM.
Der Datenspeicher 352 kann so konfiguriert sein, dass er Unternehmensteilnehmerinformationen beinhaltet, etwa Name, Stellenbezeichnung, elektronische Adressinformationen (z. B. Telefonnummer, E-Mail-Adresse, Instant-Messaging-Handle, Durchwahlnummer und dergleichen), Teilnehmerkontaktlisten (z. B. Kontaktname und elektronische Adressinformationen), andere Personaldaten, Nutzereinstellungen 324 und dergleichen. Im Datenspeicher 352 enthaltene Informationen können für einen oder mehrere der Server 316, 336, 356, 364, 372 über verschiedene Typen von Datenbanken, Servern usw. verfügbar gemacht werden.
Die verschiedenen in 3 abgebildeten Server und Komponenten können getrennt (d. h. auf unterschiedlichen Servern) oder zusammen (d. h. auf einem einzelnen Server) implementiert werden. Vor allem können zwei oder mehr abgebildete Komponenten (z. B. der Kommunikationsserver 316 und der Anwendungsserver 336) auf einem einzelnen Server implementiert werden, ohne vom Schutzbereich der vorliegenden Erfindung abzuweichen. Somit kann eine einzelne Einrichtung die Funktionalität diverser Komponenten, die in 3 getrennt abgebildet sind, zur Verfügung stellen. Um ein weiteres Beispiel anzuführen, die Grenzeinrichtung 308 und der Kommunikationsserver 316 sind möglicherweise auf einer einzelnen Einrichtung implementiert.
Wie aus 4 hervorgeht, korrespondiert eine konkrete Unterkomponente, die auf einem Server (z. B. einer auf dem Systemverwalterserver 364 bereitgestellten Systemverwalterunterkomponente 368) bereitgestellt ist, möglicherweise mit einem konkreten Diensttyp und einer konkreten Version dieses Diensttyps. Auf einem einzelnen Server können diverse unterschiedliche Diensttypen oder unterschiedliche Versionen desselben Diensttyps bereitgestellt werden, ohne vom Schutzbereich der vorliegenden Offenbarung abzuweichen. Die Diensttypen können weit definiert sein (z. B. Kommunikationsdienst, Webdienst, Mediendienst usw.) oder als ein spezielles Produkt, das von einer speziellen Gesellschaft angeboten wird, eng definiert sein (z. B. Avaya one-X^® Communicator, Avaya one-X^® Mobile, Avaya IP Office, AvayaLive^TM Connect, Avaya Aura^® Conferencing, Unified Messaging, Avaya Flare^TM Experience, WebEx^TM Collaboration Services, Sprachanalyse- oder Data-Mining-Dienste wie diejenigen, die von Aurix^TM zur Verfügung gestellt werden, usw.). Falls Unterkomponenten eines gemeinsamen Diensttyps und einer gemeinsamen Version dieses Diensttyps auf einer Mehrzahl unterschiedlicher Server zur Verfügung gestellt werden, bewirken diese Unterkomponenten daraufhin möglicherweise, dass die unterschiedlichen Server derart zusammenwirken, dass der gemeinsame Diensttyp und die gemeinsame Version dieses Diensttyps nahtlos zur Verfügung gestellt werden. Auch wenn dies nicht gezeigt wird, sollte es sich verstehen, dass Vorlagen (siehe 7) auf dem Systemverwalter 364 administriert und Nutzern/Nutzerinnen zugewiesen werden können. Auf diese administrierten Vorlagen kann daraufhin von anderen Servern zugegriffen werden, um die für einen vorgegebenen Nutzer/eine vorgegebene Nutzerin verfügbaren Dienste/Versionen zu bestimmen.
Wie oben erwähnt, kann, obwohl keine Lizenzierungsunterkomponente abgebildet ist, auch eine Lizenzierungsunterkomponente bereitgestellt werden, vielleicht auf einem Lizenzierungsserver. Andere Server (z. B. der Systemverwalter 364) können daraufhin über den Lizenzierungsserver prüfen, ob die entsprechenden Lizenzen zum Zulassen des Nutzers/der Nutzerin dieses Dienstes vorliegen. Diese Lizenzinformationen könnten die Anzahl der Nutzer/Nutzerinnen, denen der Dienst in der Vorlage zugewiesen sein kann, beinhalten und der Systemverwalter 364 ließe nicht zu, dass dem Dienst mehr Nutzer/Nutzerinnen als von der Lizenzierungsunterkomponente zugelassen zugewiesen werden.
5 bildet ein Kommunikationssystem 500 gemäß mindestens einigen Ausführungsformen der vorliegenden Offenbarung ab. Das Kommunikationssystem 500 umfasst einen gemeinsamen Kommunikationsdienst 512, der für mehrere unterschiedliche Kunden 508a–N verfügbar gemacht wird. Einer der Kunden (z. B. der dritte Kunde 508c) umfasst möglicherweise ein Netz 304, wie in 3 und 4 abgebildet, wobei sich in seinen Räumlichkeiten mehrere physische Server befinden. Die Server enthalten möglicherweise verschiedene Kommunikationsdienste 512 in Form von Unterkomponenten, die von einem Objekt 604 bereitgestellt wurden. Einer oder mehrere der Kommunikationsdienste 512 (oder von Diensten eines beliebigen anderen Typs) können gemäß Ausführungsformen der vorliegenden Offenbarung mit anderen Kunden 508a, 508b, 508N gemeinsam genutzt werden. Der Zugriff auf die gemeinsamen Kommunikationsdienste 512 kann durch Nutzung von Berechtigungsvorlagen (siehe 7) in den Kundenräumlichkeiten genauso gesteuert werden, wie ein einzelnes Unternehmen oder ein einzelner Kunde Zugriffe auf solche Dienste pro Nutzer/Nutzerin steuert.
5 zeigt auch, dass sich innerhalb des Kommunikationsnetzes 504 ein gemeinsamer Kommunikationsdienst 512 befinden kann (z. B. als cloudbasierter Kommunikationsdienst 512). Der cloudbasierte Kommunikationsdienst 512 wird möglicherweise von zwei oder mehr Kunden 508 in sicherer Weise gemeinsam genutzt – das heißt, Daten von einem Kunden werden einem anderen Kunden nicht versehentlich offengelegt. Diese Sicherheit kann erzielt werden, indem geschützte oder sensible Daten in den Kundenräumlichkeiten vor Ort oder in verschlüsselter Form geführt werden, falls die Daten auf einem gemeinsamen Server oder in einem gemeinsamen Datenspeicher 352 geführt werden.
Es wurde bereits beschrieben, wie ein Objekt 604 gemäß 6, auf die erneut Bezug genommen wird, möglicherweise mehrere Unterkomponenten 608, 616, 620 und einen Satz von Bereitstellungsbefehlen 612 umfasst, die, wenn sie vom Objektverteiler 332 befolgt oder ausgeführt werden, bewirken, dass die verschiedenen Unterkomponenten 608, 616, 620 an unterschiedliche Server in einem Netz 304 verteilt werden. In einigen Ausführungsformen enthalten die Bereitstellungsbefehle 612 zusätzlich dazu, dass sie Befehle zum Bereitstellen des Objekts 604 enthalten, sobald sie von einem Kunden 112a–N heruntergeladen wurden, möglicherweise auch noch andere Informationen, welche das Objekt 604 beschreiben. Insbesondere beinhalten die Bereitstellungsbefehle 612 möglicherweise auch Produktdokumentation, Nutzerhandbücher, Administrationshandbücher, Konfigurationsrichtlinien und beliebige andere Typen von Daten, die das Objekt beschreiben. In einigen Ausführungsformen werden die Bereitstellungsbefehle 612 möglicherweise in Form einer oder mehrerer Enterprise-Archive(EAR)-Dateien und/oder Web-Application-Archive(WAR)-Dateien zur Verfügung gestellt. Zudem können die Unterkomponenten 608, 616, 620 auch als eine oder mehrere EAR- und/oder WAR-Dateien in das Objekt 604 eingepackt werden.
Eine EAR-Datei ist ein Dateiformat, das von Java EE zum Einpacken eines oder mehrerer Module in ein einzelnes Archiv genutzt wird, damit die Bereitstellung der verschiedenen Teile dieses einzelnen Archivs auf einem einzelnen Server gleichzeitig und kohärent erfolgen kann. Sobald eine EAR-Datei einer konkreten Unterkomponente an einen konkreten Server geleitet wurde (z. B. wurde eine Nutzerportalunterkomponente 360 gemäß den Bereitstellungsbefehlen 612 für den Nutzerportalserver 356 bereitgestellt), bewirkt die inhärente Beschaffenheit der EAR-Datei somit, dass diese konkrete Unterkomponente innerhalb des konkreten Servers nahtlos bereitgestellt wird. Eine WAR-Datei ist ähnlich wie eine EAR-Datei eine Java-Archive(JAR)-Datei, die zum Verteilen einer Sammlung von JavaServer Pages, Java Servlets, Java-Klassen, XML-Dateien, Tag Librarys, statischer Webseiten (HTML- und darauf bezogener Dateien) und anderer Ressourcen, die zusammen eine Webanwendung bilden, genutzt wird. Das von der WAR-Datei genutzte JAR-Dateiformat ist ein Archivdateiformat, das zum Aggregieren von vielen Java-Klasse-Dateien und assoziierten Metadaten und Ressourcen in einer Datei genutzt wird, um die Anwendungssoftware oder Librarys auf der Java-Plattform einfach zu verteilen.
In einigen Ausführungsformen werden einige der Unterkomponenten des Objekts 604 möglicherweise als eine EAR-Datei eingepackt, während andere Unterkomponenten des Objekts 604 möglicherweise als eine WAR-Datei eingepackt werden. Der Typ der für die Unterkomponente genutzten Datei ist abhängig von der Beschaffenheit der Unterkomponente und den Fähigkeiten des Servers, der die Unterkomponente letztlich empfängt und bereitstellt. Um ein nicht beschränkendes Beispiel anzuführen, die Anrufverarbeitungsunterkomponente 616 und die Bereitstellungsbefehle werden möglicherweise als EAR-Dateien zur Verfügung gestellt, während die Systemverwalterunterkomponente 620 und die Nutzerportalunterkomponente 608 möglicherweise als WAR-Dateien zur Verfügung gestellt werden.
Nunmehr unter Bezugnahme auf 7 werden zusätzliche Einzelheiten einer Vorlage 700, die genutzt werden kann, um Zugriffe auf einen Dienst pro Nutzer/Nutzerin oder Zugriffe auf einen gemeinsamen Dienst 512 pro Kunde zu steuern, gemäß mindestens einigen Ausführungsformen der vorliegenden Offenbarung beschrieben. Auch wenn viele Einzelheiten der Vorlage 700 im Zusammenhang mit der Steuerung von Zugriffen auf Dienste pro Nutzer/Nutzerin beschrieben werden, sollte es sich verstehen, dass sich Lehren hinsichtlich Zugriffen pro Nutzer/Nutzerin auch auf Zugriffe auf gemeinsame Dienste 512 pro Kunde einfach anwenden lassen. Auch wenn die Vorlage 700 mit Bezug auf eine konkrete Struktur (z. B. eine Tabellenstruktur) beschrieben wird, sollte es sich ferner verstehen, dass Ausführungsformen der vorliegenden Offenbarung dadurch nicht beschränkt werden. Insbesondere können Datenstrukturen oder Sammlungen von Datenstrukturen eines beliebigen Typs genutzt werden, um die Features der hierin erörterten Vorlage 700 zur Verfügung zu stellen.
Eine Vorlage 700 umfasst möglicherweise eine Anzahl von Datenfeldern, die von einem Endnutzer/einer Endnutzerin eines Dienstes und/oder von einem Systemadministrator eingeführt werden können. Die Typen der Datenfelder, die in die Vorlage 700 aufgenommen werden können, beinhalten unter anderem ein Nutzerkennungsfeld 704 und mehrere Dienstkennungsfelder 708, 712, 716.
Das Nutzerkennungsfeld 704 identifiziert möglicherweise einen konkreten Nutzer/eine konkrete Nutzerin in einem Unternehmensnetz. Zum Beispiel identifiziert das Nutzerkennungsfeld 704 möglicherweise einen Mitarbeiter eines Kunden 112a–N, einen Kunden eines Betriebs, einen Administrator eines Betriebs, eine Gruppe von Mitarbeitern, eine Gruppe von Kunden usw. Das Nutzerkennungsfeld 704 wird möglicherweise auch als Kennung von Kunden genutzt, falls ein Kommunikationsdienst 512 von mehreren unterschiedlichen Kunden gemeinsam genutzt wird. Es können beliebige Strings aus Zahlen, Zeichen, Symbolen, Bits oder dergleichen genutzt werden, um einen Nutzer/eine Nutzerin oder einen Kunden im Nutzerkennungsfeld 704 eindeutig zu identifizieren. Beispiele für Daten, die zum Identifizieren eines Nutzers/einer Nutzerin genutzt werden können, beinhalten unter anderem den Namen, die Adresse, die Sozialversicherungsnummer, die Mitarbeiternummer, die Anrede, Aliasse (z. B. den eingetragenen Geschäftssitz) usw. Beispiele für Daten, die zum Identifizieren eines Kunden genutzt werden können, beinhalten unter anderem die Firma, Unternehmensabkürzungen, -marken, -nummern usw.
Jedes der Dienstkennungsfelder 708, 712, 716 korrespondiert möglicherweise mit einem anderen Dienst, der für einen Nutzer/eine Nutzerin deswegen verfügbar ist, weil am Netz 304 ein korrespondierendes Objekt 604 heruntergeladen wurde und die erforderlichen Unterkomponenten 608, 616, 620 an die entsprechenden Server innerhalb des Netzes 304 verteilt wurden. Sobald ein Objekt 604 heruntergeladen und am Netz 304 bereitgestellt wurde, kann der Vorlage 700 ein neues Feld hinzugefügt werden, das den vom Objekt 604 zur Verfügung gestellten Dienst identifiziert.
Innerhalb des heruntergeladenen Objekts 604 können (z. B. über die Bereitstellungsbefehle 612) Standardeinstellungen für Nutzerzugriffe auf einen Dienst definiert werden und/oder sie können durch Regeln definiert werden, die von einem Systemadministrator des Netzes 304 erzeugt wurden. Zum Beispiel können die Standardeinstellungen für Nutzerzugriffe definieren, dass keinem Nutzer/keiner Nutzerin Zugriff auf den korrespondierenden Dienst gewährt wird. Die Darstellung einer solchen Berechtigung oder ihr Nichtvorliegen ist mit Bezug auf den ersten Kommunikationsdienst abgebildet, der im ersten Dienstkennungsfeld 708 für Nutzer/Nutzerin 3 identifiziert ist.
Um ein weiteres Beispiel anzuführen, der Käufer des Dienstes vom Dienstlager 108 (z. B. ein Administrator des Netzes 304) definiert möglicherweise, welche Nutzer/Nutzerinnen den Dienst anfänglich nutzen dürfen, zum Kaufzeitpunkt. Der Objektgenerator 216 am Dienstlager 108 kann das Objekt 604 gemäß der Käuferanforderung konstruieren. Vor allem können die Bereitstellungsbefehle 612 definieren, dass dann, wenn in der Vorlage 700 das neu erzeugte Feld erzeugt wird, nur die vom Käufer identifizierten Nutzer/Nutzerinnen auf den Dienst zugreifen dürfen. Allen anderen Nutzern/Nutzerinnen wird kein Zugriff auf den Dienst gewährt.
In der abgebildeten Tabellenstruktur kann die Schnittfläche der Reihe eines Nutzers/einer Nutzerin und der Spalte des Diensttyps genutzt werden, um zu definieren, welche Zugriffsberechtigungen dem Nutzer/der Nutzerin mit Bezug auf den Dienst gewährt werden. Diese Berechtigungen werden für eine spezielle Version des Diensttyps möglicherweise statisch definiert. Alternativ umfassen die Berechtigungen möglicherweise einen Platzhalterwert, der definiert, dass der Nutzer/die Nutzerin auf einen Bereich von Versionen des korrespondierenden Diensttyps (z. B. eine beliebige ältere Version als Version X) zugreifen darf. Alternativ umfassen die Berechtigungen möglicherweise einen Wert, der zulässt, dass der Nutzer/die Nutzerin auf eine beliebige Version oder die aktuelle Version eines konkreten Dienstes zugreift.
Ein Vorteil bei der Nutzung der Vorlage 700 besteht darin, dass unterschiedliche Nutzer/Nutzerinnen desselben Unternehmens und innerhalb desselben Netzes 304 unterschiedliche Zugriffsberechtigungen für einen Dienst haben können. Wie aus dem Beispiel von 7 hervorgeht, wird Nutzer/Nutzerin 1 Zugriff auf Version 1.0 von Kommunikationsdienst 2, der im Feld 712 identifiziert ist, gewährt, während Nutzer/Nutzerin 2 Zugriff auf Version 1.1 desselben Kommunikationsdienstes gewährt wird. Das Feld 712 definiert auch, dass Nutzergruppe A kein Zugriff auf Kommunikationsdienst 2 gewährt wird, dass jedoch Gruppe B Zugriff auf Version 3.1 desselben Kommunikationsdienstes gewährt wird. Falls zwischen individuell für einen Nutzer/eine Nutzerin definierten Berechtigungen und für denselben Nutzer/dieselbe Nutzerin auf Gruppenbasis definierten Berechtigungen ein Widerspruch besteht (z. B. gehört Nutzer/Nutzerin 1 zu Gruppe A), können die Berechtigungen durch die individuell definierten Nutzerberechtigungen gesteuert werden. Es kann jedoch vorteilhaft sein, wenn bestimmte Widersprüche durch Gruppenberechtigungen statt individuelle Berechtigungen gesteuert werden.
In einigen Ausführungsformen ist die Vorlage 700 möglicherweise in die Nutzereinstellungen 324 aufgenommen und der Dienstauswähler 320 kann darauf Bezug nehmen, wenn er bestimmt, auf welche Diensttypen und Versionen davon ein Nutzer/eine Nutzerin zugreifen darf. Während die Vorlage 700 möglicherweise im Rahmen der Nutzereinstellungen 324 zur Verfügung gestellt wird, kann möglich sein einzuschränken, inwieweit ein Nutzer/eine Nutzerin Daten in einem Teil oder überall in der Vorlage 700 ändern, bearbeiten oder schreiben kann. Mit anderen Worten, nur weil die Vorlage 700 in die Nutzereinstellungen 324 aufgenommen ist, bedeutet dies nicht zwangsläufig, dass für den Nutzer/die Nutzerin die gesamte Vorlage 700 zur Bearbeitung verfügbar ist. Eventuell ist jedoch möglich zuzulassen, dass der Nutzer/die Nutzerin Abschnitte der Vorlage 700 innerhalb bestimmter Parameter bearbeitet, die entweder vom Administrator des Netzes 304 oder vom Anbieter des Dienstes (z. B. vom Betreiber des Dienstlagers 108) definiert werden.
Nunmehr unter Bezugnahme auf 8 wird eine Datenstruktur 800, die genutzt wird, um die hierarchische Definition und Veränderung von Regeln mit Bezug auf einen Dienst zuzulassen, gemäß mindestens einigen Ausführungsformen der vorliegenden Offenbarung beschrieben. Die Datenstruktur 800 kann in die Vorlage 700 integriert werden oder sie ist möglicherweise von der Vorlage 700 getrennt. Falls Nutzer/Nutzerin 1 zum Beispiel bestimmte Regeln für den Kommunikationsdienst 1 innerhalb der Datenstruktur 800 definiert, können diese nutzerdefinierten Regeln entweder in die Schnittfläche der Reihe von Nutzer/Nutzerin 1 und von Feld 708 kopiert werden. Oder alternativ zeigt ein Zeiger von der Schnittfläche der Reihe von Nutzer/Nutzerin 1 und von Feld 708 möglicherweise zum korrespondierenden Ort in der Datenstruktur 800. Die Datenstruktur 800 kann in die Nutzereinstellungen 324 aufgenommen oder für den Dienstauswähler 320 remote verfügbar gemacht werden.
In einigen Ausführungsformen umfasst die Datenstruktur 800 hierarchisch strukturierte Regeln, die ermöglichen, dass ein Nutzer/eine Nutzerin Betriebsparameter, Regeln oder Berechtigungen eines beliebigen Typs mit Bezug auf einen konkreten Dienst definiert, solange diese innerhalb eines zulässigen Regelsatzes liegen, der vom Anbieter des Dienstes und vom Administrator des Netzes 304 hierarchisch definiert wurde. Insbesondere umfasst die Datenstruktur 800 möglicherweise für jeden innerhalb eines Netzes 304 verfügbaren Dienst eine erste Ebene von Regeln 804, eine zweite Ebene von Regeln 808, eine dritte Ebene von Regeln 812, eine vierte Ebene von Regeln 824 usw. In einigen Ausführungsformen umfasst die erste Ebene von Regeln 804 anbieterdefinierte Regeln für den konkreten Dienst, die zweite Ebene von Regeln 808 umfasst administratordefinierte Regeln für den Dienst, die dritte Ebene von Regeln 812 umfasst nutzerdefinierte Regeln 816, gruppendefinierte Regeln 820 oder Standardregeln 828 für den Dienst, und die vierte Ebene von Regeln 824 umfasst nutzerdefinierte Regeln innerhalb der gruppendefinierten Regeln 820.
Die erste Ebene von Regeln 804 steuert möglicherweise Optionen, die für die unteren Ebenen von Regeln verfügbar sind. Falls der Anbieter zum Beispiel definiert, dass ein konkreter Dienst eine von drei Typen von Nutzerschnittstellen (z. B. drei unterschiedliche Skins für eine Webschnittstelle) aufweisen kann, dürfen der Administrator, die Nutzer/Nutzerinnen und die Gruppen möglicherweise wählen, welche der drei Schnittstellen von einem konkreten Nutzer/einer konkreten Nutzerin beim Zugreifen auf den Dienst genutzt werden sollen.
Die zweite Ebene von Regeln 808 verfeinert die erste Ebene von Regeln 804 weiter, kann jedoch die erste Ebene von Regeln 804 nicht erweitern oder über sie hinausgehen. Weiter unter Bezugnahme auf das obige Beispiel definiert der Administrator im Rahmen der Administratorregeln möglicherweise, dass für Nutzer/Nutzerinnen des konkreten Dienstes nur der erste und der zweite Typ der Nutzerschnittstellen verfügbar gemacht werden. Der Administrator darf neben den vom Anbieter definierten Schnittstellentypen keinen vierten Schnittstellentyp definieren.
Ähnlich wie die zweite Ebene von Regeln 808 kann die dritte Ebene von Regeln 812 die zweite Ebene von Regeln 808 und die erste Ebene von Regeln 804 weiter verfeinern, jedoch die erste und die zweite Ebene von Regeln 804, 808 nicht erweitern oder über sie hinausgehen. Weiter unter Bezugnahme auf das Schnittstellenbeispiel darf der Nutzer/die Nutzerin möglicherweise zwischen dem ersten und dem zweiten Nutzerschnittstellentyp für den konkreten Dienst auswählen. Der Nutzer/die Nutzerin darf die dritte Schnittstelle nicht auswählen, weil sie vom Administrator mit Einschränkungen belegt wurde, und darf keine vierte Schnittstelle auswählen, weil sie vom Anbieter nicht aktiviert wurde. Die Nutzerregel 816 kann die Auswahl des Nutzers/der Nutzerin für den Dienst speziell definieren oder sie kann sich auf die Standardregeln 828 beziehen, falls der Nutzer/die Nutzerin seine/ihre Auswahl nicht definiert hat.
Ähnlich wie die Nutzerregeln 816 können die Gruppenregeln 820 und die Nutzerregeln 824 von Nutzern/Nutzerinnen oder Gruppen von Nutzern/Nutzerinnen genutzt werden, um eine Einstellung für einen Dienst oder einen Aspekt eines Dienstes weiter zu verfeinern. Es sollte sich verstehen, dass die innerhalb der Datenstruktur 800 definierten Regeln nicht darauf beschränkt sind zu definieren, welche Schnittstelle ein Nutzer/eine Nutzerin für den Zugriff auf einen Dienst gebraucht. Ein weiterer Anwendungsfall für die Datenstruktur 800 besteht darin, dass ein Anbieter 804 einen Dienst für einen Kunden 112 möglicherweise über ein herunterladbares Objekt 604 zur Verfügung stellt. Der Dienst korrespondiert möglicherweise mit einem konkreten Kommunikationsdiensttyp (z. B. Dynamic Device Pairing, Routing-Regeln, EC500 usw.).
Zum Beispiel handelt es sich bei dem konkreten Kommunikationsdiensttyp um einen ersten Kommunikationsdienst und der erste Kommunikationsdienst hat 10 unterschiedliche Versionen. Die aktuellen Versionen (z. B. Versionen 9 und 10) werden vom Dienstanbieter unterstützt und die ältesten Versionen (z. B. Versionen 1 und 2) werden vom Dienstanbieter nicht mehr unterstützt. In diesem Szenario definiert der Anbieter innerhalb der ersten Ebene von Regeln 804 möglicherweise, dass nur Versionen 3–10 des Dienstes verfügbar sind. Weiter unter Bezugnahme auf dieses Szenario hat der Administrator möglicherweise für alle Nutzer/Nutzerinnen nur Lizenzen für Versionen 7–9 gekauft und hat für Nutzer/Nutzerin 1 (z. B. einen Testnutzer/eine Testnutzerin) möglicherweise nur eine Lizenz für Version 10 gekauft. Der Administrator kann innerhalb der zweiten Ebene von Regeln 808 definieren, dass Versionen 7–9 für alle Nutzer/Nutzerinnen des Netzes 304 verfügbar sind, während Version 10 nur für Nutzer/Nutzerin 1 verfügbar ist. Der Administrator definiert möglicherweise auch die Version des Dienstes, die genutzt wird, falls ein Nutzer/eine Nutzerin keine Dienstversion für ihn/sie zur Nutzung auswählt (z. B. über die Standardregeln 828). Daraufhin dürfen beliebige Nutzer/Nutzerinnen oder Nutzergruppen eine spezielle Version des Dienstes aus Versionen 7–9 auswählen, während Nutzer/Nutzerin 1 eine spezielle Version des Dienstes aus Versionen 7–10 auswählen darf. Dadurch wird ermöglicht, dass der Systemadministrator neue Versionen eines Dienstes austestet, ohne für jeden Nutzer/jede Nutzerin im Netz 304 eine Lizenz für den Dienst kaufen zu müssen. Dadurch wird auch zugelassen, dass jeder Nutzer/jede Nutzerin bei der Auswahl der Version des Dienstes, die er/sie gebraucht, einen gewissen Spielraum hat. Somit dürfen Nutzer/Nutzerinnen, die den Dienst frühzeitig angewendet haben, neuere Versionen des Dienstes auswählen, während Nutzer/Nutzerinnen, die den Dienst spät angewendet haben, die ältere Version, an die sie sich gewöhnt haben, weiter nutzen dürfen.
Nunmehr unter Bezugnahme auf 9 wird ein Verfahren zum Empfangen und Ausführen einer Bestellung eines Dienstes, etwa eines Kommunikationsdienstes, gemäß mindestens einigen Ausführungsformen der vorliegenden Offenbarung beschrieben. Das Verfahren beginnt, wenn am Dienstlager 108 eine Bestellung eines Dienstes empfangen wird (Schritt 904). In einigen Ausführungsformen wird die Bestellung eines Dienstes möglicherweise über das Kundenportal 208 (z. B. als webbasierte Anforderung) empfangen.
Das Verfahren wird fortgesetzt, indem der Objektgenerator 216 die Bestellung analysiert, um Parameter des angeforderten Dienstes zu bestimmen (Schritt 908). Speziell kann der Objektgenerator 216 anhand der Parameter der Anforderung bestimmen, welcher Dienst angefordert wurde, welche Version des Dienstes angefordert wurde, welche Unterkomponenten 228 erforderlich sind, um die festgelegte Version des Dienstes zu erstellen, welche Bereitstellungsbefehle 612 erforderlich sein werden, um die Unterkomponenten in den Käuferräumlichkeiten passend zu verteilen, wie viele Lizenzen für den Dienst gekauft wurden, welche Nutzer/Nutzerinnen anfänglich zum Zugriff auf den Dienst berechtigt sein werden, welchen Nutzern/Nutzerinnen der Zugriff auf den Dienst anfänglich verweigert wird, Anbieterregeln für den Dienst und/oder über welche Servertypen der Käufer in seinen Räumlichkeiten verfügt, um den Dienst zu unterstützen. Zusätzlich beinhaltet die Bestellung in einigen Ausführungsformen möglicherweise Metadaten, die einen oder mehrere Aspekte des aktuellen Dienstes und/oder des gewünschten Dienstes beschreiben. Zum Beispiel umfasst eine Bestellung möglicherweise Metadaten, die beschreiben, ob ein konkreter bestehender Dienst oder konkrete bestehende Komponenten dieses Dienstes bestimmte Fähigkeiten wie High-Availability(HA)-Fähigkeiten aufweisen oder nicht. Die in der Bestellung enthaltenen Metadaten tragen möglicherweise dazu bei zu definieren, welche Aktualisierungstypen für den Kunden verfügbar oder erforderlich sind, um den Dienst erfolgreich zu aktualisieren.
Basierend auf der Analyse der Bestellung bereitet der Objektgenerator 216 das herunterladbare Objekt 604 gemäß den Parametern der Anforderung vor (Schritt 912). Speziell ruft der Objektgenerator 216 die erforderlichen Unterkomponenten 228 ab und erstellt das Objekt 604. Die Unterkomponenten 228 können im Objekt 604 als eine oder mehrere EAR-Dateien und WAR-Dateien eingepackt werden. Des Weiteren können die Bereitstellungsbefehle 612 als eine ausführbare Datei, eine EAR-Datei, eine WAR-Datei, eine Textdatei oder dergleichen eingepackt werden.
Die abgerufenen Unterkomponenten werden daraufhin möglicherweise in das Objekt 604 eingepackt und zur Übertragung an den Käufer/Kunden 112 über das Kommunikationsnetz 104 vorbereitet (Schritt 916). Bei diesem Schritt bereitet der Objektgenerator 216 das Objekt 604 möglicherweise als ein oder mehrere Pakete vor, die über einen über das Kommunikationsnetz 104 aufgebauten Kommunikationskanal zwischen dem Dienstlager 108 und dem Kunden 112 übertragen werden sollen. Dies beinhaltet möglicherweise, dass das Objekt 604 an eine oder mehrere elektronische Nachrichten (z. B. eine E-Mail-Nachricht, eine SMS-Nachricht oder dergleichen) angehängt wird, das Objekt 604 in ein oder mehrere Pakete, die über das Kommunikationsnetz 104 übertragen werden können, eingeschlossen wird oder dergleichen. Der Objektgenerator 216 und/oder die Objektübermittlungsschnittstelle 212 können den Einpackschritt durchführen.
Danach wird das herunterladbare Objekt 604 von der Objektübermittlungsschnittstelle 212 über das Kommunikationsnetz 104 an den Käufer übermittelt (Schritt 920). Wie oben erörtert, beinhaltet dieser Übertragungsschritt möglicherweise, dass eine oder mehrere elektronische Nachrichten oder Pakete, die das Objekt 604 zum Teil oder insgesamt beinhalten, versendet werden.
Nunmehr unter Bezugnahme auf 10 wird ein Verfahren zum Bereitstellen und Installieren eines herunterladbaren Objekts 604 gemäß Ausführungsformen der vorliegenden Offenbarung beschrieben. Das Verfahren wird eingeleitet, wenn ein Kunde 112 (z. B. ein Systemadministrator eines oder mehrerer Netze 304) eine Bestellung eines Dienstes, etwa eines Kommunikationsdienstes, unterbreitet (Schritt 1004). Nachdem die Bestellung des Dienstes aufgegeben worden ist, werden die Schritte von 9 durchgeführt und der Kunde 112 wartet, bis das herunterladbare Objekt 604 am Netz 304 empfangen wird. Das herunterladbare Objekt 604 kann anfänglich an der Grenzeinrichtung 308 empfangen und anschließend an den Kommunikationsserver 316 geroutet werden, wo es anfänglich heruntergeladen wird (z. B. in einem persistenten oder temporären Arbeitsspeicher auf dem Kommunikationsserver 316 oder irgendeinem anderen Server 372 gespeichert wird) (Schritt 1008).
Der nächste Schritt besteht darin, dass der Objektentpacker 328 und/oder der Objektverteiler 332 die Bereitstellungsbefehle 612 analysieren, um die Inhalte des Objekts 604 zu bestimmen und wohin jede Unterkomponente innerhalb des Netzes 304 geleitet werden soll (Schritt 1012). Die verschiedenen Unterkomponenten 608, 616, 620 des Objekts 604 werden basierend auf den Bereitstellungsbefehlen 612 für ihre korrespondierenden Server 316, 336, 356, 364, 372 innerhalb des Netzes 304 bereitgestellt (Schritt 1016). Nach dem Empfangen der Unterkomponente entpackt der empfangende Server die Unterkomponente (entpackt z. B. die EAR- oder die WAR-Datei) und installiert sie innerhalb des Servers gemäß den in der Unterkomponente enthaltenen Befehlen (Schritt 1020). Um ein nicht beschränkendes Beispiel anzuführen, die Nutzerportalunterkomponente 608 wird möglicherweise für den Nutzerportalserver 356 bereitgestellt, wo sie als Unterkomponente 360 gespeichert wird, die Anrufverarbeitungsunterkomponente 616 wird möglicherweise für den Anwendungsserver 336 bereitgestellt, wo sie als Unterkomponente 340 gespeichert wird, und die Systemverwalterunterkomponente 620 wird möglicherweise für den Systemverwalterserver 364 bereitgestellt, wo sie als Unterkomponente 368 gespeichert wird.
Nunmehr unter Bezugnahme auf 11 wird ein Verfahren zum Anpassen eines herunterladbaren Objekts 604 gemäß Ausführungsformen der vorliegenden Offenbarung beschrieben. Das Verfahren beginnt ähnlich wie das Verfahren von 10, indem ein Kunde 112 eine Bestellung eines Dienstes, etwa eines Kommunikationsdienstes, aufgibt (Schritt 1104). Das Verfahren wird fortgesetzt, indem der Objektgenerator 216 Informationen bezüglich der in den Kommunikationsdienst aufzunehmenden Standardfeatures nebst Standardregeln 828 empfängt, die bewirken, dass sich der Dienst gemäß den Standardfeatures verhält (Schritt 1108). In einigen Ausführungsformen umfassen die Standardfeatures möglicherweise einen Satz von Grundregeln und/oder einen Bereich von Regeln, die eine akzeptable oder inakzeptable Nutzung definieren. Des Weiteren definieren die Standardfeatures möglicherweise, welche Unterkomponenten für den Dienst zur Verfügung gestellt werden, es sei denn, es werden spezielle Unterkomponenten angefordert oder bestellt.
Der Objektgenerator 216 vergleicht daraufhin die Standardfeatures des Dienstes, wie in Schritt 1108 bestimmt, mit den vom Käufer bei Schritt 1104 definierten Features, um zu bestimmen, ob speziell für diese Bestellung ein angepasster Dienst generiert werden soll (Schritt 1112). In einigen Ausführungsformen definiert der Käufer möglicherweise keine speziellen Features für den Dienst, wobei zum Generieren des Objekts 604 in diesem Fall möglicherweise Standardfeatures und Standardregeln genutzt werden (Schritt 1120). In einigen Ausführungsformen definiert der Käufer möglicherweise einen oder mehrere angepasste Aspekte des Dienstes, die sich von den Standardfeatures des Dienstes unterscheiden, oder der Käufer definiert möglicherweise, dass bestimmte Nutzer/Nutzerinnen Standardfeatures des Dienstes empfangen sollen und andere Nutzer/Nutzerinnen angepasste Features empfangen sollen (Schritt 1116).
Wenn der gekaufte Dienst ein oder mehrere angepasste Features umfasst, kann der Objektgenerator 216 die notwendigen Unterkomponenten abrufen und die Unterkomponenten selbst, Bereitstellungsbefehle 612 für das Objekt 604, Anbieterregeln 804 und/oder Standardregeln 828 für den Dienst verändern. Nachdem die erforderlichen Features und Regeln ausgewählt worden sind, kann der Objektgenerator 216 das herunterladbare Objekt 604 gemäß den ausgewählten Features erstellen (Schritt 1124).
Nunmehr unter Bezugnahme auf 12 wird ein Verfahren zum Bereitstellen eines Dienstes während der Systemlaufzeit gemäß Ausführungsformen der vorliegenden Offenbarung beschrieben. Wenngleich das Verfahren im Zusammenhang mit einem Kommunikationsdienst beschrieben wird, sollte es sich verstehen, dass Ausführungsformen der vorliegenden Offenbarung nicht auf Kommunikationsdienste beschränkt sind und mit der Laufzeitbereitstellung eines Dienstes eines beliebigen Typs, etwa von webbasierten Diensten, Mediendiensten, Präsenzdiensten usw., gebraucht werden können.
Das Verfahren wird eingeleitet, wenn in den Käuferräumlichkeiten (z. B. an irgendeiner Komponente eines Netzes 304) ein neuer Dienst empfangen wird (Schritt 1204). Der Objektentpacker 328 und/oder der Objektverteiler 332 sind möglicherweise konfiguriert, um zu identifizieren, welche Entitäten (z. B. Nutzer/Nutzerinnen) innerhalb des Netzes 304 den Dienst empfangen sollen oder auf den Dienst zugreifen dürfen, sobald er installiert ist (Schritt 1208). Vor der Installation der verschiedenen Unterkomponenten des Dienstes bestimmt der Objektverteiler 332 möglicherweise weiter, ob irgendeine identifizierte Entität gegenwärtig eine ältere Version des Dienstes, die gerade empfangen worden ist, nutzt (Schritt 1212). Insbesondere kann, falls für einen Dienst ein Upgrade ausgeführt oder ein Dienst durch den neu heruntergeladenen Dienst ersetzt wurde, der Objektverteiler 332 bestimmen, ob irgendein identifizierter Nutzer/irgendeine identifizierte Nutzerin, der/die den Dienst empfangen soll, gegenwärtig eine ältere Version dieses Dienstes nutzt.
Falls die Abfrage von Schritt 1212 negativ beantwortet wird, wird bei dem Verfahren dazu übergegangen, dass der Objektverteiler 332 die Unterkomponenten des Objekts 604 normal verteilt, und jeder Server, der eine Unterkomponente empfängt, darf seine korrespondierende Unterkomponente sofort installieren und die installierte Unterkomponente für jeden Nutzer/jede Nutzerin auf Anforderung verfügbar machen (Schritt 1228).
Falls jedoch die Abfrage von Schritt 1212 negativ beantwortet wird, wird das Verfahren fortgesetzt, indem der Objektverteiler 332 die Unterkomponenten an die entsprechenden Server verteilt, wobei jedoch zusätzliche Mechanismen aufgerufen werden, um sicherzustellen, dass der/die Nutzer/Nutzerin(nen), die gegenwärtig die alte Version des Dienstes nutzen, nicht unterbrochen werden. Speziell kann der Objektverteiler 332 die verschiedenen Unterkomponenten des Objekts 604 an die Server verteilen und die Server können die neuen Unterkomponenten installieren. Gleichzeitig dürfen die Nutzer/Nutzerinnen, die gegenwärtig die alte Version des Dienstes nutzen, den Dienst so lange weiter nutzen, bis sie dessen Nutzung abgeschlossen haben (Schritt 1216). Dies kann auf etliche Arten erreicht werden. Zum Beispiel kann der Objektverteiler 332 dem Server, der die Unterkomponente empfängt, den Befehl geben, die Unterkomponente herunterzuladen und zu installieren, die Unterkomponente jedoch nur für neue Anforderungen des Dienstes zu nutzen (Schritt 1220). Mit anderen Worten, Anforderungen eines Dienstes, die empfangen worden waren, bevor der Server die Unterkomponente empfangen hat, können weiter von der alten Version des Dienstes (z. B. der alten Unterkomponente) verarbeitet werden.
Dies kann auch erreicht werden, indem der Dienstauswähler 320 darüber informiert wird, dass Nachrichten, die im Zusammenhang mit einer alten Kommunikationssitzung (z. B. einer vor dem Empfangen und dem Herunterladen des Objekts 604 aufgebauten Sitzung) empfangen wurden, weiter an die Server und die Unterkomponenten, die anfänglich für die Kommunikationssitzung aufgerufen wurden, geroutet werden sollen. Dem Dienstauswähler wird möglicherweise der Befehl gegeben, nur die neuen Unterkomponenten für Kommunikationssitzungen aufzurufen, die nach der Installation der Unterkomponenten für den neuen Dienst aufgebaut werden. Dadurch wird ermöglicht, dass der neue Dienst von Nutzern/Nutzerinnen genutzt wird, sobald diese die Nutzung des alten Dienstes beendet haben, selbst wenn während des Herunterladens und der Installation der Unterkomponenten des neuen Dienstes die alte Dienstversion genutzt wurde (Schritt 1224).
Ein konkreteres, wenn auch nicht beschränkendes Beispiel besteht darin, dass am Kommunikationsserver 316 ein neues Voicemail-System empfangen wird und dieses neue Voicemail-System ein älteres Voicemail-System ersetzen soll. Falls ein die Unterkomponenten für das neue Voicemail-System enthaltendes Objekt 604 empfangen wird, während ein erster Nutzer/eine erste Nutzerin gegenwärtig noch das alte Voicemail-System nutzt, kann der Objektverteiler 332 dennoch bewirken, dass die notwendigen Unterkomponenten an die korrespondierenden Server verteilt werden, wo sie installiert werden. Diese Verteilung und diese Installation erfolgen möglicherweise, während der erste Nutzer/die erste Nutzerin gegenwärtig das alte Voicemail-System nutzt. Ein zweiter Nutzer/eine zweite Nutzerin versucht möglicherweise, eine Verbindung zum Voicemail-System herzustellen, während der erste Nutzer/die erste Nutzerin nach wie vor das alte Voicemail-System nutzt, und der Dienstauswähler 320 verbindet den zweiten Nutzer/die zweite Nutzerin möglicherweise mit dem neuen Voicemail-System, selbst wenn der erste Nutzer/die erste Nutzerin nach wie vor das alte Voicemail-System nutzt. Dieses Routing erfolgt möglicherweise, weil der Dienstauswähler 320 auf die Nutzereinstellungen 324 und die Versionsdefinitionen, die in der Vorlage 700 vorgesehen sind, Bezug nimmt. Dies erfolgt möglicherweise auch für andere Nutzer/Nutzerinnen, die das alte Voicemail-System nicht genutzt haben, während das neue Voicemail-System installiert wurde. Sobald der erste Nutzer/die erste Nutzerin seine/ihre Sitzung mit dem alten Voicemail-System abgeschlossen hat, werden jegliche neuen Anforderungen zum Herstellen einer Verbindung zum Voicemail-System vom ersten Nutzer/von der ersten Nutzerin durch den Dienstauswähler 320 an die Unterkomponenten geroutet, die das neue Voicemail-System zur Verfügung stellen. Folglich wird der erste Nutzer/die erste Nutzerin während der Installation des neuen Voicemail-Systems nicht unterbrochen und andere Nutzer/Nutzerinnen können sofort auf das neue Voicemail-System zugreifen, sobald es installiert worden ist.
Ein weiteres beispielhaftes Szenario kann eintreten, in dem ein Nutzer/eine Nutzerin eine ältere Version eines Dienstes weiter nutzt, auch nachdem eine neuere Version desselben Dienstes installiert worden ist. Insbesondere kann der Nutzer/die Nutzerin, solange er/sie statt der neueren Version der älteren Version, die er/sie nutzen soll, zugewiesen ist, anstelle der neueren Version weiter die ältere Version nutzen.
Nunmehr unter Bezugnahme auf 13 wird ein Verfahren zum Ausführen eines Upgrades für einen Dienst gemäß Ausführungsformen der vorliegenden Offenbarung beschrieben. Das Verfahren beginnt, wenn in den Kundenräumlichkeiten ein neuer Dienst empfangen wird (Schritt 1304). Das Verfahren wird fortgesetzt, indem der Objektentpacker 328 und/oder der Objektverteiler 332 die Entitäten identifizieren, die den neuen Dienst empfangen sollen (Schritt 1308). Diese Informationen werden möglicherweise innerhalb des Objekts 604 (z. B. über die Bereitstellungsbefehle 612) definiert oder sie werden möglicherweise an irgendeinem anderen Ort (z. B. innerhalb der Systemverwalterunterkomponente 620) definiert. Der Objektverteiler 332 erstellt basierend auf den in Schritt 1308 bezogenen Informationen eine Vorlage 700 oder fügt einer bestehenden Vorlage 700 ein Feld hinzu, sodass die Vorlage 700 die Berechtigungen für den neuen Dienst unter verschiedenen Entitäten innerhalb des Netzes 304 definiert (Schritt 1312).
Nachdem die Vorlage 700 erstellt oder aktualisiert worden ist, bewirkt der Objektverteiler 332, dass der neue Dienst an die entsprechenden Server verteilt und darin installiert wird, damit der neue Dienst innerhalb des Netzes 304 verfügbar gemacht wird (Schritt 1316). Sobald er installiert wurde, ist der Dienstauswähler 320 fähig, die Regeln, die innerhalb der Vorlage 700 definiert sind, sowie Regeln, die innerhalb beliebiger anderer Datenstrukturen enthalten sind, welche Nutzerberechtigungen und dergleichen definieren, auf beliebige Anforderungen dieses Dienstes anzuwenden/zu erzwingen (Schritt 1320). Falls ein Nutzer/eine Nutzerin zum Beispiel versucht, einen ausgehenden Telefonanruf zu tätigen, nachdem der neue Dienst installiert worden ist, und der neue Dienst mit einem Dienst vom Anrufaufzeichnungstyp, einem Sprache-Text-Dienst, einem Gesprächsanalysedienst oder dergleichen korrespondiert, routet der Dienstauswähler 320 nach dem Empfangen der Nachricht, die den Anruf einleitet, die Nachricht möglicherweise durch eine oder mehrere Unterkomponenten 340, 360, 376, sodass die neue Version des Dienstes für den ausgehenden Anruf des Nutzers/der Nutzerin genutzt wird.
Im Verlauf der Zeit kann die Vorlage 700 aktualisiert werden, um dem neuen Dienst einen Nutzer/eine Nutzerin hinzuzufügen, einen Nutzer/eine Nutzerin aus dem neuen Dienst zu entfernen, dem neuen Dienst eine Gruppe hinzuzufügen, eine Gruppe aus dem neuen Dienst zu entfernen usw. Änderungen der Vorlage 700 können dadurch eingeleitet werden, dass ein Nutzer/eine Nutzerin mit der Systemverwalterunterkomponente 368, der Nutzerportalunterkomponente 360 oder einem beliebigen anderen Modul innerhalb des Netzes 304, welches das Ansehen und das Bearbeiten der Vorlage 700 ermöglicht, interagiert. Falls bestimmt wird, dass eine Änderung der Vorlage 700 erforderlich ist (Schritt 1324), geben die Systemverwalterunterkomponente 368 und/oder die Nutzerportalunterkomponente 360 dem Kommunikationsserver 316 möglicherweise den Befehl, die korrespondierenden Felder in der Vorlage 700 zu aktualisieren, falls die Vorlage 700 am Kommunikationsserver 316 beibehalten wird. In jedem Fall wird dem für die Verwaltung der Vorlage 700 zuständigen Server der Befehl gegeben, die Vorlage so zu aktualisieren, dass sie die Änderung widerspiegelt (Schritt 1328). Danach wird bei dem Verfahren zu Schritt 1324 zurückgekehrt.
In einigen Ausführungsformen kann, statt dass direkt zu Schritt 1324 zurückgekehrt wird, ein zusätzlicher Schritt des Entfernens/Deinstallierens durchgeführt werden. Speziell werden, nachdem jeder Nutzer/jede Nutzerin eines Kommunikationssystems von einer alten Dienstversion wegmigriert worden ist, möglicherweise die alte Dienstversion und alle assoziierten Unterkomponenten auf ihren korrespondierenden Servern deinstalliert.
In einigen Ausführungsformen wird während eines System-Upgrades möglicherweise für individuelle Komponenten ein Upgrade ausgeführt, statt dass für jede Komponente des Dienstes ein Upgrade ausgeführt wird. Insbesondere wird möglicherweise, falls der ursprüngliche Dienst eine erste Anrufverarbeitungskomponente, eine erste Nutzerportalkomponente und eine erste Lizenzierungskomponente (z. B. für 10 Nutzer/Nutzerinnen) aufweist, für den ursprünglichen Dienst ein Upgrade auf einen einem Upgrade unterzogenen Dienst ausgeführt, indem einfach eine oder mehrere Komponenten des ursprünglichen Dienstes aktualisiert werden. Falls ein Kunde zum Beispiel nur für den Lizenzteil seines Dienstes ein Upgrade ausführen will, ist eventuell nur notwendig, die Lizenzierungskomponente des Dienstes auf eine zweite Lizenzierungskomponente (z. B. für 20 Nutzer/Nutzerinnen) zu aktualisieren, ohne irgendeine andere Komponente des Dienstes aktualisieren zu müssen. Es sollte sich verstehen, dass abhängig davon, für welche Komponente des Dienstes ein Upgrade ausgeführt wird, die mit diesem Dienst assoziierten Kosten gegebenenfalls angeglichen werden müssen.
Nunmehr unter Bezugnahme auf 14 wird ein Verfahren zum hierarchischen Strukturieren von Attributen oder Regeln für einen Dienst gemäß Ausführungsformen der vorliegenden Offenbarung beschrieben. In einigen Ausführungsformen werden der Dienst und das den Dienst darstellende Objekt 604 mit einer ersten Ebene von Attributberechtigungen 804 erstellt und an einen Kunden übermittelt (Schritt 1404). Die erste Ebene von Attributberechtigungen 804 korrespondiert möglicherweise mit Anbieterregeln und es handelt sich dabei möglicherweise um Standardregeln oder einen Bereich von Regeln. In einigen Ausführungsformen definiert der Käufer möglicherweise während des Bestellvorgangs, dass in das Objekt 604 eine zweite Ebene von Attributberechtigungen 808 aufgenommen werden soll (Schritt 1408). Alternativ oder zusätzlich definiert der Käufer möglicherweise die zweite Ebene von Attributberechtigungen 808, nachdem das Objekt 604 am Netz 304 empfangen worden ist. Ungeachtet dessen, wann die zweite Ebene von Attributberechtigungen 808 definiert wird, wird die zweite Ebene von Attributberechtigungen 808 innerhalb der Datenstruktur 800 erzeugt, um die erste Ebene von Attributberechtigungen 804 weiter zu verfeinern oder zu beschränken.
Das Verfahren wird fortgesetzt, indem bestimmt wird, ob eventuell mehr Ebenen von Attributberechtigungen in die Datenstruktur 800 integriert werden, um die zweite Ebene von Attributberechtigungen 808 weiter zu beschränken (Schritt 1412). Falls diese Abfrage positiv beantwortet wird, wird für den Dienst eine nächste Ebene von Attributberechtigungen definiert (Schritt 1416). Die Schritte 1412 und 1416 können nach Bedarf so lange wiederholt werden, bis die gewünschte Anzahl von Hierarchieebenen erzeugt wurde. Sobald alle gewünschten Ebenen von Attributberechtigungen erzeugt wurden, wird das Verfahren mit der Konstruktion der Datenstruktur 800 fortgesetzt, die die Attribute basierend auf den definierten Ebenen hierarchisch ordnet (Schritt 1420). Somit definiert die erste Ebene von Attributberechtigungen die weitestgehenden Grenzen der Attributberechtigungen (z. B. als Bereich oder Liste zulässiger Attribute) und die niedrigeren Ebenen der Attributberechtigungen definieren weiter die Attribute oder Regeln innerhalb der Grenzen aller höheren Ebenen von Attributberechtigungen.
In der vorangehenden Beschreibung wurden Verfahren zu Zwecken der Veranschaulichung in einer konkreten Reihenfolge beschrieben. Es sollte sich verstehen, dass die Verfahren in alternativen Ausführungsformen auch in einer anderen als der beschriebenen Reihenfolge durchgeführt werden können. Es sollte sich auch verstehen, dass die oben beschriebenen Verfahren möglicherweise von Hardware-Komponenten durchgeführt werden oder in Sequenzen maschinenausführbarer Befehle ausgebildet sind, die genutzt werden können, um zu bewirken, dass eine Maschine wie ein Mehrzweck- oder ein Spezialprozessor (GPU oder CPU) oder Logikschaltungen, die mit den Befehlen programmiert werden, die Verfahren durchführen (FPGA). Diese maschinenausführbaren Befehle können auf einem oder mehreren maschinenlesbaren Medien gespeichert sein, etwa CD-ROMs oder optischen Speicherplatten von anderer Art, Disketten, ROMs, RAMs, EPROMs, EEPROMs, magnetischen oder optischen Speicherkarten, Flash-Speichern oder maschinenlesbaren Medien von anderer Art, die zum Speichern elektronischer Befehle geeignet sind. Alternativ können die Verfahren durch eine Kombination von Hard- und Software durchgeführt werden.
In der Beschreibung wurden spezielle Einzelheiten genannt, um ein eingehendes Verständnis der Ausführungsformen zu gewährleisten. Es versteht sich jedoch für den Durchschnittsfachmann, dass die Ausführungsformen auch ohne diese speziellen Einzelheiten praktisch umgesetzt werden können. Zum Beispiel werden Schaltungen eventuell in Blockschemata gezeigt, um die Verständlichkeit der Ausführungsformen nicht durch unnötige Einzelheiten zu beeinträchtigen. In anderen Fällen werden wohlbekannte Schaltungen, Vorgänge, Algorithmen, Strukturen und Techniken eventuell ohne unnötige Einzelheiten gezeigt, um die Verständlichkeit der Ausführungsformen nicht zu beeinträchtigen.
Auch wird darauf hingewiesen, dass die Ausführungsformen als Vorgang beschrieben wurden, der als Ablaufschema, Flussdiagramm, Datenflussdiagramm, Strukturdiagramm oder Blockdiagramm abgebildet wird. Selbst wenn ein Ablaufschema die Abläufe eventuell als sequenziellen Vorgang beschreibt, können viele der Abläufe auch parallel oder gleichzeitig durchgeführt werden. Zudem kann die Reihenfolge der Abläufe geändert werden. Ein Vorgang ist beendet, wenn dessen Abläufe abgeschlossen sind, könnte jedoch zusätzliche Schritte aufweisen, welche die Figur nicht beinhaltet. Ein Vorgang korrespondiert möglicherweise mit einer Methode, einer Funktion, einer Prozedur, einer Unterroutine, einem Unterprogramm usw. Wenn ein Vorgang mit einer Funktion korrespondiert, korrespondiert seine Beendigung mit einer Rückkehr der Funktion zur aufrufenden Funktion oder zur Hauptfunktion.
Ferner können Ausführungsformen durch Hardware, Software, Firmware, Middleware, Mikrocode, Hardware-Beschreibungssprachen oder eine beliebige Kombination davon implementiert werden. Wenn Programmcode oder -codesegmente zum Durchführen der notwendigen Aufgaben in Software, Firmware, Middleware oder Mikrocode implementiert sind, können sie in einem maschinenlesbaren Medium, etwa einem Speichermedium, gespeichert werden. Ein Prozessor/Prozessoren kann/können die notwendigen Aufgaben durchführen. Ein Codesegment kann eine Prozedur, eine Funktion, ein Unterprogramm, ein Programm, eine Routine, eine Unterroutine, ein Modul, ein Software-Paket, eine Klasse oder eine beliebige Kombination von Befehlen, Datenstrukturen oder Programmanweisungen darstellen. Ein Codesegment kann durch Weitergeben und/oder Empfangen von Informationen, Daten, Argumenten, Parametern oder Arbeitsspeicherinhalten an ein anderes Codesegment oder eine Hardwareschaltung gekoppelt sein. Informationen, Argumente, Parameter, Daten usw. können über ein beliebiges geeignetes Mittel, einschließlich Memory Sharing, Nachrichtenweitergabe, Tokenweitergabe, Netzübertragung usw., weitergegeben, weitergeleitet oder übertragen werden.
Wenngleich Ausführungsbeispiele der Offenbarung hierin ausführlich beschrieben wurden, sollte es sich verstehen, dass die Erfindungsgedanken ansonsten auch anders ausgebildet und gebraucht werden können und dass die beigefügten Ansprüche so auszulegen sind, dass sie solche Variationen ebenfalls beinhalten, es sei denn, sie werden durch den Stand der Technik begrenzt.

Claims

Verfahren, das Folgendes umfasst: Empfangen einer Anforderung von einem Kunden zum Beziehen eines herunterladbaren einfügbaren Dienstes für ein Kommunikationssystem des Kunden; als Reaktion auf Empfangen der Anforderung Vorbereiten des herunterladbaren einfügbaren Dienstes, wobei Vorbereiten des herunterladbaren einfügbaren Dienstes Beziehen einer ersten und einer zweiten Unterkomponente beinhaltet, die in ein einzelnes Objekt eingepackt werden, wobei die erste Unterkomponente Befehle zum Betreiben eines ersten Servers des Kommunikationssystems des Kunden beinhaltet und wobei die zweite Unterkomponente Befehle zum Betreiben eines zweiten Servers des Kommunikationssystems des Kunden beinhaltet; und Übertragen des einzelnen Objekts an den Kunden.
Verfahren nach Anspruch 1, wobei der herunterladbare einfügbare Dienst weiter Bereitstellungsbefehle beinhaltet, die Befehle zum Installieren der ersten und der zweiten Unterkomponente auf dem ersten bzw. dem zweiten Server des Kommunikationssystems des Kunden zur Verfügung stellen.
Verfahren nach Anspruch 1, wobei Vorbereiten des herunterladbaren einfügbaren Dienstes weiter Vorbereiten einer Lizenz umfasst, die eine entsprechende Nutzung des herunterladbaren einfügbaren Dienstes am Kommunikationssystem des Kunden identifiziert, wobei die Lizenz angibt, dass ein erster Nutzer/eine erste Nutzerin des Kommunikationssystems des Kunden den herunterladbaren einfügbaren Dienst nutzen darf, und wobei die Lizenz nicht angibt, dass ein zweiter Nutzer/eine zweite Nutzerin des Kommunikationssystems des Kunden den herunterladbaren einfügbaren Dienst nutzen darf, wobei die Lizenz in einer Lizenzdatei beinhaltet ist, die in den herunterladbaren einfügbaren Dienst als eine Datei im einzelnen Objekt eingepackt wird.
Verfahren nach Anspruch 1, wobei die erste und die zweite Unterkomponente aus einem Dienstlager abgerufen werden, wobei das Dienstlager ermöglicht, dass der Kunde mehrere herunterladbare einfügbare Dienste und potenzielle Unterkomponenten davon durchsucht.
Verfahren nach Anspruch 1, wobei der erste Server mit einem Anwendungsserver korrespondiert und wobei der zweite Server mit einem Nutzerportalserver und/oder einem Systemverwalterserver korrespondiert, wobei der erste und der zweite Server je einen Anwendungscontainer und/oder einen Appletcontainer und/oder einen Webcontainer und/oder eine Anwendungsprogrammierschnittstelle (API) umfassen.
Verfahren nach Anspruch 1, wobei die erste Unterkomponente und die zweite Unterkomponente in das einzelne Objekt als eine EAR-Datei und/oder eine WAR-Datei eingepackt werden.
Verfahren nach Anspruch 1, wobei der herunterladbare einfügbare Dienst weiter Bereitstellungsbefehle in Form einer ausführbaren Datei und/oder einer EAR-Datei und/oder einer WAR-Datei beinhaltet, wobei die Bereitstellungsbefehle, wenn sie von einem Objektverteiler ausgeführt werden, bewirken, dass die erste Unterkomponente für den ersten Server bereitgestellt wird, wo sie installiert wird, und wobei die Bereitstellungsbefehle, wenn sie vom Objektverteiler ausgeführt werden, bewirken, dass die zweite Unterkomponente für den zweiten Server bereitgestellt wird, wo sie installiert wird.
Nicht transientes computerlesbares Medium, das vom Prozessor ausführbare Befehle umfasst, wobei die Befehle Folgendes umfassen: einen Objektgenerator, der konfiguriert ist, um eine Anforderung von einem Kunden zum Beziehen eines herunterladbaren einfügbaren Dienstes für ein Kommunikationssystem des Kunden zu empfangen und als Reaktion auf Empfangen der Anforderung den herunterladbaren einfügbaren Dienst vorzubereiten, wobei Vorbereiten des herunterladbaren einfügbaren Dienstes Beziehen einer ersten und einer zweiten Unterkomponente beinhaltet, die in ein einzelnes Objekt eingepackt werden, wobei die erste Unterkomponente Befehle zum Betreiben eines ersten Servers des Kommunikationssystems des Kunden beinhaltet, sodass der herunterladbare einfügbare Dienst durchgeführt wird, und wobei die zweite Unterkomponente Befehle zum Betreiben eines zweiten Servers des Kommunikationssystems des Kunden beinhaltet, sodass der herunterladbare einfügbare Dienst durchgeführt wird; und eine Objektübermittlungsschnittstelle, die konfiguriert ist, um das einzelne Objekt über ein Kommunikationsnetz an den Kunden zu übertragen.
Kommunikationssystem, das Folgendes umfasst: einen Kommunikationsserver, der einen Prozessor und einen Arbeitsspeicher beinhaltet, wobei der Arbeitsspeicher Befehle beinhaltet, die konfiguriert sind, um vom Prozessor ausgeführt zu werden, wobei die Befehle Folgendes beinhalten: einen Objektentpacker, der konfiguriert ist, um ein einzelnes Objekt von einem Dienstlager zu empfangen, wobei das einzelne Objekt mehrere Unterkomponenten umfasst, die, wenn sie unter Servern im Kommunikationssystem verteilt werden, bewirken, dass das Kommunikationssystem Nutzern/Nutzerinnen des Kommunikationssystems einen Dienst zur Verfügung stellt, wobei die mehreren Unterkomponenten eine erste und eine zweite Unterkomponente beinhalten, die in das einzelne Objekt eingepackt werden; und einen Objektverteiler, der konfiguriert ist, um die erste Unterkomponente und die zweite Unterkomponente gemäß im einzelnen Objekt enthaltenen Bereitstellungsbefehlen an unterschiedliche Server im Kommunikationssystem zu verteilen.
Verfahren nach Anspruch 9, wobei die erste Unterkomponente und die zweite Unterkomponente in das einzelne Objekt als eine EAR-Datei und/oder eine WAR-Datei eingepackt werden.