DE112009001892T5 - Datensatz basierte Codestruktur - Google Patents

Datensatz basierte Codestruktur Download PDF

Info

Publication number
DE112009001892T5
DE112009001892T5 DE112009001892T DE112009001892T DE112009001892T5 DE 112009001892 T5 DE112009001892 T5 DE 112009001892T5 DE 112009001892 T DE112009001892 T DE 112009001892T DE 112009001892 T DE112009001892 T DE 112009001892T DE 112009001892 T5 DE112009001892 T5 DE 112009001892T5
Authority
DE
Germany
Prior art keywords
code
database
logic
compiled
computer program
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
DE112009001892T
Other languages
English (en)
Inventor
Dustin Kurt Calif. Adler
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Group-A Autosports Inc Norco Us
Group-A Autosports Inc Us
Original Assignee
Xsevo Systems Inc 92860 Calif
Xsevo Systems Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from US12/183,823 external-priority patent/US8171045B2/en
Priority claimed from US12/191,711 external-priority patent/US20100042585A1/en
Priority claimed from US12/210,629 external-priority patent/US7979450B2/en
Application filed by Xsevo Systems Inc 92860 Calif, Xsevo Systems Inc filed Critical Xsevo Systems Inc 92860 Calif
Publication of DE112009001892T5 publication Critical patent/DE112009001892T5/de
Withdrawn legal-status Critical Current

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/24Querying
    • G06F16/245Query processing
    • G06F16/2457Query processing with adaptation to user needs
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44Arrangements for executing specific programs
    • G06F9/445Program loading or initiating
    • G06F9/44536Selecting among different versions

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Computational Linguistics (AREA)
  • Data Mining & Analysis (AREA)
  • Databases & Information Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Stored Programmes (AREA)

Abstract

Ein System, das aufweist: eine Rechenvorrichtung; eine Betriebssystemlogik, die so konfiguriert ist, dass sie auf der Rechenvorrichtung läuft, und auf einem computerlesbaren Medium der Rechenvorrichtung gespeichert ist; eine Datenbank, die auf einem computerlesbaren Medium gespeichert ist und Datensätze umfasst, die dazu konfiguriert sind, den kompilierten Code eines Computerprogramms zu speichern; eine Datenbankverwaltungslogik, die zum Zugreifen auf die Datenbank konfiguriert ist; und eine Codeausführungslogik, die dazu konfiguriert ist, den kompilierten Code aus den Datensätzen durch Ausführen von einer oder mehreren Abfragen auf der Datenbankverwaltungslogik abzurufen und den abgerufenen Code auf der Betriebssystemlogik auszuführen.

