-
Die
Erfindung betrifft ein Verfahren zur Erzeugung einer n-schichtigen, d.h.
mindestens zweischichtigen Softwareapplikation mit einer Verarbeitungsschicht
und einer Prozessschicht, wobei jede Schicht gekapselt und damit
plattformunabhängig lauffähig ist
und die gekapselten Schichten über
eine Anwendungsschnittstelle miteinander kommunizieren. Die Erfindung
betrifft ebenfalls ein System zur Erzeugung einer Applikation mit
einer flexiblen Verschaltungsschnittstelle innerhalb einer Anwendungsschnittstelle
zwischen gekapselten Schichten.
-
Die
Erstellung von Softwareapplikationen erfordert vom Entwickler bei
der Konzeption der Softwarearchitektur ein hohes Maß an programmiertechnischem
Wissen und Erfahrung. Bisher wird eine Applikation nahezu ausschließlich monolithisch
und damit als ein Applikationsblock erstellt, der bei notwendigen Änderungen,
wie z.B. bei Software-Updates, immer in Gänze geändert werden muss. Dies führt zu einem
erhöhten
Aufwand bei der Erstellung der Applikation und bei deren Wartung.
Darüber
hinaus sind diese monolithisch-basierten Systeme relativ fehleranfällig.
-
Neben
Applikationen für
den Desktop-Einsatz, bei denen die Applikationsschichten ausschließlich auf
einem gemeinsamen Rechner ausführbar
sind, sind Web-Applikationen bekannt, bei denen die Applikationsschichten
für den
Ablauf auf einer Client-Server-Struktur, d.h. auf mehreren Rechnern
konzipiert sind. Web-Applikationen benötigen aber wiederum die Client-Server-Struktur,
sind also ohne Server nicht einsetzbar.
-
Bei
den bisherigen Applikationssystemen ist es vorgesehen, dass eine
Applikation auf einzelnen Bibliotheken in Form einer dynamischen
oder statischen Verlinkung zugreift und innerhalb einer Ausführungsdatei
in Form eines Executables zur Ausführung gebracht wird. Die Applikationen
greifen dabei auf eine Vielzahl unterschiedlicher Dienste, Komponenten
und Daten zurück,
die der jeweils aufrufenden Applikation in unterschiedlichen hierarchischen Schichtebenen
der zugrunde liegenden Softwarearchitektur zur Verfügung gestellt
werden. Herkömmlicherweise
sind diese Dienste direkt im Quellcode einer Applikation implementiert,
wobei teilweise die Dienste und Komponenten auf unterschiedlichen Plattformen,
wie z.B. Windows-basierte oder Linux-basierte Betriebssysteme, und
unterschiedlichen Ablauforten innerhalb eines Computernetzwerkes, wie
z.B. Desktop-Rechner oder webbasierte Server-Client-Konfigurationen,
ablaufen. Eine nachträgliche
Anpassung oder Modifikation der Applikation an veränderte Plattformumgebungen
und/oder andere Ablauforte, zusammen auch als Deployment bezeichnet,
ist aufgrund der jeweils unterschiedlichen Softwarearchitektur für die verschiedenen
Deployments nicht möglich.
-
Problematisch
ist bei der Erstellung einer Softwarearchitektur für eine Applikation
daher, dass bei einer Änderung
oder Anpassung an andere Einsatzumgebungen oder an andere Deployments
bisher die zugrunde liegende Softwarearchitektur angepasst werden
muss, was in der Regel umfangreiche Änderungen erfordert. Hierbei
ist vor allem die Anordnung der Architekturschichten der Applikation
auf der jeweiligen Rechnerstruktur der unterschiedlichen Deployments
immer wieder neu vom Entwickler vorzugeben. Insbesondere muss eine
neue Softwarearchitektur für
die Applikation festgelegt, ein neuer Quellcode erstellt und in
eine Ausführungsdatei
in Form eines Executables kompiliert werden. Diese Maßnahmen
erfordern einen hohen Zeit- und Ressourcenaufwand für die Erstellung
der jeweiligen Applikationen und machen derzeit die parallele Entwicklung
von unterschiedlichen Applikationen mit abweichender Softwarearchitektur
einer Computeranwendung für
unterschiedliche Deployments notwendig.
-
Aus
diesem Grunde gibt es so genannte Frameworks als Unterstützungsumgebungen
für einen Entwickler,
wobei die Frame works häufig
die einzelnen Schichten einer Softwareapplikation innerhalb einer
generischen Laufzeitumgebung kapseln. Als gekapselt wird eine Applikationsschicht
bezeichnet, die – eingebettet
in eine generische Laufzeitumgebung – einzeln plattform- und/oder
Ablaufort-unabhängig
lauffähig
ist.
-
Ein
wichtiges Framework ist das .NET Framework der Firma Microsoft Coperation.
Dieses Framework bietet die Möglichkeit
unterschiedlichste Programmiersprachen, wie C#, Visual Basic.NET, C++/CLI
oder JScript.NET, als Grundlage für die Programmierung einer
n-schichtigen Applikation zu verwenden. Unabhängig von der Art der verwendeten Programmiersprache
wird die Applikation und/oder jeweilige Architekturschicht der Applikation
in eine "Zwischensprache" (Microsoft Intermediate
Language; abgekürzt
MSIL) umgewandelt. Die so programmierte Applikation in der Zwischensprache
wird dann anschließend
kompiliert und in eine Ausführungsdatei
umgewandelt.
-
Große Bedeutung
haben dabei die zwischen den einzelnen Schichten der Applikation
notwendigen Anwendungsschnittstellen (engl.: application programming
interface; kurz API). Man unterscheidet zwischen funktionsorientierten,
interfaceorientierten und protokollorientierten Anwendungsschnittstellen. Im
Gegensatz zu funktionsorientierten und interfaceorientierten Anwendungsschnittstellen
sind protokollorientierte Anwendungsschnittstellen unabhängig von
dem Betriebssystem der Plattform und der Art der zu verbindenden
Schichten der Applikation. Eine einmal zwischen zwei gekapselten
Schichten festgelegte Anwendungsschnittstelle ist jedoch derzeit nicht
veränderbar,
so dass – bezogen
auf die jeweiligen Deployments – damit
eine jeweils eigene, quasi monolithische Softwareapplikation notwendig
ist.
-
So
beschreibt die
DE
698 19 188 T2 einen Programmschnittstellenumsetzer für Rechner
mit mehreren Umgebungen. Ein Dienstprogramm erzeugt und aktualisiert
nach der dortigen Erfindung automatisch Codemodule zum Übersetzen
von Anwendungsschnittstellen, die für eine Plattform geschrieben
sind, damit sie auf einer anderen Plattform ordnungsgemäß ausgeführt werden
können.
Das Dienstprogramm, ausgeführt
für jeden
neuen Entwicklungsschritt eines Betriebssystems oder einer anderen
Software-Umgebung, arbeitet mit einer Reihe von Templates zur Erzeugung
vom Quellcode für die Übersetzungsmodule,
basierend auf den von den Anwendungsschnittstellen ausgeführten Funktionen.
-
Ebenfalls
beschreibt die
DE
699 08 121 T2 eine Anwendungsprogrammierschnittstelle in
einem Betriebssystem. Es wird ein System entsprechend der dortigen
Erfindung angegeben, das einen Satz von Anwendungsschnittstellen
für eine
Anzahl von Softwaremodulen und -komponenten für Umgebungen mit eingeschränkten Ressourcen
beinhaltet. Ein Beispiel einer Umgebung mit eingeschränkten Ressourcen
ist ein eingebautes System, wozu eine Vielzahl von Verbrauchergeräten und
spezialisierten Industriesteuerungen, gemeinsam mit Hand- oder Palm-size-PCs,
gehört.
-
Nachteilig
an allen im Stand der Technik bekannten Verfahren zur Erzeugung
einer n-schichtigen Applikation mittels eines Framework ist, dass zwar
die Anwendungsschnittstellen bezüglich
der notwendigen Plattformen und Ablauforten umgewandelt werden können, jedoch
besteht bisher keine Möglichkeit
die einmal für
ein Deployment festgelegte Interaktion der Schichten über die
jeweils zwischengeordneten Anwendungsschnittstellen für ein anderes
Deployment zu nutzen. Daher sind bisher parallele Entwicklungen
von Quellcodestämmen
für die
unterschiedlichen Deployments notwendig.
-
Aufgabe
der vorliegenden Erfindung ist es daher, eine zentralisierte Entwicklung
von n-schichtigen Applikationen unabhängig von der zugrunde liegenden
Softwarearchitektur unter Berücksichtigung der
verwendeten Plattformen und Ablauforte in einem Computernetzwerk
zu ermöglichen.
-
Gelöst wird
die Aufgabe durch die Merkmale des Patentanspruchs 1. Erfindungsgemäß ist vorgesehen,
dass die Anwen dungsschnittstelle eine flexible Verschaltungsschnittstelle
umfasst und die flexible Verschaltungsschnittstelle in Abhängigkeit
der zugrunde liegenden Plattformen der einzelnen gekapselten Schichten
die für
die Kommunikation über
die Anwendungsschnittstelle zwischen den gekapselten Schichten notwendigen
Kommunikationsprofile bereitstellt. Hierdurch kann die zugrunde
liegende Softwarearchitektur der Applikation unabhängig vom
jeweiligen Deployment verwendet werden. Lediglich die in den Anwendungsschnittstellen
integrierten Verschaltungsschnittstellen werden auf das jeweilige Deployment
angepasst.
-
Im
Sinne der Erfindung sind gekapselte Schichten einer Applikation
unterschiedlich hierarchische Ebenen einer Softwarearchitektur,
wobei die Ebenen plattformunabhängig
und unabhängig
vom Ablaufort innerhalb eines Computernetzwerkes sind. Die jeweiligen
gekapselten Schichten laufen insbesondere innerhalb einer generischen
Laufzeitumgebung ab und interagieren über die Schnittstellen der jeweiligen
generischen Laufzeitumgebung miteinander. Im Zuge unterschiedlicher
Verteilungen (Deployments) der einzelnen gekapselten Schichten auf
verschiedene Ablauforte innerhalb eines verbindbaren Computernetzwerkes
kann die gesamte, d.h. alle Applikationsschichten umfassende, Applikation
entweder auf einem einzigen Rechner im Desktop-Einsatz (bzw. Offline-Einsatz)
als so genannter Fat-Client oder über verschiedene Rechner innerhalb
eines verbindbaren Computernetzwerkes (Online-Einsatz) als Smart-Client, Rich-Thin-Client,
Thin (HTML)-Client oder als Webservice verteilt sein. In einer weiteren als
Rich-Client beschriebenen Deployment-Variante kann die Applikation
wahlweise im Offline-Einsatz oder im Online-Einsatz betrieben werden.
-
Durch
das erfindungsgemäße Verfahren
ist es möglich,
dass jede auf dem Framework aufsetzende Applikation automatisch
in den oben beschriebenen Deployments betrieben werden kann, ohne
dass der Applikationsentwickler für die jeweiligen Softwarearchitekturen
verschiedene Quellcodestämme entwickeln und
warten muss. Hierdurch ist es einem Applikationsentwickler möglich, nur
einmal die grundlegende Schichtenarchitektur seiner Applikation
zu erarbeiten, was die Entwicklungszeiten für die Applikation stark reduziert.
Gleichzeitig ist hierdurch eine zentralisierte Softwareentwicklung
möglich,
so dass für
die unterschiedlichen Deployments keine unterschiedlichen Softwarearchitekturen
mit abweichenden Quellcodestämmen
vorgehalten und gepflegt werden müssen.
-
Durch
die Nutzung des Frameworks in Verbindung mit der Implementierung
einer jeweils flexiblen Kommunikationsschicht innerhalb der Anwendungsschnittstelle
ist garantiert, dass die aus gekapselten Schichten bestehende Applikation
sowohl im Desktopbetrieb eines Fat-Client oder auch im Webbetrieb
eines beispielsweisen Thin (HTML)-Clients laufen können. Die
flexible Verschaltungsschnittstelle gewährleistet über die jeweiligen Anwendungsschnittstellen
mit flexibler Kommunikationsschicht eine Datenverarbeitung und einen
Zugriff der Applikation auf die jeweiligen Dienste und/oder Komponenten
innerhalb der Schichten, so dass der Applikation ihre aktuelle Einsatzumgebung
verborgen bleibt.
-
In
einer vorteilhaften Ausgestaltung des Verfahrens ist vorgesehen,
dass die gekapselten Schichten auf unterschiedlichen miteinander
verbindbaren Ablauforten innerhalb eines Computernetzwerkes lauffähig sind,
wobei die Anwendungsschnittstellen die notwendigen Kommunikationsprofile
zwischen den gekapselten Schichten bereitstellen, sowie die Datenkommunikation
zwischen den Datenschnittstellen des verbindbaren Computernetzwerkes überwachen.
-
Die
in den gekapselten Schichten implementierten Dienste und/oder Komponenten
und/oder Daten sind vorteilhafterweise bezüglich einer standardisierten
Anwendungsschnittstelle und/oder einer standardisierten Datenschnittstelle
konzipiert. Durch die Verwendung von einheitlichen Standards für Erstellung
der jeweiligen Dienste und Komponenten innerhalb der gekapselten
Schichten muss der Entwickler keine zusätzli chen Anstrengungen in die
Datenverarbeitung, Datenübertragung
und das Management der Dienste über
die Schichtgrenzen hinweg investieren. So ist es möglich, dass
die unterschiedlichen gekapselten Schichten in verschiedenen Programmiersprachen
programmiert sind und dennoch ohne zusätzliche Zwischenprozesse die
jeweiligen Dienste innerhalb der gekapselten Schichten aufgerufen
werden können.
-
Es
wird weiterhin als vorteilhaft angesehen, dass in den gekapselten
Schichten standardisierte Dienste implementiert werden und jeweils
eigenständig
aufrufbar sind.
-
In
einer vorteilhaften Ausgestaltung des Verfahrens ist vorgesehen,
dass bei der Vorgabe der Deployments in Form der Plattformen und
der jeweiligen Ablauforte innerhalb des Computernetzwerkes die für die Kommunikation
zwischen den einzelnen gekapselten Schichten jeweils notwendigen
Kommunikationsprofile automatisch ausgewählt werden. Der Applikationsentwickler
ist hierdurch bei seiner Arbeit unterstützt und gleichzeitig wird gewährleistet,
dass das jeweils notwendige Kommunikationsprofil der flexiblen Verschaltungsschnittstelle
als Teil der Anwendungsschnittstelle zwischen jeweils zwei gekapselten
Schichten ausgewählt
wird.
-
Die
Kommunikationsprofile der Anwendungsschnittstelle undoder die Kommunikationsprofile
der Datenschnittstellen werden dynamisch in Abhängigkeit der Plattformen und
Ablauforte innerhalb des Computernetzwerkes der gekapselten Schichten implementiert.
Insbesondere mittels XML- oder DLL-Konfigurationsdateien für die Konfigurierung
der flexiblen Verschaltungsschnittstelle ist es möglich, die
Applikation plattformunabhängig
und unabhängig vom
Deployment zu kompilieren. Erst beim Einsatz der Applikation auf
dem jeweiligen Deployment werden mittels der XML- oder DLL-Konfigurationsdatei die
jeweils notwendigen Kommunikationsprofile für die flexiblen Verschaltungsschnittstellen
in den Anwendungsschnittstellen zwischen den gekapselten Schichten
implementiert. Damit ist gewährleistet, dass
die Applikation ohne weitere Kompilierung oder Umwandlung auf jedem
Deployment lauffähig
ist.
-
Die
Architektur der Applikation umfasst erfindungsgemäß als unterste
Schicht eine Serviceschicht zur Bereitstellung von lokalen und/oder
externen Diensten und/oder Daten für ein Framework, eine Datenzugriffsschicht
für den
Zugriff auf Daten und zur Bereitstellung von lokalen und/oder externen Daten-
und Kommunikationsdiensten, eine Verarbeitungsschicht zur Bereitstellung
von Verarbeitungsdiensten und Verarbeitungskomponenten, eine Prozessschicht
zur Bereitstellung einer Business-Logik und eines Service-Busses
und als hierarchisch oberste Schicht eine Präsentationsschicht zur Darstellung
der Daten und Präsentationskomponenten.
-
In
einer vorteilhaften Ausgestaltung des Verfahrens steuert die Applikation
den Zugriff auf die einzelnen gekapselten Schichten selbst und ist
als gekapselte Anwendung unabhängig
vom jeweiligen der Softwarearchitektur zugrunde liegenden Deployment plattformunabhängig lauffähig. In
einer generischen Laufzeitumgebung ist die gekapselte Applikation lauffähig und
damit unabhängig
vom jeweiligen Deployment für
die gekapselten Schichten.
-
Die
gekapselte Applikation ist entweder in einer generischen Laufzeitumgebung
lauffähig
oder die gekapselte Applikation wird in einer in einem Webserver
ablaufenden generischen Laufzeitumgebung zur Ausführung gebracht.
Die Interaktion der Applikation mit der generischen Laufzeitumgebung bleibt
jedoch in jedem Deployment erhalten. Dadurch wird erreicht, dass
die Applikation bei verschiedenen Deployments nicht geändert werden
muss und unverändert
sowohl im Desktop- als auch im Webdeployment lauffähig ist.
Die Konzeption der gekapselten Schichten, wie beispielsweise der
Präsentationsschicht,
verändert
sich bei einem Wechsel der Applikation auf einem anderen Deployment – bei gleich bleibender
Softwarearchitektur der Applikation – nicht. Die Applikationsarchitektur
und die verwendete Programmiersprache bleiben damit eben falls unverändert. Im
Einzelnen kommunizieren die gekapselten Schichten über jeweils
eine integrierte flexible Verschaltungsschnittstelle der jeweils
zwischengeordneten Anwendungsschnittstelle. Wenn sich die Applikation
im Desktopeinsatz befindet, wird eine bestimmte für den Desktopeinsatz
geeignete Implementierung der Kommunikationsprofile für die flexible
Verschaltungsschnittstelle verwendet. Dadurch dass die Kommunikation
zwischen den gekapselten Schichten immer über jeweilige zwischengeschaltete
Verschaltungsschnittstellen erfolgt, ist es möglich die Implementierung der
flexiblen Verschaltungsschnittstellen frameworkseitig auszutauschen,
ohne dass die Applikation hierfür
geändert
oder erneut kompiliert werden muss.
-
Hierdurch
wird der Aufwand für
die Entwicklung und Wartung der Applikation reduziert. Der Begriff "zero-admin-deployment" kennzeichnet sich
in diesem Zusammenhang durch diese damit verbundene Funktionalität dadurch
aus, dass jeglicher Verwaltungsaufwand für die jeweiligen Deployments
für die
Applikation vermieden wird. Die parallele Erstellung und Pflege
von Quellcodestämmen
für unterschiedliche
Deployments ist somit vollständig
von der jeweiligen Applikation entkoppelt.
-
Es
wird ebenfalls als vorteilhaft angesehen, dass die Erstellung der
Softwarearchitektur der jeweils gekapselten Schichten aufgrund der
vorgegebenen Plattformen und/oder Ablauforte innerhalb eines verbindbaren
Computernetzwerkes automatisch erfolgt. Das Verfahren unterstützt den
Entwickler nicht nur bei der Auswahl der jeweils notwendigen Verschaltungsschnittstellen
innerhalb der Anwendungschnittstellen zwischen den gekapselten Schichten,
sondern auch bei der Anordnung und Implementierung der gekapselten
Schichten im Hinblick auf die beabsichtigten Deployments für die Computeranwendung.
-
Die
Aufgabe wird ebenfalls durch die Merkmale des Anspruchs 11 gelöst. Erfindungsgemäß ist ein
System zur Erzeugung einer n-schichtigen Softwareapplikation vorgesehen,
wobei innerhalb einer Anwendungsschnittstelle teilweise eine flexible
Ver schaltungsschnittstelle oberhalb des Frameworks ausgebildet ist
und die flexible Verschaltungsschnittstelle in Abhängigkeit
der zugrunde liegenden Plattformen der einzelnen gekapselten Schichten
die für die
Kommunikation über
die Anwendungsschnittstelle zwischen den gekapselten Schichten notwendigen Kommunikationsprofile
bereitstellt.
-
In
einer vorteilhaften Ausgestaltung des Systems ist die Applikation
gekapselt und damit auf einer generischen Laufzeitumgebung lauffähig. Unabhängig von
der Systemkonfiguration der Plattformen für die jeweiligen gekapselten
Schichten ist ebenfalls die ablaufende Applikation unabhängig und
muss nicht bei verschiedenen Deployments verändert werden.
-
Die
vorliegende Erfindung kann in Form von Hardware, Software oder einer
Kombination von Hardware und Software realisiert werden. Hierfür ist jede
Art von System bzw. jede andere zum Ausführen des erfindungsgemäßen Verfahrens
eingerichtete Vorrichtung geeignet. Eine typische Kombination von Hardware
und Software könnte
ein Universalcomputersystem mit einem Computerprogramm sein, welches
in das Universalcomputersystem geladen und ausgeführt wird
und das Computersystem so steuert, dass eine nach dem beschriebenen
Verfahren erstellte Applikation ausführt. In einer weiteren Kombination
von Hardware und Software kann beispielsweise eine Verarbeitungsschicht
für Bildverarbeitung in
einer speziellen Bildverarbeitungs-Hardware angeordnet sein, während die übrigen Schichten
auf konventioneller PC-Hardware ausgeführt werden. Die vorliegende
Erfindung kann auch in ein Computerprogrammprodukt integriert werden,
welches alle Merkmale umfasst, die es zur Realisierung der hier beschriebenen
computergestützten
Verfahren befähigen,
und welches nach dem Laden in ein Computersystem in der Lage ist,
diese Verfahren auszuführen.
-
Unter
den Begriffen Computerprogrammmittel, Computerprogramm und Computeranwendung ist
im vorliegenden Zusammenhang jeder Ausdruck in einer beliebigen
Computersprache, Code oder Notation eines Satzes von Anweisungen
zu verstehen, welche ein Computersystem zur Datenverarbeitung und
so zur Ausführung
einer bestimmten Funktion befähigen.
Das Computerprogrammmittel, das Computerprogramm bzw. die Computeranwendung
ist entweder direkt oder nach einer Umwandlung in eine andere Sprache,
Code, Notation oder durch die Darstellung in einer anderen materiellen
Form auf dem Computersystem lauffähig.
-
Weitere
vorteilhafte Ausführungsformen
ergeben sich aus den Unteransprüchen.
-
In
der folgenden detaillierten Figurenbeschreibung werden nicht einschränkend zu
verstehende Ausführungsbeispiele
mit deren Merkmalen und weiteren Vorteilen anhand der Zeichnungen
erläutert.
Darin zeigen:
-
1 einen
schematischen Aufbau der Softwarearchitektur mit erfindungsgemäßen Verschaltungsschnittstellen,
-
2 einen
schematischen Aufbau der Softwarearchitektur als Fat-Client mit
erfindungsgemäßen Verschaltungsschnittstellen,
-
3 einen
schematischen Aufbau der Softwarearchitektur als Rich-Thin-Client
mit erfindungsgemäßen Verschaltungsschnittstellen,
und
-
4 in
schematischer Gegenüberstellung den
Aufbau der Softwarearchitektur als Fat-Client, Rich-Client, Smart-Client,
Rich-Thin-Client und Thin-Client sowie als Web-Service.
-
Die 1 zeigt
eine fünfschichtige
Softwareapplikation 10, wobei die Softwarearchitektur eine unterste
Serviceschicht 11, eine nachfolgende Datenzugriffsschicht 12,
eine anschließende
Verarbeitungsschicht 13, eine darüber liegende Prozessschicht 14 und
eine abschließende
Präsentationsschicht 15 aufweist.
Zwischen diesen zumindest teilweise mittels eines Frameworks gekapselten
Schichten 11,12,13,14,15 befinden
sich jeweils Anwendungsschnittstellen 17a,17b,17c,17d mit
integrierter Verschaltungsschnittstelle. Diese Verschaltungs schnittstellen
der Anwendungsschnittstellen 17a, 17b, 17c, 17d sind
derart flexibel, dass sie eine Softwarearchitektur ermöglichen,
die durch Konfiguration für
unterschiedlichste Deployments, also für unterschiedlichste Aufteilungen
der Schichten 11,12,13,14,15 auf
Plattformen und Ablauforte 16a,16b innerhalb eines
verbindbaren Computernetzwerkes genutzt kann, ohne dass hierfür eine Quellcodeanpassung
der Verschaltungsschnittstellen erforderlich ist. Lediglich die
Kommunikationsprofile der in den Anwendungsschnittstellen 17a, 17b, 17c, 17d integrierten
Verschaltungsschnittstellen muss an das jeweilige Deployment angepasst
werden. Die Anpassung der Verschaltungsschnittstellen kann entweder
im Rahmen einer Kompilierung erfolgen oder ist durch eine dynamische
Verlinkung zu Dateien einer Datenbank 19, beispielsweise
als XML- oder DLL-Konfigurationsdateien,
möglich.
-
Die
jeweiligen Dienste, Daten oder Komponenten 20a,20b,20c, 20d,21a,21b,21c,21d,22a,22b,22c,22d,23a,23b,23c der
jeweils gekapselten Schicht 11,12,13,14,15 sind
entweder durch die Schichten 11,12,13,14,15 oder
durch die Applikation 10 selbst aufrufbar. Die Interaktion über Anwendungsschnittstellen 17a, 17b,17c,17d mit
integrierter Verschaltungsschnittstelle ist in der Zeichnung durch
Pfeile symbolisiert.
-
Die
Kommunikationsprofile müssen
dabei so konzipiert sein, dass die Dienste und Komponenten 20a,20b,20c,20d,21a,21b,21c, 21d,22a,22b,22c,22d,23a,23b,23c innerhalb
einer Applikation 10 über
die gekapselten Schichten 11,12,13,14,15 hinweg
miteinander kommunizieren können.
Insofern müssen
die Kommunikationsprofile Client/Server-Anforderungs-/Reaktionsprotokolle,
ereignisbasierte Datenverarbeitung, allgemeines Jobmanagement und
Probleme der Datenkommunikation, wie synchroner Datenaustausch,
Formate von Datenprotokollen und Überwachung der Datenkommunikation
und Nachrichtenformate, berücksichtigen bzw.
abhängig
vom Deployment vorgeben und überwachen.
-
Die 2 zeigt
die Softwarearchitektur der Applikation 10 bei einem Fat-Client
Deployment. Die Softwarearchitektur braucht für diese Implementierung auf
einem einzigen Rechner nicht angepasst zu werden. Die Kommunikationsprofile
der integrierten Verschaltungsschnittstellen der Anwendungsschnittstellen 17a,17b,17c,17d ermöglichen
einen Desktopeinsatz der Applikation 10. Die gekapselten
Schichten 11,12,13,14,15 laufen
dabei innerhalb ihrer jeweils eigenen Laufzeitumgebung ab, so dass
hierbei auch unterschiedliche Programmiersprachen der jeweils gekapselten
Schichten 11,12,13,14,15 nutzbar sind.
-
Im
Unterschied dazu zeigt die 3 ein Rich-Thin-Deployment. Die Serviceschicht 11,
die nachfolgende Datenzugriffsschicht 12 und die Verarbeitungsschicht 13 der
Applikation 10 laufen auf einem ersten Rechner als Server 16a ab.
Die Prozessschicht 14 und die Präsentationsschicht 15 laufen
auf einem Client 16b ab, wobei über eine Datenschnittstelle 18 zwischen
der Verarbeitungsschicht 13 und der Prozessschicht 14 ein
Datentransfer und ein Zugriff auf die jeweiligen Dienste, Daten
und Komponenten 22a,22b,22c,22d dieser
Schichten 13,14 gegebenenfalls durch eine Firewall
gesichert, stattfindet.
-
Auch
hier braucht die zugrundeliegende Softwarearchitektur weder für das Rich-Thin-Client Deployment
noch für
das Fat-Client-Deployment
verändert
werden, da lediglich die Kommunikationsprofile der Verschaltungsschnittstellen
der Anwendungsschnittstellen 17a,17b,17c,17d an
das jeweilige Deployment angepasst werden müssen.
-
Die
vorstehend beschrieben Deployment-Varianten Fat-Client 25a und
Thin-Rich-Client 25d sind in 4 weiteren
Deployment-Varianten, nämlich
Rich-Client 25b, Smart-Client 25c und Thin-Client 25e gegenübergestellt.
Wie aus 4 weiterhin entnehmbar ist,
ergeben sich diese weiteren Deployment-Varianten aus den vorstehend
beschriebenen Beispielen durch Umlagerung einer oder mehrerer Schichten 11 bis 15 oder
einzelner Bestandteile dieser Schichten 11 bis 15 zwischen
Server 16a und Client 16b.
-
Bei
dem Thin-Client 25e ist lediglich ein Frontend der Präsentationsschicht 15 nach
Art eines Web-Interface auf dem Client 16b angeordnet.
Die übrigen
Anteile der Präsentationsschicht 15 sowie die übrigen Schichten 11 bis 14 sind
auf einem oder mehreren Servern 16a angeordnet. Die Präsentationsschicht 15 ist
dabei insbesondere in HTML-Technologie implementiert. Insbesondere
ist der Server 16a dabei wiederum aufgeteilt in einen Web-Server, der
eine Benutzeroberfläche
bereitstellt und auf den Client 15b exportiert, einen Applikationsserver,
der die Schichten 12 bis 14 enthält, und
einen Datenserver, der die Serviceschicht 11 aufnimmt.
-
Bei
dem Rich-Client 25b sind im Gegensatz dazu die Schichten 12 bis 15 clientseitig
angeordnet. Lediglich die Serviceschicht 11 ist auf einem
oder mehreren Servern 16a, insbesondere einem Daten-Cluster,
angeordnet. Im Rich-Client-Deployment kann
die Applikation 10 zumindest weitgehend im Offline-Einsatz
verwendet werden. Für
die Inanspruchnahme bestimmter Dienste, z.B. zum Laden von Bilddaten,
kann der Client 15b mit dem Server 16a, verbunden
werden.
-
Bei
dem Smart-Client 25c sind Bestandteile der Verarbeitungsschicht 13 und
der Datenzugriffsschicht 12 auf dem Client 16b,
und andere Bestandteile dieser Schichten 12 und 13 auf
einem bzw. mehreren Servern 16a verteilt. Im Smart-Client-Deployment kann die
Applikation 10 – anders
als bei dem Rich-Client – nicht
ohne ständige
Netzverbindung mit dem Server 16a betrieben werden. Die
Aufteilung der Schichten 12 und 13 zwischen Client 16b und
Server 16a ermöglicht
aber, die Performance der Application 10 unter Anpassung
an die Rechen- und
Speicherleistung von Client 16b und Server 16a sowie
die zur Verfügung
stehende Datenübertragungskapazität des Netzwerkes
besonders effizient zu optimieren.
-
Erfindungsgemäß kann die
Applikation auf Basis eines einzigen Quellcodestammes in allen dargestellten
Deployment-Varianten betrieben werden. Die einzelnen Schichten 11 bis 15 der
Ap plikation können
dabei auch unterschiedlich versioniert sein. Zur Anpassung an ein
bestimmtes Deployment ist die Applikation dabei lediglich entsprechend
zu konfigurieren. Darüber
hinaus können
die Serviceschicht 11 und die Prozessschicht 14 in
einen ebenfalls in 4 dargestellten Deployment auch
isoliert als reiner Web-Service 26 betrieben werden.