Konzeption und Realisierung einer webbasierten Anwendung mit dem Java (TM) 2 Enterprise Edition Framework
Am Beispiel eines Systems zur Unterstützung der Übersetzung von Arbeitstexten in der Automobilindustrie
- Art: Diplomarbeit
- Autor: Ansgar Gerlicher
- Abgabedatum: Dezember 2001
- Umfang: 138 Seiten
- Dateigröße: 1,3 MB
- Note: 1,1
- Institution / Hochschule: Hochschule der Medien (ehem. Hochschule für Druck und Medien Stuttgart (FH)) Deutschland
- ISBN (eBook): 978-3-8324-6173-7
-
ISBN (Paperback) :
978-3-8324-6173-7 P - ISBN (CD) :978-3-8324-6173-7 CD
- Sprache: Deutsch
- Prämierung:
- Arbeit zitieren: Gerlicher, Ansgar Dezember 2001: Konzeption und Realisierung einer webbasierten Anwendung mit dem Java (TM) 2 Enterprise Edition Framework, Hamburg: Diplomica Verlag
- Schlagworte: UML, Rational Unified Process (RUP), EJB - Enterprise Java Beans, MVC - Model View Controller, Verteilte Systeme
In den Warenkorb
58,00 €
Diplomarbeit von Ansgar Gerlicher
Einleitung:
Die Entwicklung webbasierter Software Systeme und Anwendungen ist ein Thema mit dem sich zur Zeit immer mehr Firmen beschäftigen. Eine verteilte webbasierte Anwendung bringt viele Vorteile mit sich.
Auf eine Web Anwendung kann mit Hilfe eines standard Web Browsers zugegriffen werden. Dies erspart eine aufwändige Installation und Wartung von Client Software. Software Updates können zentral durchgeführt werden und stehen allen Clients sofort zur Verfügung. Die Web-Anwendung kann auch sehr leicht einer großen Benutzergruppe zugänglich gemacht werden, ohne große Vertriebswege zu benötigen. Auch für den Entwickler einer webbasierten Anwendung gibt es Vorteile. Er spart sich viel Arbeit bei der Programmierung einer Client Software, denn ein Web Browser stellt schon viel Basisfunktionalität zur Verfügung (z.B. Unicode Unterstützung). Diese Eigenschaften machen sich z.B. sogenannte Application Service Provider (ASP) zu nutze und stellen verschiedene webbasierte Dienste und Anwendungen, wie z.B. vertikale („B-2-B“) und horizontale („Nischen“ und Endanwender) Portale, zur Verfügung. Das mySAP Enterprise Portal der Firma SAP(TM) ist dafür ein Beispiel.
Der Trend hin zu verteilten webbasierten Anwendungen nimmt also zu und es gibt mittlerweile viele Technologien, um solche Systeme zu realisieren. Zwei Beispiele dafür sind die Active Server Pages (ASP) und Hypertext Preprocessor (PHP) . ASP sind, genau wie PHP , Technologien um dynamische Webseiten und damit webbasierte Anwendungen zu erstellen. Diese Technologien basieren auf Skript-Code, der in einer HTML Seite eingebettet und bei einer Anfrage eines Client Browsers zur Laufzeit interpretiert wird. Es ist damit möglich, sehr schnell und effizient verteilte webbasierte Anwendungen zu entwickeln, solange die Komplexität dieser Anwendungen in einem gewissen Rahmen bleibt. Eine weitere Technologie für die Entwicklung webbasierter Anwendungen, die den beiden oben genannten sehr ähnlich ist, ist die Java Server Pages (JSP) Technologie. Diese Technologie basiert im Gegensatz zu ASP und PHP auf der stark typisierten, objektorientierten Sprache Java.
Je nach Anforderung an die umzusetzende Anwendung, gilt es die richtige Wahl der verwendeten Technologie zu treffen. Ausschlaggebend für diese ist der Anwendungsfall. Für kleinere Projekte sind durchaus skriptbasierte Technologien wie z.B. PHP, ASP oder JSP ideal, die geringe Anforderungen an den Entwickler sowie die zugrunde liegende Plattform stellen. Wird ein verteiltes System komplexer, so mangelt es den skriptbasierten Systemen oft an einfacher Erweiterbarkeit und Performanz, was zum großen Teil auch mit der Tatsache zusammenhängt, daß oft typenlose, oder schwach typisierte Sprachen zum Einsatz kommen. Ein Nachteil dieser Programmiersprachen gegenüber stark typisierten und objektorientierten Sprachen ist, daß im Allgemeinen bei steigender Komplexität, der Programmieraufwand exponential ansteigt. Die JSP Technologie bringt, unter anderem, die Vorteile einer objektorientierten Sprache mit sich. Für sehr große und komplexe Anwendungen ist dies alleine aber nicht ausreichend. Das hauptsächliche Problem ist, daß bei den genannten Technologien, die Anwendungslogik immer mit der Präsentationslogik gekoppelt vorliegt. Man möchte diese aber trennen, da bei der Entwicklung einer großen Anwendung oft verschiedene spezialisierte Teams beteiligt sind. Ein Team mit Grafikdesignern kümmert sich dabei z.B. um das Design, ein anderes mit Webprogrammierern um die Präsentationslogik und ein drittes mit Anwendungsentwicklern und Datenbankspezialisten um die Anwendungslogik und die Datenbankzugriffe. Um dies zu erreichen wurde mit der Java 2 Enterprise Edition eine Plattform geschaffen, die diese Trennung vollzieht. Die Präsentationslogik wird hier in einem sogenannten WebContainer z.B. von JSPs abgehandelt, während die Anwendungslogik im EJBContainer in sogenannten Enterprise Beans liegt. Die J2EE Technologie verspricht durch eine komponentenbasierte Architektur gute Erweiterbarkeit, Skalierbarkeit, Flexibiliät und Performanz.
Diese Arbeit befaßt sich mit der Realisierung einer webbasierten verteilten Anwendung unter Verwendung des Java 2 Enterprise Edition Framework. Das Anwendungsdesign orientiert sich am Java Application Programming Model von SUN.
Die Wahl zur Java Technologie fiel auch aufgrund der immer größer werdenden Verbreitung und der damit verbundenen einfacheren Integrationsfähigkeit und Anpassbarkeit an andere relevante Systeme. Im Vordergrund stand auch die Erweiterbarkeit und Flexibilität der Anwendung, um sie möglichst einfach von einem bestehenden System in ein neues, sich zur Zeit noch in der Entwicklung befindendes System, überführen zu können. Außerdem war es wichtig Erfahrungswerte für spätre Projekte zu sammeln, die mit der gleichen Technologie umgesetzt werden sollen.
Die Umsetzung des Systems orientiert sich an den Vorschlägen des Rational Unified Process (RUP). Für die Konzeption und Beschreibung der Anwendung und deren Abläufe wurde die Unified Modeling Language (UML) eingesetzt.
Gang der Untersuchung:
Das Kapitel Motivation und Zielsetzung geht kurz auf den Geschäftsbereich (das Business) und dessen Problematik ein und wie eine Lösung dieser Problematik aussehen könnte.
Danach werden im Kapitel Anforderungsanalyse die Anforderungen, die an das System gestellt wurden, beschrieben und spezifiziert.
Im Kapitel Analyse & Design wird auf die verwendete Architektur und deren Aufbau eingegangen. Danach wird aus der Anforderungsspezifikation das Anwendungsdesign abgeleitet und anhand eines Beispiels erklärt.
Das Kapitel Implementierung geht auf die Entwicklungsumgebung ein. Es wird erklärt mit welchen Tools entwickelt wurde und welche Schwierigkeiten es dabei gab.
Das Kapitel Test geht auf die Vorgehensweise beim Testen und auf die Performanz der verschiedenen Enterprise Bean Typen ein.
Deployment (Verteilung) ist das Thema in Kapitel 7. Hier wird auf eine mögliche Rechnertopologie eingegangen. Danach wird kurz das Vorgehen bei der Installation erklärt.
Die in der Studie erwähnte CD ist nicht im Lieferumfang enthalten, da sie für das Verständnis der Studie nicht notwendig ist.
Inhaltsverzeichnis:
| KAPITEL 1: Einleitung | 1 | |
| 1.1 | Aufbau der Diplomarbeit | 3 |
| KAPITEL 2: Motivation & Zielsetzung | 5 | |
| 2.1 | Das Problem | 5 |
| 2.2 | Die Lösung | 7 |
| KAPITEL 3: Anforderungsanalyse | 9 | |
| 3.1 | Erste Use Cases | 11 |
| 3.1.1 | ToDo-Liste checken | 11 |
| 3.1.2 | Liste zu langer Textbausteinkombinationen checken | 11 |
| 3.1.3 | Textbaustein übersetzen | 11 |
| 3.1.4 | Textbaustein kürzen | 12 |
| 3.2 | Main Use-Case | 13 |
| 3.3 | Use-Case Text suchen | 14 |
| 3.4 | Use-Case „Übersetzungsstatistik betrachten“ | 17 |
| 3.5 | Use-Case „ToDo-Liste checken“ | 19 |
| 3.5.1 | Aufbau der ToDo-Liste | 20 |
| 3.5.2 | ToDo-Liste Szenario | 21 |
| 3.6 | Use-Case“Textbaustein bearbeiten“ | 24 |
| 3.6.1 | Ablauf der Textbaustein kürzen und übersetzen Use-Cases | 26 |
| 3.6.2 | Textbaustein bearbeiten Szenario | 27 |
| 3.6.3 | Die Benutzerschnittstelle des Übersetzungsdialogs | 28 |
| 3.6.3.1 | Textprüfung | 30 |
| 3.6.3.2 | AWAT/STARI Prüfung | 31 |
| 3.6.4 | Textliste | 31 |
| 3.7 | Use-Case „Liste zu langer Textbausteinkombinationen checken“ | 34 |
| 3.7.1 | Performanz des Use-Case zu lange Textbausteinkombinationen checken | 37 |
| 3.7.2 | Die Benutzerschnittstelle zu lange Textbausteinkombinationen checken | 40 |
| 3.8 | Use-Case „zu lange Textbausteinkombination bearbeiten“ | 42 |
| 3.8.1 | Ablauf des Use-Case „zu lange Textbausteinkombination bearbeiten“ | 43 |
| 3.8.2 | Zu lange Textbausteinkombination bearbeiten Szenario | 44 |
| 3.8.3 | Benutzerschnittstelle zu lange Textbausteinkombination bearbeiten | 45 |
| 3.9 | Erweiterte Anforderungen | 47 |
| 3.9.1 | Der Login Dialog | 47 |
| 3.9.2 | Das Anwendungsmenü | 48 |
| 3.9.3 | Das Startmenü | 49 |
| KAPITEL 4: Analyse & Design | 51 | |
| 4.1 | Model-View-Controller | 51 |
| 4.2 | Die Java 2 Enterprise Edition Architektur | 53 |
| 4.2.1 | Multi-Tier Modell | 53 |
| 4.2.2 | Client-Tier | 54 |
| 4.2.3 | Web-Tier | 55 |
| 4.2.4 | EJB-Tier | 56 |
| 4.2.5 | EIS-Tier | 56 |
| 4.3 | Architekturüberlegungen | 57 |
| 4.3.1 | EJB-Zentrische Anwendung | 57 |
| 4.3.2 | Controller Komponenten | 57 |
| 4.3.2.1 | Frontkomponente | 59 |
| 4.3.2.2 | RequestProcessor | 59 |
| 4.3.2.3 | WebController | 59 |
| 4.3.2.4 | EJBController | 59 |
| 4.4 | Analyse | 60 |
| 4.4.1 | Der Übersetzer | 60 |
| 4.4.2 | Das Account Objekt | 61 |
| 4.4.3 | Textsuche | 62 |
| 4.4.4 | Die ToDo-Liste | 63 |
| 4.4.5 | Textbausteine | 65 |
| 4.4.6 | Der Übersetzungsdialog | 69 |
| 4.4.7 | Die Textliste | 71 |
| 4.4.8 | Übersetzungsstatistik | 72 |
| 4.4.9 | Liste zu langer Textbausteinkombinationen | 73 |
| 4.4.10 | Zu lange Textbausteinkombination bearbeiten | 74 |
| 4.4.11 | StateMachine | 76 |
| 4.4.12 | Der ModelUpdateManager | 77 |
| 4.4.13 | Die Events | 77 |
| 4.4.14 | Der ModelManager | 78 |
| 4.4.15 | Der ScreenFlowManager | 79 |
| 4.5 | Design | 83 |
| 4.5.1 | Servlets | 83 |
| 4.5.2 | Java Server Pages | 83 |
| 4.5.3 | TagLibraries und Custom Tags | 84 |
| 4.5.4 | XML | 84 |
| 4.5.5 | EJBs | 86 |
| 4.5.6 | Design am Beispiel | 87 |
| 4.5.7 | Exceptions | 90 |
| 4.5.8 | Der Aufbau eines Views | 91 |
| 4.5.9 | Einlesen der XML Dateien | 93 |
| 4.5.10 | Wahl des RequestHandler | 94 |
| 4.5.11 | Der SearchWebHandler | 95 |
| 4.5.12 | Der SearchFlowHandler | 96 |
| 4.5.13 | Der Insert Custom Tag | 97 |
| 4.5.14 | Das SearchBean | 98 |
| 4.5.15 | Die SearchWebImpl | 99 |
| 4.5.16 | Der SearchEvent | 100 |
| 4.5.17 | Der SearchEJBHandler | 100 |
| 4.5.18 | Die Liste geänderter Models | 101 |
| 4.5.19 | Der SearchContextEJB | 102 |
| 4.5.20 | Das SearchDAOEJB | 103 |
| 4.5.21 | Ausnahmen der Architektur | 104 |
| KAPITEL 5: Implementierung | 105 | |
| 5.1 | Java | 105 |
| 5.2 | Alternative Plattformen | 105 |
| 5.3 | Die Entwicklungsumgebung | 106 |
| 5.3.1 | Jbuilder | 106 |
| 5.3.1.1 | Entitiy Bean Modeler | 107 |
| 5.3.1.2 | Java Bean Wizard | 107 |
| 5.3.1.3 | JBuilder EJB Container | 107 |
| 5.3.1.4 | Inprise Application Server | 108 |
| 5.3.2 | Die J2EE Referenzimplementierung | 108 |
| 5.3.3 | Das Application Deployment Tool | 109 |
| 5.3.4 | Funktionsschwächen und Fehlerquellen | 110 |
| 5.3.4.1 | Debugging | 110 |
| 5.3.4.2 | Erneutes Deployen nach Änderung | 110 |
| KAPITEL 6: Test | 113 | |
| 6.1 | Vorgehensweise | 113 |
| 6.2 | Performanz | 114 |
| 6.2.1 | Enterprise JavaBeans | 114 |
| 6.2.1.1 | Overhead | 115 |
| 6.2.1.2 | Restriktionen | 115 |
| 6.2.1.3 | Performanz gegen Stabilität | 116 |
| 6.2.1.4 | Perfomanzunterschiede zwischen EJB Typen | 116 |
| 6.3 | Einsatz der Beans | 118 |
| KAPITEL 7: Deployment | 119 | |
| 7.1 | Topologie | 119 |
| 7.2 | Das Application Deployment Tool | 121 |
| 7.3 | JARs, WARs und Deployment Descriptoren | 123 |
| 7.3.1 | JARs | |
| 7.3.2 | WARs | |
| 7.3.3 | Deployment Descriptor | 123 |
| 7.3.3.1 | EJB strukturelle Informationen | 123 |
| 7.3.3.2 | Informationen zum Anwendungsaufbau | 123 |
| KAPITEL 8: Zusammenfassung & Ausblick | 125 | |
| Abbildungsverzeichnis | 129 | |
| Literaturverzeichnis & CD-ROM | 131 | |
| Glossar | 133 |
Die Textliste ist Teil des Use-Case „ Textliste betrachten“ Sie zeigt alle zu übersetzenden . Texte eines Textbausteintyps und bietet dem Übersetzer die Möglichkeit, daraus einen Text zum Übersetzen auszuwählen. Für das Erstellen dieser Liste ist eine Klasse zuständig, die TranslationList genannt wird. Die Translationlist greift auf das aktuelle TextType Objekt des TranslationContext zu und initialisiert die entsprechenden Text Objekte in dem TextType (sofern sie noch nicht initialisiert sind) mit den Quell- und Zieltexten aus der Datenbank. Dann werden sie dargestellt. Es werden dabei immer nur maximal 20 Texte dargestellt. Gibt es mehr als 20 Texte in der Liste, so bietet die Textliste die Möglichkeit in der Liste zu „ blättern“ Die Klasse TranslationList verwaltet . also diese Liste und besitzt dazu folgende Methoden: [...]
Beim übersetzen von Texten kann es vorkommen, daß zwei Übersetzer gleichzeitig an den selben Texten arbeiten. Wie geht die Anwendung damit um? Es gibt mehrere Ansätze, wie so ein Problem gelöst werden könnte. Man könnte den Datensatz, der von einem Übersetzer gerade bearbeitet wird sperren, so daß niemand anderes zur selben Zeit darauf zugreifen kann (pessimistisches locking). Oder man überprüft den Text vor dem Speichern, ob er in der Zwischenzeit bereits geändert wurde und warnt den Übersetzer, falls dies der Fall ist (optimistisches locking). Aus Gründen der Einfachheit und weil gleichzeitiges Arbeiten an ein und dem selben Text nur sehr selten auftritt, wurde hier die dritte Möglicheit gewählt. Der letzte Übersetzer, der einen Text in der Datenbank speichert, dessen Übersetzung zählt. Wurde ein Text von einem Übersetzer A bereits übersetzt und erscheint beim Übersetzer B noch in der ToDo-Liste, so wird beim Auswählen dieses übersetzten Textes, durch den Übersetzer B, die aktuelle Übersetzung schon angezeigt. Somit kann der Übersetzer B sehen, daß der Text bereits von jemand anderem übersetzt wurde. [...]
Jeder Textbaustein weiß, wie er in der Datenbank repräsentiert wird, wie seine Instanz erzeugt wird, die Quell- und Zieltexte aus der Datenbank ausgelesen werden und wie diese in der Datenbank gespeichert werden müssen. Jeder Textbaustein besitzt zwei Referenzen auf ein Text Objekt. Jedes Text Objekt repräsentiert einen zu bearbeitenden Text. Dieser Text besteht aus einem Quell- und einem Zieltext. Zusätzlich werden im Text Objekt noch zu jedem Quell- und Zieltext Informationen über Erstelldatum des Textes, Änderungsdatum, Benutzer, der den Text geändert hat, Sprache und Textlänge gespeichert. Diese Informationen werden also bei der Initialisierung eines Text Objekts aus der Datenbank ausgelesen und im Objekt abgelegt. Mit den Text Objekten wird dann gearbeitet. Jedes Text Objekt kennt dazu seinen Textbaustein und der Textbaustein weiß, wie man die Quell- und Zieltexte persistent hält. [...]
In den Warenkorb
58,00 €
Link zur Arbeit:
http://www.diplom.de/ean/9783832461737
Arbeit zitieren:
Gerlicher, Ansgar Dezember 2001: Konzeption und Realisierung einer webbasierten Anwendung mit dem Java (TM) 2 Enterprise Edition Framework, Hamburg: Diplomica Verlag
Schlagworte:
UML, Rational Unified Process (RUP), EJB - Enterprise Java Beans, MVC - Model View Controller, Verteilte Systeme



