DE102013207608A1

DE102013207608A1 - Instrumentieren von Software-Anwendungen für die Konfiguration derselben

Info

Publication number: DE102013207608A1
Application number: DE102013207608A
Authority: DE
Inventors: Patrizio Trinchini; Massimo Villani
Original assignee: International Business Machines Corp
Current assignee: International Business Machines Corp
Priority date: 2012-05-04
Filing date: 2013-04-25
Publication date: 2013-11-07
Anticipated expiration: 2033-04-26
Also published as: GB201207851D0; GB2501757A; US20140040857A1; US20130298109A1; DE102013207608B4; US8990782B2; US8978019B2

Abstract

Vorgestellt wird eine Lösung zum Instrumentieren einer Software-Anmeldung für die Konfiguration derselben. Ein entsprechendes Verfahren weist die Schritte des Durchsuchens (409, 424, 433) eines Quellcodes der Software-Anwendung auf, um einen Hinweis auf einen Satz von Konfigurationsparametern zu finden, von denen ein jeder durch eine vordefinierte, nicht ausführbare Aussage kenntlich gemacht ist, des Erzeugens (436 bis 454) eines Satzes von Instanzen eines vordefinierten Konfigurationsobjekts, von denen eine jede einen entsprechenden der Konfigurationsparameter abbildet, wobei das Konfigurationsobjekt so ausgelegt ist, dass es den entsprechenden Konfigurationsparameter verwaltet, und des Erzeugens (412 bis 430, 457 bis 463) eines Satzes von Konfigurationsschnittstellen zum Bearbeiten der Konfigurationsparameter, wobei die Konfigurationsschnittstellen imstande sind, mit einer jeden Instanz des Konfigurationsobjekts zu interagieren, um den entsprechenden Konfigurationsparameter zu erhalten und zu setzen.

Description