Description

  • Diese Anmeldung beansprucht den Nutzen der und die Priorität der folgenden nicht-vorläufigen US-Anmeldungen:
    Anmeldung Nr. 12/183 823, eingereicht am 31. Juli 2008 und mit dem Titel ”Record Based Code Structure”;
    Anmeldung Nr. 12/191 711, eingereicht am 14. August 2008 und mit dem Titel ”Command Interpretation”; und
    Anmeldung Nr. 12/210 629, eingereicht am 15. September 2008 und mit dem Titel ”Instance Management of Code in a Database”.
  • Die Offenbarungen dieser Anmeldungen werden hiermit durch Bezugnahme hierin aufgenommen.
  • HINTERGRUND
  • Gebiet der Erfindung
  • Die Erfindung liegt im Gebiet von Rechensystemen und insbesondere in den Gebieten der Computerprogrammierung und -bereitstellung.
  • Stand der Technik
  • In einem typischen Rechenmodell wird ein Quellcode von einem Programmierer unter Verwendung eines Editors erzeugt. Dieser Quellcode kann so konfiguriert sein, dass er zu dem Zeitpunkt, zu dem er ausgeführt wird, interpretiert wird oder unter Verwendung eines Kompilierers in einen ausführbaren Code kompiliert wird. Der kompilierte Code führt typischerweise schneller als der interpretierte Code aus, da der Kompilierungsprozess eine Analyse und Syntaxprüfung vor der Ausführung umfasst. Das Kompilieren des Codes bringt auch den Code in eine Form (z. B. Objektcode), die unter Verwendung eines Betriebssystems direkt ausführbar sein kann.
  • Der kompilierte Code wird unter Verwendung eines Ablagesystems gespeichert, das typischerweise mit einem Betriebssystem versehen ist, das dazu konfiguriert ist, den kompilierten Code auszuführen. Der kompilierte Code kann beispielsweise in einer ”.exe”-Datei zur Ausführung innerhalb des Windows-Betriebssystems gespeichert sein. Der kompilierte Code kann mit anderen Dateien, die einen ausführbaren Code, Daten oder Skripten enthalten, verknüpft sein. Diese Verknüpfung kann vor oder zu dem Zeitpunkt stattfinden, zu dem der Code ausgeführt wird. Wenn der Code ausgeführt wird, wird das Dateisystem verwendet, um die Datei zu identifizieren, in der der Code gespeichert ist, und diese Datei wird durch das Betriebssystem geöffnet und verarbeitet.
  • Es bestehen mehrere Nachteile an diesem Rechenmodell. Die Modifikation des kompilierten Codes beinhaltet beispielsweise typischerweise das erneute Kompilieren eines ganzen Quellcodes oder dessen Datei. Wenn eine einzelne Funktion von vielen Funktionen innerhalb des Quellcodes modifiziert wird, dann wird der ganze Quellcode auf dateiweiser Basis erneut kompiliert. Ferner sind spezifische Befugnisse und eine spezifische Software (z. B. ein Editor) erforderlich, um den Quellcode zu modifizieren. Dies kann mühsam sein, wenn sich der Editor und der Code auf verschiedenen Rechenvorrichtungen befinden.
  • Datenbanken und Datenbankprogramme, die dazu konfiguriert sind, die Datenbanken zu verwalten, werden üblicherweise verwendet, um Daten zu speichern und auf diese zuzugreifen. Manchmal werden diese Daten von Computerprogrammen außerhalb von Datenbankprogrammen verwendet. Ein externes Programm kann beispielsweise ein Datenbankprogramm verwenden, um Daten abzurufen, die dann durch das externe Programm verarbeitet werden. Datenbankprogramme können auch ”in der Datenbank gespeicherte Prozeduren” umfassen, die durch einen Benutzer des Datenbankprogramms erstellte Funktionen zum Bearbeiten einer Datenbank sind. In der Datenbank gespeicherte Prozeduren sind auf die Bearbeitung von gespeicherten Daten begrenzt und werden von anderen Typen von Computerprogrammen insofern unterschieden, als diese Prozeduren eher unter der Steuerung (z. B. innerhalb) des Datenbankprogramms als unter der direkten Steuerung eines externen Betriebssystems abgearbeitet werden.
  • Der kompilierte Code wird typischerweise unter Verwendung einer Befehlszeile ausgeführt, die einen Namen des kompilierten Codes, z. B. einen Programmnamen, und wahlweise einen Pfad zum kompilierten Code umfasst. Diese Befehlszeile wird wahlweise durch ein graphisches Bildsymbol in einer graphischen Benutzerschnittstelle dargestellt. Eine Befehlszeile umfasst wahlweise ferner Parameter, die manchmal als Schalter bezeichnet werden und die als Eingabe in den kompilierten Code verwendet werden und verwendet werden können, um die Operation des kompilierten Codes zu steuern. Die DOS-Befehlszeile ”CD lib” umfasst beispielsweise einen Programmidentifikator ”CD” und einen Parameter ”lib”. Der Programmidentifikator wird verwendet, um den kompilierten Code zu identifizieren, der in diesem Fall zum Wechseln eines Dateiverzeichnisses konfiguriert ist. Der Parameter wird verwendet, um an den kompilierten Code eine Identität des Verzeichnisses weiterzuleiten, in das gewechselt werden soll.
  • Auf den kompilierten Code wird wahlweise über ein Computernetzwerk, wie z. B. das Internet, unter Verwendung eines Universal Resource Locator (URL) zugegriffen. Der URL www.xsevo.com/login.esp kann beispielsweise verwendet werden, um ein Login-Pramm auszuführen, das auf xsevo.com gehostet ist. Der URL kann auch verwendet werden, um Parameter an ein Programm zu übergeben. Der URL www.xsevo.com/login.esp?lvl=high kann beispielsweise verwendet werden, um einen Wert ”high” für einen Parameter ”lvl” an das Programm login.esp zu übergeben. URLs und Befehlszeilen können folglich verwendet werden, um Parameter für einen vorher erstellten kompilierten Code bereitzustellen.
  • ZUSAMMENFASSUNG
  • Verschiedene Ausführungsbeispiele der Erfindung umfassen eine Rechenarchitektur, in der ein ausführbarer Code zur Ausführung außerhalb eines Datenbankprogramms in Datensätzen einer Datenbank gespeichert ist. Der ausführbare Code wird zum Zeitpunkt der Ausführung aus der Datenbank abgerufen. Dieser ausführbare Code umfasst typischerweise einen kompilierten Code, der zur Ausführung auf einem Betriebssystem bereit ist. Im Vergleich zum Stand der Technik wird der ausführbare Code eher über das Datenbankprogramm als lediglich über ein Dateisystem verwaltet und auf diesen zugegriffen.
  • Die Speicherung des ausführbaren Codes in den Datensätzen einer Datenbank schafft eine Vielfalt von Vorteilen, von denen einige als Beispiele hierin vorgesehen sein. Der Code kann beispielsweise in einer Datenbank leichter zu verwalten sein als in einem Dateisystem. Der ausführbare Code kann mit einem größeren Grad an Granularität gespeichert werden, als es normalerweise unter Verwendung eines Dateisystems praktisch wäre. In einigen Ausführungsbeispielen wird der ausführbare Code mit einer Granularität gespeichert, so dass sich einzelne Funktionen in verschiedenen Datensätzen der Datenbank befinden. In einigen Fällen ermöglicht dies, dass der ausführbare Code eher auf der Funktionsebene als auf der Dateiebene verwaltet, modifiziert oder anderweitig bearbeitet wird.
  • Während der Ausführung eines Computerprogramms werden Datenbankabfragen verwendet, um den gespeicherten Code aus der Datenbank abzurufen. Der abgerufene Code wird dann außerhalb der Datenbank ausgeführt und durch das Betriebssystem unterstützt. Der Code kann Teil für Teil ausgeführt werden, wobei jeder Teil separat aus der Datenbank abgerufen wird. Abfragen werden wahlweise verwendet, um den bedingten Programmablauf zu erleichtern. Eine CASE-Anweisung, die ein Label verwendet, um den Programmablauf zwischen einer Anzahl von alternativen Pfaden zu lenken, kann beispielsweise durch eine Datenbankabfrage implementiert werden, die das Label als Abfrageparameter verwendet.
  • Der auszuführende kompilierte Code wird wahlweise unter Verwendung eines Befehls mit einer Befehlszeile oder einem Universal Resource Locator ausgewählt. Objekte innerhalb eines Universal Resource Locator können beispielsweise beim Bilden von Abfragen an die Datenbank des kompilierten Codes verwendet werden. Der Universal Resource Locator kann folglich verwendet werden, um einzelne Datensätze mit einem von einem Benutzer gewünschten speziellen Code auszuwählen. In einigen Ausführungsbeispielen werden Objekte innerhalb eines Befehls verwendet, um direkt auf Datensätze abzubilden. Einige Ausführungsbeispiele der Erfindung umfassen eine Logik, die dazu konfiguriert ist, eine Befehlszeile oder einen Universal Resource Locator zu analysieren. Diese Logik kann ferner dazu konfiguriert sein, eine grammatische Struktur des Befehls zu interpretieren.
  • Mehrere Instanzen des kompilierten Codes, Quellcodes und/oder anderer Informationen werden wahlweise innerhalb der Datenbank des kompilierten Codes gespeichert. Diese Instanzen können verschiedene Versionen umfassen, eine unterschiedliche Funktionalität aufweisen, Entwicklungs- und Erzeugungsversionen umfassen, auf verschiedene Sicherheitsniveaus bezogen sein, verschiedenen menschlichen Sprachen zugeordnet sein und/oder dergleichen. Die Datenbankverwaltungslogik und -abfragen, die daran ausgeführt werden, können verwendet werden, um die Instanzverwaltung zu erleichtern.
  • Die Fähigkeit, auf verschiedene Teile eines Computerprogramms zuzugreifen, indem auf einzelne Datensätze zugegriffen wird, in denen diese verschiedenen Teile gespeichert sind, kann eine externe Steuerung oder Ausführung dieser verschiedenen Teile ermöglichen. Ein externes Zeitplanprogramm kann beispielsweise verwendet werden, um die Ausführung einer Teilmenge eines Computerprogramms durch Ausführen des kompilierten Codes, der in einem oder mehreren der Datensätze gespeichert ist, gemäß einem Zeitplan zeitlich zu planen.
  • Verschiedene Ausführungsbeispiele der Erfindung umfassen ein System, das aufweist: eine Rechenvorrichtung; eine Betriebssystemlogik, die dazu konfiguriert ist, auf der Rechenvorrichtung zu laufen, und die auf computerlesbaren Medien der Rechenvorrichtung gespeichert ist; eine Datenbank, die auf computerlesbaren Medien gespeichert ist und Datensätze umfasst, die dazu konfiguriert sind, einen kompilierten Code eines Computerprogramms zu speichern; eine Datenbankverwaltungslogik, die zum Zugreifen auf die Datenbank konfiguriert ist; und eine Codeausführungslogik, die dazu konfiguriert ist, den kompilierten Code aus den Datensätzen durch Ausführen von einer oder mehreren Abfragen an die Datenbankverwaltungslogik abzurufen und den abgerufenen Code auf der Betriebssystemlogik auszuführen.
  • Verschiedene Ausführungsbeispiele der Erfindung umfassen ein Verfahren, das aufweist: Empfangen einer Anforderung zum Ausführen eines Computerprogramms; Ausführen einer ersten Abfrage, um einen ersten Datenbankdatensatz einer Datenbank zu identifizieren, in dem eine Teilmenge eines kompilierten Codes des Computerprogramms gespeichert ist; Abrufen eines ersten Codes aus dem identifizierten ersten Datenbankdatensatz als Ergebnis der ersten Abfrage; Bereitstellen des abgerufenen ersten Codes für ein Betriebssystem zur Ausführung; Erzeugen einer zweiten Abfrage auf der Basis eines Ergebnisses der Ausführung des abgerufenen ersten Codes; Verwenden der erzeugten zweiten Abfrage, um einen zweiten Datenbankdatensatz der Datenbank zu identifizieren, in dem der kompilierte Code des Computerprogramms gespeichert ist; Abrufen des kompilierten Codes aus dem zweiten Datenbankdatensatz als ein Ergebnis der zweiten Abfrage; und Bereitstellen des abgerufenen kompilierten Codes für das Betriebssystem zur Ausführung.
  • Verschiedene Ausführungsbeispiele der Erfindung umfassen ein Verfahren, das aufweist: Empfangen eines Quellcodes eines Computerprogramms, wobei der Quellcode eine Vielzahl von Funktionen umfasst; Kompilieren der Vielzahl von Funktionen, wobei die kompilierten Funktionen zur Ausführung auf einem Betriebssystem konfiguriert sind; Speichern von jeder der kompilierten Vielzahl von Funktionen in einem separaten Datenbankdatensatz; und Indizieren von jedem der separaten Datenbankdatensätze unter Verwendung eines Identifikators der im Datenbankdatensatz gespeicherten Funktion, wobei die Identifikatoren dazu konfiguriert sind, Mitglieder der Vielzahl von Funktionen gemäß einer Programmablauflogik auszuwählen.
  • Verschiedene Ausführungsbeispiele der Erfindung umfassen ein System, das aufweist: eine Rechenvorrichtung; eine Datenbank, die auf einem computerlesbaren Medium gespeichert ist und Datensätze umfasst, die dazu konfiguriert sind, einen kompilierten Code eines Computerprogramms zu speichern; eine Datenbankverwaltungslogik, die dazu konfiguriert ist, auf die Datenbank zuzugreifen; eine Codeausführungslogik, die dazu konfiguriert ist, den kompilierten Code aus den Datensätzen durch Ausführen von einer oder mehreren Abfragen auf der Datenbankverwaltungslogik abzurufen und den abgerufenen Code auf der Betriebssystemlogik auszuführen; und eine Befehlsinterpretationslogik, die auf einem computerlesbaren Medium gespeichert ist und dazu konfiguriert ist, die eine oder die mehreren Abfragen durch Interpretieren eines Befehls zu erzeugen.
  • Verschiedene Ausführungsbeispiele der Erfindung umfassen ein Verfahren, das aufweist: Empfangen eines Befehls mit einer Befehlszeile oder einem Universal Resource Locator; Analysieren des Befehls, um eine Vielzahl von Datenbankabfragen zu erzeugen; Abrufen eines kompilierten Codes aus einer Vielzahl von Datensätzen innerhalb einer Datenbank unter Verwendung der Vielzahl von Datenbankabfragen, wobei verschiedene Teile des kompilierten Codes in verschiedenen Mitgliedern der Datensätze gespeichert sind; und Ausführen des abgerufenen kompilierten Codes außerhalb der Datenbank in Reaktion auf das Empfangen des Befehls.
  • Verschiedene Ausführungsbeispiele der Erfindung umfassen ein Verfahren, das aufweist: Lesen eines ersten Objekts innerhalb einer empfangenen Befehlszeile oder eines empfangenen Universal Resource Locator; Identifizieren des ersten Objekts als vordefiniertes Präfix, das dazu konfiguriert ist, Typen von einem oder mehreren anderen Objekten innerhalb der empfangenen Befehlszeile oder des empfangenen Universal Resource Locator zu charakterisieren; Lesen eines zweiten Objekts mit der empfangenen Befehlszeile oder dem empfangenen Universal Resource Locator; und Identifizieren des zweiten Objekts als Abbildung auf einen Datensatz innerhalb einer Datenbank, wobei der Datensatz einen kompilierten Code umfasst, der so konfiguriert ist, dass er in Reaktion auf das Empfangen der empfangenen Befehlszeile oder des empfangenen Universal Resource Locators ausgeführt wird.
  • Verschiedene Ausführungsbeispiele der Erfindung umfassen ein System, das aufweist: eine Rechenvorrichtung; eine Betriebssystemlogik, die dazu konfiguriert ist, Computerprogramme auf der Rechenvorrichtung auszuführen; eine Datenbank, die auf einem computerlesbaren Medium gespeichert ist und einen ersten Datensatz, einen zweiten Datensatz und einen dritten Datensatz umfasst; eine Codeverwaltungslogik, die dazu konfiguriert ist, einen ersten kompilierten Code im ersten Datensatz zu speichern, einen zweiten kompilierten Code im zweiten Datensatz zu speichern, und einen dritten Datensatz im dritten Datensatz zu speichern, wobei der erste kompilierte Code und der zweite kompilierte Code verschiedene Teile eines Computerprogramms aufweisen, wobei der zweite kompilierte Code und der dritte kompilierte Code verschiedene Instanzen eines Teils des Computerprogramms aufweisen; eine Datenbankverwaltungslogik, die dazu konfiguriert ist, auf die Datenbank zuzugreifen; und eine Codeausführungslogik, die dazu konfiguriert ist, eine der verschiedenen Instanzen des kompilierten Codes auszuwählen und die ausgewählte Instanz des kompilierten Codes aus den Datensätzen durch Ausführen von einer oder mehreren Abfragen auf der Datenbank unter Verwendung der Datenbankverwaltungslogik abzurufen und die abgerufene Instanz auf der Betriebssystemlogik auszuführen.
  • Verschiedene Ausführungsbeispiele der Erfindung umfassen ein computerlesbares Medium, auf dem gespeichert ist: eine Logik, die dazu konfiguriert ist, einen Code eines Computerprogramms zu empfangen; eine Logik, die dazu konfiguriert ist, den Code in eine Vielzahl von Teilen zu unterteilen; eine Logik, die dazu konfiguriert ist, die Vielzahl von Teilen jeweils in einem separaten Datensatz einer Datenbank zu speichern; eine Logik, die dazu konfiguriert ist, ein Mitglied der Vielzahl von Teilen zu modifizieren, um eine modifizierte Instanz des Mitgliedes aus einer ursprünglichen Instanz des Mitgliedes zu erzeugen; eine Logik, die dazu konfiguriert ist, die modifizierte Instanz in der Datenbank zu speichern; und eine Logik, die dazu konfiguriert ist, alternativ die ursprüngliche Instanz oder die modifizierte Instanz unter Verwendung einer Datenbankabfrage auszuwählen.
  • Verschiedene Ausführungsbeispiele der Erfindung umfassen ein Verfahren, das aufweist: Empfangen eines Codes eines Computerprogramms; Unterteilen des Codes in eine Vielzahl von Teilen; Speichern der Vielzahl von Teilen jeweils in einem separaten Datensatz einer Datenbank; Modifizieren eines Mitgliedes der Vielzahl von Teilen, um eine modifizierte Instanz des Mitgliedes aus einer ursprünglichen Instanz des Mitgliedes zu erzeugen; Speichern der modifizierten Instanz in der Datenbank; alternatives Auswählen der ursprünglichen Instanz oder der modifizierten Instanz unter Verwendung einer Datenbankabfrage; und wahlweise Ausführen der ausgewählten Instanz.
  • Verschiedene Ausführungsbeispiele der Erfindung umfassen ein System, das aufweist: eine Rechenvorrichtung, die dazu konfiguriert ist, ein Computerprogramm unter Verwendung einer Betriebssystemlogik auszuführen; eine Datenbank, die auf computerlesbaren Medien gespeichert ist und Datensätze umfasst, die dazu konfiguriert sind, einen kompilierten Code des Computerprogramms als separate Teile zu speichern; eine Datenbankverwaltungslogik, die zum Zugreifen auf die Datenbank konfiguriert ist; und eine Zeitplanlogik außerhalb des Computerprogramms, die dazu konfiguriert ist, die Ausführung einer Teilmenge der separaten Teile auf der Rechenvorrichtung gemäß einem Zeitplan anzufordern.
  • KURZBESCHREIBUNG DER ZEICHNUNGEN
  • 1 stellt ein Rechensystem gemäß verschiedenen Ausführungsbeispielen der Erfindung dar.
  • 2 stellt eine Datenstruktur gemäß verschiedenen Ausführungsbeispielen der Erfindung dar.
  • 3 stellt ein verteiltes Rechensystem gemäß verschiedenen Ausführungsbeispielen der Erfindung dar.
  • 4 stellt Verfahren zum Ausführen eines Computerprogramms gemäß verschiedenen Ausführungsbeispielen der Erfindung dar.
  • 5 stellt Verfahren zum Erzeugen und Modifizieren eines Computerprogramms gemäß verschiedenen Ausführungsbeispielen der Erfindung dar.
  • 6 stellt ein Verfahren zum Interpretieren eines Befehls unter Verwendung des Rechensystems von 1 gemäß verschiedenen Ausführungsbeispielen der Erfindung dar.
  • 7 stellt ein Verfahren zum Analysieren eines Befehls gemäß verschiedenen Ausführungsbeispielen der Erfindung dar.
  • 8 stellt ein Verfahren zum Speichern von mehreren Instanzen eines Rechencodes gemäß verschiedenen Ausführungsbeispielen der Erfindung dar.
  • AUSFÜHRLICHE BESCHREIBUNG
  • In verschiedenen Ausführungsbeispielen umfasst die Erfindung eine Rechenvorrichtung, auf der ein Computerprogramm innerhalb einer Datenbank gespeichert ist, Systeme und Verfahren zum Speichern und Modifizieren des Computerprogramms, Systeme und Verfahren zum Ausführen des Computerprogramms und weitere hierin erörterte Merkmale. Das gespeicherte Computerprogramm umfasst einen kompilierten Code sowie optional Daten, Skripten, eine Dokumentenauszeichnungssprache (Mark-Up-Language), Bilder, einen Quellcode oder dergleichen. Das Computerprogramm ist wahlweise mit einer Granularität gespeichert, wobei einzelne Funktionen in separaten Datensätzen gespeichert sind. Das Computerprogramm wird durch Abrufen des gespeicherten kompilierten Codes aus der Datenbank zum Zeitpunkt der Ausführung ausgeführt. In einigen Fällen ist das Computerprogramm ein Teil einer Anwendung auf Internetbasis, die so konfiguriert ist, dass auf diese durch einen Browser zugegriffen wird, sie modifiziert und/oder ausgeführt wird.
  • Der kompilierte Code ist ein Objektcode oder Bytecode, der analysiert und von einer für den Menschen lesbaren Quellcodeform umgewandelt wurde, damit er durch einen Software-Interpretierer effizienter ausgeführt wird. Der Bytecode kann durch eine virtuelle Maschine (z. B. einen Interpretierer) ausgeführt werden oder er kann weiter in einen Maschinencode kompiliert werden. Unter Verwendung des Bytecodes kann ein Computerprogramm in zwei Phasen ausgeführt werden, wobei zuerst der Quellcode in den Bytecode kompiliert wird und dann der Bytecode an eine virtuelle Maschine übergeben wird. Solche virtuellen Maschinen sind portabel und existieren für populäre Programmiersprachen, wie z. B. C, Java, Python, PHP (Hypertext Preprocessor), Forth und Tcl (Tool Command Language). Andere Beispiele eines Bytecodes umfassen unter anderen einen Code der BCPL-Programmiersprache, einen p-Code von UCSD Pascal, Scheme 48, CLISP, CMUCL, Microsoft.NET Common Intermediate Language. Der Objektcode ist eine Repräsentation des Quellcodes, der durch einen Kompilierer oder Assemblierer erzeugt wurde. Dieser Code kann binäre Befehle (Maschinencode), Daten zur Verwendung durch den Code, Programmsymbole, Verschiebungsinformationen, Fehlerbeseitigungsinformationen und/oder dergleichen umfassen. Das Kompilieren des Objektcodes oder Bytecodes umfasst typischerweise das Ausführen von Syntaxprüfungen am Quellcode und das Analysieren des Quellcodes mindestens einmal, um den Objekt- oder Bytecode zu erzeugen.
  • 1 stellt ein Rechensystem 100 gemäß verschiedenen Ausführungsbeispielen der Erfindung dar. Das Rechensystem 100 ist für die Erstellung, Speicherung und/oder Ausführung von Computerprogrammen konfiguriert. Wie hierin weiter beschrieben, ist das Rechensystem 100 wahlweise ein verteiltes System mit einer Vielzahl von diskreten Vorrichtungen, die dazu konfiguriert sind, miteinander zu kommunizieren. Das Rechensystem 100 umfasst mindestens eine Rechenvorrichtung 110. Die Rechenvorrichtung 110 umfasst eine Hardware, wie z. B. einen Prozessor, Speicher und/oder Eingang/Ausgang, die dazu konfiguriert ist, ein Computerprogramm auszuführen. In verschiedenen Ausführungsbeispielen weist die Rechenvorrichtung 110 einen Server, einen Personalcomputer (PC), einen Arbeitsplatzrechner, eine portable Rechenvorrichtung oder dergleichen auf.
  • Die Rechenvorrichtung 110 ist wahlweise mit anderen Rechenvorrichtungen über ein Netzwerk 120 verbunden. Das Netzwerk 120 kann das Internet, ein weiträumiges Netzwerk, ein lokales Netzwerk oder dergleichen umfassen. In einigen Ausführungsbeispielen umfasst die Rechenvorrichtung 110 beispielsweise einen Server, der dazu konfiguriert ist, ein Computerprogramm auszuführen, dessen Ausgabe über das Internet übertragen wird und einem Benutzer innerhalb eines Browsers präsentiert wird. Das Netzwerk 120 kann auch dazu konfiguriert sein, die Kommunikation zwischen verschiedenen verteilten Elementen des Rechensystems 100 zu erleichtern.
  • Das Rechensystem 100 weist ferner eine Betriebssystemlogik 130 auf. Die Betriebssystemlogik 130 ist wahlweise auf computerlesbaren Medien innerhalb der Rechenvorrichtung 110 gespeichert und ist so konfiguriert, dass sie auf der Rechenvorrichtung 110 läuft, um die Ausführung des Objektcodes oder Bytecodes auf der Rechenvorrichtung 110 zu unterstützen. Die Betriebssystemlogik 130 ist wahlweise ferner dazu konfiguriert, ein Dateisystem auf der Rechenvorrichtung 110 zu unterstützen. Die Betriebssystemlogik 130 kann beispielsweise LINUX, UNIX, BSD Unix, Mac OS X, HPUX, Solaris, Microsoft Windows oder dergleichen umfassen.
  • Das Rechensystem 100 weist ferner eine Datenbank 140 auf. Die Datenbank 140 ist typischerweise eine relationale Datenbank, die auf computerlesbaren Medien gespeichert ist und auf der Rechenvorrichtung 110 oder auf irgendeiner anderen Rechenvorrichtung innerhalb des Rechensystems 100 gespeichert sein kann. Die Datenbank 140 weist Datensätze auf, die dazu konfiguriert sind, den kompilierten Code eines Computerprogramms zu speichern. Die Datensätze innerhalb der Datenbank 140 sind wahlweise auch dazu konfiguriert, Daten, die der Computer verarbeitet, Konfigurationsdaten in Bezug auf das Computerprogramm, nicht-kompilierte Rechenbefehle und/oder dergleichen zu speichern. Nicht-kompilierte Rechenbefehle, die in Datensätzen der Datenbank 140 gespeichert sind, können beispielsweise Skripten, Dokumentenauszeichnungssprachbefehle, einen Quellcode, einen Code, der so konfiguriert ist, dass er in einem Textformat interpretiert wird, oder dergleichen umfassen. Kompilierte und nicht-kompilierte Rechenbefehle können im gleichen und/oder in verschiedenen Datensätzen gespeichert werden. In einigen Ausführungsbeispielen umfasst das Rechensystem 100 eine Instanz der Datenbank 140, die dazu konfiguriert ist, den kompilierten Code zu speichern, und eine ähnliche Datenbank, die dazu konfiguriert ist, den zugehörigen Quellcode zu speichern. Die logische Unterteilung des kompilierten Codes auf verschiedene Datensätze kann zur Aufteilung des Quellcodes unter Datenbankdatensätzen ähnlich sein. Weitere Details der Datenbank 140 werden anderswo hierin beschrieben, beispielsweise mit Bezug auf 2.
  • Die Datenbank 140 wird typischerweise durch eine Datenbankverwaltungslogik 150 verwaltet, die auf derselben Rechenvorrichtung wie die Datenbank 140 installiert ist. Die Datenbankverwaltungslogik 150 ist dazu konfiguriert, auf Datensätze innerhalb der Datenbank 140 unter Verwendung von Abfragen zuzugreifen (z. B. zu lesen oder zu schreiben). Die Datenbankverwaltungslogik 150 kann auch dazu konfiguriert sein, den Zugriff auf die Datenbank 140 zu steuern, Tabellen von Datensätzen innerhalb der Datenbank 140 zu definieren, Operationen an der Datenbank 140 zu protokollieren und/oder andere Funktionen auszuführen, die üblicherweise von Datenbankverwaltungswerkzeugen verfügbar sind. Die Datenbank 140 ist wahlweise dazu konfiguriert, den kompilierten Code von mehr als einem Computerprogramm zu speichern.
  • Das Rechensystem 100 umfasst ferner eine Codeausführungslogik 160. Die Codeausführungslogik 160 ist dazu konfiguriert, den kompilierten Code aus den Datensätzen durch Ausführen von einer oder mehreren Abfragen durch die Datenbankverwaltungslogik 150 abzurufen und den abgerufenen Code unter Verwendung der Betriebssystemlogik 130 auszuführen. Die Codeausführungslogik 160 kann auf der Rechenvorrichtung 110 oder auf irgendeiner anderen Rechenvorrichtung innerhalb des Rechensystems 100 gespeichert sein.
  • Insbesondere ist die Codeausführungslogik 160 dazu konfiguriert, Abfragen zu formulieren, die dazu konfiguriert sind, ein nächstes erforderliches gespeichertes Stück des kompilierten Codes abzurufen. Wenn beispielsweise ein Computerprogramm zum ersten Mal ausgeführt wird, kann die Codeausführungslogik 160 verwendet werden, um eine Abfrage zu formulieren, die dazu konfiguriert ist, einen Datensatz innerhalb der Datenbank 140 zu identifizieren, der einen Code eines Eintrittspunkts des Computerprogramms umfasst. Diese Abfrage kann einen Identifikator des Programms sowie einen Parameter, der angibt, dass der Eintrittspunkt erforderlich ist, umfassen. Die Ergebnisse dieser Abfrage weisen den Eintrittspunktcode auf, der dann an die Betriebssystemlogik 130 zur Ausführung übergeben wird. Die Codeausführungslogik 160 wird dann verwendet, um eine zweite Abfrage zu formulieren, die dazu konfiguriert ist, den nächsten aus der Datenbank 140 abzurufenden Code zur Ausführung auf der Betriebssystemlogik 130 abzurufen. Die zweite Abfrage kann formuliert werden, nachdem die erste Abfrage formuliert ist, und/oder kann formuliert werden, nachdem der erste Code ausgeführt ist.
  • Die zweite Abfrage kann kurz nach der ersten Abfrage formuliert werden, wenn der Programmablauf nach dem durch die erste Abfrage abgerufenen Code bekannt ist. Der Programmablauf ist die Reihenfolge, in der der Code ausgeführt wird. Der Programmablauf kann beispielsweise unter Verwendung von bedingten Verzweigungsanweisungen innerhalb des Computerprogramms verändert werden. Diese bedingten Verzweigungsanweisungen umfassen beispielsweise IF-Anweisungen, WHILE-Anweisungen, CASE-Anweisungen oder dergleichen. Wenn das Computerprogramm eine bedingte Verzweigungsanweisung umfasst, kann der Inhalt der zweiten Abfrage von Ergebnissen der Ausführung des unter Verwendung der ersten Abfrage abgerufenen Codes abhängen. In einigen Ausführungsbeispielen kann es daher nicht möglich sein, die zweite Abfrage zu formulieren, bis nachdem der Code der ersten Abfrage mit der Ausführung fertig ist.
  • Manchmal umfassen bedingte Verzweigungsanweisungen ein Label, zu dem der Programmablauf springen sollte. In Systemen des Standes der Technik kann dieses Label in einen Zeiger umgewandelt werden. In einigen Ausführungsbeispielen wird das Label als Parameter in der zweiten Abfrage verwendet. Innerhalb der Abfrage wird dieses Label von der Datenverwaltungslogik 150 verwendet, um den Datensatz zu identifizieren, in dem der nächste auszuführende Code gespeichert ist. Infolge dieses Merkmals können die Abfragefähigkeiten der Datenbankverwaltungslogik 150 verwendet werden, um den Programmablauf innerhalb des ausgeführten Programms zu steuern. Dies kann zu mehreren Vorteilen führen. Eine neue Option (Programmablaufziel) kann beispielsweise zu einer bedingten Verzweigungsanweisung hinzugefügt werden, indem ein geeigneter Datensatz zur Datenbank 140 hinzugefügt wird und der hinzugefügte Datensatz unter Verwendung eines Labels indiziert wird, das durch die Codeausführungslogik 160 in eine Abfrage aufgenommen werden soll. In verschiedenen Ausführungsbeispielen werden in Abfragen enthaltene Parameter durch die Codeausführungslogik 160 von einem Benutzer, von einer Befehlszeile, von einer Konfigurationsdatei, von einer Untersuchung der verfügbaren Hardware empfangen, von einer Datenbank, Webanforderungsdaten und/oder einem anderen Computerprogramm abgerufen.
  • Die Codeausführungslogik 160 kann dazu konfiguriert sein, weitere Abfragen nach der zweiten Abfrage mit ähnlichen Eigenschaften zu formulieren und auszuführen. Dieser Prozess kann bis zur Programmbeendung wiederholt werden.
  • Das Rechensystem 100 umfasst wahlweise ferner eine Codekompilierungslogik 170, die dazu konfiguriert ist, den kompilierten Code aus dem Quellcode zu erzeugen. Die Codekompilierungslogik 170 ist wahlweise ein Standardkompilierer, der zum Kompilieren des Quellcodes in Byte- oder Objektcode konfiguriert ist. Die Codekompilierungslogik 170 ist alternativ ein kundenangepasster Kompilierer, der dazu konfiguriert ist, den Quellcode in Byte- oder Objektcode zu kompilieren und den Quellcode in einer stückweisen Form mit Stücken des kompilierten Codes, die für die Speicherung in der Datenbank 140 einen geeigneten Umfang aufweisen, auszugeben. Die Kompilierungslogik 170 kann beispielsweise den kompilierten Code in Teile auf der Funktions-(Prozedur-)Ebene, einer funktionalen Ebene, durch Klassendefinition oder in andere logische Elemente unterteilen. In einigen Ausführungsbeispielen wird der kompilierte Code auf der Basis des Programmablaufs innerhalb des Computerprogramms in Teile unterteilt. In diesen Ausführungsbeispielen kann der kompilierte Code an Punkten unterteilt werden, an denen Sprünge zu Labeln innerhalb des Codes durchgeführt werden. In einigen Ausführungsbeispielen ist die Codekompilierungslogik 170 dazu konfiguriert, den empfangenen Quellcode automatisch zu kompilieren und dann den kompilierten Code in der Datenbank 140 zu speichern. Die Codekompilierungslogik 170 kann in der Rechenvorrichtung 110 oder in irgendeiner anderen Rechenvorrichtung des Rechensystems 100 gespeichert sein. In einigen Ausführungsbeispielen ist die Codevollendungslogik 170 dazu konfiguriert, einen Definitionscode für eine Klasse in einem Datensatz zu speichern oder alternativ jedes Klassenverfahren einer Klasse in einem separaten Datensatz zu speichern.
  • Das Rechensystem 100 umfasst wahlweise ferner eine Codeverwaltungslogik 180, die zum Modifizieren und anderweitigen Bearbeiten des kompilierten Codes konfiguriert ist. In einigen Ausführungsbeispielen ist die Codeverwaltungslogik 180 konfiguriert, damit ein Benutzer auf den Quellcode zugreift, den Quellcode, auf den zugegriffen wurde, abruft, den Quellcode überarbeitet, den Quellcode unter Verwendung der Codekompilierungslogik 170 kompiliert und/oder den kompilierten Quellcode in der Datenbank 140 speichert. Die Codeverwaltungslogik 180 verwendet typischerweise die Datenbankverwaltungslogik 150 zum Zugreifen auf, Abrufen und Speichern des kompilierten Codes in der Datenbank 140. Die Datenbankverwaltungslogik 150 verwendet wahlweise ferner die Datenbankverwaltungslogik 150 (oder eine Instanz davon) zum Zugreifen auf den Quellcode, der in der Datenbank 140 oder einer anderen Datenbank gespeichert ist.
  • Die Codeverwaltungslogik 180 ist wahlweise zur Verwendung innerhalb eines Webbrowsers konfiguriert. Die Codeverwaltungslogik 180 kann beispielsweise dazu konfiguriert sein, mit der Datenbankverwaltungslogik 150 und/oder der Codekompilierungslogik 170 über das Internet zu kommunizieren. In einigen Ausführungsbeispielen ist die Codeverwaltungslogik 180 dazu konfiguriert, auf sowohl den kompilierten Code als auch den Quellcode unter Verwendung von einer oder mehreren Instanzen der Datenbankverwaltungslogik 150 zuzugreifen. Wenn beispielsweise der Quellcode in einer Datenbank gespeichert ist, kann die Codeverwaltungslogik 180 Abfragen verwenden, um auf diesen Quellcode zuzugreifen. Der Quellcode kann in einem einzelnen Datensatz gespeichert sein oder in mehreren Datensätzen stückweise gespeichert sein. In Ausführungsbeispielen, in denen der Quellcode in mehreren Datensätzen gespeichert ist, ist die Codeverwaltungslogik 180 wahlweise dazu konfiguriert, entweder ein Stück des Quellcodes einem Benutzer auf einmal oder mehrere Stücke des Quellcodes einem Benutzer gleichzeitig zu präsentieren. Wenn mehrere Stücke des Quellcodes dem Benutzer gleichzeitig präsentiert werden, können die Ergebnisse der Abfragen an die Datenbank mit dem Quellcode zusammen angehängt werden, so dass der Quellcode als kontinuierlicher Körper von für den Menschen lesbarem Text dargestellt wird. Die Codeverwaltungslogik 180 ist wahlweise dazu konfiguriert, den Quellcode einem Benutzer innerhalb einer Überarbeitungsumgebung zu präsentieren, so dass der Quellcode vom Benutzer modifiziert werden kann.
  • Wenn der Quellcode überarbeitet wird, ist die Codeverwaltungslogik 180 dazu konfiguriert, den überarbeiteten Quellcode zu speichern. Diese Speicherung kann in einer Datei oder in einer Datenbank stattfinden. Die Codeverwaltungslogik 180 ist ferner dazu konfiguriert, den überarbeiteten Quellcode zu kompilieren und den kompilierten Quellcode in der Datenbank 140 zu speichern. Der Quellcode kann in seiner Gesamtheit oder stückweise kompiliert werden. Wenn beispielsweise nur ein Stück des Quellcodes aus einer Datenbank abgerufen und überarbeitet wurde, dann kann nur dieses Stück des Quellcodes erneut kompiliert und in der kompilierten Form in der Datenbank 140 gespeichert werden.
  • Das Rechensystem 100 umfasst wahlweise ferner eine Befehlsinterpretationslogik 190, die dazu konfiguriert ist, einen empfangenen Befehl zu interpretieren. Die Befehlsinterpretationslogik 190 kann auf computerlesbaren Medien innerhalb der Rechenvorrichtung 110 gespeichert sein und ist wahlweise in der Codeausführungslogik 160 und/oder der Codeverwaltungslogik 180 enthalten. Die Befehlsinterpretationslogik 190 ist dazu konfiguriert, einen Befehl zu empfangen und diesen Befehl für die Ausführung des ausführbaren Codes zu verarbeiten. Der empfangene Befehl kann eine Befehlszeile oder einen Universal Resource Locator umfassen und umfasst typischerweise eine Vielzahl von interpretierbaren Objekten.
  • Die Codeverwaltungslogik 180 ist wahlweise zum Verwalten von verschiedenen Instanzen des kompilierten Codes, Quellcodes oder anderer hierin erörterter Informationen innerhalb der Datensätze der Datenbank 140 konfiguriert. Eine erste Version des kompilierten Codes kann beispielsweise in einem ersten Datensatz gespeichert sein und eine zweite Version des kompilierten Codes kann in einem zweiten Datensatz gespeichert sein. Die Datensätze umfassen wahlweise ein Feld, das zum Speichern von Informationen konfiguriert ist, die verwendet werden können, um zwischen den zwei Instanzen zu unterscheiden. Dieses Feld kann einen Versionsidentifikator, ein Passwort, ein Datum, ein Fehlerbeseitigungsflag, eine Browseridentität, ein Label, eine von der Datenbank ausgegebene eindeutige ID (z. B. eine ganze Zahl), eine für den Menschen lesbare Beschreibung und/oder dergleichen umfassen.
  • In einigen Ausführungsbeispielen unterscheiden sich verschiedene Instanzen des Codes durch eine von einem Benutzer durchgeführte Änderung. Ein Benutzer kann beispielsweise den Quellcode überarbeiten und die ursprüngliche Version in einem ersten Datensatz speichern und die neue Version in einem zweiten Datensatz speichern. In einigen Ausführungsbeispielen unterscheiden sich verschiedene Instanzen des Codes in der Weise, in der sie kompiliert wurden. Beispielsweise kann eine Instanz Fehlerbeseitigungsinformationen zur Verwendung in einem Entwicklungsmodus umfassen und einer Instanz können die Fehlerbeseitigungsinformationen fehlen, wie es in einem Erzeugungsmodus erwünscht wäre. In einigen Ausführungsbeispielen unterscheiden sich verschiedene Instanzen des Codes in einer Weise in Bezug auf Sicherheitsniveaus oder Privilegien. Verschiedene Instanzen können beispielsweise ausgewählt werden in Abhängigkeit davon, ob ein Benutzer angemeldet ist, von einem Passwort, einer Identität und/oder Privilegien eines Benutzers, einem Netzwerksicherheitsprotokoll, einer Internetprotokolladresse, einer MAC-Adresse und/oder dergleichen. In einigen Ausführungsbeispielen unterscheiden sich verschiedene Instanzen des Codes in den menschlichen Sprachen, denen sie zugeordnet sind. Eine Instanz kann beispielsweise dazu konfiguriert sein, englische Zeichen zu analysieren, und eine andere Instanz kann dazu konfiguriert sein, chinesische Zeichen zu analysieren. Instanzen können sich in anderen Typen von Funktionalität unterschieden, z. B. darin, wie Berechnungen durchgeführt werden, in Merkmalen, die einem Benutzer angeboten werden, in einem Schnittstellenstil, in Browsern, die sie unterstützen, in der Hardware, die sie unterstützen, und/oder dergleichen.
  • Die Codeverwaltungslogik 180 ist wahlweise ferner dazu konfiguriert, mehrere Instanzen von anderen Informationen als den Code in verschiedenen Datensätzen der Datenbank 140 zu verwalten. Verschiedene Instanzen von Konfigurationsdaten, Formatvorlagen, Anzeigetext können beispielsweise in verschiedenen Datensätzen gespeichert werden. Diese Instanzen können auf der Basis der verfügbaren Hardware, eines Browsertyps, einer bevorzugten menschlichen Sprache und/oder dergleichen ausgewählt werden. Eine spezielle Instanz von Konfigurationsdaten kann beispielsweise ausgewählt werden in Reaktion auf Informationen, die hinsichtlich der verfügbaren Hardware, eines Zielbetriebssystems, Benutzervorlieben und/oder dergleichen empfangen werden.
  • In einigen Ausführungsbeispielen werden Instanzen von verschiedenen Teilen eines Computerprogramms logisch zu einem Instanzsatz gruppiert. Ein Instanzsatz ist eine Vielzahl von Instanzen, die dazu konfiguriert sind, zusammenzuarbeiten. Wenn beispielsweise ein Computerprogramm eine Vielzahl von Teilen umfasst und einige dieser Teile modifiziert werden, können die modifizierten Teile voneinander abhängen. Die Verwendung einer ursprünglichen Instanz eines ersten Teils in Kombination mit einer modifizierten Instanz eines zweiten Teils kann zu einem Fehler führen. In einigen Ausführungsbeispielen ist die Codeverwaltungslogik 180 dazu konfiguriert, Instanzen, die während desselben Ereignisses modifiziert werden, zu einem Instanzsatz zu gruppieren. Diese Gruppierung ist wahlweise automatisch. Die Datensätze der Datenbank 140 umfassen wahlweise ein Feld, das dazu konfiguriert ist, ein oder mehrere Kennzeichen zu speichern, die die Mitgliedschaft in einem Instanzsatz identifizieren. Eine Instanz kann ein Mitglied von mehr als einem Instanzsatz sein. Ein Instanzsatz kann unter Verwendung eines Präfix oder einer Abbildung ausgewählt werden, die anderswo hierin erörtert sind.
  • In einigen Ausführungsbeispielen ist die Codeverwaltungslogik 180 dazu konfiguriert, Merkmale der Datenbankverwaltungslogik 150 zu verwenden, um zu helfen, verschiedene Instanzen zu verwalten. Ein Ereignisprotokollierungsmerkmal, das in der Datenbankverwaltungslogik 150 enthalten ist, wird beispielsweise wahlweise verwendet, um Instanzen innerhalb der Datenbank 140 zu verfolgen. In einem anderen Beispiel kann ein Wiederholungsmerkmal, das in der Datenbankverwaltungslogik 150 enthalten ist, verwendet werden, um vorherige Instanzen wiederherzustellen.
  • Die Fähigkeit, Teile eines Computerprogramms auf einer granuläreren Ebene auszuführen, zu speichern und zu bearbeiten als es im Stand der Technik möglich ist, kann zahlreiche Vorteile aufweisen. Wenn beispielsweise zwei verschiedene Versionen eines Computerprogramms erforderlich sind, dann werden im Stand der Technik zwei Kopien einer Quelldatei und einer ausführbaren Datei aufbewahrt. Wenn die Unterschiede zwischen den Versionen des Computerprogramms in nur einer oder zwei Funktionen vorkommen, dann müssen in einigen Ausführungsbeispielen der Erfindung mehrere Instanzen von nur diesen Funktionen gespeichert werden.
  • Einige Ausführungsbeispiele der Erfindung umfassen eine Zeitplanlogik 185. Die Zeitplanlogik 185 ist dazu konfiguriert, die Ausführung von Funktionen eines Computerprogramms gemäß einem Zeitplan zu ermöglichen. Die Zeitplanlogik 185 kann verwendet werden, um diese Ausführung auf einer funktionsweisen Basis zeitlich zu planen. Die Zeitplanlogik 185 kann beispielsweise eine Anforderung zur Codeausführungslogik 160 senden, um die Ausführung einer in einem Datensatz der Datenbank 140 gespeicherten speziellen Funktion anzufordern. Dies wird wahlweise ohne Ausführung irgendwelcher anderen Teile eines Computerprogramms, von dem die Funktion ein Teil ist, durchgeführt. Die Zeitplanlogik 185 kann auf einem Datenbankserver, einem Webserver, einer Client-Vorrichtung oder dergleichen ausgeführt werden und kann auf einer von der Datenbank 140 oder der Rechenvorrichtung 110 separaten Vorrichtung ausgeführt werden.
  • Interpretierbare Objekte innerhalb eines Befehls können beispielsweise ein vordefiniertes Präfix, eine Abbildung auf die Datenbank 140 und/oder statische Werte umfassen. Ein vordefiniertes Präfix ist ein Objekt, das verwendet wird, um nachfolgende Objekte zu charakterisieren. Ein vordefiniertes Präfix kann beispielsweise verwendet werden, um anzugeben, dass die nächsten drei Objekte innerhalb des Befehls als Abbildung und zwei Werte oder irgendeine andere Kombination von Objekten behandelt werden sollten. Ein durch ein vordefiniertes Präfix spezifiziertes Objekt kann ein anderes vordefiniertes Präfix sein. Dies führt zu einer hierarchischen Beziehung zwischen Objekten innerhalb des Befehls. Die Verwendung von vordefinierten Präfixen ermöglicht auch, dass der Befehl als grammatische Struktur interpretiert wird. Z. B. eine Struktur, in der die Interpretation von Objekten eher von anderen Objekten innerhalb des Befehls als lediglich einer statischen Vorlage abhängen kann. In einigen Ausführungsbeispielen ermöglicht die grammatische Struktur, dass ein Befehl Phrasen von verwandten Objekten umfasst.
  • Ein Abbildungsobjekt ist ein Objekt, das auf einen Datensatz innerhalb der Datenbank 140 abbildet. In verschiedenen Ausführungsbeispielen umfasst ein Abbildungsobjekt einen Index auf einen speziellen Datensatz und/oder kann verwendet werden, um eine Vielzahl von Datensätzen auszuwählen. Da ein Abbildungsobjekt auf einen oder mehrere Datensätze innerhalb der Datenbank 140 abbildet, kann das Abbildungsobjekt verwendet werden, um einen speziellen ausführbaren Code für die Ausführung auszuwählen. Ein Abbildungsobjekt kann beispielsweise an die Codeausführungslogik 160 zur Aufnahme in eine Abfrage übergeben werden. Das übergebene Abbildungsobjekt kann dazu konfiguriert sein, eine von einer Vielzahl von alternativen Funktionen zur Ausführung auszuwählen. In einigen Ausführungsbeispielen kann ein Abbildungsobjekt auch als vordefiniertes Präfix dienen. Ein Abbildungsobjekt kann beispielsweise verwendet werden, um Datensätze innerhalb der Datenbank 140 auszuwählen und auch nachfolgende Objekte innerhalb eines Befehls zu charakterisieren. Ein Wertobjekt umfasst einen statischen Wert wie z. B. eine Zeichenkette, ein Zeichen, eine ganze Zahl, eine Gleitkommazahl oder irgendeinen anderen einfachen oder zusammengesetzten Datentyp. Ein Abbildungsobjekt kann Datenbankreferenzen umfassen, die eine Beziehung von vielen zu vielen zwischen einem Satz von Abbildungen und einem in der Datenbank 140 gespeicherten kompilierten Code herstellen. Ein Abbildungsobjekt kann auf einen Datensatz abbilden, der ein gespeichertes Abbildungsobjekt umfasst. Dieses gespeicherte Abbildungsobjekt kann zwischen Identifikatoren und dem in der Datenbank 140 gespeicherten kompilierten Code abbilden.
  • Die Verwendung von verschiedenen Objekten mit einem Befehl wird durch ein Beispiel unter Verwendung des Universal Resource Locator ”http://xsevo.com/itemA/1/itemB/2/edit_production” erläutert. Dieser Befehl umfasst die Protokollinformation ”http” und eine Zeichenkette ”xsevo.com”, die in eine Internetprotokoll-(IP)Adresse umwandelbar ist. Dieser Befehl umfasst ferner 5 Objekte, die durch die Befehlsinterpretationslogik 190 interpretiert werden. Diese Objekte können auf eine Vielfalt von verschiedenen Weisen in Reaktion auf irgendwelche vordefinierten Präfixe, die unter den Objekten enthalten sein können, interpretiert werden.
  • ”itemA” kann beispielsweise ein vordefiniertes Präfix sein, das spezifiziert, dass ein Wertobjekt folgen sollte, ein vordefiniertes Präfix, das spezifiziert, dass ein Wertobjekt und ein zweites vordefiniertes Präfix folgen sollten, oder ein vordefinierte Präfix, das spezifiziert, dass drei Wertobjekte folgen sollten. Das vordefinierte Präfix kann den Datentyp eines Wertobjekts spezifizieren. ”itemA” kann beispielsweise spezifizieren, dass das erste Wertobjekt ”1” als ganze Zahl behandelt werden soll und das zweite Wertobjekt ”itemB” als Zeichenkette behandelt werden soll. Die durch ein vordefiniertes Präfix definierten Objekte werden als grammatische Phrase dieses vordefinierten Präfixes betrachtet.
  • Wenn das Objekt ”itemB” auch ein vordefiniertes Präfix ist, kann es ein Teil der grammatischen Phrase von ”itemA” oder der Beginn einer zweiten unabhängigen grammatischen Phrase sein. Wenn ein zweites vordefiniertes Präfix ein Teil einer grammatischen Phrase ist, die durch ein erstes vordefiniertes Präfix definiert ist, existiert eine hierarchische Beziehung zwischen den vordefinierten Präfixen. Das zweite vordefinierte Präfix und irgendwelche durch das zweite Objekt definierten Objekte können als Töchter und/oder Enkeltöchter des ersten vordefinierten Präfixes betrachtet werden.
  • In einigen Ausführungsbeispielen umfasst ein vordefiniertes Präfix ein Gemisch von Datentypbezeichnungen und anderen Objekten. Ein vordefiniertes Präfix kann beispielsweise eine Datentypbezeichnung für ein anderes Objekt innerhalb eines Befehls und auch einen statischen Wert, eine Abbildung oder irgendein anderes vordefiniertes Präfix umfassen. In einem Ausführungsbeispiel umfasst ein vordefiniertes Präfix eine erste Zeichenkettentypbezeichnung, eine Typbezeichnung einer ganzen Zahl, einen statischen Booleschen Wert und eine Abbildung.
  • Typischerweise ist die Befehlsinterpretationslogik 190 dazu konfiguriert, einen Befehl durch Betrachten jeweils eines Objekts auf einmal und Behandeln jedes Objekts als Funktion von irgendwelchen vorher betrachteten vordefinierten Präfixen zu analysieren. Ein vordefiniertes Präfix wird typischerweise vor dem Empfang eines Befehls definiert, beispielsweise von einem Benutzer wie z. B. einem Programmierer. Vordefinierte Präfixe können an einer Stelle gespeichert werden, die für die Befehlsinterpretationslogik 190 zugänglich ist. Die Befehlsinterpretationslogik 190 ist dazu konfiguriert, Objekte innerhalb eines Befehls mit diesen gespeicherten vordefinierten Präfixen zu vergleichen.
  • In einigen Ausführungsbeispielen wird, wenn ein Objekt innerhalb eines Befehls nicht als vordefiniertes Präfix erkannt wird und kein Objekt ist, das durch ein vordefiniertes Präfix charakterisiert ist, dann das Objekt als Abbildung betrachtet. In dem vorstehend erörterten beispielhaften Universal Resource Locator kann beispielsweise das Objekt ”edit_production” eine Abbildung auf einen Datensatz innerhalb der Datenbank 140 sein. Als Abbildung wird ”edit_production” an die Codeausführungslogik 160 übergeben, wo das Objekt verwendet wird, um eine Abfrage zu erzeugen. Diese Abfrage wird dann auf die Datenbank 140 unter Verwendung der Datenbankverwaltungslogik 150 angewendet. In einigen Ausführungsbeispielen wird eine Abbildung direkt in einer Abfrage als Suchbegriff verwendet. In dem vorstehend erörterten Beispiel kann die Abbildung ”edit_production” auf den kompiliert Code abbilden, der zum Überarbeiten des Quellcodes in einem Erzeugungsmodus konfiguriert ist. Eine alternative Abbildung wie z. B. ”edit_development” kann auf den kompilierten Code abbilden, der zum Überarbeiten des Quellcodes in einem Entwicklungsmodus konfiguriert ist. Die Objekte ”itemA”, ”1”, ”itemB” und ”2” könnten verwendet werden, um den zu überarbeitenden Quellcode, Versionsinformationen, Zugriffsanforderungen, Editoroptionen, Login-Informationen oder dergleichen zu identifizieren.
  • In einigen Ausführungsbeispielen sind Abbildungsobjekte und/oder vordefinierte Präfixe von zwei allgemeinen Arten. Objekte einer ersten Art sind so konfiguriert, dass sie in einem exakten Übereinstimmungsvergleich verwendet werden, während Objekte einer zweiten Art so konfiguriert sind, dass sie als regulärer Ausdruck verwendet werden. Ein regulärer Ausdruck ist ein flexibles Mittel zum Identifizieren von Objekten wie z. B. Textzeichenketten. Ein regulärer Ausdruck ”edit\d” umfasst beispielsweise ein Platzhalterzeichen ”\d” und kann verwendet werden, um Textzeichenketten ”edit1”, ”edit2” oder dergleichen zu vergleichen. Ein regulärer Ausdruck kann in einer empfangenen Befehlszeile oder einem empfangenen Universal Resource Locator, in einem gespeicherten vordefinierten Präfix oder in einem Datensatz verwendet werden. Ein regulärer Ausdruck kann einem exakten Ausdruck gegenübergestellt werden, der ein Ausdruck ist, der zum Durchführen eines exakten Vergleichs konfiguriert ist.
  • Ein regulärer Ausdruck kann so konfiguriert sein, dass er mit einer ganzen Befehlszeile oder einem ganzen Universal Resource Locator verglichen wird. Alternativ kann ein regulärer Ausdruck so konfiguriert sein, dass er mit einer Teilmenge einer Befehlszeile oder eines Universal Resource Locator verglichen wird. Beispielsweise kann ein regulärer Ausdruck mit einem einzelnen Objekt oder einer grammatischen Phrase innerhalb eines Befehls verglichen werden. Ein regulärer Ausdruck wird wahlweise verwendet, um ein Objekt, das als Teil eines Befehls empfangen wird, in zwei Parameter zu trennen. Beispielsweise kann ein empfangenes Objekt ”edit6” mit einem vordefinierten Präfix ”edit\d” verglichen werden. In diesem Fall können das ”edit” und die ”6” des empfangenen Objekts getrennt und unabhängig verwendet werden. Insbesondere kann eine Abbildung ”edit(?P<Id>\d) verwendet werden, um einen Parameter Id = 6 an einen Zielcode zu übergeben, wenn er mit der Zeichenkette ”edit6” verglichen wird. Unter anderen Vorteilen kann dies eine leichte Bezugnahme auf mehrere verschiedene Versionen eines kompilierten Codes ermöglichen, auf den das ”edit”-Objekt abgebildet wird.
  • Die Befehlsinterpretationslogik 190 ist wahlweise für die Vererbung von Attributen zwischen Elementen eines empfangenen Befehls konfiguriert. Das Analysieren des Befehls kann beispielsweise als Analysebaum betrachtet werden und Attribute können an diesem Baum (nach oben und/oder unten) vererbt werden. Werte in einem Kindobjekt können Werte, die in einem Mutterobjekt festgelegt sind, außer Kraft setzen oder umgekehrt. Ein Befehl, der /itemA/itemB/edit_production” aufweist, wobei itemA und itemB jeweils Präfixe sind und edit_production eine Abbildung ist, kann beispielsweise die Präfixe itemA und itemB verwenden, um jeweils einen oder mehrere Parameter festzulegen, die an edit_production übergeben werden. Einer oder mehrere Parameter, die durch itemA festgelegt sein, können durch itemB außer Kraft gesetzt werden. ItemB kann eine Teilmenge der durch itemA festgelegten Parameter außer Kraft setzen.
  • Die Befehlsinterpretationslogik 190 ist wahlweise unter mehreren Teilen des Rechensystems 100 verteilt. Ein Teil der Befehlsinterpretationslogik 190 kann beispielsweise in der Codeausführungslogik 160 enthalten sein und ein Teil der Befehlsinterpretationslogik 190 kann in der Codeverwaltungslogik 180 enthalten sein.
  • 2 stellt eine Datenstruktur 200, wie sie in der Datenbank 140 enthalten sein kann, gemäß verschiedenen Ausführungsbeispielen der Erfindung dar. Die Datenstruktur 200 weist eine Vielzahl von Datensätzen 210 auf, die individuell mit 210A, 210B, ... 210N bezeichnet sind. Die Datenstruktur 200 kann eine beliebige Anzahl von Datensätzen 210 umfassen. Jeder der Datensätze 210 weist eine Vielzahl von Datenfeldern 220 auf, die individuell mit 220A, 220B, ... 220N bezeichnet sind. Jeder der Datensätze 210 kann mehr oder weniger Felder 220 als in 2 dargestellt umfassen. Diese Felder 220 sind unter Verwendung von Abfragen, die durch die Datenbankverwaltungslogik 150 ausgeführt werden, zugänglich, lesbar und beschreibbar. Typischerweise sind mehrere Instanzen der Datenstruktur 200 in der Datenbank 140 enthalten. Jede Datenstruktur 200 ist wahlweise in einer anderen Datei gespeichert. Die Reihenfolge der in 2 dargestellten Datenfelder 220 kann in alternativen Ausführungsbeispielen verändert sein.
  • In einem beispielhaften Ausführungsbeispiel ist ein Feld 220A dazu konfiguriert, einen Datensatzindexwert zu speichern. Der Indexwert ist typischerweise ein eindeutiger Identifikator, der dazu konfiguriert ist, einen speziellen Datensatz zu identifizieren. Der Indexwert wird wahlweise als Label verwendet, um den Programmablauf zu steuern. Ein Feld 220B ist dazu konfiguriert, ein Stück eines ausführbaren Codes oder Quellcodes eines Computerprogramms zu speichern. Wie anderswo hierin erörtert, kann dieser Code auf einer zeilenweisen Basis, auf einer Funktionsbasis, auf einer funktionalen Basis, auf einer Basis basierend auf dem Programmablauf oder auf irgendeiner anderen Basis zum Unterteilen des Computerprogramms in separate Stücke gespeichert werden.
  • Ein optionales Feld 220C ist dazu konfiguriert, einen Daten- oder Funktionstyp zu speichern. Dieser Typ kann der Typ eines Werts (oder Objekts) sein, der von dem im Feld 220B gespeicherten Code erwartet wird, oder der Typ eines Werts (oder Objekts), der von dem im Feld 220B gespeicherten Code zurückgegeben wird.
  • Ein optionales Feld 220D ist dazu konfiguriert, Daten zu speichern, zu deren Bearbeitung der im Feld 220B gespeicherte Code konfiguriert ist. Das Datenfeld 220D kann beispielsweise Konstanten zur Verwendung durch den gespeicherten Code umfassen.
  • Die Datensätze 210 können eine breite Vielfalt von zusätzlichen Feldern, die in 2 durch das Feld 220N dargestellt sind, umfassen. Ein oder mehrere Felder 220N können Felder umfassen, die dazu konfiguriert sind, Folgendes zu speichern: weitere Label, die dazu konfiguriert sind, den Programmablauf zu steuern, ein Label (oder einen Indexwert) eines nachfolgenden Stücks des Codes, einen Versionsidentifikator des im Feld 22B gespeicherten Codes, Konfigurationsinformationen, Abbildungsinformationen, Zeitplaninformationen, eine für den Menschen lesbare Beschreibung oder Erläuterung des Codes, Organisationsinformationen für einen Editor oder dergleichen.
  • Die Datenbank 140 ist typischerweise in einer oder mehreren Tabellen gespeichert, die jeweils eine Instanz der Datenstruktur 200 umfassen. Diese Tabellen werden wahlweise unter Verwendung eines JOIN-Befehls oder dergleichen kombiniert. In einigen Ausführungsbeispielen wird beispielsweise der Code in einer ersten Datenbanktabelle gespeichert, die Funktionstypen, Funktionsnamen, Funktionsparameter und Vorgabedaten umfasst, einer zweiten Tabelle, die einen Quellcode für jede Instanz einer Funktion umfasst, und einer dritten Tabelle, die einen kompilierten Bytecode (oder dergleichen) jeder Funktionsinstanz umfasst.
  • 3 stellt verteilte Ausführungsbeispiele des Rechensystems 100 dar. In diesen Ausführungsbeispielen ist das Rechensystem 100 beispielsweise in einen Verwaltungsserver 305 und einen Datenbankserver 310 unterteilt. Der Verwaltungsserver 305 umfasst eine Betriebssystemlogik 130, eine Codeausführungslogik 160 und wahlweise eine Codekompilierungslogik 170 und eine Codeverwaltungslogik 180. Der Datenbankserver 310 umfasst eine Datenbank 140 und eine Datenbankverwaltungslogik 150. Der Verwaltungsserver 305 und der Datenbankserver 310 sind dazu konfiguriert, durch einen Teil des Netzwerks 120, beispielsweise ein lokales Netzwerk 120A, miteinander zu kommunizieren. Der Verwaltungsserver 305 ist wahlweise dazu konfiguriert, mit mehr als einer Instanz des Datenbankservers 310 zu kommunizieren. Jede dieser Instanzen kann dazu konfiguriert sein, ein oder mehrere verschiedene Computerprogramme zu unterstützen. In einigen Ausführungsbeispielen wird eine Instanz der Datenbank 140 als Master-Datenbank behandelt und andere Instanzen der Datenbank 140, die wahlweise auf separaten Vorrichtungen gespeichert sind, werden als Slave-Datenbanken behandelt. Die Master-Datenbank kann beispielsweise als aktuellster Zustand der Daten betrachtet werden, während die Slave-Datenbanken Reproduktionen des Masters sind.
  • Der Verwaltungsserver 305 ist ferner dazu konfiguriert, mit einem oder mehreren Clients 315, die hierin als Client 315A, Client 315B, Client 315C usw. bezeichnet sind, zu kommunizieren. Diese Kommunikation kann durch einen anderen Teil des Netzwerks 120, beispielsweise das Internet 120B, stattfinden. In einigen Ausführungsbeispielen ist der Verwaltungsserver 305 so konfiguriert, dass auf ihn durch Benutzer der Clients über einen Internetbrowser 320, z. B. den Internet Explorer oder Firefox, zugegriffen wird. Dieser Zugriff kann die Ausführung von Computerprogrammen, die in der Datenbank 140 gespeichert sind, und/oder eine Entwicklung und Modifikation dieser Computerprogramme umfassen.
  • 4 stellt Verfahren zum Ausführen eines Computerprogramms gemäß verschiedenen Ausführungsbeispielen der Erfindung dar. Wie anderswo hierin beschrieben, wird das Computerprogramm durch Abrufen des ausführbaren Codes aus einer Datenbank und Ausführen dieses abgerufenen Codes auf einem Betriebssystem außerhalb der Datenbank ausgeführt. Diese Verfahren können unter Verwendung des Rechensystems 100 wahlweise in Reaktion auf Kommunikationen, die von den Clients 315 empfangen werden, durchgeführt werden. Die in 4 dargestellten Schritte können in alternativen Reihenfolgen durchgeführt werden.
  • In einem Anforderungsempfangsschritt 410 wird eine Anforderung zum Ausführen eines Computerprogramms durch das Rechensystem 100 empfangen. Diese Anforderung kann von einer anderen Rechenvorrichtung, von einem Benutzer des Verwaltungsservers 305 oder von einem Benutzer von einem der Clients 315 empfangen werden. In einigen Ausführungsbeispielen wird die Anforderung über den Browser 320 empfangen, umfasst einen Universal Resource Locator (URL) und/oder wird über HTTP übertragen, wird über TCP/IP übertragen und/oder wird unter Verwendung einer POST-Operation bereitgestellt. Zusätzlich zu Informationen, die das Computerprogramm identifizieren, umfasst die Anforderung wahlweise andere Daten wie z. B. Sicherheitsinformationen, Konfigurationsdaten, Versionsinformationen, hochgeladene Dateidaten, ein Bild, Video oder dergleichen.
  • In einem Abfrageausführungsschritt 415 wird eine Abfrage zur Datenbankverwaltungslogik 150 bereitgestellt. Diese Abfrage ist dazu konfiguriert, eine Teilmenge des kompilierten Codes des Computerprogramms von einem der Datensätze 210 innerhalb der Datenbank 140 abzurufen. Die Abfrage kann eine vorbestimmte Abfrage sein oder kann in Reaktion auf Daten, die als Teil der Anforderung empfangen werden, konfiguriert werden.
  • In einem Codeabrufschritt 420 führt die Ausführung der im Abfrageausführungsschritt 415 ausgeführten Abfrage zum Abruf eines ersten Stücks des Codes aus der Datenbank 140. Dieses erste Stück des Codes ist eine Teilmenge des Codes des Computerprogramms. Wie anderswo hierin erörtert, kann der abgerufene Code eine einzelne Funktion, eine einzelne Funktionseinheit, ein Codeblock zwischen bedingten Verzweigungen in einem Programmablauf, eine einzelne Codezeile oder eine andere Unterteilung des gesamten Codes des Computerprogramms sein.
  • Wenn der Abruf des Codes im Codeabrufschritt 420 fehlschlägt, z. B. wenn der Code nicht erhältlich ist, dann wird in einem optionalen Codeerzeugungsschritt 425 der kompilierte Code aus dem Quellcode unter Verwendung der Codekompilierungslogik 170 erzeugt. Dieser erzeugte Code wird dann in einem der Datensätze 210 der Datenbank 140 gespeichert. Der Codeerzeugungsschritt 425 kann alles oder eine Teilmenge des gesamten Codes des Computerprogramms umfassen. Wenn der ganze Code erzeugt wird, dann werden verschiedene Teile des erzeugten Codes in verschiedenen Datensätzen 210 gespeichert.
  • In einem optionalen Schritt 430 zum Speichern des kompilierten Codes wird irgendein im Codeerzeugungsschritt 425 erzeugter Code in einem oder mehreren Datensätzen 210 der Datenbank 140 unter Verwendung der Datenbankverwaltungslogik 150 gespeichert. Der Codeabrufschritt 420 wird dann wieder versucht. Diese Speicherung kann in einer ursprünglichen Kopie der Datenbank 140 oder einer gecacheden Kopie der Datenbank 140 stattfinden. Eine gecachede Kopie wird wahlweise durch die Codeausführungslogik 160 oder andere Elemente des Rechensystems 100 erzeugt.
  • In einem Codebereitstellungsschritt 435 wird der im Codeabrufschritt 420 abgerufene ausführbare Code der Betriebssystemlogik 130 zur Ausführung bereitgestellt. Diese Ausführung hängt typischerweise nicht von der Datenbankverwaltungslogik 150 ab. Wie in 3 dargestellt, sind beispielsweise die Betriebssystemlogik 130 und die Datenbankverwaltungslogik 150 wahlweise auf verschiedenen Rechenvorrichtungen enthalten. Der Code wird somit wahlweise auf der Betriebssystemlogik 130 entfernt von der Datenbankverwaltungslogik 150 ausgeführt.
  • In einem Abfrageerzeugungsschritt 440 wird eine zweite Abfrage erzeugt. Diese Abfrage ist dazu konfiguriert, einen weiteren Code des Computerprogramms aus der Datenbank 140 abzurufen. Die zweite Abfrage basiert wahlweise auf einem Ergebnis der Ausführung des abgerufenen ersten Codes. Die Ausführung des abgerufenen ersten Codes kann beispielsweise einen Wert erzeugen, der einen Programmablauf bestimmt, z. B. das Objekt einer nachfolgenden IF- oder CASE-Anweisung. Dieser Wert kann dann in die zweite Abfrage als Parameter aufgenommen werden.
  • In einem Abfrageverwendungsschritt 445 wird die erzeugte zweite Abfrage verwendet, um einen zweiten der Datensätze 210 der Datenbank 140 zu identifizieren. Dieser zweite der Datensätze 210 kann einen kompilierten Code des Computerprogramms, einen anderen ausführbaren Code, einen nicht-kompilierten Code, Daten, Skripten, eine Dokumentenauszeichnungssprache, Bilder, einen Quellcode und/oder dergleichen umfassen.
  • In einem Codeempfangsschritt 450 wird der ausführbare Code vom zweiten Datenbankdatensatz als Ergebnis der zweiten Abfrage empfangen. Dieser Code wird durch eine Rechenvorrichtung mit der Betriebssystemlogik 130, beispielsweise dem Verwaltungsserver 305, empfangen. Der ausführbare Code wird wahlweise über das Netzwerk 120 empfangen.
  • In einem Codebereitstellungsschritt 455 wird der im Codeempfangsschritt 445 empfangene ausführbare Code der Betriebssystemlogik 130 zur Ausführung bereitgestellt. Diese Ausführung ist wahlweise von der Datenbankverwaltungslogik 150 unabhängig, obwohl die Ausführung ein Ergebnis erzeugen kann, das später verwendet wird, um auf die Datenbank 140 unter Verwendung der Datenbankverwaltungslogik 150 zuzugreifen. An sich können die Schritte Abfrageerzeugung 440 bis Codebereitstellung 455 wiederholt werden, um mehrere Stücke des Codes aus der Datenbank 140 abzurufen und auszuführen. Dieser Prozess kann fortfahren, bis das Computerprogramm beendet wird.
  • 5 stellt Verfahren zum Erzeugen und Modifizieren eines Computerprogramms gemäß verschiedenen Ausführungsbeispielen der Erfindung dar In diesen Verfahren wird ein Quellcode empfangen und kompiliert. Der kompilierte Code wird auf eine indizierte Weise in mehreren Stücken innerhalb der Datensätze 210 gespeichert. Das Verfahren umfasst wahlweise weitere Schritte, in denen der Quellcode oder andere Daten gespeichert werden, der gespeicherte kompilierte Code modifiziert wird, die Datenbankverwaltungslogik 150 verwendet wird, um zusätzliche Merkmale vorzusehen, und/oder das Datenbank-Computerprogramm durch Bereitstellen einer Kopie der Datenbank 140 bereitgestellt wird. Die in 5 dargestellten Schritte können in alternativen Reihenfolgen durchgeführt werden.
  • In einem Quellcodeempfangsschritt 510 wird der Quellcode eines Computerprogramms durch das Rechensystem 100 empfangen. Das Computerprogramm kann von einer Speichervorrichtung, von einer anderen Rechenvorrichtung über das Netzwerk 120 oder von einem Benutzer, der Text eingibt, empfangen werden. Der empfangene Quellcode umfasst typischerweise eine Vielzahl von Funktionen.
  • In einem Kompilierungsschritt 515 wird der im Quellcodeempfangsschritt 510 empfangene Quellcode unter Verwendung der Codekompilierungslogik 170 kompiliert. Dieser Schritt kann das Erzeugen eines einzelnen Blocks des kompilierten Codes oder das Erzeugen von mehreren Stücken des kompilierten Codes, der wie anderswo hierin erörtert unterteilt ist, umfassen. Die Codekompilierungslogik 170 kann beispielsweise verwendet werden, um den kompilierten Code in Stücke zu unterteilen, die separat in Datensätzen 210 der Datenbank 140 gespeichert werden können. In einigen Ausführungsbeispielen wird beispielsweise die Codekompilierungslogik 170 verwendet, um separate Stücke des kompilierten Codes auf der Basis von Funktionen oder des Programmablaufs des Quellcodes zu erzeugen. Der im Kompilierungsschritt 515 erzeugte kompilierte Code ist zur Ausführung auf der Betriebssystemlogik 130 konfiguriert und liegt typischerweise in einem Bytecode, Objektcode, Maschinencode und/oder dergleichen vor.
  • In einem Speicherschritt 520 wird der im Kompilierungsschritt 515 erzeugte kompilierte Code in Datensätzen 210 der Datenbank 140 gespeichert. Jedes Stück des kompilierten Codes wird wahlweise in einem separaten Mitglied der Datensätze 210 gespeichert.
  • Wenn der Code in mehreren Stücken im Kompilierungsschritt 515 erzeugt wurde, dann können diese Stücke typischerweise direkt gespeichert werden. Wenn jedoch der Kompilierungsschritt 515 einen einzelnen Block des kompilierten Codes ergibt, dann umfasst der Speicherschritt 520 das Unterteilen dieses Blocks in separate Stücke. Diese Unterteilung kann unter Verwendung der Codeverwaltungslogik 180 durchgeführt werden und umfasst typischerweise das Unterteilen des Codes auf einer oder mehreren der anderswo hierin erörterten Basen.
  • Der Speicherschritt 520 umfasst wahlweise das Speichern von weiteren Informationen zusätzlich zum kompilierten Code. Der Speicherschritt 520 kann beispielsweise das Speichern eines anderen ausführbaren Codes, eines Konfigurationscodes, von Daten, die durch den Code verarbeitet werden sollen, Datentypinformationen oder irgendwelchen der anderen hierin erörterten Informationen umfassen.
  • In einem Indexschritt 525 werden die Mitglieder der Datensätze 210, in denen der kompilierte Code gespeichert ist, indiziert. Der Indizierungsprozess wird typischerweise unter Verwendung der Codeverwaltungslogik 180 und/oder der Datenbankverwaltungslogik 150 durchgeführt. Die Indizierung ist für die Identifikation und das Abrufen des gespeicherten kompilierten Codes und wahlweise anderer Informationen konfiguriert. Jedes separat gespeicherte Stück des Codes ist typischerweise einem eindeutigen Index oder Satz von Indizes zugeordnet. Folglich kann jedes Stück des Codes unter Verwendung der Indizierung identifiziert werden. In einigen Ausführungsbeispielen umfasst der Indexschritt 525 das Hinzufügen von Labeln (oder anderer Identifikatoren), die für den Programmablauf sinnvoll sind, zu Datensätzen 210. Ein im Indexschritt 525 hinzugefügtes Label kann beispielsweise ein Stück des Codes als Programmablaufziel nach einer bedingten Anweisung identifizieren.
  • In einem optionalen Quellenspeicherschritt 530 wird der im Quellcodeempfangsschritt 510 empfangene Quellcode gespeichert. Der Quellcode wird wahlweise in Stücken mit dem kompilierten Code in der Datenbank 140 oder in Stücken in einer separaten Datenbank mit einer Struktur, die zu jener der Datenbank 140 ähnlich ist, gespeichert, z. B. wo das Feld 220 verwendet wird, um eher den Quellcode als den kompilierten Code zu speichern. Alternativ kann der Quellenspeicherschritt 530 das Speichern des Quellcodes in einer herkömmlichen Textdatei umfassen.
  • In einem optionalen Konfigurationsdatenspeicherschritt 535 werden Konfigurationsdaten in der Datenbank 140 gespeichert. Diese Konfigurationsdaten sind zum Versehen eines Benutzers mit alternativen Konfigurationen des Computerprogramms, das durch den empfangenen Quellcode dargestellt ist, konfiguriert. In einigen Ausführungsbeispielen wird beispielsweise mehr als ein Satz von Konfigurationsdaten in der Datenbank 140 gespeichert, jeder Satz in einem anderen Datensatz. Eine unter Verwendung der Datenbankverwaltungslogik 150 ausgeführte Abfrage kann dann verwendet werden, um eine Konfiguration abzurufen, die von einem Benutzer gewünscht wird oder für ein spezifisches Hardwareziel geeignet ist, oder dergleichen.
  • In einem optionalen Modifikationsschritt 540 wird der kompilierte Code innerhalb der Datensätze 210 modifiziert. Dieser Modiffkationsprozess kann das Ändern des gespeicherten Quellcodes oder das Empfangen eines neuen Quellcodes, das Kompilieren des geänderten oder neuen Quellcodes und das Ersetzen des in einem oder mehreren der Datensätze 210 gespeicherten kompilierten Codes durch den neuen kompilierten Quellcode umfassen. Der Modifikationsschritt 540 kann durchgeführt werden unter Verwendung der Codeverwaltungslogik 180, um den Quellcode zu modifizieren, der Codekompilierungslogik 170, um den Quellecode zu kompilieren, und der Datenbankverwaltungslogik 150, um den neuen kompilierten Code in einem oder mehreren der Datensätze 210 zu speichern.
  • Der Modifikationsschritt 540 wird wahlweise jeweils an einem Stück des kompilierten Codes zu einer Zeit durchgeführt. Die Modifikation kann beispielsweise am kompilierten Code, der in nur einem oder einer Teilmenge der Datensätze 210 gespeichert ist, durchgeführt werden. Ein anderer kompilierter Code desselben Computerprogramms muss nicht notwendigerweise erneut kompiliert werden. An sich können die Modifikation und das erneute Kompilieren begrenzt sein auf ein einziges Stück des Codes, das vom anderen Code auf der Basis der Funktion, Funktionalität, des Programmablaufs oder dergleichen getrennt ist. In einigen Ausführungsbeispielen ist die Codekompilierungslogik 170 dazu konfiguriert, in einem Erzeugungsmodus und einem Entwicklungsmodus zu arbeiten. Eine größere Menge des kompilierten Codes wird im Erzeugungsmodus relativ zum Entwicklungsmodus nach der Modifikation des Codes erneut kompiliert.
  • In einem optionalen Versionsverwaltungsschritt 545 werden eine Versionssteuerung des gespeicherten kompilierten Codes und anderer Teile des Computerprogramms unter Verwendung von Protokollierungsfähigkeiten der Datenbankverwaltungslogik 150 durchgeführt. In einigen Ausführungsbeispielen umfasst die Datenbankverwaltungslogik 150 beispielsweise ein Protokollierungsmerkmal, das dazu konfiguriert ist, Änderungen in der Datenbank 140 zu protokollieren. Dieses Merkmal kann verwendet werden, um Änderungen im Computerprogramm zu verfolgen. Ebenso kann die Datenbankverwaltungslogik 150 ein Wiederholungsmerkmal aufweisen, das dazu konfiguriert ist, die Datenbank in einen vorherigen Zustand zurückzuführen. Dieses Merkmal kann verwendet werden, um vorherige Versionen des Codes wiederherzustellen. In einigen Ausführungsbeispielen ist die Datenbankverwaltungslogik 150 dazu konfiguriert, mehrere Kopien der Datenbank 140 oder von einzelnen Datensätzen 210 aufzubewahren und diese Kopien unter Verwendung von Versionsinformationen zu verfolgen.
  • In einem optionalen Zugriffssteuerschritt 550 werden Zugriffssteuermerkmale der Datenbankverwaltungslogik 150 verwendet, um den Zugriff auf das Computerprogramm oder auf Merkmale desselben zu steuern. Beispielsweise kann die Datenbankverwaltungslogik 150 dazu konfiguriert sein, den Zugriff auf spezielle Datensätze 210 oder Sätze davon innerhalb der Datenbank 140 zu steuern (oder den Zugriff auf die Datenbank 140 in ihrer Gesamtheit zu steuern). Diese Zugriffssteuerung kann verwendet werden, um zu verhindern, dass ein Benutzer auf Stücke des kompilierten Codes zugreift, die einer spezifischen Funktionalität, spezifischen Daten, Bildern oder irgendeinem anderen Aspekt des Computerprogramms zugeordnet sind.
  • In einem optionalen Bereitstellungsschritt 555 wird das Computerprogramm zu einer Rechenvorrichtung durch Bereitstellen einer Kopie der Datenbank 140 für die Rechenvorrichtung bereitgestellt. Diese Bereitstellung kann über das Netzwerk 120 stattfinden. Der Schritt nutzt die Tatsache, dass in einigen Ausführungsbeispielen die Datenbank 140 portabel ist.
  • 6 stellt ein Verfahren zum Interpretieren eines Befehls unter Verwendung des Rechensystems von 1 gemäß verschiedenen Ausführungsbeispielen der Erfindung dar. Der interpretierte Befehl kann eine Befehlszeile oder einen Universal Resource Locator umfassen. Obwohl die in 6 dargestellten Schritte mit Bezug auf den kompilierten Code erörtert werden, können sie auch in Bezug auf andere Arten eines ausführbaren Codes und/oder von Daten durchgeführt werden.
  • In einem optionalen Definitionsschritt 610 wird ein Präfix vordefiniert. Diese Vordefinition kann durch einen Programmierer oder Systemverwalter beispielsweise unter Verwendung der Codeverwaltungslogik 180, Datenbankverwaltungslogik 150 oder eines Editors durchgeführt werden. Die Vordefinition umfasst typischerweise eine Spezifikation eines Labels, das das vordefinierte Präfix identifiziert, und einen oder mehrerer Datentypen, die Objekte charakterisieren. Ein vordefiniertes Präfix kann beispielsweise ”Mitglied; Zeichenkette; ganze Zahl; Präfix” umfassen. Dieses vordefinierte Präfix umfasst ein Label ”Mitglied”, das dazu konfiguriert ist, das vordefinierte Präfix zu identifizieren und dieses Label mit dem vordefinierten Präfix zu vergleichen, wenn das Label in einem Befehl vorkommt. Dieses vordefinierte Präfix umfasst ferner Datentypen ”Zeichenkette” und ”ganze Zahl”, die in einigen Ausführungsbeispielen dazu konfiguriert sind, anzugeben, dass die nächsten zwei Objekte als Zeichenkette bzw. ganze Zahl behandelt werden sollten. Dieses vordefinierte Präfix umfasst ferner einen Typ ”Präfix”. Dieser Typ wird wahlweise verwendet, um anzugeben, dass ein Objekt als vordefiniertes Tochterpräfix behandelt werden sollte. In verschiedenen Ausführungsbeispielen kann ein vordefiniertes Präfix eine breite Vielfalt von alternativen Syntaxen, Typen und dergleichen umfassen.
  • In verschiedenen Ausführungsbeispielen kann ein Präfix ein oder mehrere der Folgenden umfassen: a) einen eindeutigen Identifikator, z. B. eine ganze Zahl, für das Präfix; b) eine Zeichenkette, die zum Vergleichen des Präfix verwendet wird; c) und einen Identifikator, z. B. eine ganze Zahl oder einen Zeiger, eines Mutterpräfix; d) eine Zeichenkette, die mögliche Objekte, z. B. Werte, die innerhalb eines Befehls zu erwarten sind, und Variablen, denen die Werte zugewiesen werden sollen, identifiziert; e) eine Zeichenkette, die statische Werte, die an den ausführbaren Code übergeben werden sollen, und Variablen des ausführbaren Codes zum Zuweisen dieser Werte identifiziert; f) ein Freigabe/Sperr-Flag; g) einen für den Menschen lesbaren Namen des Präfix; h) einen Schlüssel zu einer externen Datenbank; i) einen Formatvorlagenidentifikator; einen Anwendungsidentifikator, der dazu konfiguriert ist, eine oder mehrere Anwendungen zu identifizieren, zu denen das Präfix gehört; j) einen Konfigurationsparameter; k) Informationen (z. B. eine Internetprotokolladresse) in Bezug auf Websites, auf denen das Präfix erhältlich ist und/oder verwendet werden kann; und 1) eine für den Menschen lesbare Beschreibung des Präfix. Die vordefinierten Präfixe werden an einer Stelle gespeichert, auf die die Befehlsinterpretationslogik 190 zugreifen kann, wahlweise in der Datenbank 140.
  • In einem optionalen Bereitstellungsschritt 615 wird ein Computerprogramm auf einer Rechenvorrichtung bereitgestellt, wie z. B. dem Datenbankserver 310 durch Übertragen der Datenbank 140 und eines Satzes von vordefinierten Präfixen zur Rechenvorrichtung.
  • In einem Empfangsschritt 620 wird ein Befehl durch das Rechensystem 100 empfangen. Dieser Befehl umfasst eine Vielzahl von Objekten, beispielsweise ein vordefiniertes Präfix, einen Wert, eine Abbildung und/oder dergleichen. Typischerweise umfasst der Befehl eine Befehlszeile oder einen Universal Resource Locator oder dergleichen. In einigen Ausführungsbeispielen wird der Befehl über einen Browser und/oder ein Netzwerk wie z. B. das Netzwerk 120B empfangen.
  • In einem Analyseschritt 625 wird der im Empfangsschritt 620 empfangene Befehl unter Verwendung der Befehlsinterpretationslogik 190 analysiert. Wie anderswo hierin erörtert, kann diese Analyse eine Identifikation von vordefinierten Präfixen, Abbildungen, Werten und/oder anderer Objekte innerhalb des empfangenen Befehls umfassen. Der Analyseschritt 625 umfasst die Erzeugung von einer oder mehreren Abfragen unter Verwendung der Codeausführungslogik 160 auf der Basis von einem oder mehreren Objekten, die im Analyseschritt 625 identifiziert werden. In einigen Ausführungsbeispielen ist eine innerhalb des empfangenen Befehls identifizierte Abbildung als Suchbegriff in einer der Abfragen enthalten.
  • In einem Abrufschritt 630 wird der kompilierte Code von einem Datensatz 210 der Datenbank 140 unter Verwendung der im Analyseschritt 625 erzeugten einen oder mehreren Abfragen abgerufen. Dieser Abruf wird typischerweise unter Verwendung der Datenbankverwaltungslogik 150 durchgeführt. In einigen Ausführungsbeispielen werden beispielsweise verschiedene Teile des kompilierten Codes eines Computerprogramms aus verschiedenen Mitgliedern von Datensätzen 210 unter Verwendung der im Analyseschritt 625 erzeugten Abfragen abgerufen. Der Analyseschritt 625 und/oder der Abrufschritt 630 können in Reaktion auf das Empfangen einer anfänglichen Anforderung von einem Benutzer durchgeführt werden oder können vor dem Empfangen der Anforderung durchgeführt werden. Wenn sie vor dem Empfangen der Anforderung durchgeführt werden, wird der kompilierte Code gecached zur Ausführung, wenn die Anforderung empfangen wird.
  • In einem Ausführungsschritt 635 wird der kompilierte Code, der im Abrufschritt 630 abgerufen wird, beispielsweise unter Verwendung der Betriebssystemlogik 130 ausgeführt. Diese Ausführung geschieht normalerweise außerhalb der Datenbankverwaltungslogik 150. Die Ausführung kann beispielsweise das Übergeben des kompilierten Codes von der Datenbankverwaltungslogik 150 an die Betriebssystemlogik 130 umfassen, wo er auf der Rechenvorrichtung 110 ausgeführt wird.
  • 7 stellt ein Verfahren zum Analysieren eines empfangenen Befehls gemäß verschiedenen Ausführungsbeispielen der Erfindung dar. Dieser Prozess wird typischerweise unter Verwendung der Befehlsinterpretationslogik 190 durchgeführt.
  • In einem Objektleseschritt 710 wird ein erstes Objekt innerhalb eines empfangenen Befehls gelesen. In verschiedenen Ausführungsbeispielen wird der Befehl von rechts nach links oder von links nach rechts gelesen. Objekte innerhalb des Befehls können durch ein ”/”, ”\”, ”.”, ”;” oder ein anderes geeignetes Zeichen getrennt sein.
  • In einem Identifikationsschritt 715 wird das im Objektleseschritt 710 gelesene Objekt als Wert, vordefiniertes Präfix und/oder Abbildung identifiziert. Vordefinierte Präfixe werden durch Vergleichen des gelesenen Objekts mit einem Satz von vordefinierten Präfixen, die im Rechensystem 100 gespeichert sind, identifiziert. Diese Speicherung geschieht normalerweise vor dem Empfang des Befehls. In einigen Ausführungsbeispielen wird das gelesene Objekt per Vorgabe als Abbildung identifiziert, wenn es nicht entweder als Wertobjekt oder als vordefiniertes Präfix identifiziert wird. Wenn ein vordefiniertes Präfix bereits identifiziert wurde (beispielsweise in einer vorherigen Umsetzung des Identifikationsschritts 715), dann kann der Identifikationsschritt 715 auf dieses vordefinierte Präfix reagieren. Wenn beispielsweise das vordefinierte Präfix ein nächstes Objekt als Wertobjekt charakterisiert und das gelesene Objekt das nächste Objekt ist, dann wird das Objekt als Wertobjekt identifiziert.
  • In einem optionalen Syntaxprüfschritt 720 wird die Syntax des gelesenen Objekts geprüft. Wenn beispielsweise das Objekt als Zeichen oder Gleitkommawert identifiziert wird, wird das Objekt darauf geprüft, ob es eine Syntax aufweist, die jeweils diesen Typen entspricht. Der Syntaxprüfschritt 720 wird wahlweise zu anderen Zeitpunkten während des in 7 dargestellten Verfahrens durchgeführt. Der Syntaxprüfschritt 720 kann auf einer individuellen Basis auf Objekte oder grammatische Phrasen innerhalb des empfangenen Befehls angewendet werden. An sich kann der Syntaxprüfschritt 720 wiederholt werden, nachdem weitere Objekte aus dem Befehl gelesen werden.
  • In einem Schritt 725 zum Lesen des nächsten Objekts wird ein nächstes Objekt innerhalb des empfangenen Befehls gelesen. Typischerweise ist dieses nächste Objekt eines, das zum vorher gelesenen Objekt im Befehl benachbart ist.
  • In einem Schritt 730 zum Verarbeiten des nächsten Objekts wird das im Schritt 725 zum Lesen des nächsten Objekts gelesene Objekt unter Verwendung der Befehlsinterpretationslogik 190 verarbeitet. Diese Verarbeitung umfasst die Identifikation des Objekts und kann von einem vorher gelesenen vorbestimmten Präfix abhängen. Wenn beispielsweise das im Objektidentifikationsschritt 715 identifizierte Objekt ein vordefiniertes Präfix ist, das das nächste Objekt als Zeichen charakterisiert, dann wird im Schritt 730 zum Verarbeiten des nächsten Objekts das im Schritt 725 zum Lesen des nächsten Objekts gelesene Objekt automatisch als Zeichen identifiziert. Der Schritt 725 zum Lesen des nächsten Objekts und der Schritt 730 zum Verarbeiten des nächsten Objekts werden typischerweise wiederholt, bis der ganze empfangene Befehl verarbeitet ist.
  • In einem optionalen Abbildungsverwendungsschritt 735 wird ein in einem Identifikationsschritt 715 oder Schritt 730 zum Verarbeiten des nächsten Objekts identifiziertes Abbildungsobjekt an die Codeausführungslogik 160 zur Verwendung beim Erzeugen einer Datenbankabfrage übergegeben. Wie anderswo hierin erörtert, kann diese Abbildung verwendet werden, um einen ausführbaren Code wie z. B. einen kompilierten Code aus der Datenbank 140 auszuwählen. Das Abbildungsobjekt kann an die Codeausführungslogik 160 in Kombination mit anderen im Befehl identifizierten Objekten übergeben werden. Das Abbildungsobjekt kann beispielsweise mit einer Textzeichenkette, einer ganzen Zahl oder irgendeinem anderen Typ von Objekt kombiniert werden und die Kombination kann von der Codeausführungslogik 160 verwendet werden, um die Datenbankabfrage zu erzeugen. Der Abbildungsverwendungsschritt 735 kann zu anderen Zeitpunkten innerhalb des durch 7 dargestellten Verfahrens stattfinden. Der Abbildungsverwendungsschritt 735 kann beispielsweise durchgeführt werden, sobald ein Abbildungsobjekt identifiziert wird, und dann wiederholt werden, wenn ein zweites Abbildungsobjekt identifiziert wird. Im Abbildungsverwendungsschritt 735 kann der durch ein Abbildungsobjekt identifizierte, kompilierte Code ausgeführt werden oder kann als Parameter an ein anderes Stuck des kompilierten Codes übergeben werden.
  • 8 stellt ein Verfahren zum Speichern von mehreren Instanzen eines Rechencodes gemäß verschiedenen Ausführungsbeispielen der Erfindung dar. In diesem Verfahren werden Teile eines Computerprogramms in separaten Datensätzen der Datenbank 140 gespeichert, einer oder mehrere dieser Teile werden modifiziert, um modifizierte Instanzen der Teile zu erzeugen, die Codeverwaltungslogik 170 wird dann verwendet, um zwischen den modifizierten oder ursprünglichen Instanzen zu einem Zeitpunkt der Ausführung und/oder Bereitstellung des Computerprogramms auszuwählen.
  • In einem Codeempfangsschritt 810 wird ein Rechencode durch das Rechensystem 100 empfangen. Der empfangene Code kann einen Quellcode, einen ausführbaren Code, Konfigurationsdaten und/oder andere Informationen umfassen. In einigen Ausführungsbeispielen wird der Code als einzelne Datei, beispielsweise über das Netzwerk 120, empfangen. Alternativ kann der Code stückweise empfangen werden, beispielsweise wenn er von einem Benutzer eingetippt wird. In einigen Ausführungsbeispielen wird der Code über eine Überarbeitungsschnittstelle empfangen, die in einem Browser dargestellt wird. Der Codeempfangsschritt 810 kann über die Zeit stattfinden.
  • In einem Codeunterteilungsschritt 820 wird der im Codeempfangsschritt 810 empfangene Code in separate Teile zur Speicherung in Datensätzen 210 unterteilt, wobei jeder Teil in einem anderen Mitglied der Datensätze 210 gespeichert wird. Dieser Schritt kann das Analysieren des Codes umfassen, um die Unterteilungspunkte zu bestimmen. Wie anderswo hierin erörtert, kann der Code unter Verwendung einer Vielfalt von Ansätzen unterteilt werden, einschließlich, jedoch nicht begrenzt auf die Unterteilung des Codes nach Funktionen (Prozeduren), nach Klassendefinition, nach Anweisungshierarchie, per Zeile, nach Programmablaufverzweigung oder dergleichen. In einigen Ausführungsbeispielen wird beispielsweise jede Funktion des Computerprogramms in einem separaten Mitglied der Datensätze 210 gespeichert. In einigen Ausführungsbeispielen wird die höchste Anweisungshierarchie innerhalb einer Funktion verwendet, um Teile des empfangenen Codes zu unterteilen. Beispielsweise kann die Verwendung von WHILE-Anweisungen, CASE-Anweisungen oder IF-Anweisungen eine hierarchische Struktur erzeugen, in der Unteranweisungen innerhalb einer dieser Anweisungen auf einer niedrigeren Hierarchieebene liegen. Der empfangene Code kann auf der hierarchischen Ebene, einschließlich der WHILE-, CASE- und IF-Anweisungen, unterteilt werden.
  • In einigen Ausführungsbeispielen steht die Unterteilung des Codes im Codeunterteilungsschritt 820 unter der Steuerung eines Benutzers. Ein Benutzer kann beispielsweise durch einen Editor oder eine ähnliche Schnittstelle festlegen, wie der Code unterteilt werden soll. Diese Festlegung kann durch die Anordnung von Markierungen innerhalb des Quellcodes durch einen Benutzer erleichtert werden. Die Codeverwaltungslogik 180 ist wahlweise dazu konfiguriert, diese Markierungen zu verwenden, um Stellen zu identifizieren, an denen der Quellcode unterteilt werden kann. Ferner ist die Codekompilierungslogik 170 wahlweise dazu konfiguriert, diese Markierungen zu verwenden, während der Quellcode kompiliert wird, um den resultierenden kompilierten Code zu unterteilen. Die Markierungen werden wahlweise innerhalb eines Texts angeordnet, der ansonsten innerhalb der Programmiersprache des Quellcodes als Kommentar interpretiert werden würde.
  • In einigen Ausführungsbeispielen wird der empfangene Code in Abhängigkeit davon unterteilt, wie er empfangen wird. Wenn der Code beispielsweise als Teile stückweise empfangen wird, kann er gemäß diesen Teilen unterteilt werden.
  • Der Quellcode und der kompilierte Code, der aus dem Quellcode erzeugt wird, können unter Verwendung derselben Unterteilungen gespeichert werden oder nicht. Der Quellcode kann beispielsweise unterteilt werden und der kompilierte Code kann an denselben Punkten wie der Quellcode unterteilt werden. Alternativ kann die Quelle nicht unterteilt werden, z. B. kann sie als einzelne Datei gespeichert werden, und der kompilierte Code, der sich aus der Kompilierung des Quellcodes ergibt, kann unterteilt werden. In einigen Ausführungsbeispielen wird der Quellcode schließlich unterteilt, aber der kompilierte Code wird anders unterteilt. Dies kann beispielsweise stattfinden, wenn die Unterteilung vom Programmablauf abhängt, der während des Kompilierungsprozesses bestimmt wird.
  • In einem Codespeicherschritt 830 wird der im Codeempfangsschritt 810 empfangene und im Codeunterteilungsschritt 820 unterteilte Code innerhalb der Datenbank 140 gespeichert. Jeder unterteilte Teil des Codes wird in einem separaten Mitglied der Datensätzen 210 gespeichert. Typischerweise wird die Speicherung unter Verwendung der Datenbankverwaltungslogik 150 durchgeführt und kann über das Netzwerk 120 stattfinden. Der Codeempfangsschritt 810, der Codeunterteilungsschritt 820 und der Codespeicherschritt 830 werden wahlweise mehr als einmal durchgeführt, um mehrere Teile eines Computerprogramms zu verarbeiten.
  • In einem Codemodifikationsschritt 840 wird eine modifizierte Instanz von einem oder mehreren Teilen des im Codespeicherschritt 830 gespeicherten Codes erzeugt. Diese Modifikation kann das Überarbeiten des Quellcodes, das Austauschen oder erneute Kompilieren des kompilierten Codes und/oder dergleichen umfassen. In einigen Ausführungsbeispielen wird beispielsweise der im Codespeicherschritt 830 gespeicherte Quellcode unter Verwendung einer Abfrage aus der Datenbank 140 abgerufen. Der Quellcode wird dann durch einen Benutzer, wahlweise über eine Browserschnittstelle, überarbeitet. In einigen Ausführungsbeispielen umfasst der Codemodifikationsschritt 840 das Modifizieren des kompilierten Codes. Der Quellcode kann beispielsweise modifiziert werden und dann erneut kompiliert werden, um einen modifizierten kompilierten Code zu erzeugen. Derselbe Quellcode kann auf eine andere Weise kompiliert werden, z. B. mit anderen Kompilierereinstellungen, um einen modifizierten kompilierten Code zu erzeugen.
  • In einem optionalen Codekompilierungsschritt 850 wird der im Codemodifikationsschritt 840 modifizierte Quellcode unter Verwendung der Codekompilierungslogik 170 kompiliert. Der Codekompilierungsschritt 850 ist unnötig, wenn der modifizierte Code bereits in einer kompilierten Form vorliegt oder wenn eine kompilierte Form des Codes nicht erforderlich ist. In einem Schritt 860 zum Speichern des modifizierten Codes wird der im Codemodifikationsschritt 840 erzeugte und wahlweise im Codekompilierungsschritt 850 kompilierte modifizierte Code in einem oder mehreren der Datensätze 210 gespeichert. Der modifizierte Code wird wahlweise als separate Instanz des ursprünglichen Codes gespeichert. Der Schritt 860 zum Speichern der modifizierten Codes kann die Festlegung eines Werts in einem Feld der Datensätze 210 umfassen, um verschiedene Instanzen des Codes zu unterscheiden. Die Speicherung wird typischerweise unter Verwendung der Datenbankverwaltungslogik 150 durchgeführt.
  • In einem Instanzauswahlschritt 870 wird eine Auswahl unter den verschiedenen Instanzen des Codes, z. B. der ursprünglichen Instanz und der im Codemodifikationsschritt 840 erzeugten Instanz, durchgeführt. Diese Auswahl kann in Reaktion auf eine Anforderung zum Zugreifen auf und/oder Ausführen des Codes stattfinden. Wahlweise wird die Auswahl unter Verwendung einer Datenbankabfrage und der Datenbankverwaltungslogik 150 durchgeführt. Die ausgewählte Instanz wird wahlweise unter Verwendung der Betriebssystemlogik 130 ausgeführt.
  • Verschiedene Ausführungsbeispiele sind hierin speziell dargestellt und/oder beschrieben. Es ist jedoch zu erkennen, dass Modifikationen und Veränderungen von den obigen Lehren abgedeckt sind und innerhalb des Schutzbereichs der beigefügten Ansprüche liegen, ohne vom Gedanken und beabsichtigten Schutzbereich derselben abzuweichen. Beispielsweise kann die verschiedene hierin erörterte Logik eine Hardware, Firmware und/oder Software aufweisen, die auf computerlesbaren Medien gespeichert ist. Verschiedene Teile eines Computerprogramms werden wahlweise innerhalb verschiedener Tabellen der Datenbank 140 gespeichert. Wenn beispielsweise ein Computerprogramm mehrere Quelldateien und/oder Objektdateien umfasst, kann jede von diesen in einer separaten Tabelle gespeichert werden. Der hierin erörterte kompilierte Code ist wahlweise zur Ausführung innerhalb eines Browsers konfiguriert. Die hierin erörterten verschiedenen Ausführungsbeispiele können auf Web- oder Nicht-Web-Anwendungen angewendet werden. Der hier erörterte kompilierte Code kann auf einer virtuellen Maschine ausgeführt werden. Ebenso können verschiedene Komponenten des Rechensystems 100 virtuelle Maschinen umfassen. Objekte innerhalb eines empfangenen Befehls können verwendet werden, um andere Informationen als den kompilierten Code aus der Datenbank 140 abzurufen, beispielsweise Formatvorlagen, statische Daten oder dergleichen. Der hierin erörterte Begriff vordefiniertes Präfix kann alternativ ein Suffix sein. Verschiedene Ausführungsbeispiele der Erfindung umfassen eine graphische Benutzerschnittstelle, die dazu konfiguriert ist, Abbildungsobjekte, Präfixe oder dergleichen zu spezifizieren. Eine graphische Benutzerschnittstelle kann beispielsweise zum Auswählen eines auszuführenden Zielcodes gemäß einer gegebenen Abbildung verwendet werden.
  • Die hierin erörterten Ausführungsbeispiele erläutern die vorliegende Erfindung. Da diese Ausführungsbeispiele der vorliegenden Erfindung mit Bezug auf Erläuterungen beschrieben sind, können verschiedene Modifikationen oder Anpassungen der beschriebenen Verfahren und/oder spezifischen Strukturen für den Fachmann auf dem Gebiet ersichtlich werden. Alle solchen Modifikationen, Anpassungen oder Veränderungen, die auf den Lehren der vorliegenden Erfindung beruhen und durch die diese Lehren das Fachgebiet vorangebracht wurden, werden als innerhalb des Gedankens und Schutzbereichs der vorliegenden Erfindung betrachtet. Daher sollten diese Beschreibungen und Zeichnungen nicht in einer begrenzenden Hinsicht betrachtet werden, da es selbstverständlich ist, dass die vorliegende Erfindung keineswegs nur auf die erläuterten Ausführungsbeispiele begrenzt ist.
  • Zusammenfassung:
  • DATENSATZ BASIERTE CODESTRUKTUR
  • Der kompilierte Code eines Computerprogramms wird in mehreren Stücken innerhalb einer Datenbank gespeichert. Jedes Stück wird wahlweise innerhalb eines separaten Datensatzes gespeichert. Die Ausführung des Computerprogramms umfasst die Verwendung von Datenbankabfragen, um Stücke des kompilierten Codes zur Ausführung abzurufen. Die Datenbank und die zugehörige Datenbankverwaltungslogik werden verwendet, um zahlreiche Vorteile bei der Ausführung und Verwaltung des Computerprogramms vorzusehen. In einigen Ausführungsbeispielen werden beispielsweise Datenbankabfragen verwendet, um zu helfen, die Programmablauflogik zu erleichtern. In einem anderen Beispiel basieren Datenbankabfragen auf einer Befehlszeile oder einem Universal Resource Locator. Diese Abfragen können verwendet werden, um die Funktionalität eines Computerprogramms in Reaktion auf die Befehlszeile oder den Universal Resource Locator auszuwählen.

