DE112011100619T5

DE112011100619T5 - Verfahren und system zur gemeinsamen nutzung von daten zwischen softwaresystemen

Info

Publication number: DE112011100619T5
Application number: DE112011100619T
Authority: DE
Inventors: Michael Monteith; Stephen Owens
Original assignee: Thoughtwire Holdings Corp
Current assignee: Thoughtwire Holdings Corp
Priority date: 2010-02-22
Filing date: 2011-01-17
Publication date: 2013-01-24
Also published as: US20110209138A1; DE112011100620T5; GB201216776D0; CA2788708C; US9501508B2; GB201116597D0; CA2727761C; GB2492684A; WO2011100849A1; CA2727761A1; US20120310900A1; CA2788708A1; US9244965B2; WO2011100836A1; GB2490372A

Abstract

Ein Verfahren und System zur gemeinsamen Nutzung von Daten zwischen Softwaresystemen wird bereitgestellt. Eine Graphen-Datenstruktur wird im Speicher eines Rechengeräts aufrechterhalten. Die Graphen-Datenstruktur weist Datenelemente und Beziehungen dazwischen auf, die semantisch beschrieben sind. Eine Anfrage, die von einem ersten Softwaresystem empfangen wurde, wird gespeichert. Die Anfrage ist für den Wert von angefragten Daten, die semantisch beschrieben sind, und eine Adresse, die durch das erste Softwaresystem deklariert wird. Die angefragten Daten werden semantisch in mindestens eines der Datenelemente in der Graphen-Datenstruktur zerlegt. Die Adresse wird angerufen und der Wert des einen Datenelements wird an das erste Softwaresystem weitergeleitet, wenn der Wert von einem der mindestens einen Datenelemente aktualisiert wird.

Description

Gebiet der Erfindung
Die vorliegende Erfindung betrifft im Allgemeinen Informationssysteme. Insbesondere betrifft die Erfindung ein Verfahren und System zur gemeinsamen Nutzung von Daten zwischen Softwaresystemen.
Hintergrund der Erfindung
Viel von dem, was die durchschnittliche Einzelperson als Arbeit, Lernen oder Spiel erfährt, wird durch ihre Wechselwirkungen mit Computern und Software bewerkstelligt. Milliardenmal mal am Tag wechselwirken hunderte Millionen Menschen mit Computern und Software bei ihren täglichen Beschäftigungen. Leute werden zunehmend mit der Herausforderung des Arbeitens mit mehreren unabhängigen Softwaresystemen konfrontiert, um alle von den alltäglichsten bis zu den kompliziertesten Aufgaben durchzuführen. Wie hier verwendet, bezieht sich ”Softwaresystem” auf eine oder mehrere Applikationen, Dienste, Firmware, ausgeführte Skripte, Middleware, Funktionalitätsätze, die über Web-Seiten verfügbar sind, etc., die Daten gemeinsam nutzen und/oder anfragen können. In vielen Fällen enthält kein einziges Softwaresystem sämtliche erforderliche Information oder Funktionalität und es ist häufig die Arbeit des Einzelnen als der Verbindungspunkt unter den Softwaresystemen zu wirken, die verwendet werden.
Der Mangel an Integration zwischen den meisten Softwaresystemen bedeutet, dass der Anwender mit der komplexen, zeitaufwändigen und fehleranfälligen Aufgabe belastet wird, mit jedem Softwaresystem einzeln zu interagieren und zu versuchen, eine koordinierte Aufgabe zwischen ihnen durchzuführen. Sie verschwenden wertvolle Zeit beim Kopieren und Einfügen und erneutem Eingeben von Information, beim Umschalten zwischen den Applikationen und einzelnen Web-Seiten, die sie benutzen müssen, während sie zur gleichen Zeit versuchen, sich an die Information zu erinnern, die sie von einer Applikation erhalten haben, die in die nächste Applikation eingegeben werden muss.
Ob es eine Person betrifft, die versucht, dass Internet zu benutzen, um ihren Traumurlaub zu recherchieren und zu arrangieren, einen Mitarbeiter in einer Kundendienstabteilung, der versucht, ein Problem zu lösen, oder einen Arzt in einer Notaufnahme, der versucht schnell auf sämtliche über seinen Patienten verfügbare Information zuzugreifen, überall dort taucht das Problem auf, wo Menschen Softwaresysteme während ihres Tages verwenden. Die Wirkungen des Problems sind universell und weitreichend, wobei individuelle Produktivität, Kosten, Qualität der Arbeit und Zufriedenheit negativ beeinflusst werden. Insgesamt sind die Implikationen Schwindel erregend und stellen eine unerschlossene potentielle Quelle für Verbesserungen in fast jeder Industrie dar.
In manchen Fällen wurden Softwaresysteme integriert, um eine gemeinsame Nutzung von Daten zwischen ihnen zu ermöglichen. Systemintegration wurde herkömmlicherweise in einer Punkt-zu-Punkt-Art unter Verwendung von programmatischen Verbindungen zwischen den separaten Systemen in einem Aufruf/Antwort-Muster (invocation/response pattern durchgeführt. Gewöhnlicherweise wird die Verbindung über eine Applikationsprogrammierschnittstelle (”API”) hergestellt, die durch eines der zu integrierenden Softwaresysteme bereitgestellt wird. Da diese APIs typischerweise Softwaresystem-spezifisch sind, ist die Kenntnis von verschiedenen APIs im Allgemeinen erforderlich, wenn neue Softwaresysteme mit anderen integriert werden. Jedes Softwaresystem weist im Allgemeinen unterschiedliche Kennungen für Datenelemente auf, so dass von dem Integrator verlangt wird, Kenntnisse über die Datenelemente und Strukturen für jedes Softwaresystem aufzuweisen, mit dem eine Wechselwirkung stattfinden soll. Ferner müssen die Ereignisse für jedes integrierte Softwaresystem die Daten verstehen, die sich zwischen integrierten Softwaresystemen bewegen. Diese Ereignisse sind typischerweise kundenspezifisch und müssen den Ereignissen entsprechen, die in anderen Softwaresystemen auftreten. Beispiele von Ereignissen umfassen den Abschluss einer Datenbanktransaktion, das Erscheinen einer Datei in einem Verzeichnis oder das Erscheinen einer Nachricht in einer Warteschlange. Jedes dieser Ereignisse kann erfordern, dass es in etwas lokal Bedeutungsvolles für jedes integrierte Softwaresystem umgesetzt wird.
Integrationssysteme wurden entwickelt, um die Integration zwischen unterschiedlichen Softwaresystemen zu handhaben, diese Integrationssysteme können jedoch alle die gleichen Probleme aufweisen, wie sie angetroffen werden, wenn Softwaresysteme direkt integriert werden.
Punkt-zu-Punkt-Integrationen können für eine kleine Anzahl von Softwaresystemen mit relativ einfachen, gemeinsam zu nutzenden Daten annehmbar arbeiten. Aufgrund der Komplexität derartiger Integrationen sind sie im Allgemeinen für Unternehmenssysteme reserviert und werden serverseitig durchgeführt. Wenn die Wechselwirkung von jedem Softwaresystem mit jedem anderen Softwaresystem explizit programmiert wird, erfordert die Integration von jedem zusätzlichen Softwaresystem einen deutlich erhöhten Aufwand. Ein weiteres Problem besteht darin, dass es im Allgemeinen sehr schwierig für einen Dritten ist, die Integration zwischen Softwaresystemen zu verbessern.
Ein weiteres Problem besteht noch darin, dass Datenpersistenz in den meisten Integrationen nicht sehr gut gehandhabt wird. Während der Verarbeitung einer Transaktion wird, falls ein Softwaresystem, das für das Durchführen einer Aufgabe verantwortlich ist, nicht vorhanden ist, die Transaktion im Allgemeinen scheitern. Um Robustheit in derartige integrierte Softwaresysteme einzuführen, muss Ereignisbehandlung (event handling) als Ausfallsicherheit (failsafes) für verschiedene Szenarien hinzugefügt werden, was die Komplexität derartiger Integrationen weiter erhöht.
Serverseitige Integration wird sogar noch anspruchsvoller bei so vielen weit voneinander getrennten Softwaresystemen, die lediglich auf einem Rechengerät zusammen kommen, das von einem Endbenutzer und häufig auf einer Ad-hoc-Grundlage verwendet wird.
Eine Lösung, die für die gemeinsamen Nutzung von Daten durch Google vorgeschlagen und missbilligt wurde, kann bei http://code.google.com/apis/gadgets/docs/pubsub.html gefunden werden. Der Vorschlag beschreibt einen Veröffentlichen-Abonnieren-Rahmen (publish-subscribe framework), um Nachrichten von einem Gadget zu einem weiteren weiterzuleiten. Google-Gadgets sind vorgespeicherte Funktionalitätssätze, die in einem Web-Portal, wie beispielsweise iGoogle, enthalten sein können. Google unterstützte bisher diese Funktionalität, die in anderen Portalen nicht vorhanden wäre. Gadgets mit Daten zur gemeinsamen Nutzung würden die Daten mit einem Satz von definierten Kennungen über Kanäle veröffentlichen, so lange wie den Gadgets bewusst war, dass mindestens ein anderes Gadget an den Daten interessiert war. Gadgets, die an den Daten interessiert sind, würden ihr Interesse kundtun, zu erfahren, wann sich die Werte dieser Datenelemente geändert haben. Da die Daten über Kanäle zu der Zeit geschoben werden, wenn es eine Änderung gibt, kann jedoch der Zustand der Daten für neue Gadgets nicht verfügbar sein. Ferner müssen Gadgets mit Kenntnis der definierten Datenkennungen programmiert worden sein. Diese Lösung ist spezifisch für Google-Gadgets und ist nicht auf anderen Typen von Softwaresystemen portierbar.
Es ist daher eine Aufgabe der Erfindung, ein neuartiges Verfahren und System zur gemeinsamen Nutzung von Daten zwischen Softwaresystemen bereitzustellen.
Zusammenfassung der Erfindung
Gemäß einem Aspekt der Erfindung wird ein Verfahren zur gemeinsamen Nutzung von Daten zwischen Softwaresystemen bereitgestellt, das umfasst:
Aufrechterhalten einer Graphen-Datenstruktur im Speicher eines Rechengeräts, wobei die Graphen-Datenstruktur Datenelemente und Beziehungen dazwischen aufweist, die semantisch beschrieben sind;
Speichern einer Anfrage, die von einem ersten Softwaresystem für den Wert von angefragten Daten empfangen wurde, die semantisch beschrieben sind, und einer Adresse, die durch das erste Softwaresystem deklariert wird;
Semantisches Zerlegen der angefragten Daten in mindestens eines der Datenelemente in der Graphen-Datenstruktur; und
Aufrufen der Adresse und Weiterleiten des Werts des mindestens einen Datenelements an das erste Softwaresystem, wenn der Wert von einem der mindestens einen Datenelemente aktualisiert wird.
Das Verfahren kann ein Empfangen eines Werts für eines der Datenelemente in der Graphen-Datenstruktur von einem zweiten Softwaresystem umfassen. Ferner kann das Aufrufen umfassen: Aktualisieren der Graphen-Datenstruktur mit dem Wert, falls der Wert einer aktuellen Transaktion entspricht, und Verwerfen des Werts des einen Datenelements, falls der Wert einer veralteten Transaktion entspricht.
Das Verfahren kann ein Verwerfen der von dem ersten Softwaresystem empfangenen Anfrage umfassen, falls das erste Softwaresystem inaktiv wird.
Gemäß einem weiteren Aspekt der Erfindung wird ein Computersystem zur gemeinsamen Nutzung von Daten zwischen Softwaresystemen bereitgestellt, das umfasst:
einen Dienst zur gemeinsamen Nutzung von Daten, der auf dem Computersystem läuft, wobei der Dienst zur gemeinsamen Nutzung von Daten eine Graphen-Datenstruktur speichert, in der Datenelemente und Beziehungen dazwischen semantisch beschrieben sind, wobei der Dienst zur gemeinsamen Nutzung von Daten eine Anfrage, die von einem ersten Softwaresystem empfangen wurde, für den Wert von angefragten Daten, die semantisch beschrieben sind, und eine Adresse für das erste Softwaresystem speichert, wobei der Dienst zur gemeinsamen Nutzung von Daten die angefragten Daten in mindestens eines der Datenelemente in der Graphen-Datenstruktur semantisch zerlegt, die Adresse aufruft und den Wert des mindestens einen Datenelements an das erste Softwaresystem weiterleitet, wenn der Wert von einem des mindestens einen Datenelements aktualisiert wird.
Der Dienst zur gemeinsamen Nutzung von Daten kann eine Schnittstelle zum Empfangen eines Werts für eines der Datenelemente in der Graphen-Datenstruktur von einem zweiten Softwaresystem umfassen. Der Dienst zur gemeinsamen Nutzung von Daten kann die Graphen-Datenstruktur mit dem Wert aktualisieren, falls der Wert einer aktuellen Transaktion entspricht, und kann den Wert des einen Datenelements verwerfen, falls der Wert einer veralteten Transaktion entspricht.
Der Dienst zur gemeinsamen Nutzung von Daten kann die von dem ersten Softwaresystem empfangene Anfrage verwerfen, falls das erste Softwaresystem inaktiv wird.
Gemäß einem weiteren Aspekt der Erfindung wird ein Verfahren zur gemeinsamen Nutzung von Daten zwischen Softwaresystemen bereitgestellt, das umfasst:
Speichern von Werten für Datenelemente, die von Softwaresystemen empfangen wurden, im Speicher, wobei die Datenelemente und die Beziehungen dazwischen semantisch beschrieben sind;
Speichern von Anfragen, die von den Softwaresystemen empfangen wurden, wobei jede der Anfragen angefragte Daten semantisch kennzeichnet und eine Adresse umfasst;
Bestimmen, welcher der Anfragen entsprochen wird, durch semantisches Zerlegen der angefragten Daten in mindestens eines der Datenelemente, und Bestimmen, ob einer der Werte der mindestens einen Datenelemente aktualisiert wurde; und
Aufrufen der Adresse, die in der entsprochenen Anfrage gekennzeichnet ist, für jede der entsprochenen Anfragen und Weiterleiten der Werte der Datenelemente, in die sich die angefragten Daten semantisch zerlegen.
Das Bestimmen kann periodisch durchgeführt werden.
Das Verfahren kann ein Empfangen eines Wertes für eines der Datenelemente von einem der Softwaresysteme umfassen. Das Verfahren kann umfassen: Speichern des Wertes für das eine Datenelement, falls der Wert einer aktuellen Transaktion entspricht, und Verwerfen des Werts für das eine Datenelement, falls der Wert einer veralteten Transaktion entspricht.
Das Bestimmen kann als Antwort auf das Speichern durchgeführt werden.
Das Verfahren kann ein Hinzufügen von semantischer Information umfassen, die die Datenelemente mit anderen Datenelementen in Beziehung setzt.
Gemäß mit einem noch weiteren Aspekt der Erfindung wird ein Computersystem zur gemeinsamen Nutzung von Daten zwischen Softwaresystemen bereitgestellt, das umfasst:
einen Dienst zur gemeinsamen Nutzung von Daten, der auf dem Computersystem läuft, wobei der Dienst zur gemeinsamen Nutzung von Daten Werte für Datenelemente, die von Softwaresystemen empfangen wurden, im Speicherspeichert, wobei die Datenelemente und Beziehungen dazwischen semantisch beschrieben sind, der Dienst zur gemeinsamen Nutzung von Daten Anfragen speichert, die von den Softwaresystemen empfangen wurden, jede der Anfragen angefragte Daten semantisch kennzeichnet und eine Adresse umfasst, der Dienst zur gemeinsamen Nutzung von Daten durch semantisches Zerlegen der angefragten Daten in mindestens eines der Datenelemente bestimmt, welcher der Anfragen entsprochen wird, und bestimmt, ob einer der Werte des mindestens einen Datenelements aktualisiert wurde, und für jede der entsprochenen Anfragen die Adresse, die in der entsprochenen Anfrage gekennzeichnet ist, aufruft und die Werte der Datenelemente, in die sich die angefragten Daten semantisch zerlegen, weiterleitet.
Der Dienst zur gemeinsamen Nutzung von Daten kann bestimmen, welcher der Anfragen periodisch entsprochen wird.
Der Dienst zur gemeinsamen Nutzung von Daten kann eine Schnittstelle zum Empfangen eines Wert für eines der Datenelemente von einem der Softwaresysteme umfassen. Der Dienst zur gemeinsamen Nutzung von Daten kann den Wert für das eine Datenelement speichern, falls der Wert einer aktuellen Transaktion entspricht, und kann den Wert für das eine Datenelement verwerfen, falls der Wert einer veralteten Transaktion entspricht. Der Dienst zur gemeinsamen Nutzung von Daten kann bestimmen, welcher der Anfragen als ein Ergebnis des Speicherns des Werts entsprochen wird.
Der Dienst zur gemeinsamen Nutzung. von Daten kann semantische Information hinzufügen, die die Datenelemente mit anderen Datenelementen in Beziehung setzt.
Gemäß einem noch weiteren Aspekt der Erfindung wird ein Computer-lesbares Medium bereitgestellt, das darauf Computerausführbare Anweisungen gespeichert aufweist, die einen Dienst zur gemeinsamen Nutzung von Daten implementieren, wenn sie auf einem Computersystem ausgeführt werden, wobei der Dienst zur gemeinsamen Nutzung von Daten Werte für Datenelemente, die von Softwaresystemen empfangen wurden, im Speicherspeichert, die Datenelemente und Beziehungen dazwischen semantisch beschrieben sind, der Dienst zur gemeinsamen Nutzung von Daten Anfragen speichert, die von den Softwaresystemen empfangen wurden, wobei jede der Anfragen angefragte Daten semantisch kennzeichnet und eine Adresse umfasst, wobei der Dienst zur gemeinsamen Nutzung von Daten durch semantisches Zerlegen der angefragten Daten in mindestens eines der Datenelemente bestimmt, welcher der Anfragen entsprochen wird, und bestimmt, ob einer der Werte des mindestens einen Datenelements aktualisiert wurde, und für jede der entsprochenen Anfragen die Adresse, die in der entsprochenen Anfrage gekennzeichnet ist, aufruft und die Werte der Datenelemente, in die sich die angefragte Daten semantisch zerlegen, weiterleitet.
Gemäß einem weiteren Aspekt der Erfindung wird ein Verfahren bereitgestellt, um eine gemeinsame Nutzung von Daten zu ermöglichen, das umfasst:
Verfügbarmachen von Computer-ausführbaren Anweisungen über ein Netzwerk, wobei die Computer-ausführbaren Anweisungen einen Dienst zur gemeinsamen Nutzung von Daten implementieren, wenn sie auf einem Computersystem ausgeführt werden, wobei der Dienst zur gemeinsamen Nutzung von Daten Werte für Datenelemente, die von Softwaresystemen empfangen wurden, im Speicher speichert, die Datenelemente und Beziehungen dazwischen semantisch beschrieben sind, der Dienst zur gemeinsamen Nutzung von Daten Anfragen speichert, die von den Softwaresystemen empfangen wurden, jede der Anfragen angefragte Daten semantisch kennzeichnet und eine Adresse umfasst, wobei der Dienst zur gemeinsamen Nutzung von Daten durch semantisches Zerlegen der angefragten Daten in mindestens eines der Datenelemente bestimmt, welcher der Anfragen entsprochen wird, und bestimmt, ob einer der Werte des mindestens einen Datenelements aktualisiert wurde, und für jede der entsprochenen Anfragen die Adresse, die in der entsprochenen Anfrage gekennzeichnet ist, aufruft und die Werte der Datenelemente, in die sich die angefragten Daten semantischen zerlegen, weiterleitet.
Kurze Beschreibung der Zeichnungen
Ausführungsformen werden nun lediglich beispielhaft mit Bezug auf die beigefügten Figuren beschrieben, wobei:
1 eine Architektur hoher Ebene eines Computersystems zur gemeinsamen Nutzung von Daten in Übereinstimmung mit einer Ausführungsform der Erfindung zeigt;
2 ein schematisches Diagramm von Komponenten eines Dienstes zur gemeinsamen Nutzung von zustandsorientierten Daten und anderen Applikationen zeigt, die auf dem Computersystem von 1 laufen;
3 das allgemeine Verfahren zum Registrieren von Softwaresystemen durch den Dienst zur gemeinsamen Nutzung von zustandsorientierten Daten von 2 zeigt;
4 das allgemeine Verfahren zur Verarbeitung von ankommenden Datenelementwerten von Softwaresystemen durch den Dienst zur gemeinsamen Nutzung von zustandsorientierten Daten von 2 zeigt;
5 das allgemeine Verfahren zur Verarbeitung von Datenelementwerten, die von Softwaresystemen empfangen wurden, durch den Dienst zur gemeinsamen Nutzung von zustandsorientierten Daten von 2 zeigt;
6 ein Softwaresystem PatientSystem, ein Softwaresystem BMICalc, ein Softwaresystem RiskCalc und den Dienst zur gemeinsamen Nutzung von zustandsorientierten Daten von 2 in einem beispielhaften Szenario zeigt;
7 eine Graphen-Datenstrukturdefinition für die durch das Softwaresystem PatientSystem von 6 gemeinsam genutzten Datenveranschaulicht;
8 eine Graphen-Datenstrukturdefinition für die durch das Softwaresystem BMICalc von 6 gemeinsam genutzten Datenveranschaulicht;
9 eine Graphen-Datenstrukturdefinition für die durch das Softwaresystem RiskCalc von 6 gemeinsam genutzten Datenveranschaulicht;
10 die Datenelementwerte zeigt, die durch das Softwaresystem PatientSystem von 6 gemeinsam genutzt werden;
11 den Manager für gemeinsam genutzte Werte zeigt, der Konsumanfragen des Softwaresystems BMICalc von 6 erfüllt;
12 die Datenelementwerte zeigt, die durch das Softwaresystem BMICalc von 6 gemeinsam genutzt werden;
13 den Manager für gemeinsam genutzte Werte zeigt, der Konsumanfragen des Softwaresystems RiskCalc von 6 erfüllt;
14 die Datenelementwerte zeigt, die durch das Softwaresystem RiskCalc von 6 gemeinsam genutzt werden; und
15 den Manager für gemeinsam genutzte Werte zeigt, der Konsumanfragen des Softwaresystems PatientSystem von 6 erfüllt.
Detaillierte Beschreibung der Ausführungsformen
Im Gegensatz zu der bisherigen Praxis stellt die Erfindung ein neues Verfahren und System zur gemeinsamen Nutzung von Daten zwischen Softwaresystemen bereit, wobei im Allgemeinen persistente Information mit gemeinsam genutzter Semantik statt Punkt-zu-Punkt-Integration verwendet wird. Softwaresysteme nutzen semantisch gekennzeichnete Daten gemeinsam und fragen Daten, die sie benötigen, basierend auf der Semantik dieser Daten bei einem Dienst zur gemeinsamen Nutzung von zustandsorientierten Daten an. Der Dienst zur gemeinsamen Nutzung von zustandsorientierten Daten stellt Softwaresystemen Daten bereit, die durch andere Softwaresystemen gemeinsam benutzt werden, die semantisch mit dem übereinstimmen, was sie angefragt hatten, wenn die Daten aktualisiert werden.
Diese Vorgehensweise erleichtert eine Skalierung, um eine große Anzahl und einen großen Bereich von Softwaresystemen aufzunehmen. Mit der Erfindung können viele Softwaresysteme teilnehmen, ohne fortwährend die Integrationskomplexität zu erhöhen und ohne privilegierten Zugriff auf die Serverinfrastruktur, da die Integration im Auftrag von und für den Kontext des Benutzers durchgeführt wird. Stattdessen tragen alle Softwaresysteme zu dem gemeinsam genutzten Datensatz in einer Weise bei, die die verfügbaren Daten für alle Softwaresysteme bereichert.
Da die Integration nicht Punkt-zu-Punkt ist und Persistenz von gemeinsam genutzten Daten bereitstellt, nachdem sie bereitgestellt ist, wird ermöglicht, dass mehr als zwei Softwaresysteme Daten asynchron gemeinsam nutzen können. Sowohl die gemeinsam genutzten Daten als auch die gemeinsam genutzte Semantik kann persistent gemacht und von den Softwaresystemen externalisiert werden. Diese Kombination von Daten und Semantik kann unabhängig von irgendeinem der Softwaresysteme wertvoll sein. Netzwerkwirkungen wurden seit langem in verbundenen Softwaresystemen erkannt, wobei eine Netzwerkwirkung auftritt, wenn der Wert des Systems als Ganzes als ein Ergebnis der Anzahl von verbundenen Softwaresystemen schnell nach oben gehen kann. Das Verfahren und System zur gemeinsamen Nutzung von Daten der Erfindung zeigen Netzwerkwirkungen, da die Anzahl von Softwaresystemen und die Menge gemeinsam genutzter Daten zunimmt. Mehrere Softwaresysteme können gleichzeitig mit den gleichen gemeinsam genutzten Daten arbeiten und können tätig werden, um den Wert der gesamten, über das System gemeinsam genutzten Daten zu erhöhen. Das System stimmt Transaktionen ab, indem einfach Anfragen nach Daten empfangen werden und auf die Anfragen geantwortet wird, wenn Werte für Datenelemente, die semantisch mit den angefragten Daten übereinstimmen, verfügbar sind, was derartige Transaktionen Daten-getrieben macht.
Falls das Softwaresystem 1 beispielsweise sowohl Wert A als auch Wert B benötigt, um seine Arbeit zu tun, dann könnte das Softwaresystem 2 Wert A beitragen und das Softwaresystem 3 könnte Wert B beitragen. So weit es das Softwaresystem 1 betrifft, würde es die Information bekommen, die es benötigt, und würde sogar keine Kenntnis davon haben, dass mehrere Softwaresysteme beteiligt waren. Außerdem würde es unerheblich sein, wenn die Information durch die ersten beiden Softwaresysteme bereitgestellt würde, solange wie das Softwaresystem 1 imstande wäre, Werte A und B zu einem Zeitpunkt oder nach einem Zeitpunkt, an dem sie verfügbar wurden, zu empfangen. Das heißt, die Softwaresysteme 2 und 3 können sehr gut aufgehört haben teilzunehmen, wobei jedoch die Information, die sie bereitstellten, persistent gemacht und verwendet werden kann, um zukünftige Abfragen zu erfüllen.
1 ist ein Architekturdiagramm hoher Ebene eines Computersystems 20 zur gemeinsamen Nutzung von Daten gemäß einer Ausführungsform der Erfindung. Wie gezeigt, weist das Computersystem 20 eine Anzahl von physischen und logischen Komponenten auf, einschließlich einer zentralen Verarbeitungseinheit (”CPU”) 24, eines Direktzugriffsspeichers (”RAM”) 28, einer Eingabe/Ausgabe(”E/A”)-Schnittstelle 32, einer Netzwerkschnittstelle 36, eines nichtflüchtigen Speichers 40 und eines Lokalbus 44, der der CPU 24 ermöglicht, mit den anderen Komponenten zu kommunizieren. Die CPU 24 führt ein Betriebssystem, einen Dienst zur gemeinsamen Nutzung von zustandsorientierten Daten und eine Anzahl von Softwaresystemen aus. Der RAM 28 stellt der CPU 24 relativ ansprechbare flüchtige Speicher zur Verfügung. Die E/A-Schnittstelle 32 ermöglicht, dass eine Eingabe von einem oder mehreren Geräten, wie beispielsweise einer Tastatur, einer Maus, etc. empfangen werden kann, und gibt Information an Ausgabegeräte, wie beispielsweise einer Anzeige und/oder Lautsprecher, aus. Die Netzwerkschnittstelle 36 erlaubt eine Kommunikation mit anderen Systemen. Der nichtflüchtige Speicher 40 speichert das Betriebssystem und Programme, einschließlich Computer-ausführbaren Anweisungen zum Implementieren des Dienstes zur gemeinsamen Nutzung von zustandsorientierten Daten und der Daten des Dienstes zur gemeinsamen Nutzung von zustandsorientierten Daten. während des Betriebs des Computersystems 20 können das Betriebssystem, die Programme und die Daten von dem nichtflüchtigen Speicher 40 abgerufen und in dem RAM 28 platziert werden, um die Ausführung zu erleichtern.
2 zeigt die Hauptkomponenten des Dienstes zur gemeinsamen Nutzung von zustandsorientierten Daten 100, nämlich einen Manager für gemeinsam genutzte Werte (shared value manager) 104, ein Verzeichnis 108 und einen Raum für gemeinsam genutzte Werte (shared value space) 112, sowie auch eine Anzahl von verbundenen Softwaresystemen 116. Der Dienst zur gemeinsamen Nutzung von zustandsorientierten Daten 100 ist eine Java-Applikation, die beim Anlaufen des Computersystems 20 ausgeführt wird. Die Softwaresysteme 116 sind die Teilnehmer in diesem System zur gemeinsamen Nutzung von Daten, die Datenelemente gemeinsam nutzen und/oder konsumieren. Jedes Softwaresystem 116 ist eine Instanz eines Softwaresystemtyps. Zum Beispiel kann ein Softwaresystemtyp eine Applikation sein, die von einem Server auf dem Internet heruntergeladen werden kann, die programmiert ist, um bestimmte Datenelemente gemeinsam zu nutzen und/oder zu konsumieren. In diesem Beispiel würde ein Softwaresystem eine ausführende Instanz der Applikation sein. Jeder Softwaresystemtyp kann N Datenelemente gemeinsam nutzen und M Datenelemente konsumieren. Es gibt keine erforderliche Korrelation zwischen den gemeinsam genutzten Datenelementen und den konsumierten Datenelementen und jeder der beiden Werte kann Null sein, was bedeuten würde, dass der Softwaresystemtyp lediglich konsumiert oder lediglich gemeinsam nutzt. Die Softwaresysteme 116 müssen keinerlei Kenntnis davon, was die anderen Softwaresysteme 116 gemeinsam nutzen oder konsumieren, noch Kenntnis von der Existenz der anderen Softwaresysteme 116 aufweisen. Ferner können die Softwaresysteme 116 Daten mit anderen Softwaresystemen 116, die aktiv oder nicht aktiv sein können, gemeinsam nutzen und konsumieren.
Der Manager für gemeinsam genutzte Werte 104 ist in Kommunikation mit einer Anzahl von Softwaresystemen 116, die Daten über eine Schnittstelle liefern und anfragen, die der Manager für gemeinsam genutzte Werte 104 bereitstellt. Insbesondere ist die Schnittstelle eine Web-Schnittstelle zum Empfangen von Kommunikationen in der Form von Hypertext-Transfer-Protocol(”HTTP”)-Anfragen. HTTP ist das Protokoll, das von Webbrowsern verwendet wird, um Web-Seiten von Web-Servern abzurufen. Der Manager für gemeinsam genutzte Werte 104 verwaltet den Satz von gemeinsam genutzten Daten, wie er veröffentlicht (dass heißt, von den Softwaresystemen 116 gemeinsam genutzt wird) und dann anschließend anderen Softwaresystemen 116 bereitgestellt oder ”konsumiert” wird. Der Manager für gemeinsam genutzte Werte 104 umfasst einen Abfrageauswerter (query evaluator), der auswertet, ob den von den Softwaresystemen 116 empfangenen Datenanfragen, die als ”stehende Abfragen” (standing queries) bezeichnet werden, entsprochen wird. Insbesondere umfasst der Abfrageauswerter ein Begründermodul (reasoner module), das die in den stehenden Abfragen angefragten Daten, falls möglich, semantisch in Datenelemente zerlegt, für die Werte empfangen wurden. Das Begründermodul führt dies aus, indem Inferenzen zwischen der semantischen Beschreibung der angefragten Daten und der semantischen Beschreibung der Datenelemente in dem Raum für gemeinsam genutzte Werte 112 berechnet werden. Es wird erkannt, dass das Begründermodul in einigen Fällen nicht imstande sein wird, die angefragten Daten in Datenelemente in dem Raum für gemeinsam genutzte Werte 112 zu zerlegen. Zum Beispiel können die angefragten Daten noch nicht verfügbar sein, weil ein besonderer Softwaresystemtyp, der die Datenelemente aufweist, in die die angefragten Daten semantisch zerlegt werden, noch nicht registriert wurde, oder weil die angefragten Daten einfach nicht mit einem der Datenelemente übereinstimmen, die in den Graphen-Datenstrukturdefinitionen für Softwaresystemtypen in dem Verzeichnis 108 definiert sind. Der Abfrageauswerter bestimmt dann, durch Überprüfen des Raums für gemeinsam genutzte Werte 112, ob Werte für die übereinstimmenden Datenelemente empfangen wurden. Der besondere Abfrageauswerter, der in dieser Ausführungsform implementiert ist, ist von Jena, einem Open-Source-Java-Framework (quelloffenen Java-Rahmen) zum Erstellen von semantischen Web-Applikationen, wobei Information darüber bei http://jena.sourceforge.net/ gefunden werden kann. Pellet wurde zum Implementieren des Begründermoduls verwendet, wobei Information darüber bei http://clarkparsia.com/pellet/ gefunden werden kann.
Das Verzeichnis 108 kann persistente Graphen-Datenstrukturdefinitionen speichern. Jede Graphen-Datenstrukturdefinition stellt einen besonderen Softwaresystemtyp und ihre Absicht dar, an einem Punkt Datenelementwerte der darin definierten Typen gemeinsam zu nutzen. Die Graphen-Datenstrukturdefinitionen definieren semantisch die Datenelemente und die Beziehungen dazwischen. Die Graphen-Datenstrukturdefinitionen werden unter Verwendung des Resource Description Frameworks (”RDF”) (Rahmen zur Beschreibung von Ressourcen) erzeugt, einem Metadaten-Datenmodell, das über eine Familie von Spezifikationen des World Wide Web Consortium (”W3C”) zum konzeptionellen Modellieren von Information definiert ist. Die Graphen-Datenstrukturdefinitionen stellen eine ausreichende Semantik über die Datenelemente und die Softwaresysteme 116 bereit, um eine brauchbare Übereinstimmung und Entdeckung der Datenelemente, die durch die Softwaresystemtypen gemeinsam genutzt werden, durch das Begründermodul des Managers für gemeinsam genutzte Werte 104 zu ermöglichen. Außerdem kann das Verzeichnis 108 eine oder mehrere stehende Abfragen speichern, die für jeden Softwaresystemtyp definiert sind. Die stehenden Abfragen sind in der ”SPARQL Protocol and RDF Query Language” (”SPARQL”) geschrieben, die eine weitere W3C-Spezifikation zum semantischen Abfragen von Information ist. Das Verzeichnis 108 wird im Allgemeinen mit Graphen-Datenstrukturdefinitionen und stehenden Abfragen für Softwaresystemtypen gefüllt, von denen vor dem Einsatz erwartet wird, dass sie Daten über den Dienst zur gemeinsamen Nutzung von zustandsorientierten Daten 100 gemeinsam nutzen. Das Verzeichnis 108 ist in dem nichtflüchtigen Speicher 40 gespeichert und kann in den RAM 28 während des Betriebs des Dienstes zur gemeinsamen Nutzung von zustandsorientierten Daten 100 kopiert werden, um den Zugriff zu erleichtern.
Die Datenelemente weisen eindeutige Kennungen auf, die in dem Verzeichnis 108 der formalen semantischen Beschreibung der Daten zugeordnet sind, die verwendet werden können, um die Verarbeitung zur Übereinstimmung und Transformation von Daten zu automatisieren. Jede Datenelementkennung ist über den Satz von gemeinsam genutzten Daten eindeutig. Die Eindeutigkeit der Kennungen kann durch Verwenden eines Standards, wie Uniform Resource Identfiers (”URIs”), bereitgestellt werden, um die Kennungen innerhalb eines Umfangs zu definieren, der dem Autor des Softwaresystems 116 gehört. Zum Beispiel könnte der Domänennamensystem(”DNS”)-Name der Firma, die der Ersteller der Komponente war, verwendet werden, um die Kennung zu dieser Firma mit einem Suffix zu verbinden, das das besondere Datenelement kennzeichnet, das gemeinsam genutzt wird. Die Eindeutigkeit über sämtliche Softwaresysteme 116 ermöglicht, dass jede Verwendung dieser Datenelementkennung ein Datenelement mit den gleichen Charakteristika zuverlässig kennzeichnet. Vereinfacht ausdrückt, falls ein Softwaresystem A ein Datenelement mit einer Kennung von http://example.com/2010/Cl veröffentlicht und ein Softwaresystem B wünscht, Daten mit einer semantischen Beschreibung zu konsumieren, die mit der des Datenelements übereinstimmt, kann es sich auf die Tatsache zählen, dass das Datenelement mit der Kennung http://example.com/2010/Cl vom Softwaresystem A die erwarteten Daten sind.
Der Raum für gemeinsam genutzte Werte 112 ist ein persistenter Speicher, in dem Datenelemente und ihre zugeordneten Werte, die von den Softwaresystemen 116 empfangen werden, durch den Manager für gemeinsam genutzte Werte 104 gespeichert werden. Außerdem speichert der Manager für gemeinsam genutzte Werte 104 Konsumanfragen, die von den Softwaresystemen 116 empfangen wurden, in dem Raum für gemeinsam genutzte Werte 112. Jede Konsumanfrage umfasst eine stehende Abfrage für den Wert/die Werte von angefragten Daten, die semantisch in ein oder mehrere Datenelemente, falls verfügbar, zerlegt werden können, zusammen mit einer zugeordneten Adresse, die verwendet werden kann, um Werte von gemeinsam genutzten Datenelementen an das Softwaresystem 116 weiterzuleiten. Der Manager für gemeinsam genutzte Werte 104 kopiert die Graphen-Datenstrukturdefinitionen für die Softwaresystemtypen, die Softwaresystemen 116 entsprechen, die aktuell (d. h. aktiv) in dem Raum für gemeinsam genutzte Werte 112 registriert werden, und somit wird ein semantischer Übereinstimmungsvergleich (semantic matching) lediglich für Datenelemente durchgeführt, die durch aktuell registrierte Softwaresysteme 116 gemeinsam genutzt worden sein können. Der Raum für gemeinsam genutzte Werte 112 ist in dem nichtflüchtigen Speicher 40 gespeichert und kann in den RAM 28 während des Betriebs des Dienstes zur gemeinsamen Nutzung von zustandsorientierten Daten 100 kopiert werden, um den Zugriff zu erleichtern.
Der Dienst zur gemeinsamen Nutzung von zustandsorientierten Daten 100 kann sicherstellen, dass die Softwaresysteme 116 gemäß einem etablierten Satz von Regeln gemeinsam nutzen. Zum Beispiel stellt der Manager für gemeinsam genutzte Werte 104 sicher, dass jedes gemeinsam genutzte Datenelement geeignet gekennzeichnet ist, sodass seine Semantik immer bestimmt werden kann. Semantische Beschreibungen ermöglichen dem Dienst zur gemeinsamen Nutzung von zustandsorientierten Daten 100, nicht explizite Beziehungen zwischen den gemeinsam genutzten Daten zu definieren und dann zu verarbeiten. Die Semantik ermöglicht beispielsweise, dass zwei unterschiedliche Eigenschaften wie ”Yearsold” und ”Age” gleichgesetzt werden können; sogar etwas derart einfaches kann ohne semantische Beschreibungen umfangreiche Nacharbeiten insbesondere über eine große Anzahl von Softwaresystemen erfordern. Da Information in dem gemeinsam genutzten Datensatz geändert wird, der in dem Raum für gemeinsam genutzte Werte 112 gespeichert ist, kann das Softwaresystem 116 durch den Manager für gemeinsam genutzte Werte 116 über die Änderungen informiert werden, so dass sie auf den aktuellen Informationszustand antworten können.
Die Beschreibung der Datenelemente und der Softwaresysteme 116, die diese gemeinsam nutzen oder konsumieren, ermöglicht den Softwaresystemen 116, ihre gemeinsam genutzten und konsumierten Elemente auf eine Art und Weise zu deklarieren, die von ihrer internen Darstellung unabhängig ist, und ermöglicht ihnen, unzweideutig gekennzeichnet zu sein. Die Verwendung von Semantik ermöglicht dem Manager für gemeinsam genutzte Werte 104, die Beziehungen zwischen Datenelementen und Softwaresystemen 116 ohne Punkt-zu-Punkt-Verbindungen geeignet zu bestimmen, die durch die Softwaresysteme selbst etabliert werden.
Wenn die Softwaresysteme 116 wünschen, Daten mit den instanziierten Graphen-Datenstrukturen, die die gemeinsam genutzten Daten in dem Raum für gemeinsam genutzte Werte 112 speichern, gemeinsam zu nutzen und von diesen zu empfangen, übermitteln sie eine Registrierungsanfrage an den Manager für gemeinsam genutzte Werte 104. Die Registrierungsanfrage kennzeichnet den Softwaresystemtyp des Senders. Außerdem kann die Registrierungsanfrage eine Beschreibung der Daten, die gemeinsam genutzt werden, und ein oder mehrere Konsumanfragen umfassen. Wie zuvor bemerkt, umfasst jede Konsumanfrage eine stehende Abfrage für angefragte Daten, die semantisch in ein oder mehrere Datenelemente zerlegt werden können, zusammen mit einer der stehenden Abfrage zugeordneten Adresse, die ermöglicht, Werte für gemeinsam genutzte Datenelemente an die besondere Instanz des Softwaresystems weiterzuleiten. Die Adresse kennzeichnet das Mittel, durch das die Softwaresysteme 116 Werte für die angefragten Daten bereitstellen sollen. Beispielhafte Adressen können zum Beispiel die Adresse einer JavaScript-Funktion oder eines Uniform Resource Locators (”URL”) für einen Web-Dienst-Endpunkt umfassen. Der Manager für gemeinsam genutzte Werte 104 überwacht Änderungen bei den Werten der Datenelemente, die durch die Softwaresysteme 116 gemeinsam genutzt werden. Beim Erfassen einer Änderung/Aktualisierung bei dem Wert eines Datenelements bestimmt der Manager für gemeinsam genutzte Werte 104, welchen registrierten Konsumanfragen entsprochen wird. Konsumanfragen werden entsprochen, falls der Abfrageauswerter Werte in dem Raum für gemeinsam genutzte Werte für jedes Datenelement finden kann, das semantisch mit den Daten übereinstimmt, die in der enthaltenen stehenden Abfrage angefragt wurden, dass heißt, falls die stehende Abfrage Ergebnisse zurückliefert. Für jede stehende Abfrage, die Ergebnisse zurückliefert, tätigt der Manager für gemeinsam genutzte Werte 104 einen Aufruf an die Adresse, die durch das Softwaresystem 116 in der entsprechenden Konsumanfrage deklariert wurde, und leitet die Datenelementwerte an das Softwaresystem 116 mit dem Aufruf weiter. Somit kann, indem Konsumanfragen gespeichert werden, die stehende Abfragen und ein Verfahren (d. h. die Adresse) für den Manager für gemeinsam genutzte Werte 104 aufweisen, um den Softwaresystemen 116 die Ergebnisse der stehenden Abfragen mitzuteilen, sobald sie verfügbar sind, der Dienst zur gemeinsamen Nutzung von zustandsorientierten Daten 100 eine asynchrone gemeinsame Nutzung von Daten ermöglichen.
Das allgemeine Verfahren, das durch den Dienst zur gemeinsamen Nutzung von zustandsorientierten Daten 100 benutzt wird, um Softwaresysteme 116 zu registrieren, um ihnen zu ermöglichen, an der gemeinsamen Nutzung von Daten teilzunehmen, wird nun mit Bezug auf 2 und 3 beschrieben. In dem Verfahren, das bei 200 allgemein gekennzeichnet ist, empfängt der Manager für gemeinsam genutzte Werte 104 eine Registrierungsanfrage von einem Softwaresystem 116 und bestimmt, ob das Softwaresystem 116 einem erwarteten Softwaresystemtyp entspricht; das heißt, einem zuvor in dem Verzeichnis 108 definierten Softwaresystemtyp. Abhängig davon, ob das Softwaresystem 116 erkannt wird, aktualisiert der Manager für gemeinsam genutzte Werte 104 entweder die Information in dem Verzeichnis 108 für den besonderen Softwaresystemtyp basierend auf der Registrierungsanfrage oder erzeugt einen neuen Softwaresystemtyp in dem Verzeichnis 108 und fügt die in der Registrierungsanfrage bereitgestellte Information hinzu. Der Manager für gemeinsam genutzte Werte 104 instanziiert dann die Graphen-Datenstrukturdefinition in dem Verzeichnis 108 in dem Raum für gemeinsam genutzte Werte 112 für das Softwaresystem 116. Außerdem fügt der Manager für gemeinsam genutzte Werte 104 die mit der Registrierungsanfrage bereitgestellten Konsumanfragen hinzu.
Das Verfahren beginnt mit dem Empfang einer Registrierungsanfrage durch den Manager für gemeinsam genutzte Werte 104 (204). Softwaresysteme 116 können konfiguriert sein, um eine Registrierungsanfrage bei der Initialisierung oder zu anderen Zeiten zu erzeugen. Die Registrierungsanfrage liegt in der Form einer HTTP-Anfrage vor. Die Registrierungsanfrage umfasst eine Teilnehmerkennzeichnung, die den Typ des Softwaresystems 116 kennzeichnet, das die Registrierungsanfrage erzeugte. Die Teilnehmerkennzeichnung liegt in der Form einer URI vor und wird durch den Autor des Softwaresystemtyps gesetzt. In einem Modell für die Teilnehmerkennzeichnung umfasst die Teilnehmerkennzeichnung den DNS-Namen der Firma, die sie erzeugte, um Eindeutigkeit sicherzustellen. Zum Beispiel könnte die Teilnehmerkennzeichnung eines Softwaresystemtyps „http://example.com/twid/2010/02/client1” sein. Die Registrierungsanfrage kann ebenfalls ein oder mehrere Beschreibungen zur gemeinsamen Nutzung und/oder Konsumanfragen umfassen. Die Beschreibungen zur gemeinsamen Nutzung nehmen die Form eines Satzes von ”Tripeln” an, die die gemeinsam zu nutzenden Datenelemente definieren. Jedes Tripel definiert eine Beziehung zwischen einem zuvor definierten Knoten und einem anderen Knoten, wodurch eine Graphen-Datenstrukturdefinition gebildet wird. Zum Beispiel kann, wo ein Softwaresystemtyp einen einzigen Wert gemeinsam nutzt, ein erstes Tripel einen ersten Typ zur gemeinsamen Nutzung für den Softwaresystemtyp definieren und ein zweites Tripel kann definieren, dass der erste Typ zur gemeinsamen Nutzung einen Wert umfasst.
Bei Empfang einer Registrierungsanfrage bestimmt der Manager für gemeinsam genutzte Werte 104, ob es in Ordnung ist, die Registrierungsanfrage zu registrieren (208). Diese Entscheidung kann beispielsweise auf Sicherheitszwängen basieren, die die Registrierungen dahingehend einschränken, dass sie von einer bekannten Quelle kommen. Falls der Manager für gemeinsam genutzte Werte 104 bestimmt, dass die Registrierungsanfrage nicht angenommen werden soll, endet das Verfahren 200.
Falls stattdessen der Manager für gemeinsam genutzte Werte 104 bestimmt, dass die Registrierungsanfrage angenommen werden soll, bestimmt der Manager für gemeinsam genutzte Werte 104, ob die Registrierungsanfrage einen bekannten Softwaresystemtyp oder einen neuen Softwaresystemtyp kennzeichnet (212). Insbesondere vergleicht der Manager für gemeinsam genutzte Werte 104 die Teilnehmerkennzeichnung URI in der Registrierungsanfrage mit denen von registrierten Softwaresystemtypen, die in dem Verzeichnis 108 gespeichert sind. Falls die Teilnehmerkennzeichnung URI nicht mit einer für einen registrierten Softwaresystemtyp übereinstimmt, fügt der Manager für gemeinsam genutzte Werte 104 den Softwaresystemtyp zu dem Verzeichnis 108 hinzu (216). Außerdem fügt der Manager für gemeinsam genutzte Werte 104 jegliche Beschreibungen zur gemeinsamen Nutzung, die mit der Registrierungsanfrage bereitgestellt wurden, zu dem Verzeichnis 108 hinzu (224). Der Manager für gemeinsam genutzte Werte 104 verarbeitet jedes Tripel, um eine Graphen-Datenstrukturdefinition zu erstellen, die in dem Verzeichnis 108 gespeichert wird. Als nächstes fügt der Manager für gemeinsam genutzte Werte 104 jegliche Konsumanfragen hinzu, die mit der Registrierungsanfrage enthalten sind (228). Insbesondere fügt der Manager für gemeinsam genutzte Werte 104 die stehenden Abfragen, die Konsumanfragen kennzeichnen, falls vorhanden, zu dem Verzeichnis 108 hinzu. Nach Hinzufügen aller passenden Einträge zu dem Verzeichnis 108 registriert der Manager für gemeinsam genutzte Werte 104 das Softwaresystem 116 in dem Raum für gemeinsam genutzte Werte (228). Der Manager für gemeinsam genutzte Werte instanziiert die Graphen-Datenstrukturdefinition von dem Verzeichnis 108 in dem Raum für gemeinsam genutzte Werte 112 in Vorbereitung des Empfangens von Werten von dem Softwaresystem 116.
Außerdem fügt der Manager für gemeinsam genutzte Werte 104 jegliche Konsumanfragen, die mit der Registrierungsanfrage bereitgestellt wurden, in ihrer Gesamtheit zu dem Raum für gemeinsam genutzte Werte 112 hinzu.
Falls der Manager für gemeinsam genutzte Werte 104 stattdessen bei 212 bestimmt, dass die in der Registrierungsanfrage bereitgestellte Teilnehmerkennzeichnung URI mit einer für einen in dem Verzeichnis 108 gespeicherten Softwaresystemtyp übereinstimmt, aktualisiert der Manager für gemeinsam genutzte Werte 104 die Beschreibungen zur gemeinsamen Nutzung in dem Verzeichnis 108 für jene, die mit der Registrierungsanfrage bereitgestellt wurden (232). Dabei kann der Manager für gemeinsam genutzte Werte 104 Knoten (dass heißt, Datenelemente) der Graphen-Datenstrukturdefinition, die in dem Verzeichnis 108 für den Softwaresystemtyp gespeichert ist, hinzufügen oder von dieser entfernen. Dann aktualisiert der Manager für gemeinsam genutzte Werte 104 die stehenden Abfragen für den Softwaresystemtyp in dem Verzeichnis 108 für diejenigen, die in jeglichen Konsumanfragen enthalten sind, die die Registrierungsanfrage begleiten (236). Dabei kann der Manager für gemeinsam genutzte Werte 104 stehende Abfragen, die in dem Verzeichnis 108 gespeichert sind, für den Softwaresystemtyp hinzufügen oder entfernen. Beim Aktualisieren des Verzeichnisses 108 geht das Verfahren zu 228 weiter, wobei der Manager für gemeinsam genutzte Werte 104 an diesem Punkt das Softwaresystem 116 und jegliche Konsumanfragen, die mit der Registrierungsanfrage bereitgestellt wurden, in dem Raum für gemeinsam genutzte Werte 112 registriert.
Nach der Registrierung des Softwaresystems 116 in dem Raum für gemeinsam genutzte Werte 112 bei 228 sendet der Manager für gemeinsam genutzte Werte 104 eine Bestätigung an das Softwaresystem 116 (240). Die Bestätigung wird durch ein Kürzel begleitet, das die besondere Instanz des Softwaresystemtyps in dem Raum für gemeinsam genutzte Werte 112 kennzeichnet, der durch den Manager für gemeinsam genutzte Werte 104 erzeugt wird. Durch Zuweisen von eindeutigen Kennungen für jede Instanz der Softwaresystemtypen kann der Manager für gemeinsam genutzte Werte 104 mehreren Instanzen des gleichen Softwaresystemtyps (zum Beispiel, vielen Instanzen der gleichen Applikation) erlauben, Daten gemeinsam zu nutzen und zu empfangen. Der Manager für gemeinsam genutzte Werte 104 schiebt dann den Wert von konsumierten Datenelementen, falls vorhanden, durch das Softwaresystem 116 (244). Der Manager für gemeinsam genutzte Werte 104 prüft die registrierten Konsumanfragen für das Softwaresystem 116 in dem Raum für gemeinsam genutzte Werte 112 und bestimmt, ob irgendwelchen entsprochen wurde. Falls einer Konsumanfrage entsprochen wird, ruft der Manager für gemeinsam genutzte Werte 104 die Adresse in der Konsumanfrage auf und leitet die Werte für Datenelemente, die semantisch mit den Daten übereinstimmen, die in der stehenden Abfrage angefragt wurden, sowie auch eine Versionskennzeichnung für diejenigen Werte, die nachstehend beschrieben wird, an das Softwaresystem 116 weiter.
Sobald der Manager für gemeinsam genutzte Werte 104 jegliche erfüllte Konsumanfragen für das neu registrierte Softwaresystem 116 vollzogen hat, ist das Verfahren 200 zum Registrieren des Softwaresystems 116 abgeschlossen.
Nachdem ein Softwaresystem 116 registriert wurde, kann es Daten mit dem Dienst zur gemeinsamen Nutzung von zustandsorientierten Daten 100 gemeinsam nutzen. Die gemeinsam zu nutzenden Daten können durch das Softwaresystem 116 unabhängig von dem Dienst zur gemeinsamen Nutzung von zustandsorientierten Daten 100 als Teil einer neuen Transaktion erzeugt werden oder können als Antwort auf das Empfangen von Daten von dem Dienst zur gemeinsamen Nutzung von zustandsorientierten Daten 100 erzeugt werden und einen Teil dieser existierenden Transaktion bilden.
Transaktionen sind Sätze von einer oder mehreren logisch verbundenen Operationen, die an Daten durchgeführt werden. Ein oder mehrere Softwaresysteme 116 können die Operationen kooperativ durchführen, ohne dass sie Kenntnis von der Existenz oder den Funktionen des/der anderen haben. Wenn ein Satz von Datenelementwerten, der unabhängig erzeugt wurde, über den Dienst zur gemeinsamen Nutzung von zustandsorientierten Daten 100 gemeinsam genutzt wird, wird er als die Wurzel einer Transaktion bezeichnet und bekommt eine neue Transaktionsversionskennzeichnung zugewiesen. Wenn irgendetwas von dem Wurzelsatz von Datenelementwerten von anderen Softwaresystemen 116 verwendet wird, um Werte für zusätzliche Datenelemente zu erzeugen, bilden diese Datenelementwerte einen Teil der gleichen Transaktion und werden der gleichen Versionskennzeichnung zugewiesen. Softwaresysteme 116 empfangen die aktuelle Transaktionsversionskennzeichnung, wenn ihnen Werte mitgeteilt werden, die mit ihren Konsumanfragen übereinstimmen, und verwenden diese Transaktionsversionsinformation, um ihre Teilnahme über mehrere Transaktionen geeignet zu koordinieren. Der Manager für gemeinsam genutzte Werte 104 stellt sicher, dass geeignet implementierte Softwaresysteme 116 die erwarteten Ergebnisse erzeugen. Auf diese Art und Weise verfolgt und segregiert der Dienst zur gemeinsamen Nutzung von zustandsorientierten Daten 100 Werte für separate Transaktionen, wobei sichergestellt wird, dass die Werte für separate Transaktionen nicht gemischt werden.
Der Manager für gemeinsam genutzte Werte 104 stimmt die Transaktionen ab, indem einfach Anfragen nach Daten empfangen werden und auf die Anfragen geantwortet wird, wenn Werte für Datenelemente, die semantisch mit den angefragten Daten übereinstimmen, verfügbar sind. Die Deklarationen von Definitionen zur gemeinsamen Nutzung und von Konsumanfragen durch die Softwaresysteme 116 ermöglichen, dass derartige Transaktionen Daten-getrieben sind.
Das Verfahren zum Empfangen und Bereitstellen gemeinsam genutzter Datenelementwerte durch den Dienst zur gemeinsamen Nutzung von zustandsorientierten Daten 100 wird nun mit Bezug auf 1 bis 5 beschrieben.
4 zeigt allgemein bei 300 das Verfahren zur Vorverarbeitung von Datenelementen, die von einem Softwaresystem 116 gemeinsam genutzt werden. Das Verfahren 300 beginnt damit, dass ein Softwaresystem 116 einen Wert von einem oder mehreren Datenelementen veröffentlicht (304). Das Softwaresystem 116 stellt das Folgende als Parameter einer HTTP-Anfrage dem Dienst zur gemeinsamen Nutzung von zustandsorientierten Daten 100 zur Verfügung: die URI, die die besondere Instanz des Softwaresystemtyps des Softwaresystems 116 kennzeichnet, eine Datenelementkennung URI für jedes Datenelement, die kennzeichnet, was gemeinsam genutzt wird, einen Wert/Werte für die gemeinsam genutzten Datenelemente, und eine Versionskennzeichnung für den Satz aus Datenelementwert(en), falls vorhanden, die verwendet wird, um den Datenelementwert, der veröffentlicht wird, zu erzeugen. Somit kann, falls ein Softwaresystem 116 ein oder mehrere Datenelementwerte basierend auf Datenelementwerten erzeugt, die zuvor von dem Manager für gemeinsam genutzte Werte 104 empfangen wurden (d. h. die einen Teil der gleichen Transaktion bilden), der Manager für gemeinsam genutzte Werte 104 bei Empfang des veröffentlichten Satzes von aktualisierten Datenelementwerten von dem Softwaresystem 116 bestimmen, ob die Werte, auf die man sich beim Erzeugen des veröffentlichten Satzes von Datenelementwerte verlassen hat, noch gültig sind. Das heißt, der Manager für gemeinsam genutzte Werte 104 bestimmt, ob ein Satz von empfangenen Datenelementwerten einer veralteten oder aktuellen Transaktion entspricht. Der Manager für gemeinsam genutzte Werte 104 bestimmt bei Empfang des Satzes von gemeinsam genutzten Datenelementwerten, ob es in Ordnung ist, den Raum für gemeinsam genutzte Werte 112 für den Satz von gemeinsam genutzten Datenelementwerten zu aktualisieren (308). Insbesondere vergleicht der Manager für gemeinsam genutzte Werte 104 die veröffentlichten Datenelemente mit den Definitionen für die gemeinsame Nutzung, die in dem Verzeichnis 108 für den Softwaresystemtyp des Softwaresystems 116 gespeichert sind, das die Datenelementwerte veröffentlichte. Falls irgendein veröffentlichtes Datenelement nicht den Definitionen für die gemeinsame Nutzung entspricht, die in dem Verzeichnis 108 für den besonderen Softwaresystemtyp gespeichert sind, verwirft der Manager für gemeinsam genutzte Werte 104 den veröffentlichten Satz von Datenelementwerten und das Verfahren 300 endet.
Falls stattdessen der Satz von veröffentlichten Datenelementen den Definitionen für die gemeinsame Nutzung entspricht, die in dem Verzeichnis 108 für den besonderen Softwaresystemtyp gespeichert sind, schiebt der Manager für gemeinsam genutzte Werte 104 den veröffentlichten Satz von Datenelementwerten auf eine Werteaktualisierungswarteschlange, die er aufrechterhält (312). Der Manager für gemeinsam genutzte Werte 104 umfasst auch jegliche Versionskennzeichnung, die mit den Datenelementwerten empfangen wurde. Nach Platzierung des Satzes von Datenelementwerten in der Werteaktualisierungswarteschlange endet das Verfahren 300.
Der Manager für gemeinsam genutzte Werte 104 verarbeitet dann die Sätze von Datenelementwerten in der Werteaktualisierungswarteschlange. In einigen Fällen kann ein Softwaresystem 116 einen Satz von Datenelementwerten als Antwort auf ein Empfangen eines Satzes von Datenelementwerten von dem Manager für gemeinsam genutzte Werte 104, der einer seiner Konsumanfragen entspricht, erzeugen und veröffentlichen. Der Manager für gemeinsam genutzte Werte 104 kann jedoch wissen, dass die von dem Softwaresystem 116 verwendeten Werte aufgrund einer nachfolgenden Aktualisierung in dem Raum für gemeinsam genutzte Werte 112 obsolet sind. In diesem Fall verwirft der Manager für gemeinsam genutzte Werte 104 den Satz von Datenelementwerten, der von dem Softwaresystem 116 empfangen wurde, da er weiß, dass sie nicht länger gültig sein können. Zu diesem Zweck unterhält der Manager für gemeinsam genutzte Werte 104 Versionsinformation für die Werte der in dem Raum für gemeinsam genutzte Werte 112 gespeicherten Datenelemente. Insbesondere weist der Manager für gemeinsam genutzte Werte 104 eine eindeutige Versionskennzeichnung jedem Satz von Datenelementwerten zu, die einen Teil einer Transaktion bilden.
5 zeigt allgemein bei 400 das Verfahren zur Verarbeitung von Sätzen von Datenelementwerten in der Werteaktualisierungswarteschlange. Dieses Verfahren 400 wird ausgeführt, wann immer die Werteaktualisierungswarteschlange mindestens einen Satz von Datenelementwerten zum Aktualisieren darin aufweist. Das Verfahren 400 beginnt mit der Entfernung eines Satzes von Datenelementwerten aus der Werteaktualisierungswarteschlange (404). Der Manager für gemeinsam genutzte Werte 104 verarbeitet im Allgemeinen Sätze von Datenelementwerten in der Reihenfolge, in der sie empfangen werden. Der Satz von Datenelementwerten kann von einer Versionskennzeichnung für die Transaktion, zu der die Datenelementwerte gehören, begleitet sein. Der Manager für gemeinsam genutzte Werte 104 bestimmt dann, ob die Datenelementwerte in dem aus der Werteaktualisierungswarteschlange entfernten Satz gültig sind (408). Falls der aus der Werteaktualisierungswarteschlange entfernte Satz von Datenelementwerten nicht von einer Versionskennzeichnung begleitet wurde, wird der Satz von Datenelementwerten genommen, um eine neue Transaktion zu beginnen, und wird von dem Manager für gemeinsam genutzte Werte 104 als gültig angesehen. Falls der Satz von Datenelementwerten, der aus der Werteaktualisierungswarteschlange entfernt wurde, von einer Versionskennzeichnung begleitet wurde, prüft der Manager für gemeinsam genutzte Werte 104 die Versionskennzeichnung, um zu bestimmen, ob sie noch aktuell ist. Das heißt, der Manager für gemeinsam genutzte Werte 104 bestimmt, ob der in die Werteaktualisierungswarteschlange gesetzte Satz von Datenelementwerten einer veralteten oder aktuellen Transaktion entspricht. Falls der Manager für gemeinsam genutzte Werte 104 bestimmt, dass die begleitende Versionskennzeichnung aktuell ist, werden die Datenelementwerte in dem Satz, der aus der Werteaktualisierungswarteschlange entfernt wurde, als gültig angesehen. Falls jedoch der Manager für gemeinsam genutzte Werte 104 bestimmt, dass die begleitende Versionskennzeichnung nicht aktuell ist, wird der Satz von Datenelementwerten verworfen, der aus den Werteaktualisierungswarteschlange entfernt wurde, und der Manager für gemeinsam genutzte Werte 104 bestimmt, ob es verbleibende Sätze von Datenelementwerten gibt, die in der Werteaktualisierungswarteschlange geblieben sind (412). Falls es verbleibende Sätze von Datenelementwerten in der Wertaktualisierungswarteschlange gibt, kehrt das Verfahren zu 404 zurück, bei dem ein anderer Satz von Datenelementwerten aus der Werteaktualisierungswarteschlange entfernt wird. Falls es stattdessen keine verbleibenden Sätze von Datenelementwerten in der Werteaktualisierungswarteschlange gibt, endet das Verfahren 400.
Falls von dem Manager für gemeinsam genutzte Werte 104 bei 408 bestimmt wird, dass der aus der Werteaktualisierungswarteschlange entfernte Satz von Datenelementwerten gültig ist (d. h. Teil der aktuellen Transaktion oder einer neuen Transaktion ist), aktualisiert der Manager für gemeinsam genutzte Werte 104 den Satz von Datenelementwerten in dem Raum für gemeinsam genutzte Werte 112 (416). Falls der Satz von Datenelementwerten keine Versionskennzeichnung aufweist, dann erzeugt der Manager für gemeinsam genutzte Werte 104 ebenfalls eine neue eindeutige Versionskennzeichnung für den Satz von Datenelementwerten, der in dem Raum für gemeinsam genutzte Werte 112 platziert wird.
Sobald der Manager für gemeinsam genutzte Werte 104 den Raum für gemeinsam genutzte Werte 112 für die neuen Datenelementwerte aktualisiert hat, erzeugt der Manager für gemeinsam genutzte Werte 104 eine Liste von registrierten Konsumanfragen, die die aktualisierten Datenelemente umfassen können (420). In der Default-Konfiguration platziert der Manager für gemeinsam genutzte Werte 104 alle Konsumanfragen in dieser Liste, da es in vielen Szenarien weniger Prozessorintensiv sein kann, alle Konsumanfragen zu verarbeiten, statt zu bestimmen, welche anwendbar sind. Der Manager für gemeinsam genutzte Werte 104 überprüft lediglich Konsumanfragen in dem Raum für gemeinsam genutzte Werte 112; das heißt, registrierte Konsumanfragen für Softwaresysteme 116, von denen angenommen wird, dass sie aktiv sind. Die Liste der bei 420 erzeugten Konsumanfragen kann leer sein oder kann eine oder mehrere Konsumanfragen umfassen. Der Manager für gemeinsam genutzte Werte 104 bestimmt dann, ob es irgendwelche verbleibenden Konsumanfragen in der Liste gibt (424). Falls es keine verbleibenden Konsumanfragen für die aktualisierten Datenelementwerte gibt, dann ist die Aktualisierung der Datenelementwerte abgeschlossen und der Manager für gemeinsam genutzte Werte 104 bestimmt bei 412, ob es verbleibende Sätze von Datenelementwerten in der Werteaktualisierungswarteschlange gibt.
Falls es stattdessen verbleibende Konsumanfragen in der bei 420 erzeugten Liste gibt, dann entfernt der Manager für gemeinsam genutzte Werte 104 eine Konsumanfrage aus der Liste (428). Der Manager für gemeinsam genutzte Werte 104 bestimmt, ob der aus der Liste entfernten Konsumanfrage entsprochen wird (432). Wie zuvor bemerkt, werden Konsumanfragen entsprochen, falls der Abfrageauswerter die in der enthaltenen stehenden Abfrage angefragten Daten semantisch in Datenelementwerte in dem Raum für gemeinsam genutzte Werte 112 unter Verwendung der semantischen Deskriptoren für diese Datenelemente zerlegen kann; das heißt, falls die stehende Abfrage Ergebnisse zurückliefert. Falls der Konsumanfrage nicht entsprochen wird, bestimmt der Manager für gemeinsam genutzte Werte 104 bei 424, ob es verbleibende Konsumanfragen in der Liste gibt. Falls der Konsumanfrage entsprochen wird, bestimmt der Manager für gemeinsam genutzte Werte 104, ob es in Ordnung ist, das Softwaresystem 116 zu benachrichtigen, das der Konsumanfrage zugeordnet ist (436). In einigen Fällen kann es spezifiziert sein, dass bestimmte Datenelemente nur mit bestimmten Softwaresystemen 116 und/oder Softwaresystemtypen gemeinsam genutzt werden. Falls der Manager für gemeinsam genutzte Werte 104 bestimmt, dass es nicht in Ordnung ist, das Softwaresystem 116 zu benachrichtigen, bestimmt der Manager für gemeinsam genutzte Werte 104 bei 424, ob es verbleibende Konsumanfragen in der Liste gibt. Falls der Manager für gemeinsam genutzte Werte 104 stattdessen bestimmt, dass es in Ordnung ist, das Softwaresystem zu benachrichtigen, sendet der Manager für gemeinsam genutzte Werte 104 dem Softwaresystem 116 die Ergebnisse der Konsumanfrage (440). Der Manager für gemeinsam genutzte Werte 104 ruft die Adresse an, die in der Konsumanfrage gekennzeichnet ist, wobei die Ergebnisse an das Softwaresystem 116 als Parameter des Aufrufs weitergeleitet werden. Das Softwaresystem 116 verwendet die Information, die es von dem Manager für gemeinsam genutzte Werte 104 empfängt, in dem Funktionsanruf, um zu bestimmen, welche Aktion(en) durchzuführen ist/sind. Zum Beispiel kann das Softwaresystem 116 angezeigte Information aktualisieren, Berechnungen durchführen, die zurückgelieferten Datenelementwerte speichern, etc. als Antwort auf das Empfangen neuer Information. Nachdem die Ergebnisse dem Softwaresystem 116 bereitgestellt wurden, bestimmt der Manager für gemeinsam genutzte Werte 104 bei 424, ob es verbleibende Konsumanfragen in der Liste gibt. Sobald der Manager für gemeinsam genutzte Werte 104 bei 424 bestimmt, dass es keine verbleibenden Konsumanfragen in der Liste gibt, geht das Verfahren 400 zu 412 weiter, wo der Manager für gemeinsam genutzte Werte 104 bestimmt, ob es verbleibende Sätze von Datenelementwerten gibt, die in der Werteaktualisierungswarteschlange zu aktualisieren sind.
Es ist unerwünscht, Konsumanfragen für Softwaresysteme 116 zu verarbeiten, die nicht länger aktiv sind. Um sicherzustellen, dass der Manager für gemeinsam genutzte Werte 104 lediglich Konsumanfragen für aktive Softwaresysteme 116 in dem Raum für gemeinsam genutzte Werte 112 verarbeitet, werden stehende Abfragen für inaktive Softwaresysteme 116 aus dem Raum für gemeinsam genutzte Werte 112 entfernt. Wenn ein Softwaresystem 116 inaktiv wird (d. h. abschaltet), überträgt das Softwaresystem 116 eine ”Entregistrieren”-Benachrichtigung mit seiner eindeutigen Kennung an den Manager für gemeinsam genutzte Werte 104. Als Antwort vermerkt der Manager für gemeinsam genutzte Werte 104 die Entregistrierung des Softwaresystems 116 und entfernt die Konsumanfragen des Softwaresystems 116 aus dem Raum für gemeinsam genutzte Werte 112. Außerdem sendet der Manager für gemeinsam genutzte Werte 104 periodisch Aktivitätsbestätigungsanfragen an die registrierten Softwaresysteme 116, um sicherzustellen, dass sie noch aktiv sind. Der Manager für gemeinsam genutzte Werte 104 hält die Werte in dem Raum für gemeinsam genutzte Werte 112 aufrecht, die durch ein Softwaresystem 116 bereitgestellt werden, das entregistriert wird, es sei denn, dass er durch das Softwaresystem 116 anders angewiesen wird.
Um die Funktion des Computersystems 20 zur gemeinsamen Nutzung von Daten zu veranschaulichen, wird sie nun mit Bezug auf ein beispielhaftes Szenario mit Rückbezug auf 1 bis 5 beschrieben.
Eine beispielhafte Konfiguration des Computersystems 20 wird in 6 für eine Arztpraxis gezeigt. Drei unterschiedliche Softwaresysteme wechselwirken auf dem Computersystem 20, um zusammen eine Lösung bereitzustellen. Ein erstes Softwaresystem 516A, das als ”PatientSystem” bezeichnet wird, speichert Grunddaten für Patienten in der Arztpraxis. Die für jeden Patienten gespeicherten Grunddaten umfassen eine Patientenkennung, das Geburtsdatum, das Geschlecht, das Gewicht und die Größe des Patienten. PatientSystem 516A verwendet das Geburtsdatum des Patienten, um ein Alter für den Patienten zu berechnen. PatientSystem 516A umfasst jedoch nicht die Funktionalität, die erforderlich ist, um einen ”BMI” (Body Mass Index = Körpermasseindex) und einen Risikofaktor für den Patienten basierend auf Alter, Gewicht, Größe und Geschlecht des Patienten zu berechnen, wobei es jedoch diese Werte gerne einem Benutzer mit anderen Daten darstellen würde.
Ein zweites Softwaresystem 516B, das als ”BMICalc”, bezeichnet wird, nimmt ein Gewicht und eine Größe einer Person und berechnet einen BMI-Wert. Dieses Softwaresystem wird von einer Web-Site außerhalb der medizinischen Einrichtung verfügbar gemacht. Es stellt die Basis-BMI Berechnung zur Verfügung und zeigt aktuelle Graphen an, die zeigen, wo der berechnete BMI innerhalb der Gesamtbevölkerungsverteilung hineinpasst. Der Dienst zur gemeinsamen Nutzung von zustandsorientierten Daten erleichtert die Integration mit dem BMI-Rechner eines Dritten. Informationsgeheimhaltung (information privacy) wird gewahrt, weil lediglich anonyme Information (d. h. Gewicht und Größe) ausgetauscht wird und BMICalc 516B mit PatientSystem 516A im Gegensatz zu einer serverseitigen Integrationslösung ohne Zugriff auf die Serverinformation der medizinischen Einrichtungen integriert ist.
Ein drittes Softwaresystem 516C, das als ”RiskCalc” bezeichnet wird, nimmt das Geschlecht, das Alter und den BMI einer Person und berechnet einen Risikofaktor ”Risk”. Wie BMICalc 516B wird dieses Softwaresystem von einer Webseite außerhalb der medizinischen Einrichtung verfügbar gemacht. RiskCalc 516C ist ein sehr einfaches, auf Regeln basierendes Expertensystem, dass keine Wechselwirkung oder Schnittstelle mit dem Benutzer aufweist. Es ist zum Berechnen einer Risikoabschätzung basierend auf einigen anonymen Datenpunkten spezialisiert; dass heißt, Alter, Geschlecht und BMI. Wie BMICalc 516B erfordert RiskCalc 516C lediglich anonyme Information, um seine Funktion durchzuführen.
PatientSystem 516A, BMICalc 516B und RiskCalc 516C sind jeweils definierte Softwaresystemtypen in dem Verzeichnis 108. Keines der Softwaresysteme 516A, 516B und 516C hat Kenntnis voneinander noch von den Funktionen, die die anderen Softwaresysteme bereitstellen.
7 zeigt allgemein bei 600 die Graphen-Datenstrukturdefinition für die von PatientSystem 516A gemeinsam genutzten Datenelemente. Das PatientSystem 516A wird durch einen ersten Knoten 604 dargestellt. Wie gezeigt, definiert das PatientSystem 516A einen Satz von Werten, den es gemeinsam nutzt, und gibt diesem Satz die Kennung PSharel 608. Die PSharel 608 umfasst einen Patienten, der durch Patient 612 dargestellt wird. Obwohl es ist hier nicht veranschaulicht ist, könnte PatientSystem 516A andere Sätze von Werten gemeinsam nutzen, wobei jedem Satz seine eigene Kennung gegeben wird.
Um Flexibilität beim Verständnis der durch das PatientSystem 516A bereitgestellten Daten zu ermöglichen, wird eine Unterklasse für Patienten 612, genannt Person 616, definiert. Person 616 weist zwei Eigenschaften auf, Geschlecht 620 und Alter 624. Patient 612 weist ebenfalls drei Eigenschaften auf, Alter in Jahren 628, Gewicht 632 und Größe 636. Zwei Eigenschaften, Alter 624 und Alter in Jahren 628, sind dadurch gekennzeichnet, dass sie sich unter Verwendung einer formalen semantischen Beschreibung auf die gleichen Daten beziehen.
Die folgende Tabelle veranschaulicht die ”Tripel”, die verwendet werden, um die in 7 gezeigte Graphen-Datenstruktur zu definieren:
Wie bemerkt wird, werden die folgende Prädikate in den Tripeln verwendet:
rdfs:domain: dies gibt an, dass das Objekt eine Eigenschaft des Subjekts ist
rdfs:subClassOf: dies gibt an, dass das Subjekt eine Unterklasse des Objekts ist, das heißt, dass Mitglieder der Subjektklasse ebenfalls Mitglieder der Objektklasse sind
owl:sameAs: dies gibt an, dass die Mitglieder der Objektklasse die gleichen wie die Mitglieder der Subjektklasse sind
rdf:type: dies gibt an, dass das Subjekt eine Instanz des Objekts ist
Der erste Teil jedes dieser Tripel ist ein Präfix, das als eine Kurzform für den Rest der URI verwendet wird. Es gibt fünf Präfixe, die verwendet werden: ”rdfs:”, ”rdf”, „:”, ”owl:” und ”foaf”. Jedes dieser Präfixe kann sich auf ein unterschiedliches URI-Präfix beziehen. Wenn sie mit dem Suffix kombiniert sind, bilden sie eine volle, unzweideutige und eindeutige URI.
Wie oben bemerkt, ist ein ”Patient” eine Unterklasse von ”Person”. Auf diese Art und Weise können Eigenschaften einer Person mit Eigenschaften eines Patienten gleichgesetzt werden. Außerdem stellen ”Alter in Jahren” und ”Alter” die gleiche Eigenschaft dar, obwohl sich die Kennung der beiden Datenelemente unterscheidet. Dies ermöglicht einen Bezug auf das gleiche Prädikat in dem Raum für gemeinsam genutzte Werte 112, wobei entweder die Prädikatkennung ”:Alter in Jahren” oder die Prädikatkennung ”foaf:age” verwendet wird.
Außerdem kommuniziert bei der Registrierung PatientSystem 516A auch zwei Konsumanfragen: eine für den BMI und eine für den Risikofaktor. Die Struktur für diese beiden Konsumanfragen wird nachstehend dargestellt:
Jede Konsumanfrage weist eine eindeutige Kennung für die Anfrage und die stehende Abfrage auf, die der Manager für gemeinsam genutzte Werte 104 ausführt, um zu bestimmen, ob der Konsumanfrage entsprochen wird. Die erste Konsumanfrage in der Tabelle weist eine Kennung von ”:PatientSystem#CR1” auf. Sie fragt ein Tripel an, das den aktuellen Wert des Datenelements ”:BMI” bereitstellt, ohne Rücksicht auf das Subjekt, auf das es sich bezieht. Dieser Konsumanfrage ist die Adresse einer Funktion ”&pfuncl” innerhalb PatientSystem 516A zugeordnet, die benachrichtigt werden soll, wenn der ersten Konsumanfrage entsprochen wird. Die zweite Konsumanfrage mit einer Kennung von ”:PatientSystem#CR2” fragt ein Tripel an, das den aktuellen Wert des Datenelements ”:Risk” bereitstellt, ohne Rücksicht auf das Subjekt, auf das es sich bezieht. Der zweiten Konsumanfrage ist die Adresse einer Funktion ”&pfunc2” innerhalb PatientSystem 516A zugeordnet, die benachrichtigt werden soll, wenn der zweiten Konsumanfrage entsprochen wird.
8 zeigt allgemein bei 700 die Graphen-Datenstrukturdefinition für die Datenelemente, die durch BMICalc 516B gemeinsam genutzt werden. BMICalc 516B wird durch einen ersten Knoten 704 dargestellt. Wie gezeigt, definiert BMICalc 516B einen Satz von Werten, den es gemeinsam nutzt, und gibt diesem Satz die Kennung BSharel 708. Das BSharel 708 weist eine Eigenschaft von BMI 712 auf. Die folgende Tabelle veranschaulicht die Tripel, die verwendet werden, um die in 8 gezeigte Graphen-Datenstruktur zu definieren:
Außerdem kommuniziert bei der Registrierung BMICalc 516B auch eine Konsumanfrage für Größe und Gewicht einer Person. Die Struktur für diese Konsumanfrage wird nachstehend dargestellt:
Die durch BMICalc 516B definierte einzige Konsumanfrage wird als ”:BMICalc#CRl” gekennzeichnet. Die stehende Abfrage liefert den aktuellen Wert von sowohl der Größe als auch des Gewichtes zurück, wobei sie sich beide auf die gleiche Instanz einer ”foaf:Person” beziehen. Dieser Konsumanfrage ist die Adresse einer JavaScript-Funktion ”onHeightWeight” innerhalb BMICalc 516B zugeordnet, die benachrichtigt werden soll, wenn der Konsumanfrage entsprochen wird. BMICalc 516B wurde verfasst, um ein allgemeiner Client zu sein; es fragt an, das Gewicht und die Größe einer Person zu konsumieren. Diese Definition ist explizit genug, um ungültige Werte auszuschließen; sie umfasst eine Person, sodass, falls es mit einem Versandsystem gepaart ist, BMICalc 516B nicht versuchen würde, den BMI eines Behälters zu berechnen, nur weil das Versandsystem die Werte ”:Weight” und ”:Height” eines Behälters gemeinsam nutzt. Da BMICalc 516B nicht spezifisch geschrieben wurde, um mit PatientSystem 516A zu arbeiten, sucht es nicht nach einem ”:Patient” und sucht stattdessen nach einem ”foaf:Person”. Die semantische Definition des Datentyps ”:Patient” umfasst die Definition, dass ”:Patient” eine Unterklasse von ”foaf:Person” ist, und das bringt diese Konsumanfrage dazu, mit dem Datenelement übereinzustimmen, das durch PatientSystem 516A gemeinsam genutzt wird. Während der Ausführung der stehenden Abfrage durch den Abfrageauswerter wird ein Prozess, der allgemein Begründung (reasoning) genannt wird, durch das Begründermodul ausgeführt, wobei die in der stehenden Abfrage angefragten Daten semantisch in Datenelementwerte in dem Raum für gemeinsam genutzte Werte 112 unter Verwendung der Semantik zerlegt werden, die mit der Beschreibung der Graphen-Datenstruktur für das Softwaresystem 116 beschrieben ist. Es ist dieser Begründungsprozess, der imstande ist, die Unterklassenbeziehung von ”:Patient” zu ”foaf:Person” zu verwenden, um Verbindungen herzustellen, die keine genauen Übereinstimmungen sind.
9 zeigt allgemein bei 800 die Graphen-Datenstrukturdefinition für die Datenelemente, die durch RiskCalc 516C gemeinsam genutzt werden. RiskCalc 516C wird durch einen ersten Knoten 804 dargestellt. Wie gezeigt, definiert RiskCalc 516C einen Satz von Werten, den es gemeinsam nutzt, und gibt diesem Satz die Kennung RShare1 808. Die RShare1 808 weist eine Eigenschaft von Risk 812 auf.
Die folgende Tabelle veranschaulicht die Tripel, die verwendet werden, um die in 9 gezeigte Graphen-Datenstruktur zu definieren:
Außerdem kommuniziert bei der Registrierung RiskCalc 516C auch eine Konsumanfrage für jeweils das Geschlecht, das Alter und den BMI einer Person. Die Struktur für diese Konsumanfrage wird nachstehend dargestellt:
Die durch RiskCalc definierte einzige Konsumanfrage 516C wird als ”:RiskCalc#CRl” gekennzeichnet. Die stehende Abfrage liefert den aktuellen Wert des Geschlechts und Alters zurück, wobei sie sich beide auf die gleiche Instanz eines ”foaf:Person” beziehen, sie liefert ebenfalls den aktuellen Wert des Datenelements ”:BMI” zurück. Dieser Konsumanfrage ist die Adresse eines Web-Dienstes ”http://example.com/riskservice.asmx” für RiskCalc 516C zugeordnet, die benachrichtigt werden soll, wenn der Konsumanfrage entsprochen wird. RiskCalc 516C stützt sich auf die gleiche Abstraktion ”foaf:Person”, um zu erreichen, dass der Abfrageauswerter seine Information findet, und die Semantik stellt die gleiche Verbindung her, um eine semantische Zerlegung in einen ”:Patient” zu ermöglichen. Weil RiskCalc 516C ”foaf:Person” Konzepte benutzt, weiß es nichts über ”:Alter in Jahren”, und als Ergebnis muss die Anfrage für die ”foaf:age” keine genaue Übereinstimmung in irgendeiner der gemeinsam genutzten Information aufweisen. Ein Mensch, der auf die gemeinsam genutzte Information schaut, würde erkennen, dass der Wert ”:Patient:Alter in Jahren” das gleiche Konzept wie ”foaf:age” ist; aufgrund der semantischen Beschreibung der Daten kann der Abfrageauswerter die gleiche Beziehung finden. Die Verbindung ist semantisch mit dem Prädikat ”owl:sameAs” definiert, sodass das Begründermodul die Beziehung zwischen ihnen verarbeiten kann.
Die gemeinsame Nutzung von Daten zwischen den verschiedenen Komponenten des beispielhaften Szenarios von 6 wird nun mit Bezug auf 1 bis 15 beschrieben. Die gemeinsame Nutzung von Daten wird als ein Ergebnis dessen initiiert, dass ein Benutzer einen Patienten in PatientSystem 516A auswählt. Für die Zwecke dieses Beispiels sei angenommen, dass PatientSystem 516A, BMICalc 516B und RiskCalc 516C alle zuvor mit dem Dienst zur gemeinsamen Nutzung von zustandsorientierten Daten 100 registriert wurden. Es wird jedoch verstanden, dass dies nicht der Fall sein muss.
10 zeigt PatientSystem 516A, das eine Kommunikation 900 an den Manager für gemeinsam genutzte Werte 104 sendet, die einen Satz von Parametern und einen Satz von Datenelementwerten umfasst, die als ein Satz von Tripeln bereitgestellt werden. Die Parameter kennzeichnen die Instanz des Softwaresystemtyps, die das PatientSystem 516A ist, und den Typ der gemeinsamen Nutzung, die das PatientSystem 516A bereitstellt. Der von PatientSystem 516A gesendete Satz von Tripeln wird nachstehend zusammen mit einer Beschreibung davon gezeigt, was jedes Tripel angibt.
Es sei bemerkt, dass ”:patient-id” eine nicht private eindeutige Kennung in diesem Beispiel ist, die durch PatientSystem 516A zur externen Verwendung erzeugt wird. Der Manager für gemeinsam genutzte Werte 104 erzeugt Kennungen für die Instanz des Softwaresystemtyps und die gemeinsame Nutzung zur Registrierungszeit. Für Veranschaulichungszwecke sind diese Werte ”id-1” bzw. ”id-2”.
Außerdem wird die Graphen-Datenstruktur 904 gezeigt, die der Manager für gemeinsam genutzte Werte 104 in dem Raum für gemeinsam genutzte Werte 112 als ein Ergebnis des Empfangens der Parameter und der gemeinsam genutzten Datenelementwerte von PatientSystem 516A erzeugt. Es wird erkannt, dass das PatientSystem 516A einen Patienten gemeinsam genutzt hat, der männlich ist, 42 Jahre alt ist, ein Gewicht von 210 Pfund und eine Größe von 73 Zoll aufweist.
Bei Empfangen der Datenelementwerte führt der Manager für gemeinsam genutzte Werte 104 die Verfahren 300 und 400 aus. Als Ergebnis bestimmt der Manager für gemeinsam genutzte Werte 104, dass die durch BMICalc 516B übermittelte Konsumanfrage 516B erfüllt wurde.
11 zeigt den Manager für gemeinsam genutzte Werte 104, der die Konsumanfrage von BMICalc 516B vollzieht, indem ein Aufruf 950 an die Adresse, die in der Konsumanfrage an BMICalc gekennzeichnet ist, mit den Datenelementwerten ”:Größe” und ”:Gewicht”, die durch PatientSystem 516A als Parameter bereitgestellt werden, sowie auch der Versionskennzeichnung für die Transaktion, zu der sie gehören, getätigt wird.
BMICalc 516B ist konfiguriert, sodass bei Empfangen einer Größe und eines Gewichts es einen BMI berechnet, wobei BMICalc 516B angegeben hat, dass es ihn mit dem Dienst zur gemeinsamen Nutzung von zustandsorientierten Daten 100 gemeinsam nutzen würde.
12 zeigt das BMICalc 516B, das eine Kommunikation 1000 an den Manager für gemeinsam genutzte Werte 104 sendet, die einen Satz von Parametern und einen Datenelementwert umfasst, der als ein einziges Tripel bereitgestellt wird. Die Parameter kennzeichnen die Instanz des Softwaresystemtyps, die BMICalc 516B ist, den Typ der gemeinsamen Nutzung, den BMICalc 516B bereitstellt, und die Versionskennzeichnung für die Version, auf die es sich beim Berechnen des BMI stützte. Das von BMICalc 516B gesendete Tripel wird nachstehend zusammen mit einer Beschreibung davon gezeigt, was das Tripel angibt.
Es sei bemerkt, dass das oben gekennzeichnete Tripel angibt, dass BMICalc 516B ”:patient-id” kennt, welches es in der entsprochenen Konsumanfragebenachrichtigung empfangen hat. Wie zuvor bemerkt, ist ”patient-id” keine private Information.
Außerdem wird die Graphen-Datenstruktur 1004, die der Manager für gemeinsam genutzte Werte 104 erzeugt, in dem Raum für gemeinsam genutzte Werte 112 als ein Ergebnis des Empfangens der Parameter und des gemeinsam genutzten Datenelementwerts von BMICalc 516B gezeigt. Wie erkannt wird, hat BMICalc 516B den berechneten Wert ”:BMI” von ”22,4” gemeinsam genutzt.
Bei Empfangen des Werts ”:BMI” führt der Manager für gemeinsam genutzte Werte 104 die Verfahren 300 und 400 aus. Als ein Ergebnis des Empfangens dieses gemeinsam genutzten Werts und des Aufrechterhaltens des persistenten Zustands der zuvor gemeinsam genutzten Werte von PatientSystem 516A, bestimmt der Manager für gemeinsam genutzte Werte 104, dass der von RiskCalc 516C übermittelten Konsumanfrage entsprochen wurde.
13 zeigt den Manager für gemeinsam genutzte Werte 104, der die Konsumanfrage von RiskCalc 516C vollzieht, indem ein Aufruf 1050 an die in der Konsumanfrage gekennzeichnete Adresse an RiskCalc 516C, mit den Datenelementwerten ”foaf:age” und ”foaf:gender”, die durch PatientSystem 516A bereitgestellt werden, und dem Datenelementwert ”:BMI”, der durch BMICalc 516B bereitgestellt wird, als Parameter sowie auch der aktuellen Versionskennzeichnung getätigt wird.
RiskCalc 516C ist derart konfiguriert, dass bei Empfangen eines Alters, Geschlechts und BMI es einen Risikofaktor ”:Risk” berechnet, wobei RiskCalc 516C angegeben hat, dass es ihn mit dem Dienst zur gemeinsamen Nutzung von zustandsorientierten Daten 100 gemeinsam nutzen würde.
14 zeigt RiskCalc 516C, das eine Kommunikation 1100 an den Manager für gemeinsam genutzte Werte 104 sendet, die einen Satz von Parametern und einen als ein einziges Tripel bereitgestellten Datenelementwert aufweist. Die Parameter kennzeichnen die Instanz des Softwaresystemtyps, die RiskCalc 516C ist, den Typ der gemeinsamen Nutzung, den RiskCalc 516C bereitstellt, und die Versionskennzeichnung für die Version, auf die es sich beim Berechnen von Risk stützte. Der durch RiskCalc 516C gesendete Satz von Tripeln wird nachstehend zusammen mit einer Beschreibung davon gezeigt, was das Tripel angibt.
Es sei bemerkt, dass das oben gekennzeichnete Tripel angibt, dass RiskCalc 516C ”:patient-id” kennt, welches es in der entsprochenen Konsumanfragebenachrichtigung empfing. Wie zuvor bemerkt, ist ”patient-id” keine private Information.
Außerdem wird die Graphen-Datenstruktur 1104 gezeigt, die der Manager für gemeinsam genutzte Werte 104 in dem Raum für gemeinsam genutzte Werte 112 als ein Ergebnis des Empfangens der Parameter und des gemeinsam genutzten Datenelementwerts von RiskCalc 516C erzeugt. Wie erkannt wird, hat RiskCalc 516C einen Datenelementwert ”:Risk” von ”Medium” gemeinsam genutzt.
Bei Empfangen des Werts ”:Risk” führt der Manager für gemeinsam genutzte Werte 104 die Verfahren 300 und 400 aus. Als Ergebnis bestimmt der Manager für gemeinsam genutzte Werte 104, dass der durch PatientSystem 516A übermittelten Konsumanfrage entsprochen wurde.
15 zeigt den Manager für gemeinsam genutzte Werte 104, der die Konsumanfrage von PatientSystem 516A vollzieht, indem ein Aufruf 1150 an die in der Konsumanfrage gekennzeichneten Adresse an PatientSystem 516A mit dem Datenelementwert ”:BMI”, der durch BMICalc 516B bereitgestellt wird, und dem Datenelementwert ”:Risk”, der durch RiskCalc 516C bereitgestellt wird, als Parameter sowie auch der Versionskennzeichnung getätigt wird.
PatientSystem 516A ist so konfiguriert, dass es bei Empfangen der Datenelementwerte ”:BMI” und ”:Risk” die Information einem Benutzer auf einer Anzeige darstellt. Der Empfang dieser Werte durch PatientSystem 516A beendet die Transaktion.
Somit ermöglicht der Dienst zur gemeinsamen Nutzung von zustandsorientierten Daten 100 eine gemeinsame Nutzung von Daten zwischen Softwaresystemen, die im Allgemeinen persistente Information mit gemeinsam genutzter Semantik benutzen. Da die Integration nicht Punkt-zu-Punkt ist und Persistenz von gemeinsam genutzten Daten bereitstellt, nachdem sie verfügbar gemacht wird, wird ermöglicht, dass mehr als zwei Softwaresysteme Daten asynchron gemeinsam nutzen können. Sowohl die gemeinsam genutzten Daten als auch die gemeinsam genutzte Semantik kann persistent gemacht und von den Softwaresystemen externalisiert werden. Der Dienst zur gemeinsamen Nutzung von zustandsorientierten Daten 100 stimmt Transaktionen ab, indem einfach Anfragen nach Daten gespeichert werden und auf die Anfragen geantwortet wird, wenn Werte für Datenelemente, die semantisch mit den angefragten Daten übereinstimmen, verfügbar sind, was derartige Transaktionen Daten-getrieben macht.
Computer-ausführbare Anweisungen zum Implementieren des Dienstes zur gemeinsamen Nutzung von zustandsorientierten Daten auf einem Computersystem könnten separat von dem Computersystem, beispielsweise auf einem Computer-lesbaren Medium (wie beispielsweise einer optischen Platte, einer Festplatte, einem USB-Laufwerk oder einer Media-Karte) bereitgestellt werden, oder indem sie zum Herunterladen über ein Kommunikationsnetzwerk, wie beispielsweise das Internet, verfügbar gemacht werden. Die Computer-ausführbaren Anweisungen könnten mit einem oder mehreren Softwaresystemen gebündelt werden. Zum Beispiel könnte der Besuch einer Webseite, die die Softwaresystem-Funktionalität umfasst, ein Herunterladeereignis für die Computer-ausführbaren Anweisungen auslösen.
Obwohl die Erfindung mit Spezifizität auf eine Java-Implementierung beschrieben wurde, werden einem Fachmann andere Typen von Implementierungen in den Sinn kommen. Zum Beispiel könnte der Dienst zur gemeinsamen Nutzung von zustandsorientierten Daten in irgendeiner einer Anzahl von Programmiersprachen, wie beispielsweise Microsoft C# oder Javascript, geschrieben sein. Jede Allzweck-Programmiersprache könnte ausgetauscht werden.
Anstatt alle Konsumanfragen jedes Mal zu verarbeiten, wenn Datenwerte geändert werden, kann es unter bestimmten Umständen wünschenswert sein, basierend auf der semantischen Information zu bestimmen, welche Konsumanfragen anwendbar sind oder anwendbar sein können. In einer anderen alternativen Konfiguration können alle Konsumanfragen unabhängig vom Empfang von Datenelementwerten bei einer gewissen regelmäßigen Frequenz, wie beispielsweise alle 100 Millisekunden, verarbeitet werden.
Anstatt Graphen-Datenstrukturdefinitionen und stehende Anfragen persistent in dem Verzeichnis zu speichern, können die Softwaresysteme diese Information nach Bedarf, wie beispielsweise während der Registrierung, bereitstellen.
Die Web-Schnittstelle zum Empfangen von Anfragen könnte mit irgendeiner einer Vielfalt von Schnittstellen ausgetauscht werden, womit das HTTP ersetzt wird, das mit irgendeinem Kommunikationsprotokoll, wie beispielsweise Java Remote Method Invocation, .NET Windows Communication Framework, „Message queue style” Kommunikationen oder sogar einfachen Funktionsaufrufen verwendet wird.
RDF kann als das Metadatenformat durch anderen Typen von Metadatensprachen, wie beispielsweise DAML und XML, ersetzt werden.
SPARQL ist lediglich eine mögliche Abfragesprache zur Verwendung beim Aufbauen von stehenden Abfragen. Andere Beispiele umfassen XsRQL und RQL.
Obwohl das Computersystem als ein einziger physischer Computer gezeigt wird, kann erkannt werden, dass das Computersystem zwei oder mehrere physische Computer in Kommunikation miteinander umfassen kann. Demgemäß wird, obwohl die Ausführungsform die verschiedenen Komponenten des Dienstes zur gemeinsamen Nutzung von zustandsorientierten Datenzeigt, die auf dem gleichen physischen Computer liegen, ein Fachmann erkennen, dass sich die Komponenten auf separaten physischen Computern befinden können. Ferner können einzelne oder alle Komponenten des Dienstes zur gemeinsamen Nutzung von zustandsorientierten Daten auf einem von den Softwaresystemen separaten physischen Computer liegen.
Der Manager für gemeinsam genutzte Werte kann separate Transaktionen in dem Raum für gemeinsam genutzte Werte aufrechterhalten oder kann separate Räume für gemeinsam genutzte Werte für jeden Typ von Transaktion erzeugen.
Die Softwaresysteme könnte entweder visuell oder nicht-visuell sein, wobei Beispiele von Clientsystemen umfassen: Webseiten, Rich Web Applications, Clientsoftware wie Microsoft Excel, SOA-Endpunkte, Datenbanken, JavaScript-Skripte, etc..
Die mit Konsumanfragen bereitgestellten Adressen können alternativ Adressenzeiger, TCP/IP-Sockets, Nachrichtenkanäle oder jedes andere Mittel zum Kommunizieren mit den Softwaresystemen sein.
Obwohl eine Werteaktualisierungswarteschlange in der oben beschriebenen Ausführungsform verwendet wird, können andere Verfahren zur Verarbeitung von Sätzen von Datenelementwerten verwendet werden. Zum Beispiel umfassen alternative Verfahren die Verwendung einer exklusiven Sperre, eine parallele Ausführung mit exklusiven Datenräumen oder jedes andere Verfahren, das einen konsistenten Endzustand für den Raum von gemeinsam genutzten Werten nach der Aktualisierung sicherstellt.
Jede Kennung, die Eindeutigkeit innerhalb des referenzierbaren Adressenraums bereitstellt, würde anstelle von URIs funktionieren. Zum Beispiel könnte eine ganzzahlige oder eine global eindeutige Kennung (Globally Unique Identifier) (”GUID”) benutzt werden.
Der Dienst zur gemeinsamen Nutzung von zustandsorientierten Daten kann die semantische Information für die Datenelemente durch Integrieren zusätzlicher semantischer Definitionen mit den semantischen Beschreibungen der gemeinsam genutzten Daten vergrößern, um eine verbesserte Verarbeitung bereitzustellen. Das heißt, dass zusätzliche semantische Information, die die Datenelemente in der Graphen-Datenstruktur mit anderen Datenelementen in Beziehung setzt, hinzugefügt werden kann. Zum Beispiel kann der Dienst zur gemeinsamen Nutzung von zustandsorientierten Daten eine Beziehung zwischen ”:Person”, die in der beispielhaften Graphen-Datenstrukturdefinition von 7 definiert ist, und einem Datenelement genannt ”Individual” unter Verwendung des Deskriptors ”rdfs:subClassOf” hinzufügen. Auf diese Art und Weise könnte der Dienst zur gemeinsamen Nutzung von zustandsorientierten Daten eine Anfrage nach dem Alter einer Einzelperson unter Verwendung der Daten, die durch PatientSystem gemeinsam genutzt werden, semantisch zerlegen.
Die Beschreibung der Softwaresysteme kann separat von den Registrierungsanfragen bereitgestellt werden. Diese. Information könnte als ein separater Schritt bereitgestellt werden, und das Verzeichnis könnte bereits zur Zeit der Registrierung gefüllt sein. Das Verzeichnis könnte über mehrere Instanzen und Sitzungen des Managers für gemeinsam genutzte Werte persistent sein.
Die stehenden Anfragen können in einigen Fällen in Datenelemente als Teil einer Vorverarbeitungsstufe für die stehenden Anfragen semantisch zerlegt werden.
In dem Manager für gemeinsam genutzte Werte gehaltene Werte können so persistent sein, wie es durch den Implementierer und die Softwaresysteme gewünscht wird. Werte können persistent gehalten werden, sogar wenn der Manager für gemeinsam genutzte Werte nicht ausführend ist, oder könnten alternativ Lebensdauern aufweisen, die viel kürzer als das Leben eines einzigen Client sind. In einer alternativen Konfiguration können Werte eine ”time-to-live”-Eigenschaft zugewiesen werden, die die Länge der Zeitperiode angibt, während der die Werte gültig sind. In diesem Fall wird jeder Wert entweder durch einen anschließend gemeinsam genutzten Wert ersetzt oder wird nach der spezifizierten Zeitperiode verworfen.
Datenübersetzer-Softwaresysteme können mit der Erfindung benutzt werden. Zum Beispiel könnte, falls ein erstes Softwaresystem einen Wert zu dem Satz von gemeinsam genutzter Information beiträgt, den ein zweites Softwaresystem nicht versteht, ein drittes Softwaresystem den Wert interpretieren, um dem zweiten Softwaresystem zu ermöglichen, ihn zu verarbeiten.
Obwohl gemeinsam genutzte Datenelementwerte, die veralteten Transaktionen entsprechen, in der oben beschriebenen Ausführungsform verworfen werden, könnte der Dienst zur gemeinsamen Nutzung von zustandsorientierten Daten Datenelementwerte gleichzeitig speichern, die unterschiedlichen Transaktionen entsprechen.
Die Softwaresysteme könnten wiederholt versuchen, sich mit dem Dienst zur gemeinsamen Nutzung von zustandsorientierten Daten zu registrieren, falls er bei dem ersten Versuch nicht aktiv war. Alternativ könnten sie den Dienst zur gemeinsamen Nutzung von zustandsorientierten Daten veranlassen, sich zu initialisieren, falls er nicht aktiv ist.
Andere Typen von Datenelementkennungen werden einem Fachmann in den Sinn kommen.
Der Manager für gemeinsam genutzte Werte könnte auf Verlangen anstatt beim Anlaufen des Computersystems gestartet werden.
Die oben beschriebenen Ausführungsformen sind bestimmt, Beispiele der vorliegenden Erfindung zu sein, und Änderungen und Modifikationen daran können durch einen Fachmann erfolgen, ohne von dem Schutzumfang der Erfindung abzuweichen, der einzig und allein durch die angefügten Ansprüche definiert ist.
ZITATE ENTHALTEN IN DER BESCHREIBUNG
Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
Zitierte Nicht-Patentliteratur

http://code.google.com/apis/gadgets/docs/pubsub.html [0010]
http://jena.sourceforge.net/ [0051]
http://clarkparsia.com/pellet/ [0051]
http://example.com/2010/Cl [0053]
http://example.com/twid/2010/02/client1 [0059]
http://example.com/riskservice.asmx [0097]

Claims

Verfahren zur gemeinsamen Nutzung von Daten zwischen Softwaresystemen, das umfasst: Aufrechterhalten einer Graphen-Datenstruktur im Speicher eines Rechengeräts, wobei die Graphen-Datenstruktur Datenelemente und Beziehungen dazwischen aufweist, die semantisch beschrieben sind; Speichern einer Anfrage, die von einem ersten Softwaresystem für den Wert von angefragten Daten empfangen wurde, die semantisch beschrieben sind, und einer Adresse, die durch das erste Softwaresystem deklariert wird; Semantisches Zerlegen der angefragten Daten in mindestens eines der Datenelemente in der Graphen-Datenstruktur; und Aufrufen der Adresse und Weiterleiten des Werts des mindestens einen Datenelements an das erste Softwaresystem, wenn der Wert von einem der mindestens einen Datenelemente aktualisiert wird.
Verfahren gemäß Anspruch 1, das ferner umfasst: Empfangen eines Werts für eines der Datenelemente in der Graphen-Datenstruktur von einem zweiten Softwaresystem.
Verfahren gemäß Anspruch 2, bei dem das Aufrufen umfasst: Aktualisieren der Graphen-Datenstruktur mit dem Wert, falls der Wert einer aktuellen Transaktion entspricht.
Verfahren gemäß Anspruch 3, bei dem das Aufrufen ferner umfasst: Verwerfen des Werts des einen Datenelements, falls der Wert einer veralteten Transaktion entspricht.
Verfahren gemäß Anspruch 1, das ferner umfasst: Verwerfen der von dem ersten Softwaresystem empfangenen Anfrage, falls das erste Softwaresystem inaktiv wird.
Computersystem zur gemeinsamen Nutzung von Daten zwischen Softwaresystemen, das umfasst: einen Dienst zur gemeinsamen Nutzung von Daten, der auf dem Computersystem läuft, wobei der Dienst zur gemeinsamen Nutzung von Daten eine Graphen-Datenstruktur speichert, in der Datenelemente und Beziehungen dazwischen semantisch beschrieben sind, wobei der Dienst zur gemeinsamen Nutzung von Daten eine Anfrage, die von einem ersten Softwaresystem empfangen wurde, für den Wert von angefragten Daten, die semantisch beschrieben sind, und eine Adresse für das erste Softwaresystem speichert, wobei der Dienst zur gemeinsamen Nutzung von Daten die angefragten Daten in mindestens eines der Datenelemente in der Graphen-Datenstruktur semantisch zerlegt, die Adresse aufruft und den Wert des mindestens einen Datenelements an das erste Softwaresystem weiterleitet, wenn der Wert von einem des mindestens einen Datenelements aktualisiert ist.
Computersystem gemäß Anspruch 6, bei dem der Dienst zur gemeinsamen Nutzung von Daten eine Schnittstelle zum Empfangen eines Werts für eines der Datenelemente in der Graphen-Datenstruktur von einem zweiten Softwaresystem aufweist.
Computersystem gemäß Anspruch 7, bei dem der Dienst zur gemeinsamen Nutzung von Daten die Graphen-Datenstruktur mit dem Wert aktualisiert, falls der Wert einer aktuellen Transaktion entspricht.
Computersystem gemäß Anspruch 8, bei dem der Dienst zur gemeinsamen Nutzung von Daten den Wert des einen Datenelements verwirft, falls der Wert einer veralteten Transaktion entspricht.
Computersystem gemäß Anspruch 6, bei dem der Dienst zur gemeinsamen Nutzung von Daten die von dem ersten Softwaresystem empfangene Anfrage verwirft, falls das erste Softwaresystem inaktiv wird.
Verfahren zur gemeinsamen Nutzung von Daten zwischen Softwaresystemen, das umfasst: Speichern von Werten für Datenelemente, die von Softwaresystemen empfangen wurden, im Speicher, wobei die Datenelemente und die Beziehungen dazwischen semantisch beschrieben sind; Speichern von Anfragen, die von den Softwaresystemen empfangen wurden, wobei jede der Anfragen angefragte Daten semantisch kennzeichnet und eine Adresse umfasst; Bestimmen, welcher der Anfragen entsprochen wird, durch semantisches Zerlegen der angefragten Daten in mindestens eines der Datenelemente, und Bestimmen, ob einer der Werte der mindestens einen Datenelemente aktualisiert wurde; und Aufrufen für jede der entsprochenen Anfragen, der Adresse, die in der entsprochenen Anfrage gekennzeichnet ist, und Weiterleiten der Werte der Datenelemente, in die sich die die angefragten Daten semantisch zerlegen.
Verfahren gemäß Anspruch 11, bei dem das Bestimmen periodisch durchgeführt wird.
Verfahren gemäß Anspruch 11, das ferner umfasst: Empfangen eines Wertes für eines der Datenelemente von einem der Softwaresysteme.
Verfahren gemäß Anspruch 13, das ferner umfasst: Speichern des Wertes für das eine Datenelement, falls der Wert einer aktuellen Transaktion entspricht.
Verfahren gemäß Anspruch 14, das ferner umfasst: Verwerfen des Werts für das eine Datenelement, falls der Wert einer veralteten Transaktion entspricht.
Verfahren gemäß Anspruch 14, bei dem das Bestimmen als Antwort auf das Speichern durchgeführt wird.
Verfahren gemäß Anspruch 11, das ferner umfasst: Hinzufügen von semantischer Information, die die Datenelemente mit anderen Datenelementen in Beziehung setzt.
Computersystem zur gemeinsamen Nutzung von Daten zwischen Softwaresystemen, das umfasst: einem Dienst zur gemeinsamen Nutzung von Daten, der auf dem Computersystem läuft, wobei der Dienst zur gemeinsamen Nutzung von Daten Werte für Datenelemente, die von Softwaresystemen empfangen wurden, im Speicherspeichert, wobei die Datenelemente und Beziehungen dazwischen semantisch beschrieben sind, wobei der Dienst zur gemeinsamen Nutzung von Daten Anfragen speichert, die von den Softwaresystemen empfangen wurden, wobei jede der Anfragen angefragte Daten semantisch kennzeichnet und eine Adresse umfasst, der Dienst zur gemeinsamen Nutzung von Daten bestimmt, welcher der Anfragen entsprochen wird, durch semantisches Zerlegen der angefragten Daten in mindestens eines der Datenelemente, und bestimmt, ob einer der Werte des mindestens einen Datenelements aktualisiert wurde, und für jede der entsprochenen Anfragen die Adresse aufruft, die in der entsprochenen Anfrage gekennzeichnet ist, und die Werte der Datenelemente, in die sich die angefragten Daten semantisch zerlegen, weiterleitet.
Computersystem gemäß Anspruch 18, bei dem der Dienst zur gemeinsamen Nutzung von Daten bestimmt, welcher der Anfragen periodisch entsprochen wird.
Computersystem gemäß Anspruch 18, bei dem der Dienst zur gemeinsamen Nutzung von Daten eine Schnittstelle zum Empfangen eines Werts für eines der Datenelemente von einem der Softwaresysteme umfasst.
Computersystem gemäß Anspruch 20, bei dem der Dienst zur gemeinsamen Nutzung von Daten den Wert für das eine Datenelement speichert, falls der Wert einer aktuellen Transaktion entspricht.
Computersystem gemäß Anspruch 20, bei dem der Dienst zur gemeinsamen Nutzung von Daten den Wert für das eine Datenelement verwirft, falls der Wert einer veralteten Transaktion entspricht.
Computersystem gemäß Anspruch 21, bei dem der Dienst zur gemeinsamen Nutzung von Daten bestimmt, welcher der Anfragen entsprochen wird, als ein Ergebnis des Speicherns des Werts.
Computersystem gemäß Anspruch 18, bei dem der Dienst zur gemeinsamen Nutzung von Daten semantische Information hinzufügt, die die Datenelemente mit anderen Datenelementen in Beziehung setzt.
Computer-lesbares Medium, das darauf Computerausführbare Anweisungen gespeichert hat, die einen Dienst zur gemeinsamen Nutzung von Daten implementieren, wenn sie auf einem Computersystem ausgeführt werden, wobei der Dienst zur gemeinsamen Nutzung von Daten Werte für Datenelemente, die von Softwaresystemen empfangen wurden, im Speicherspeichert, die Datenelemente und Beziehungen dazwischen semantisch beschrieben sind, der Dienst zur gemeinsamen Nutzung von Daten Anfragen speichert, die von den Softwaresystemen empfangen wurden, wobei jede der Anfragen angefragte Daten semantisch kennzeichnet und eine Adresse umfasst, wobei der Dienst zur gemeinsamen Nutzung von Daten bestimmt, welcher der Anfragen entsprochen wird, durch semantisches Zerlegen der angefragten Daten in mindestens eines der Datenelemente, und bestimmt, ob einer der Werte des mindestens einen Datenelements aktualisiert wurde, und für jede der entsprochenen Anfragen die Adresse aufruft, die in der entsprochenen Anfrage gekennzeichnet ist, und die Werte der Datenelemente, in die sich die angefragte Daten semantisch zerlegen, weiterleitet.
Verfahren zum Ermöglichen einer gemeinsame Nutzung von Daten, das umfasst: Verfügbarmachen von Computer-ausführbaren Anweisungen über ein Netzwerk, wobei die Computer-ausführbaren Anweisungen einen Dienst zur gemeinsamen Nutzung von Daten implementieren, wenn sie auf einem Computersystem ausgeführt werden, der Dienst zur gemeinsamen Nutzung von Daten Werte für Datenelemente, die von Softwaresystemen empfangen wurden, im Speicher speichert, die Datenelemente und Beziehungen dazwischen semantisch beschrieben sind, der Dienst zur gemeinsamen Nutzung von Daten Anfragen speichert, die von den Softwaresystemen empfangen wurden, jede der Anfragen angefragte Daten semantisch kennzeichnet und eine Adresse umfasst, wobei der Dienst zur gemeinsamen Nutzung von Daten bestimmt, welcher der Anfragen entsprochen wurde, durch semantisches Zerlegen der angefragten Daten in mindestens eines der Datenelemente, und bestimmt, ob einer der Werte des mindestens einen Datenelements aktualisiert wurde, und für jede der entsprochenen Anfragen die Adresse aufruft, die in der entsprochenen Anfrage gekennzeichnet ist, und die Werte der Datenelemente, in die sich die angefragten Daten semantisch zerlegen, weiterleitet.