DE102009041256A1

DE102009041256A1 - Verfahren und Vorrichtung zum Ermöglichen einer persisten Anwendungsprogrammierungsschnittstelle

Info

Publication number: DE102009041256A1
Application number: DE200910041256
Authority: DE
Inventors: Jeffrey M. San Mateo Collins; Calum Santa Rosa Murray; Robert A. Fremont Luben; James Lee Los Gatos Showalter; Raymond J. San Jose Chapman
Original assignee: Intuit Inc
Current assignee: Intuit Inc
Priority date: 2008-10-10
Filing date: 2009-09-11
Publication date: 2010-04-15
Also published as: AU2009212935A1; GB0917486D0; CN101727318A; US20100095311A1; AU2009212935B2; US9135089B2; CN106095600A

Abstract

Eine Ausführungsform der vorliegenden Erfindung stellt ein System zum Implementieren einer Persistenz-Anwendungsprogrammierungsschnittstelle (API), welche plattformunabhängig ist und Aufwärts-Aufrufe an Geschäftslogik durchführen kann, bereit. Während eines Betriebs empfängt das System eine Anfrage bei der API, ein Kommando bei einer Persistenzschicht einer n-Schicht-verteilten Anwendung auszuführen. In Antwort auf die Anfrage bestimmt das System einen Entitätstypen für eine durch das Kommando betroffene Entität. Als Nächstes identifiziert das System eine Funktion bei einer Mittelschicht der n-Schicht-verteilten Anwendung, welche dem Entitätstypen und dem Kommando zugeordnet ist, wobei die Mittelschicht die Geschäftslogik umfasst. Das System sendet dann eine Anweisung an die Mittelschicht, die Funktion auszuführen. Schließlich führt das System das Kommando bei der Persistenzschicht auf Empfangen einer Bestätigung bei der API hin, dass die Funktion ausgeführt ist, aus.

Description

