DE60221118T2

DE60221118T2 - Dienst applikationsarchitektur für dienstenanbieter von integrierende kommunikationsnetzwerken

Info

Publication number: DE60221118T2
Application number: DE60221118T
Authority: DE
Inventors: Thomas Boca Raton CREAMER; Samuel Kallner; Zygmunt Anthony Papworth Everard LOZINSKI; Victor Boynton Beach MOORE; Gal Shachor; Pnina Vortman; Glen Hollywood WALTERS
Original assignee: International Business Machines Corp
Current assignee: International Business Machines Corp
Priority date: 2001-05-24
Filing date: 2002-05-14
Publication date: 2008-03-20
Anticipated expiration: 2022-05-15
Also published as: WO2002098097A3; AU2002302741A1; JP2004537886A; EP1389395A2; KR20040000439A; EP1389395B1; CN100586203C; ATE367059T1; JP3924279B2; KR100602318B1; CN1537392A; DE60221118D1; WO2002098097A2

Description

GEBIET DER ERFINDUNG
Die Erfindung betrifft das Gebiet moderner intelligenter Netzwerke und insbesondere eine Dienstverarbeitungsarchitektur für Dienstanbieter in integrierten Netzen.
HINTERGRUND DER ERFINDUNG
Die Entwicklung der Schnittstelle für die Programmierung von Anwendungsprogrammen (API) in offenen Netzen markiert einen wichtigen Schritt des Übergangs von herkömmlichen Verfahren zur Öffnung der Architektur des öffentlichen Telefonnetzes. Eine solche API für offene Netze, die API für moderne intelligente Netzwerke (AIN) und die entsprechende Architektur, definiert ein Anrufmodell, mit dessen Hilfe Telekommunikations-Dienstanwendungen außerhalb der Vermittlungsumgebung geschaffen werden können. Telekommunikations-Dienstanwendungen sind speziell zugeschnittene Telekommunikationsanwendungen, die für eine zwischen zwei oder mehr Teilnehmern eingerichtete Telefonsitzung Zusatzdienste bereitstellen können. Als beispielhafte Dienstanwendungen können Warteschleife, Anruferkennung, Anrufweiterleitung, sprachgesteuertes Wählen und Konferenzschaltung infrage kommen.
Zum Zeitpunkt ihrer Einführung stellten die AIN für den Prozess der Schaffung von Dienstanwendungen einen bedeutenden Fortschritt dar. Durch die AIN wurde die Entwicklung der Dienste von der Vermittlung getrennt, sodass Logikkomponenten für die Dienste schnell entwickelt und in speziellen, an Datenbanken angeschlossenen Netzwerkelementen untergebracht werden konnten. Die Vermittlungsrechner wiederum waren von der gesamten Logik für die Dienste befreit und konnten auf Geschwindigkeit und Wirkungsgrad optimiert werden. Typische entsprechend den AIN-Regeln entwickelte Dienstanwendungen werden auch heute noch in speziellen Sprachen von speziell ausgebildeten Programmierern geschrieben, die sich spezieller Entwicklungsumgebungen für Dienste bedienen.
Wichtig ist, dass sich zukünftige Fernsprechnetze durch neue und sich entwickelnde Netzarchitekturen auszeichnen, in denen paketvermittelte, leitungsvermittelte und drahtlose Netze integriert werden, um den Teilnehmern eine Vielzahl neuartiger Multimediaanwendungen für viele Teilnehmer anzubieten. Desgleichen muss davon ausgegangen werden, dass sich der Prozess der Entwicklung von Telekommunikationsanwendungen verändern wird und nicht mehr dem Betreiber des Telefonnetzes oder dem Anbieter von Dienstanwendungen obliegt. Um ein breites Angebot neuartiger und attraktiver Anwendungen schnell anbieten zu können, sind die Anbieter von Dienstanwendungen tatsächlich immer mehr auf außenstehende Anwendungsentwickler und Softwareanbieter angewiesen. Somit nähert sich die Entwicklung von Anwendungen im Telekommunikationsbereich im Allgemeinen immer mehr der Entwicklung von Software und Informationstechnologie an, wobei die Kunden vom schärferen Wettbewerb, von der verkürzten Markteinführungszeit und der beschleunigten Einführung neuer Technologien profitieren.
Zur praktischen Umsetzung dieser Zielstellung sind die AIN-Prinzipien zugunsten einer neuen Entwicklungsstrategie für Komponenten von Dienstanwendungen aufgegeben worden. Insbesondere wurde erkannt, dass zukünftige integrierte Netze den Entwicklern einen Satz von offenen Standard-APIs zur Verfügung stellen müssen, damit die kompatibel für das System eines Anbieters geschriebenen Anwendungen im System eines anderen Anbieters laufen können. Dadurch lassen sich die Kosten für Entwicklung der Anwendungen und somit die Endkosten für den Kunden senken. Java-APIs für integrierte Netze (JAIN) erfüllen die Anforderungen der neuen Entwicklungsstrategie für Komponenten von Dienstanwendungen. Gegenwärtig beinhaltet JAIN veröffentlichte offene Standard-Java-APIs für Systeme der nächsten Generation, die aus integrierten Netzen nach dem Internetprotokoll (IP) oder nach dem asynchronen Transportmodus (ATM), aus dem Festnetz und drahtlosen Netzen bestehen. Die JAIN-APIs beinhalten Schnittstellen auf Protokollebene für unterschiedliche Protokolle wie das Media Gateway Control Protocol (MGCP), das Session Initiation Protocol (SIP) und Transactional Capabilities Application Part (TCAP) sowie Protokolle in den höheren Schichten des Telekommunikations-Protokollstapels.
JAIN beinhaltet einen Satz APIs für integrierte Netze für die Java-Plattform und eine Umgebung zum Erstellen und Integrieren von JAIN-Komponenten in Dienste oder Anwendungen, die gleichermaßen in öffentlichen, paketvermittelten und drahtlosen Netzen funktionieren. Der JAIN-Lösungsansatz integriert leitungsgebundene, drahtlose und paketvermittelte Netze, indem er die Logik für die Dienstanwendungen von der Netzwerklogik trennt. 1 veranschaulicht eine herkömmliche JAIN-Ausführungsart. 1 zeigt, dass eine herkömmliche JAIN-Ausführungsart eine Protokollschicht 102 beinhalten kann, die Schnittstellen zu IP-, leitungsgebundenen und drahtlosen Signalisierungsprotokollen beinhalten kann. Obwohl unter der Bezugsnummer 110 nur die Protokolle TCAP, JCC und H.323 gezeigt werden, sind die durch die JAIN-Regeln unterstützten Protokolle nicht auf bestimmte Protokolle beschränkt und können zum Beispiel TCAP, ISUP, INAP, MAP, SIP, MGCP und H.323 beinhalten. Außerdem kann die JAIN-Ausführungsart eine Schnittstelle zu einem Konnektivitätsverwaltungs- und Anrufsteuerungsprotokoll wie beispielsweise JCC beinhalten.
Außer der Protokollschicht 102 kann die herkömmliche JAIN-Ausführungsart auch eine Verarbeitungsschicht 104 zur Verarbeitung des sicheren Netzwerkzugriffs und anderer externer Dienste 120 beinhalten. Ferner kann eine herkömmliche JAIN-Ausführungsart eine Dienstlogikschicht 106 beinhalten, die eine Logikumgebung zur Schaffung und Ausführung von Diensten von Netzbetreibern (SLEE) 108 beinhalten kann. Die Dienstkomponenten 112 stellen die JAIN-Hauptkomponenten dar und können in der SLEE 108 ausgeführt werden. Speziell können die Dienstkomponenten 112 Fernsprech- und Netzdienstleistungen realisieren und gemäß einem Standardkomponentenmodell aufgebaut sein. Instanzen von Dienstkomponentenpaketen werden in Verbindung mit der SLEE 108 ausgeführt.
Während des Betriebs können Dienstkomponenten 112 unter Verwendung von Informationen über die Protokollschicht 102, die in die SLEE 108 integriert werden können, mit einem zugrunde liegenden Protokollstapel 110 kooperieren, ohne über spezielle Kenntnisse vom Protokollstapel 110 zu verfügen. Noch wichtiger ist, das die SLEE 108 den Dienstkomponenten 112 übliche Lebenszyklusaufgaben wie beispielsweise mobile Unterstützung von Transaktionen, Datenbankzugriffe, Lastausgleich, Sicherheit und Zusammenfassung von Objekten und Verbindungsinstanzen abnehmen kann. Auf diese Weise können sich die Dienstkomponenten 112 voll auf die Bereitstellung von Fernsprech- und/oder Netzdiensten konzentrieren. Insbesondere kann die SLEE 110 für den Datenaustausch direkt mit Client-Komponenten wie externen Anwendungen 116, Protokollstapeln 110 und Dienstkomponenten 112 verbunden werden.
Zum Beispiel können Dienstkomponenten 112, die in der Dienstlogikschicht 106 der SLEE 108 laufen, über Protokolladapter in der SLEE 108 Daten mit den Protokollstapeln 110 in der Protokollschicht austauschen. Die Protokolladapter können üblicherweise Klassenmethoden, Rückrufe, Kapselungsschnittstellen oder Ereignisroutinen beinhalten. In vielen Fällen kann ein zugrunde liegender Protokollstapel 110 Daten direkt mit der SLEE 108 durch eine Ereignistabelle 114 in der SLEE 108 austauschen, die so konfiguriert ist, dass sie speziell dem zugrunde liegenden Protokollstapel 110 zugewiesene Ereignisse verarbeitet. Demzufolge kann die SLEE 108 diese bestimmten Ereignisse erkennen und nach dem Empfangen eines solchen Ereignisses vom zugrunde liegenden Protokollstapel 110 dieses Ereignis an eine Dienstkomponente 112 für den Teilnehmer weiterleiten. Ferner kann die Dienstkomponente 112 fallbezogen so programmiert werden, dass sie mit speziellen externen Diensten 120 kooperiert, zum Beispiel mit relationalen Datenbanken, Verzeichnisdiensten usw.
Trotz der deutlichen Vorteile der JAIN-Regeln beinhalten herkömmliche Ausführungsart der JAIN-Regeln noch einige Nachteile, insbesondere bezüglich ihrer Anwendung auf Ferngespräche in Echtzeit. Erstens beinhaltet die SLEE von herkömmlichen JAIN-Ausführungsarten einen Enterprise Javabean^®-Ansatz (EJB), der überflüssige Routineaufgaben, zum Beispiel Lebenszykluszuständigkeiten, enthält. Lebenszykluszuständigkeiten sind bei Echtzeitgesprächen jedoch nicht so kritisch wie bei anderen Datenübertragungen. Somit werden durch die Verwendung von EJBs möglicherweise zu viele Latenzen eingeführt, um die Anforderungen an den Echtzeitbetrieb zu erfüllen. Um die Dienstkomponenten von den Komplexitäten der Protokollstapel zu entlasten, muss die SLEE spezielle Kenntnis von den zugrunde liegenden Protokollstapeln haben, die sie aus den entsprechenden Ereignistabellen gewinnen kann, die zur Durchführung von Datenübertragungen zwischen der SLEE und einem zugrunde liegenden Protokollstapel genutzt werden können. Durch die Einbeziehung spezieller Informationen über die Client-Komponenten kann die SLEE jedoch unnötig mit Komplexität belastet werden. Aus der Sicht der Erhaltung des Lebenszyklus kann dies problematisch sein. Ferner wird die SLEE durch die Einbeziehung von Informationen über die Client-Komponente unnötig direkt auf bestimmte Client-Komponenten ausgerichtet. Und schließlich kann es bei einer direkten Ausrichtung der SLEE auf bestimmte Client-Komponenten erforderlich werden, die Verarbeitungsschicht, die Protokollschicht und die Dienstlogikschicht datenverarbeitungsmäßig nahe beieinander anzuordnen.
Der Datenaustausch mit einer Dienstkomponente in der SLEE kann auch für externe Anwendungen problematisch sein. Insbesondere muss eine externe Anwendung programmtechnisch auf diejenigen Dienstkomponenten in der SLEE ausgerichtet sein, mit denen die externe Anwendung Daten austauschen kann. Dieses Problem kann sich noch verschlimmern, wenn die externe Anwendung auf ein Computernetz wie das Internet verteilt ist. Demzufolge muss jeder Versuch zur Integration von Diensten oder anderen über das Internet einschließlich des World Wide Web verfügbaren Funktionalitäten unter Verwendung eines separaten, anbieterspezifischen Systems realisiert werden.
Gemäß der JAIN-Spezifikation erfordert insbesondere die Entwicklung einer drahtlosen Dienstanwendung die Kenntnis über viele verschiedene Datenübertragungsschnittstellen und -protokolle zum Zugreifen auf Funkdienste. Zum Beispiel gibt es zur Zeit eine Vielzahl verschiedener Datenübertragungsprotokolle, die die Nutzung des Funknetzes unterstützen. Zu diesen Protokollen können das globale System für mobile Kommunikation (Global System for Mobile Communication, GSM), der allgemeine paketvermittelte Funkdienst (General Packet Radio System, GPRS), die erhöhte Datenrate für GSM-Umgebung (Enhanced Data Rate Environment, EDGE), das Universalsystem für mobile Telekommunikation (Universal Mobile Telecommunications System, UMTS), das Protokoll für drahtlose Anwendungen (Wireless Application Protocol, WAP), das Protokoll für mobilen Zugriff (Mobile Access Protocol, MAP) und der Modus i-Mode zählen.
Um eine drahtlose Dienstanwendung entwickeln zu können, muss ein Entwickler mit der betreffenden drahtlosen Protokollschnittstelle für den jeweiligen drahtlosen Dienst oder die Funktion vertraut sein, die in die zu entwickelnde drahtlose Dienstanwendung integriert werden soll. Zum Beispiel liefert WAP einen Standard für eine Reihe von Datenübertragungsprotokollen, der die drahtlose Datenübertragung zwischen mobilen Geräten standardisiert.
Somit muss ein Entwickler von drahtlosen Diensten für mobile Geräte zumindest mit WAP im Großen und Ganzen vertraut sein, um eine solche Dienstanwendung erfolgreich entwickeln zu können.
Desgleichen müsste ein Entwickler von Dienstanwendungen, der eine Dienstanwendung für die interaktive Nutzung einer Website unter Verwendung eines drahtlosen tragbaren Gerätes erstellen will, mit GPRS vertraut sein, das eine höhere Datenrate als WAP ermöglicht. Lösungen wie GPRS und WAP können das Zusammenwirken verschiedener Endgeräte und Dienste erleichtern und die Verwendung anbieterspezifischer Lösungen verringern. Zur Entwicklung einer Vielzahl drahtloser Dienstanwendungen muss ein Entwickler darüber hinaus auch mit einer Vielzahl verschiedener drahtloser Protokolle und Schnittstellen vertraut sein. Demzufolge kann die Anzahl der Personen mit der erforderlichen Sachkenntnis im Umgang mit verschiedenen drahtlosen Datenübertragungsprotokollen und -schnittstellen begrenzt werden.
Vergleichbar mit den Schwierigkeiten bei der Entwicklung von drahtlosen Dienstanwendungen erfordert auch die Entwicklung von Dienstanwendungen für den Fernsprechverkehr die Kenntnis vieler unterschiedlicher Datenübertragungsschnittstellen und -protokolle für den Zugriff auf Dienstanwendungen und -funktionen. Zum Beispiel kann für Dienstanwendungen wie Anrufsperre oder Anrufweiterleitung zusätzlich zu Dienstkomponenten für den Zugriff auf das Anrufmodell der Zugriff auf Verzeichnisdienste oder andere anbieterspezifische Datenbanken erforderlich sein, um auf Informationen zum Realisieren des Anrufmodells zuzugreifen. Für den Zugriff auf Verzeichnisdienste kann jedoch eine spezielle Kenntnis des vereinfachten Verzeichniszugriffsprotokolls (Lightweight Directory Access Protocol, LDAP) erforderlich sein. Vergleichsweise kann für den Zugriff auf eine bestimmte Datenbank die Kenntnis von DB2, MQSeries oder einem anderen anbieterspezifischen Protokolls für den Datenbankzugriff erforderlich sein.
Üblicherweise können die für die Entwicklung einer drahtlosen Anwendung unter Verwendung eines bestimmten Protokolls erforderlichen Kenntnisse so speziell sein, dass in einem Unternehmen möglicherweise nur eine Person über das nötige Fachwissen verfügt. Dieses Personalproblem führt oft dazu, dass jedes Mal, wenn eine Lösung für ein bestimmtes Format der drahtlosen Datenübertragung entwickelt wird, diese Lösung nicht einfach auf ein anderes drahtloses Format oder Protokoll übertragen werden kann.
Da das Wissen des Programmierers so hochspezialisiert sein kann, erfordert das Übertragen einer Dienstanwendung auf ein anderes Format oder Protokoll darüber hinaus normalerweise zusätzliches Personal mit dem entsprechenden Fachwissen über das Zielformat oder -protokoll.
Somit kann sich die hohe Spezialisierung bei der Entwicklung von Dienstanwendungen für den Fernsprechverkehr in höheren Entwicklungsausgaben und längeren Entwicklungszyklen niederschlagen. Ferner werden die Umstellung und Wartung von Systemen, Merkmalen und Anwendungen durch die damit verbundenen Komplexitäten stark erschwert.
Da das für den Zugriff auf eine bestimmte Dienstfunktionalität erforderliche Protokoll und die entsprechende Logik in der zu entwickelnden Dienstanwendung enthalten sind, können zum Beispiel Änderungen an einem zugrunde liegenden Protokoll die Neuprogrammierung der gesamten Dienstanwendung erforderlich machen. Kurz gesagt, der hohe Spezialisierungsgrad kann bei der Entwicklung von Dienstanwendungen für drahtlose Datenübertragung zu höheren Entwicklungsausgaben und längeren Entwicklungszeiten führen. Ferner können durch die damit verbundenen Komplexitäten die Umstellung von Systemen, Merkmalen und Anwendungen stark erschwert werden. Somit wird eine flexiblere Architektur für Dienstanwendungen für Dienstanbieter in integrierten Netzen benötigt.
In WO 01/28 186 A von Broadsoft Inc. wird ein System zum Bereitstellen von Diensten beschrieben, das Diensteinheiten, Schnittstelleinheiten und einen Dienstbus beinhaltet. Der Dienstbus verbindet die Schnittstelleneinheiten und die Diensteinheiten und überträgt Ereignisse zwischen den Schnittstelleneinheiten und den Diensteinheiten.
ZUSAMMENFASSUNG DER ERFINDUNG
Gemäß einem ersten Aspekt stellt die vorliegende Erfindung eine Umgebung zur Ausführung von Anwendungen gemäß Anspruch 1 bereit.
Vorzugsweise umfasst die Umgebung zur Ausführung von Anwendungen ferner mindestens eine universelle Dienstkomponente, die in der SLEE ausgeführt wird. Die universelle Dienstkomponente kann so konfiguriert sein, dass sie Daten mit anderen Dienstkomponenten in der SLEE austauscht. Die universelle Dienstkomponente kann auch so konfiguriert sein, dass sie Daten mit speziellen externen Diensten in der Verarbeitungsschicht austauscht.
Vorzugsweise umfasst die Umgebung zur Ausführung von Anwendungen ferner mindestens eine Fernsprechkomponente, die in der SLEE ausgeführt wird, wobei die Fernsprechkomponente so konfiguriert ist, dass sie über den Ereignis-Routing-Bus in der SLEE Daten mit Client-Komponenten in der Protokollschicht und mit anderen Dienstkomponenten in der Dienstlogikschicht austauscht.
Vorzugsweise umfasst die Verbindungs-/Oberflächenschnittstelle eine Client-Komponenten-Oberfläche, die eine abstrahierte Schnittstelle für eine Client-Komponente in der Protokollschicht bereitstellt, und ein der SLEE zugewiesenes Verbindungselement, das der Client-Komponenten-Oberfläche entspricht, wobei das Verbindungselement so konfiguriert ist, dass es über die durch die Client-Komponenten-Oberfläche bereitgestellte abstrahierte Schnittstelle Daten mit der Client-Komponente austauscht.
Vorzugsweise umfasst die Umgebung zur Ausführung von Anwendungen ferner einen SLEE-Deskriptor, wobei der SLEE-Deskriptor mindestens eine Client-Komponente bezeichnet, mit welcher die SLEE so konfiguriert werden kann, dass sie Daten über eine Verbindungs-/Oberflächenschnittstelle austauscht.
Vorzugsweise umfasst die Umgebung zur Ausführung von Anwendungen ferner mindestens einen Client-Komponenten-Deskriptor, wobei jeder Client-Komponenten-Deskriptor einer bestimmten Client-Komponente in der Protokollschicht entspricht und der mindestens eine Client-Komponenten- Deskriptor bestimmte Ereignisse bezeichnet, über welche die bestimmte Clientkomponente durch den Ereignis-Routing-Bus in der SLEE in Kenntnis gesetzt werden kann.
Vorzugsweise dient als Client-Komponente ein Protokollstapel. Alternativ kann als Client-Komponente eine Anrufsteuerungskomponente, eine Signalisierungs-Protokollkomponente, eine Verbindungsverwaltungs-Protokollkomponente oder eine Protokollkomponente für den sicheren Netzzugriff dienen.
Vorzugsweise ist die SLEE mit dem JAIN-Konzept kompatibel.
Vorzugsweise umfasst die SLEE ferner ein Klassenladeprogramm zum Laden von Dienstkomponenten in die SLEE, wobei die SLEE jede geladene Dienstkomponente registriert, damit diese an bestimmte registrierte Dienstkomponenten gerichtete Ereignisse empfangen können, wobei der Ereignis-Routing-Bus die empfangenen Ereignisse an die in der SLEE ausgeführten bestimmten registrierten Dienstkomponenten weiterleitet.
Vorzugsweise umfasst die SLEE ferner einen Vorrat an ausführbaren Programmsegmenten und eine Einheit zur Verwaltung des Vorrats an ausführbaren Programmsegmenten zum Zuweisen ausführbarer Protokollsegmente durch die geladenen Dienstkomponenten.
Gemäß einem zweiten Aspekt stellt die vorliegende Erfindung ein Verfahren zur Bereitstellung von Fernsprechdiensten gemäß Anspruch 12 bereit.
Gemäß einem dritten Aspekt stellt die Erfindung einen maschinenlesbaren Speicher bereit, in welchem ein Computerprogramm zum Bereitstellen von Fernsprechdiensten gespeichert ist, wobei das Computerprogramm einen durch eine Maschine ausführbaren Programmcode aufweist, der die Maschine zum Ausführen eines Verfahrens gemäß dem zweiten Aspekt veranlasst.
Gemäß einem vierten Aspekt stellt die vorliegende Erfindung eine Logikumgebung zur Ausführung von Diensten (SLEE) in einem intelligenten Netzmodell bereit, wobei die SLEE Folgendes umfasst: ein Klassenladeprogramm zum Laden von Dienstkomponenten in die SLEE, wobei die SLEE jede geladene Dienstkomponente registriert, damit diese an bestimmte registrierte Dienstkomponenten gerichtete Ereignisse empfangen können, und einen Ereignis-Routing-Bus zum Empfangen von Ereignissen von einer Protokollschicht und anderen Dienstkomponenten, wobei der Ereignis-Routing-Bus die empfangenen Ereignisse an die in der SLEE ausgeführten bestimmten registrierten Dienstkomponenten weiterleitet.
Gemäß einem fünften Aspekt stellt die vorliegende Erfindung eine Umgebung zur Ausführung von Anwendungen für ein intelligentes Netzwerk bereit, wobei die Umgebung Folgendes umfasst: eine Logikumgebung zur Ausführung von Diensten (SLEE) mit mindestens einer Client-Komponenten-Oberflache, wobei die mindestens eine Client-Komponenten-Oberfläche eine abstrahierte Schnittstelle für eine bestimmte Client-Komponente bereitstellt, und mindestens ein der SLEE zugeordnetes Verbindungselement, wobei das mindestens eine Verbindungselement der mindestens einen Client-Komponenten-Oberfläche entspricht und so konfiguriert ist, dass es über die abstrahierte Schnittstelle, die durch die entsprechende mindestens eine Client-Komponenten-Oberfläche bereitgestellt wird, Daten mit der Client-Komponente austauscht.
Gemäß einem sechsten Aspekt stellt die vorliegende Erfindung ein verbessertes intelligentes Netzwerk zur Verwendung mit einem drahtlosen Dienst bereit, wobei das intelligente Netzwerk Folgendes umfasst: eine Logikumgebung zur Ausführung von Diensten (SLEE), mindestens eine in der SLEE ausgeführte Dienstanwendung und mindestens eine universelle Dienstkomponente zur Verwendung mit einer drahtlosen Dienstanwendung, die über ein Verbindungselement Daten mit der Dienstanwendung austauscht, wobei die universelle Dienstkomponente eine Schnittstelle zu der außerhalb der SLEE befindlichen drahtlosen Dienstanwendung umfasst.
Gemäß einem siebenten Aspekt stellt die vorliegende Erfindung ein verbessertes intelligentes Netzwerk zur Verwendung mit einem Anrufmodell bereit, wobei das intelligente Netzwerk Folgendes umfasst: eine Logikumgebung zur Ausführung von Diensten (SLEE), mindestens eine in der SLEE ausgeführte Dienstanwendung und mindestens eine universelle Dienstkomponente, die über ein Verbindungselement Daten mit der Dienstanwendung austauscht, wobei die universelle Dienstkomponente eine Schnittstelle zu einer außerhalb der SLEE befindlichen zweiten Dienstanwendung umfasst.
Gemäß einem achten Aspekt stellt die vorliegende Erfindung ein Datenverarbeitungssystem für ein intelligentes Netzwerk bereit, wobei das Datenverarbeitungssystem Folgendes umfasst: eine Dienstlogikschicht, die eine Logikumgebung zur Ausführung von Diensten (SLEE) umfasst, eine Protokollschicht, die mindestens eine Dienstkomponente umfasst, wobei die mindestens eine Dienstkomponente über eine Verbindungs-/Oberflächenschnittstelle Daten mit der SLEE austauscht und wobei die SLEE einen Ereignis-Routing-Bus zum Weiterleiten von Ereignissen zwischen Dienstkomponenten in der Dienstlogikschicht und Dienstkomponenten in einer Protokollschicht und einer Verarbeitungsschicht umfasst, und mindestens eine in der SLEE ausgeführte Fernsprech-Dienstkomponente, die so konfiguriert ist, dass sie über den Ereignis-Routing-Bus in der SLEE Daten mit Client-Komponenten in der Protokollschicht und anderen Dienstkomponenten in der Dienstlogikschicht austauscht.
Somit stellt die vorliegende Erfindung eine flexible Architektur zur Ausführung von Dienstanwendungen für Dienstanbietern in integrierten Netzen bereit. Die vorliegende Erfindung behebt die Unzulänglichkeiten nach dem Stand der Technik durch die Bereitstellung einer direkteren Verarbeitung von Ereignissen durch die Dienstkomponenten und durch Verringerung des in der Logikumgebung zur Ausführung von Diensten (SLEE) enthaltenen speziellen Codes des Protokollstapels. Darüber hinaus behebt die vorliegende Erfindung die Unzulänglichkeiten nach dem Stand der Technik durch das Herausnehmen spezieller Informationen über die Dienstkomponenten aus der SLEE und durch Einführen eines Verbindungs-/Oberflächenschnittstelle an deren Stelle. Dadurch ist die SLEE in der Lage, unabhängig von den individuellen Betriebsdaten der zugrunde liegenden Client-Komponenten Daten universell über die Verbindungs-/Oberflächenschnittstelle zu übertragen und zu empfangen. Gemäß der vorliegenden Erfindung kann somit die Komplexität der SLEE verringert werden. Darüber hinaus braucht eine gemäß der vorliegenden Erfindung konfigurierte SLEE nicht direkt auf bestimmte Client-Komponenten ausgerichtet zu werden.
Vorzugsweise beinhaltet die Architektur gemäß der vorliegenden Erfindung universelle Dienstkomponenten, die so konfiguriert werden können, dass sie Daten mit bestimmten externen Diensten austauschen, und stellt gleichzeitig eine universelle Schnittstelle zu anderen in der SLEE ausgeführten Dienstkomponenten bereit. Auf diese Weise können in der SLEE ausgeführte Dienstkomponenten, zum Beispiel Fernsprech-Dienstkomponenten, universell von der universellen Dienstkomponente externe Dienste wie beispielsweise Datenbankoperationen anfordern. Als Reaktion auf das Empfangen einer universellen Anforderung nach einem externen Dienst kann die universelle Dienstkomponente eine oder mehrere Funktionen des entsprechenden speziellen externen Dienstes abrufen, um der anfordernden Fernsprech-Dienstkomponente den angeforderten externen Dienst zur Verfügung zu stellen. Folglich braucht die Fernsprech-Dienstkomponente keinen speziellen Code zu enthalten, der auf den speziellen externen Dienst ausgerichtet ist. Stattdessen beinhaltet nur die universelle Dienstkomponente den auf den speziellen externen Dienst ausgerichteten speziellen Code. Somit kann die Komplexität von Fernsprech-Dienstkomponenten verringert werden.
KURZBESCHREIBUNG DER ZEICHNUNGEN
Im Folgenden wird die vorliegende Erfindung beispielhaft unter Bezug auf eine bevorzugte Ausführungsart der Erfindung in Verbindung mit den beiliegenden Zeichnungen beschrieben, wobei:
1 eine schematische Darstellung einer Architektur für ein intelligentes Netzwerk ist, das gemäß einer herkömmlichen JAIN-Ausführungsart nach dem Stand der Technik konfiguriert ist;
2 eine schematische Darstellung einer Architektur für ein intelligentes Netzwerk ist, das eine Logikumgebung zur Ausführung von Diensten (SLEE) beinhaltet;
3 eine genauere Darstellung einer Fernsprech-Dienstkomponente ist, die zur Ausführung in der SLEE von 2 konfiguriert ist;
4 eine genauere Darstellung einer universellen Dienstkomponente ist, die zur Ausführung in der SLEE von 2 konfiguriert ist;
5 ein Blockschaubild einer Gruppe universeller Dienstkomponenten ist, die für den Zugriff auf Dienstanwendungen in der Verarbeitungsschicht der Architektur für intelligente Netzwerke von 2 konfiguriert ist; und
6 ist ein Ablaufplan, der ein Verfahren zur Herstellung einer Datenübertragungsverbindung zwischen einer Client-Komponente und der SLEE von 2 über eine Verbindungs-/Oberflächenschnittstelle veranschaulicht.
DETAILLIERTE BESCHREIBUNG DER BEVORZUGTEN AUSFÜHRUNGSART
Die vorliegende Erfindung bietet eine flexible Architektur für Dienstanwendungen für Anbieter von integrierten Netzen. Die Architektur kann der Architektur von modernen intelligenten Netzen insofern ähneln, als die Architektur über eine Protokollschicht, eine Dienstlogikschicht und eine Verarbeitungsschicht verfügen kann. Gemäß den erfindungsgemäßen Anordnungen kann die Architektur der vorliegenden Erfindung eine Logikumgebung zur Ausführung von Anwendungen (SLEE) in der Dienstlogikschicht beinhalten. Insbesondere kann die SLEE JAIN-kompatibel sein. Die SLEE kann einen Ereignis-Routing-Bus zum Weiterleiten von Ereignissen zwischen Dienstkomponenten in der Dienstlogikschicht und Client-Komponenten in der Protokollschicht und der Verarbeitungsschicht beinhalten. Insbesondere kann die in der SLEE ausgeführte Fernsprech-Dienstkomponente so konfiguriert sein, dass sie über den Ereignis-Routing-Bus in der SLEE Daten mit Komponenten in der Protokollschicht und anderen Dienstkomponenten in der Dienstlogikschicht austauschen kann. Und schließlich können Client-Komponenten über eine Verbindungs-/Oberflächenschnittstelle Daten mit der SLEE austauschen.
Durch die Einbeziehung einer gemäß einer bevorzugten Ausführungsart der vorliegenden Erfindung konfigurierten SLEE können Unzulänglichkeiten nach dem Stand der Technik behoben werden, indem ein Ereignis-Routing-Bus bereitgestellt wird, der die Übertragung von Ereignissen zwischen Dienstkomponenten erleichtert. Durch die Bereitstellung einer direkteren Übertragung von Ereignissen können die beim EJB-Ansatz der JAIN-Regeln naturgemäß auftretenden Latenzen verringert werden. Im Gegensatz zu herkömmlichen Ausführungsformen einer SLEE, bei denen Dienstkomponenten nur Ereignisse empfangen und verarbeiten können, die über die SLEE von einer Client-Komponente wie beispielsweise einem Protokollstapel empfangen wurden, können Dienstkomponenten gemäß einer bevorzugten Ausführungsart der vorliegenden Erfindung auch Ereignisse von anderen Dienstkomponenten empfangen und verarbeiten. Somit können neuartige Kombinationen von Dienstkomponenten geschaffen werden, die umfassendere Dienstkomponenten ergeben.
Ferner können Dienstkomponenten so gestaltet werden, dass sie bestimmte Kenntnisse über einen bestimmten Protokollstapel beinhalten. Demzufolge können diese bestimmten Kenntnisse über den bestimmten Protokollstapel aus der SLEE entfernt werden, sodass die SLEE weniger komplex wird. Das führt dazu, dass in einer SLEE gemäß einer bevorzugten Ausführungsart der vorliegenden Erfindung dem intelligenten Netzwerk neue Protokollstapel hinzugefügt werden, ohne dass die SLEE neu codiert werden muss, weil Dienstkomponenten erzeugt werden können, die bestimmte Kenntnisse über den hinzugefügten Protokollstapel beinhalten. Nach dem dynamischen Hinzufügen einer anderen Dienstkomponenten in die SLEE können andere Dienstkomponenten durch die hinzugefügte Dienstkomponente über den Ereignis-Routing-Bus auf den neuen Protokollstapel zugreifen. Im Gegensatz zu intelligenten Netzwerken nach dem Stand der Technik, bei denen keine Datenübertragung zwischen den Dienstkomponenten möglich ist, zeichnet sich eine bevorzugte Ausführungsart der vorliegenden Erfindung dadurch aus, dass durch die Datenübertragung zwischen den Dienstkomponenten das Hinzufügen neuer Protokollstapel vereinfacht werden kann.
Die Architektur gemäß der vorliegenden Erfindung kann auch eine Verbindungs-/Oberflächenschnittstelle für die Datenübertragung der SLEE mit Client-Komponenten in der Protokollschicht beinhalten. Durch die Verbindungs-/Oberflächenschnittstelle zwischen der SLEE und den Client- Komponenten in der Protokollschicht können auch die Unzulänglichkeiten nach dem Stand der Technik behoben werden, indem eine konfigurierbare Verbindung über eine universelle Schnittstelle zu einer bestimmten Client-Komponente hergestellt wird, ohne die Client-Komponente unveränderlich auf die SLEE auszurichten.
Im Gegensatz zu herkömmlichen Ausführungsformen einer SLEE, die direkt auf die Client-Komponenten ausgerichtet ist, mit denen die SLEE Daten austauscht, brauchen die SLEE und die Client-Komponente bei einer bevorzugten Ausführungsart der vorliegenden Erfindung nicht nahe beieinander angeordnet zu sein. Vielmehr können die SLEE und die Client-Komponente über ein Netzwerk verteilt sein, wenn dies erforderlich sein sollte. Dadurch kann zwischen der Client-Komponente und der SLEE eine flexiblere Verbindung hergestellt werden, welche während des Lebenszyklus die Wartung und die Verbesserung der SLEE erleichtern kann. Darüber hinaus können die speziellen Kenntnisse einer bestimmten Client-Komponente aus der SLEE entfernt und anstatt in die Schnittstelle in die Client-Komponente eingefügt werden. Das führt dazu, dass die Komplexität der SLEE verringert werden kann.
Schließlich beinhaltet eine bevorzugte Ausführungsart der vorliegenden Erfindung universelle Komponenten zum Bereitstellen einer abstrahierten Schnittstelle für spezielle externe Dienste. Insbesondere kann einerseits jede universelle Dienstkomponente die Kenntnis von einer bestimmten Ausführungsart eines speziellen externen Dienstes haben, während andererseits andere Dienstkomponenten, insbesondere in der SLEE ausgeführte Fernsprech-Dienstkomponenten, universell externe Dienste der universellen Dienstkomponente aufrufen können, ohne von der speziellen Ausführungsart eines entsprechenden speziellen externen Dienstes Kenntnis zu haben. Auf diese Weise kann die Komplexität der Dienstkomponenten verringern werden, und die Dienstkomponenten können von speziellen Ausführungsarten externer Dienste getrennt werden.
2 ist eine schematische Darstellung eines JAIN-kompatiblen intelligenten Netzes, das gemäß einer bevorzugten Ausführungsart der vorliegenden Erfindung konfiguriert ist. Ein JAIN-kompatibles Netz wird unter Verwendung einer Protokollschicht 202, einer Verarbeitungsschicht 205 und einer Dienstlogikschicht 207 konfiguriert. Die Verarbeitungsschicht 205 kann Anwendungen 208 von dritten Teilnehmern aufnehmen. Typische Anwendungen 208 von dritten Teilnehmern können den Bedarf an Diensten für den Massengebrauch befriedigen, zum Beispiel virtuelle private Netze (Virtual Private Networks, VPNs), ankommende Dienste und vereinheitlichte Nachrichtenübermittlung. Externe Anwendungen 208 von dritten Teilnehmern können kurzzeitige und Nischenanwendungen beinhalten, die unter Verwendung von ungesicherten Übermittlungsverfahren wie beispielsweise Oberflächen zur Datenbanksuche, herunterzuladende Mechanismen und die Parlay-API, die in der Technik bestens bekannt sind, eingesetzt werden können. Schließlich können spezielle externe Dienste 220, zum Beispiel Datenbankdienste, Verzeichnisdienste und drahtlose Dienste, in die Verarbeitungsschicht 205 integriert werden.
Die Dienstlogikschicht 207 kann einen SLEE-Server wie beispielsweise einen JSLEE-Server 200 beinhalten, der JAIN-kompatibel konfiguriert werden kann. Wichtig ist, dass der JSLEE-Server 200 einen Ereignis-Routing-Bus 218 beinhalten kann. Der Ereignis-Routing-Bus 218 kann Nachrichten zwischen Dienstkomponenten 203, 204 und 205 empfangen und senden. Insbesondere können Dienstkomponenten 203, 204 und 205 so konfiguriert werden, dass sie Nachrichten zum Ereignis-Routing-Bus 218 senden und sich beim JSLEE-Server 200 registrieren können, um solche von anderen Dienstkomponenten 203, 204 und 205 gesendeten Ereignisse zu empfangen. Auf diese Weise kann die Datenübertragung zwischen Dienstkomponenten ermöglicht werden. Ferner können Dienstkomponenten 203, 204 und 205 so konfiguriert werden, dass sie über den Ereignis-Routing-Bus 218 Ereignisse von externen Anwendungen empfangen. Außerdem können die von externen Anwendungen 208 empfangenen und an den Ereignis-Routing-Bus 218 gesendeten Ereignisse an andere Dienstkomponenten 203, 204 und 205 weitergeleitet werden, die sich für den Empfang solcher Ereignisse registriert haben.
Die Dienstkomponenten 203, 204 und 205 können Fernsprech-Dienstkomponenten 204, universelle Dienstkomponenten 203 und Internet-Dienstkomponenten 205 beinhalten. 3 ist eine schematische Darstellung einer Fernsprech-Dienstkomponente 204, die für die Verwendung im JSLEE-Server 200 von 2 konfiguriert ist. 3 zeigt, dass die Fernsprech-Dienstkomponente 204 eine oder mehrere Dienstinstanzen 302 beinhalten kann. Die Dienstinstanzen 302 sind einzeln erstellte Dienste, die in der JSLEE 200 ausgeführt werden können. Noch wichtiger ist, dass sich jede Dienstinstanz 302 beim Ereignis-Routing-Bus 218 registrieren kann, um Ereignisse empfangen und an die Protokollschicht 202 sowie andere Fernsprech- und universelle Dienstkomponenten 203, 204 und 205 senden kann.
Auf jede Dienstinstanz 302 kann über eine Dienstoberfläche 306 zugegriffen werden, die die Ausführungsdetails der Dienstinstanz abtrennt. Insbesondere kann über eine in der Dienstoberfläche 306 enthaltene gemeinsame Oberfläche auf die Daten- und Verfahrenselemente der Dienstklasse zugegriffen werden. Ferner kann ein Einsatzdeskriptor 310 verwendet werden. Als Einsatzdeskriptor 310 kann ein Dokument, zum Beispiel ein XML-Dokument, verwendet werden, das die passenden Parameter zum erstmaligen Laden einer Instanz der Dienstkomponente 302 in den JSLEE 200 beschreiben kann. Insbesondere kann externen Objekten eine Schnittstelle zur Dienstoberfläche 306 über eine Dienstschnittstelle 308 mitgeteilt werden, die zum Beispiel einen Bestandteil eines XML-Dokuments darstellt. Desgleichen kann eine Schnittstelle zu jeder Dienstinstanz 302 Teil einer Kontextschnittstelle 304 sein, die ebenfalls zum Beispiel einen Bestandteil eines XML-Dokuments darstellt. Nachdem die Dienstinstanzen 302 geladen worden sind, können sie Daten über den Ereignis-Routing-Bus 218 im JSLEE-Server 200 austauschen.
Damit die Fernsprech-Dienstkomponenten 204 für den Zugriff auf bestimmte externe Dienste 220 keinen Code enthalten müssen, wie dies bei anbieterspezifischen und relationalen Datenbank- und Verzeichnisdiensten der Fall ist, können in die Architektur gemäß der vorliegenden Erfindung universelle Dienstkomponenten 203 aufgenommen werden. Universelle Dienstkomponenten 203 können eine abstrahierte Schnittstelle zu bestimmten externen Diensten 220 bereitstellen und speziell auf universelle Anforderungen von anderen Dienstkomponenten 203, 204 und 205 reagieren, um mit den bestimmten externen Diensten 220 in Verbindung zu treten. Insbesondere können universelle Dienstkomponenten 203 eine gemeinsame API für den Zugriff auf Dienstanwendungen wie beispielsweise drahtlose Dienste, Verzeichnisdienste, Datenbankdienste und Nachrichtendienste bereitstellen.
Praktisch kann für jede verschiedene Dienstanwendung eine universelle Dienstkomponente 203 erstellt werden. Darüber hinaus kann für jedes verschiedene durch die Dienstanwendung verwendete Protokoll eine universelle Dienstkomponente 203 erstellt werden. Somit kann gemäß 2 eine Vielzahl von universellen Dienstkomponenten 203 integriert werden, die jeweils einer Dienstanwendung oder einem Protokoll entsprechen. Zum Beispiel kann für die LDAP-, DB2- und MQSeries-basierten Dienste oder Funktionen jeweils eine andere universelle Dienstkomponente 203 erstellt werden. Desgleichen kann für den Zugriff auf drahtlose Dienstanwendungen jeweils eine andere universelle Dienstkomponente 203 erstellt werden, zum Beispiel wie jene, die das globale Systems für die mobile Kommunikation (Global System for Mobile Communication, GSM), den allgemeinen paketvermittelten Funkdienst (General Packet Radio System, GPRS), die erhöhte Datenrate für GSM-Umgebung (Enhanced Data Rate Environment, EDGE), das Universalsystem für mobile Telekommunikation (Universal Mobile Telecommunications System, UMTS), das Protokoll für drahtlose Anwendungen (Wireless Application Protocol, WAP), das Protokoll für mobilen Zugriff (Mobile Access Protocol, MAP) und den i-Modus verwenden. Durch die Integration von universellen Dienstkomponenten 203 kann daher darauf verzichtet werden, dass andere Dienstkomponenten, insbesondere Fernsprech-Dienstkomponenten 204, über eine spezielle Konfiguration für den Datenaustausch mit bestimmten externen Diensten 220 verfügen.
4 ist eine schematische Darstellung einer universellen Dienstkomponente 203, die für die Verwendung im JSLEE-Server 200 in 2 konfiguriert ist. 4 zeigt, dass die universelle Dienstkomponente 203 eine oder mehrere universelle Dienstinstanzen 402 beinhalten kann. Ebenso wie bei den Fernsprech-Dienstinstanzen 302 von 3 sind die universellen Dienstinstanzen 402 von 4 einzeln erstellte universelle Dienste, die in der JSLEE 200 ausgeführt werden können. Noch wichtiger ist, dass sich jede universelle Dienstinstanz 402 beim Ereignis-Routing-Bus 218 registrieren kann, um Ereignisse von anderen Dienstkomponenten 203, 204 und 205 in der Dienstlogikschicht 207 zu empfangen und an diese zu senden. Ebenso wie bei der Fernsprech-Dienstkomponente 204 kann auf jede universelle Dienstinstanz 402 über eine universelle Dienstoberfläche 406 zugegriffen werden, die die Einzelheiten der Realisierung der Dienstinstanz abtrennt. Insbesondere kann über eine in der universellen Dienstoberfläche 406 enthaltene gemeinsame Schnittstelle auf die Daten- und Verfahrenselemente der Dienstklasse zugegriffen werden.
Ferner kann auch ein Einsatzdeskriptor 410 bereitgestellt werden. Als Einsatzdeskriptor 410 kann ein Dokument, zum Beispiel ein XML-Dokument verwendet werden, das die passenden Parameter für das erstmalige Laden einer Instanz der universellen Dienstkomponente 402 in den JSLEE-Server 200 beschreiben kann. Insbesondere kann externen Objekten über eine universelle Dienstoberfläche 408 eine Schnittstelle zur universellen Dienstoberfläche 406 mitgeteilt werden, die zum Beispiel Bestandteil eines XML-Dokuments sein kann. Desgleichen kann eine Schnittstelle zu jeder Dienstinstanz 402 Teil einer Kontextschnittstelle 404 sein, die auch zum Beispiel als Bestandteil eines XML-Dokuments mitgeteilt werden kann. Nachdem die universellen Dienstinstanzen 402 geladen worden sind, können sie über den Ereignis-Routing-Bus 218 im JSLEE-Server 200 Daten austauschen.
5 ist eine vereinfachte bildliche Darstellung einer beispielhaften Anordnung von universellen Dienstkomponenten 502A, 5028, 502C, 502D, 502E und 502F in dem JAIN-kompatiblen intelligenten Netz einer bevorzugten Ausführungsart der vorliegenden Erfindung. 5 zeigt, dass jede universelle Dienstkomponente 502A, 5028, 502C, 502D, 502E und 502F eine Dienstoberfläche 506 und eine oder mehrere Client-Dienstinstanzen 502 beinhalten kann. Die Dienstoberfläche 506 kann sich beim JSLEE-Server 200 registrieren, um einen bestimmten Ereignistyp zu empfangen, der einer Dienstanwendung 530 entspricht. Demzufolge kann die Dienstoberfläche 506 die zum Umsetzen eines empfangenen Ereignisses und zum Neuformatieren dieses Ereignisses gemäß einem bestimmten Protokoll erforderliche Funktionalität beinhalten. Das neuformatierte Ereignis kann zu einer bestimmten drahtlosen Dienstanwendung weitergeleitet werden. Die Dienstoberfläche 506 kann eine Client-Dienstinstanz 502 zur Verarbeitung einer bestimmten Transaktion oder eines oder mehrerer Ereignisse erstellen. Die Client-Dienstinstanz 502 kann auch zum Austauschen von Daten mit einer der Dienstanwendungen 530A, 530B, 530C, 530D, 530E oder 530F erstellt werden.
5 zeigt, dass die beispielhaften universellen Dienstkomponenten 502A, 502B, 502C, 502D, 502E und 502F unter Anderem eine universelle WAP-Dienstkomponente 502A, eine universelle EDGE-Dienstkomponente 502B, eine universelle GPRS-Dienstkomponente 502C, eine universelle LDAP-Dienstkomponente 502D, eine universelle DB2-Dienstkomponente 502E bzw. eine universelle MQSeries-Dienstkomponente 502F beinhalten kann. Zum Beispiel kann sich die Dienstoberfläche 506 als Teil der universellen WAP-Dienstkomponente 502A beim JSLEE-Server 200 registrieren, um Ereignisse drahtlos zu empfangen, die für ein festnetzunabhängiges Gerät bestimmt sind, zum Beispiel für ein mobiles Empfangsgerät. 5 zeigt, dass die Dienstoberfläche 506 drei Client-Dienstinstanzen 502 erstellt hat, je eine für jedes empfangene Ereignis oder eine Reihe von Ereignissen, die eine Transaktion für eine WAP-basierte festnetzunabhängige Dienstanwendung umfassen. Alternativ kann eine einzige Client-Dienstinstanz 502 mehrere Transaktionen verarbeiten. Somit kann jede Client-Dienstinstanz 502 mit der WAP-basierten Dienstanwendung 530A in Verbindung treten.
Desgleichen kann die universelle EDGE-Dienstkomponente 502B bzw. die universelle MQSeries-Dienstkomponente 502F jeweils eine Dienstoberfläche und eine oder mehrere Client-Dienstinstanzen beinhalten, um drahtlos mit EDGE-basierten Dienstanwendungen 530B bzw. mit MQSeries-basierten Nachrichtenwarteschlange-Dienstanwendungen 530F in Verbindung zu treten. Es sollte klar sein, dass eine universelle Dienstkomponente bei Bedarf für eine beliebige Dienstanwendung erstellt werden kann, darunter auch für anbieterspezifische Datenbank- und festnetzunabhängige Dienste unter Verwendung von anbieterspezifischen Schnittstellen und Protokollen.
Im Gegensatz zu den Fernsprech- und universellen Dienstkomponenten 203 und 204 in 2 können die internetfähigen Dienstkomponenten 205 vorkonfiguriert werden, um Daten mit einem externen Protokoll im Server wie beispielsweise einem Servlet oder einem Script auszutauschen.
Als Beispiele für Server-Zusatzprogramme können unter Anderem Common Gateway Interface (CGI), Perl-Scripts, Java^TM-Server Pages, VB-Scripts, Active Server Pages^TM oder andere Scriptverfahren dienen. Sobald eine externe Anwendung 232 auf die internetfähigen Dienstkomponenten 205 zugegriffen hat, können die internetfähigen Dienstkomponenten der externen Anwendung 232 den Zugriff auf den Ereignis-Routing-Bus 218 im JSLEE-Server 200 ermöglichen, wodurch die Dienstkomponenten 203, 204 und 205 Daten miteinander austauschen können.
Durch diesen Mechanismus können die im JSLEE-Server 200 ausgeführten Dienstkomponenten 203, 204 und 205 Daten auch mit den internetfähigen Dienstkomponenten 205 austauschen. Da die internetfähigen Dienstkomponenten 205 für den Datenaustausch mit einem Server-Zusatzprogramm 232 verbunden sein können, das in Verbindung mit einem Web-Server 230 in einem computergestützten Datennetz wie dem Internet ausgeführt wird, können somit andere Dienstkomponenten 203 und 204 im JSLEE-Server 200 die internetfähigen Dienstkomponenten 205 nutzen, um Daten über das Internet zu senden und zu empfangen. Darüber hinaus können Benutzer und Administratoren aus dem Internet auf andere Dienstkomponenten 203 und 204 im JSLEE-Server 200 zugreifen.
Die internetfähigen Dienstkomponenten 205 können so konfiguriert werden, dass sie Daten direkt mit dem Web-Server 230 austauschen, indem sie Anforderungen und Antworten gemäß einem Hypertext-Übertragungsprotokoll (HTTP) senden und empfangen. Desgleichen kann der Web-Server 230 Server-Zusatzprogramme beinhalten, die ebenfalls gemäß dem HTTP zum Austauschen von Daten mit internetfähigen Dienstkomponenten 205 konfiguriert sind. Ungeachtet dessen ist die Erfindung nicht auf die Art und Weise beschränkt, wie die internetfähigen Dienstkomponenten 205 Daten mit den entsprechenden Server-Zusatzprogrammen austauschen. Vielmehr sind beliebige bekannte Datenübertragungsverfahren einschließlich solcher allgemeiner verbindungsorientierter Verfahren wie explizite TCP/IP-Datenübertragungen geeignet.
Durch die Kombination von Server-Zusatzprogrammen 232 und den internetfähigen Dienstkomponenten 205 kann über das Internet und eine durch die internetfähigen Dienstkomponenten 205 bereitgestellte Schnittstelle für die Programmierung von Anwendungsprogrammen (API) auf verschiedene Aspekte von Diensten und Dienstkomponenten zugegriffen werden. Zum Beispiel können Teilnehmer auf Dienstattribute zugreifen und diese verändern. Dienstattribute können einen beliebigen Aspekt eines Dienstes beinhalten, auf den ein Teilnehmer zugreifen kann. Desgleichen können Dienstadministratoren oder bevorzugte Anwender (super users) auf Verwaltungsfunktionen über das Internet zugreifen, diese überwachen und ausführen. Zu Verwaltungsfunktionen gehören unter Anderem beliebige einem Systemadministrator oder einem bevorzugten Anwender vorbehaltene Funktionalitäten, die einem Teilnehmer nicht angeboten werden. Insbesondere können die internetfähigen Dienstkomponenten 205 diesen Zugriff Teilnehmern und Administratoren über das Internet zur Verfügung stellen, ohne sich externer Dienste oder Systeme zu bedienen.
Jede internetfähige Dienstkomponente 205 kann ebenso wie andere Dienstkomponenten 203 oder 204 im JSLEE-Server 200 so konfiguriert werden, dass sie Ereignisse empfangen und an den JSLEE-Server 200 senden kann. Auf diese Weise können sich andere Dienstkomponenten 203 und 204 beim JSLEE-Server 200 registrieren, um solche Ereignisse empfangen zu können. Diese Dienstkomponenten 203 und 204 können entsprechend Ereignisse an den JSLEE-Server senden, bei dem die internetfähigen Dienstkomponenten 205 für den Empfang registriert sind. Es sollte klar sein, dass die internetfähigen Dienstkomponenten 205 sowohl vom JSLEE-Server 200 empfangene Ereignisse als auch vom Web-Server 230 empfangene Daten verarbeiten können. Auf diese Weise können die internetfähigen Dienstkomponenten 205 als Schnittstelle zwischen dem Internet und dem JSLEE-Server 200 fungieren.
Insbesondere kann der JSLEE-Server 200 auch verschiedene Lebenszyklus-Verwaltungskomponenten einschließlich eines Vorrats an ausführbaren Programmsegmenten 222, eines Klassenladeprogramms 224, Zeitgebern 226 und Betriebslastzählern 228 beinhalten. Auch die Lebenszyklus-Verwaltungskomponenten sind nicht auf die in 2 gezeigten Komponenten beschränkt. Vielmehr können die Lebenszyklus-Verwaltungskomponenten Komponenten beinhalten, die andere Lebenszyklus-Verwaltungsaufgaben wie beispielsweise den Lastausgleich ausführen können. Auf jeden Fall sind die einzelnen Dienstkomponenten gemäß den erfindungsgemäßen Anordnungen von der Ausführung systembedingter Aufgaben wie der Lebenszyklusverwaltung befreit und können bei Fernsprechanwendungen zweckdienlicher eingesetzt werden.
Insbesondere kann der Vorrat an ausführbaren Programmsegmenten 222 gemäß 2 eine Vielzahl vorkonfigurierter und geladener Ausführungssegmente beinhalten, die durch eine Komponente zur Verwaltung des Vorrats an ausführbaren Programmsegmenten auf Anforderung den anfordernden Dienstkomponenten 203, 204 und 205 zugewiesen werden können, die im JSLEE-Server 200 ausgeführt werden. Wenn die anfordernden Dienstkomponenten 203, 204 und 205 mit der Nutzung des zugewiesenen Programmsegments fertig sind, kann die Komponente zur Verwaltung des Vorrats an ausführbaren Programmsegmenten die Zuweisung des zugewiesenen Programmsegments aufheben und das frei gewordene Programmsegment wieder in den Vorrat der ausführbaren Programmsegmente 222 einfügen, damit dieser von anderen anfordernden Dienstkomponenten 203, 204 und 205 genutzt werden kann, die im JSLEE-Server ausgeführt werden.
Das Klassenladeprogramm 224 kann vom JSLEE-Server 200 zum ordnungsgemäßen Laden von Dienstkomponenten 203, 204 und 205 verwendet werden, damit diese im JSLEE-Server ausgeführt werden. Insbesondere kann das Klassenladeprogramm 224 die mit jeder zu ladenden Dienstkomponente 203, 204 und 205 verbundenen Konfigurations- und Ladeparameter prüfen. Anschließend kann das Klassenladeprogramm 24 die Dienstkomponenten 203, 204 und 205 unter Verwendung der ermittelten Konfigurations- und Ladeparameter ausführen. Zum Schluss kann das Klassenladeprogramm 224 die Dienstkomponenten 203, 204 und 205 beim Ereignis-Routing-Bus 218 registrieren, damit Ereignisse an die und von den Dienstkomponenten 203, 204 und 205 übertragen werden können, die im JSLEE-Server 200 ausgeführt werden.
Schließlich kann die Protokollschicht 202 einen oder mehrere Protokollstapel 206 beinhalten, die so konfiguriert sein können, dass sie mit den im JSLEE-Server 200 ausgeführten Dienstkomponenten 204 in Verbindung treten. Obwohl 2 nur drei Protokollstapel 206 zeigt, ist die Erfindung insbesondere nicht auf die Anzahl oder die Art der Protokollstapel 206 beschränkt. Vielmehr kann der JSLEE-Server 200 mit jeder Art von Protokollstapel in Verbindung treten, zum Beispiel mit Protokollstapeln, die gemäß den JAIN-Regeln konfiguriert sind.
Während des Betriebs kann der JSLEE-Server 200 Ereignisse an die Protokollstapel 206 in der Protokollschicht 202 senden und von diesen empfangen. Insbesondere können die Ereignisse über den Ereignis-Routing-Bus 218 im JSLEE-Server 200 gesendet und empfangen werden. Die Fernsprech-Dienstkomponenten 204 und die universellen Dienstkomponenten 203 können sich als Empfänger für bestimmte Ereignisse registrieren, die über den Ereignis-Routing-Bus 218 empfangen werden. Die Dienstkomponenten 203, 204 und 205, die beim JSLEE-Server 200 registriert sind, können Protokollstapel-Ereignisse empfangen, die an einzelne dieser Dienstkomponenten 203, 204 oder 205 gerichtet sind. Ferner können die Dienstkomponenten 203, 204 und 205 Dienstkomponenten-Ereignisse empfangen, die an einzelne dieser Dienstkomponenten 203, 204 oder 205 gerichtet sind. Insbesondere kann der Ereignis-Routing-Bus 218 des JSLEE-Servers 200 empfangene Ereignisse an die Dienstkomponenten 203, 204 und 205 weiterleiten, die sich für den Empfang solcher Ereignisse beim JSLEE-Server 200 registriert haben.
Gemäß einer bevorzugten Ausführungsart der vorliegenden Erfindung kann der JSLEE-Server 200 so konfiguriert werden, dass er Daten mit Client-Komponenten in dem JAIN-kompatiblen intelligenten Netz austauschen kann. Als Client-Komponenten kommen nicht nur die Protokollstapel 206, sondern auch andere Dienstkomponenten 203, 204 und 205, spezielle externe Dienste 220 und externe Anwendungen 208 infrage. Wichtig ist, dass der JSLEE-Server 200 ohne spezielle Kenntnisse über die Ausführungsdetails jeder Client-Komponente so konfiguriert werden kann. Zu diesem Zweck kann der JSLEE-Server 200 Verbindungselemente 210 beinhalten, die mit Oberflächen 216 Daten austauschen können und dadurch eine Verbindungs-/Oberflächenschnittstelle bilden. Die Oberfläche 216 kann dem Verbindungselement 210 eine abstrahierte Schnittstelle für eine bestimmte Client-Komponente wie beispielsweise den Protokollstapel 206 darbieten. Jedes Verbindungselement 210 wiederum kann so konfiguriert werden, dass es Daten mit einer entsprechenden Client-Komponente wie einem Protokollstapel 206 über die abstrahierte Schnittstelle austauscht, die von der entsprechenden Oberfläche 216 dargeboten wird.
Im Allgemeinen kann der JSLEE-Server 200 somit unabhängig von den Ausführungsdetails der zugrunde liegenden Client-Komponenten wie beispielsweise der Protokollstapel 206 universal Ereignisse über die Verbindungs-/Oberflächenschnittstelle senden und empfangen. Vielmehr benötigt lediglich die Oberfläche 216 spezielle Kenntnisse über die Ausführungsdetails des zugrunde liegenden Protokollstapels 206. Gemäß einem Aspekt der Erfindung kann ein JSLEE-Deskriptor 214 integriert werden, der einzelne Oberflächen 216 bezeichnen kann, mit deren Hilfe entsprechende Verbindungselemente 210 für die Datenübertragung konfiguriert werden können.
Insbesondere kann der JSLEE-Server 200 beim Systemstart den JSLEE-Deskriptor 214 lesen, um die Identität jeder angegebenen Oberfläche 216 kennen zu lernen. Anschließend kann der JSLEE-Server 200 die Verbindungselemente 210 konfigurieren, damit diese mit den angegebenen Oberflächen 216 in Verbindung treten können. Desgleichen können für jedes Verbindungselement 210 Client-Komponenten-Deskriptoren 212 bereitgestellt werden. Die Client-Komponenten-Deskriptoren 212 können bestimmte Ereignisse bezeichnen, über welche eine zugehörige Client-Komponente wie beispielsweise ein Protokollstapel 206 durch den Ereignis-Routing-Bus 218 des JSLEE-Servers 200 benachrichtigt werden kann.
6 ist ein Ablaufplan, der ein Verfahren zum Verbinden einer SLEE für den Datenaustausch mit einer Client-Komponenten in einer Umgebung zur Ausführung von Anwendungen in einem integrierten Netz veranschaulicht. Das Verfahren kann in Kasten 602 beginnen, in welchem die SLEE geladen werden kann. In Kasten 604 kann ein SLEE-Deskriptor geladen werden. Wenn die Prüfung in Kasten 606 eine angegebene Client-Komponente ergibt, kann in Kasten 608 eine Verbindungselement-Instanz erzeugt und so konfiguriert werden, dass sie mit einer der angegebenen Client-Komponente zugewiesenen Oberfläche Daten austauschen kann. In Kasten 610 kann ein dem konfigurierten Verbindungselement zugeordneter Teilnehmer-Deskriptor geladen und in Kasten 612 bei einer Ereignisverarbeitungsroutine in der SLEE die angegebene Client-Komponente registriert werden, damit sie die im Teilnehmer-Deskriptor verzeichneten Ereignisse empfängt.
Anschließend können, wenn die Prüfung in Kasten 614 ergibt, dass im SLEE-Deskriptor noch weitere Client-Komponenten bezeichnet sind, weitere Verbindungselement-Instanzen gemäß Kasten 608 bis 612 erzeugt und konfiguriert werden. Zum Schluss, nachdem alle Verbindungselement-Instanzen erzeugt und konfiguriert worden sind, kann in Schritt 616 die SLEE gestartet werden, und Ereignisse können ungeachtet der zugrunde liegenden Ausführungsdetails jeder einzelnen Client-Komponente Ereignisse über die Verbindungs-/Oberflächenschnittstelle zu den registrierten Client- Komponenten weitergeleitet werden. Das bedeutet, dass die SLEE über Client-Komponenten-Oberflächen für den Datenaustausch mit Client-Komponenten verbunden werden kann, ohne dass die SLEE über spezielle Kenntnisse über jede Client-Komponente verfügen muss.
Die vorliegende Erfindung kann in Form von Hardware, Software oder einer Kombination aus Hardware und Software realisiert werden. Ein Verfahren zur Bereitstellung von Fernsprechdiensten gemäß der vorliegenden Erfindung kann entweder zentralisiert in einem Computersystem oder verteilt realisiert werden, indem verschiedene Elemente auf mehrere miteinander verbundene Computersysteme verteilt sind. Beliebige Arten von Computersystemen – oder anderer zum Ausführen der hier beschriebenen Verfahren geeigneter Vorrichtungen – sind geeignet. Eine typische Kombination aus Hardware und Software kann in einem Universalcomputersystem mit einem Computerprogramm bestehen, das in das System geladen und in diesem ausgeführt wird und das Computersystem so steuert, dass es die hier beschriebenen Verfahren ausführt.
Die vorliegende Erfindung kann auch in ein Computerprogrammprodukt integriert werden, das alle Merkmale zum Ausführen der hier beschriebenen Verfahren umfasst und nach dem Laden in ein Computersystem diese Verfahren auszuführen in der Lage ist. Unter einem Computerprogrammmittel oder einem Computerprogramm ist im vorliegenden Zusammenhang ein beliebiger Ausdruck eines Satzes von Anweisungen in einer beliebigen Sprache, einem beliebigen Code oder einer beliebigen Schreibweise zu verstehen, der ein System mit einer Datenverarbeitungskapazität veranlassen soll, eine bestimmte Funktion entweder direkt oder nach einem oder beiden der folgenden Schritte auszuführen: a) Umwandlung in eine andere Sprache, einen anderen Code oder eine andere Schreibweise; b) Wiedergabe in einer anderen materiellen Form.

Claims

Umgebung zur Ausführung von Anwendungen für ein intelligentes Netzwerk, wobei die Umgebung Folgendes umfasst: eine Logikumgebung zur Ausführung von Diensten (SLEE) in einer logischen Dienstschicht (207), wobei die SLEE einen Ereignis-Routing-Bus (218) zum Weiterleiten von Ereignissen zwischen Dienstkomponenten (203, 304, 205) in der logischen Dienstschicht und Client-Komponenten in einer Protokollschicht (202) und einer Verarbeitungsschicht (205) umfasst; mindestens eine Client-Komponente in der Protokollschicht, wobei die mindestens eine Client-Komponente über eine Verbindungs-/Oberflächenschnittstelle (210, 216) zur Datenübertragung mit der SLEE verbunden ist; mindestens eine Dienstkomponente, die so konfiguriert ist, dass sie über den Ereignis-Routing-Bus Daten mit anderen Dienstkomponenten in der SLEE austauschen kann; und dadurch gekennzeichnet ist, dass sie mindestens eine internetfähige Dienstkomponente (IESC) (205) umfasst, die in der SLEE ausgeführt wird, wobei die IESC eine Konfiguration zum Senden und Empfangen von Ereignissen an andere oder von anderen Dienstkomponenten in der SLEE über den Ereignis-Routing-Bus und eine Datenübertragungsverbindung zu einem Server-Zusatzprogramm außerhalb der SLEE aufweist.
Umgebung zur Ausführung von Anwendungen nach Anspruch 1, bei der mindestens eine Dienstkomponente eine Fernsprech-Dienstkomponente (204) ist, die in der SLEE ausgeführt wird, wobei die Fernsprech-Dienstkomponente ferner so konfiguriert ist, dass sie Daten mit den Clientkomponenten in der Protokollschicht austauscht.
Umgebung zur Ausführung von Anwendungen nach Anspruch 1 oder nach Anspruch 2, bei der mindestens eine Dienstkomponente eine universelle Dienstkomponente (203) ist, die in der SLEE ausgeführt wird, wobei die universelle Dienstkomponente ferner so konfiguriert ist, dass sie Daten mit speziellen externen Diensten in der Verarbeitungsschicht austauscht.
Umgebung zur Ausführung von Anwendungen nach einem der vorhergehenden Ansprüche, bei der die Verbindungs-/Oberflächenschnittstelle Folgendes umfasst: eine Client-Komponenten-Oberfläche, wobei die Client-Komponenten-Oberfläche eine abstrahierte Schnittstelle für eine Client-Komponente in der Protokollschicht bereitstellt; und eine der SLEE zugeordnete Verbindung, wobei die Verbindung der Client-Komponenten-Oberfläche entspricht und so konfiguriert ist, dass sie über die abstrahierte Schnittstelle, die durch die Client-Komponenten-Oberflache bereitgestellt wird, Daten mit der Client-Komponente austauscht.
Umgebung zur Ausführung von Anwendungen nach einem der vorhergehenden Ansprüche, die ferner Folgendes umfasst: einen SLEE-Deskriptor (214), wobei der SLEE-Deskriptor mindestens eine Client-Komponente bezeichnet, mit welcher die SLEE so konfiguriert werden kann, dass sie Daten über eine Verbindungs-/Oberflächenschnittstelle austauscht.
Umgebung zur Ausführung von Anwendungen nach einem der vorhergehenden Ansprüche, die ferner Folgendes umfasst: mindestens einen Client-Komponenten-Deskriptor, wobei jeder Client-Komponenten-Deskriptor einer bestimmten Client-Komponente in der Protokollschicht entspricht und der mindestens eine Client-Komponenten-Deskriptor bestimmte Ereignisse bezeichnet, über welche die bestimmte Clientkomponente durch den Ereignis-Routing-Bus in der SLEE in Kenntnis gesetzt werden kann.
Umgebung zur Ausführung von Anwendungen nach einem der vorhergehenden Ansprüche, bei welcher die Client-Komponente ein Protokollstapel ist.
Umgebung zur Ausführung von Anwendungen nach einem der Ansprüche 1 bis 6, bei welcher die Client-Komponente aus der Gruppe ausgewählt wird, die aus einer Anrufsteuerungskomponente, einer Signalisierungs-Protokollkomponente, einem Verbindungsverwaltungs- Protokoll und einem Protokoll für sicheren Netzzugriff besteht.
Umgebung zur Ausführung von Anwendungen nach einem der vorhergehenden Ansprüche, wobei die SLEE mit dem JAIN-Konzept (Java-APIs für integrierte Netzwerke) kompatibel ist.
Umgebung zur Ausführung von Anwendungen nach einem der vorhergehenden Ansprüche, wobei die SLEE ferner Folgendes umfasst: ein Klassenladeprogramm (224) zum Laden von Dienstkomponenten in die SLEE, wobei die SLEE jede geladene Dienstkomponente registriert, damit diese an bestimmte registrierte Dienstkomponenten gerichtete Ereignisse empfangen können; wobei der Ereignis-Routing-Bus die empfangenen Ereignisse an die in der SLEE ausgeführten bestimmten registrierten Dienstkomponenten weiterleitet.
Umgebung zur Ausführung von Anwendungen nach einem der vorhergehenden Ansprüche, wobei die SLEE ferner Folgendes umfasst: einen Vorrat an ausführbaren Programmsegmenten (thread pool) (222), und eine Einheit zur Verwaltung des Vorrats an ausführbaren Programmsegmenten zum Zuweisen von ausführbaren Programmsegmenten zur Verwendung durch die geladenen Dienstkomponenten.
Verfahren zur Bereitstellung von Fernsprechdiensten, wobei das Verfahren die folgenden Schritte umfasst: in einem Ereignis-Routing-Bus in einer Logikumgebung zur Ausführung von Diensten (SLEE), Empfangen von Ereignissen der Protokollschicht von Client-Komponenten über eine Verbindungs-/Oberflächenschnittstelle, Empfangen von Ereignissen der logischen Dienstschicht von Dienstkomponenten, die in der SLEE ausgeführt werden, und Weiterleiten der betreffenden Ereignisse der Protokollschicht und der Ereignisse der logischen Dienstschicht an Dienstkomponenten und Client-Komponenten, die für den Empfang der betreffenden Ereignisse der Protokollschicht und der logischen Dienstschicht registriert sind; und wobei mindestens eine Dienstkomponente eine internetfähige Dienstkomponenten IESC ist und wobei die IESC: mindestens ein Ereignis der logischen Dienstschicht an den Ereignis-Routing-Bus sendet, wobei der Ereignis-Routing-Bus das gesendete Ereignis der logischen Dienstschicht an eine andere Dienstkomponente senden kann, die für den Empfang des gesendeten Ereignisses der logischen Dienstschicht registriert ist; Empfangen eines Ereignisses der logischen Dienstschicht von einer anderen Dienstkomponente; und Bereitstellen einer Datenübertragungsverbindung zu einem Server-Zusatzprogramm außerhalb der SLEE als Reaktion auf dem Empfang des Ereignisses der logischen Dienstschicht von der anderen Dienstkomponente.
Maschinenlesbarer Speicher, in welchem ein Computerprogramm zum Bereitstellen von Fernsprechdiensten gespeichert ist, wobei das Computerprogramm einen durch eine Maschine ausführbaren Programmcode aufweist, der die Maschine zum Ausführen der Schritte nach Anspruch 12 veranlasst.