DE10129147B4

DE10129147B4 - Verfahren und Datenverarbeitungs-System zum Entwicklen von Software im Internet-, Netzwerk- und/oder Anwendungssoftware-Bereich für einen Webserver

Info

Publication number: DE10129147B4
Application number: DE10129147A
Authority: DE
Inventors: Michael Remme
Original assignee: BRAINTAGS GmbH
Current assignee: Braintags De GmbH
Priority date: 2001-06-16
Filing date: 2001-06-16
Publication date: 2007-11-15
Anticipated expiration: 2021-06-17
Also published as: DE10129147A1

Abstract

Verfahren zum Entwickeln von Software im Internet-, Netzwerk- und/oder Anwendungssoftware-Bereich für einen Webserver, mit der Datenbanken vom Webserver aus gesteuert werden, dadurch gekennzeichnet, dass ein unter Verwendung von Befehlen der Programmiersprache Java programmierbares Software-Tool eine Schnittstelle bildet, die alle angebundenen, ggfs. unterschiedlichen Datenbanken mit denselben Befehlen anspricht und alle angebundenen, ggfs. unterschiedlichen Datenbanken ein datenbankneutrales Ergebnis zurückliefern und dass in der Software Automatismen verwendet werden, die die Entwicklung beliebiger, internetbasierender Software-Applikationen teilautomatisieren.

Description

