Vergleich Client-Server Architektur zu Three-Tier Architektur am Beispiel einer Oracle Datenbankanwendung
Aus Winfwiki
| Name des Autors: | Sebastian Kolder |
| Titel der Arbeit: | "Vergleich Client-Server Architektur zu Three-Tier Architektur am Beispiel einer Oracle Datenbankanwendung" |
| Hochschule und Studienort: | FOM Düsseldorf |
Inhaltsverzeichnis |
1 Einleitung
Die Verwaltung von Daten innerhalb einer relationalen Datenbank ist in der heutigen Zeit aus kaum einem Unternehmensbereich wegzudenken. Um die Daten ergonomisch dem Endnutzer zur Verfügung zu stellen, ohne dass er die im Hintergrund liegende Komplexität wahrnimmt, ist eine der größten Herausforderungen bei der Erstellung von Individualsoftware. Diese Seminararbeit beschäftigt sich mit dem Vergleich der Systemarchitekturen für verteilte Anwendungen, der Client-Server Architektur, sowie der Three-Tier Architektur. Diese beiden Architekturen bilden den Schwerpunkt dieser Seminararbeit, da die Firma Oracle in der aktuellen Version der Oracle Developer Suite[1] eine Distribution anbietet, welche voll auf den aktuellen Trend der Weborientierung ausgerichtet ist und somit auf einer Three-Tier Architektur basiert. In früheren Versionen der Oracle Forms Datenbankanwendungen handelte es sich um eine reine Client-Server Architektur, welche ab der Oracle Forms Version 10g[2] nicht mehr supported wird. Aus diesem Grund sahen sich viele Unternehmen, bei denen Oracle zum Einsatz kommt gezwungen ihre IT-Infrastruktur der Three-Tier Architektur anzupassen, um somit die Aktualität zu wahren. Diese Seminararbeit vergleicht nun beide Architekturen im Allgemeinen, sowie im oraclespezifischem Zusammenhang, um ihre jeweiligen Stärken und Schwächen aufzudecken.
2 Einführung und Definition
Um die Begriffe Client-Server Architektur und Three-Tier Architektur verstehen zu können, müssen im Vorfeld Distributed-Systems sowie Distributed-Computing-Anwendungen erläutert werden, da beide Architekturen auf Distributed-Systems aufbauen und Distributed-Computing-Anwendungen nutzen.
3 Distributed-Systems und Distributed-Computing-Anwendungen
Es gibt Datenverarbeitungs-Systeme, die ihre Aufgaben völlig eigenständig bewältigen können, ohne dabei in Kontakt mit anderen Computern oder andersartigen Maschinen zu treten. Solche Einzelrechner sind im unternehmerischen Alltag, selbst in KMU kaum mehr anzutreffen. In einem verteilten System werden die Aufgaben, die der Standalone Computer alleine bewältigt, in mehrere Teilaufgaben auf verschiedenen, unabhängigen Rechnern aufgeteilt, wobei ein jedes Glied auf die zu erledigende Aufgabe spezialisiert ist.[3] Der Benutzer soll von der Komplexität der Architektur im Hintergrund bei der Erledigung seiner Aufgaben möglichst nichts mitbekommen, daher ist eine zentrale Eigenschaft eines verteilten Systems, dass es nach Außen als ein einzelnes, kohärentes System in Erscheinung tritt und es dem Benutzer so einfach wie möglich gemacht wird auf entfernte Ressourcen, wie z.B. eine Datenbank zuzugreifen[4] . Um dies zu erreichen müssen hardware- sowie softwareseitige Anforderungen erfüllt sein. Die Unterschiede zwischen den Computern und der Art und Weise, wie diese miteinander kommunizieren, sollen für den Benutzer nicht erkenntlich sein[5] Leslie Lamport, ein US-Amerikanischer Mathematiker, Informatiker und Programmierer, hat einmal gesagt: "A distributed system is one in which the failure of a computer you didn’t even know existed can render your own computer unusable.", was soviel bedeutet wie, dass ein verteiltes System ein System ist, in dem der Ausfall eines Computers, von dem du nicht einmal wusstest, dass er existiert, deinen eigenen Rechner unbrauchbar machen kann.[6] Neben dem Argument der Strukturiertheit besitzen verteilte Systeme Eigenschaften[7] wie:
- Zentrale Datenhaltung: Mehreren Benutzern wird der Zugang auf den zentralen Datenpool ermöglicht
- Skalierbarkeit: Durch Hinzunehmen von neuen Rechnern können Performanceprobleme gelöst werden. Somit lässt sich ein verteiltes System beinahe beliebig an die jeweiligen Leistungsanforderungen anpassen
- Fehlertoleranz: Softwarekomponenten können von mehreren Rechnern zur Verfügung gestellt werden.
- Transparenz: Die Tatsache verbergen, dass Prozesse und Ressourcen physisch über mehrere Computer verteilt sind.
- Offenheit: Angebotene Dienste müssen in Syntax und Semantik beschrieben sein
Das Konzept Transparenz in verteilten Systemen kann auf mehrere Aspekte des verteilten Systems angewendet werden[8] Die Zugriffstransparenz beschäftigt sich damit, die Unterschiede in der Datendarstellung so darzustellen und aufzubereiten, dass der Benutzer diese gar nicht erst wahrnimmt. Der Zugriff auf die Ressourcen soll so transparent und im Hintergrund geschehen. Die sog. Positionstransparenz (Ortstransparenz) beschäftigt sich mit der Geheimhaltung der physischen Lage der Ressourcen innerhalb des gesamten Systems. Die Namensgebung spielt hier eine wichtige Rolle, da sich z.B. Dateiendungen zwischen den unabhängigen Rechnern unterscheiden können. Die nachfolgende Tabelle[9] gibt einen Überblick über die wichtigsten Transparenzen, die innerhalb von verteilten Systemen vorherrschen sollten.
| Transparenz | Beschreibung |
| Zugriff | Vergibt Unterschiede in der Datendarstellung und wie der Zugriff auf eine Ressource erfolgt
|
| Position | Verbirgt, wo sich eine Ressource befindet |
| Migration | Verbirgt, dass eine Ressource an eine andere Position verschoben werden kann |
| Relokation | Verbirgt, dass eine Ressource an eine andere Position verschoben werden kann, während sie genutzt wird |
| Replikation | Verbirgt, dass eine Ressource repliziert ist |
| Nebenläufigkeit | Verbirgt, dass eine Ressource von mehreren konkurrierenden Benutzern gleichzeitig genutzt werden kann
|
| Fehler | Verbirgt den Ausfall und die Wiederherstellung einer Ressource |
| Persistenz | Verbirgt, ob eine (Software-) Ressource sich im Speicher oder auf einer Festplatte befindet
|
Die Offenheit verteilter Systeme ist ebenfalls ein zentraler Punkt. So wird ein verteiltes System als offen beschrieben, wenn alle vom verteilten System angebotenen Dienste auch für die Verwendung beschrieben werden und somit genutzt werden können. Realisiert werden diese Dienste durch entsprechende Protokolle. Hierbei liegt die größte Herausforderung darin, ganz genau zu spezifizieren, was diese Dienste tun sollen. Ist dies geschehen, so kann beliebigen Prozessen der Zugriff auf diese Dienste über Schnittstellen ermöglicht werden, man spricht in diesem Fall von einer vollständigen und neutralen Spezifikation der Dienste.[10] Verteilte Systeme sollen eine Skalierbarkeit aufweisen, doch was bedeutet dies? Laut Neumann lässt sich die Skalierbarkeit eines Systems anhand von mindestens drei unterschiedlichen Dimensionen messen. Die Größenskalierbarkeit eines verteilten Systems ermöglicht es uns dem System einfach neue Benutzer oder Ressourcen hinzufügen zu können. Ein Problem bei der Größenskalierbarkeit kann sein, dass zentrale Dienste, Daten und Algorithmen Einschränkungen unterworfen sein können. Folge dessen wäre, dass der Server zum Flaschenhals werden kann, wenn die Anzahl der Benutzer ansteigt. Ein geografisch skalierbares System erlaubt eine große Entfernung zwischen den Benutzern und Ressourcen. So kann sich ein Teil bzw. ein Benutzer des verteilten Systems in einer anderen Stadt, in einem anderen Land, ja sogar auf einem anderen Kontinent, oder in Zukunft vielleicht auch auf einem anderen Planeten befinden. Die geografische Skalierbarkeit ist eingeschränkt, wenn beispielsweise ein verteiltes System, welches für ein lokales Netzwerk entworfen wurde skaliert werden soll. In einem lokalen Netzwerk wird es kaum zu Geschwindigkeitsproblemen kommen, da die Kommunikation innerhalb von Bruchteilen einer Sekunde von statten geht. Was passiert, wenn die Antwort des Servers plötzlich doppelt so lange dauert? In manchen verteilten Systemen mag die Antwortzeit nicht die größte Rolle spielen, verallgemeinern kann man diese Aussage jedoch nicht. Ein weiteres Problem der geografischen Skalierbarkeit ist, dass die Kommunikation fast immer durch Punkt-zu-Punkt Verbindungen realisiert wird, welche bei weitem nicht so zuverlässig sind wie Kommunikationsfunktionen innerhalb lokaler Netzwerke.[11] Der dritte Aspekt in Bezug auf die Skalierbarkeit eines verteilten Systems ist laut Neumann, dass ein System administrativ Skalierbar sein kann, was bedeutet, dass das System trotz unabhängiger administrativer Organisationen einfach in der administrativen Skalierbarkeit sein muss.
Eine verteilte Anwendung ist eine Software, welche die Hardware bzw. Infrastruktur der verteilten Systeme nutzt. Sie ist ein Anwendung, welche die Prozesse über Rechnergrenzen hinaus miteinander interagieren.[12] Die am einfachsten vorzustellende Interaktion einer verteilten Anwendung innerhalb eines verteilten Systems, ist das Senden und Empfangen von Nachrichten. Ohne verteilte Systeme würden dementsprechend auch keine verteilten Anwendungen existieren, daher werden diese Bergriffe oft analog verwendet.
3.1 Definition Mehrschichtensystem
Mehrschichtige Systeme, wie die Client-Server oder die Three-Tier Architektur, zeichnen sich durch eine Unterteilung von hardwareseitigen sowie softwareseitigen Aspekten aus. Die Unterteilung wird in verschiedene Schichten vollzogen, in sog. "Tiers". Die ursprüngliche Definition des Client-Server-Bergriffes aus den 1980er Jahren umfasste nur die reine hardwareseitige Trennung, was sich heutzutage als nicht mehr praktikabel erweist aufgrund der vielen zu differenzierenden Dienste wie Datenbank, Application-Server, File-Server oder Web-Server. Die unabhängigen Rechner sowie die einzelnen Dienste lassen sich abweichend vom Mainframe-Computing im Allgemeinen in drei Überkategorien unterteilen:[13]
- Präsentation
- Geschäfts/Anwendungslogik
- Datenhaltung
Diese drei Überkategorien sind bei mehrschichtigen Architekturen auf die Anzahl der Rechner der Architektur aufgeteilt. Die Präsentation dient der Darstellung einer wechselseitig beeinflussenden Benutzerschnittstelle. Die Anwendungslogik stellt die Funktionalität der Anwendung dar, wobei die Datenhaltung die reine, permanente Sicherung der Daten bereitstellt, sowie die Datenkonsistenz gewährleistet. Unternehmensanwendungen bestehen in der heutigen Zeit meist aus drei oder mehr Schichten, wobei die Datenbank hier als eigene Schicht angesehen wird.
3.2 Gründe für mehrschichtige Systeme
Mehrschichtige Systeme helfen dabei die Komplexität des Systems in seiner Gesamtheit besser in den Griff zu bekommen und somit eine optimale Strukturierung des Systems zu erreichen. Sie entstanden aus dem Problem der Aufsplittung von Anwendungen in eine Benutzeroberfläche, eine Verarbeitungskomponente sowie eine Datenebene. [14] Diese Schichten können als Abbild der Anforderungen der gewünschten Applikation angesehen werden. Für die physische Unterteilung dieser drei logischen Ebenen stehen in einer Client-Server Architektur mehrere Möglichkeiten zur Verfügung. So lassen sich die drei logischen Ebenen nahezu beliebig auf die Client- bzw. Servermaschine auslagern. Bei einer Three-Tier Architektur hingegen übernimmt das Frontend lediglich die Darstellung der Oberfläche der jeweiligen Applikation.[15] Ein großer Vorteil eines mehrschichtigen Systems besteht in der Minimierung der Berührungspunkte zwischen den einzelnen Teilen des Systems. Die übrigen Berührungspunkte und Dienste sind über ihre Schnittstellen genau beschrieben. In Folge dessen vermindert sich das Risiko, dass Änderungen an einer Schicht eine andere Schicht beeinflussen können.
3.3 Zusammenspiel Distributed-Systems mit Distributed-Computing-Anwendungen
Verteilte Systeme sind laut Tanenbaum ein Zusammenschluss von mehreren unabhängig operierenden Computern, welche sich dem Endnutzer als ein einzelnes, kohärentes System präsentieren[16]. Mehrschichtarchitekturen lassen sich auf solchen verteilten Systemen optimal abbilden, sie sind sogar an die mehrschichtigen Systeme gebunden. Es herrscht also sozusagen eine Symbiose zwischen ihnen. Die verteilten Anwendungen nutzen die exakt beschriebenen Schnittstellen der verteilten Systeme in einem hohen Maß aus.
3.4 Abgrenzung P2P-Modell zum Client-Server-Modell
Das P2P-Modell steht im direkten Gegensatz zum Client-Server Modell, da hier davon ausgegangen wird, dass alle Rechner innerhalb des P2P-Netzes gleichberechtigt sind. Peer-to-Peer Anwendungen zeichnen sich vor allem durch die folgenden drei Eigenschaften[17] aus:
- 1. Client- und Serverfunktionalität: Jede Station innerhalb des Peer-to-Peer-Netzwerkes darf das gleiche.
- 2. Direkter Austausch zwischen den Peers: Im gleichen Netzwerk können die Stationen untereinander in Echtzeit interagieren. Hier existiert kein
- zentraler Knoten, der die Kommunikation verzögert oder filtert. Für welchen Zweck die Daten hier ausgetauscht werden ist völlig unerheblich.
- 3. Autonomie: Ein jeder Knoten ist vollkommen autonom bei der Kontrolle der eigenen Aktivitäten, was bedeutet, dass sie selber entscheiden, wann sie welche Ressourcen in welchem Umfang zur Verfügung stellen. Die Folge dieser Autonomie ist, dass der Knoten nicht ständig im Netz zur Verfügung steht.
Aufgrund dieser Eigenschaften wird im Folgenden nicht weiter auf dieses Modell eingegangen.
4 Client-Server-Architektur
Abb1: Funktionsverteilung[18]
Bei der Client-Server-Architektur oder auch Two-Tier-Architektur genannt, werden Datenbankanwendung und Datenbank in ein Frontend[19] und ein Backend[20] unterteilt. Ursprünglich beschrieb der Client-Server-Begriff ausschließlich die Aspekte der Trennung auf Hardware-Ebene [21] Der Computer, auf dem die Datenbankanwendung läuft, wird als Client bezeichnet, der auf dem die Datenbank läuft als Server. Der Client führt die lokal installierte Anwendung aus und greift auf die Datenbank-Informationen interaktiv über Eingabegeräte, wie Maus, Tastatur und Bildschirm zu. Der Client enthält die Präsentations-Schicht sowie die Geschäftsschicht, auch Geschäftslogik genannt. Der Server führt die Software aus und übernimmt Funktionen für die gleichzeitige, gemeinsame Nutzung der Daten. Auf dem Server findet nur die reine Datenhaltung statt. Ein Prozess lässt sich immer klar dem Server oder dem Client zuordnen. Dem Server ist es durchaus möglich mehrere Clients gleichzeitig zu bedienen, wobei die Clients theoretisch nicht voneinander wissen müssen. So gesehen kann die Client-Server Architektur mit einer Konsumenten-Produzentenbeziehung beschrieben werden. Clients sind die Konsumenten und tätigen Anfragen an den Server für bestimmte Services oder Informationen und können dann die Rückantwort des Servers für die Erfüllung ihrer Aufgaben benutzen. Der Server bekommt die Rolle des Produzenten, er kümmert sich darum, dass die Daten- oder Servicerequests vom Client voll zufrieden stellend beantwortet werden. [22] Ihren Ursprung hat die Client-Server Architektur in der Betriebssystementwicklung, woraus sich dann das Anwendungsgebiet der Anwendungsenwicklung entwickelte. Die Trennung der logischen Ebenen, wie unter 3.3 angeschnitten kann laut Tanenbaum[23] wie in der Grafik "Alternative Client-Server-Anordnung" durchgeführt werden, wobei die einfachste Anordnung die Verteilung der Benutzeroberfläche auf den Client sowie den Rest auf die Server-Maschine darstellt. Da diese Unterteilung dem Server gegenüber doch sehr "unfair" erscheint, gibt es einige weitere Möglichkeiten die Aufgaben auf die beiden Ebenen zu verteilen, wie aus Abbildung 1 hervorgeht.
4.1 Client-Server Ebenen
Die im Vorfeld beschriebenen drei logischen Schichten lassen sich nach den jeweiligen Anforderungen auf die beiden Schichten der Client-Server Architektur verteilen.
4.1.1 verteilte Präsentation
Durch eine Aufteilung der Präsentationsfunktionen in eine Server- sowie eine Clientkomponente, wie auf der Abbildung 1 Schnittpunkt 1, lässt sich die verteilte Präsentation realisieren.[24] Die Applikation läuft losgelöst vom Client auf dem Server. In diese Kategorie fallen z.B. X-Terminals. In UNIX-artigen Betriebssystemen kommt das X-Window-System zum Einsatz, wobei die Kommunikation zwischen Server und Client über ein eigenes Protokoll abgewickelt wird. Durch das erhöhte Kommunikationsaufkommen kommt es zu einer Mehrbelastung des Netzwerkes. Die verteilte Präsentation eignet sich besonders für die Integration von auf unterschiedlichen Rechnern ablaufenden Anwendungen.
4.1.2 entfernte Präsentation
Abbildung 1 Schnittpunkt 2 zeigt, dass die entfernte Präsentation grundsätzlich mit der traditionellen Terminal-Host-Konfiguration zu vergleichen ist. Der Bildschirm wird durch die Applikation über bestimmte Kommandosequenzen gesteuert.[25] Hier übernimmt der Client neben der reinen Präsentationsfunktion auch weiterführende Funktionen, wie z.B. die Steuerung von Dialogen. Die entfernte Präsentation ist weniger kommunikationsintensiv wie die verteilte Präsentation.
4.1.3 kooperative Verarbeitung
Bei der kooperativen Verarbeitung wird die Anwendungslogik zur einen Hälfte auf dem Client und zur anderen Hälfte auf den Server verteilt. Abbildung 1 Schnittpunkt 3 zeigt, dass Client und Server Teile der Anwendungslogik enthalten.[26] Die kooperative Verarbeitung setzt voraus, dass der Entwickler genau weiss, wo und wie er die Anwendungslogik auf die Client- und Serverseite verteilt. Der Client übernimmt die Darstellung der Anwendung und die clientseitige Anwendungslogik, der Rest (Datenbanklogik usw.) wird vom Server zur Verfügung gestellt. Diese Art der Verarbeitung stellt sich als sehr flexibel dar, stellt aber höhere Anforderungen an den Entwickler.
4.1.4 entfernte Datenbank
Abbildung 1 Schnittpunkt 4 stellt eine Client-Server Variante mit entferntem Datenbankzugriff dar, welcher über Schnittstellen, wie z.B. SQL realisiert wird. Meist handelt es sich bei dem Client um einen PC oder eine Workstation. Der Großteil der Applikation wird hier auf der Client-Maschine ausgeführt, wobei alle Operationen für Dateien oder Datenbankeinträge vom Server übernommen werden. Der Server erfährt bei dieser Art von Funktionsverteilung eine erhebliche Entlastung, da er lediglich die Daten zur Verfügung stellt.[27] Diese Technik ist heutzutage sehr verbreitet, obgleich hier die Transparenz fehlt und das Kommunikationsaufkommen relativ hoch ist. Ein normales LAN sollte damit jedoch zurecht kommen.
4.1.5 Dateiserver / Pageserver bzw. verteilte Datenbank
Bei dieser Client-Server Variante ist der Server auf einen reinen Datei- bzw. Pageserver reduziert. Hier enthält der Client einen Teil der Daten auf seiner Festplatte, wie Abbildung 1 Schnittpunkt 5 deutlich macht.[28]
5 Three-Tier-Architektur
Von einer Three-Tier Architektur spricht man, wenn die Präsentationsschicht, Anwendungslogik und Datenhaltung auf drei unabhängige Rechnersysteme verteilt wurde. Der Begriff Three-Tier[29] beinhaltet also die Anzahl der physikalischen Schichten der Architektur. In diesem Architekturmodell wird die Anwendungslogik (auch Geschäftslogik genannt) auf einen eigenständigen Rechner, dem sog. Application Server ausgelagert. Diese Geschäftslogik wird auch oft als Middleware bezeichnet.[30] Die Three-Tier Architektur unterstützt Web-basierte Anwendungen, wo die Client-Anwendung ein einfacher Web-Browser sein kann.
5.1 mehrstufige C/S-Architektur
Als mehrstufige Client-Server Architektur bezeichnet man Systeme, in denen der Server Dienste eines anderen Servers benötigt. Hier lässt sich keine klare Unterscheidung zwischen der Rolle eines Servers und der eines Clients feststellen, die Architektur lässt sich jedoch weiterhin als zweischichtig bezeichnen.
6 Oraclespezifische Umsetzung
Im Folgenden wird auf die oraclespezifische Umsetzung der in den vorangegangenen Kapiteln gewonnenen Erkenntnisse eingegangen. An dieser Stelle werden die beiden Architekturen, die den Kern dieser Seminararbeit bilden, auf ihre spezifischen, von der Norm abweichenden Eigenschaften untersucht.
6.1 Aufbau der bisherigen C/S-Architektur mit Forms
Im Folgenden wird beschrieben, wie die Client-Server Architektur mit Oracle Forms realisiert wurde.
6.1.1 Der Client
Die Clients in der Oracle C/S-Architektur sind die Rechner an jedem Arbeitsplatz. Ihnen ist es möglich selbständig Aufgaben zu erfüllen und für alle Aufgaben, die sie selber nicht erledigen können, den Server hinzuzuziehen. Ein jeder Client innerhalb der C/S Architektur kann als Fat-Client bezeichnet werden, da dieser neben der Präsentationsschicht den Großteil der Anwendungslogik der Datenbankapplikation ausführt. Um die Forms-Module ausführen zu können, müssen diese auf jeden einzelnen Rechner kopiert werden. Damit der Client mit dem Server kommunizieren kann muss ebenfalls SQL*Net von Oracle installiert sein.
6.1.2 Der Server
Der Oracle Datenbankserver übernimmt den Zugriff auf die Ressourcen der Datenbank und nimmt keine neue Aufgabe wahr. Die Verbindung vom Client zum Server wird über den Forms-Runtime Prozess durchgeführt, welcher eine ständige Verbindung zur Datenbank über das SQL*Net Protokoll hat.[31]
6.2 Three-Tier-Architektur mit Forms 10g bzw. 11g
Abb2: Three-Tier-Architektur in Oracle[32]
Seit der Oracle Forms 10g ist die Client-Server Architektur der zukunftsträchtigen Three-Tier Architektur gewichen. Dieser Wandel fand in Anlehnung an die fortschreitende Weborientierung von Unternehmensanwendungen statt. Die Three-Tier Web-Applikation umfasst in der Regel den Anschluss einer Server-seitigen Java Applikation über eine JDBC-Verbindung (Java Database Connectivity) auf die Datenbank. Die Three-Tier Application ist eine Architektur, in der Toplink[33] (seit 11g durch EclipseLink ersetzt) in einem Java-Server untergebracht ist. Die Server Session ermöglicht nun den Clients im gemeinsamen Zugriff auf die JDBC-Verbindungen sowie auf den gemeinsamen Objekt-Cache. Diese Tatsache macht die Oracle Three-Tier Architektur einfach und leicht skalierbar.
6.2.1 Data-Server-Tier
Das Server-Tier übernimmt die Aufgabe der Bereitstellung der Ressourcen für einen gleichzeitigen Zugriff mehrerer User. Die Funktion des Server-Tiers hat sich im Vergleich zur Client-Server Architektur nur marginal verändert.
6.2.2 Das Middletier / Application-Server-Tier
Seit der Oracle Forms 10g Version ist das Middletier hinzugekommen, welche hauptsächlich die Anwendungslogik enthält. Das Middletier wird in der Oracle Three-Tier Architektur als Oracle Application Server bezeichnet. Das Middletier beinhaltet die Software für die Forms Services und stellt die Forms-Applikationen, die sog. Forms Module, zur Verfügung. Die Forms-Services unterteilen sich in die Komponenten Forms Servlet, Forms Listener Servlet und Forms Runtime Prozess. Bei den Forms-Services handelt es sich um eine J2EE-Applikation, welche vom OC4J Server betrieben und durch einen HTTP Server zugänglich gemacht wird.[34]
6.2.3 Client-Tier-Layer
Abb3: Three-Tier Detail[35]
Auf den Clients müssen innerhalb der Oracle Three-Tier Architektur nur wenige Vorkehrungen getroffen werden, da dieser die reine Präsentation übernimmt. Zum einen muss ein beliebiger, aktueller Browser auf dem Client installiert sein und zum anderen die JRE. Anstelle des JRE empfiehlt Oracle die Verwendung der hauseigenen Laufzeitumgebung, dem JInitiator. Sind diese Voraussetzungen gegeben ist der Client softwareseitig einsatzfähig.
Eine Client-Session ist ein rein Client-seitiger Kommunikationsmechanismus, der zusammen mit der Server-Session arbeitet, um die Client/Server Verbindung zu gewährleisten. Diese Client-Sessions werden von der Server-Session zur Laufzeit vergeben. Im Normalfall teilt sich die Client-Session den Session-Cache mit der übergeordneten Server-Session. Diese Client-Session kommuniziert im Namen der Client-Applikation mit dem Server.[36]
Im Wesentlichen ist der Forms Client ein generisches Java-Applet, dass durch den Forms-Runtime Prozess auf dem Oracle AS gesteuert wird. Hier ist zu beachten, dass das Java-Applet keine eigenständige Java-Applikation ist, die in einer virtuellen Maschine ausgeführt wird, sondern in eine HTML-Seite eingebettet ist und in einem Browser geladen werden kann. Das Java-Applet muss nicht auf dem Client abgelegt werden, sondern wird beim Start der Oracle Datenbankanwendung automatisch vom AS auf den Client geladen und dort im Cache abgelegt.
Eine Installation einer Forms-Client-Software ist nicht mehr nötig, lediglich die Laufzeitumgebung für die korrekte Darstellung des Java-Code im Browser muss auf dem Client Installiert sein. Solche Laufzeitumgebungen sind mittlerweile Standard und gehören meist zur Grundinstallation eines Clients. Um eine maximale Kompatibilität zu gewährleisten, bietet Oracle eine eigene Laufzeitumgebung, den JInitiator.[37]
6.3 Vergleich der Architekturen
Abb4: Übersicht Tier-Architekturen[38]
Durch die Umstellung der Client-Server Architektur auf die Three-Tier Architektur fällt die Installation einer Client-Software, welche auf Betriebssystem-Bibliotheken zurückgreift, weg. Der Sourcecode der Forms Dateien wird aufgrund des neu eingeführten Middletiers, nicht mehr auf dem Client interpretiert, sondern ausgelagert auf dem AS. Der Client stellt nur noch die Darstellung des Java-Applets zur Verfügung und ist von der Ausführung komplett getrennt.[39] Somit fällt das Kopieren der Forms-Applikation auf jeden einzelnen Client weg, da sich der Client nun das aktuelle Modul von einer zentralen Stelle, dem Application Server, in den Cache zieht, um es auszuführen. Nach dem Umstieg fällt gleich auf, dass die Java-Laufzeitumgebung sehr viel mehr Rechnerressourcen in Anspruch nimmt als die reine Oracle Forms Client-Anwendung. An diesen Punkt sollte bei einem geplanten Umstieg unbedingt gedacht werden, da ein unperformanter Client besonders die Ladezeiten für Initialisierungsprozesse ausbremsen kann. Der Wartungsaufwand stellt aufgrund der nun zentralen Administration einen nicht zu verachtenden Vorteil dar. Die Zeit für die Verteilung neuer bzw. geänderter Forms-Applikationen kann sich um bis zu 95%[40] verringern, da die Forms-Applikationen (sog. Webforms) nun zentral zur Verfügung gestellt werden und zur Laufzeit vom Client in den Cache geladen werden.
7 Fazit
Abb5: Oracle Forms Roadmap [41]
Der Umstieg von der Client-Server Architekur zur Three-Tier Architektur für Oracle Datenbankanwendungen hat nicht nur Vorteile. Durch den Einsatz einer entsprechenden Java-Laufzeitumgebung werden performantere Clients benötigt als beim Einsatz der Forms-Client Applikation. Besonders der Arbeitsspeicher des Clients wird mehr belastet. Aufgrund der Auslagerung der Anwendungslogik auf den AS wird das System in sich komplexer. Das Kommunikationsaufkommen zwischen den Schichten erhöht sich um ein Vielfaches, da der Client selber nur noch die präsentierende Schicht zur Verfügung stellt. Für den Forms-Entwickler ändert sich nur wenig. Er ist in der Lage die Kenntnisse der Forms-Programmierung für die Client-Server Architektur ohne besondere neue Erkenntnisse auf die Three-Tier Architektur anzuwenden und somit dem aktuellen Trend der Weborientierung zu entsprechen. Durch die verbesserte Kommunikation mit der Außenwelt können Forms-Anwendungen nun z.B. auf Webseiten eingebunden werden, was den Forms-Entwicklern völlig neue Möglichkeiten bereitet. Die neuen Features zur Kommunikation mit eingebetteten Webseiten bieten eine Reihe von Vorteilen, die in die Richtung gehen, dass die alten Forms-Module auch in Zukunft weiterbenutzt werden können um sie in Webseiten einzubetten. Durch diese völlig neue Infrastruktur bieten sich eine Reihe von neuen Schnittstellen die mittels des Frameworks ADF [42] implementiert werden können. Diese Entwicklungen zeigen, dass Oracle mehr und mehr dazu übergeht, die Migration in die Oracle ADF Welt zu beschleunigen um Funktionalitäten einerseits zu erhalten und zum anderen zu neuen Technologien zu erweitern. Für Kunden, welche noch ältere Oracle Forms Versionen, wie z.B. 6i benutzen, bleiben nach Ablauf des Supports folgende Möglichkeiten:
- Upgrade der bestehenden Forms Version auf die aktuelle Version 11g
- Migration der Forms-Anwendung in neue Technologien wie z.B. Java
- Migration der Forms-Anwendung nach Oracle Application Express
- Einsatz von Standardsoftware wie z.B. ERP-, CRM- und anderer Standardsoftware
Abb6: Forms und neue Technologien [43]
Hier wird deutlich, dass nur ein Umstieg auf die Three-Tier Architektur die Aktualität und Funktionalität von Oracle Forms gewährleistet. Oracle hat seinerseits angekündigt Oracle-Forms weiterzuentwickeln und bezüglich der Entwicklungsumgebund weiterhin auf PL/SQL als Programmiersprache zu setzen. Die Oracle Forms Roadmap macht deutlich klar, dass die Stufe nach den Webforms bisher noch nicht abzusehen ist. Es kann also nur vermutet werden, wann die endgültige Ablösung der Forms-Programmiersprache PL/SQL vollzogen sein wird.
8 Abkürzungsverzeichnis
| ODS | Oracle Developer Suite |
| JRE | Java Runtime Environment |
| J2EE | Java Platform, Enterprise Edition |
| KMU | Kleine und mittlere Unternehmen |
| WYSIWYG | What You See Is What You Get |
| EVA | Eingabe Verarbeitung Ausgabe |
| AS | Application Server |
| P2P | Peer-to-Peer |
| OC4J | Oracle Containers for Java |
| PL/SQL | Procedural Language/SQL |
9 Abbildungsverzeichnis
10 Fußnoten
- ↑ beinhaltet Oracle JDeveloper, Oracle Designer, Oracle Forms Developer, Oracle Reports Developer, Oracle Software Configuration Manager, Oracle Discoverer, Oracle Warehouse Builder, Oracle Business Intelligence Beans
- ↑ WYSIWYG Erstellung von interaktiven Dialogmasken
- ↑ vgl. Netze - Protokolle - Spezifikationen S. 1f
- ↑ vgl. Verteilte Systeme S. 20
- ↑ vgl. Verteilte Systeme S. 18f
- ↑ vgl. Leslie Lamport: Distributed Computing: Concepts and Implementations
- ↑ Systemarchitekturen für Verteilte Anwendungen S. 41
- ↑ Verteilte Systeme S. 21
- ↑ Verteilte Systeme S. 22 Abb. 1.2
- ↑ vgl. Verteilte Systeme S. 24f
- ↑ Verteilte Systeme S. 26ff
- ↑ vgl. Verteilte Systeme: Grundlagen und Praxis des Client-Server-Computing S. 27
- ↑ vgl. IT-projekte strukturiert realisieren S. 8
- ↑ vgl. Verteilte Systeme S. 72
- ↑ vgl. Verteilte Systeme S. 70
- ↑ vgl: Verteilte Systeme S. 18
- ↑ vgl: Peer-to-Peer: S. 4
- ↑ vgl. Verteilte Systeme: Grundlagen und Praxis des Client-Server-Computing S. 282
- ↑ vgl. http://www.computerlexikon.com/definition-frontend?highlight=frontend
- ↑ vgl. http://www.computerlexikon.com/definition-backend?highlight=backend
- ↑ vgl. IT-projekte strukturiert realisieren: S. 431f
- ↑ Verteilte Systeme: Grundlagen und Praxis des Client-Server-Computing S. 29
- ↑ Verteilte Systeme S. 71 Abbildung 1.29
- ↑ vgl. Verteilte Datenbanken und Client/server-systeme S. 282f
- ↑ vgl. Verteilte Datenbanken und Client/server-systeme S. 282
- ↑ vgl. Verteilte Datenbanken und Client/server-systeme S. 282
- ↑ vgl. Verteilte Datenbanken und Client/server-systeme S. 282
- ↑ vgl. Verteilte Systeme S. 71
- ↑ Drei-Schichten
- ↑ vgl. IT-projekte strukturiert realisieren S. 432f
- ↑ vgl. Praktische Anwendungsentwicklung mit Oracle Forms S. 21
- ↑ vgl. http://www.oracle.com/technology/products/ias/toplink/doc/1013/main/_html/undtldev010.htm
- ↑ vgl. http://www.oracle.com/technology/products/ias/toplink/index.html
- ↑ vgl. Praktische Anwendungsentwicklung mit Oracle Forms S. 46
- ↑ vgl. http://www.oracle.com/
- ↑ vgl. http://www.oracle.com/technology/products/ias/toplink/doc/10131/main/_html/undtldev010.htm
- ↑ vgl. Praktische Anwendungsentwicklung mit Oracle Forms S. 44
- ↑ vgl. IT-projekte strukturiert realisieren S. 432
- ↑ vgl. Praktische Anwendungsentwicklung mit Oracle Forms S. 22
- ↑ Eigene Erfahrungen
- ↑ vgl. Oracle White Paper Dezember 2009
- ↑ vgl. Oracle White Paper Dezember 2009
- ↑ vgl. Oracle White Paper Dezember 2009 S. 6
11 Literatur- und Quellenverzeichnis
Literraturquellen:
| Verteilte Systeme: | Andrew S. Tanenbaum , Maarten van Steen: Verteilte Systeme: Prinzipien und Paradigmen, PEARSON STUDIUM;Auflage: 2., Aufl. |
| Netze - Protokolle - Spezifikationen. | Alfred Olbrich: Netze - Protokolle - Spezifikationen. Die Grundlagen für die erfolgreiche Praxis Vieweg+Teubner; Auflage: 1 |
| Verteilte Datenbanken und Client/Server-Systeme: | Peter Dadam: Verteilte Datenbanken und Client/Server-Systeme: Grundlagen, Konzepte und Realisierungsformen, Springer, Berlin, Auflage: 1 |
| Systemarchitekturen für verteilte Anwendungen: | J. Dunkel, A. Eberhart, S. Fischer, C. Kleiner, A. Koschel: Systemarchitekturen für verteilte Anwendungen. Client-Server, Multi-Tier, SOA, Event Driven Architecture, P2P, Grid, Web 2.0 , Hanser Fachbuch; Auflage: 1 |
| IT-Projekte strukturiert realisieren: | Ralph Brugger: IT-Projekte strukturiert realisieren: Situationen analysieren, Lösungen konzipieren - Vorgehen systematisieren, Sachverhalte visualisieren - UML und EPKs nutzen, Vieweg+Teubner; Auflage: 2. |
| Praktische Anwendungsentwicklung mit Oracle Forms: | P. Pakull, S. Jüssen, W. Müller: Praktische Anwendungsentwicklung mit Oracle Forms, Hanser Fachbuch; Auflage: 1 |
| Verteilte Datenbanken und Client/Server-Systeme: | Peter Dadam: Verteilte Datenbanken und Client/Server-Systeme: Grundlagen, Konzepte und Realisierungsformen , Springer, Berlin |
| Verteilte Systeme: Grundlagen und Praxis des Client-Server-Computing | Günther Bengel: Verteilte Systeme: Grundlagen und Praxis des Client-Server-Computing , Vieweg+Teubner; Auflage: 3. A. |
| Peer-to-Peer: | D. Schoder, R. Teichmann, K. Fischbach: Peer-to-Peer: Ökonomische, technologische und juristische Perspektiven, Springer, Berlin; Auflage: 1 |
Internetquellen:
