DE602004006648T2

DE602004006648T2 - Benutzungsverfahren und system in einem kommunikationsnetz

Info

Publication number: DE602004006648T2
Application number: DE602004006648T
Authority: DE
Inventors: Joachim Bruchlos; Joachim Hagmeier; Dietmar Kuebler; Timo Kussmaul
Original assignee: International Business Machines Corp
Current assignee: International Business Machines Corp
Priority date: 2003-12-22
Filing date: 2004-12-01
Publication date: 2008-01-31
Anticipated expiration: 2024-12-02
Also published as: EP1698104B1; ATE363169T1; US20080027735A1; JP2007521581A; US8543512B2; CN1751474A; CN100373875C; EP1698104A1; JP4563403B2; ES2284075T3; WO2005062532A1; DE602004006648D1

Description

Hintergrund der Erfindung
1. Gebiet der Erfindung
Die Erfindung betrifft ein Nutzungsverfahren und -system in einem Kommunikationsnetz. Insbesondere betrifft die Erfindung ein Validierungsverfahren und -system für Lizenzverträge in einem Computernetz für Web-Services während der Laufzeit.
2. Beschreibung der zugrunde liegenden Technik
Lizenzverträge für Web-Services oder andere Dienste in einem Kommunikationsnetz legen Regeln in Bezug auf die Inanspruchnahme von Diensten fest. Während der Laufzeit erfordern die Lizenzverträge eine Validierung im Online-Zustand, um Verstöße gegen den Lizenzvertrag, beispielsweise die Überschreitung des vorgegebenen Umfangs der Dienst-Inanspruchnahme, festzustellen. In vielen Fällen kann der Lizenzvertrag die Inanspruchnahme sogenannter High-Value/Low-Quantity-Web-Services sowie die Inanspruchnahme von Low-Value/High-Quantity-Web-Services betreffen.
Ein Lizenzvertrag ist im Allgemeinen eine Vereinbarung zwischen zwei oder mehreren Vertragsparteien, welche die Lizenzbedingungen festlegt. Insbesondere betrifft der Lizenzvertrag für Web-Services die Bedingungen für die Inanspruchnahme von Web-Services. Insbesondere betrifft der Lizenzvertrag für Web-Services die Bedingungen für die Inanspruchnahme von Web-Services. Er definiert einen oder mehrere Web-Services, die Identität der anfordernden Vertragspartei, die als Servicekonsument bezeichnet wird, beliebige Attribute zur Spezifizierung der Service-Inanspruchnahme, wie beispielsweise Klassifizierung, Preis und Servicequalität sowie Zugriffsregeln. Des Weiteren können im Lizenzvertrag eine Inanspruchnahmerichtlinie, eine Mehrfachzugriffsrichtlinie, eine Zeitrichtlinie, eine Namensrichtlinie und eine Nutzungsbedingungsrichtlinie definiert sein. Gemäß der Inanspruchnahmerichtlinie kann nur eine maximale Anzahl von Anforderungen zulässig sein. Die Mehrfachzugriffsrichtlinie gibt die maximale Anzahl gleichzeitiger Anforderungen an. Die Zeitrichtlinie definiert bestimmte Zeiten, zu denen Anforderungen nur zulässig sind. Die Namensrichtlinie definiert, dass nur die im Vertrag festgelegten Identitäten einen Service anfordern können. Die Nutzungsbedingungsrichtlinie kann enthalten, dass beispielsweise der Weiterverkauf von Services nicht zulässig ist.
Die Inanspruchnahme eines Web-Service wird durch einen Zählservice überwacht, bei dem es sich um eine externe Serverkomponente handeln kann. Jedes Mal, wenn ein Web-Service aufgerufen wird, erzeugt der Zählservice Zählereignisse. Der Inhalt dieser Zählereignisse gibt neben anderen Daten den Lizenzvertrag an, der zur Inanspruchnahme eines Web-Service gehört. Typische Beispiele von Zählereignissen sind die Startzeit des Aufrufs (Startereignis), die Endezeit des Aufrufs (Endeereignis), der Aufruftrigger (sogenanntes ad-hoc-Ereignis) und das Abbruchereignis (Abbruchereignis).
Die Validierung und Zählung eines Web-Serviceaufrufs wird durch eine Anordnung aufeinanderfolgender Handler verarbeitet. Diese Handler rufen Dienste auf, um Aufgaben wie beispielsweise die Überprüfung der Identität des Servicekonsumenten oder die Validierung des Lizenzvertrags durchzuführen. Ein Zähl-Handler ruft den Zählservice auf, um die zu dem Aufruf des Web-Service gehörenden Zählereignisse zu verarbeiten und zu speichern. Die Serverkomponente, die diese Handler und Dienste bereitstellt, wird als Serviceanbieter bezeichnet. Eine Serverkomponente, die den angeforderten Web-Service anbietet, wird als Servicelieferant bezeichnet.
Wenn der Servicekonsument eine Serviceanforderung auslöst, wird der Nachrichtenkontext beim Serviceanbieter aus einer Serviceanforderungsnachricht extrahiert. Der Nachrichtenkontext enthält die relevanten Informationen der Serviceanforderungsnachricht. Beim Durchlaufen der unterschiedlichen Handler wird der Nachrichtenkontext vervollständigt. Dadurch werden zusätzliche relevante Informationen in den Nachrichtenkontext eingefügt. Jeder Handler kann einen Dienst aufrufen, um definierte Aktivitäten durchzuführen. Bei diesen Diensten kann es sich um externe Serverkomponenten handeln. Eine derartige Aktivität kann beispielsweise im Überprüfen der Identität des Servicekonsumenten oder im Bereitstellen von vertrags- und lizenzbezogenen Daten bestehen.
Am Ende der Reihe von Handlern enthält der Nachrichtenkontext alle Daten, die der Zähl-Handler benötigt, um eine entsprechende Zählereignisanforderung zu erzeugen. Bei diesen zusätzlichen Daten kann es sich insbesondere um die bestätigte Identität, Vertragsdaten oder Lizenzdaten handeln. Jeder Serviceaufruf veranlasst die Erzeugung verschiedener Zählereignisanforderungen. Diese Zählereignisanforderungen werden durch den Zähl-Handler erzeugt und an den Zählservice gesendet. Der Zählservice verarbeitet diese Zählereignisanforderungen. Da die Aufrufe des Zählservice relativ langsam sind, stellt das Verarbeiten dieser Zählereignisanforderungen einen schwerwiegenden Engpass für die Systemleistung dar.
Der Zähl-Handler nach dem Stand der Technik umfasst den Nachrichtenkontexttrenner, einen Zählereignisgenerator, einen Cache-Controller, einen Cache-Speicher (Zwischenspeicher) und eine Zählservice-Aufrufeinheit.
Der Nachrichtenkontexttrenner trennt die betreffenden Informationen vom Nachrichtenkontext ab, beispielsweise Serviceanforderungsinformationen, Identität des Servicekonsumenten, Vertrags- und Lizenzinhalt, und leitet diese Informationen zum Zählereignisgenerator weiter. Der Zählereignisgenerator erzeugt eine Zählereignisanforderung, die die Art des Zählereignisses und die Informationen aus dem Nachrichtenkontext enthält. Je nach Status der Web-Serviceanforderung sind das Zählstartereignis, Zählendeereignis, das Aufrufzählereignis und das Abbruchzählereignis Beispiele der enthaltenen Zählereignisarten.
Der Cache-Controller empfängt die erzeugte Zählereignisanforderung und speichert diese Zählereignisanforderung vorübergehend in einem dedizierten Cache-Speicher. Gewöhnlich ist der Cache-Speicher physisch durch einen RAM-Speicherbereich realisiert. Die maximale Anzahl von Zählereignisanforderungen, die im Cache-Speicher gespeichert werden können, ist ein fester codierter Programmparameter. Daher kann der Cache-Speicher eine feste und vorgegebene Anzahl von Zählereignisanforderungen speichern. Die Anzahl der gespeicherten Zählereignisanforderungen wird vom Cache-Controller überwacht. Wird die maximale Anzahl überschritten, liest der Cache-Controller alle gespeicherten Zählereignisanforderungen aus dem Cache, leitet sie zur Zählservice-Aufrufeinheit weiter und löscht schließlich den Inhalt des Cache-Speichers. Die Zählservice-Aufrufeinheit erzeugt eine Nachricht, die die Zählereignisanforderungen enthält, und ruft den Zählservice auf, um die Zählereignisanforderungen zu verarbeiten.
Das Zwischenspeichern der Zählereignisanforderungen ist notwendig oder zumindest vorteilhaft, da das Aufrufen des Zählservice langsam ausgeführt wird und erhebliche Netzwerkressourcen erfordert. Die langsame Ausführung des Aufrufs des Zählservice wird in der Hauptsache durch die Transaktionszeit des Netzes verursacht. Die Transaktionszeit wird zum Übertragen der Anforderung an den entfernten Zählservice und Empfangen einer Antwort benötigt. Die langsame Ausführung wird des Weiteren durch das Codieren und Decodieren von Nachrichten und durch die Zeit verursacht, die der Zählservice für die Ausführung benötigt.
Der Zählservice erzeugt aus den Zählereignisanforderungen Zählereignisse, speichert diese in einer Datenbank und benachrichtigt die Lizenzvalidierungskomponente des Vertragsservice über den aktualisierten Status der Datenbank.
Die Lizenzvalidierungskomponente des Vertragsservice verwendet die gespeicherten Zählereignisse, um zu berechnen und zu überprüfen, ob ein Web-Serviceaufruf mit den im entsprechenden Lizenzvertrag definierten Servicezugriffsregeln übereinstimmt. Lizenzverträge für Web-Services beruhen auf Lizenzmodellen, welche diese Servicezugriffsregelungen beschreiben.
Ein bedeutendes Lizenzmodell ist der konsumtive und/oder kumulative Servicezugriff. Diese Regelung hat zum Inhalt, dass ein Lizenzvertrag für ein vorgegebenes Quantum gilt. Ein derartiges Quantum kann beispielsweise definieren, wie viele Verbraucher den Web-Service unter einem gegebenen Lizenzvertrag nutzen dürfen. Ein weiteres bedeutendes Lizenzmodell ist der gleichzeitige Servicezugriff. Diese Regelung definiert die Grenzen hinsichtlich der zulässigen Anzahl simultaner Serviceaufrufe.
Zur Lizenzvertragsvalidierung ruft die Lizenzvertrag-Validierungskomponente den Zählservice auf, um die gespeicherten Zählereignisse zu empfangen, die dem Lizenzvertrag entsprechen. Die Lizenzverträge, die die Regelungen betreffs Kumulierung und Gleichzeitigkeit der Inanspruchnahme von Web-Services definieren, erfordern online während der Laufzeit eine Status-Validierung, um Verstöße gegen den Lizenzvertrag zu überwachen, beispielsweise das Überschreiten des vorgegebenen Quantums der Service-Inanspruchnahme. Das Überschreiten vorgegebener Lizenzvertragsgrenzen während der Laufzeit hat in der Regel geschäftliche Konsequenzen zur Folge, wie Zusatzkosten, Gebühren wegen Vertragsverstoßes oder sogar den Ausschluss von Services.
Da der zähl-Handler die Zählereignisanforderungen im Cache-Speicher ablegt, ist nicht garantiert, dass die vom Zählservice verwaltete Persistenzeinrichtung, beispielsweise die Datenbank, zu dem Zeitpunkt, zu dem der Geschäftsservice angefordert wird, den aktuellen Status der Inanspruchnahme des Geschäftsservice repräsentiert.
Daher werden mögliche Verstöße bei der Inanspruchnahme des Web-Service erst erkannt, nachdem der Inhalt des Cache-Speichers in die Datenbank übertragen wurde. Dieser Zeitpunkt kann erheblich später eintreten als der Zeitpunkt, zu welchem der Service angefordert wurde. Diese verspätete Erkennung eines Verstoßes kann schwerwiegende Konsequenzen nach sich ziehen. Servicelieferanten können im Moment des Auftretens einer Überlastung von Ressourcen diese nicht erkennen. Wegen des Verstoßes gegen Beschränkungen des Servicezugriffs hinsichtlich der Inanspruchnahme und/oder des gleichzeitigen Zugriffs drohen dem Servicekonsumenten zusätzliche Kosten und daher unvorhersehbare geschäftliche Auswirkungen. Aufgrund der festen codierten Zwischenspeicherungsstrategie des Zähl-Handlers kann der Serviceanbieter das Zwischenspeichern der Zählereignisanforderungen nicht an die Bedürfnisse der einzelnen Verträge anpassen. Die dem Stand der Technik entsprechende Patentschrift EP 1 202 528 von Stevens et al. vom 02.05.2002 offenbart eine Berichtsstruktur, die Berichte über Nutzungsmessungen liefern kann, entweder auf einer Echtzeitbasis oder auf der Basis einer stapelweisen Speicherung/Weiterleitung.
Aufgabe der Erfindung
Aufgabe der vorliegenden Erfindung ist die Bereitstellung eines verbesserten Nutzungsverfahrens und -systems, mit denen die oben erwähnten Nachteile überwunden werden.
Überblick über die Erfindung
Die oben erwähnte Aufgabe wird durch ein Verfahren und System wie in den Hauptansprüchen dargelegt gelöst. Weitere vorteilhafte Ausführungsarten der vorliegenden Erfindung sind in den Unteransprüchen beschrieben und in der nachfolgenden Beschreibung erläutert.
Das Nutzungsverfahren und -system nutzen mindestens einen Parameter, der definiert, ob und wie viele der Serviceanforderung zugeordnete Zählereignisanforderungen im Cache-Speicher gespeichert werden dürfen. Beispielsweise kann ein Boolescher Parameter definieren, ob eine bestimmte Zählereignisanforderung oder ein dieser Anforderung zugeordnetes Signal generell im Cache-Speicher gespeichert werden darf. Des Weiteren kann ein dem Booleschen Parameter zugeordneter Ganzzahlparameter definieren, wie viele dieser bestimmten Zählereignisanforderungen oder der diesen Anforderungen zugeordneten Signale im Cache-Speicher gespeichert werden dürfen. Gemäß einem weiteren Beispiel können der Boolesche Parameter und der Ganzzahlparameter in einem einzigen Parameter bereitgestellt werden.
Vorzugsweise kann in dem Zählsystem ein Serviceaufrufzähler für jeden angebotenen Service implementiert sein. Dieser Zähler gibt den aktuellen Aufrufstatus eines gegebenen Service wieder, wie er in der Datenbank gespeichert ist.
Kurzbeschreibung der Zeichnungen
Die oben erwähnte sowie weitere Aufgaben, Merkmale und Vorteile der vorliegenden Erfindung sind aus der nachfolgenden detaillierten schriftlichen Beschreibung ersichtlich.
Die neuartigen Merkmale der Erfindung sind in den beigefügten Ansprüchen dargestellt. Die Erfindung selbst und deren Vorteile werden am besten anhand der nachfolgenden detaillierten Beschreibung bevorzugter Ausführungsarten in Verbindung mit den beigefügten Zeichnungen verständlich. Es zeigen:
1 den Datenfluss einer bevorzugten Ausführungsart des Verfahrens gemäß der vorliegenden Erfindung;
2 eine schematische Darstellung einer bevorzugten Ausführungsart des Systems gemäß der vorliegenden Erfindung;
3 eine schematische Darstellung einer ersten Anwendung des Systems gemäß der vorliegenden Erfindung;
4 eine detaillierte Darstellung der ersten Anwendung des Systems gemäß der vorliegenden Erfindung;
5 eine schematische Darstellung einer zweiten Anwendung des Systems gemäß der vorliegenden Erfindung;
6 eine detaillierte Darstellung der zweiten Anwendung des Systems gemäß der vorliegenden Erfindung.
Detaillierte Beschreibung der Erfindung
1 zeigt ein Datenflussdiagramm eines Lizenzvertrag-Validierungsverfahrens gemäß einer bevorzugten Ausführungsart der vorliegenden Erfindung.
In einem ersten Schritt 20 werden die relevanten Informationen von einem Nachrichtenkontext abgetrennt. Der Nachrichtenkontext wurde aus der Serviceanforderungsnachricht eines Servicekonsumenten extrahiert. Der Nachrichtenkontext kann beispielsweise Serviceanforderungsinformationen, die Identität eines Servicekonsumenten, Vertrags- und Lizenzinhalt sowie relevante Parameter enthalten. In einem zweiten Schritt 22 wird eine Zählereignisanforderung erzeugt, die die Art des Zählereignisses und die relevanten Informationen aus dem Nachrichtenkontext enthält. Beispiele für Arten von Zählereignissen sind ein Zählstartereignis, ein Zählendeereignis, ein ad-hoc-Zählereignis und ein Abbruchzählereignis.
Der dritte Schritt 24 bewertet den Status eines Parameters CEP (Cache Enable Parameter). Der CEP ist ein Boolescher Parameter mit den zwei Stati WAHR und FALSCH. Der CEP ist im Lizenzvertrag enthalten und definiert, ob die Zählereignisanforderung in einem dedizierten Cache-Speicher gespeichert werden darf oder nicht.
Hat der CEP im Schritt 24 den Wert FALSCH, d. h. die Zählereignisanforderung darf nicht in dem dedizierten zugeordneten Cache-Speicher gespeichert werden, wird die Zählereignisanforderung gemäß Schritt 25 direkt an den Zählservice übergeben.
Hat der CEP im Schritt 24 den Wert WAHR, wird die Zählereignisanforderung weitergeleitet, um einen nächsten Schritt 26 durchzuführen. Im nächsten Schritt 26 wird ein Parameter CFP (Cache Flush Parameter, Cache-Leerungsparameter) bewertet und mit der Anzahl von Zählereignisanforderungen in dem dedizierten Cache-Speicher verglichen. Der CFP ist ein Ganzzahlparameter und definiert die maximale Anzahl von Zählereignisanforderungen, die in dem dedizierten Cache-Speicher gespeichert werden dürfen.
Wenn im Schritt 26 die Anzahl von Zählereignisanforderungen in dem dedizierten Cache-Speicher kleiner als die durch CFP angegebene Anzahl ist, wird die Zählereignisanforderung im Schritt 27 in dem dedizierten Cache-Speicher gespeichert.
Wenn im Schritt 26 die Anzahl von Zählereignisanforderungen in dem dedizierten Cache-Speicher gleich der durch CFP angegebenen Anzahl ist, werden alle Zählereignisanforderungen gemäß Schritt 28 vom Cache-Speicher zur Zählservice-Aufrufeinheit übertragen. Schließlich wird der Inhalt des Cache-Speichers gemäß Schritt 30 gelöscht.
Der dedizierte Cache-Speicher ist vorgesehen, um die erzeugte Zählereignisanforderung zeitweise zu speichern. Die Parameter CEP und CFP verhindern, dass zu viele Zählereignisanforderungen im Cache-Speicher gespeichert werden. Mittels dieses Verfahrens kann die durch den CFP definierte maximale Anzahl von Zählereignisanforderungen in dem dedizierten Cache-Speicher nicht überschritten werden.
Die Zählservice-Aufrufeinheit empfängt die Zählereignisanforderungen und ruft einen Zählservice auf, um die Zählereignisanforderungen zu verarbeiten.
Alternativ dazu können der CEP und der CFP als ein einziger Parameter vorgesehen sein. Dieser einzige Parameter kann eine Ganzzahl sein, die die maximale Anzahl von Zählereignisanforderungen im Cache-Speicher festlegt. Der Boolesche Status FALSCH kann durch den Wert null und der Boolesche Status WAHR durch einen beliebigen positiven Ganzzahlwert repräsentiert sein. Dieser einzige Parameter kann ebenfalls im Lizenzvertrag enthalten sein.
2 zeigt ein schematisches Diagramm einer bevorzugten Ausführungsart eines Lizenzvertrag-Validierungssystems gemäß der vorliegenden Erfindung. Das Lizenzvertrag-Validierungssystem ist als ein Zähl-Handler 50 realisiert. Die Komponenten des Zähl-Handlers 50 sind vorgesehen, um das Verfahren gemäß dem Datenflussdiagramm in 1 durchzuführen.
Der Zähl-Handler 50 umfasst eine Eingangseinheit 59, einen Nachrichtenkontexttrenner 60, einen Zählereignisgenerator 62, eine Cache-Freigabeeinheit 64, einen Cache-Controller 66 mit einer integrierten CFP-Überwachungseinheit 68, einen Cache-Speicher 70 und eine Zählservice-Aufrufeinheit 72.
Die Eingangseinheit 59, der Nachrichtenkontexttrenner 60, der Zählereignisgenerator 62 und die Cache-Freigabeeinheit 64 sind in Reihe geschaltet. Die Cache-Freigabeeinheit 64 umfasst zwei Ausgänge. Der erste Ausgang der Cache-Freigabeeinheit 64 ist mit dem Cache-Controller 66 verbunden. Der zweite Ausgang der Cache- Freigabeeinheit 64 ist mit der Zählservice-Aufrufeinheit 72 verbunden. Die CFP-Überwachungseinheit 68 ist in den Cache-Controller 66 integriert. Der Cache-Controller 66 ist bidirektional mit dem Cache-Speicher 70 verbunden. Des Weiteren ist der Cache-Controller 66 mit der Zählservice-Aufrufeinheit 72 verbunden.
Die Eingangseinheit 59 empfängt eine Serviceanforderungsnachricht von einem Servicekonsumenten. Der Nachrichtenkontexttrenner 60 trennt die relevanten Informationen, beispielsweise die Serviceanforderungsinformationen, Identität des Servicekonsumenten, Vertrags- und Lizenzinhalt, vom Nachrichtenkontext ab und leitet diese Informationen zum Zählereignisgenerator 62 weiter. Wenn der Web-Service durch den Serviceanbieter aufgerufen wird, leitet der Nachrichtenkontexttrenner 60 zur sofortigen Ausführung des angeforderten Web-Service den Nachrichteninhalt außerdem an einen Service-Handler 56 weiter.
Der Zählereignisgenerator 62 erzeugt eine Zählereignisanforderung, die die Art des Zählereignisses und die Informationen aus dem Nachrichtenkontext enthält. Je nach Status der Web-Serviceanforderung sind ein Zählstartereignis, Zählendeereignis, ein Aufrufzählereignis („ad-hoc"-Ereignis) oder ein Abbruchzählereignis Beispiele für Zählereignisarten.
Die Cache-Freigabeeinheit 64 bewertet den Status des CEP. Ist der CEP WAHR, wird die Zählereignisanforderung zum Cache-Controller 66 weitergeleitet. Ist der CEP FALSCH, wird die Zählereignisanforderung direkt an die die Zählservice-Aufrufeinheit 72 übergeben.
Der Cache-Controller 66 empfängt die erzeugte Zählereignisanforderung von der Cache-Freigabeeinheit 64. Die maximale Anzahl von Zählereignisanforderungen, die im Cache-Speicher 70 gespeichert werden darf, ist durch den CFP festgelegt. Der Cache-Speicher 70 speichert diese Zählereignisanforderungen zeitweise. Vorzugsweise besteht der Cache-Speicher 70 physisch aus einem Bereich des RAM-Speichers. Die CFP-Überwachungseinheit 68 überwacht die Anzahl von im Cache-Speicher 70 gespeicherten Zählereignisanforderungen und achtet darauf, dass die durch den CFP definierte maximale Anzahl nicht überschritten wird. Wenn die Anzahl von Zählereignisanforderungen im Cache-Speicher 70 der durch den CFP festgelegten Anzahl entspricht, überträgt der Cache-Controller 66 alle Zählereignisanforderungen zur Zählservice-Aufrufeinheit 72 und löscht abschließend den Inhalt des Cache-Speichers 70. Die Zählservice-Aufrufeinheit 72 sendet alle Zählereignisanforderungen an einen Zählservice, der nicht notwendigerweise eine Komponente des Zähl-Handlers 50 ist.
Das Zwischenspeichern der Zählereignisanforderungen ist vorteilhaft, da der Aufruf des Zählservice langsam ausgeführt wird und erhebliche Netzwerkressourcen erfordert. Die langsame Ausführung des Aufrufs des Zählservice wird in der Hauptsache durch die Transaktionszeit des Netzes verursacht. Die Transaktionszeit ist die Zeit, die zum Übertragen der Anforderung an den Zählservice und Empfangen der Antwort benötigt wird. Die langsame Ausführung wird des Weiteren durch das Verarbeiten von Nachrichten, beispielsweise durch das Codieren und Decodieren von Nachrichten, und durch die Zeit verursacht, die der Zählservice für die Ausführung benötigt.
Die Einführung von CEP und CFP ermöglicht den Vertragsparteien, das Validierungsverfahren für Lizenzverträge an ihre speziellen Anforderungen anzupassen. Die Deaktivierung des CEP, d. h. der Status FALSCH, deaktiviert alle Zwischenspeicherungsfunktionen des Zähl-Handlers 50. Dies gewährleistet, dass der Zählservice und dessen Datenbank den wirklichen Status der Nutzung des Web-Service wiedergeben. Dies ermöglicht Serviceanbietern sowie Servicekonsumenten, sicherzustellen, dass High-Value-Web-Serviceanforderungen keinesfalls die Werte einer kumulativen oder konsumtiven Lizenzvertragsgrenze überschreiten. Dadurch wird die Gefahr vermieden, geplante Budgetgrenzen zu überziehen.
Wenn ein Servicekonsument viele Low-Value-Web-Services anfordert, wird durch die Freigabe des CEP die volle Systemleistung bereitgestellt, obwohl die Gefahr unkontrollierter Budgetüberziehungen durch Definieren eines angemessenen CFP begrenzt wird.
Ein Serviceanbieter kann einen Lizenzvertrag, der einem bestimmten Web-Service zugeordnet ist, je nach der Definition von CEP und CFP im Lizenzvertrag zu unterschiedlichen Preisen anbieten, da die Einstellung dieser Parameter die Kosten für Netzverkehr und -ressourcen beeinflusst.
Die 3 bis 6 veranschaulichen zwei unterschiedliche Anwendungen, bei denen der Zähl-Handler 50 integriert ist. Diese zwei Anwendungen sind sowohl schematisch als auch im Detail dargestellt.
3 zeigt eine schematische Darstellung der ersten Anwendung. 3 veranschaulicht das Zusammenwirken und die Verbindung zwischen dem Servicekonsumenten 32, einem Servicelieferanten 34 und dem Serviceanbieter 36. Der Servicekonsument 32 fordert einen vom Servicelieferanten 34 bereitgestellten Web-Service an. Der Servicelieferant 34 nutzt einen Serviceanbieter 36, um die Identität des Servicekonsumenten 32 und die Gültigkeit des Lizenzvertrags zu validieren und um die Serviceausführung zu messen.
Die Reihenfolge der Interaktionen zwischen dem Servicekonsumenten 32, dem Servicelieferanten 34 und dem Serviceanbieter 36 ist nachfolgend beschrieben. Die Interaktionen sind durch die Pfeile 1 bis 5 dargestellt. Der Servicekonsument 32 löst 1 eine Serviceanforderung aus, um einen Web-Service aufzurufen, der durch einen Servicelieferanten 34 bereitgestellt wird. Der Servicelieferant 34 empfängt die Anforderung und sendet 2 eine Serviceanforderung an den Serviceanbieter 36, um die vom Serviceanbieter 36 bereitgestellten Vertragsabschlusssystem- und Infrastrukturservices zu nutzen. Der Serviceanbieter 36 führt die angeforderten Vertragsabschluss- und Infrastrukturservices durch, beispielsweise überprüft er die Identität des Servicekonsumenten, bestätigt, dass ein Lizenzvertrag zur Verfügung steht, löst ein Zählereignis aus und gibt 3 den Status an den Servicelieferanten 34 zurück. Der Servicelieferant 34 führt den angeforderten Service durch und ruft 4 den Serviceanbieter 36 auf, um die entsprechenden Zählereignisse zu erzeugen. Der Servicelieferant 34 sendet 5 resultierende Servicedaten an den Servicekonsumenten.
4 zeigt im Detail die Komponenten des Serviceanbieters 36 gemäß 3. Der Serviceanbieter 36 ist gemäß 3 mit dem Servicelieferanten 34 gekoppelt. Der Serviceanbieter 36 umfasst eine Schnittstelle 40, bei der es sich um eine serverseitige Schnittstelle des Web-Service handelt, einen Profil-Handler 42, einen Vertrags-Handler 46 und den Zähl-Handler 50 gemäß 2. Der Serviceanbieter 36 ist mit einem Profilservice 44, einem Vertragsservice 48 und einem Zählservice 52 gekoppelt. Der Profilservice 44, der Vertragsservice 48 und der Zählservice 52 können externe Serverkomponenten sein. Des Weiteren sind der Vertragsservice 48 und der Zählservice 52 mit einer Lizenzüberprüfungskomponente 54 verbunden, die ebenfalls eine externe Serverkomponente sein kann.
Die Schnittstelle 40 ist direkt mit dem Servicelieferant 34 gekoppelt. Der Profil-Handler 42 verwendet den Profilservice 44, um die Identität des Servicekonsumenten 32 zu überprüfen. Der Vertrags-Handler 46 verwendet den Vertragsservice 48 und die Lizenzüberprüfungskomponente 54, um Vertragszustände und anwendbare Lizenzrichtlinien zu überprüfen. Der Zähl-Handler 50 erzeugt entsprechende Zählereignisse, wie Startereignisse, Endeereignisse, ad-hoc-Ereignisse und/oder Abbruchereignisse. Der Profilservice 44 sorgt für die Identitätskontrolle. Der Vertragsservice 48 überprüft die Existenz eines gültigen Vertrags. Er enthält eine Lizenzierungskomponente, die gewährleistet, dass die Serviceanforderung definierte Lizenzrichtlinien einhält. Der Zählservice 52 erzeugt und speichert Zählereignisse.
Die Interaktionen zwischen diesen Komponenten sind nachfolgend beschrieben. Die Schnittstelle 40 empfängt die durch den Servicelieferanten 34 ausgelöste Serviceanforderung, extrahiert den Nachrichtenkontext und gibt diesen an nachfolgende Handler weiter. Die Handler erweitern und/oder modifizieren den Nachrichtenkontext und reichen diesen an den nächsten Handler in der Kette weiter. Der Profil-Handler 42 löst eine Serviceanforderung an den Profilservice 44 aus, um die Identität des Servicelieferanten 34 zu prüfen. Der Profilservice 44 gibt das Ergebnis der Identitätsprüfung an den Profil-Handler 42 zurück. Der Vertrags-Handler 46 ruft den Vertragsservice 48 auf, um einen entsprechenden Vertrag zu identifizieren und zu validieren. Die Lizenzüberprüfungskomponente 54 prüft, ob die im Vertrag definierten Lizenzrichtlinien eingehalten sind. Die Lizenzüberprüfungskomponente 54 verwendet zu diesem Zweck aktuelle oder historische Verwendungsdaten aus dem Zählservice 52. Der Vertragsservice 48 gibt den Lizenzvertragszustand, das Validierungsergebnis und relevante Vertragsdaten an den Vertrags-Handler 46 zurück. Der Vertrags-Handler 46 vervollständigt den Nachrichtenkontext und gibt diesen an den Zähl-Handler 50 weiter. Der Zähl-Handler 50 ruft den Zählservice 52 auf, um Zählereignisse zu erzeugen, die den Status der Serviceanforderung wiedergeben. Der Zählservice 52 benachrichtigt die Lizenzkomponente über die Verwendung des Web-Service. Die Lizenzüberprüfungskomponente 54 verwendet diese Information zur Validierung bestimmter Lizenzrichtlinien, beispielsweise der konsumtiven oder gleichzeitigen Lizenzverwendung. Der Zähl-Handler 50 gibt den aktualisierten Nachrichtenkontext an die Schnittstelle 40 zurück. Die Schnittstelle 40 gibt die Validierungsergebnisse an den Servicelieferanten 34 zurück.
Der Zählservice 52 erzeugt aus den Zählereignisanforderungen Zählereignisse, speichert diese in einer Datenbank und benachrichtigt die Lizenzvalidierungskomponente eines Vertragsservice über den aktualisierten Status der Datenbank. Die Zählereignisanforderungen werden durch die Zählservice-Aufrufeinheit 72 des Zähl-Handlers 50 gesendet.
Des Weiteren ist in der Lizenzvalidierungskomponente 54 ein Serviceaufrufzähler für jeden angebotenen Lizenzvertrag implementiert. Jeder Zähler repräsentiert den Aufrufstatus eines angebotenen Web-Service, wie er in der Datenbank des Zählservice gespeichert ist. Die Lizenzkomponente wird jedes Mal vom Zählservice benachrichtigt, wenn der Zählservice seine Datenbank mit neu erzeugten Zählereignissen aktualisiert. Die Lizenzkomponente inkrementiert ihre Zähler entsprechend. Der Vertragsservice 48 verwendet diese Zähler, um zu überprüfen, ob eine festgelegte Lizenzbedingung überschritten wird, wenn eine Serviceanforderung eintrifft.
5 zeigt eine schematische Darstellung einer zweiten Anwendung. 5 veranschaulicht die Interaktion und die Verbindung zwischen dem Servicekonsumenten 32, dem Servicelieferanten 34 und einem Serviceanbieter 38. Der Serviceanbieter 38 bietet dem Servicekonsumenten 32 den Web-Service an. Um die Serviceanforderung zu erfüllen, fordert der Serviceanbieter 38 den Web-Service vom Servicelieferanten 34 an.
Dies erfordert die nachstehende Abfolge von Interaktionen, die durch die Pfeile 6 bis 9 dargestellt sind. Der Servicekonsument 32 fordert 6 einen vom Serviceanbieter 38 angebotenen Web-Service an. Der Serviceanbieter 38 überprüft die Identität des Servicekonsumenten 32, bestätigt, dass ein Lizenzvertrag zur Verfügung steht und verwendbar ist, löst ein Zählereignis aus und ruft 7 den angeforderten Web-Service auf, der vom Servicelieferant 34 bereitgestellt wird. Der Servicelieferant 34 führt den angeforderten Service aus und gibt 8 das Ergebnis an den Serviceanbieter 38 zurück. Der Serviceanbieter 38 erzeugt ein oder mehrere entsprechende Zählereignisse und gibt 9 das Ergebnis des Web-Service an den Servicekonsumenten 32 zurück.
6 zeigt die Komponenten des Serviceanbieters 38 und die Abfolge ihrer Aufrufe im Detail. Der Serviceanbieter 38 umfasst ebenso wie der Serviceanbieter 36 in 4 die Schnittstelle 40, bei der es sich um eine serverseitige Schnittstelle des Web-Service handelt, den Profil-Handler 42, den Vertrags-Handler 46 und den Zähl-Handler 50. Zusätzlich umfasst der Serviceanbieter 38 einen Service-Handler 56. Der Service-Handler 56 ist mit einem kommerziellen Web-Service 58 gekoppelt. Der kommerzielle Web-Service 58 ist eine externe Serverkomponente, die durch den Servicelieferanten 34 bereitgestellt wird, um den angeforderten Service zu erfüllen.
Der Profil-Handler 42, der Vertrags-Handler 46 und der Zähl-Handler 50 sind in derselben Weise wie in 4 mit dem Profilservice 44, dem Vertragsservice 48 bzw. dem Zählservice 52 verbunden. Der Profilservice 44 kann eine externe Serverkomponente sein, die für die Identitätsprüfung sorgt. Der Vertragsservice 48 kann eine externe Serverkomponente sein, welche die Existenz eines gültigen Vertrags überprüft. Der Service enthält eine Lizenzierungskomponente, die gewährleistet, dass die Serviceanforderung festgelegte Lizenzrichtlinien einhält. Der Zählservice 52 kann eine externe Serverkomponente sein, welche die Zählereignisse erzeugt und speichert.
Die Interaktionen zwischen den funktionellen Komponenten des Serviceanbieters werden nachfolgend beschrieben. Die Schnittstelle 40 empfängt die durch einen Servicekonsumenten 32 ausgelöste Serviceanforderung, extrahiert den Nachrichtenkontext und gibt diesen an nachfolgende Handler weiter. Die Handler erweitern und/oder modifizieren den Nachrichtenkontext und geben diesen an den nächsten Handler in der Kette weiter. Der Profil-Handler 42 löst eine Serviceanforderung an den Profilservice 44 aus, um die Identität des Servicelieferanten 34 zu prüfen. Der Profilservice 44 gibt das Ergebnis der Identitätsprüfung an den Profil-Handler 42 zurück. Der Vertrags-Handler 46 ruft den Vertragsservice 48 auf, um einen entsprechenden Vertrag zu identifizieren und zu validieren. Die Lizenzüberprüfungskomponente 54 prüft, ob die im Vertrag festgelegten Lizenzrichtlinien eingehalten sind. Die Lizenzüberprüfungskomponente 54 verwendet zu diesem Zweck aktuelle oder historische Verwendungsdaten vom Zählservice 52. Der Vertragsservice 48 gibt 6 den Lizenzvertragszustand, das Validierungsergebnis und relevante Vertragsdaten an den Vertrags-Handler 46 zurück. Der Vertrags-Handler 46 vervollständigt den Nachrichtenkontext und gibt diesen an den Zähl-Handler 50 weiter, bei dem es sich um den nächsten Handler in der Kette handelt. Der Zähl-Handler 50 ruft den Zählservice 52 auf, um Zählereignisse zu erzeugen, die den Status der Web-Serviceanforderung wiedergeben, beispielsweise erfolgreich beendet oder abgebrochen. Der Zählservice 52 benachrichtigt die Lizenzkomponente über die Verwendung des Web-Service. Die Lizenzüberprüfungskomponente 54 verwendet diese Information zur Validierung bestimmter Lizenzrichtlinien, beispielsweise der konsumtiven oder gleichzeitigen Lizenzverwendung. Der Service-Handler 56 ruft den angeforderten Web-Service auf und aktualisiert den Nachrichtenkontext mit den resultierenden Serviceantworten. Der Zähl-Handler 50 gibt 10 den aktualisierten Nachrichtenkontext an die Schnittstelle 40 zurück. Die Schnittstelle 40 gibt das Ergebnis des anfänglichen Aufrufs an den Servicekonsumenten 32 zurück.
Des Weiteren sind in der Lizenzüberprüfungskomponente 54 Serviceaufrufzähler implementiert. Für jeden angebotenen Lizenzvertrag ist ein Serviceaufrufzähler vorgesehen. Jeder Serviceaufrufzähler repräsentiert den Aufrufstatus eines angebotenen Web-Service, wie er in der Datenbank des Zählservice gespeichert ist. Die Lizenzkomponente wird jedes Mal vom Zählservice benachrichtigt, wenn der Zählservice seine Datenbank mit neu erzeugten Zählereignissen aktualisiert. Die Lizenzkomponente inkrementiert diese Zähler entsprechend. Der Vertragsservice verwendet diese Zähler, um zu überprüfen, ob eine festgelegte Lizenzbedingung überschritten wird, wenn eine Serviceanforderung eintrifft.
Die Einführung der Serviceaufrufzähler in die Lizenzkomponente des Vertragsservice reduziert außerdem die Netzverkehrskosten in hohem Maße, da nur dann Serviceverkehr zwischen dem Zählservice 52 und der Lizenzüberprüfungskomponente 54 erzeugt wird, wenn die Datenbank aktualisiert wurde. Die Serviceaufrufzähler vermeiden hohe Netzkosten.
Die folgenden Beispiele veranschaulichen die Vorteile der Erfindung.
Beispiel 1
Gemäß einem ersten Beispiel muss der Servicekonsument 32 auf der Grundlage eines konsumtiven Lizenzvertrags, in dem ein Limit von maximal fünf Zuordnungen für diesen Vertragspartner festgelegt ist, für einen Zeitrahmen von einer Woche Server-Hardware von einem Servicelieferanten 34 zuordnen. Da es sich hierbei um eine High-Value-Serviceanforderung handelt, möchte der Servicekonsument 32 sicherstellen, dass diese Grenze, beispielsweise 5, nicht überschritten wird. Daher verwendet er einen Lizenzvertrag, der den CEP deaktiviert. In diesem Fall geben die Zählereignisdatenbank und anschließend der entsprechende Serviceaufrufzähler der Lizenzvalidierungskomponente stets den aktuellen Status des Serviceaufrufs wieder, wodurch die Gefahr beseitigt ist, dass die Grenzen des Lizenzvertrages überschritten werden.
Beispiel 2
Gemäß einem zweiten Beispiel führt der Servicekonsument 32 Anwendungen in einer Grid-Computing-Umgebung aus. Um bei auftretenden Lastspitzen Speicher dynamisch zuzuordnen, führt er diese Anwendungen unter einem konsumtiven Lizenzvertrag aus, den er mit einem Speicherlieferanten abgeschlossen hat. Da die Zuordnung zusätzlichen Speichers als Low-Value-Service gilt, der jedoch häufig aufgerufen wird, wurde der Lizenzvertrag auf der Grundlage der vorausberechneten maximalen Zuordnung ausgelegt, lässt jedoch in einem gewissen Umfang das Überschreiten dieses Grenzwerts durch Freigeben des CEP und Definieren eines angemessenen CFP zu. Dies gewährleistet, dass die Speicherzuordnung fortgesetzt wird, selbst wenn die Obergrenze zeitweise überschritten ist. Daher werden Operationen des Servicekonsumenten nicht unterbrochen, während gleichzeitig die Gefahr eingeschränkt ist, dass mit Zusatzkosten verbundene Zielwerte überschritten werden.
Beispiel 3
Gemäß einem dritten Beispiel bietet der Serviceanbieter 38 eine Geschäftsanwendung als Web-Service zu unterschiedlichen Klassifizierungs- und/oder Preiskonditionen an. Die entsprechenden Lizenzverträge unterscheiden sich in den Werten für CEP und CFP, da diese Parameter die Kosten stark beeinflussen, zu denen der Serviceanbieter 38 den Web-Service anbieten kann. Dies ermöglicht dem Serviceanbieter 38, seinen Web-Service je nach seinem Risiko bei der Kalkulation der entsprechenden Bereitstellungskosten mit unterschiedlichen Preiskennzeichnungen anzubieten.
Das System gemäß der vorliegenden Erfindung kann in Hardware, Software oder einer Kombination von Hardware und Software realisiert werden.
Die vorliegende Erfindung kann außerdem in ein Computerprogrammprodukt eingebettet sein, das alle Merkmale zum Ermöglichen der Implementierung der hierin beschriebenen Verfahren umfasst. Des Weiteren ist das Computerprogrammprodukt, wenn es in ein Computersystem geladen wurde, in der Lage, diese Verfahren auszuführen.
Obwohl die hierin beschriebene Erfindung hauptsächlich Web-Services betrifft, ist die Erfindung des Weiteren auf beliebige Services in jeder Art von Kommunikationsnetz anwendbar.

20: Schritt des Trennens von Daten aus dem Nachrichtenkontext
22: Schritt des Erzeugens einer Zählereignisanforderung
24: Schritt des Bewertens des Booleschen Parameters
25: Schritt des Sendens einer Zählereignisanforderung an den Zähl-Webservice
26: Schritt des Bewertens des Ganzzahlparameters
27: Schritt des Speicherns einer Zählereignisanforderung im Cache-Speicher
28: Schritt des Sendens einer Zählereignisanforderung und zwischengespeicherter Zählereignisanforderungen an den Zählservice
30: Schritt des Löschens des Cache-Speichers
32: Servicekonsument
34: Servicelieferant
36: Serviceanbieter
38: Serviceanbieter
40: Schnittstelle
42: Profil-Handler
44: Profilservice
46: Vertrags-Handler
48: Vertragsservice
50: Zähl-Handler
52: Zählservice
54: Lizenzüberprüfungskomponente
56: Service-Handler
58: Kommerzieller Web-Service
59: Eingangseinheit
60: Nachrichtenkontexttrenner
62: Zählereignisgenerator
64: Cache-Freigabeeinheit
66: Cache-Controller
68: CFP-Überwachungseinheit
70: Cache-Speicher
72: Zählservice-Aufrufeinheit

Claims

Nutzungsverfahren in einem Kommunikationsnetz, das mindestens einen Serviceanbieter (36; 38) und mindestens einen Servicekonsumenten (32) umfasst, bei dem der Serviceanbieter (36; 38) Services für den Servicekonsumenten (32) bereitstellt, wobei das Verfahren die folgenden Schritte umfasst: a) Empfangen einer Serviceanforderungsnachricht vom Servicekonsumenten (32); b) Erzeugen einer dieser Serviceanforderung zugeordneten Zählereignisanforderung; c) Vergleichen des aktuellen Inhalts eines Cache-Speichers (70) mit mindestens einem Parameter (CEP, CFP); d) Speichern der Zählereignisanforderung im Cache-Speicher (70), wenn dies, abhängig von diesem Vergleich, zulässig ist; oder e) Senden der Zählereignisanforderung und des Inhalts des Cache-Speichers (70) an einen Zählservice (52), um die Zählereignisanforderungen zu verarbeiten, wenn die Zählereignisanforderung, abhängig von diesem Vergleich, nicht im Cache-Speicher (70) gespeichert werden darf; dadurch gekennzeichnet, dass der mindestens eine Parameter (CEP; CFP) der Serviceanforderung und einer vordefinierten Konvention zugeordnet ist und dieser Parameter (CEP; CFP) definiert, ob und wie viele Zählereignisanforderungen im Cache-Speicher (70) gespeichert werden dürfen.
Verfahren nach Anspruch 1, bei dem der Schritt c) den folgenden Schritt umfasst: Bewerten eines Status eines Booleschen Parameters (CEP), der anzeigt, ob die Zählereignisanforderung im Cache-Speicher (70) gespeichert werden darf oder nicht.
Verfahren nach Anspruch 2, bei dem der Schritt c) des Weiteren die folgenden Schritte umfasst, wenn die Zählereignisanforderung im Cache-Speicher (70) gespeichert werden darf: – Bewerten eines Wertes eines Ganzzahlparameters (CFP), der dem Booleschen Parameter (CEP) zugeordnet ist; und – Vergleichen dieses Wertes des Ganzzahlparameters (CFP) mit dem Inhalt des Cache-Speichers (70).
Verfahren nach Anspruch 3, bei dem der Schritt e) die folgenden Schritte umfasst, wenn die aktuelle Anzahl der Zählereignisanforderungen im Cache-Speicher (70) gleich dem oder größer als der Wert des Ganzzahlparameters (CFP) ist: – Senden der Zählereignisanforderung an den Zählservice (52), um die Zählereignisanforderung zu verarbeiten; und – Löschen des Inhalts des Cache-Speichers (70).
Verfahren nach Anspruch 3, bei dem die Zählereignisanforderung im Cache-Speicher (70) gespeichert wird, wenn die aktuelle Anzahl der Zählereignisanforderungen im Cache-Speicher (70) kleiner als dieser Wert des Ganzzahlparameters (CFP) ist.
Verfahren nach einem der vorhergehenden Ansprüche, bei dem die Konvention in einem Lizenzvertrag vordefiniert ist, der die Arten und den Umfang von Services zwischen dem Serviceanbieter (36; 38) und dem Servicekonsumenten (32) betrifft.
Verfahren nach einem der vorhergehenden Ansprüche, bei dem nach dem Empfangen der Serviceanforderungsnachricht relevante Informationen aus der Serviceanforderungsnachricht abgetrennt werden.
Verfahren nach Anspruch 7, bei dem die relevanten Informationen der Serviceanforderungsnachricht Anforderungsdaten, Vertragsdaten, Lizenzdaten, den Booleschen Parameter (CEP), den Ganzzahlparameter (CFP) und/oder die Identität des Servicekonsumenten (32) umfassen.
Verfahren nach einem der vorhergehenden Ansprüche, wobei das Verfahren des Weiteren die folgenden Schritte umfasst: – Zählen der Services, wenn die zugeordnete Zählereignisanforderung an den Zählservice (52) gesendet wurde; und – Senden der aktuellen Zählergebnisse an den Serviceanbieter (36; 38) und/oder den Servicekonsumenten (32).
Verfahren nach Anspruch 9, bei dem jede Art der angebotenen Services separat gezählt wird.
Verfahren nach einem der vorhergehenden Ansprüche, bei dem das Kommunikationsnetz ein zur Bereitstellung von Web-Services geeignetes Computernetz ist.
Verfahren nach einem der vorhergehenden Ansprüche, wobei dieses Verfahren ein Lizenzvertrag-Validierungsverfahren ist und wobei der Lizenzvertrag die Arten und den Umfang von Services zwischen dem Serviceanbieter (36; 38) und dem Servicekonsumenten (32) definiert.
Nutzungssystem für ein Kommunikationsnetz, das mindestens einen Serviceanbieter (36; 38) und mindestens einen Servicekonsumenten (32) umfasst, bei dem der Serviceanbieter (36; 38) eingerichtet ist, um Services für den Servicekonsumenten (32) bereitzustellen, wobei dieses System die folgenden Komponenten umfasst: – eine Eingangseinheit (59) zum Empfangen einer Serviceanforderungsnachricht vom Servicekonsumenten (32); – einen Generator (62) zum Erzeugen einer der Serviceanforderung zugeordneten Zählereignisanforderung; – einen Cache-Speicher (70) zum Speichern der Zählereignisanforderungen; – einen Cache-Controller (66) zum Steuern des Cache-Speichers (70); und – eine Aufrufeinheit (72) zum Senden der Zählereignisanforderungen an einen Zählservice (52), um die Zählereignisanforderungen zu verarbeiten; wobei dieses System eine Cache-Freigabeeinheit (64) zum Bewerten umfasst, ob überhaupt eine Zählereignisanforderung im Cache-Speicher (70) gespeichert werden darf, und dieses System dadurch gekennzeichnet ist, dass es eine Überwachungseinheit (68) zum Bewerten umfasst, ob und wie viele Zählereignisanforderungen, abhängig von mindestens einem der Anforderung zugeordneten Parameter (CEP; CFP) und einer vordefinierten Konvention, in einem Cache-Speicher (70) gespeichert werden dürfen.
System nach Anspruch 13, bei dem die Cache-Freigabeeinheit (64) zum Bewerten eines Status eines Booleschen Parameters (CEP) vorgesehen ist, der anzeigt, ob die Zählereignisanforderung im Cache-Speicher (70) gespeichert werden darf.
System nach Anspruch 13 oder 14, bei dem die Überwachungseinheit (68) zum Bewerten eines Status eines Ganzzahlparameters (CFP) vorgesehen ist, der anzeigt, wie viele Zählereignisanforderungen im Cache-Speicher (70) gespeichert werden dürfen.
System nach Anspruch 13, 14 oder 15, bei dem die Eingangseinheit (59) mit einem Nachrichtenkontexttrenner (60) zum Abtrennen der relevanten Informationen aus der Serviceanforderungsnachricht gekoppelt ist.
System nach einem der Ansprüche 13 bis 16, wobei das System einen Zähler zum zählen der angeforderten Services umfasst, wenn die zugeordnete Zählereignisanforderung an den Zählservice (52) gesendet worden ist.
System nach einem der Ansprüche 13 bis 17, wobei das System für ein Nutzungsverfahren nach einem der vorhergehenden Ansprüche 1 bis 12 vorgesehen ist.
System nach einem der Ansprüche 13 bis 18, wobei das System in Hardware, Software oder in einer Kombination aus Hardware und Software realisiert ist.
Computerprogrammprodukt, das auf einem computergeeigneten Medium gespeichert ist und computerlesbare Programmmittel umfasst, um zu bewirken, dass der Computer ein Verfahren nach einem der vorhergehenden Ansprüche 1 bis 12 durchführt, wenn diese Programmmittel auf einem Computer ausgeführt werden.