Die Erfindung betrifft ein Verfahren zum Entwickeln von Software im Internet-, Netzwerk und/oder Anwendungssoftware-Bereich für einen Webserver, mit der Datenbanken vom Webserver aus gesteuert werden.
Der Programmieraufwand für Datenverarbeitungsprogramme, wie z.B. für dynamische Internet-Applikationen und andere Programme ist derzeit sehr hoch. Der damit verbundene Personal- und Zeitaufwand und die demzufolge entstehenden Kosten entsprechen dem hohen Programmieraufwand und der hohen Qualifikation des Personals. Die hohe Qualifikation der Programmierer, ihre Ausbildungszeit und der Ausbildungsstand, die für verschiedene Branchen nicht zur Verfügung stehen, sind verantwortlich für staatliche Maßnahmen, aus anderen Staaten Personal anzuwerben, um hier Arbeitskapazität zu schaffen. Im allgemeinen muss davon ausgegangen werden, dass ein Programmierer nicht alle Programmiersprachen beherrscht, wie z.B. C++, Tel/Tk, Perl, Lips, Phyton, Postscript, HTML, T_EX, Ada, Fortran, Pascal, Java, Basic, Cobol u.a. Sprachen. Dabei ist auch die jeweilige Tätigkeit in einer Branche für ein ausgewähltes Arbeitsgebiet und ein besonderes Anwendungsgebiet zu berücksichtigen. Für grafische Programmierung mit textuellen Ergänzungen stellt außerdem z.B. LabView eine spezielle Programmiersprache dar.
Der Programmierer hat außerdem das jeweilige Betriebssystem, den Compiler, einen Interpreter, einen Emulator und eine Virtual Machine zu berücksichtigen. Für die Ausführbarkeit von Programmen kommen zusätzlich der Prozessortyp der CPU, das Betriebssystem und Programme für wiederkehrende Schritte in Betracht. Neben den diversen Programmiersprachen muss der Entwickler sich zusätzlich noch mit den Eigenheiten der anzubindenden Datenbank auskennen. Dabei hat er die Eigenschaften der Datenbanken, ob SQL oder nicht SQL und unterschiedliche SQL-Dialekte zu berücksichtigen.
Es ist ein Verfahren, ein System und ein Computerprogramm zum Erzeugen von Dokumenteninhalten durch Transcodierung mit Hilfe von Java Server Pages bekannt ( DE 100 48 940 A1 ), die es ermöglichen, aufgrund der Java Server Pages den Inhalt eines von einem Client angeforderten Dokuments zu transcodieren, um das Ausgabedokument gemäß anwendungsspezifischer Merkmale anzupassen. Diese anwendungsspezifischen Merkmale bestehen darin, dass eine Transcodierungsdirektive ein oder mehrere überschreibende Schlüsselwort/Wert-Paare enthält, die dem Ersetzen geänderter Schlüsselwort/Wert-Paare dient und zum Erzeugen einer angepassten Ausgabeversion des Eingabedokumentes verwendet wird. Dieses Verfahren kann jedoch durch ein oder mehrere andere Verfahren ersetzt werden, die noch weiter Programmierarbeit einsparen und leicht anwendbar sind, ohne besondere Kenntnisse der Programmiersprache Java zu besitzen.
Aus Huiwei Guan, Horace H. S. Ip, Yanchun Zhang: "Java-based approaches for accessing databases on the Internet and a JDBC-ODBC implementation"; Dept. of Comput. Eng., Shanghai (niv.; Computing & Control Engineering Journal, Pages 71–78, April 1998) ist eine weitergehende Entwicklung bekannt, eine allgemeine Software oder ein Tool zu entwickeln. Dadurch ist dieser Vorschlag auf ein Beispiel für die Anwender-Software beschränkt und beinhaltet nicht, den Programmierer auf eine höhere Stufe der Programm-Entwicklung zu stellen. Es ist somit auch kein Verfahren zum Entwickeln von Software für einen Webserver bekannt. Außerdem beschreibt die vorstehende Literaturstelle nicht ein System aus Software-Tools, das Schnittstellen generiert. Es werden jedoch allgemein Anregungen zur Entwicklung von Software-Tools gegeben, ohne auszuführen, welcher Natur diese sein sollen. Das Programm Java Database Connectivity kann danach ein von der Datenbank unabhängiges Netzprotokoll erstellen, das dann in einem zur Datenbank spezifischen Protokoll durch einen Mittelstufen-Server übersetzt werden würde. Dabei entstehen Nachteile für eine besprochene Übersetzung von JDBC in ODBC. Dabei wird davon ausgegangen, dass JDBC für Tools und Datenbank-Entwickler günstig sei und dass diese dem Programm-Schreiben von Datenbank-Anwendungen diene.
Der Erfindung liegt demgegenüber die Aufgabe zugrunde, das Programmieren von Software unabhängig von einem Servertyp bzw. von einem Betriebssystem und unabhängig von einem Datenbanksystem für alle Medien zu vereinfachen und dadurch weitergehend Programmierzeit und Ausbildungsaufwand der Programmierer einzusparen.
Die gestellte Aufgabe wird erfindungsgemäß dadurch gelöst, dass ein unter Verwendung von Befehlen der Programmiersprache Java programmiertes Software-Tool eine Schnittstelle bildet, die alle angebundenen, ggfs. unterschiedlichen Datenbanken mit denselben Befehlen anspricht und alle angebundenen, ggfs. unterschiedlichen Datenbanken ein datenbankneutrales Ergebnis zurückliefern und dass in der Software Automatismen verwendet werden, die die Entwicklung beliebiger, internetbasierter Software-Applikationen teilautomatisieren. Die Schnittstellen für die unterschiedlichsten Datenbanken werden ein einziges Mal umgesetzt, wobei in dieser Umsetzung die datenbankeigenen Vorgänge und Dialekte angewendet werden. Nach außen hin werden nur die Methoden angewendet, die durch eine vordefinierte Schnittstelle angeboten werden. Dieses Verfahren bedeutet, dass sich der Entwickler nicht mehr mit den internen Datenbankabläufen beschäftigen muss, sondern dass er die Datenbank einfach als Speichermedium benutzt. Außerdem ist das Austauschen einer Datenbank gegen eine andere möglich, indem eine einzige Voreinstellung des Software-Tools geändert wird und nicht der gesamte Code der Programmierung geändert werden muss. Es ergeben sich Vorteile neben der Möglichkeit einer dynamischen Abbildung von Datenbankinhalten aller Medien. Die Datenbank- und Plattformunabhängigkeit der Software ist ein wesentlicher Vorteil. Darüber hinaus liegt ein wesentliches Merkmal darin, dass in der Software Automatismen enthalten sind, die die Entwicklung beliebiger, internetbasierter Software-Applikationen teilautomatisieren. Der Programmieraufwand für z.B. dynamische Internet-Applikationen wird um ca. 80–90% gegenüber klassischer Software-Entwicklung gesenkt. Das Software-Tool setzt auf jeder Serverplattform bzw. auf jedem Betriebssystem, das von Java unterstützt wird, auf. Es ist damit unabhängig davon, ob eines der Betriebssysteme Linux, Unix, Windows NT oder Apple Macintosh verwendet wird. Dabei ist das Software-Tool in der Lage, jeden auf dem Markt befindlichen Datenbanktyp anzusteuern, wobei es keine Rolle spielt, ob die Datenbank SQL-fähig ist. Dieser Vorteil gilt z.B. für Oracle, Interbase, Microsoft-SQL oder Access. Die Anwendung des Software-Tools ist z.B. bei Webservern des Typs Apache oder Microsoft möglich. Da das Software-Tool in der Lage ist, jede Form einer Benutzer-Anfrage umzusetzen, kann jegliche eBusiness-Applikation, die Interaktionen zwischen User und dynamischen Datenbankinhalten benötigen, verwirklicht werden. Als Beispiele sind Shop-Systeme, Auktionsplattformen, Portale, Virtuelle Marktplätze, Kunden/Lieferanten-Extranets, Intranet-Applikationen u. dgl. zu nennen. Es sind auch keine Kenntnisse anderer Programmiersprachen erforderlich. Allenfalls genügen Grundkenntnisse in HTML und ein oberflächliches Wissen um Datenbanken. Die Einsatzmöglichkeiten des Software-Tools sind dabei unbegrenzt. Die Einsatzmöglichkeiten ergeben sich aus den tatsächlichen Bedürfnissen der Unternehmen, die aus unternehmensinternen oder – externen Transaktionsprozessen, Kommunikationsprozessen, Distributionsprozessen oder Informationsprozessen bestehen können. Das Einsatzgebiet ist sowohl bran chen- als auch prozessunabhängig. Ein Benutzer wird in die Lage versetzt, internetbasierte Software-Applikationen zu entwickeln, die die Datenbankinhalte im Kern darstellen.
Weitere Vorteile ergeben sich daraus, dass das Software-Tool zu 100% in der Programmiersprache Java programmiert wird. Die Programmiersprache Java arbeitet, wie in der Fachwelt anerkannt ist, objektorientiert, erzeugt Byte-Codes unabhängig von der jeweiligen Plattform, ist architekturneutral und portabel, ist dynamisch und gilt als „verteilte" Sprache, wobei lokale und entfernte Dateien gleichermaßen gelesen werden können. Java arbeitet mit einfachen Sprachkonstrukten und ist robust und gilt als sicher. Java ist hochleistungsfähig und Multithread-fähig.
Vorteilhaft ist weiterhin, dass die entwickelten Software-Applikationen on-line im Webserver generiert werden. Ein ausgewählter Webserver, der mit dem Software-Tool ausgerüstet ist, kann daher auch aus der Entfernung gesteuert werden.
Eine besonders hervorzuhebende Anwendungsmöglichkeit ergibt sich dadurch, dass zum Erzeugen einer datenbankgebundenen eBusiness-Applikation alle Verbindungen zwischen dem Anwender, dem Webserver und einer beliebigen Datenbank strukturiert und definiert werden.
Nach weiteren Schritten wird derart vorgegangen, dass während der Initialisierung die Verbindung zu der jeweiligen Datenbank aufgebaut und innerhalb von Verbindungs-Pools gespeichert wird.
Dabei ist weiter vorteilhaft, dass die Verbindung zu den Datenbanken über Präferenzen und Klassen (es sind die Klassen des Software-Tools, des BasicDbServlet, von Command-Modulen, von Templates, von Scriptlanguage, für den Schutz der Templates sowie von Tags und von HTML-Templates vorteilhaft) aufgebaut wird.
Weiterhin besteht ein bedeutender Schritt darin, dass für jeden Aufruf ein Objekt der Klasse HTTP_Info erzeugt wird, in dem alle Informationen abgelegt werden, die im Lauf der Abarbeitung einer Anfrage gesammelt werden.
Sodann ist vorgesehen, dass über die Klassen jeweils ein Interface-SoftwareTool.dB.Beans.DB.Gateway implementiert wird.
Ein weiterer Schritt besteht darin, dass ankommende Anrufe über das Interface in funktionale Blöcke unterteilt werden, die über den Parameter "command" genutzt werden.
Nach weiteren Merkmalen wird vorgeschlagen, dass das Software-Tool zumindest mehrere Module aus jeweils einer Logik „Insert", „Update", „Delete", "Duplicate" oder „Display" dynamisch abgreift.
Ein weiterer Vorteil ergibt sich dadurch, dass die Logiken im Software-Tool vorprogrammiert werden. Diese vorprogrammierten Logiken machen es dem Nutzer möglich, jeden von ihm gewünschten Geschäftsprozess oder eine eBusiness-Funktionalität, ohne Programmierungskenntnisse umzusetzen.
Dabei können die Logiken im Software-Tool bis zu 90% vorprogrammiert werden. Dadurch wird ein Programmieraufwand bis zu 90% des gesamten Programmieraufwandes eines jeden eBusiness-Projektes abgedeckt.
Dabei ist es weiter vorteilhaft, dass der nicht vorprogrammierte Restteil der Logiken durch die Anwendung von HTML erstellt wird.
Weiterhin wird vorgeschlagen, dass das Software-Tool modulare Funktionen in Servlet-Technologie und XML als Dokumentenformat verwendet. Die Servlets sind auf Java beruhende Programme, die die Funktionalität von Webservern erweitern. Sie werden eingesetzt, um spezifische Geschäftsprozesse, für deren Umsetzung ein normaler Webserver nicht geeignet ist, umzusetzen.
Die Servlets werden, meist in Verbindung mit einer oder mehreren Datenbanken, als Module in den Webserver integriert, die über eine Schnittstelle mit dem Webserver kommunizieren. Für den Fall, dass ein Servlet durch einen Seiten-Aufruf angefordert wird, erhält es vom Webserver alle Informationen der Anforderung, wertet diese aus, erzeugt eine Antwort (derzeit als http/HTML) und reicht diese über die Schnittstelle an den Webserver zurück. Die Antwort kann eine komplette HTML-Seite, eine Fehlermeldung o. dgl. sein.
In Ausgestaltung ist vorgesehen, dass Aufrufe durch den Webserver an das Software-Tool gerichtet werden, die die zur Bearbeitung erforderlichen Informationen erfassen. Die Informationen stellen z.B. die Art des Datenbankaufrufs dar (insert/delete/update/duplicate/display). Dabei führt das Software-Tool eine Reihe von Standardaufgaben durch, bei denen es unter anderem automatisch das aktuelle Objekt aus einem Datensatz der Datenbank erzeugt. Der Aufruf wird in Abhängigkeit von der Art des Datenbankaufrufs an einer der vier Logikmodule (display-, update-, insert- oder delete-Modul) weitergereicht. Diese Module führen gleichermaßen automatisch ausgewählte Aufgaben durch, sofern dieser Vorgang gestartet wird. Das delete-Modul kann z.B. vollautomatisch ein oder mehrere Objekte aus der Datenbank löschen, das insert- und das update-Modul können automatisch einen neuen Datensatz in der Datenbank anlegen oder einen bestehenden aktualisieren, wobei z.B. auf die Angaben in einer HTML-Eingabeform zurückgegriffen wird. Das Ergebnis der Aktion des Display-Moduls ist eine HTML-Seite, XML-Seite oder eine Fehlermeldung in http.
Weiters ist vorgesehen, dass zur Erzeugung einer HTML-Seite Templates verwendet werden, die in einer verbundenen Datenbank gespeichert werden.
Nach anderen Merkmalen ist vorgesehen, dass die Templates in XML gesichert und durch einen Java-XML-Parser bearbeitet werden.
Dabei kann aufgrund der Templates in einer Datenbank eine Auswahl erzeugt werden. Die Auswahl kann z.B. über eine query (Suche) erfolgen.
Aufgrund der Templates können nach anderen Merkmalen in einer Datenbank Datensätze erzeugt, gelöscht, geändert und/oder abgebildet werden.
Eine andere Ausgestaltung besteht darin, dass aufgrund der Templates ein dynamischer HTML-Table erzeugt wird.
Für die „Tags" (Servlets) existiert eine offene und dokumentierte Schnittstelle, mit der es dem Java-Entwickler schnell möglich ist, eigene „Tags" zu entwickeln.
Nach anderen Merkmalen wird vorgeschlagen, dass die Bearbeitung der Templates und/oder der Servlets unmittelbar on-line in vorprogrammierte HTML-Editiermasken durchgeführt wird. Dieser Vorgang wird bei berechtigtem Zugriff ausgeführt.
Trotzdem die speziellen „Tags" in der Formulierung so einfach wie möglich gehalten sind, bedeutet dies doch, dass nicht jeder ein Template erzeugen kann. Es ist jedoch möglich, dass die Templates aufgrund eines WYSIWYG-Editors erzeugt werden (WYSIWYG = what you see is what you get).
Eine Weiterentwicklung besteht darin, dass die Templates aufgrund eines Java-Applets als Editor erzeugt werden. Dadurch können Änderungen on-line durchgeführt werden. Zusätzlich werden Möglichkeiten der Programmbenutzung zu einem echten WYSIWYG-Editor führen, der es auch einem nicht weiter ausgebildeten Anwender gestattet, sehr komplexe eBusiness-Projekte zu verwirklichen.
Schließlich besteht eine Ausgestaltung darin, dass die Templates aufgrund einer grafischen WYSIWYG-Editierebene erzeugt werden.
Ein anderer Schritt besteht darin, dass Veränderungen der Inhalte von HTTP_Info durch erweiternde Programmierungen, die auf die Verarbeitung der aktuellen Anfrage Einfluss nehmen, vorgenommen werden.
Weiter ist vorgesehen, dass der erste Client, der im SoftwareTool angelegt wurde, als Super-Client geführt wird.
In untergeordneter Folge kann auch dahingehend eine Hierarchie aufgebaut werden, dass anstelle des Super-Clients ein oder mehrere Super-Administratoren eingesetzt werden, die die Rechte des Super-Client für den Zugriff auf das System ausüben.
Dabei ist noch vorgesehen, dass für den Super-Client und/oder für den Super-Administrator das Passwort "super" eingeführt wird.
Eine andere Ausgestaltung der Erfindung besteht darin, dass als Klassen "software-Tool.dB.servlet.BasicDbServlet" zur Auswahl von Datenbanktabellen und zur Kommunikation mit Java-Klassen, ferner Command-Module, ferner Template-Module, ferner Scriptlanguage-Module, ferner Sicherheits-Module und HTML-Template-Module vorgesehen werden.
Eine andere Ausgestaltung sieht vor, dass die Existenz eines Clients zumindest über ein "Member", "Super", "Superadministrator" oder verschiedene HTML-Templates festgelegt wird.
Ein anderer Schritt besteht darin, dass über das Modul "Scriptlanguage" Inhalte in eine Website eingefügt werden.
Der Aspekt der Datensicherung wird zunächst dadurch berücksichtigt, dass zum Schutz der Templates und zum Schutz der Tags ein Online-Template-Editor, ein Table-Generator und je ein Bereich für die Client- und Member-Verwaltung eingegeben werden.
Eine andere Einzelheit ist darin zu sehen, dass die Command-Module aus dem Software-Tool-Package abgeleitet werden und zum Einwirken auf die Inhalte des übergebenen HTTP_Info verwendet werden.
Vorteilhaft ist auch der Schritt, dass die Templates als Datensätze in einer angeschlossenen Stammdatenbank gespeichert werden und dass das Ergebnis als eine HTML-Seite, ein XML, ein anders geartetes Dokument oder eine Datei dargestellt wird.
Dabei wird weiter vorgeschlagen, dass die Templates entweder im Zustand des Editor-Views oder des Runtime-Views eingesetzt werden.
Schließlich besteht ein Schritt des Verfahrens darin, dass das Template als dynamische HTML-Seite mit austauschbaren Detail-Elementen geführt wird.
Das zugehörige Datenverarbeitungs-System mit verkabelten oder über Funk verbundenen Clients, wie z.B. an Netzwerke angeschlossenen Clients und mit einem Webserver und unabhängigen Datenbanken ist dahingehend gestaltet, dass der Webserver mittels datenbankgestützten Webseiten über ein zwischen dem Webserver und den Datenbanken angeordneten Software-Tool, das Schnittstellen bildet, belieferbar ist.
Dabei ist noch vorteilhaft, dass das Software-Tool alle Verbindungen zwischen einem Client, den Webseiten und beliebigen Datenbanken strukturiert und definiert.
Ein weiterer Vorteil des Datenverarbeitungs-Systems besteht darin, dass auf dem Ortsfernen Webserver das Software-Tool Schnittstellen zu den Datenbanken schaltet.
In der Zeichnung sind Ausführungsbeispiele der Erfindung dargestellt, die nachstehend näher erläutert werden.
Es zeigen:
1 eine Blockdarstellung des Webservers mit Software-Tool und in der Peripherie befindlichen Datenbanken,
2 ein schematisches Flussdiagramm einer Verarbeitung einer Client-Anfrage,
3 ein Flussdiagramm des Software-Tools für die Initiierungsphase,
4 ein Flussdiagramnm für die Untersuchung der Anfrage,
5 ein Flussdiagramm für das Insert-Modul,
6 ein Flussdiagramm für den Ablauf in einem Update-Modul,
7 ein Flussdiagramm für den Ablauf in einem Delete-Modul,
8 ein Flussdiagramm für den Ablauf in einem Duplicate-Modul,
9 ein Flussdiagramm für den Ablauf in einem Display-Modul und
10 ein Datenverarbeitungs-System in Blockdarstellung.
Das dargestellte und beschriebene Verfahren dient dem Zweck, übernommen von dbServlet, ein programmiertechnisches Fundament für die Erzeugung jeglicher datenbankgestützter Online-Applikationen zu schaffen. Dieses Fundament strukturiert und definiert alle Verbindungen zwischen einem Client, einem Webserver und einer beliebigen Datenbank. In erster Linie sollen datenbankgebundene eBusiness-Applikationen geschaffen werden. Nach einer vollzogenen ersten Verbindung können viele Vorgänge, die üblicherweise immer wieder erneut programmiert werden müssten, automatisiert werden. Im wesentlichen werden diese Vorgänge aus dbServlet entnommen und weitere Vorgänge hinzugefügt, wobei unter anderem die in dbServlet vorgesehene Trennung von Logik und Präsentation zu 100% umgesetzt wird. Eine Vermischung von Java- und HTML-/XML-Codes findet nicht statt.
Im wesentlichen ist dbServlet aus sechs verschiedenen Klassen gebildet: Auf einem (ortsfernen) Webserver 1 wird ein Software-Tool 2 installiert, das Schnittstellen zu Datenbanken 3 und/oder 4 schaltet (1).