Technisches Gebiet
Die Lösung gemäß einer oder mehreren Ausführungsformen der vorliegenden Erfindung bezieht sich auf das Gebiet der Datenverarbeitung. Im Besonderen bezieht sich diese Lösung auf die Konfiguration von Software-Anwendungen.
Technischer Hintergrund
Jede Software-Anwendung erfordert in der Regel während der Laufzeit eine Art von Konfiguration, um ihre Einstellungen ordnungsgemäß zu initialisieren und/oder ihren Betrieb gemäß dem tatsächlichen Kontext der Software-Anwendung anzupassen (ohne dabei den Code zu ändern); dies ermöglicht einem Systemadministrator beispielsweise, Netzwerkadressen/-anschlüsse festzulegen, Funktionen zu aktivieren/deaktivieren, Sicherheitsstufen auszuwählen, Benutzernamen und -kennwörter festzulegen, Berechtigungen zu definieren usw.
Zu diesem Zweck besteht eine übliche Lösung in der Verwendung einer Konfigurationsdatei (oder config-Datei), die Konfigurationsparameter der Software-Anwendung mit ihren Werten (als Parameter-Werte-Paare) speichert. Die Konfigurationsdatei liegt im Allgemeinen in Form einer Textdatei vor, so dass sie von Hand unter Verwendung eines Standard-Texteditors angepasst werden kann; alternativ kann eine spezielle Benutzeroberfläche genutzt werden, die von einem Universalwerkzeug (wie es z. B. in der Patentschrift US-A-US6691138 beschrieben wird, deren Offenbarung hier als Ganzes durch Bezugnahme mit aufgenommen wird) oder von einem spezifischen, in die Software-Anwendung selbst integrierten Werkzeug bereitgestellt wird.
Ein typisches Beispiel ist eine Software-Anwendung, die der Java (Handelsmarke) Enterprise Edition(JEE)-Spezifikation (früher: J2EE) entspricht. Die JEE-Spezifikation definiert ein Software-Schema, das einen Satz von Anwendungsprogrammschnittstellen (Application Program Interfaces, APIs) und eine Laufzeitumgebung bereitstellt, welche die Entwicklung einer Reihe von Software-Anwendungen erleichtern; im Besonderen definiert das Software-Schema der JEE-Spezifikation (bzw. das JEE-Schema) ein Modell für das Erzeugen der Software-Anwendungen unter Verwendung von Komponenten, die Dienste nutzen, welche von gemeinsamen Containern bereitgestellt werden (um damit den Entwicklern zu ermöglichen, sich auf die relevanten Geschäftsprobleme zu konzentrieren und etwaige Nebenaspekte derselben außer Acht zu lassen).
Die derzeitigen Realisierungen des JEE-Schemas stellen im Allgemeinen eine Verwaltungskonsole zum Konfigurieren der Dienste der Container bereit, darunter die Integrate Service Console (ISC) des WebSphere-Servers der IBM Corporation (Handelsmarken) oder die Admin Console des JBoss-Servers von RedHat (Handelsmarken).
Jede Software-Anwendung auf der Grundlage des JEE-Schemas (oder JEE-Anwendung) kann zudem einen oder mehrere Implementierungsdeskriptoren aufweisen. Jeder Implementierungsdeskriptor gibt die Werte von Standard-Konfigurationsparametern der JEE-Anwendung an, die in der JEE-Spezifikation vordefiniert sind (z. B. Ressourcenverweise, Sicherheitsrollen und Transaktionsattribute); die Container sind dafür ausgelegt, diese Standard-Konfigurationsparameter von den Implementierungsdeskriptoren zu erhalten und sie anzuwenden, indem sie entsprechend auf die JEE-Anwendung einwirken. Die tatsächliche Realisierung des JEE-Schemas stellt im Allgemeinen Anwendungsentwicklungswerkzeuge zum Bearbeiten der Standard-Konfigurationsparameter bereit, wie z. B. in „Behind the Scenes of J2EETM Deployment" von Elizabeth Hatfield, Daniel Edwin und Tom Kincaid und in „Deploying and Customizing J2EE Applications Guide for Oracle Siebel eStatement Manager" von Oracle" (Handelsmarken) beschrieben, deren Offenbarungen hier als Ganzes durch Bezugnahme mit aufgenommen werden.
Alternativ kann der Wert der Standard-Konfigurationsparameter auch in Form von Annotationen direkt im Code der JEE-Anwendung definiert werden (so dass jeder Standard-Konfigurationsparameter bei den Elementen stehen kann, auf die er sich auswirkt). In diesem Fall kann der Wert eines jeden Standard-Konfigurationsparameters, wie er in der entsprechenden Annotation definiert ist, auch durch einen weiteren Wert desselben in den Implementierungsdeskriptoren überschrieben werden (um damit zu vermeiden, dass der Code der JEE-Anwendung geändert wird), wie dies z. B. in der Patentschrift US-B-7607126 beschrieben wird, deren Offenbarung hier als Ganzes durch Bezugnahme mit aufgenommen wird.
Allerdings stellt das JEE-Schema keinen umfassenden Satz von APIs für den gesamten Verwaltungsprozess der anderen (benutzerdefinierten) Konfigurationsparameter bereit, die für eine jede JEE-Anwendung spezifisch sind (d. h. für das Bearbeiten, Abrufen, Festlegen und Anwenden derselben). In diesem Fall besteht ein bewährtes Verfahren darin, eine oder mehrere Eigenschaftendateien der JEE-Anwendung zu verwenden, welche (anhand der entsprechenden Eigenschaften) die Werte der benutzerdefinierten Konfigurationsparameter definieren. Das JEE-Schema stellt ein Standardverfahren zum Verweisen auf die Eigenschaftendateien bereit, indem für jede Eigenschaftendatei eine Verweisadresse (Uniform Resource Locator, URL) mit geeignetem Umfang definiert wird (um sie so unabhängig vom spezifischen Kontext der JEE-Anwendung zu machen). Zudem wird im Jgroups-Beitrag, JGRP-723, „Use Java annotations to automatically set protocol properties”, unter https://issues.jboss.org/browse/JGRP-723 (dessen Offenbarung als Ganzes hier durch Bezugnahme mit aufgenommen wird) die Möglichkeit vorgeschlagen, anhand von Annotationen und Java-Reflexion Protokolleigenschaftenwerte auf statische Art und Weise den passenden Java-Feldern zuzuweisen.
Dessen ungeachtet erfordert jede JEE-Anwendung spezifischen Code für das Verwalten der benutzerdefinierten Konfigurationsparameter. Hierfür weist die JEE-Anwendung in der Regel ein zweckbestimmtes Eigenschaftenverwaltungsprogramm auf, der aus einer einelementigen Komponente besteht (d. h. von dem es zu jedem beliebigen Zeitpunkt nur eine einzige Instanz gibt); das Eigenschaftenverwaltungsprogramm greift über ihre URL auf jede Eigenschaftendatei zu, erhält den Wert eines jeden darin definierten benutzerdefinierten Konfigurationsparameters und wendet ihn auf die JEE-Anwendung an. Entsprechend ist zusätzlicher Code erforderlich, um eine Benutzerschnittstelle zum Bearbeiten und Setzen der Konfigurationsparameter zu realisieren. Zudem sind die benutzerdefinierten Konfigurationsparameter eng an das Konfigurationsverwaltungsprogramm gekoppelt, da für ihre Verwaltung im Code der JEE-Anwendung ein statischer Verweis darauf enthalten ist.
Ein weiterer Nachteil besteht darin, dass die benutzerdefinierten Konfigurationsparameter während eines Lebenszyklus der JEE-Anwendung statisch sind; tatsächlich werden die Werte der benutzerdefinierten Konfigurationsparameter erhalten und angewendet, wenn die JEE-Anwendung gestartet wird, so dass sie zu einem späteren Zeitpunkt nicht geändert werden können (ohne die JEE-Anwendung neu zu starten). Darüber hinaus ist üblicherweise keine Beziehung zwischen den benutzerdefinierten Konfigurationsparametern realisiert.
Zusammenfassung
Allgemein gesprochen, beruht die Lösung gemäß einer oder mehreren Ausführungsformen der vorliegenden Erfindung auf der Vorstellung eines automatischen Instrumentierens der Software-Anwendung für ihre Konfiguration.
Im Besonderen werden ein oder mehrere Aspekte der Lösung gemäß spezifischen Ausführungsformen der Erfindung in den unabhängigen Ansprüchen und vorteilhafte Merkmale derselben Lösung in den abhängigen Ansprüchen dargelegt, wobei der Inhalt aller Ansprüche hier wörtlich durch Bezugnahme mit aufgenommen wird (wobei ein etwaiges vorteilhaftes Merkmal, das mit Bezug auf einen spezifischen Aspekt der Lösung gemäß einer Ausführungsform der Erfindung bereitgestellt wird, wechselseitig auch für jeden anderen Aspekt derselben gilt).
Konkret stellt ein Aspekt der Lösung gemäß einer Ausführungsform der Erfindung ein Verfahren zum Instrumentieren einer Software-Anwendung für ihre Konfiguration bereit, wobei ein Quellcode der Software-Anwendung daraufhin untersucht wird, ob ein Hinweis auf einen Satz von Konfigurationsparametern gefunden wird, und wobei ein Satz von Instanzen eines vordefinierten Konfigurationsobjekts (jedes einzelne zum Verwalten eines entsprechenden Konfigurationsparameters) und ein Satz von Konfigurationsschnittstellen (zum Bearbeiten der Konfigurationsparameter) erzeugt werden.
Ein weiterer Aspekt der Lösung gemäß einer Ausführungsform der Erfindung stellt ein Computerprogramm zum Durchführen dieses Verfahrens bereit.
Ein weiterer Aspekt der Lösung gemäß einer Ausführungsform der Erfindung stellt ein entsprechendes System bereit.
Kurzbeschreibung der Zeichnungen
Die Lösung gemäß einer oder mehreren Ausführungsformen der Erfindung sowie weitere Merkmale und Vorteile derselben werden am offensichtlichsten mit Blick auf die folgende ausführliche Beschreibung, die ausschließlich als nicht einschränkende Information zu verstehen und in Verbindung mit den beigefügten Zeichnungen zu lesen ist (bei denen aus Gründen der Einfachheit entsprechende Elemente mit gleichen oder ähnlichen Bezugsziffern versehen sind und ihre Erläuterung nicht wiederholt wird sowie die Bezeichnung für eine jede Einheit im Allgemeinen verwendet wird, um sowohl ihre Art als auch ihre Attribute, wie beispielsweise Wert, Inhalt und Darstellung, zu benennen). Im Besonderen:
zeigt 1 eine bildliche Darstellung eines Systems, worin die Lösung gemäß einer Ausführungsform der Erfindung angewendet werden kann,
zeigt 2 die Haupt-Software-Komponenten, die verwendet werden können, um die Lösung gemäß einer Ausführungsform der Erfindung zu realisieren,
zeigt 3 ein Beispiel einer Realisierung der Lösung gemäß einer Ausführungsform der Erfindung, und
zeigen die 4A und 4B ein Aktivitätsschaubild, das den Fluss von Aktivitäten in Zusammenhang mit einer Realisierung der Lösung gemäß einer Ausführungsform der Erfindung beschreibt.
Beschreibung der Ausführungsformen
Mit gesondertem Blick auf 1 wird eine bildliche Darstellung eines Systems 100 gezeigt, worin die Lösung gemäß einer Ausführungsform der Erfindung angewendet werden kann.
Das System 100 beruht auf einem Client/Server-Modell, bei dem ein oder mehrere Server-Computer (oder einfach Server) 105 einem oder mehreren Client-Computern (oder einfach Clients) 110 Dienste bereitstellen. Typischerweise weist das System 100 eine verteilte Architektur mit den Servern 105 und den Clients 110 auf, die über ein (z. B. auf dem Internet beruhendes) Netzwerk 115 miteinander Daten austauschen.
Jeder (Server- oder Client-)Computer weist mehrere Einheiten auf, die parallel mit einem Systembus 120 (mit einer Struktur, die gemäß der tatsächlichen Funktion des Computers in dem System 100 passend skaliert ist) verbunden sind. Im Einzelnen steuern ein oder mehrere Mikroprozessoren (μP) 125 den Betrieb des Computers; ein RAM 130 wird von den Mikroprozessoren 125 als Arbeitsspeicher verwendet, und ein ROM 135 speichert grundlegenden Code für ein Booten des Computers. Mehrere Peripherieeinheiten sind (mittels entsprechender Schnittstellen) um einen lokalen Bus 140 gruppiert. Im Besonderen weist ein Massenspeicher eine oder mehrere Festplatten 145 und Laufwerke 150 zum Lesen/Beschreiben von optischen Platten 155 (z. B. CDs oder DVDs) auf. Darüber hinaus weist der Computer Eingabeeinheiten 160 (z. B. eine Tastatur und eine Maus) und Ausgabeeinheiten 165 (z. B. einen Bildschirm) auf. Ein Netzwerkadapter 170 dient zum Verbinden des Computers mit dem Netzwerk 115. Eine Brückeneinheit 175 dient als Schnittstelle zwischen dem Systembus 120 und dem lokalen Bus 140. Jeder Mikroprozessor 125 und die Brückeneinheit 175 können als Master-Agenten fungieren, die zum Übertragen von Daten einen Zugriff auf den Systembus 120 anfordern. Eine Entscheidungseinheit 180 verwaltet das Gestatten des Zugriffs mit wechselseitigem Ausschluss auf den Systembus 120.
Die Haupt-Software-Komponenten, die verwendet werden können, um die Lösung gemäß einer Ausführungsform der Erfindung zu realisieren, werden in 2 gezeigt. Die Informationen (Programme und Daten) werden üblicherweise auf der Festplatte gespeichert und gemeinsam mit einem Betriebssystem und anderen Anwendungsprogrammen (in der Figur nicht abgebildet) (zumindest teilweise) in den Arbeitsspeicher eines jeden Computers geladen, wenn die Programme ausgeführt werden. Die Programme werden anfangs z. B. von optischen Platten auf der Festplatte installiert.
Im Besonderen führt das oben beschriebene System JEE-Anwendungen aus, von denen eine jede eine mehrschichtige Architektur beruhend auf Komponenten aufweist, die von gemeinsamen Containern bereitgestellte Dienste nutzen; üblicherweise weist die JEE-Anwendungen drei Schichten auf, da sie auf einen Client 110, der eine Client-Schicht 205 realisiert, auf einen (als JEE-Server 105j bezeichneten) Server, der eine Web-Schicht 210 und eine Geschäftsschicht 215 realisiert, und auf einen weiteren (als Datenbank-Server 105d bezeichneten) Server verteilt ist, der eine EIS-Schicht (Enterprise Information System) 220 realisiert.
Jede Komponente besteht aus einem eigenständigen Software-Modul, das eine spezifische Funktion ausführt, wobei die Komponente in der Java-Programmiersprache von Oracle (Handelsmarken) geschrieben und mit der JEE-Spezifikation konform ist.
Genauer ausgedrückt, kann der Client 110 entsprechende Komponenten ausführen, die entweder aus Web-Clients 225 oder Anwendungs-Clients 230 bestehen. Jeder Web-Client 225 dient dazu, anhand von Webseiten (d. h. in der HTML-Sprache formatierten Hypertext-Dokumenten, auf die über einen Web-Browser zugegriffen wird), die Applets (d. h. kleine, zur Ausführung in dem Web-Browser vorgesehene Programme) aufweisen können, über die Web-Schicht 210 mit der Geschäftsschicht 215 zu interagieren. Andererseits wird jeder Anwendungs-Client 230 dazu verwendet, anhand eines umfangreicheren Satzes von Befehlen, der üblicherweise als zweckbestimmte grafische Benutzeroberfläche (Graphical User Interface, GUI) realisiert ist, (entweder über die Web-Schicht 210 oder direkt) mit der Geschäftsschicht 215 zu interagieren.
Die Web-Schicht 210 des JEE-Servers 105j kann entsprechende Komponenten ausführen, die entweder aus Java-Servlets 235 (d. h. kleinen, dauerhaft bereitgestellten Programmen, die über entsprechende, in einem einzelnen Prozess ausgeführte Teilprozesse mehrere Anforderungen erfüllen können), JavaServer Pages (JSPs) 240 (d. h. Web-Seiten, die in der Lage sind, automatisch Servlets zu erzeugen) oder JavaServer Faces (JSFs) 245 (d. h. Web-Anwendungsschemata, die auf Servlets und JSPs aufbauen) bestehen. Die Geschäftsschicht 215 des JEE-Servers 105j kann anstelle dessen entsprechende Komponenten ausführen, die aus Enterprise JavaBeans (EJBs) 250 bestehen. Jede EJB 250 ist eine Java Bean (d. h. ein Objekt, das vorgegebenen Spezifikationen entspricht), die dazu dient, spezifische Operationen in der relevanten Geschäftsdomäne der JEE-Anwendung durchzuführen (z. B. Bank-, Versicherungs- oder Einzelhandelsorganisationen); die EJB 250 kann eine Session Bean (die vorübergehende Sitzungen mit dem Client 110 verwaltet) oder eine Message-Driven Bean sein (welche die Session Bean um Funktionen für das Nachrichtenhören ergänzt, so dass Nachrichten asynchron von dem Client 110 empfangen werden können).
Abschließend führt der Datenbank-Server 105d herkömmliche Systeme 255 aus, die üblicherweise den Zugriff auf eine oder mehrere Datenbanken verwalten. Die herkömmlichen Systeme 255 verarbeiten Anforderungen von den EJBs 250 oder von den Anwendungs-Clients 230; zu diesem Zweck definiert die JEE-Spezifikation Java-persistente API-Entitäten, von denen eine jede für dauerhaft bereitgestellte Daten in einer Datenbank steht (wodurch die Entity Beans aus der J2EE-Spezifikation ersetzt werden).
Andererseits besteht ein Container aus einer Schnittstelle zwischen Komponenten eines entsprechenden Typs und der darunterliegenden Software-Umgebung. Anders ausgedrückt: Der Container stellt untergeordnete (für eine jede Software-Umgebung spezifische) Funktionen bereit, die seine Komponenten unterstützen. Typische Beispiele dieser Funktionalitäten weisen Nachrichtenaustausch, Planung, Pooling, Fehlerverarbeitung und Ähnliches auf; im Besonderen ist der Container für das korrekte Weitergeben von Anforderungen und entsprechenden Antworten (gemäß einem entsprechenden Abbilden der relevanten Komponenten) zuständig.
Mit besonderem Blick auf den Client 110 verwaltet ein Applet-Container 260 die Ausführung der Web-Clients 225; üblicherweise besteht der Applet-Container 260 aus einem Web-Browser (zum Abrufen von, Anzeigen von und Interagieren mit den Webseiten), der eine Java Virtual Machine oder JVM (zum Ausführen der Applets) aufweist. Desgleichen verwaltet ein Anwendungs-Client-Container 265 die Ausführung der Anwendungs-Clients 230; üblicherweise besteht der Anwendungs-Client-Container 265 aus einer Java Runtime Environment (JRE). Mit Blick auf den JEE-Server 105j verwaltet in der Web-Schicht 210 ein Web-Container 270 die Ausführung der Servlets 235, JSPs 240 und JavaServer Faces 245, während in der Geschäftsschicht 215 ein EJB-Container 275 die Ausführung der EJBs 250 verwaltet.
Die JEE-Anwendung ist in JEE-Module gepackt. Jedes JEE-Modul weist eine oder mehrere Komponenten für ein und denselben Container auf; im Besonderen weisen Anwendungs-Client-Module Web-Clients 225 und/oder Anwendungs-Clients 230 auf, Web-Module weisen Java-Servlets 235, JSPs 240 und/oder JavaServer Faces 245 auf, EJB-Module weisen EJBs 250 auf, und Ressourcen-Adaptermodule weisen beliebige Ressourcen auf, die benötigt werden, um eine Verbindung mit den herkömmlichen Systemen 255 herzustellen. Die Module sind wiederum gemeinsam mit optionalen Implementierungsdeskriptoren in einer Enterprise Archive(EAR)-Datei gebündelt; die Implementierungsdeskriptoren sind Dateien im XML-Format, die Daten zur Konfiguration der Komponenten eines betreffenden Moduls oder der gesamten JEE-Anwendung enthalten. Die Implementierungsdeskriptoren können JEE-Implementierungsdeskriptoren (welche die Werte von Standard-Konfigurationsparametern angeben, die in der JEE-Spezifikation vordefiniert sind) oder Laufzeit-Implementierungsdeskriptoren sein (die benutzerdefinierte Konfigurationsparameter angeben, welche für die JEE-Anwendung spezifisch sind); alternativ kann der Wert der Standard-Konfigurationsparameter auch in Form von Annotationen direkt im Code der JEE-Anwendung definiert sein. Eine Annotation ist eine nicht ausführbare, im Quellcode der JEE-Anwendung vorhandene Aussage, die Informationen zu der JEE-Anwendung bereitstellt (die z. B. durch einen Kompilierer oder anderweitige Werkzeuge genutzt werden). Die Annotation wird durch das Symbol @ gefolgt von ihrem Namen kenntlich gemacht; die Annotation kann auch ein oder mehrere Elemente aufweisen, von denen jedes entweder aus einem Wert oder aus einem Namen-Werte-Paar bestehen kann (gemäß einem Typ der Annotation, der in einer entsprechenden Schnittstelle definiert ist). Ein Beispiel für eine Realisierung der Lösung gemäß einer Ausführungsform der Erfindung wird in 3 gezeigt. Die Informationen (Programme und Daten) werden üblicherweise auf der Festplatte gespeichert und gemeinsam mit einem Betriebssystem und anderen Anwendungsprogrammen (in der Figur nicht abgebildet) (zumindest teilweise) in den Arbeitsspeicher eines jeden Computers geladen, wenn die Programme ausgeführt werden. Die Programme werden anfangs z. B. von optischen Platten auf der Festplatte installiert.
Ein Anwendungs-Server 305 realisiert das oben beschriebene JEE-Schema, indem er die durch die JEE-Spezifikation definierten APIs bereitstellt (die den Web-Container und den EJB-Container aufweisen), zusammenfassend mit der Bezugsziffer 310 bezeichnet. Darüber hinaus kann der Anwendungs-Server 305 zusätzliche (nicht in der JEE-Spezifikation definierte) Werkzeuge bereitstellen, die nützlich sind, um die JEE-Anwendungen zu verwalten; im Besonderen weist der Anwendungs-Server 305 üblicherweise eine Verwaltungskonsole 315 mit einer GUI auf der Grundlage des Web auf, die zum Konfigurieren, Starten und Stoppen der JEE-Anwendungen verwendet werden kann. Beispiele für den Anwendungs-Server 305 sind die oben erwähnten WebSphere- und JBoss-Server sowie der TomCat-Server der Apache Software Foundation (Handelsmarken).
Eine allgemeine JEE-Anwendung 320, welche die entsprechenden Komponenten 325 und mögliche Implementierungsdeskriptoren 330 aufweist, wird auf dem Anwendungs-Server 305 bereitgestellt. Zu diesem Zweck fügt ein Systemadministrator dem Anwendungs-Server 305 die Komponenten 325 und die Deskriptoren 350 hinzu. Danach konfiguriert der Systemadministrator die JEE-Anwendung 320 wie gewohnt, indem er deren Standard-Konfigurationsparameter über die Verwaltungskonsole 315 passend setzt.
Bei der Lösung gemäß einer Ausführungsform der Erfindung werden die benutzerdefinierten Konfigurationsparameter durch die entsprechenden Annotationen des Quellcodes der JEE-Anwendung 320 definiert. So kann die JEE-Anwendung 320 z. B. eine oder mehrere zusätzliche Komponenten 335 (wie z. B. Java Beans) aufweisen, die als annotierte Komponenten 335 bezeichnet werden, um sie von den Komponenten 325 zu unterscheiden, die Funktionalitäten der JEE-Anwendung definieren (und als Funktionskomponenten bezeichnet werden).
Der Anwendungs-Server 305 weist eine Konfigurationserweiterung 340 auf, welche die annotierten Komponenten 335 durchsucht, um etwaige Annotationen zu finden, die entsprechende benutzerdefinierte Konfigurationsparameter definieren. Für jeden benutzerdefinierten Konfigurationsparameter erzeugt die Konfigurationserweiterung 340 dynamisch ein Objekt (z. B. eine Java Bean), das aus einer entsprechenden Instanz einer vordefinierten Konfigurationsklasse besteht, die den benutzerdefinierten Konfigurationsparameter abbildet (als Konfigurationskomponente 345 bezeichnet). Die Konfigurationsklasse ist so ausgelegt, dass sie Felder aufweist, welche den entsprechenden benutzerdefinierten Konfigurationsparameter (der auf die Funktionskomponenten 325 anzuwenden ist) und seinen Wert identifizieren, der anfänglich auf einen (von der Konfigurationserweiterung 340 bei der Instanziierung weitergegebenen) Standardwert gesetzt ist; die Konfigurationsklasse weist zudem Verfahren auf, um den Wert des benutzerdefinierten Konfigurationsparameters zu erhalten und den Wert des benutzerdefinierten Konfigurationsparameters zu setzen (und ihn z. B. in einer Datei dauerhaft bereitzustellen). Darüber hinaus erzeugt die Konfigurationserweiterung 340 dynamisch eine oder mehrere Benutzerschnittstellen zum Aktualisieren der benutzerdefinierten Konfigurationsparameter; so ist es z. B. möglich, Konfigurations-Web-Seiten (oder einfach Konfigurationsseiten) 350 mit vordefiniertem Verwaltungscode bereitzustellen, die mit den Konfigurationskomponenten 345 (z. B. auf der Grundlage des JMX-Standards (Java Management Extensions)) interagieren, wobei die Konfigurationsseiten 350 durch die Verwaltungskonsole 315 gesteuert werden.
Die Lösung gemäß einer Ausführungsform der Erfindung erfordert keinen speziellen Code für das Verwalten und Bearbeiten der benutzerdefinierten Konfigurationsparameter; daher kann die JEE-Anwendung automatisch für ihre Konfiguration instrumentiert werden, wodurch dies deutlich vereinfacht wird. Konkret müssen die Entwickler nun lediglich die Komponenten und ihre Variablen, die für die benutzerdefinierten Konfigurationsparameter stehen, mit Annotationen versehen (während die Realisierung der Einzelheiten der gesamten Verwaltung der benutzerdefinierten Konfigurationsparameter den Entwicklern nun verborgen bleibt).
Im Besonderen macht die oben beschriebene spezifische Ausführungsform die Verwaltung der benutzerdefinierten Konfigurationsparameter für den Anwendungs-Server 305 und die JEE-Anwendung 320 einheitlicher; tatsächlich kann der Systemadministrator in diesem Fall ein und dieselbe Verwaltungskonsole 315 verwenden, um die Konfigurationsparameter zu bearbeiten, die sowohl von allgemeiner Gültigkeit für den Anwendungs-Server 305 als auch spezifisch für die JEE-Anwendung 320 sind.
So kann z. B. eine allgemeine, annotierte Komponente eine Klasse meineAnnotierteKomponente instanziieren. In der Klasse meineAnnotierteKomponente wird jeder benutzerdefinierte Konfigurationsparameter durch ein Feld definiert, dem ein entsprechender Standardwert zugewiesen ist (z. B. die benutzerdefinierten Konfigurationsparameter meinParameter1 und meinParameter2 mit den Standardwerten meinWert1 bzw. meinWert2); der benutzerdefinierte Konfigurationsparameter wird durch eine vordefinierte (Parameter-)Annotation @Eigenschaft identifiziert, die drei Name-Werte-Paare hat, die ein Element name für einen Namen des benutzerdefinierten Konfigurationsparameters (d. h. meinName1 bzw. meinName2), ein Element beschreibung für eine erläuternde Beschreibung des benutzerdefinierten Konfigurationsparameters (d. h. meineBeschreibung1 bzw. meineBeschreibung2) und ein Element ändereProzess für einen Aktualisierungsbetriebszustand aufweisen, der durch den benutzerdefinierten Konfigurationsparameter unterstützt wird (z. B. Setzen auf das Schlüsselwort konfiguration für einen kalten Betriebszustand, der den Neustart der JEE-Anwendung erfordert, oder auf das Schlüsselwort laufzeit für einen warmen Betriebszustand, der auch bei laufender JEE-Anwendung möglich ist). Die Annotation Eigenschaft kann zudem ein (optionales) Element validierung für eine (oder mehrere) Validierungsregeln des benutzerdefinierten Konfigurationsparameters aufweisen (z. B. einen Bereich von gültigen Werten desselben, die entweder als Absolutwerte oder als eine Funktion der Werte anderer benutzerdefinierter Konfigurationsparameter ausgedrückt werden); so sollte der Wert des benutzerdefinierten Konfigurationsparameters meinParameter1 beispielsweise zwischen meinTiefstwert1 und meinHöchstwert2 liegen, während der Wert des benutzerdefinierten Konfigurationsparameters meinParameter2 unter dem Doppelten des Werts des benutzerdefinierten Konfigurationsparameters meinParameter1 liegen sollte. Vorzugsweise werden zusammengehörige benutzerdefinierte Konfigurationsparameter in Abschnitten zusammengefasst, die durch eine vordefinierte (Abschnitts-)Annotation @Eigenschaftenmanager kenntlich gemacht werden, welche für die oben erwähnten benutzerdefinierten Konfigurationsparameter meinParameter1 und meinParameter2 z. B. lautet:
Der benutzerdefinierte Konfigurationsparameter meinParameter1 kann z. B. eine Zeitüberschreitung sein (die in dem warmen Betriebszustand aktualisiert werden kann), und der benutzerdefinierte Konfigurationsparameter meinParameter2 kann eine Anschlussnummer sein (die nur in dem kalten Betriebszustand aktualisiert werden kann).
Für jeden benutzerdefinierten Konfigurationsparameter, der das Aktualisieren in der kalten Betriebsart unterstützt (ändereProzess = ”Laufzeit”), wird auch ein entsprechendes Anwendungsverfahren bereitgestellt. Das Anwendungsverfahren ist durch eine vordefinierte (Anwendungs-)Annotation @zuEigenschaftsänderung mit einem Element eigenschaft für ihren benutzerdefinierten Konfigurationsparameter kenntlich gemacht; das Anwendungsverfahren weist die (für die JEE-Anwendung spezifischen) Anweisungen auf, die auszuführen sind, um den benutzerdefinierten Konfigurationsparameter anzuwenden, wenn er aktualisiert wird (z. B. Neuladen von Verbindungen, Tabellen und Ähnlichem). Im hier genannten Beispiel weist die Klasse meineAnnotierteKomponente ein Anwendungsverfahren Anwenden1 für den benutzerdefinierten Konfigurationsparameter meinParameter1 auf (wobei eine Ganzzahl zurückgegeben wird, die ein Ergebnis ihrer Anwendung angibt):
Die Konfigurationsseiten sind so aufgebaut, dass sie den Namen und die Beschreibung eines jeden (aus den entsprechenden Elementen name bzw. beschreibung erhaltenen) benutzerdefinierten Konfigurationsparameters gemeinsam mit seinem aktuellen (zu Beginn auf den Standardwert gesetzten) Wert anzeigen.
Vorzugsweise wird für jeden Abschnitt von benutzerdefinierten Konfigurationsparametern eine andere Konfigurationsseite angezeigt (um auf diese Weise ihre Verwaltung zu vereinfachen).
Als weitere Verbesserung können die annotierten Komponenten in einer hierarchischen Struktur angeordnet werden, wie sie von der Java-Sprache inhärent bereitgestellt wird. Hierfür werden die benutzerdefinierten Konfigurationsparameter in mehreren annotierten Komponenten definiert; einige dieser annotierten Komponenten erweitern (direkt oder indirekt) einige andere der annotierten Komponenten, um so ihre Merkmale zu erben. In diesem Fall werden die den benutzerdefinierten Konfigurationsparametern zugehörigen Konfigurationsseiten (gemäß ihren Abhängigkeiten) in einer entsprechenden Baumstruktur organisiert; dies stellt eine unmittelbare visuelle Darstellung der entsprechenden hierarchischen Struktur der benutzerdefinierten Konfigurationsparameter bereit. So ist es beispielsweise möglich, eine Breadcrumb-Navigationsdarstellung zu realisieren, bei der jede Konfigurationsseite eine Kette von Verknüpfungen zurück zu ihren Eltern-Konfigurationsseiten in der hierarchischen Struktur aufweist.
Mit Blick auf die 4A und 4B wird ein Aktivitätsschaubild gezeigt, das den Fluss von Aktivitäten in Zusammenhang mit einer Realisierung der Lösung gemäß einer Ausführungsform der Erfindung beschreibt. So kann jeder Block in dem Schaubild ein Modul, Segment oder einen Code-Teil darstellen, der einen oder mehrere ausführbare Befehle aufweist, mit denen sich die angegebene(n) logische(n) Funktion(en) realisieren lässt/lassen.
Im Besonderen stellt das Schaubild einen beispielhaften Prozess dar, der in dem oben beschriebenen System realisiert werden kann, um eine allgemeine JEE-Anwendung mit einem Verfahren 400 automatisch für ihre Konfiguration zu instrumentieren.
Das Verfahren wechselt von Block 403 zu Block 406, wenn die JEE-Anwendung auf dem Anwendungs-Server bereitgestellt wird. In dieser Phase werden die (Funktions- und annotierten)Komponenten mit den möglichen Implementierungsdeskriptoren der JEE-Anwendung dem Anwendungs-Server hinzugefügt; darüber hinaus konfiguriert der Systemadministrator über die Verwaltungskonsole wie gewohnt die JEE-Anwendung.
Bei der Lösung gemäß einer Ausführungsform der Erfindung durchsucht die Konfigurationserweiterung des Anwendungs-Servers in Block 409 den Quellcode der JEE-Anwendung, um die Annotationen zu finden, die relevant für Instrumentierung derselben sind. Danach wird eine Schleife durchgeführt, um (beginnend mit der ersten Annotation) jede gefundene Annotation zu verarbeiten; die Schleife beginnt in Block 412, wo geprüft wird, ob eine Konfigurationsseite für die annotierte Komponente, in der diese Annotation gefunden wurde, bereits vorhanden ist. Wenn dies nicht der Fall ist, wird in Block 415 eine neue Konfigurationsseite erzeugt und in die Verwaltungskonsole eingebunden. Danach wird in Block 418 geprüft, ob die annotierte Komponente eine andere annotierte (Eltern-)Komponente erweitert. Wenn dies der Fall ist, wird in Block 421 die neu erzeugte Konfigurationsseite mit der Konfigurationsseite der annotierten (Eltern-)Komponente verknüpft. Das Verfahren geht dann zu Block 424; derselbe Punkt wird auch direkt von Block 412 (falls die Konfigurationsseite der annotierten Komponente bereits vorhanden ist) oder von Block 418 erreicht (falls die Klasse der annotierten Komponente die Klasse einer beliebigen anderen annotierten Komponente nicht erweitert). Danach verzweigt sich der Aktivitätsfluss gemäß dem Annotationstyp.
Konkret werden die Blöcke 427 bis 430 ausgeführt, wenn die Annotation eine Abschnittsannotation (d. h. @Eigenschaftenmanager) ist, während die Blöcke 433 bis 463 ausgeführt werden, wenn die Annotation eine Parameterannotation (d. h. @Eigenschaft) ist; in beiden Fällen kommt das Verfahren bei Block 466 wieder zusammen.
Mit Blick auf Block 427 (Abschnittsannotation) wird geprüft, ob für den Abschnitt in der Konfigurationsseite für die annotierte Komponente der Annotation bereits ein Registerkarten-Teilfenster vorhanden ist. Wenn dies nicht der Fall ist, wird in Block 430 für den betreffenden Abschnitt ein neues Registerkarten-Teilfenster zu dieser Konfigurationsseite hinzugefügt. Danach springt das Verfahren zu Block 466; derselbe Punkt wird ansonsten auch direkt von Block 427 erreicht.
Mit Blick auf Block 433 (Parameterannotation) wird der entsprechende (direkt auf die Annotation folgende) benutzerdefinierte Konfigurationsparameter ermittelt. Indem mit Block 436 fortgefahren wird, erzeugt die Konfigurationserweiterung eine neue Konfigurationskomponente (indem sie die Konfigurationsklasse instanziiert). Diese Konfigurationskomponente wird in Block 439 initialisiert, um so den benutzerdefinierten Konfigurationsparameter (z. B. mit einem Feld, das für die Verwaltung eines allgemeinen benutzerdefinierten Konfigurationsparameters vorgesehen ist, das diesem zugewiesen ist, wobei der mögliche Standardwert in der annotierten Komponente genannt wird) abzubilden; darüber hinaus werden weitere Felder der Konfigurationskomponente gemäß dem Namen und der Beschreibung des benutzerdefinierten Konfigurationsparameters initialisiert, wie in den entsprechenden Elementen der Annotation (d. h. name bzw. beschreibung) definiert. Danach verzweigt das Verfahren in Block 442 gemäß dem Wert des Elements ändereProzess des benutzerdefinierten Konfigurationsparameters. Konkret wird die Konfigurationskomponente in Block 445 initialisiert, wenn das Element ändereProzess den Wert konfiguration hat, um so den benutzerdefinierten Konfigurationsparameter in der kalten Betriebsart anzuwenden (indem beispielsweise eine entsprechende Markierung zugesichert wird). Dagegen wird die Konfigurationskomponente in Block 448 initialisiert, wenn das Element ändereProzess den Wert laufzeit hat, um damit den benutzerdefinierten Konfigurationsparameter in der warmen Betriebsart anzuwenden (indem beispielsweise dieselbe Markierung nicht zugesichert wird). In diesem Fall wird der Quellcode der JEE-Anwendung daraufhin durchsucht, ob die entsprechende Anwendungsannotation (d. h. @zuEigenschaftsänderung, wobei das Element eigenschaft den benutzerdefinierten Konfigurationsparameter angibt) gefunden wird. Danach wird in Block 454 das Anwendungsverfahren der (unmittelbar auf sie folgenden) Anwendungsannotation der Konfigurationskomponente zugeordnet (indem z. B. ein betreffendes Feld entsprechend gesetzt wird).
Der Aktivitätsfluss geht entweder von Block 445 oder von Block 454 zu Block 457. In dieser Phase wird geprüft, ob der Parameterannotation (in derselben annotierten Komponente) eine Abschnittsannotation vorangeht. Wenn dies der Fall ist, wird in Block 460 dem Registerkarten-Teilfenster des betreffenden Abschnitts (in der Konfigurationsseite der annotierten Komponente) ein neues Eingabefeld für den benutzerdefinierten Konfigurationsparameter (mit einer auf seinen Namen und seine Beschreibung gesetzten Kennung) hinzugefügt; das Eingabefeld wird der Validierungsregel des benutzerdefinierten Konfigurationsparameters zugeordnet, sofern diese vorhanden ist (wie im Element validierung angegeben). Andernfalls wird in Block 463 dasselbe Eingabefeld direkt dem Hauptteil der Konfigurationsseite der annotierten Komponente hinzugefügt. In jedem Fall geht das Verfahren dann zu Block 466.
Danach wird geprüft, ob alle benutzerdefinierten Konfigurationsparameter verarbeitet wurden. Wenn dies nicht der Fall ist, kehrt das Verfahren zu Block 412 zurück, um dieselben Operationen für einen nächsten benutzerdefinierten Konfigurationsparameter zu wiederholen; andernfalls kehrt das Verfahren zu Block 403 zurück und wartet auf die Bereitstellung einer weiteren JEE-Anwendung.
Wenn der Systemadministrator die JEE-Anwendung konfigurieren muss, wechselt das Verfahren auf eine vollständig asynchrone Art und Weise von Block 469 zu Block 472. In dieser Phase zeigt die Verwaltungskonsole eine Baumdarstellung der hierarchischen Struktur der Konfigurationsseiten an, um dem Systemadministrator so zu gestatten, durch diese Baumdarstellung zu navigieren und eine etwaige gewünschte Konfigurationsseite auszuwählen. Indem mit Block 475 fortgefahren wird, wird die (ausgewählte) Konfigurationsseite in der Verwaltungskonsole angezeigt; konkret ruft die Konfigurationsseite für jedes Eingabefeld der Konfigurationsseite die entsprechende Konfigurationskomponente auf, um den aktuellen Wert ihres benutzerdefinierten Konfigurationsparameters zu erhalten. Vorzugsweise fügt die Verwaltungskonsole auch einen Breadcrumb-Navigationspfad zu der Konfigurationsseite hinzu (der Verknüpfungen zurück zu einer etwaigen vorherigen Konfigurationsseite in der hierarchischen Struktur bereitstellt).
Indem mit Block 478 fortgefahren wird, kann der Systemadministrator entweder einen oder mehrere benutzerdefinierte Konfigurationsparameter der Konfigurationsseite bearbeiten. Für jeden benutzerdefinierten Konfigurationsparameter, der bearbeitet wurde, wird in Block 481 ein vordefiniertes Validierungsverfahren der entsprechenden Konfigurationsseite aufgerufen, indem ihre Validierungsregel (sofern vorhanden) weitergegeben wird. Wenn der neue Wert des benutzerdefinierten Konfigurationsparameters nicht der Validierungsregel entspricht, kehrt das Verfahren zu Block 478 zurück und fordert den Systemadministrator auf, ihn zu korrigieren. Sobald die benutzerdefinierten Konfigurationsparameter validiert und akzeptiert wurden, geht das Verfahren zu Block 484. Danach wird eine Schleife durchgeführt, um jeden (aktualisierten) benutzerdefinierten Konfigurationsparameter zu verarbeiten (wobei mit dem ersten begonnen wird); hierzu ruft die Konfigurationsseite die entsprechende Konfigurationskomponente auf, um den neuen Wert ihres benutzerdefinierten Konfigurationsparameters zu setzen; als Reaktion darauf wird ein neuer Wert des benutzerdefinierten Konfigurationsparameters dauerhaft bereitgestellt. Indem mit Block 487 fortgefahren wird, verzweigt sich der Aktivitätsfluss gemäß der Initialisierung der Konfigurationskomponente. Konkret wird der Systemadministrator, wenn die Konfigurationskomponente initialisiert wurde, um den entsprechenden benutzerdefinierten Konfigurationsparameter in der kalten Betriebsart anzuwenden, in Block 490 benachrichtigt, dass der neue Wert des benutzerdefinierten Konfigurationsparameters bei einem nächsten Neustart der JEE-Anwendung angewendet wird. Andernfalls wendet die Konfigurationskomponente den neuen Wert des benutzerdefinierten Konfigurationsparameters in Block 493 auf die JEE-Anwendung an; zu diesem Zweck ruft die Konfigurationskomponente sein Anwendungsverfahren auf (wie in dem entsprechenden Feld angegeben). Somit wird die JEE-Anwendung über die Aktualisierung des benutzerdefinierten Konfigurationsparameters unterrichtet und reagiert entsprechend.
In beiden Fällen wird in Block 496 geprüft, ob alle aktualisierten benutzerdefinierten Konfigurationsparameter verarbeitet wurden. Wenn dies nicht der Fall ist, kehrt das Verfahren zu Block 484 zurück, um dieselben Operationen für einen nächsten aktualisierten, benutzerdefinierten Konfigurationsparameter zu wiederholen; andernfalls verzweigt das Verfahren in Block 499. Wenn der Systemadministrator mit der Konfiguration der JEE-Anwendung fortfahren muss, kehrt das Verfahren in dieser Phase zu Block 472 zurück, um dieselben Operationen wie oben beschrieben zu wiederholen; andernfalls kehrt das Verfahren zu Block 469 zurück und wartet auf eine nächste Konfiguration derselben oder einer anderen JEE-Anwendung.
Um lokale und spezifische Anforderungen zu erfüllen, kann ein Fachmann selbstverständlich zahlreiche logische und/oder physische Anpassungen und Änderungen an der oben beschriebenen Lösung vornehmen. Konkret sollte klar sein, dass, obwohl diese Lösung in gewisser Weise mit Bezug auf eine oder mehrere Ausführungsformen derselben beschrieben wurde, verschiedene Auslassungen, Ersetzungen und Änderungen an Form und Einzelheiten sowie anderweitige Ausführungsformen möglich sind. Insbesondere können verschiedene Ausführungsformen der Erfindungen sogar ohne die in der voranstehenden Beschreibung genannten spezifischen Einzelheiten (wie z. B. die Zahlenwerte) praktisch durchgeführt werden, um so ein gründlicheres Verständnis derselben zu erlauben; andererseits wurden bekannte Merkmale unter Umständen ausgelassen oder vereinfacht, um die Beschreibung nicht durch unnötige Details unklar zu machen. Zudem ist ausdrücklich beabsichtigt, dass spezifische Elemente und/oder Verfahrensschritte, die in Zusammenhang mit einer beliebigen Ausführungsform der offenbarten Lösung beschrieben werden, im Rahmen einer allgemeinen Auslegungsentscheidung auch in eine beliebige andere Ausführungsform integriert werden können. In jedem Fall werden Ordnungszahlen oder andere qualifizierende Angaben lediglich als Kennungen verwendet, um Elemente mit demselben Namen voneinander zu unterscheiden, ohne selbst jedoch eine wie auch immer geartete Priorität, Vorrangstellung oder Rangfolge nahezulegen. Darüber hinaus sollten die Begriffe „beinhalten”, „aufweisen”, „haben”, „enthalten” und „einbeziehen” (sowie sämtliche Formen derselben) in einem offenen, nicht ausschließenden Sinne (d. h. nicht auf die genannten Objekte beschränkt) verstanden werden, die Begriffe „auf der Grundlage von”, „abhängig von”, „gemäß”, „als Funktion von” (sowie sämtliche Formen derselben) sollten als eine nicht ausschließliche Beziehung (d. h. unter Einschluss einer möglichen weiteren Variable) verstanden werden, und der Begriff „ein/eine/eines” sollte (soweit nicht ausdrücklich anderweitig genannt) als ein oder mehrere Objekte verstanden werden.
So stellt eine Ausführungsform der vorliegenden Erfindung z. B. ein Verfahren zum Instrumentieren einer Software-Anwendung für die Konfiguration derselben bereit. Das Verfahren weist die folgenden Schritte auf. Ein Quellcode der Software-Anwendung wird daraufhin untersucht, ob ein Hinweis auf einen Satz von (einem oder mehreren) Konfigurationsparametern gefunden wird, von denen ein jeder durch eine vordefinierte, nicht ausführbare Aussage kenntlich gemacht ist. Ein Satz von Instanzen eines vordefinierten Konfigurationsobjekts wird erzeugt, von denen eine jede einen entsprechenden der Konfigurationsparameter abbildet; das Konfigurationsobjekt ist so ausgelegt, dass es den entsprechenden Konfigurationsparameter verwaltet. Ein Satz von (einer oder mehreren) Konfigurationsschnittstellen wird erzeugt, um die Konfigurationsparameter zu bearbeiten; die Konfigurationsschnittstellen sind imstande, mit einer jeden Instanz des Konfigurationsobjekts zu interagieren, um den entsprechenden Konfigurationsparameter zu erhalten und zu setzen.
Ähnliche Überlegungen gelten jedoch, wenn dieselbe Lösung mit einem gleichwertigen Verfahren realisiert wird (indem ähnliche Schritte mit denselben Funktionen oder aber mehr Schritte oder Teile derselben verwendet, einige Schritte als nicht wesentlich betrachtet und daher weggelassen oder weitere optionale Schritte hinzugefügt werden); zudem können die Schritte in einer anderen Reihenfolge, gleichzeitig oder (zumindest teilweise) überlappend durchgeführt werden.
In jedem Fall ist dasselbe Verfahren, wie unten erläutert, auf jede beliebige Software-Anwendung und jeden beliebigen Konfigurationsparameter anwendbar, der durch eine beliebige nicht ausführbare Aussage kenntlich gemacht ist; entsprechend ist es möglich, Instanzen eines beliebigen Konfigurationsobjekts zu erzeugen und beliebige Konfigurationsschnittstellen zu erzeugen.
Bei einer Ausführungsform der Erfindung weist die Software-Anwendung einen Satz von (einer oder mehreren) Software-Komponenten auf, die so gestaltet sind, dass sie in einem Satz von (einem oder mehreren) Software-Containern eines Anwendungs-Servers ausgeführt werden; ein jeder Software-Container dient dazu, eine Schnittstelle zwischen den Software-Komponenten eines entsprechenden Typs und einer Software-Umgebung eines Datenverarbeitungs-Servers herzustellen. Die Schritte des Verfahrens werden als Reaktion darauf, dass die Software-Anwendung auf dem Datenverarbeitungs-Server bereitgestellt wird, unter Steuerung durch den Anwendungs-Server durchgeführt.
Dabei können sowohl die Komponenten als auch die Container jedoch einen beliebigen Typ aufweisen; in jedem Fall kann dasselbe Verfahren in einem beliebigen Kontext ausgeführt werden (z. B. wenn die Software-Anwendung kompiliert oder gepackt ist).
Bei einer Ausführungsform der Erfindung ist die Software-Anwendung eine JEE-Software-Anwendung und der Anwendungs-Server ein JEE-Anwendungs-Server; jede nicht ausführbare Aussage ist eine Annotation und jede Konfigurationsschnittstelle eine Web-Seite.
Dabei spricht jedoch nichts dagegen, dasselbe Verfahren auf ein beliebiges anderes Software-Schema (z. B. die ASP.NET-Technologie der Microsoft Corporation – Handelsmarken) anzuwenden; darüber hinaus können die Annotationen durch beliebige andere nicht ausführbare Aussagen (z. B. Kommentare) ersetzt werden, und/oder die Web-Seiten können durch beliebige andere Konfigurationsschnittstellen (sogar des Befehlszeilentyps) ersetzt werden.
Bei einer Ausführungsform der Erfindung weist der Anwendungs-Server eine Verwaltungskonsole zum Konfigurieren des Anwendungs-Servers und weiterer Konfigurationsparameter der Software-Anwendung auf (die in dem Anwendungs-Server vordefiniert sind); der Schritt des Erzeugens eines Satzes von Konfigurationsschnittstellen weist das Einbinden der Konfigurationsschnittstellen in die Verwaltungskonsole auf.
Allerdings wird die Möglichkeit, die Konfigurationsschnittstellen unabhängig von einer wie auch immer gearteten Verwaltungskonsole zu verwalten, nicht ausgeschlossen (z. B. wenn sie in dem Anwendungs-Server nicht verfügbar ist).
Bei einer Ausführungsform der Erfindung weist die Software-Anwendung eine Vielzahl von zweckbestimmten Exemplaren der Komponenten auf, welche die nicht ausführbaren Aussagen aufweisen; dabei erweitert mindestens eine der zweckbestimmten Komponenten eine andere der zweckbestimmten Komponenten. Der Schritt des Erzeugens eines Satzes von Konfigurationsschnittstellen weist das Erzeugen einer Vielzahl von Konfigurationsschnittstellen auf, wobei eine jede jeweils für die Konfigurationsparameter einer entsprechenden Komponente der zweckbestimmten Komponenten vorgesehen ist; dabei sind die Konfigurationsschnittstellen gemäß den Erweiterungen der zweckbestimmten Komponenten in einer hierarchischen Struktur angeordnet.
Allerdings spricht nichts dagegen, die Konfigurationsparameter auf eine beliebige andere Art und Weise anzuordnen (bis hin zu einer vollständig horizontalen Struktur, ja sogar mit einer einzigen Konfigurationsschnittstelle für alle Konfigurationsparameter); in jedem Fall können die Konfigurationsparameter an anderer Stelle in dem Quellcode der Software-Anwendung definiert sein (z. B. direkt in den Funktionskomponenten, wo sie verwendet werden).
Bei einer Ausführungsform der Erfindung weist der Schritt des Durchsuchens eines Quellcodes der Software-Anwendung des Weiteren das Durchsuchen des Quellcodes auf, um einen Satz von Konfigurationsparametern zu finden, von denen ein jeder durch eine weitere vordefinierte, nicht ausführbare Aussage kenntlich gemacht ist. Der Schritt des Erzeugens eines Satzes von Konfigurationsschnittstellen weist das Zusammenfassen der Konfigurationsparameter eines jeden Abschnitts in den Konfigurationsschnittstellen auf.
Die Abschnitte können jedoch auch auf eine beliebige andere Art und Weise definiert sein (z. B. durch entsprechende Attribute der nicht ausführbaren Aussagen, die Konfigurationsparameter angeben); in jedem Fall spricht nichts dagegen, alle Konfigurationsparameter ohne eine wie auch immer geartete Zusammenfassung derselben gleich zu behandeln.
Bei einer Ausführungsform der Erfindung liegen die Konfigurationsschnittstellen als Fensterformen vor; die Konfigurationsparameter eines jeden Abschnitts sind in einem entsprechenden Teilfenster der Fensterformen zusammengefasst.
Allerdings können die Abschnitte auch auf eine andere Art und Weise verwaltet werden (z. B. anhand von Rahmen, Aufklappfenstern und Ähnlichem).
Bei einer Ausführungsform der Erfindung weist der Schritt des Erzeugens eines Satzes von Konfigurationsschnittstellen das Zuordnen eines Satzes von (Null, einer oder mehreren) Validierungsregeln, die in der entsprechenden nicht ausführbaren Aussage angegeben sind, zu einem jeden Konfigurationsparameter in den Konfigurationsschnittstellen auf; die Konfigurationsschnittstellen sind imstande, als Reaktion auf ein Bearbeiten eines jeden Konfigurationsparameters ein vordefiniertes Validierungsverfahren aufzurufen, um den Konfigurationsparameter gemäß den zugehörigen Validierungsregeln (sofern vorhanden) zu validieren.
Dabei können die Validierungsregeln jedoch auch einen beliebigen Typ aufweisen (z. B. zulässige Werte aufführen) und in einer beliebigen Anzahl vorliegen (bis hin zum vollständigen Verzicht darauf).
Bei einer Ausführungsform der Erfindung beschränkt mindestens eine der Validierungsregeln den entsprechenden Konfigurationsparameter gemäß mindestens einem anderen der Konfigurationsparameter.
Die Konfigurationsparameter können jedoch auch auf eine beliebige andere Art und Weise beschränkt werden (z. B. gemäß Laufzeitmessungen).
Bei einer Ausführungsform der Erfindung weist der Schritt des Erzeugens eines Satzes von Instanzen eines vordefinierten Konfigurationsobjekts das Initialisieren einer jeden Instanz des Konfigurationsobjekts auf, um den entsprechenden Konfigurationsparameter in einer kalten Betriebsart oder in einer warmen Betriebsart auf die Software-Anwendung anzuwenden, wenn die entsprechende nicht ausführbare Aussage einen vordefinierten Anzeiger für eine kalte Betriebsart bzw. einen vordefinierten Anzeiger für eine warme Betriebsart aufweist.
Allerdings kann der Anzeiger für eine kalte/warme Betriebsart auch auf eine beliebige andere Art und Weise bereitgestellt werden (z. B. anhand weiterer Annotationen), oder es können andere Konfigurationsbetriebsarten der Software-Anwendung unterstützt werden (bis hin zu einer einzigen Betriebsart). Es besteht auch die Möglichkeit, für jeden benutzerdefinierten Konfigurationsparameter zusätzliche oder alternative Daten bereitzustellen (z. B. Regeln für das automatische Aktualisieren der Konfigurationsparameter gemäß Laufzeitmessungen wie Last oder Transaktionsdauer, um auf abnorme Bedingungen zu reagieren oder die Software-Anwendung entsprechend zu optimieren).
Bei einer Ausführungsform der Erfindung weist der Schritt des Initialisierens einer jeden Instanz des Konfigurationsobjekts das Initialisieren der Instanz des Konfigurationsobjekts für einen jeden Konfigurationsparameter auf, der in der warmen Betriebsart anzuwenden ist, um als Reaktion auf eine Aktualisierung des Konfigurationsparameters ein entsprechendes Anwendungsverfahren aufzurufen.
Dabei kann die Anwendung des Konfigurationsparameters in der warmen Betriebsart jedoch auch auf eine andere Art und Weise realisiert werden (z. B. mit Abrufverfahren).
Bei einer Ausführungsform der Erfindung kann der Schritt des Initialisierens der Instanz des Konfigurationsobjekts für jeden Konfigurationsparameter, der in der warmen Betriebsart anzuwenden ist, die folgenden Operationen aufweisen. Der Quellcode der Software-Anwendung wird untersucht, um das entsprechende Anwendungsverfahrenzu finden, die durch eine weitere vordefinierte, nicht ausführbare Aussage kenntlich gemacht ist, welche einen Bezeichner des Konfigurationsparameters aufweist; das Anwendungsverfahren ist der entsprechenden Instanz des Konfigurationsobjekts zugehörig.
Allerdings kann das Anwendungsverfahren auf eine beliebige Art und Weise dem entsprechenden Konfigurationsparameter zugehörig sein (z. B. direkt innerhalb seiner nicht ausführbaren Aussage).
Eine weitere Ausführungsform der vorliegenden Erfindung stellt ein Computerprogramm bereit, das Code-Mittel aufweist, um ein Datenverarbeitungssystem zu veranlassen, die Schritte des oben beschriebenen Verfahren durchzuführen, wenn das Computerprogramm auf dem Datenverarbeitungssystem ausgeführt wird.
Der Fachmann weiß, dass Aspekte der vorliegenden Erfindung als ein System, Verfahren oder Computerprogrammprodukt ausgeführt werden können. Entsprechend können Aspekte der vorliegenden Erfindung in Gestalt einer vollständig in Hardware realisierten Ausführungsform, einer vollständig in Software realisierten Ausführungsform (z. B. Firmware, residente Software, Mikrocode usw.) oder in Gestalt einer Ausführungsform vorliegen, die Software- und Hardware-Aspekte vereint, welche zusammenfassend als „Schaltung”, „Modul” oder „System” bezeichnet werden können. Des Weiteren können Aspekte der vorliegenden Erfindung in Gestalt eines Computerprogrammprodukts vorliegen, das in einem oder mehreren computerlesbaren Medien ausgeführt ist, auf denen computerlesbarer Programmcode enthalten ist. Dabei kann eine beliebige Kombination aus einem oder mehreren computerlesbaren Medien genutzt werden. Das computerlesbare Medium kann ein computerlesbares Signalmedium oder ein computerlesbares Speichermedium sein. Ein computerlesbares Speichermedium kann z. B. ein elektronisches, magnetisches, optisches, elektromagnetisches, Infrarot- oder Halbleitersystem bzw. eine entsprechende Vorrichtung oder Einheit oder aber eine beliebige geeignete Kombination der vorgenannten Elemente sein, ohne jedoch auf diese beschränkt zu sein. Konkretere Beispiele des computerlesbaren Speichermediums würden Folgendes aufweisen (wobei dies eine nicht vollständige Liste darstellt): eine elektrische Verbindung mit einem oder mehreren Leitern, eine tragbare Computerdiskette, eine Festplatte, einen Direktzugriffsspeicher (RAM), einen Festwertspeicher (ROM), einen löschbaren, programmierbaren Nur-Lese-Speicher (EPROM- oder Flash-Speicher), einen Lichtwellenleiter, eine tragbare CD-ROM, eine optische Speichereinheit, eine magnetische Speichereinheit oder eine beliebige geeignete Kombination der vorgenannten Elemente. In Verbindung mit diesem Dokument kann ein computerlesbares Speichermedium ein beliebiges physisches Medium sein, das ein Programm enthalten oder speichern kann, welches von oder im Zusammenhang mit einem der Befehlsausführung dienenden System, einer Vorrichtung oder Einheit verwendet wird. Ein computerlesbares Signalmedium kann ein weitergeleitetes Datensignal mit darin enthaltenem computerlesbarem Programmcode aufweisen, z. B. in einem Basisband oder als Teil einer Trägerwelle. Ein derartiges weitergeleitetes Signal kann eine beliebige Vielfalt von unterschiedlichen Formen annehmen, einschließlich, ohne auf diese beschränkt zu sein, eine elektromagnetische Form, eine optische Form oder auch jede geeignete Kombination derselben. Ein computerlesbares Signalmedium kann ein beliebiges computerlesbares Medium sein, das kein computerlesbares Speichermedium ist und das ein Programm übermitteln, weiterleiten oder übertragen kann, welches für die Nutzung durch oder in Verbindung mit einem/einer der Befehlsausführung dienenden System, Vorrichtung oder Einheit vorgesehen ist. Auf einem computerlesbaren Medium enthaltener Programmcode kann unter Verwendung eines beliebigen geeigneten Mediums übertragen werden, einschließlich, ohne auf diese beschränkt zu sein, drahtlose, drahtgebundene, Lichtwellenleiterkabel-, Funk- und andere Medien oder eine beliebige Kombination der vorgenannten Medien. Computerprogrammcode für das Ausführen von Arbeitsschritten für Aspekte der vorliegenden Erfindung kann in einer beliebigen Kombination von einer oder mehreren Programmiersprachen geschrieben sein, darunter eine objektorientierte Programmiersprache wie Java, Smalltalk, C++ oder ähnliche (Handelsmarken) sowie herkömmliche prozedurale Programmiersprachen wie die Programmiersprache „C” oder ähnliche Programmiersprachen. Der Programmcode kann vollständig auf dem Computer des Benutzers, teilweise auf dem Computer des Benutzers, als eigenständiges Softwarepaket, teilweise auf dem Computer des Benutzers und teilweise auf einem entfernt angeordneten Computer oder aber vollständig auf dem entfernt angeordneten Computer oder Server ausgeführt werden. Im letztgenannten Szenario kann der entfernt angeordnete Computer über eine beliebige Art von Netzwerk, darunter ein lokales Netz (LAN) oder ein Weitverkehrsnetz (WAN), mit dem Computer des Benutzers verbunden sein, oder die Verbindung kann mit einem externen Computer hergestellt werden (z. B. über das Internet unter Verwendung eines Internet-Dienstanbieters). Im Folgenden werden Aspekte der vorliegenden Erfindung unter Bezugnahme auf Darstellungen von Ablaufplänen und/oder Blockschaubilder von Verfahren, Vorrichtungen (Systemen) und Computerprogrammprodukten gemäß Ausführungsformen der Erfindung beschrieben. Dabei dürfte klar sein, dass jeder Block der Ablaufplan-Darstellungen und/oder Blockschaubilder sowie Kombinationen von Blöcken in den Ablaufplan-Darstellungen und/oder Blockschaubildern durch Computerprogrammbefehle realisiert werden kann/können. Diese Computerprogrammbefehle können einem Prozessor eines Universalcomputers, Spezialcomputers oder einer anderweitigen programmierbaren Datenverarbeitungsvorrichtung bereitgestellt werden, um eine Maschine zu erzeugen, so dass die Befehle, die über den Prozessor des Computers oder der anderweitigen programmierbaren Datenverarbeitungsvorrichtung ausgeführt werden, ein Mittel erzeugen, mit dem die Funktionen/Handlungen realisiert werden können, die in dem Block bzw. den Blöcken des Ablaufplans und/oder Blockschaubilds angegeben sind. Diese Computerprogrammbefehle können auch auf einem computerlesbaren Medium gespeichert werden, das einen Computer, eine anderweitige programmierbare Datenverarbeitungsvorrichtung oder andere Einheiten anweisen kann, auf eine bestimmte Art und Weise zu funktionieren, so dass die auf dem computerlesbaren Medium gespeicherten Befehle einen Gegenstand hervorbringen, der Befehle aufweist, mit denen die in dem Block bzw. den Blöcken des Ablaufplans und/oder Blockschaubilds angegebene Funktion/Handlung realisiert wird. Die Computerprogrammbefehle können zudem in einen Computer, eine anderweitige programmierbare Datenverarbeitungsvorrichtung oder andere Einheiten geladen werden, um zu veranlassen, dass eine Reihe von Betriebsschritten auf dem Computer, der anderweitigen programmierbaren Datenvorrichtung oder den anderen Einheiten ausgeführt wird, so dass die Befehle, die auf dem Computer oder der anderweitigen Datenverarbeitungsvorrichtung ausgeführt werden, Prozesse bereitstellen, mit denen die in dem Block bzw. den Blöcken des Ablaufplans und/oder Blockschaubilds angegebenen Funktionen/Handlungen realisiert werden.
Eine weitere Ausführungsform der vorliegenden Erfindung stellt ein System bereit, das Mittel für das Durchführen der Schritte desselben Verfahrens aufweist.
Dabei gelten jedoch ähnliche Überlegungen, falls das System eine andere Struktur oder gleichwertige Einheiten oder anderslautende Betriebsmerkmale aufweist. In jedem Fall kann eine jede Einheit desselben in mehr Elemente unterteilt werden, oder zwei oder mehr Einheiten können zu einem einzigen Element kombiniert werden; darüber hinaus kann jede Einheit vervielfacht werden, um die parallele Ausführung der entsprechenden Arbeitsschritte zu ermöglichen. Es wird außerdem darauf verwiesen, dass (sofern nicht anderweitig angegeben) eine beliebige Interaktion zwischen verschiedenen Einheiten im Allgemeinen nicht fortlaufend sein muss und dass sie entweder direkt oder – über eine oder mehrere zwischengeschaltete Einheiten – indirekt erfolgen kann. In jedem Fall kann das System (z. B. der Server) eine andere Struktur oder ähnliche Elemente aufweisen (z. B. Cachespeicher, welche die Programme oder Teile derselben vorübergehend speichern); zudem ist es möglich, den Server durch eine beliebige, entweder auf einer physischen oder einer virtuellen Maschine beruhende Code-Ausführungseinheit oder durch eine Kombination mehrerer Einheit zu ersetzen (z. B. eine mehrschichtige Architektur, eine Grid-Computing-Infrastruktur und Ähnliches). Allgemeiner gesprochen, kann dasselbe Verfahren auch in einem System auf der Grundlage einer anderen Architektur (z. B. einem Nahbereichs-, Weitverkehrs-, weltweiten, Funk- oder satellitengestützten Netz) durchgeführt werden und jeden beliebigen Typ von (drahtgebunden und/oder drahtlosen) Verbindungen nutzen. Dabei wird seine Realisierung als ein eigenständiger Computer (der sowohl die Server als auch die Clients realisiert) jedoch nicht ausgeschlossen.
ZITATE ENTHALTEN IN DER BESCHREIBUNG
Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
Zitierte Patentliteratur