HINTERGRUND
Betreffende Technik
Um Leistungsfähigkeit und Skalierbarkeit zu verbessern, sind viele Web-basierte Anwendungen unter Benutzung einer Mehrschichtarchitektur (multi-tier architecture) aufgebaut, wobei die Web-basierte Anwendung über viele Server oder Cluster (Schichten (tiers)) verteilt ist, welche verschiedene Typen von Funktionalität bereitstellen. Zum Beispiel kann eine typische Web-basierte Anwendung von drei verschiedenen und unabhängigen Schichten umfasst sein: Eine Präsentationsschicht, welche als ein Zugang (front-end) für die Anwendung dient, welche als ein Zwischenstück zwischen den Benutzern und der Web-basierten Anwendung agiert; eine Geschäftsschicht (business tier), oder Mittelschicht (middle tier), welche die gesamte Geschäftslogik (business logic) der Web-basierten Anwendung umfasst; und eine Persistenzschicht, welche eine Datenbank oder ein anderes Speichersystem oder -gerät umfasst. Jede Schicht läuft unabhängig von den anderen Schichten und kann ersetzt oder aktualisiert werden, ohne die anderen Schichten nachteilig zu beeinflussen.
Trotz der vielen Vorteile von Mehrschicht-Web-Anwendungen haben diese Web-Applikationen einige Probleme. Zum Beispiel wird in vielen Umgebungen jede Schicht durch verschiedene Gruppen gewartet, welche wenig oder keine Kenntnis der anderen Schichten haben. Zum Beispiel wissen die Anwendungsprogrammierer, welche die Geschäftslogik erzeugen, typischerweise über die Implementationsdetails der Persistenzschicht nicht Bescheid. Weiterhin wissen Datenbankadministratoren typischerweise nicht viel über die Geschäftslogik. Dies kann problematisch sein, wenn eine komplexe Operation viele Interaktionen zwischen den Schichten involviert. Wenn zum Beispiel eine Aktualisierung für einen Datensatz in einer Datenbank eine sekundäre Aktualisierung für eine zweite Tabelle auslöst, kann es notwendig sein, dass die sekundäre Aktualisierung für die zweite Tabelle durch die Geschäftslogik überprüft wird, um sicherzustellen, dass die sekundäre Aktualisierung die definierten Geschäftsbeschränkungen und -regeln befolgt. In diesem Beispiel müsste die Persistenzschicht die sekundäre Aktualisierung an die Mittelschicht zurücksenden (ein ”Aufwärts-Aufruf” (”up-call”)), so dass die Mittelschicht diese Überprüfung durchführen kann.
In einigen Mehrschichtanwendungen sind spezielle Auslöser (triggers) oder gespeicherte Prozeduren (stored procedures) bei der Persistenzschicht implementiert, um diese Aufwärts-Aufrufe an die Geschäftsschicht falls notwendig durchführen. Diese Implementationen involvieren jedoch ein Verwischen der Schichtgrenzen und können eine Organisation an eine spezifische Implementation oder einen spezifischen Persistenzschichtanbieter binden.
ZUSAMMENFASSUNG
Eine Ausführungsform der vorliegenden Erfindung stellt ein System zum Implementieren einer Persistenz-Anwendungsprogrammierungsschnittstelle (API) bereit, welche plattformunabhängig ist und Aufwärts-Aufrufe an Geschäftslogik durchführen kann. Während eines Betriebs empfängt das System eine Anfrage bei der API, ein Kommando bei einer Persistenzschicht einer n-Schicht-verteilten Anwendung auszuführen. In Antwort auf die Anfrage bestimmt das System einen Entitätstypen für eine durch das Kommando betroffene Entität. Als Nächstes identifiziert das System eine Funktion bei einer Mittelschicht der n-Schicht-verteilten Anwendung, welche dem Entitätstypen und dem Kommando zugeordnet ist, wobei die Mittelschicht die Geschäftslogik umfasst. Das System sendet dann eine Anweisung an die Mittelschicht, die Funktion auszuführen. Schließlich führt das System das Kommando bei der Persistenzschicht auf Empfangen einer Bestätigung bei der API hin, dass die Funktion ausgeführt ist, aus.
Wenn das System die Anweisung an die Mittelschicht sendet, die Funktion auszuführen, sendet in einigen Ausführungsformen der vorliegenden Erfindung das System auch das Kommando an die Mittelschicht, wobei ein Teil des Kommandos als ein Parameter für die Funktion benutzt wird.
In einigen Ausführungsformen der vorliegenden Erfindung empfängt das System eine zweite Anfrage von der Mittelschicht bei der API, ein zweites Kommando bei der Persistenzschicht auszuführen.
In Antwort auf die zweite Anfrage bestimmt das System in einigen Ausführungsformen der vorliegenden Erfindung einen zweiten Entitätstypen für eine zweite durch das zweite Kommando betroffene Entität. Als Nächstes identifiziert das System eine zweite Funktion bei der Mittelschicht der n-Schicht-verteilten Anwendung, welche dem zweiten Entitätstypen und dem zweiten Kommando zugeordnet ist. Das System sendet dann eine zweite Anweisung an die Mittelschicht, die zweite Funktion auszuführen. Schließlich führt das System auf Empfangen einer zweiten Bestätigung bei der API hin, dass die zweite Funktion ausgeführt ist, das zweite Kommando bei der Persistenzschicht aus.
In einigen Ausführungsformen der vorliegenden Erfindung erzeugt das System eine Transaktion bei der API, welche die Anweisung und/oder das Kommando umfasst. Als Nächstes bestimmt das System, ob die Funktion bei der Mittelschicht erfolgreich ausgeführt wurde und ob das Kommando bei der Persistenzschicht erfolgreich ausgeführt wurde. Wenn dem so ist, führt das System die Transaktion durch. Wenn dem jedoch nicht so ist, macht das System die Transaktion rückgängig.
In einigen Ausführungsformen der vorliegenden Erfindung erzeugt das System die Transaktion durch Erzeugen einer Persistenzschicht-Untertransaktion bei der Persistenzschicht. Man beachte, dass Durchführen der Transaktion Durchführen der Persistenzschicht-Untertransaktion umfasst, und dass Zurücknehmen der Transaktion Zurücknehmen der Persistenzschicht-Untertransaktion umfasst.
In einigen Ausführungsformen der vorliegenden Erfindung umfasst die Persistenzschicht eine relationale Datenbank.
Vor Identifizieren der Funktion bei der Mittelschicht der n-Schicht-verteilten Anwendung empfängt das System in einigen Ausführungsformen der vorliegenden Erfindung eine Registrierung bei der API, welche die Funktion und den zugeordneten Entitätstypen und das zugeordnete Kommando identifiziert.
In einigen Ausführungsformen der vorliegenden Erfindung werden die Schritte von Identifizieren der Funktion bei der Mittelschicht und Senden der Anweisung an die Mittelschicht durch einen Orchestrierungsdeligierten abgewickelt, wobei der Orchestrierungsdeligierte die Ausführung von vorher bei der API registriertem Code anordnet, wenn eine Registrierungsbedingung erfüllt ist.
KURZE BESCHREIBUNG DER FIGUREN
1 illustriert eine Computerumgebung in Übereinstimmung mit einer Ausführungsform der vorliegenden Erfindung.
2 illustriert eine Vorrichtung in Übereinstimmung mit einer Ausführungsform der vorliegenden Erfindung.
3 präsentiert ein zugeordnetes Flussdiagramm, welches den Prozess eines Ermöglichens einer Persistenz-Anwendungsprogrammierungsschnittstelle (API) illustriert, welche plattformunabhängig ist und Aufwärts-Aufrufe an Geschäftslogik durchführen kann, in Übereinstimmung mit einer Ausführungsform der vorliegenden Erfindung illustriert.
DETAILLIERTE BESCHREIBUNG
Die vorliegende Beschreibung ist präsentiert, um irgend einen Fachmann in der Technik zu befähigen, die offenbarten Ausführungsformen auszuführen und zu benutzen, und ist im Kontext einer bestimmten Anwendung und ihrer Anforderungen bereitgestellt. Verschiedene Modifikationen zu den offenbarten Ausführungsformen werden leicht für die Fachleute in der Technik offensichtlich sein, und die hierin definierten allgemeinen Prinzipien können auf andere Ausführungsformen und Anwendungen angewendet werden, ohne von dem Geist und dem Geltungsbereich der vorliegenden Erfindung abzuweichen. Somit ist die vorliegende Erfindung nicht beabsichtigt, auf die gezeigten Ausführungsformen begrenzt zu sein, sondern ist in dem breitesten Geltungsbereich zu gewähren, welcher mit den hierin offenbarten Prinzipien und Merkmalen konsistent ist.
Die Datenstrukturen und Code, welche bzw. welcher in dieser detaillierten Beschreibung beschrieben sind, sind typischerweise auf einem computerlesbaren Speichermedium gespeichert, welches irgend ein Gerät oder Medium sein kann, welches Code und/oder Daten zur Benutzung durch ein Computersystem speichern kann. Das computerlesbare Speichermedium umfasst, ist jedoch nicht darauf beschränkt, volatilen Speicher, nicht-volatilen Speicher, magnetische und optische Speichergeräte, wie etwa Festplattenlaufwerke, Magnetband, CDs (compact discs), DVDs (digitale versatile Platten (digital versatile discs) oder digitale Videoplatten (digital video discs)), oder irgend welche anderen Medien, welche befähigt sind, computerlesbare Medien zu speichern, welche bekannt sind oder später entwickelt sind.
Die in dem detaillierten Beschreibungsabschnitt beschriebenen Verfahren und Prozesse können als Code und/oder Daten verkörpert sein, welche in einem computerlesbaren Speichermedium gespeichert sind, wie oben beschrieben. Wenn ein Computersystem den Code und/oder Daten, welcher bzw. welche auf dem computerlesbaren Speichermedium gespeichert sind, liest und ausführt, führt das Computersystem die Verfahren und Prozesse durch, welche als Datenstrukturen und Code verkörpert sind und innerhalb des computerlesbaren Speichermediums gespeichert sind.
Weiterhin können die unten beschriebenen Verfahren und Prozesse in Hardware-Modulen umfasst sein. Zum Beispiel können die Hardware-Module umfassen, sind jedoch nicht darauf beschränkt, anwendungsspezifische integrierte Schaltkreis-(ASIC)-Cips, feldprogrammierbare Gategatter (field-programmable gate arrays) (FPGAs), und andere programmierbare-Logik-Geräte, welche nun bekannt sind oder später entwickelt sind. Wenn die Hardware-Module aktiviert werden, führen die Hardware-Module die Verfahren und Prozesse aus, welche innerhalb der Hardware-Module umfasst sind.
Überblick
Eine Ausführungsform der vorliegenden Erfindung stellt ein System zum Implementieren einer Persistenz-Anwendungsprogrammierungsschnittstelle (API) bereit, welche plattformunabhängig ist und Aufwärts-Aufrufe an Geschäftslogik durchführen kann. Während eines Betriebs empfängt das System eine Anfrage bei der API, ein Kommando bei einer Persistenzschicht einer n-Schicht-verteilten Anwendung auszuführen. In Antwort auf die Anfrage bestimmt das System einen Entitätstypen für eine durch das Kommando betroffene Entität. Als Nächstes identifiziert das System eine Funktion bei einer Mittelschicht der n-Schicht-verteilten Anwendung, welche dem Entitätstypen und dem Kommando zugeordnet ist, wobei die Mittelschicht die Geschäftslogik umfasst. Das System sendet dann eine Anweisung an die Mittelschicht, die Funktion auszuführen. Schließlich führt das System das Kommando bei der Persistenzschicht auf Empfangen einer Bestätigung bei der API hin, dass die Funktion ausgeführt ist, aus.
Zum Beispiel können alle Aufrufe an die Persistenzschicht durch die Persistenz-API abgewickelt werden. Die Persistenz-API ermöglicht der Web-basierten Anwendung, Daten in der Datenbank zu sichern und dabei Geschäftslogik auszuführen, welche die Gültigkeit überprüft, Buchführung durchführt, etc. Die Persistenz-API ermöglicht, Mittelschichtlogik von der Persistenzschicht aus aufzurufen, was tatsächlich ein Aufwärts-Aufruf von einer niedrigeren Schicht an eine höhere Schicht ist. Diese Aufwärts-Aufrufe werden ohne den Programmierer durchgeführt, ohne dass der Programmierer, welcher den Mittelschichtcode schreibt, irgend eine Kenntnis über die Implementation der Persistenzschicht hat. Man beachte, dass die Persistenzschicht-API der Mittelschichtlogik ermöglicht, keine Persistenzdetails wissen zu müssen. Zusätzlich ermöglicht die Persistenz-API der Web-basierten Anwendung, portierbar über Datenbanken, objektrelationale (OR)-Abbildungen (object relational(OR)-mappers), Sprachen (wie etwa Java^TM und C#^®) und Plattformen (wie etwa Windows^® und Unix^®) zu bleiben.
Wenn das System die Anweisung an die Mittelschicht sendet, die Funktion auszuführen, sendet in einigen Ausführungsformen der vorliegenden Erfindung das System auch das Kommando an die Mittelschicht, wobei ein Teil des Kommandos als ein Parameter für die Funktion benutzt wird.
In einigen Ausführungsformen der vorliegenden Erfindung empfängt das System eine zweite Anfrage von der Mittelschicht bei der API, ein zweites Kommando bei der Persistenzschicht auszuführen. Man beachte, dass die Mittelschicht zusätzliche Anfragen an die Persistenz-API senden kann, während die Mittelschicht dem Kommando zugeordneten Code ausführt. Weiterhin kann jede dieser zusätzlichen Anfragen wiederum zu noch mehr zusätzlichen Anfragen führen.
In Antwort auf die zweite Anfrage bestimmt das System in einigen Ausführungsformen der vorliegenden Erfindung einen zweiten Entitätstypen für eine zweite durch das zweite Kommando betroffene Entität. Als Nächstes identifiziert das System eine zweite Funktion bei der Mittelschicht der n-Schicht-verteilten Anwendung, welche dem zweiten Entitätstypen und dem zweiten Kommando zugeordnet ist. Das System sendet dann eine zweite Anweisung an die Mittelschicht, die zweite Funktion auszuführen. Schließlich führt das System auf Empfangen einer zweiten Bestätigung bei der API hin, dass die zweite Funktion ausgeführt ist, das zweite Kommando bei der Persistenzschicht aus.
In einigen Ausführungsformen der vorliegenden Erfindung erzeugt das System eine Transaktion bei der API, welche die Anweisung und/oder das Kommando umfasst. Als Nächstes bestimmt das System, ob die Funktion bei der Mittelschicht erfolgreich ausgeführt wurde und ob das Kommando bei der Persistenzschicht erfolgreich ausgeführt wurde. Wenn dem so ist, führt das System die Transaktion durch. Wenn dem jedoch nicht so ist, macht das System die Transaktion rückgängig. Man beachte, dass die Transaktionen von der Persistenz-API erzeugt, durchgeführt und rückgängig gemacht werden.
In einigen Ausführungsformen der vorliegenden Erfindung erzeugt das System die Transaktion durch Erzeugen einer Persistenzschicht-Untertransaktion bei der Persistenzschicht. Man beachte, dass Durchführen der Transaktion Durchführen der Persistenzschicht-Untertransaktion umfasst, und dass Zurücknehmen der Transaktion Zurücknehmen der Persistenzschicht-Untertransaktion umfasst. In diesen Ausführungsformen setzt die Persistenz-API das existierende Transaktionssystem der Datenbank ein.
In einigen Ausführungsformen der vorliegenden Erfindung umfasst die Persistenzschicht eine relationale Datenbank. Während viele Ausführungsformen der vorliegenden Erfindung eine relationale Datenbank benutzen, beachte man, dass im Allgemeinen irgend ein Type von Datenspeicher benutzt werden kann. In einigen Ausführungsformen kann dies ein XML-basiertes Dateimanagementsystem umfassen.
Vor Identifizieren der Funktion bei der Mittelschicht der n-Schicht-verteilten Anwendung empfängt das System in einigen Ausführungsformen der vorliegenden Erfindung eine Registrierung bei der API, welche die Funktion und den zugeordneten Entitätstypen und das zugeordnete Kommando identifiziert. Man beachte, dass ein Programmierer lediglich eine spezifische Funktion mit dem zugeordneten Entitätstypen und Kommando registrieren muss und nicht irgend etwas anderes über die Persistenzschicht wissen muss.
Zum Beispiel kann der Programmierer eine spezifische Funktion registrieren, welche Geschäftsregeln für die Hinzufügung eines neuen Kunden anwendet, wenn die API ein Kommando empfängt, welches einen neuen Datensatz in eine Kundentabelle eingibt.
In einigen Ausführungsformen der vorliegenden Erfindung werden die Schritte von Identifizieren der Funktion bei der Mittelschicht und Senden der Anweisung an die Mittelschicht durch einen Orchestrierungsdeligierten abgewickelt, wobei der Orchestrierungsdeligierte die Ausführung von vorher bei der API registriertem Code anordnet, wenn eine Registrierungsbedingung erfüllt ist.
Man beachte, dass der Orchestrierungsdeligierte aktiv diese Anweisungen an die Mittelschicht sendet, sowie die Kommandos bei der API ausgeführt werden. Alternativ könnte das System ein Registrierungsmodell anstelle des Orchestrierungsdeligierten benutzen, wobei die Funktionen bei der Mittelschicht konfiguriert sind, auf spezifische Ereignisse bei der API zu horchen.
In einer Ausführungsform der vorliegenden Erfindung ist eine ”der Speicher” (”the Repository”) genannte API die öffentliche API für alle Persistenzoperationen. Die Implementation dieser API: analysiert den hereinkommenden Graphen von Entitäten und gewöhnlichen Objekten; bestimmt, welche Artikel neu sind und welche Artikel Aktualisierungen für existierende Artikel sind; tauscht Kompositionskinder (composition children) gegen Kompositionseltern (composition parents) aus; setzt Einschränkungen durch; und ruft einen Logikdeligierten auf, welcher die tatsächlichen Persistenzoperationen (Erzeugen, Lesen, Aktualisieren und Löschen) durchführt. Der Logikdeligierte ruft auch Mittelschichtlogik auf, welche als ein oder mehr Orchestrierungsatome implementiert ist, welche bei dem System registriert sind. Die Mittelschichtlogik kann beliebig komplexe Operationen durchführen, was Durchführen von zusätzlichen Aufrufen an den Speicher umfasst. Der Speicher erledigt auch Starten, Durchführen und Zurücknehmen von Transaktionen.
Computerumgebung
1 illustriert eine Computerumgebung 100 in Übereinstimmung mit einer Ausführungsform der vorliegenden Erfindung. Computerumgebung 100 umfasst eine Anzahl von Computersystemen, welche im Allgemeinen irgend einen Typ von Computersystem basierend auf einem Mikroprozessor, einem Mainframe-Computer, einem digitalen Signalprozessor, einem tragbaren Computergerät, einem persönlichen Organisator, einer Gerätesteuerung, oder einer Rechenmaschine innerhalb eines Gerätes umfassen. Mit Bezug auf 1 umfasst Computerumgebung 100 insbesondere Klienten 110–112, Benutzer 120 und 121, Server 130–150, Netzwerk 160, Datenbank 170, Geräte 180 und Apparat 190.
Klienten 110–112 können irgend einen Knoten auf einem Netzwerk, welches Rechenfähigkeit und einen Mechanismus zum Kommunizieren über das Netzwerk umfasst, umfassen. Zusätzlich können Klienten 110–112 eine Schicht in einer n-Schicht-Anwendungsarchitektur umfassen, wobei Klienten 110–112 als Server auftreten (welche Anfragen von niedrigeren Schichten oder Benutzern bedienen), und wobei Klienten 110–112 als Klienten auftreten, (welche die Anfragen an eine höhere Schicht weiterleiten).
Ähnlich können Server 130–150 im Allgemeinen irgend einen Knoten auf einem Netzwerk umfassen, wobei der Knoten einen Mechanismus zum Bedienen von Anfragen nach Rechen- und/oder Datenspeicherressourcen von einem Klienten umfasst. Server 130–150 können in einem hochentwickelten Computercluster teilnehmen oder können als alleinstehende Server fungieren. In einer Ausführungsform der vorliegenden Erfindung ist Server 140 ein eingeschalteter ”heißer Ersatz” (online ”hot spare”) von Server 150.
Benutzer 120 und 121 können umfassen: ein Individuum; eine Gruppe von Individuen; eine Organisation; eine Gruppe von Organisationen; ein Computersystem; eine Gruppe von Computersystemen; oder irgend eine andere Entität, welche mit Computerumgebung 100 interagieren kann.
Netzwerk 160 kann irgend einen Typ von kabelumfassendem oder kabellosem Kommunikationskanal umfassen, welcher befähigt ist, Computerknoten miteinander zu koppeln. Dies umfasst, ist jedoch nicht darauf beschränkt, ein Lokalbereichsnetzwerk (local area network), ein Fernbereichsnetzwerk (wide area network), oder eine Kombination von Netzwerken. In einer Ausführungsform der vorliegenden Erfindung umfasst Netzwerk 160 das Internet. In einigen Ausführungsformen der Erfindung umfasst Netzwerk 160 Telefon- und Mobiltelefonnetzwerke.
Datenbank 170 kann irgend einen Typ von System zum Speichern von Daten in einem nicht volatilen Speicher umfassen. Dies umfasst, ist jedoch nicht darauf beschränkt, Systeme, welche auf magnetischen, optischen, oder magneto-optischen Speichergeräten basieren, sowie Speichergeräte, welche auf Flashspeicher und/oder batterieunterstütztem Speicher basieren. Man beachte, dass Datenbank 170 gekoppelt sein kann: an einen Server (wie etwa Server 150), an einen Klienten, oder direkt an ein Netzwerk.
Geräte 180 können irgend einen Typ eines elektronischen Geräts umfassen, welches an einen Klienten, wie etwa Klienten 112, gekoppelt werden kann. Dies umfasst, ist jedoch nicht darauf beschränkt, Mobiltelefone (cell phones), persönliche digitale Assistenten (personal digital assistants) (PDAs), Smart-Telefone (smart-phones), persönliche Musikabspielgeräte (wie etwa MP3-Abspielgeräte), Spielsysteme, digitale Kameras, tragbare Speichermedien, oder irgend ein anderes Gerät, welches mit dem Klienten gekoppelt werden kann. Man beachte, dass in einigen Ausführungsformen der vorliegenden Erfindung Geräte 180 direkt mit Netzwerk 160 gekoppelt werden können und in derselben Weise als Klienten 110–112 fungieren können.
Apparat 190 kann irgend einen Typ von Apparat umfassen, welcher mit Netzwerk 160 gekoppelt werden kann. Dies umfasst, ist jedoch nicht darauf beschränkt, Vermittlungsknoten (routers), Schalter (switches), Lastausgleicher (load balancers), Netzwerkbeschleuniger (network accelerators), und Spezialprozessoren. Apparat 190 kann als ein Portal (gateway), ein Proxy, oder ein Übersetzer (translater) zwischen Server 140 und Netzwerk 160 agieren.
Man beachte, dass verschiedene Ausführungsformen der vorliegenden Erfindung verschiedene Systemkonfigurationen benutzen können und nicht auf die in Computerumgebung 100 illustrierte Systemkonfiguration beschränkt sind. Im Allgemeinen kann irgend ein Gerät, welches befähigt ist, über Netzwerk 160 zu kommunizieren, Elemente der vorliegenden Erfindung aufnehmen.
Zum Beispiel benutzt in einer Ausführungsform der vorliegenden Erfindung Benutzer 120 Klient 110, um auf eine n-Schicht-Web-basierte Anwendung, welche auf Servern 140 und 150 gehostet ist, und Datenbank 170 zuzugreifen. In dieser Ausführungsform dient Server 140 als die Präsentationsschicht und wickelt alle Interaktionen mit Benutzer 120 und Klient 110 ab. Zusätzlich umfasst Server 150 die Geschäftsschicht oder Mittelschicht und umfasst die gesamte Geschäftslogik. Schließlich umfasst Datenbank 170 die Persistenzschicht und stellt den Datenspeicher für die Web-basierte Anwendung bereit.
Vorrichtung
2 illustriert eine Vorrichtung 200 und 3 präsentiert ein zugeordnetes Flussdiagramm, welches den Prozess eines Ermöglichens einer Persistenz-Anwendungsprogrammierungsschnittstelle (API), welche plattformunabhängig ist und Aufwärts-Aufrufe an Geschäftslogik durchführen kann, in Übereinstimmung mit einer Ausführungsform der vorliegenden Erfindung illustriert.
Vorrichtung 200, welche zum Beispiel Server 150, Datenbank 170, Apparat 190, Klient 110, Geräte 180 oder irgend eine Kombination davon umfassen kann, umfasst einen Empfangsmechanismus (Empfangsmittel) 202, Bestimmungsmechanismus (Bestimmungsmittel) 204, Identifikationsmechanismus (Identifikationsmittel) 206, Sendemechanismus (Sendemittel) 208, Ausführungsmechanismus (Ausführungsmittel) 210, Prozessor 214 und Speicher 216.
Während eines Betriebs empfängt Empfangsmechanismus 202 eine Anfrage bei der API, ein Kommando bei einer Persistenzschicht einer n-Schicht-verteilten Anwendung auszuführen (Operation 302). Als Nächstes bestimmt Bestimmungsmechanismus 204 einen Entitätstypen für eine durch das Kommando betroffene Entität in Antwort auf die Anfrage (Operation 304). Zum Beispiel könnte das Kommando eine Aktualisierung für einen Angestelltendatensatz umfassen, um das Angestelltengehalt abzugleichen. In diesem Beispiel wäre der Entitätstyp die Angestelltentabelle.
Identifikationsmechanismus 206 identifiziert dann eine Funktion bei einer Mittelschicht der n-Schicht-verteilten Anwendung, welche dem Entitätstypen und dem Kommando zugeordnet ist (Operation 306), wobei die Mittelschicht die Geschäftslogik umfasst. Zum Beispiel könnte die Funktion überprüfen, dass das Gehalt innerhalb eines erlaubten Bereichs ist und dass die das Kommando erstellende Person genügende Rechte dazu hat.
An diesem Punkt kann die API optional eine Transaktion starten (Operation 307). Wie vorher beschrieben, kann in einigen Ausführungsformen der vorliegenden Erfindung die API ein existierendes Transaktionssystem, welches Teil der Datenbank 170 ist, einsetzen.
Als Nächstes sendet Sendemechanismus 208 eine Anweisung an die Mittelschicht, die Funktion auszuführen (Operation 308). Auf Empfangen einer Bestätigung bei der API hin, dass die Funktion ausgeführt ist, führt Ausführungsmechanismus 210 das Kommando bei der Persistenzschicht aus (Operation 310). Falls die API vorher eine Transaktion startete und falls die Funktion und das Kommando erfolgreich ausgeführt wurden, führt die API schließlich die Transaktion durch (Operation 312).
Beispielhafte Ausführungsform
Der folgende Abschnitt beschreibt eine Ausführungsform der vorliegenden Erfindung lediglich für beispielhafte Zwecke. Man beachte, dass die vorliegende Erfindung nicht beabsichtigt ist, auf die in dieser Ausführungsform beschriebenen Details beschränkt zu sein.
Diese Ausführungsform stellt ein System bereit, wobei Persistenz von Objekten durch eine Entitätsdienst-API (Entity Service API) kontrolliert wird, wobei der Entitätsdienst Hibernate aufruft, um CRUD-(Erzeugen, Lesen, Aktualisieren, Löschen)-Operationen durchzuführen.
Man beachte, dass es Hibernate unter Benutzung seines internen Mechanismus' zum Detektieren von unreinen Objekten und zum Implementieren von Persistenz-durch-Erreichbarkeit (persistence-by-reachability) erledigt, zu bestimmen, was zu erzeugen, was zu aktualisieren und was zu löschen ist (wobei es automatisch bestimmt, was ausgeführt werden muss, um die Elemente in einem gesamten Objektgraphen oder in einem Satz von Objektgraphen zu CRUD).
Speicher, die öffentliche API für ausgedehneten Datenzugriff (Extensible Data Access) und Abstraktionsschicht oberhalb von Entitätsdienst, ruft Entitätsdienst nicht direkt für Erzeugen-, Aktualisieren- oder Löschen-Operationen auf. Statt dessen führt Speicher Erzeugen, Aktualisieren und Löschen durch Aufrufen von Erzeugen-, Aktualisieren- und Löschen-CRUD-Orchestrierungen aus.
Man beachte, dass CRUD-Orchestrierungen Implementationen der ICrudDelegate-Schnittstelle sind, welche in dem Speicherprojekt definiert ist.
Die CRUD-Orchestrierungdelegiertenschnittstelle ist sehr einfach und sieht wie folgt aus:
Während eines Systemhochlaufs wird eine CRUD-Orchestrierungsdelegiertenimplementation in Speicher durch Orchestrierungsinitialisierungscode delegiert. Wenn Speicheroperationen aufgerufen werden, überprüft Speicher, um zu sehen, ob ein CRUD-Orchestrierungsdelegierter in Speicher ist. Wenn es keinen CRUD-Orchestrierungsdelegierten gibt, führt Speicher CRUD-Operationen ohne Ausführen von Orchestrierungen durch. Wenn es jedoch einen CRUD-Orchestrierungsdelegierten gibt, arbeitet Speicher mit dem CRUD-Orchestrierungsdelegierten, um Gültigkeitslogik, andere Geschäftslogik und CRUD-Operationen korrekt auszuführen.
Für Kompositionsrelationen (composition relations) kann das System Hibernate den Objektgraphen persistieren lassen. Das System kann dieses tun, weil das System nur CRUD-Orchestrationen für Kompositionseltern (composition parents) definiert.
Für Zuordnungen zu Datenobjekten und für Hash-Funktionen (hash maps) von Datentypen lässt das System Hibernate den Graphen persistieren. Das System kann dies tun, weil CRUD-Orchestrierungen niemals für Datenobjekte oder Datentypen definiert sind. Für Zuordnungen unter Entitäten definiert das System jedoch CRUD-Orchestrierungen für beide Enden der Zuordnung und führt beide CRUD-Orchestrierungen aus. Man beachte, dass dies Koordination von CRUD-Orchestrierungsausführungen und -operationen erfordert, welche durch Hibernate für Kaskadenpersistenz (cascading persistence) für Zuordnungen durchgeführt werden.
Die folgende Diskussion beschreibt die Details, wie der Speicher Ausführung von CRUD-Orchestrierungen und Hibernate-Persistenz für Objektgraphabschließungen (object graph closures) von Entitäten handhabt, welche Sichern- und Löschen-APIs präsentiert sind.
Anforderungen und Anwendungsfälle
Als Erstes kann das System idealerweise eine API bereitstellen, welche ein intuitives Verhalten hat, leicht zu benutzen ist und korrekte Resultate erzeugt. Dies ist die Anforderung des obersten Niveaus. Alles Weitere in diesem Abschnitt aufgelistete ist beabsichtigt, diese Anforderung für Klienten der Speicher-API zu erfüllen. Die Klienten der API können zum Beispiel das Folgende tun:

1. Eine neue Kundenentität durch Sichern einer Rechnung (neu oder vorher gesichert), welche auf eine neue Kundenentität weist, erzeugen.
2. Eine vorher gesicherte Kundenentität durch Ändern derselben im Speicher, Zuordnen zu ihr von einer Rechnung und Sichern der Rechnung aktualisieren.
3. Eine vorher gesicherte Kundenentität, welche bereits einer Rechnung zugeordnet ist, durch Ändern der Kundenentität im Speicher und Sichern der Rechnung aktualisieren.

Das System kann auch einen ganzen Satz von Operationen unter einer einzigen Transaktion ablaufen lassen. Speicher muss eine Transaktion zu Beginn eines Aufrufs einer Speicheroperation (z. B. Sichern) starten und muss diese Transaktion beim Ende des Aufrufs durchführen. Wenn irgend etwas zu irgend einem Zeitpunkt während des Betriebs falsch läuft, muss Speicher die gesamte Transaktion rückgängig machen.
Das System kann auch doppelte Entitäten vor Senden von Feldern an den CRUD-Orchestrierungsdeligierten entfernen. In nicht trivialen Graphen von Entitäten und Datenobjekten ist es möglich (tatsächlich wahrscheinlich), dass dieselbe Entität über mehr als einen einzigen Pfad durch den Graph erreichbar sein wird. Zum Beispiel könnten zwei verschiedene Rechnungsentitäten auf dieselbe Kundenentität zeigen.
Um redundante Aufrufe von Orchestrierungslogik zu vermeiden, kann Speicher alle Duplikate von allen Feldern entfernen, bevor sie dem CRUD-Orchestrierungsdeligierten gesendet werden, so dass jede bestimmte Entität genau einmal durch die Orchestrierungsmaschine gesehen wird.
Das System kann konfiguriert sein, nur neue Entitäten zu senden, um Orchestrierungen zu erzeugen. Der CRUD-Orchestrierungsdeligierten-Erzeugen-Methode gesendete Felder sollten nur neue Entitäten enthalten (Entitäten, welche niemals vorher in der Datenbank gesichert worden sind).
Das System sollte nur vorher gesicherte Entitäten, welche momentan unrein sind, an Aktualisieren-Orchestrierungen senden.
Man beachte, dass der CRUD-Orchestrierungsdeligierten-Aktualisieren-Methode gesendete Felder nur Entitäten enthalten sollten, welche vorher in der Datenbank gesichert worden sind und nun unrein sind. Eine Entität ist unrein, wenn sich irgend eine ihrer einfachen Eigenschaften (properties) geändert hat, oder wenn sich irgend eine ihrer 1:1-Relationen von nicht-Null nach Null (unter der Annahme, dass sie Null sein können) oder von Null nach nicht-Null geändert hat, oder wenn irgend eine ihrer Kollektionsrelationen hinzugefügte oder gelöschte Elemente hatte.
Wenn zum Beispiel eine unidirektionale Zuordnung zwischen einer Quellenentität und einer Zielentität nicht länger existiert, kann Speicher die Quellenentität an den CRUD-Orchestrierungsdeligierten für Aktualisieren senden. Wenn ähnlich eine bidirektionale Zuordnung zwischen zwei Entitäten nicht länger existiert, kann Speicher beide Entitäten an den CRUD-Orchestrierungsdeligierten für Aktualisieren senden. Man beachte, dass dies impliziert, dass Relationen (1:1 und viele) hinzugefügte und gelöschte Elemente nachverfolgen sollten.
Das System sollte nur vorher gesicherte Entitäten an Löschen-Orchestrierungen senden. Außerdem sollten der CRUD-Orchestrierungsdeligierten-Löschen-Methode gesendete Felder nur Entitäten beinhalten, welche vorher in der Datenbank gesichert worden sind. Eine Entität kann aus einem von zwei Gründen gelöscht werden:

1. Der API-Klient ruft spezifisch Speicher-Löschen auf der Entität auf.
2. Die Entität ist ein Kompositionskind, welches von einer Kompensationsrelation (1:1 oder viele) entfernt worden ist und der Kompensationselter ist gesichert, was Löschen auf der entfernten Entität auslösen muss.

Das System kann CRUD-Orchestrierungen ausführen, welche entlang eines Vererbungspfades für eine Entität definiert sind. Zum Beispiel können Entitätsklassen Unterklassen von anderen Entitätsklassen bis zu irgend einer durch den Modellierer spezifizierten Tiefe sein. Wenn CRUD an einer Entität durchgeführt wird, welche Elternklassen in ihrem Vererbungspfad hat, können für die Elternklassen definierte CRUD-Orchestrierungen auf der Entität ablaufen gelassen werden. Mit anderen Worten können Orchestrierungen polymorph ausführen.
Man beachte, dass Speicher diese Anforderung nicht implementieren kann, weil er keine Elternentitätsinstanzen hat, um sie dem CRUD-Orchestrierungsdeligierten zu übergeben. Statt dessen kann diese Anforderung vollständig innerhalb des Orchestrierungs-CRUD-Orchestrierungsdelegierten durch Wandern entlang des Vererbungspfades und Ablaufenlassen der für jede Entitätsklasse in dem Pfad definierten Orchestrierungen implementiert werden.
Das System kann auch Löschen von neuen Entitäten verhindern. Wenn Speicher-Löschen auf einer neuen Entität aufgerufen wird, kann eine Ausnahme (exception) geworfen werden. (Man beachte, dass dies schon durch Entitätsdienst erledigt wird.)
Das System kann anstatt von Erweiterungen (extensions) erweiterte Entitäten (extended entities) an CRUD-Orchestrierungsdeligierten senden. Wenn eine CRUD-Operation auf einer Erweiterung durchgeführt wird, kann Speicher die Erweiterung durch die Entität ersetzen, welche sie erweitert, und kann die erweiterte Entität an den CRUD-Orchestrierungsdeligierten senden, anstatt ihm die ursprüngliche Erweiterung zu geben. Es gibt zwei Gründe für diese Anforderung:

1. Eine Erweiterung kann eine von n Erweiterungen einer bestimmten Entität sein. Damit CRUD-Orchestrierungen korrekt ausführen, sollten sie nicht genau an der Erweiterung ausführen, sondern auch an der erweiterten Entität und an allen anderen Erweiterungen der erweiterten Entität. Durch Umdrehen der Erweiterungen auf die Entität, welche sie erweitert, vor Aufrufen des CRUD-Orchestrierungsdeligierten, werden alle Orchestrierungen korrekt ausgeführt. Man beachte, dass dies erfordert, dass Orchestrierungserweiterung richtig arbeitet.
2. In composita (composites) können die der erweiterten Entität zugeordneten Orchestrierungen aufgehoben (overriden) werden, aber dieses wird nicht korrekt funktionieren, es sei denn dem CRUD-Orchestrierungsdeligierten wird die erweiterte Entität anstatt der Erweiterung übergeben.

Das System sollte dem CRUD-Orchestrierungsdeligierten auch nur Kompositionselternentitäten senden. Wenn Speicher-Sichern oder -Löschen auf einer Kompositionskinderentität aufgerufen wird, welche neu oder unrein ist, sollte Speicher die Kinderentität durch die Elternentität ersetzen und dem CRUD-Orchestrierungsdeligierten die Elternentität senden, anstatt ihm die Kinderentität zu geben. Wenn die Elternentität neu ist, kann Speicher dem CRUD-Orchestrierungsdeligierten die Elternentität zum Erzeugen senden. Wenn die Elternentität nicht neu ist, kann Speicher dem CRUD-Orchestrierungsdeligierten die Elternentität zur Aktualisierung senden.
Wenn die Entität, welche die Kinderentität besitzt, selbst ein Kind in einer Kompositionsrelation ist, kann Speicher dem CRUD-Orchestrierungsdeligierten den Elter des Elter geben, anstatt ihm den Elter zu geben, usw. bis die transitive Abschließung der Kompositionsrelationen nach oben erschöpft ist. Nur der letztendliche Elter einer Kette von Kompositionen sollte dem CRUD-Orchestrierungsdeligierten für Aktualisieren oder Erzeugen gegeben werden.
Wenn zum Beispiel As Bs besitzt und Bs besitzt Cs, sollte es nur eine für As definierte Orchestrierung geben und diese Orchestrierung muss sämtliche Geschäftslogik, welche sowohl für Bs als auch Cs notwendig ist, erledigen.
Man beachte, dass diese Anforderung die vorherige Anforderung über Erweiterungen umfasst, da Erweiterungen als bidirektionale 1:1-Kompositionen abgebildet werden, mit der Erweiterung als dem Kind. Wegen der Unteranforderung, dass Orchestrierungen auf allen Erweiterungen der erweiterten Entität ablaufen sollten, ist es jedoch wichtig, spezifisch den Erweiterungsfall aufzurufen.
Führe folgend auf Persistenz der Wurzelentität CRUD-Orchestrierungen aus
Dieser Abschnitt kapselt einen revidierten Zugang für Ausführung von CRUD-Orchestrierungen als Teil von Speicherpersistenzoperationen. Der ursprüngliche Entwurfspfad zum Durchführen von automatischen CRUD-Orchestrierungen von Entitätsobjekten, welche Speicher-Sichern- und -Löschen-Operationen zugeführt wurden, involvierte ein Einsammeln von allen Kandidatentitätsobjekten von Graphabschließungen von zugeführten Objekten und ein Übergeben von ihnen an den CRUD-Orchestrierungsdeligierten in Bündeln (batches) von homogenen Entitätstypen, wobei sowohl Entitätsdienstpersistenzoperationen als auch CRUD-Orchestrierungen durchgeführt würden.
Ein enges Koppeln von Entitätspersistenz und CRUD-Orchestrierungen funktioniert gut für jedes an Speicher- Sichern- und -Löschen-Methoden übergebenes Entitätsobjekt. Es präsentiert jedoch Herausforderungen, wenn versucht wird, CRUD-Orchestrierungen für Entitäten durchzuführen, welche indirekt als Teil der Objektgraphabschließung einer Entität, welche an den Speicher in einer Sichern- oder Löschen-Operation übergeben wurde, persistiert sind. Eine Entität, welche für implizite Persistenz bestimmt ist, kann leicht von der Objektgraphabschließung einer Eingabeentität identifiziert werden. Das Problem ist, wie solch eine Entität an den CRUD-Orchestrierungsdeligierten zu übergeben ist, wobei sowohl CRUD-Orchestrierungen als auch Persistenz durchgeführt werden, ohne Konflikte in der Persistenzschicht aufzuwerfen. Zum Beispiel wird Sichern einer neuen Entität, welche in der Objektgraphabschließung einer an Speicher.Sichern(T) übergebenen Entität gefunden wird, eine Ausnahme erzeugen, wenn bereits als Teil eines Sicherns der Eingabeentität persistiert.
Anstatt Einschränkungen an Persistenzkonfiguration einzuführen oder Beschränkungen auf das Ausmaß von erlaubten automatischen CRUD-Orchestrierungen aufzuerlegen, maximiert ein alternativer Plan Ausführung von automatischen CRUD-Orchestrierungen für alle Entitäten, welche durch Speicher-Sichern- und -Löschen-Operationen betroffen sind. Die Idee ist, Entitäten in zwei Schritten zu prozessieren, wobei nur eine einzelne Entität zu einer gegebenen Zeit an den CRUD-Orchestrierungsdeligierten übergeben wird. Zuerst führt das System Persistenz und CRUD-Orchestrierungen für jede der Speicheroperation zugeführte Entität durch. Tatsächlich kann die an den CRUD-Orchestrierungsdeligierten übergebene Entität der Kompositionswurzelelter sein, wenn zugeführte Entität ein Kompositionskind oder die erweiterte Entität einer zugeführten Entitätserweiterung ist. Die dem CRUD-Orchestrierungsdeligierten in diesem Schritt weitergeleitete Entität kann die ”Wurzelentität” genannt werden. Man beachte, dass die Wurzelentität persistiert ist und dass registrierte CRUD-Orchestrierungen ausgeführt werden.
Zu diesem Zeitpunkt sind CRUD-Orchestrierungen für diejenigen Entitäten, welche indirekt persistiert sind, nicht durchgeführt worden und stehen aus. Man bedenke, dass sie als Teil von Wurzelentitätspersistenz persistiert werden. Der zweite Schritt involviert ein Senden jeder dieser Entitäten an den CRUD-Orchestrierungsdeligierten. Dabei lassen die Entitäten CRUD-Orchestrierungen laufen und werden für ein zweites Mal an den Persistenzmanager übergeben. In Fällen, in welchen eine existierende Entität bereits aktualisiert wurde und nun wieder aktualisiert wird, wird Hibernate Aktualisierungsanfragen als eine einzelne innerhalb derselben Transaktion verbinden. Im Wesentlichen wird ein zweites Sichern eine nicht-op. Persistenzkonflikte könnten noch auftreten, wie etwa der Fall, in welchem eine neue Entität vorher als Teil einer Wurzelentitäts-Sichern-Operatöion indirekt persistiert wurde. Erkennen von verschiedenen Typen von Konflikten mit Persistenz einer bereits persistierten Entität und Codieren um diese herum ermöglicht eine größere Abdeckung für automatische CRUD-Orchestrierungen.
Neue Entitäten in der Objektgraphabschließung einer Wurzelentität, welche bereits persistiert sind, wenn die Wurzelentität gesichert ist, sollten der Persistenzschicht nicht wieder in derselben Transaktion präsentiert werden. Innerhalb des CRUD-Orchestrierungsdeligierten kann eine Entität auf den Wert von isNew() untersucht werden. Wenn der Wert wahr ist und die Entität einen ID-Wert hat (was anzeigt, dass eine Instanz in einem früheren Sichern erzeugt wurde), hat sie CRUD-Orchestrierungen ausführen lassen und wird nicht wieder persistiert.
In Speicher-Sichern- und -Löschen-Operationen, welche ein Eingabefeld von Entitäten zuführen, kann es für doppelte Instanzen möglich sein, entweder explizit in den Feldelemente oder implizit in den Objektgraphabschließungen von Entitäten in dem Feld zu erscheinen. Wenn dies nicht abgewickelt wird, können doppelte Instanzen zu vielen Ausnahmen von CRUD-Orchestrierungen für dieselbe Entität führen. Der Speicher identifiziert doppelte Entitäten und wirft eine Ausnahme, wenn sie ihm begegnen, um Aufrufer zu helfen, Speicher Entitäten ohne Duplikate zuzuführen.
Löschen von zugeordneten Entitäten in der Objektgraphabschließung einer Wurzelentität kann die Relationssemantik brechen. Zum Beispiel sollte ein Löschen einer Rechnung nicht zu einem Entfernen des ihr zugeordneten Kunden führen. Der Speicher wird nur die Wurzelentität löschen und daher nur CRUD-(i.e. Löschen)-Orchestrierungen an ihr ausführen. Dies bedeutet, dass Entitäten, welche auf Löschen der Wurzelentität folgend in der Objektgraphabschließung von Wurzelentität entfernt oder aktualisiert wurden, nicht CRUD-Orchestrierungen ablaufen lassen werden.
Eine Löschen-Operation, welche an einem Kompositionskind aufgerufen wurde, sollte eine Ausnahme werfen. Der Speicher sollte das Kind durch sein Wurzelelter ersetzen und ein Löschen auf ihn aufrufen, was zu Entfernen des Elter und aller seiner Kinder führt. Dies sollte nicht die Absicht von Aufrufer sein. Wenn ein Kind gelöscht werden soll, sollte der Elter durch Entfernen eines designierten Kindes modifiziert und dann gesichert werden.
Ein neues der Speicher-Sichern-Operation gesendetes Kompositionskind sollte das einzige neue Kind einer Elternentität sein. Es ist nicht möglich, die geeignete Kindentität zu bestimmen, wenn mehr als eine neue Kindentität unter dem gleichen Elter erzeugt wird. InvalidOperationException wird geworfen, wenn diese Situation auftreten sollte.
Besucher (visitor)
Ein Besucher kann implementiert werden, um neue oder aktualisierte Entitäten in Objektgraphabschließung einer Entität zu identifizieren, welche an Speicher-Sichern- und -Löschen-Methoden übergeben wurde. Der Besucher implementiert IEntityVisitor. Sowohl für Sicherungen und Löschungen kann der Besucher:

1. Einen Weg bereitstellen, zwischen Sichern- und Löschen-Methoden zu wechseln.
2. Den gesamten Objektgraphen traversieren, welcher den Sichern(Entität)/Löschen(Entität)(save(Entity)/delete(Entity))-Methoden übergeben ist, und das gesamte Feldes von gesamten Objektgraphen, welches den Sichern(Entität[])/Löschen(Entität[]-Methoden übergeben ist, zu traversieren, während eines Durchführens von Zyklusdetektion, um zu vermeiden, dass irgend ein Knoten mehr als einmal besucht wird (bereits Teil der Besucherimplementation in EntityCommon).
3. Die Knoten in dem/den Objektgraphen analysieren, um Entitäten zu identifizieren und zu sammeln, welche dem CRUD-Orchestrierungsdeligierten übergeben werden sollen.

Bei Sicherungen wird der Besucher:

1. Die eindeutige ID in jeder Entität setzen, in welcher sie nicht bereits gesetzt ist, mit Ausnahme der Entitäten, welche Erweiterungen sind.
2. Neue Entitäten in Erzeugen-Felder setzen, welche spezifisch für jeden genauen Typ von Entität sind.
3. Vorher gesicherte, momentan unreine Entitäten in Aktualisieren-Felder setzen, welche spezifisch für jeden genauen Typ von Entität sind.
4. Sicherstellen, dass jede Entität genau einmal in dem gesamten Satz von Feldern vorkommt.
5. Erweiterungen zu ersetzen durch das, was sie erweitern.
6. Kompositionskindentitäten durch ihre Elternentitäten transitiv, bis die letztendlichen Eltern erreicht sind, zu ersetzen.
7. Die gesammelten Feldentitäten Speicher zugänglich machen.

Bei Löschungen kann der Benutzer bestimmen, ob irgend eine Entität in der Objektgraphabschließung neu ist, um dem Speicher zu ermöglichen, eine Ausnahme zu werfen. Man bemerke, dass der Entitätsdienst dies bereits tut, aber es ist verschwenderisch, einen gesamten Graphen an den Server zu senden, wenn das Sytem den Fehler vorher abfangen kann.
Speicherverhalten (Repository Behavior)
Wenn Speicher-Sichern aufgerufen wird, kann Speicher:

1. Eine Transaktion starten.
2. Einen Besucher erzeugen und ihn in Sichern-Modus setzen.
3. Den Besucher an einer Eingabeentität oder -entitäten ausführen.
4. Als eine Erweiterung identifizierte Wurzelentität durch erweiterte Entität ersetzen.
5. Als ein Kompositionskind identifizierte Wurzelentität durch Wurzelkompositionselter ersetzen.
6. Wurzelentität an CRUD-Orchestrierungsdeligierter-Aktualisieren- oder -Erzeugen-Methode senden.
7. Jede durch den Besucher identifizierte Entität an CRUD-Orchestrierungsdeligierte-Aktualisieren- oder -Erzeugen-Methode senden.
8. Die Transaktion durchführen, um Persistenz von Entitäten in der Datenbank zu beenden.
9. Gesicherte Entität/Entitäten an Aufrufer zurückzugeben.

Wenn Speicher-Löschen aufgerufen wird, kann Speicher:

1. Eine Transaktion starten.
2. Einen Besucher erzeugen und ihn in Löschen-Modus setzen.
3. Besucher an Wurzelentität ausführen, um eine Ausnahme zu werfen, wenn neue Entitäten in Objektgraphabschließung gefunden sind.
4. Für Löschen (Entität []) (delete(Entity []) eine Ausnahme werfen, wenn doppelte Entitäten in Objektgraphabschließungen gefunden sind.
5. Wurzelentität an CRUD-Orchestrierungsdeligierter-Löschen-Methode senden.
6. Die Transaktion durchführen.

Ausnahmen (Exceptions)
Eine Anzahl von neuen Fehlersituationen werden durch den Speicher beim Prozessieren von Eingabeentitäten für Sichern- und Löschen-Operationen identifiziert. In jedem Fall wird InvalidOperationException (ungültige-Operation-Ausnahme) geworfen. Die Ausnahme wird durch den Speicher aufgefangen, um Transaktion, welche ursprünglich für Sichern- oder Löschen-Operation initiiert wurde, rückgängig zu machen. Man beachte, dass Ausnahme detailliert, dass:

1. Eine neue Entität Löschen-Operation zugeführt wurde.
2. Ein Kompositionskind ohne Kompositionselterinstanz in Objektgraphabschließung einer Sichern-Operation zugeführten Entität gefunden wurde.
3. Ein Kompositionskind Löschen-Operation zugeführt wurde. Gegeben, dass Speicher immer durch den Elter ersetzt, ist ein Löschen des Elter nicht geeignet.
4. Viele Vorkommen derselben Entitätsinstanz in Objektgraphabschließung von Entität oder Entitäten, welche Sichern-Operation zugeführt wurden, gefunden wurden.
5. Keine aufgelöste Entität in Objektgraphabschließung einer Sichern-Operation zugeführten Entität gefunden wurde.
6. Unfähig, ein gesichertes Objekt, welches einer einer Sichern-Operation zugeführten Entität entspricht, zurückzugeben.

Die vorangehenden Beschreibungen von Ausführungsformen der vorliegenden Erfindung sind nur für Illustrations- und Beschreibungszwecke präsentiert worden. Sie sind nicht beabsichtigt, erschöpfend zu sein oder die vorliegende Erfindung auf die offenbarten Formen zu beschränken. Demgemäß werden viele Modifikationen und Variationen für Fachpraktiker offensichtlich sein. Zusätzlich ist die obige Offenbarung nicht beabsichtigt, die vorliegende Erfindung zu begrenzen. Der Geltungsbereich der vorliegenden Erfindung ist durch die angehängten Ansprüche definiert.

Claims

Verfahren zum Implementieren einer Persistenz-Anwendungsprogrammierungsschnittstelle (API), welche plattformunabhängig ist und Aufwärts-Aufrufe an Geschäftslogik durchführen kann, wobei das Verfahren umfasst: Empfangen einer Anfrage bei der API, ein Kommando bei einer Persistenzschicht einer n-Schicht-verteilten Anwendung auszuführen; in Antwort auf die Anfrage Bestimmen eines Entitätstypen für eine durch das Kommando betroffene Entität; Identifizieren einer dem Entitätstypen und dem Kommando zugeordneten Funktion bei einer Mittelschicht der n-Schicht-verteilten Anwendung, wobei die Mittelschicht die Geschäftslogik umfasst; Senden einer Anweisung an die Mittelschicht, die Funktion auszuführen; und auf Empfangen einer Bestätigung bei der API hin, dass die Funktion ausgeführt ist, Ausführen des Kommandos bei der Persistenzschicht.
Verfahren nach Anspruch 1, wobei Senden der Anweisung an die Mittelschicht weiterhin Senden des Kommandos an die Mittelschicht umfasst, wobei ein Teil des Kommandos als ein Parameter für die Funktion benutzt wird.
Verfahren nach Anspruch 1, welches weiterhin Empfangen einer zweiten Anfrage von der Mittelschicht bei der API, ein zweites Kommando bei der Persistenzschicht auszuführen, umfasst.
Verfahren nach Anspruch 3, weiterhin umfassend: In Antwort auf die zweite Anfrage, Bestimmen eines zweiten Entitätstyps für eine zweite durch das zweite Kommando betroffene Entität; Identifizieren einer zweiten Funktion bei der Mittelschicht der n-Schicht-verteilten Anwendung, welche dem zweiten Entitätstypen und dem zweiten Kommando zugeordnet ist; Senden einer zweiten Anweisung an die Mittelschicht, die zweite Funktion auszuführen; und auf Empfangen einer zweiten Bestätigung bei der API hin, dass die zweite Funktion ausgeführt ist, Ausführen des zweiten Kommandos bei der Persistenzschicht.
Verfahren nach Anspruch 1, weiterhin umfassend: Erzeugen einer Transaktion bei der API, welche die Anweisung und/oder das Kommando umfasst; Bestimmen, ob die Funktion bei der Mittelschicht erfolgreich ausgeführt wurde und ob das Kommando bei der Persistenzebene erfolgreich ausgeführt wurde; wenn dem so ist, Durchführen der Transaktion; und wenn dem nicht so ist, Zurücknehmen der Transaktion.
Verfahren nach Anspruch 5, wobei Erzeugen der Transaktion Erzeugen einer Persistenzschicht-Untertransaktion bei der Persistenzschicht umfassen kann, wobei Durchführen der Transaktion Durchführen der Persistenzschicht-Untertransaktion umfasst, und wobei Zurücknehmen der Transaktion Zurücknehmen der Persistenzschicht-Untertransaktion umfasst.
Verfahren nach Anspruch 1, wobei die Persistenzschicht eine relationale Datenbank umfasst.
Verfahren nach Anspruch 1, wobei vor Identifizieren der Funktion bei der Mittelschicht der n-Schicht-verteilten Anwendung das Verfahren weiterhin Empfangen einer Registrierung bei der API umfasst, welche die Funktion und den zugeordneten Entitätstypen und das zugeordnete Kommando identifiziert.
Verfahren nach Anspruch 1, wobei die Schritte von Identifizieren der Funktion bei der Mittelschicht und Senden der Anweisung an die Mittelschicht durch einen Orchestrierungsdeligierten abgewickelt werden, wobei der Orchestrierungsdeligierte die Ausführung von vorher bei der API registriertem Code anordnet, wenn eine Registrierungsbedingung erfüllt ist.
Computerlesbares Speichermedium, welches Anweisungen speichert, welche dazu führen, wenn sie durch einen Computer ausgeführt werden, dass der Computer ein Verfahren zum Implementieren einer Persistenz-Anwendungsprogrammierungsschnittstelle (API) durchführt, welche plattformunabhängig ist und Aufwärts-Aufrufe an Geschäftslogik durchführen kann, wobei das Verfahren umfasst: Empfangen einer Anfrage bei der API, ein Kommando bei einer Persistenzschicht einer n-Schicht-verteilten Anwendung auszuführen; in Antwort auf die Anfrage Bestimmen eines Entitätstypen für eine durch das Kommando betroffene Entität; Identifizieren einer dem Entitätstypen und dem Kommando zugeordneten Funktion bei einer Mittelschicht der n-Schicht-verteilten Anwendung, wobei die Mittelschicht die Geschäftslogik umfasst; Senden einer Anweisung an die Mittelschicht, die Funktion auszuführen; und auf Empfangen einer Bestätigung bei der API hin, dass die Funktion ausgeführt ist, Ausführen des Kommandos bei der Persistenzschicht.
Computerlesbares Speichermedium nach Anspruch 10, wobei Senden der Anweisung an die Mittelschicht weiterhin Senden des Kommandos an die Mittelschicht umfasst, wobei ein Teil des Kommandos als ein Parameter für die Funktion benutzt wird.
Computerlesbares Speichermedium nach Anspruch 10, wobei das Verfahren weiterhin Empfangen einer zweiten Anfrage von der Mittelschicht bei der API, ein zweites Kommando bei der Persistenzschicht auszuführen, umfasst.
Computerlesbares Speichermedium nach Anspruch 12, wobei das Verfahren weiterhin umfasst: In Antwort auf die zweite Anfrage, Bestimmen eines zweiten Entitätstyps für eine zweite durch das zweite Kommando betroffene Entität; Identifizieren einer zweiten Funktion bei der Mittelschicht der n-Schicht-verteilten Anwendung, welche dem zweiten Entitätstypen und dem zweiten Kommando zugeordnet ist; Senden einer zweiten Anweisung an die Mittelschicht, die zweite Funktion auszuführen; und auf Empfangen einer zweiten Bestätigung bei der API hin, dass die zweite Funktion ausgeführt ist, Ausführen des zweiten Kommandos bei der Persistenzschicht.
Computerlesbares Speichermedium nach Anspruch 10, wobei das Verfahren weiterhin umfasst: Erzeugen einer Transaktion bei der API, welche die Anweisung und/oder das Kommando umfasst; Bestimmen, ob die Funktion bei der Mittelschicht erfolgreich ausgeführt wurde und ob das Kommando bei der Persistenzebene erfolgreich ausgeführt wurde; wenn dem so ist, Durchführen der Transaktion; und wenn dem nicht so ist, Zurücknehmen der Transaktion.
Computerlesbares Speichermedium nach Anspruch 14, wobei Erzeugen der Transaktion Erzeugen einer Persistenzschicht-Untertransaktion bei der Persistenzschicht umfasst, wobei Durchführen der Transaktion Durchführen der Persistenzschicht- Untertransaktion umfasst, und wobei Zurücknehmen der Transaktion Zurücknehmen der Persistenzschicht-Untertransaktion umfasst.
Computerlesbares Speichermedium nach Anspruch 10, wobei die Persistenzschicht eine relationale Datenbank umfasst.
Computerlesbares Speichermedium nach Anspruch 10, wobei vor Identifizieren der Funktion bei der Mittelschicht der n-Schicht-verteilten Anwendung das Verfahren weiterhin Empfangen einer Registrierung bei der API umfasst, welche die Funktion und den zugeordneten Entitätstypen und das zugeordnete Kommando identifiziert.
Computerlesbares Speichermedium nach Anspruch 10, wobei die Schritte von Identifizieren der Funktion bei der Mittelschicht und Senden der Anweisung an die Mittelschicht durch einen Orchestrierungsdeligierten abgewickelt werden, wobei der Orchestrierungsdeligierte die Ausführung von vorher bei der API registriertem Code anordnet, wenn eine Registrierungsbedingung erfüllt ist.
Vorrichtung, welche konfiguriert ist, eine Persistenz-Anwendungsprogrammierungsschnittstelle (API) zu implementieren, welche plattformunabhängig ist und Aufwärts-Aufrufe an Geschäftslogik durchführen kann, wobei die Vorrichtung umfasst: ein Empfangsmittel, welches konfiguriert ist, eine Anfrage bei der API zu empfangen, ein Kommando bei einer Persistenzschicht einer n-Schicht-verteilten Anwendung auszuführen; ein Bestimmungsmittel, welches konfiguriert ist, einen Entitätstypen für eine durch das Kommando betroffene Entität in Antwort auf die Anfrage zu bestimmen; ein Identifikationsmittel, welches konfiguriert ist, eine dem Entitätstypen und dem Kommando zugeordnete Funktion bei einer Mittelschicht der n-Schicht-verteilten Anwendung zu identifizieren, wobei die Mittelschicht die Geschäftslogik umfasst; ein Sendemittel, welches konfiguriert ist, eine Anweisung, die Funktion auszuführen, an die Mittelschicht zu senden; und ein Ausführungsmittel, welches konfiguriert ist, das Kommando bei der Persistenzschicht auf Empfangen einer Bestätigung bei der API hin, dass die Funktion ausgeführt ist, auszuführen.
Vorrichtung nach Anspruch 19, wobei das Sendemittel weiterhin konfiguriert ist, das Kommando an die Mittelschicht zu senden, wobei ein Teil des Kommandos als ein Parameter für die Funktion benutzt wird.