1. Das BasicdbServlet erweitert javax.servlet.http.HttpServlet. Während der Initialisierung werden die Verbindungen zu den Datenbanken 3 oder 4 aufgebaut und innerhalb von Connection-Pools gespeichert. Die Verbindung wird über Präferenzen gesteuert und über noch zu beschreibende Klassen aufgebaut, die das Interface SoftwareTool.db.Beans.DB.Gateway implementieren. Zur Laufzeit erhält BasicDBServlet jeden Aufruf und ermittelt technische Basisdaten, wie z.B. die laufende Session, Art des Seitenaufrufs, angeforderte Datenbankobjekte u. dgl. Für jeden Aufruf des BasicDBServlets wird ein Objekt der Klasse HTTP_Info erzeugt, in dem alle Informationen, die im Laufe der Abarbeitung einer Anfrage gesammelt werden, abgelegt werden. Während der Abarbeitung einer Anfrage wirft BasicDBServlet in den verschiedenen Stadien der Abarbeitung Events auf. Diese Events können von Programmierungen, die BasicDBServlet erweitern, abgefangen werden. Jeder Event beinhaltet das aktuelle HTTP_Info, sodass die erweiternden Programmierungen immer über den aktuellen Stand der laufenden Anfrage informiert und selbst in der Lage sind, den Zustand zu ändern. BasicDBServlet unterteilt ankommende Aufrufe in funktionale Blöcke, die über den Parameter "command" gesetzt werden. Es sind fünf verschiedene Commands vorgesehen: "insert", "update", "delete", "duplicate" und "display". Für den Fall, dass BasicDBServlet den entsprechenden Command nicht findet, wird au tomatisch ein display-command verwendet. Für die Verarbeitung der verschiedenen Commands sind die noch zu beschreibenden Module zuständig, die von BasicDBServlet aufgerufen werden und denen als Information das aktuelle HTTP_Info übergeben wird. Nachdem die aufgerufenen Module abgearbeitet sind, schickt BasicDBServlet eine Antwort an den Client zurück, deren Inhalt vom Zustand des aktuellen HTTP_Info abhängig ist. Die Antwort kann z.B. aus typischen HTML oder XML bestehen, eine komplette Datei beinhalten u. dgl..
2. Command-Module: Im Paket SoftwareTool.db.Servlet sind zumindest fünf Module enthalten, die für die Abarbeitung der verschiedenen Commands zuständig sind und von BasicDBServlet aufgerufen werden, wenn der Parameter "command" des aktuellen Aufrufes ihren Einsatz erfordert. Die Module sind, entsprechend der existierenden Commands als Display-Modul, insert-Modul, update-Modul, delete-Modul und duplicate-Modul bezeichnet. Bis auf das Display-Modul arbeiten alle Module automatisch, indem bestimmte Datensätze in der Datenbank angelegt, aktualisiert, gelöscht oder dupliziert werden, womit auf die Anforderungen eines Clients reagiert wird. Alle Module erzeugen in bestimmten Phasen der Abarbeitung verschiedene Events. Erweiternde Programmierungen können diese Events der Module abfangen und werden durch die Übergabe des aktuellen HTTP_Info über den kompletten Zustand des Systems informiert. Darüber hinaus können erweiternde Programmierungen durch Veränderung der Inhalte von HTTP_Info auf die weitere Verarbeitung der aktuellen Anfrage Einfluss nehmen. Erweiternde Programmierungen haben jederzeit die Möglichkeit, die stattfindenden Automatismen der Module ganz oder teilweise zu deaktivieren. Insert-, Update-, Delete- und Duplicate-Module rufen nach Abwicklung ihrer Aufgabe immer das Display-Modul auf, dessen Aufgabe es ist, eine Antwort an den Client zu generieren. Das Display-Modul von dbServlet beinhaltet noch keine Automatismen. Stellvertretend für unterschiedliche Phasen der Abarbeitung werden Events erzeugt, die dann durch erweiternde Programmierungen ausgewertet werden können. In einem Tutorial wird ein mögliches Konzept erläutert, mittels dessen der Display-Bereich strukturiert und automatisiert werden kann.
3. Templates: Templates werden im Software-Tool als Datensätze in einer angeschlossenen Stammdatenbank gespeichert. Innerhalb des Software-Tools werden Templates als Objekte der Klasse brainTags.netrelay.html.HtmlPage dargestellt. Ein Template kann als Ergebnis ein HTML-Source, ein XML- oder ein anders geartetes Dokument oder eine Datei liefern. Die Steuerung, welches Ergebnis ein Template erzeugen soll, findet durch das Setzen von bestimmten Schlüsselfeldern im Template selbst und/oder den Einsatz entsprechenden Tags der Scriptlanguage statt. (Innerhalb dieser Beschreibung wird als Ergebnis eines Templates eine generierte HTML-Seite zugrunde gelegt).