US 6691138 A [0003]
US 7607126 B [0007]

Zitierte Nicht-Patentliteratur

„Behind the Scenes of J2EETM Deployment” von Elizabeth Hatfield, Daniel Edwin und Tom Kincaid [0006]
„Deploying and Customizing J2EE Applications Guide for Oracle Siebel eStatement Manager” von Oracle” [0006]
https://issues.jboss.org/browse/JGRP-723 [0008]

Claims

Verfahren (400) zum Instrumentieren einer auf einem Anwendungs-Server ausgeführten Software-Anwendung, um die Konfiguration derselben an eine zentrale Konfigurationsverwalter-Software-Anwendung auszulagern, wobei das Verfahren die Schritte aufweist des: Durchsuchens (409, 424, 433) eines Quellcodes der Software-Anwendung durch das Anwendungsverwaltungsprogramm, um einen Hinweis auf einen Satz von Konfigurationsparametern zu finden, von denen ein jeder durch eine vordefinierte, nicht ausführbare Aussage kenntlich gemacht ist, Erzeugens (436 bis 454) eines Satzes von Instanzen eines vordefinierten Konfigurationsobjekts, von denen eine jede einen entsprechenden der Konfigurationsparameter abbildet, wobei das Konfigurationsobjekt so ausgelegt ist, dass es den entsprechenden Konfigurationsparameter verwaltet, und Erzeugens (412 bis 430, 457 bis 463) eines Satzes von Konfigurationsschnittstellen zum Bearbeiten der Konfigurationsparameter, wobei die Konfigurationsschnittstellen imstande sind, mit einer jeden Instanz des Konfigurationsobjekts zu interagieren, um den entsprechenden Konfigurationsparameter zu erhalten und zu setzen.
Verfahren (400) nach Anspruch 1, wobei die Software-Anwendung (320) einen Satz von Software-Komponenten (325) aufweist, die so gestaltet sind, dass sie in einem Satz von Software-Containern (270, 275) eines Anwendungs-Servers (305) ausgeführt werden, wobei ein jeder dazu dient, eine Schnittstelle zwischen den Software-Komponenten eines entsprechenden Typs und einer Software-Umgebung eines Datenverarbeitungs-Servers (105j) herzustellen, wobei die Schritte des Verfahrens als Reaktion auf eine Bereitstellung der Software-Anwendung auf dem Datenverarbeitungs-Server unter der Steuerung durch den Anwendungs-Server durchgeführt werden.
Verfahren (400) nach Anspruch 2, wobei die Software-Anwendung (320) eine JEE-Software-Anwendung und der Anwendungs-Server (305) ein JEE-Anwendungs-Sever ist, wobei jede nicht ausführbare Aussage eine Annotation und jede Konfigurationsschnittstelle eine Web-Seite ist.
Verfahren (400) nach Anspruch 2 oder 3, wobei der Anwendungs-Server (305) eine Verwaltungskonsole (315) zum Konfigurieren des Anwendungs-Servers und weiterer Konfigurationsparameter der Software-Anwendung (320) aufweist, die in dem Anwendungs-Server vordefiniert sind, wobei der Schritt des Erzeugens (412 bis 430, 457 bis 463) eines Satzes von Konfigurationsschnittstellen aufweist: Einbinden (415) der Konfigurationsschnittstellen in die Verwaltungskonsole.
Verfahren (400) nach einem beliebigen Anspruch 2 bis 4, wobei die Software-Anwendung (320) eine Vielzahl von zweckbestimmten Exemplaren der Komponenten (335) aufweist, welche die nicht ausführbaren Aussagen aufweisen, wobei mindestens eine der zweckbestimmten Komponenten eine andere der zweckbestimmten Komponenten erweitert, wobei der Schritt des Erzeugens (412 bis 430, 457 bis 463) eines Satzes von Konfigurationsschnittstellen aufweist: Erzeugen (415 bis 421) einer Vielzahl von Konfigurationsschnittstellen, wobei eine jede jeweils für die Konfigurationsparameter einer entsprechenden Komponente der zweckbestimmten Komponenten vorgesehen ist, wobei die Konfigurationsschnittstellen gemäß den Erweiterungen der zweckbestimmten Komponenten in einer hierarchischen Struktur angeordnet sind.
Verfahren (400) nach einem beliebigen Anspruch 1 bis 5, wobei der Schritt des Durchsuchens (409, 424, 433) eines Quellcodes der Software-Anwendung weiterhin aufweist: Durchsuchen (409, 424) des Quellcodes, um einen Satz von Abschnitten von Konfigurationsparametern zu finden, von denen ein jeder durch eine weitere vordefinierte, nicht ausführbare Aussage kenntlich gemacht ist, und wobei der Schritt des Erzeugens (412 bis 430, 457 bis 463) eines Satzes von Konfigurationsschnittstellen aufweist: Zusammenfassen (427 bis 430, 460) der Konfigurationsparameter eines jeden Abschnittes in Konfigurationsschnittstellen.
Verfahren (400) nach Anspruch 6, wobei die Konfigurationsschnittstellen als Fensterformen vorliegen, wobei die Konfigurationsparameter eines jeden Abschnitts in einem entsprechenden Teilfenster der Fensterformen zusammengefasst sind.
Verfahren (400) nach einem beliebigen Anspruch 1 bis 7, wobei der Schritt des Erzeugens (412 bis 430, 457 bis 463) eines Satzes von Konfigurationsschnittstellen aufweist: Zuordnen (460–463) eines Satzes von Validierungsregeln, die in der entsprechenden nicht ausführbaren Aussage angegeben sind, zu einem jeden Konfigurationsparameter in den Konfigurationsschnittstellen, wobei die Konfigurationsschnittstellen imstande sind, als Reaktion auf ein Bearbeiten eines jeden Konfigurationsparameters ein vordefiniertes Validierungsverfahren aufzurufen, um den Konfigurationsparameter gemäß den zugehörigen Validierungsregeln zu validieren.
Verfahren (400) nach Anspruch 8, wobei mindestens eine der Validierungsregeln den entsprechenden Konfigurationsparameter gemäß mindestens einem anderen der Konfigurationsparameter beschränkt.
Verfahren (400) nach einem beliebigen Anspruch 1 bis 9, wobei der Schritt des Erzeugens (436 bis 454) eines Satzes von Instanzen eines vordefinierten Konfigurationsobjekts aufweist: Initialisieren (439 bis 454) einer jeden Instanz des Konfigurationsobjekts, um den entsprechenden Konfigurationsparameter in einer kalten Betriebsart oder in einer warmen Betriebsart auf die Software-Anwendung anzuwenden, wenn die entsprechende nicht ausführbare Aussage einen vordefinierten Anzeiger für eine kalte Betriebsart bzw. einen vordefinierten Anzeiger für eine warme Betriebsart aufweist.
Verfahren (400) nach Anspruch 10, wobei der Schritt des Initialisierens (439 bis 454) einer jeden Instanz des Konfigurationsobjekts aufweist: Initialisieren (451 bis 454) der Instanz des Konfigurationsobjekts für einen jeden Konfigurationsparameter, der in der warmen Betriebsart anzuwenden ist, um als Reaktion auf eine Aktualisierung des Konfigurationsparameters ein entsprechendes Anwendungsverfahren aufzurufen.
Verfahren (400) nach Anspruch 11, wobei der Schritt des Initialisierens (451 bis 454) der Instanz des Konfigurationsobjekts für einen jeden in der warmen Betriebsart anzuwendenden Konfigurationsparameter aufweist: Durchsuchen (451) des Quellcodes der Software-Anwendung, um das entsprechende Anwendungsverfahren zu finden, die durch eine weitere vordefinierte, nicht ausführbare Aussage kenntlich gemacht ist, welche einen Bezeichner des Konfigurationsparameters aufweist, und Zuordnen (454) des Anwendungsverfahrens zu der entsprechenden Instanz des Konfigurationsobjekts.
Computerprogramm (305), das ein Code-Mittel aufweist, um ein Datenverarbeitungssystem (105j) zu veranlassen, die Schritte des Verfahrens (400) nach einem beliebigen Anspruch 1 bis 12 durchzuführen, wenn das Computerprogramm auf dem Datenverarbeitungssystem ausgeführt wird.
System (105j), das Mittel (305) aufweist, um die Schritte des Verfahrens (400) nach einem beliebigen Anspruch 1 bis 12 durchzuführen.