Claims (93)

  1. Ein System, das aufweist: eine Rechenvorrichtung; eine Betriebssystemlogik, die so konfiguriert ist, dass sie auf der Rechenvorrichtung läuft, und auf einem computerlesbaren Medium der Rechenvorrichtung gespeichert ist; eine Datenbank, die auf einem computerlesbaren Medium gespeichert ist und Datensätze umfasst, die dazu konfiguriert sind, den kompilierten Code eines Computerprogramms zu speichern; eine Datenbankverwaltungslogik, die zum Zugreifen auf die Datenbank konfiguriert ist; und eine Codeausführungslogik, die dazu konfiguriert ist, den kompilierten Code aus den Datensätzen durch Ausführen von einer oder mehreren Abfragen auf der Datenbankverwaltungslogik abzurufen und den abgerufenen Code auf der Betriebssystemlogik auszuführen.
  2. Ein System, das aufweist: eine Rechenvorrichtung; eine Datenbank, die auf einem computerlesbaren Medium gespeichert ist und Datensätze umfasst, die dazu konfiguriert sind, den kompilierten Code eines Computerprogramms zu speichern; eine Datenbankverwaltungslogik, die dazu konfiguriert ist, auf die Datenbank zuzugreifen; eine Codeausführungslogik, die dazu konfiguriert ist, den kompilierten Code aus den Datensätzen durch Ausführen von einer oder mehreren Abfragen auf der Datenbankverwaltungslogik abzurufen und den abgerufenen Code auf der Betriebssystemlogik auszuführen; und eine Befehlsinterpretationslogik, die auf einem computerlesbaren Medium gespeichert ist und dazu konfiguriert ist, die eine oder die mehreren Abfragen durch Interpretieren eines Befehls zu erzeugen.
  3. Ein System, das aufweist: eine Rechenvorrichtung; eine Betriebssystemlogik, die dazu konfiguriert ist, Computerprogramme auf der Rechenvorrichtung auszuführen; eine Datenbank, die auf einem computerlesbaren Medium gespeichert ist und einen ersten Datensatz, einen zweiten Datensatz und einen dritten Datensatz umfasst; eine Codeverwaltungslogik, die dazu konfiguriert ist, einen ersten kompilierten Code im ersten Datensatz zu speichern, einen zweiten kompilierten Code im zweiten Datensatz zu speichern und einen dritten Datensatz im dritten Datensatz zu speichern, wobei der erste kompilierte Code und der zweite kompilierte Code verschiedene Teile eines Computerprogramms aufweisen, der zweite kompilierte Code und der dritte kompilierte Code verschiedene Instanzen eines Teils des Computerprogramms aufweisen; eine Datenbankverwaltungslogik, die dazu konfiguriert ist, auf die Datenbank zuzugreifen; und eine Codeausführungslogik, die dazu konfiguriert ist, eine der verschiedenen Instanzen des kompilierten Codes auszuwählen und die ausgewählte Instanz des kompilierten Codes aus den Datensätzen durch Ausführen von einer oder mehreren Abfragen an die Datenbank unter Verwendung der Datenbankverwaltungslogik abzurufen und die abgerufene Instanz auf der Betriebssystemlogik auszuführen.
  4. Ein System, das aufweist: eine Rechenvorrichtung, die dazu konfiguriert ist, ein Computerprogramm unter Verwendung einer Betriebssystemlogik auszuführen; eine Datenbank, die auf einem computerlesbaren Medium gespeichert ist und Datensätze umfasst, die dazu konfiguriert sind, den kompilierten Code des Computerprogramms als separate Teile zu speichern; eine Datenbankverwaltungslogik, die zum Zugreifen auf die Datenbank konfiguriert ist; und eine Zeitplanlogik außerhalb des Computerprogramms, die dazu konfiguriert ist, die Ausführung einer Teilmenge der separaten Teile auf der Rechenvorrichtung gemäß einem Zeitplan anzufordern.
  5. Das System nach Anspruch 1–3 oder 4, wobei zumindest ein Teil des kompilierten Codes als Funktion gespeichert ist.
  6. Das System nach Anspruch 1–4 oder 5, wobei zumindest ein Teil des kompilierten Codes dazu konfiguriert ist, eine Vorrichtung außerhalb der Datenbank zu steuern.
  7. Das System nach Anspruch 1–5 oder 6, wobei der kompilierte Code einen kompilierten Pythoncode oder einen kompilierten Code der Microsoft.NET Common Intermediate Language umfasst.
  8. Das System nach Anspruch 1–6 oder 7, wobei die Datenbank ferner Datensätze umfasst, die dazu konfiguriert sind, einen nicht-kompilierten Code zu speichern.
  9. Das System nach Anspruch 1–7 oder 8, wobei die Datenbank ferner Datensätze umfasst, die dazu konfiguriert sind, den Quellcode des kompilierten Codes zu speichern.
  10. Das System nach Anspruch 1–8 oder 9, wobei die Datenbank ferner Datensätze umfasst, die dazu konfiguriert sind, eine Hypertext-Dokumentenauszeichnungssprache, ein Skript oder eine erweiterte Dokumentenauszeichnungssprache zu speichern.
  11. Das System nach Anspruch 1–9 oder 10, wobei die Codeausführungslogik ferner dazu konfiguriert ist, ein Computerprogramm durch Durchführen einer Vielzahl von Abfragen an die Datenbank auszuführen und eine Vielzahl von kompilierten Codes, die als Ergebnis dieser Abfragen zurückgegeben werden, auszuführen.
  12. Das System nach Anspruch 1–10 oder 11, wobei ein Programmablauf des Computerprogramms von den Abfragen abhängt.
  13. Das System nach Anspruch 1–11 oder 12, wobei die Codeausführungslogik ferner dazu konfiguriert ist, die Abfragen zu bestimmen, wobei die Abfragen auf einer Logik eines bedingten Programmablaufs basieren.
  14. Das System nach Anspruch 1–12 oder 13, die ferner eine Codeverwaltungslogik umfasst, die zum Modifizieren des kompilierten Codes konfiguriert ist.
  15. Das System nach Anspruch 1–13 oder 14, wobei die Codeverwaltungslogik dazu konfiguriert ist, abwechselnd in einem Erzeugungsmodus und einem Entwicklungsmodus zu arbeiten, wobei eine größere Menge des kompilierten Codes im Erzeugungsmodus relativ zum Entwicklungsmodus nach der Modifikation des Codes erneut kompiliert wird.
  16. Das System nach Anspruch 1–14 oder 15, wobei die Codeverwaltungslogik so konfiguriert ist, dass über einen Browser auf sie zugegriffen wird.
  17. Das System nach Anspruch 1–15 oder 16, wobei die Codeverwaltungslogik dazu konfiguriert ist, den Quellcode innerhalb der Datenbank auf einem Niveau einzelner Datensätze zu überarbeiten.
  18. Das System nach Anspruch 1–16 oder 17, wobei die Codeverwaltungslogik dazu konfiguriert ist, den Code vor der Speicherung in der Datenbank automatisch zu kompilieren.
  19. Das System nach Anspruch 1–17 oder 18, wobei die Codeverwaltungslogik dazu konfiguriert ist, den Code auf einer datensatzweisen Basis zu überarbeiten und erneut zu kompilieren.
  20. Das System nach Anspruch 1–18 oder 19, wobei die Codeverwaltungslogik dazu konfiguriert ist, eine Anwendung für die Rechenvorrichtung bereitzustellen durch Bereitzustellen der Datenbank zur Rechenvorrichtung über ein Netzwerk.
  21. Das System nach Anspruch 1–19 oder 20, wobei die Codeverwaltungslogik dazu konfiguriert ist, die Datensätze auf der Basis der Programmablauflogik im Quellcode zu indizieren.
  22. Das System nach Anspruch 1–20 oder 21, wobei die Codeverwaltungslogik vom Computersystem entfernt ist.
  23. Das System nach Anspruch 1–21 oder 22, das ferner eine Codekompilierungslogik umfasst, die dazu konfiguriert ist, den kompilierten Code aus dem Quellcode zu erzeugen.
  24. Das System nach Anspruch 1–22 oder 23, wobei die Codeausführungslogik ferner dazu konfiguriert ist, eine Datenbankabfrage auszuführen, um festzustellen, ob ein Teil des kompilierten Codes in der Datenbank verfügbar ist, und die Codekompilierungslogik zu verwenden, um den Teil des kompilierten Codes zu erzeugen, wenn der Teil des kompilierten Codes in der Datenbank nicht verfügbar ist.
  25. Das System nach Anspruch 1–23 oder 24, wobei die Codeausführungslogik ferner dazu konfiguriert ist, eine Kopie des erzeugten Teils des kompilierten Codes in der Datenbank zu cachen.
  26. Das System nach Anspruch 1–24 oder 25, wobei der Befehl der gesamte oder ein Teil eines Universal Resource Locator ist.
  27. Das System nach Anspruch 1–25 oder 26, wobei der Befehl der gesamte oder ein Teil einer Befehlszeile ist.
  28. Das System nach Anspruch 1–26 oder 27, wobei die Befehlsinterpretationslogik dazu konfiguriert ist, die eine oder die mehreren Abfragen zu erzeugen, um eine spezifische Funktion aus der Datenbank abzurufen.
  29. Das System nach Anspruch 1–27 oder 28, wobei der kompilierte Code einen Perl-, PHP-, Ruby- oder kompilierten Java-Code umfasst.
  30. Das System nach Anspruch 1–28 oder 29, wobei die Befehlsinterpretationslogik dazu konfiguriert ist, die eine oder die mehreren Abfragen zu erzeugen, um eine spezifische Hypertext-Dokumentenauszeichnungssprache, ein Skript oder eine erweiterte Dokumentenauszeichnungssprache aus der Datenbank abzurufen.
  31. Das System nach Anspruch 1–29 oder 30, wobei die Codeausführungslogik ferner dazu konfiguriert ist, ein Computerprogramm auszuführen durch Durchführen einer Vielzahl von Abfragen an die Datenbank auszuführen und eine Vielzahl von kompilierten Codes, die als Ergebnis der durch die Befehlsinterpretationslogik erzeugten Abfragen zurückgegeben werden.
  32. Das System nach Anspruch 1–30 oder 31, wobei ein Programmablauf des Computerprogramms von der einen oder den mehreren Abfragen, die durch die Befehlsinterpretationslogik erzeugt werden, abhängt.
  33. Das System nach Anspruch 1–31 oder 32, das ferner eine Codeverwaltungslogik umfasst, die zum Abbilden einer Vielzahl von Abbildungen auf eine Vielzahl von Datensätzen innerhalb der Datenbank konfiguriert ist.
  34. Das System nach Anspruch 1–32 oder 33, wobei die Befehlsinterpretationslogik dazu konfiguriert ist, einen über einen Browser empfangenen Befehl zu interpretieren.
  35. Das System nach Anspruch 1–33 oder 34, wobei die Befehlsinterpretationslogik ferner dazu konfiguriert ist, eine Version des kompilierten Codes zur Ausführung auf der Basis des Befehls auszuwählen.
  36. Das System nach Anspruch 1–34 oder 35, wobei die eine oder die mehreren Abfragen, die durch die Befehlsinterpretationslogik erzeugt werden, dazu konfiguriert sind, sowohl den kompilierten Code als auch nicht-kompilierte Informationen aus Datensätzen der Datenbank abzurufen.
  37. Das System nach Anspruch 1–35 oder 36, wobei die Befehlsinterpretationslogik ferner dazu konfiguriert ist, eine grammatische Struktur des Befehls zu interpretieren.
  38. Das System nach Anspruch 1–36 oder 37, wobei die grammatische Struktur ein vordefiniertes Präfix und eine Abbildung auf einen Datensatz der Datenbank, in dem der kompilierte Code gespeichert ist, umfasst.
  39. Das System nach Anspruch 1–37 oder 38, wobei das vordefinierte Präfix und die Abbildung in einer hierarchischen Beziehung liegen.
  40. Das System nach Anspruch 1–38 oder 39, wobei die grammatische Struktur dazu konfiguriert ist, den in der Datenbank gespeicherten kompilierten Code an einen Parameter zum ausführbaren Code zu übergeben.
  41. Das System nach Anspruch 1–39 oder 40, wobei ein Teil der grammatischen Struktur einen regulären Ausdruck umfasst und ein Teil der grammatischen Struktur einen exakten Ausdruck umfasst.
  42. Das System nach Anspruch 1–40 oder 41, wobei ein Teil der grammatischen Struktur einen regulären Ausdruck umfasst und die Befehlsinterpretationslogik dazu konfiguriert ist, mehr als ein Objekt aus dem regulären Ausdruck zu extrahieren.
  43. Das System nach Anspruch 1–41 oder 42, wobei eines des mehr als einen Objekts eine Abbildung auf einen Datensatz innerhalb der Datenbank ist.
  44. Das System nach Anspruch 1–42 oder 43, wobei die Zeitplanlogik auf einer von der Rechenvorrichtung separaten Vorrichtung ausgeführt wird.
  45. Das System nach Anspruch 1–43 oder 44, wobei die Zeitplanlogik dazu konfiguriert ist, die Ausführung auf einer funktionsweisen Basis anzufordern.
  46. Das System nach Anspruch 1–44 oder 45, wobei die verschiedenen Instanzen des kompilierten Codes verschiedene Versionen des kompilierten Codes aufweisen.
  47. Das System nach Anspruch 1–45 oder 46, wobei die verschiedenen Instanzen einen kompilierten Code mit einer unterschiedlichen Funktionalität aufweisen.
  48. Das System nach Anspruch 1–46 oder 47, wobei die verschiedenen Instanzen eine Entwicklungsversion und eine Erzeugungsversion des Teils des kompilierten Codes aufweisen.
  49. Das System nach Anspruch 1–47 oder 48, wobei die verschiedenen Instanzen verschiedenen Sicherheitsniveaus zugeordnet sind.
  50. Das System nach Anspruch 1–48 oder 49, wobei die verschiedenen Instanzen verschiedenen menschlichen Sprachen zugeordnet sind.
  51. Das System nach Anspruch 1–49 oder 50, wobei die Datenbank ferner Datensätze umfasst, die dazu konfiguriert sind, verschiedene Instanzen von Anwendungskonfigurationsdaten zu speichern.
  52. Das System nach Anspruch 1–50 oder 51, wobei die Codeausführungslogik ferner konfiguriert ist, damit ein Benutzer unter verschiedenen Instanzen eines kompilierten Codes auf einer Funktionsebene auswählt.
  53. Das System nach Anspruch 1–51 oder 52, wobei die Codeausführungslogik konfiguriert ist, damit der Benutzer unter den verschiedenen Instanzen eines kompilierten Codes unter Verwendung einer Befehlszeile oder eines Universal Resource Locator auswählt.
  54. Das System nach Anspruch 1–52 oder 53, wobei die Codeausführungslogik dazu konfiguriert ist, einen Instanzsatz auf der Basis eines Präfix oder einer Abbildung abzurufen.
  55. Das System nach Anspruch 1–53 oder 54, wobei der ausgeführte abgerufene Code eine zu einem ersten Datum kompilierte, erste Funktion des Computerprogramms und eine zu einem zweiten Datum kompilierte, zweite Funktion des Computerprogramms umfasst, wobei das erste Datum vom zweiten Datum verschieden ist.
  56. Ein Verfahren, das aufweist: Empfangen einer Anforderung zum Ausführen eines Computerprogramms; Ausführen einer ersten Abfrage, um einen ersten Datenbankdatensatz einer Datenbank zu identifizieren, in dem eine Teilmenge des kompilierten Codes des Computerprogramms gespeichert ist; Abrufen eines ersten Codes aus dem identifizierten ersten Datenbankdatensatz als Ergebnis der ersten Abfrage; Bereitstellen des abgerufenen ersten Codes für ein Betriebssystem zur Ausführung; Erzeugen einer zweiten Abfrage auf der Basis eines Ergebnisses der Ausführung des abgerufenen ersten Codes; Verwenden der erzeugten zweiten Abfrage, um einen zweiten Datenbankdatensatz der Datenbank zu identifizieren, in dem der kompilierte Code des Computerprogramms gespeichert ist; Abrufen des kompilierten Codes aus dem zweiten Datenbankdatensatz als Ergebnis der zweiten Abfrage; und Bereitstellen des abgerufenen kompilierten Codes für das Betriebssystem zur Ausführung.
  57. Ein Verfahren, das aufweist: Empfangen eines Quellcodes eines Computerprogramms, wobei der Quellcode eine Vielzahl von Funktionen umfasst; Kompilieren der Vielzahl von Funktionen, wobei die kompilierten Funktionen zur Ausführung auf einem Betriebssystem konfiguriert sind; Speichern jeder kompilierten Funktion der Vielzahl von Funktionen in einem separaten Datenbankdatensatz; und Indizieren eines jedem der separaten Datenbankdatensätze unter Verwendung eines Identifikators der im Datenbankdatensatz gespeicherten kompilierten Funktion, wobei die Identifikatoren dazu konfiguriert sind, Mitglieder der Vielzahl von kompilierten Funktionen gemäß einer Programmablauflogik auszuwählen.
  58. Ein Verfahren, das aufweist: Empfangen eines Befehls, der eine Befehlszeile oder einen Universal Resource Locator aufweist; Analysieren des Befehls, um eine Vielzahl von Datenbankabfragen zu erzeugen; Abrufen eines kompilierten Codes aus einer Vielzahl von Datensätzen innerhalb einer Datenbank unter Verwendung der Vielzahl von Datenbankabfragen, wobei verschiedene Teile des kompilierten Codes in verschiedenen Mitgliedern der Datensätze gespeichert sind; und Ausführen des abgerufenen kompilierten Codes außerhalb der Datenbank in Reaktion auf das Empfangen des Befehls.
  59. Ein Verfahren, das aufweist: Lesen eines ersten Objekts innerhalb einer empfangenen Befehlszeile oder eines empfangenen Universal Resource Locator; Identifizieren des ersten Objekts als vordefiniertes Präfix, das dazu konfiguriert ist, Datentypen von einem oder mehreren anderen Objekten innerhalb der empfangenen Befehlszeile oder des empfangenen Universal Resource Locator zu charakterisieren; Lesen eines zweiten Objekts mit der empfangenen Befehlszeile oder dem empfangenen Universal Resource Locator; und Identifizieren des zweiten Objekts als Abbildung auf einen Datensatz innerhalb einer Datenbank, wobei der Datensatz einen kompilierten Code umfasst, der so konfiguriert ist, dass er in Reaktion auf das Empfangen der empfangenen Befehlszeile oder des empfangenen Universal Resource Locator ausgeführt wird.
  60. Das Verfahren nach Anspruch 56–58 oder 59, wobei die Anforderung über ein Rechennetzwerk empfangen wird.
  61. Das Verfahren nach Anspruch 56–59 oder 60, wobei die zweite Abfrage auf einer Logik eines bedingten Programmablaufs des Computerprogramms basiert.
  62. Das Verfahren nach Anspruch 56–60 oder 61, wobei der zweite Code aus einer kompilierten Funktion besteht.
  63. Das Verfahren nach Anspruch 56–61 oder 62, das ferner das Feststellen, dass der kompilierte Code in der Datenbank nicht verfügbar ist, das Erzeugen des kompilierten Codes und das Speichern des erzeugten kompilierten Codes in der Datenbank aufweist.
  64. Das Verfahren nach Anspruch 56–62 oder 63, wobei der Quellcode von der ersten Datenbank oder einer zweiten Datenbank empfangen wird.
  65. Das Verfahren nach Anspruch 56–63 oder 64, das ferner das Speichern eines nicht-kompilierten Codes des Computerprogramms in der Datenbank aufweist.
  66. Das Verfahren nach Anspruch 56–64 oder 65, das ferner das Speichern von Konfigurationsdaten des Computerprogramms in der Datenbank aufweist.
  67. Das Verfahren nach Anspruch 56–65 oder 66, das ferner das Bereitstellen des Computerprogramms durch Bereitstellen der Datenbank zu einer Rechenvorrichtung über ein Netzwerk aufweist.
  68. Das Verfahren nach Anspruch 56–66 oder 67, das ferner das Modifizieren des Computerprogramms durch Modifizieren von einem der separaten Datenbankdatensätze aufweist.
  69. Das Verfahren nach Anspruch 56–67 oder 68, wobei das Modifizieren des Computerprogramms das erneute Kompilieren der in dem einen der separaten Datenbankdatensätze gespeicherten Funktion umfasst, aber nicht von anderen Mitgliedern der Vielzahl von Funktionen, die in den Datenbankdatensätzen gespeichert sind.
  70. Das Verfahren nach Anspruch 56–68 oder 69, wobei das Modifizieren des Computerprogramms das Analysieren und Durchführen einer Syntaxprüfung der in dem einen der separaten Datenbanksätze gespeicherten Funktion aufweist.
  71. Das Verfahren nach Anspruch 56–69 oder 70, das ferner das Modifizieren des Computerprogramms unter Verwendung der Datenbankverwaltungslogik aufweist.
  72. Das Verfahren nach Anspruch 56–70 oder 71, das ferner das Durchführen einer Versionssteuerung am Computerprogramm unter Verwendung der Datenbankverwaltungslogik aufweist.
  73. Das Verfahren nach Anspruch 56–71 oder 72, das ferner das Vorsehen einer Zugriffssteuerung auf das Computerprogramm unter Verwendung der Datenbankverwaltungslogik aufweist.
  74. Das Verfahren nach Anspruch 56–72 oder 73, wobei der Befehl über einen Browser empfangen wird.
  75. Das Verfahren nach Anspruch 56–73 oder 74, wobei das Analysieren des Befehls das Identifizieren von Objekten innerhalb des Befehls alternativ als Abbildung, als vordefiniertes Präfix oder als Wert umfasst.
  76. Das Verfahren nach Anspruch 56–74 oder 75, wobei das Analysieren des Befehls das Interpretieren einer grammatischen Struktur des Befehls umfasst.
  77. Das Verfahren nach Anspruch 56–75 oder 76, wobei die grammatische Struktur eine hierarchische Beziehung zwischen einem vordefinierten Präfix und einer Abbildung auf die Datensätze umfasst.
  78. Das Verfahren nach Anspruch 56–76 oder 77, wobei das Analysieren des Befehls das Identifizieren einer Teilmenge des Befehls, der ein regulärer Ausdruck ist, umfasst.
  79. Das Verfahren nach Anspruch 56–77 oder 78, wobei das Analysieren des Befehls das Durchführen einer Syntaxprüfung des Befehls umfasst.
  80. Das Verfahren nach Anspruch 56–78 oder 79, wobei der abgerufene kompilierte Code verschiedene Teile eines Computerprogramms aufweist.
  81. Das Verfahren nach Anspruch 56–79 oder 80, das ferner das Abrufen des nicht-kompilierten Codes aus der Vielzahl von Datensätzen unter Verwendung der Vielzahl von Datenbankabfragen aufweist.
  82. Das Verfahren nach Anspruch 56–80 oder 81, wobei der empfangene Befehl ein Objekt umfasst, das dazu konfiguriert ist, eine Version des in einem Mitglied der Datensätze gespeicherten kompilierten Codes auszuwählen.
  83. Das Verfahren nach Anspruch 56–81 oder 82, wobei der empfangene Befehl ein Objekt umfasst, das dazu konfiguriert ist, den Zugriff auf die verschiedenen Teile des kompilierten Codes zu steuern.
  84. Das Verfahren nach Anspruch 56–82 oder 83, das ferner das Erzeugen einer Abbildung von Identifikatoren auf die verschiedenen Teile des kompilierten Codes, die in den verschiedenen Mitgliedern der Datensätze gespeichert sind, aufweist.
  85. Das Verfahren nach Anspruch 56–83 oder 84, das ferner das Bereitstellen eines Computerprogramms durch Bereitstellen der Datenbank für eine Rechenvorrichtung über ein Netzwerk aufweist.
  86. Das Verfahren nach Anspruch 56–84 oder 85, das ferner die Verwendung des zweiten Objekts aufweist, um eine Datenbankabfrage zu erzeugen, die dazu konfiguriert ist, den kompilierten Code aus dem Datensatz auszuwählen.
  87. Ein computerlesbares Medium, auf dem Folgendes gespeichert ist: eine Logik, die dazu konfiguriert ist, einen Code eines Computerprogramms zu empfangen; eine Logik, die dazu konfiguriert ist, den Code in eine Vielzahl von Teilen zu unterteilen; eine Logik, die dazu konfiguriert ist, die Vielzahl von Teilen jeweils in einem separaten Datensatz einer Datenbank zu speichern; eine Logik, die dazu konfiguriert ist, ein Mitglied der Vielzahl von Teilen zu modifizieren, um eine modifizierte Instanz des Mitgliedes aus einer ursprünglichen Instanz des Mitgliedes zu erzeugen; eine Logik, die dazu konfiguriert ist, die modifizierte Instanz in der Datenbank zu speichern; und eine Logik, die dazu konfiguriert ist, die ursprüngliche Instanz oder die modifizierte Instanz unter Verwendung einer Datenbankabfrage alternativ auszuwählen.
  88. Das computerlesbare Medium nach Anspruch 87, wobei der Code des Computerprogramms einen Quellcode aufweist.
  89. Das computerlesbare Medium nach Anspruch 87 oder 88, das ferner eine Logik aufweist, die dazu konfiguriert ist, jeden der Vielzahl von Teilen zu kompilieren, und eine Logik, die dazu konfiguriert ist, jeden der kompilierten Teile in einem separaten Datensatz der Datenbank zu speichern.
  90. Das computerlesbare Medium nach Anspruch 87, 88 oder 89, wobei der Code des Computerprogramms einen kompilierten Code aufweist.
  91. Das computerlesbare Medium nach Anspruch 87–89 oder 90, das ferner eine Logik aufweist, die dazu konfiguriert ist, ein Protokollierungsmerkmal eines Datenbankverwaltungsprogramms zu verwenden, um die ursprüngliche Instanz und die modifizierte Instanz zu verwalten.
  92. Das computerlesbare Medium nach Anspruch 87–90 oder 91, das ferner eine Logik aufweist, die dazu konfiguriert ist, die ursprüngliche Instanz unter Verwendung eines Wiederholungsmerkmals eines Datenbankverwaltungsprogramms wiederherzustellen.
  93. Das computerlesbare Medium nach Anspruch 87–91 oder 92, das ferner eine Logik aufweist, die dazu konfiguriert ist, den Zugriff auf den Code unter Verwendung eines Datenbankverwaltungsprogramms zu steuern.