Templates sind durch zwei Zustände oder Betrachtungsweisen definiert: Durch den Editor- und den Runtime-View.
Der Editorview eines Template besteht aus einer Reihe von funktionalen Feldern. Während der Initialisierung des Software-Tools wird überprüft, ob ein Standard-Online-Editor existiert und unter Umständen zusammen mit dem Online-Administrator ein Tool erzeugt. Der Standard-Online-Editor stellt die Felder des Editor-Views eines Templates in der logischen Struktur einer HTML-Seite dar. Aufgrund des Standard-Online-Editors können entsprechend berechtigte Mitglieder Templates erzeugen und bearbeiten. Als Inhalte der Templates können z.B. Texte, HTML, Tags der Software-Tool-Scriptlanguage u. dgl. eingesetzt werden. Mit Ausnahme von bestimmten HTML-Tags müssen alle Inhalte XML-konform sein. Nach Bearbeitung der Templates werden durch das Aktivieren eines Sichern-Buttons diverse Prozesse aktiviert, an deren Ende bei fehlerfreiem Durchgang die Erzeugung des Runtime-Views steht.
Innerhalb dieser Prozesse wird aus den Inhalten aller Felder der Editor-Views ein Komplett-Dokument erzeugt, in ein XML-Dokument verwandelt und einem XML-Parser zur weiteren Bearbeitung übergeben. Der Parser untersucht das Dokument rekursiv und überprüft dabei jeden Node nach einer bestimmten Regel. Hierbei werden alle gefundenen Elemente belassen wie sie sind, es sei denn es wird ein Node mit dem Namen "BrainTag1" gefunden, dessen Attribut "class" auf eine existierende Klasse verweist, die das Interface "BrainTags.netRelay.util.BrainTagInterface" erweitert. Hier übergibt das Software-Tool alle nötigen Informationen an die Methode "preparse" eines Objektes dieser Klasse. Die aufgerufene Methode muss als Minimum den aktuellen Node von "BrainTag1" in "BrainTag2" umbenennen. Darüber hinaus kann die Methode Überprüfungen durchführen (Pflichteingaben, inhaltsrichtige Eingaben u. dgl.) und eine unter Umständen schwer lesbare, aber dafür performantere Syntax erzeugen. Weitere Aktionen sind einzig vom Sinn des entsprechenden tags abhängig.
Das Ergebnis des gesamten Preparse-Prozesses ist ein geändertes XML-Dokument, das im Feld xml_doc des aktuellen Datensatzes gespeichert wird und einen Runtime-View darstellt.
Zur Laufzeit des Systems, wenn ein Client das erzeugte Template anfordert, findet ein ähnlicher Prozess wie nach der Bearbeitung des Editor-Views statt. Als Quelle wird hier allerdings der Inhalt des Feldes xml_doc verwendet und durch einen Parser rekursiv verarbeitet. Für den Fall, dass der Parser einen Node findet, mit dem Namen "brainTag2", so übergibt er alle für die Laufzeit relevanten Daten an die Methode "finalParse" eines Objektes der entsprechenden Klasse. Das Ergebnis dieser Methode kann ein String (z.B. HTML) sein, das dann in das zu generierende Gesamtdokument eingefügt wird. Darüber hinaus kann die Methode Einfluss auf die gesamte Laufzeitumgebung nehmen, indem sie z.B. einen oder mehrere Datensätze aus der Da tenbank anfordert und diese für eine spätere Verarbeitung oder Anzeige dem Gesamtsystem zur Verfügung stellt. Das Ergebnis dieses Prozesses ist ein Dokument, das an den Client zurückgesendet wird.

4. Scriptlanguage: Die Scriptlanguage des Software-Tools stellt die Werkzeuge dar, aufgrund deren dynamische (z.B. auf einer Datenbank basierende) Inhalte in eine Website eingefügt werden und darüber hinaus Business-Prozesse modular definiert werden können. Jeder Befehl der Scriptlanguage wird in XML-Struktur als XML-Tag definiert, kann über Attribute und untergeordnete Nodes parametrisiert werden. Die untergeordneten Child-Nodes können irgendeines Inhalts sein und dabei auch wieder auf "Tags" der Scriptlanguage verweisen. Jeder Tag, der im Template in XML-Struktur eingefügt wird, verweist auf eine existierende Klasse im Software-Tool, die für die Funktionalität und das Ergebnis zuständig ist. Da für die Entwicklung neuer Tags eine offene und gut dokumentierte Schnittstelle existiert, ist jeder Java-Entwickler in der Lage, eigene Tags zu entwickeln. Dazu bestehen folgende Vorteile: Der Entwickler muss sich bei der Problemlösung letztlich nur um die wesentlichen Bestandteile eines Projektes kümmern. Der Entwickler kann jederzeit Tags entwickeln, die sehr spezialisert sind, ohne dabei die Übertragbarkeit anderer Entwicklungen auf andere Projekte zu zerstören. Der Entwickler kann einem HTML-Entwickler schnell zuarbeiten, indem er neue Tags mit neuer Funktionalität in kurzen Zeiträumen liefert. Die Trennung zwischen Logik und Präsentation ist klar definiert und kann kaum durchbrochen oder aufgeweicht werden.
5. Sicherheit im Software-Tool: Geschützt werden können Templates und die Tags.
6. HTML-Templates: Templates sind das Gegenstück zu den statischen HTML-Seiten auf einem Webserver. Eine statische Webseite wird normalerweise als Datei auf der Festplatte eines Servers gespeichert und bei jedem Aufruf geladen und an gezeigt. Diese Seite auf dem Papier, die der Leser gerade liest, ist eine statische Webseite. Diese Seite wird unabhängig von ihrer Anzeige immer den gleichen Inhalt haben.

Im Gegensatz zu dieser gedruckten Seite kann (und wird) eine dynamische HTML-Seite auf die aktuelle Situation "reagieren". Die Definition einer Template (engl. Vorlage) versetzt den Client in die Lage, eine Web-Seite zu erstellen, die z.B. den Namen des aktuellen Benutzers oder einen anderen Inhalt einer Datenbank darstellt.
Templates bestehen aus statischen und dynamischen Elementen und beschreiben das Aussehen der Seite, die angezeigt wird. Für den Fall, dass ein Client den Inhalt seines Warenbestandes online bringen will, so kann er zwei Templates erstellen: Eine, die alle Artikel als Liste anzeigt und eine weitere, in der zu einem bestimmten Artikel auch Artikel-Details aufgeführt sind.
Für den Fall, dass ein Client die Artikelliste aufruft, so erhält er eine Seite in seinem Browser, in der alle Artikel aus der Datenbank aufgeführt sind. Zu jedem Artikel in dieser Liste wird ein Link generiert. Nach einem Klick auf dieses Link öffnet sich eine neue Seite, in der zu dem augenblicklich angeklickten speziellen Artikel die Details aufgeführt sind.
Die Definition der Detail-Seite kann wie folgt aussehen:
Artikel-Name: <hier steht der Artikelname>
 Artikel-Beschreibung: <hier steht die Artikel-Beschreibung>
Dieses Beispiel ist insofern stark vereinfacht, da zu einem Artikel noch sehr viel mehr Informationen gegeben sind, aber bereits hier kann der Unterschied zwischen den statischen und dynamischen Elementen der Templates erkannt werden. Der Text Artikel-Name ist der statische Teil. Es ist gleich, welcher Artikel gerade angezeigt wird, dieser Text wird immer derselbe bleiben und sich nicht verändern. Im Gegensatz hierzu wird der Text, nach <hier steht der Artikelname> gegen den Inhalt des gerade aktiven Artikels ausgetauscht werden. Für den Fall, dass ein Client in einer Artikelliste z.B. auf den Namen "Erdbeere" klickt, wird er in der ersten Zeile der Detail-Anzeige das folgende sehen:

Artikel-Name: Erdbeere.
Für den Fall, dass der Client auf einen Artikel mit dem Namen "Kirsche" klickt, so wird angezeigt:

Artikel-Name: Kirsche.
Nach diesem Verfahren ist der Client in der Lage, alle Artikel online zu bringen und doch muss er nur zwei kleine Seiten erstellen. Es bestehen noch weitere Vorteile: Bei Änderung des Preises oder der Beschreibung eines Artikels wird die Änderung in die Datenbank eingetragen. Der nächste Benutzer, der den entsprechenden Artikel aufruft, wird sofort die Änderung sehen. Es besteht nämlich kein Grund zur Änderung von hunderten oder tausenden von Web-Seiten. Weiterhin sind alle diese Artikel in einer strukturierten Datenbank gespeichert und können auch auf anderem Weg und mit anderen Medien weiterverarbeitet werden. Die Verbreitung der Datenbank spart z.B. Produktionskosten für gedruckte Kataloge ein.
Der Ablauf des Verfahrens ergibt sich sodann aus den 2–9. Gemäß 2 löst eine Anfrage eines Client deren Untersuchung aus (4), wobei unter Verwendung und Weitergabe der HTTP_Info das Modul "insert" (5) oder das Modul "update" (6), das Modul "delete" (7) oder das Modul "duplicate" (8) und stets das Modul "display" (9) angesprochen wird. Daraus entsteht eine Anwort, die z.B. auf dem Bildschirm angezeigt wird.
In 3 ist das Software-Tool für die Initiierungsphase dargestellt. Sofern keine Präferenzen vorhanden sind, werden Standard-Präferenzen vorgegeben und eine Fehlermeldung generiert, wonach der Prozess gestoppt wird. Bei Vorhandensein von Präferenzen werden Verbindungen zu Datenbanken aufgebaut, nach Tabellen der Datenbanken gefragt und bei deren Nichtfeststellung werden durch weitere Präferenzen Tabellen neu erstellt. Sofern dieser Vorgang durch fehlende Präferenzen abgebrochen wird, wird wiederum die eingangs beschriebene Fehlermeldung erstellt. Bei Vorhandensein entsprechender Präferenzen werden die Tabellen erstellt. Sofern schon eingangs alle Tabellen als vorhanden erkannt wurden, werden entsprechende Verbindungen zu den Datenbanken in einem Connection-Pool gespeichert. Der nächste Schritt ist dann eine Anfrage nach der Existenz des Clients in der Stammdatenbank. Im Verneinungsfall wird eine Superadministration angelegt, der Super-Client wird angelegt und die Super-Administration wird dem Super-Client zugewiesen. Im Fall der Bejahung der Frage nach der Client-Existenz wird nach der Existenz des Super-Administrators gefragt. Bei Verneinung erfolgt die Anlegung des Super-Administrators, wonach die Standard-HTML-Templates initialisiert werden. Die nächste Frage betrifft die Standard-Web-Verzeichnisse, die bei Nichtvorhandensein eingerichtet werden. Damit ist die Initialisierung beendet.
In 4 ist die Untersuchung der Anfrage eines Clients dargestellt. Die Anfrage erzeugt die HTTP_Info. Danach werden Basis-Daten der Anfrage ermittelt und in der HTTP_Info zwischengespeichert. Nach dem jeweiligen Ergebnis kann die Anfrage eingestellt werden und das folgende Command-Modul bestimmt werden. Es erfolgt eine Bestimmung, an welchen Client die Anfrage gerichtet war. Darauf folgt eine Überprüfung, ob die Anfrage ein Login ist. Für den Fall, dass die Anfrage kein Login darstellt„ findet eine Prüfung einer früheren Autorisierung statt. Diese wird sodann einem "member" zugeordnet. Dasselbe findet statt, wenn die Anfrage als Login festgestellt wurde. Dem "member" wird sodann ein Template zugeordnet. Danach wird geprüft, ob das "member" Zugriffs-Restriktionen aufweist. Bei fehlenden Zugriffs-Restriktionen wird geprüft, ob das "member" Berechtigung zur Benutzung des Templates besitzt. Bei fehlender Berechtigung wird wiederum eine Fehlermeldung und eine entsprechende Antwort gesendet. Bei gegebener Berechtigung bzw. bei Bestätigung, dass Zugriffs-Restriktionen nicht bestehen, wird ein Hauptobjekt erzeugt. Dieser Vorgang erfolgt über das Command-Modul "insert", wobei das Hauptobjekt soweit wie möglich mit Werten gefüllt wird. Danach kann das Hauptobjekt in die entsprechenden Tabellen geschrieben werden und das nächste Command-Modul "update" kann aufgerufen werden. Nach dem Erzeugen des Hauptobjekts kann demzufolge entschieden werden, dass auf das Command-Modul "insert" folgend das Command-Modul "update" angesprochen wird. Andere Command-Module können aufgerufen werden.
In 5 ist das Command-Modul "insert" dargestellt. Es erfolgt ein Aufruf durch den Client. Danach wird die angegebene Klasse geprüft und zwar auf Existenz und auf Vorhandensein aller notwendigen Werte. Bei Verneinung dieser Frage wird die bereits beschriebene Fehlermeldung generiert und über das Display-Modul auf dem Bildschirm, angezeigt. Für den Fall, dass Klasse und Werte zutreffen, wird eine neue Klassen-Instanz erstellt. Das erstellte Objekt wird soweit möglich mit Daten des Aufrufs gefüllt. Das Objekt wird darauf in die HTTP_Info eingefügt. Die nächste Frage umfasst eine Autosave-Option des aufrufenden Templates und ob diese aktiviert ist. Im Verneinungsfall wird wiederum eine Fehlermeldung generiert und angezeigt. Im Bejahensfall wird das Objekt in einen Speicher eingeschrieben. Daraufhin wird ein neuer Datensatz angelegt mit der Syntax "dbBeans.DB_Gateway.Insert". Das Insert-Verfahren ist damit abgeschlossen.
In 6 ist das update-Modul mit seinem Ablauf wiedergegeben. Es erfolgt ein Aufruf durch den Client. Danach wird die Klasse auf Existenz und Vorhandensein aller einzutragenden Daten geprüft. Für den Fall, dass diese Prüfung negativ ausfällt, wird eine Fehlermeldung generiert, die auf dem Display angezeigt wird. Für den Fall, dass die angegebene Klasse für gültig anerkannt wird, wird der im Aufruf enthaltene und gefundene Datensatz übergeben. Danach wird das Objekt zum Datensatz erstellt. Der nächste Schritt ist, dass das erstellte Objekt mit Werten aus dem Aufruf gefüllt wird. Danach wird das Objekt in der HTTP_Info eingefügt. In einer Prüfung, ob die Autosave-Option die aufrufenden Templates aktiviert, wird bei Verneinung die Fehlermeldung erzeugt und angezeigt und bei Bejahung wird das update-Modul angesprochen für die Speicherung des Objektes. Anschließend wird der Datensatz aktualisiert unter der Syntax "dbBeans.DB_Gateway.update".
In 7 ist das delete-Modul mit Ablauf dargestellt. Es erfolgt wiederum bei Aufruf durch den Client die Prüfung der Gültigkeit der angegebenen Klasse auf Vorhandensein und Vollständigkeit des Datensatzes. Bei Verneinung wird eine Fehlermeldung generiert und auf dem Display angezeigt. Bei Bejahung wird im nächsten Schritt geprüft, ob die Datensatz-Identifikation im Aufruf übergeben wurde und der Datensatz gefunden wurde. Im Verneinungsfall wird die beschriebene Fehlermeldung generiert. Im Bejahungsfall wird das Objekt aus dem Datensatz erstellt. Das Objekt wird im nächsten Schritt in HTTP_Info eingefügt. Danach wird eine Anfrage nach einer Aktivierung der Autosave-Option der aufrufenden Templates gerichtet. Ist eine Aktivierung nicht möglich, so wird wiederum die generierte Fehlermeldung auf dem Display abgebildet. Im Fall der möglichen Aktivierung erfolgt eine Löschung der gespeicherten Informationen des Objekts. Der entsprechende Datensatz wird aufgrund der Syntax "dbBeans.DB_Gateway.delete" gelöscht.
Gemäß 8 ist das Flussdiagramm für ein Duplicate-Modul dargestellt. Nach einem Aufruf durch den Client wird die Gültigkeit der angegebenen Klasse geprüft, d.h. die Existenz und die Informationswerte werden abgefragt. Bei Verneinung eines dieser Werte wird eine Fehlermeldung generiert und das Display-Modul wird aufgerufen, d.h. die Fehlermeldung wird auf dem Bildschirm angezeigt. Bei Bejahung der Existenzwerte wird weiter geprüft, ob der Datensatz im Aufruf übergeben und der Datensatz gefunden wurde. Im Verneinungsfall wird wiederum die generierte Fehlermeldung auf dem Display angezeigt. Bei Bejahung wird das Objekt aus dem Datensatz erstellt. Danach wird das Objekt in HTTP_Info eingefügt. Danach wird die zu speichernde Information in doppelter Form abgespeichert. Die Syntax ist dazu "recordInfo.duplicateObject" bzw. "recordInfo.InsertObject". Der duplizierte Datensatz wird dann eingefügt unter der Syntax "dbBeans.DB_Gateway.insert".
Das Display-Modul ist mit seinem Flussdiagramm in 9 dargestellt. Es wird zunächst ein Feld xml_doc des Template ausgewählt. Der Inhalt wird sodann in einem Parser verarbeitet. Die Parser-Verarbeitung ist in einem geschlossenen Feld dargestellt. In einem folgenden Schritt wird geprüft, ob ein Netzwerksknoten (Node) gefunden werden kann. Im Bejahungsfall wird gefragt, ob der Node ein spezifischer Software-Tool-Node ist. Sofern diese Frage verneint wird, wird nach Unter-Nodes gesucht. Für den Fall des Findens werden die Unter-Nodes rekursiv durch Parser untersucht und dabei wird solang wiederholt bis das Template-Ende erreicht ist.
Wird die Frage nach einem spezifischen Software-Tool-Node bejaht, wird nach der zugehörigen Klasse gefragt. Sofern eine solche Klasse nicht gefunden wird, erfolgt die Generierung einer Fehlermeldung, die auf dem Display des Client angezeigt wird, sodass jedes so erzeugte Dokument an den Client zurückgelangt. Für den Fall des Auffindens der zugehörigen Klasse werden die Daten an eine Final-Parse-Methode übergeben. Das Ergebnis der Final-Klasse kann eine Fehlermeldung sein, ansonsten wird das generierte Ergebnis eingefügt, wobei das Template-Ende erreicht ist oder nicht. Für den Fall, dass das Template-Ende erreicht ist, wird wie beschrieben das erzeugte Dokument an den Client zurückgesandt oder aber es findet eine rekursive Untersuchung durch Parser wiederholt statt bis jeweils das Template-Ende erreicht ist.
Gemäß 10 ist in einem Datenverarbeitungs-System eine Schnittstellenverbindung der Datenbanken 3, 4 und 5 an das Software-Tool 2 geschaltet. An dem Webserver 1, der mit statischen Webseiten 6 beliefert werden kann, ist ein Zentralrechner (z.B. eine Gateway-Computer) angeschlossen, von dem aus die Anzeigevorrichtungen 8, 9 und 10 mit den fertigen Produkten beliefert werden können, die also bei einem Client aufgestellt sind. Über das Software-Tool 2 gelangen somit datenbankgestützte Webseiten 11 in den Webserver 1 und können in diesem wie beschreiben gestaltet und verarbeitet werden.