DE112009001892T 2008-07-31 2009-06-25 Datensatz basierte Codestruktur Withdrawn DE112009001892T5 (de)

Applications Claiming Priority (7)

Application Number Priority Date Filing Date Title
US12/183,823 US8171045B2 (en) 2008-07-31 2008-07-31 Record based code structure
US12/183,823 2008-07-31
US12/191,711 2008-08-14
US12/191,711 US20100042585A1 (en) 2008-08-14 2008-08-14 Command Interpretation
US12/210,629 US7979450B2 (en) 2008-09-15 2008-09-15 Instance management of code in a database
US12/210,629 2008-09-15
PCT/US2009/048672 WO2010014323A1 (en) 2008-07-31 2009-06-25 Record based code structure

Publications (1)

Publication Number Publication Date
DE112009001892T5 true DE112009001892T5 (de) 2011-07-21

Family

ID=41610667

Family Applications (1)

Application Number Title Priority Date Filing Date
DE112009001892T Withdrawn DE112009001892T5 (de) 2008-07-31 2009-06-25 Datensatz basierte Codestruktur

Country Status (3)

Country Link
CN (1) CN102144230B (de)
DE (1) DE112009001892T5 (de)
WO (1) WO2010014323A1 (de)

Families Citing this family (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9201490B2 (en) 2013-03-15 2015-12-01 International Business Machines Corporation Power management for a computer system
CN103257934B (zh) * 2013-04-12 2016-02-10 广东数字证书认证中心有限公司 数字证书的存储、获取方法和装置
CN103838614B (zh) 2014-02-19 2017-12-22 华为技术有限公司 一种数据处理方法及装置
US10169513B2 (en) * 2016-05-06 2019-01-01 Baidu Usa Llc Method and system for designing FPGA based on hardware requirements defined in source code
CN112463149B (zh) * 2020-12-07 2022-07-19 中国科学院软件研究所 一种面向软件定义卫星的可复用代码库构建方法与装置
US20220198003A1 (en) * 2020-12-22 2022-06-23 Microsoft Technology Licensing, Llc Detecting added functionality in open source package

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US3411139A (en) * 1965-11-26 1968-11-12 Burroughs Corp Modular multi-computing data processing system
CA2284250C (en) * 1989-09-01 2001-12-04 Amdahl Corporation Computer method for implementing a get instruction
US6279151B1 (en) * 1998-01-20 2001-08-21 International Business Machines Corporation Method and apparatus for remote source code inclusion
EP1467289A1 (de) * 2003-04-07 2004-10-13 Deutsche Thomson-Brandt Gmbh Datenbank Modell für ein hierarchisches Datenformat
US20050187980A1 (en) * 2004-02-10 2005-08-25 Microsoft Corporation Systems and methods for hosting the common language runtime in a database management system
US20070038662A1 (en) * 2005-08-04 2007-02-15 Peter Bendel Method and system for managing external routines in a database management system

Also Published As

Publication number Publication date
CN102144230B (zh) 2015-07-01
CN102144230A (zh) 2011-08-03
WO2010014323A1 (en) 2010-02-04

Similar Documents

Publication Publication Date Title
US9684495B2 (en) Command interpretation
DE60126016T2 (de) Serverseitige Kontrollobjekte zur Verarbeitung von kundenseitigen Benutzerschnittstellenelementen
DE60001916T2 (de) Plattformunabhängige speicherabbild analysearchitektur zur programmfehlerbeseitigung
DE10042601B4 (de) Sprache für XML-Server-Seiten
DE10121790B4 (de) Softwarekonfigurationsverfahren zur Verwendung in einem Computersystem
DE69636887T2 (de) System und Verfahren,um verschiedenen Anbietern von Namen zu ermöglichen,sich dynamisch einer Namensföderation anzuschliessen
US10684828B2 (en) Method and apparatus for user interface modification
DE60035745T2 (de) Verfahren zum bei Bedarf Laden und Ausführen einer Netzwerkanwendung
DE60131683T2 (de) Verfahren und system zur verwaltung von mehreren netzwerk-betriebsmitteln
DE69907919T2 (de) Mehrsprachige benutzeroberfläche für ein betriebssystem
DE102013207608B4 (de) Instrumentieren von Software-Anwendungen für die Konfiguration derselben
DE10135445B4 (de) Integriertes Verfahren für das Schaffen einer aktualisierbaren Netzabfrage
DE69838139T2 (de) Verfahren und system zur schaffung von datenbankanwendungssoftware,die minimales programmieren benötigen
DE202014010938U1 (de) Omega-Namen: Namenserzeugung und -ableitung
DE112016003949T5 (de) Webbasierte programmierumgebung für eingebettete geräte
DE102013017085A1 (de) System für eine tiefe Verknüpfung und Suchmaschinenunterstützung für Webseiten, in die eine Drittanwendung und Komponenten integriert sind
US20100042585A1 (en) Command Interpretation
CH699770A1 (de) Erfassung des visuellen Inhalts von Browserfenstern.
DE112009001892T5 (de) Datensatz basierte Codestruktur
DE60102694T2 (de) Modulares computersystem und -verfahren
DE10052313A1 (de) Verfahren und Vorrichtung zur Beschränkung des freien Verweisens (Hyperlinking) auf Webseiten der ursprünglichen Inhaltserzeuger (Content producers) durch Internet-Inhaltsverteiler (Content distributors)
DE10250836A1 (de) System und Verfahren zum Zugreifen auf entfernte Lesezeichenlisten und Verwenden derselben
US20120173575A1 (en) Record Based Code Structure
DE69907714T2 (de) Komponentbasiertes quellcodegeneratorverfahren
DE102004005730A1 (de) Verfahren zur Konfiguration eines Computerprogramms

Legal Events

Date Code Title Description
R082 Change of representative

Representative=s name: KAHLER, KAECK & MOLLEKOPF, DE

R081 Change of applicant/patentee

Owner name: GROUP-A AUTOSPORTS, INC., NORCO, US

Free format text: FORMER OWNER: DUSTIN KURT ADLER, GROUP-A AUTOSPORTS, INC., , US

Effective date: 20130621

Owner name: GROUP-A AUTOSPORTS, INC., NORCO, US

Free format text: FORMER OWNER: DUSTIN KURT ADLER, XSEVO SYSTEMS INC., , US

Effective date: 20130430

Owner name: GROUP-A AUTOSPORTS, INC., NORCO, US

Free format text: FORMER OWNERS: ADLER, DUSTIN KURT, PALO ALTO, CALIF., US; GROUP-A AUTOSPORTS, INC., NORCO, CALIF., US

Effective date: 20130621

Owner name: GROUP-A AUTOSPORTS, INC., NORCO, US

Free format text: FORMER OWNERS: ADLER, DUSTIN KURT, PALO ALTO, CALIF., US; XSEVO SYSTEMS INC., 92860 NORCO, CALIF., US

Effective date: 20130430

Owner name: GROUP-A AUTOSPORTS, INC., US

Free format text: FORMER OWNER: DUSTIN KURT ADLER, GROUP-A AUTOSPORTS, INC., , US

Effective date: 20130621

Owner name: GROUP-A AUTOSPORTS, INC., US

Free format text: FORMER OWNER: DUSTIN KURT ADLER, XSEVO SYSTEMS INC., , US

Effective date: 20130430

R082 Change of representative

Representative=s name: KAHLER KAECK MOLLEKOPF PARTNERSCHAFT VON PATEN, DE

Effective date: 20130430

Representative=s name: KAHLER KAECK MOLLEKOPF PARTNERSCHAFT VON PATEN, DE

Effective date: 20130621

Representative=s name: KAHLER, KAECK & MOLLEKOPF, DE

Effective date: 20130430

Representative=s name: KAHLER, KAECK & MOLLEKOPF, DE

Effective date: 20130621

R012 Request for examination validly filed
R079 Amendment of ipc main class

Free format text: PREVIOUS MAIN CLASS: G06F0017300000

Ipc: G06F0016000000

R079 Amendment of ipc main class

Free format text: PREVIOUS MAIN CLASS: G06F0016000000

Ipc: G06F0008700000

R119 Application deemed withdrawn, or ip right lapsed, due to non-payment of renewal fee