Claims

Verfahren zum Entwickeln von Software im Internet-, Netzwerk- und/oder Anwendungssoftware-Bereich für einen Webserver, mit der Datenbanken vom Webserver aus gesteuert werden, dadurch gekennzeichnet, dass ein unter Verwendung von Befehlen der Programmiersprache Java programmierbares Software-Tool eine Schnittstelle bildet, die alle angebundenen, ggfs. unterschiedlichen Datenbanken mit denselben Befehlen anspricht und alle angebundenen, ggfs. unterschiedlichen Datenbanken ein datenbankneutrales Ergebnis zurückliefern und dass in der Software Automatismen verwendet werden, die die Entwicklung beliebiger, internetbasierender Software-Applikationen teilautomatisieren.
Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass das Software-Tool zu 100% in der Programmiersprache Java programmiert wird.
Verfahren nach einem der Ansprüche 1 oder 2, dadurch gekennzeichnet, dass die entwickelten Software-Applikationen on-line im Webserver generiert werden.
Verfahren nach einem der Ansprüche 1 bis 3, dadurch gekennzeichnet, dass zum Erzeugen einer datenbankgebundenen eBusiness-Applikation alle Verbindungen zwischen dem Anwender, dem Webserver und einer beliebigen Datenbank strukturiert und definiert werden.
Verfahren nach einem der Ansprüche 1 bis 4, dadurch gekennzeichnet, dass während der Initialisierung die Verbindung zu der jeweiligen Datenbank aufgebaut und innerhalb von Verbindungs-Pools gespeichert wird.
Verfahren nach einem der Ansprüche 1 bis 5, dadurch gekennzeichnet, dass die Verbindung zu den Datenbanken über Präferenzen und Klassen aufgebaut wird.
Verfahren nach einem der Ansprüche 1 bis 6, dadurch gekennzeichnet, dass für jeden Aufruf ein Objekt der Klasse HTTP_Info erzeugt wird, in dem alle Informationen abgelegt werden, die im Lauf der Abarbeitung einer Anfrage gesammelt werden.
Verfahren nach einem der Ansprüche 6 oder 7, dadurch gekennzeichnet, dass über die Klassen jeweils ein Interface–SoftwareTool.dB.Beans.DB. Gateway implementiert wird.
Verfahren nach einem der Ansprüche 6 bis 8, dadurch gekennzeichnet, dass ankommende Anrufe über das Interface in funktionale Blöcke unterteilt werden, die über den Parameter "command" genutzt werden.
Verfahren nach einem der Ansprüche 1 bis 9, dadurch gekennzeichnet, dass das Software-Tool zumindest mehrere Module, die aus Logiken „Insert", „Update", „Delete", "Duplicate" und „Display" bestehen, dynamisch abgreift.
Verfahren nach Anspruch 10, dadurch gekennzeichnet, dass die Logiken im Software-Tool vorprogrammiert werden.
Verfahren nach einem der Ansprüche 9 bis 11, dadurch gekennzeichnet, dass die Logiken im Software-Tool bis zu 90% vorprogrammiert werden.
Verfahren nach einem der Ansprüche 1 bis 12, dadurch gekennzeichnet, dass der nicht vorprogrammierte Restteil der Logiken durch die Anwendung von HTML erstellt wird.
Verfahren nach einem der Ansprüche 1 bis 13, dadurch gekennzeichnet, dass das Software-Tool modulare Funktionen in Servlet-Technologie und XML als Dokumentenformat verwendet.
Verfahren nach einem der Ansprüche 1 bis 14, dadurch gekennzeichnet, dass die Servlets als Module in den Webserver integriert werden, die über eine Schnittstelle mit dem Webserver kommunizieren.
Verfahren nach einem der Ansprüche 1 bis 15, dadurch gekennzeichnet, dass Aufrufe durch den Webserver an das Software-Tool gerichtet werden, die die zur Bearbeitung erforderlichen Informationen erfassen.
Verfahren nach einem der Ansprüche 1 bis 16, dadurch gekennzeichnet, dass zur Erzeugung einer HTML-Seite Templates verwendet werden, die in einer verbundenen Datenbank gespeichert werden.
Verfahren nach Anspruch 17, dadurch gekennzeichnet, dass die Templates in XML gesichert und durch einen Java-XML-Parser bearbeitet werden.
Verfahren nach einem der Ansprüche 17 oder 18, dadurch gekennzeichnet, dass aufgrund der Templates in einer Datenbank eine Auswahl erzeugt wird.
Verfahren nach einem der Ansprüche 17 bis 19, dadurch gekennzeichnet, dass aufgrund der Templates in einer Datenbank Datensätze erzeugt, gelöscht, geändert und/oder abgebildet werden.
Verfahren nach einem der Ansprüche 17 bis 20, dadurch gekennzeichnet, dass aufgrund der Templates ein dynamischer HTML-Table erzeugt wird.
Verfahren nach einem der Ansprüche 14 bis 21, dadurch gekennzeichnet, dass für die Servlets eine offene und dokumentierte Schnittstelle generiert wird.
Verfahren nach einem der Ansprüche 14 bis 22, dadurch gekennzeichnet, dass die Bearbeitung der Templates und/oder der Servlets unmittelbar on-line in vorprogrammierte HTML-Editiermasken durchgeführt wird.
Verfahren nach einem der Ansprüche 14 bis 23, dadurch gekennzeichnet, dass die Templates aufgrund eines WYSIWYG-Editors erzeugt werden.
Verfahren nach einem der Ansprüche 14 bis 24, dadurch gekennzeichnet, dass die Templates aufgrund eines Java-Applets als Editor erzeugt werden.
Verfahren nach einem der Ansprüche 14 bis 25, dadurch gekennzeichnet, dass die Templates aufgrund einer grafischen WYSIWYG-Editierebene erzeugt werden.
Verfahren nach einem der Ansprüche 1 bis 26, dadurch gekennzeichnet, dass Veränderungen der Inhalte von HTTP_Info durch erweiternde Programmierungen, die auf die Verarbeitung der aktuellen Anfrage Einfluss nehmen, vorgenommen werden.
Verfahren nach einem der Ansprüche 1 bis 27, dadurch gekennzeichnet, dass der erste Client, der im Software-Tool angelegt wurde, als Super-Client geführt wird.
Verfahren nach Anspruch 28, dadurch gekennzeichnet, dass anstelle des Super-Client ein oder mehrere Super-Administratoren eingesetzt werden, die die Rechte des Super-Client für den Zugriff auf das System ausüben.
Verfahren nach einem der Ansprüche 28 oder 29, dadurch gekennzeichnet, dass für den Super-Client und/oder für den Super-Administrator das Passwort "super" eingeführt wird.
Verfahren nach einem der Ansprüche 6 bis 9, dadurch gekennzeichnet, dass als Klassen "softwareTool.dbServlet.BasicDbServlet" zur Auswahl von Datenbanktabellen und zur Kommunikation mit Java-Klassen, ferner Command-Module, ferner Template-Module, ferner Scriptlanguage-Module, ferner Sicherheits-Module und HTML-Template-Module vorgesehen werden.
Verfahren nach einem der Ansprüche 1 bis 32, dadurch gekennzeichnet, dass die Existenz eines Clients zumindest über ein "Member", "Super", "Super-Administrator", oder verschiedene HTML-Templates festgelegt wird.
Verfahren nach einem der Ansprüche 31 oder 32, dadurch gekennzeichnet, dass über das Modul "Scriptlanguage" Inhalte in eine Website eingefügt werden.
Verfahren nach einem der Ansprüche 31 bis 33, dadurch gekennzeichnet, dass zum Schutz der Templates und zum Schutz der Tags ein Online-Template-Editor, ein Table-Generator und je ein Bereich für die Client- und Member-Verwaltung eingegeben werden.
Verfahren nach einem der Ansprüche 31 bis 34, dadurch gekennzeichnet, dass die Command-Module aus dem Software-Tool-Package abgeleitet werden und zum Einwirken auf die Inhalte des übergebenen HTTP_Info verwendet werden.
Verfahren nach einem der Ansprüche 31 bis 35, dadurch gekennzeichnet, dass die Templates als Datensätze in einer angeschlossenen Stammdatenbank gespeichert werden und dass das Ergebnis als eine HTML-Seite, ein XML, ein anders geartetes Dokument oder eine Datei dargestellt wird.
Verfahren nach einem der Ansprüche 31 bis 36, dadurch gekennzeichnet, dass die Templates entweder im Zustand des Editor-Views oder des Runtime-Views eingesetzt werden.
Verfahren nach einem der Ansprüche 31 bis 37, dadurch gekennzeichnet, dass das Template als dynamische HTML-Seite mit austauschbaren DetailElementen geführt wird.
Datenverarbeitungs-System mit verkabelten oder über Funk verbundenen Clients, wie z.B. an Netzwerken angeschlossenen Clients und mit einem Webserver und unabhängigen Datenbanken, dadurch gekennzeichnet, dass der Webserver (1) mittels datenbankgestützten Webseiten (11) über ein zwischen dem Webserver (1) und den Datenbanken (3, 4, 5) angeordneten Software-Tool (2), das Schnittstellen generiert, belieferbar ist.
Datenverarbeitungs-System nach Anspruch 39, dadurch gekennzeichnet, dass das Software-Tool (2) alle Verbindungen zwischen einem Client, dem Webserver (1) und beliebigen Datenbanken (3, 4, 5) strukturiert und definiert.
Datenverarbeitungs-System nach einem der Ansprüche 39 oder 40, dadurch gekennzeichnet, dass auf dem ortsfernen Webserver (1) das Software-Tool (2) Schnittstellen zu den Datenbanken (3, 4 oder 5) schaltet.