Komponentenmodelle für Web-Anwendungen
- Art: Diplomarbeit
- Autor: Christian Osterrieder
- Abgabedatum: Juli 2004
- Umfang: 166 Seiten
- Dateigröße: 3,4 MB
- Note: 1,0
- Institution / Hochschule: Paris-Lodron-Universität Salzburg Österreich
- ISBN (eBook): 978-3-8324-8119-3
-
ISBN (Paperback) :
978-3-8324-8119-3 P - ISBN (CD) :978-3-8324-8119-3 CD
- Sprache: Deutsch
- Prämierung:
- Arbeit zitieren: Osterrieder, Christian Juli 2004: Komponentenmodelle für Web-Anwendungen, Hamburg: Diplomica Verlag
- Schlagworte: COBRA, J2EE, .NET, Web Services, Enterprise JavaBeans
In den Warenkorb
48,00 €
Diplomarbeit von Christian Osterrieder
Zusammenfassung:
Die Diplomarbeit vergleicht die de-facto-Standards der komponentenbasierten Softwareentwicklung und die Spezifikationen und Frameworks zur Entwicklung von Web-Anwendungen, die mit den untersuchten Komponentenmodellen in Verbindung stehen.
Um die Ziele dieser Diplomarbeit zu erreichen, wurden im Kapitel 2 die Grundlagen der komponentenbasierten Softwareentwicklung vorgestellt. Anschließend wurde ein Überblick über die Komponentenmodelle und Spezifikationen der de-facto-Standards CORBA, der Enterprise JavaBeans, des .NET Frameworks und der Web-Services gegeben. Das Kapitel 2 schließt mit einem Vergleich der vorgestellten Komponentenmodelle, welcher durch eine tabellarische Übersicht verdeutlicht wurde.
Kapitel 3 beschäftigt sich in erster Linie mit Grundlagen und Architekturen von Web-Anwendungen. Dabei wurden die wichtigsten Anforderungen an Web-Anwendungen beschrieben, welche als typische Eigenschaften von Web-Anwendungen gesehen werden können. Diese Anforderungen wurden in einem Kriterienkatalog zusammengefasst. Er gilt als Verlgleichsgrundlage der beschriebenen Techniken. Ein Überblick über die Architekturen von Web-Anwendungen schafft einen Einblick in mehrschichtige Architekturen und deren Middleware. Ein oft verwendetes Entwurfsmuster für Architekturen von Web-Anwendungen ist das Model-View-Controller-Muster, welches abschließend in Kapitel 3 beschrieben wurde.
In Kapitel 4 wurden die Spezifikationen und Frameworks der beschriebenen Komponentenmodelle, im Zusammenhang mit Web-Anwendungen, näher untersucht. Die Untersuchungen beziehen sich auf die Architekturen der jeweiligen Spezifikationen und Frameworks und deren Lösungsstrategien um den in Kapitel 3 gefundenen Anforderungen aus dem Kriterienkatalog gerecht zu werden.
Praktisches Ziel der Diplomarbeit war die Entwicklung einer komponentenbasierten Web-Anwendung in Form eines Terminkalenders. Die dazu notwendigen Aktionen sind in Kapitel 5 zusammengefasst. Dazu wurde zuerst die zu entwickelnde Web-Anwendung spezifiziert, indem funktionale und nicht-funktionale Anforderungen an die Anwendung erhoben wurden. Anschließend erfolgte eine Auseinandersetzung mit den Vor- und Nachteilen der vorgestellten Techniken von CORBA, der J2EE Spezifikation, dem .NET Framework und er Web-Services um ein geeignetes Komponentenmodell für den Terminkalender zu finden. Die Entscheidung fiel auf die J2EE Spezifikation und Web-Services. Die restlichen Abschnitte beschreiben schließlich den Entwicklungsprozess des Terminkalenders und einer Synchronisationsanwendung. Diese Synchronisationsanwendung dient dazu, die Kalenderdaten mit Hilfe eines Web-Services und eines so genannten Conduits, mit einem Handheld-Computer der Firma Palm zu synchronisieren. Dabei wurden die Architekturen der Anwendungen vorgestellt und Probleme bei der Softwareentwicklung und deren Lösungen beschrieben.
Das Kapitel 6 versucht abschließend einen Ausblick auf künftig zu erwartende Entwicklungen, für komponentenbasierte Softwareentwicklung von Web-Anwendungen, zu geben. Insbesondere wurde dabei auf das semantische Web eingegangen.
Inhaltsverzeichnis:
| 1. | Einleitung | 1 |
| 1.1 | Zielsetzung | 2 |
| 1.2 | Gliederung | 2 |
| 2. | Beschreibung von Komponentenmodellen | 4 |
| 2.1 | Grundlagen der komponentenbasierten Softwareentwicklung | 4 |
| 2.1.1 | Begriffe und Definitionen | 4 |
| 2.1.2 | Grundidee der komponentenbasierten Softwareentwicklung | 6 |
| 2.2 | Die de-facto-Standards der komponentenbasierten Softwareentwicklung | 9 |
| 2.2.1 | Die Common Object Request Broker Architecture | 10 |
| 2.2.2 | Die Enterprise JavaBeans der Java 2 Enterprise Edition | 17 |
| 2.2.3 | Die Assemblies des .NET Frameworks | 24 |
| 2.2.4 | Web-Services | 29 |
| 2.2.5 | Vergleich der Komponentenmodelle | 34 |
| 3. | Beschreibung von Web-Anwendungen | 42 |
| 3.1 | Grundlagen | 42 |
| 3.1.1 | Begriffe und Definitionen | 42 |
| 3.1.2 | Anforderungen an Web-Anwendungen als Kriterienkatalog | 45 |
| 3.2 | Architekturen | 49 |
| 3.2.1 | Mehrschichtige-Architekturen | 50 |
| 3.2.2 | Middleware | 52 |
| 3.2.3 | Model-View-Controller-Muster | 54 |
| 4. | Architekturen und Lösungsstrategien fürWeb-Anwendungen | 56 |
| 4.1 | Common Object Request Broker Architecture (CORBA) | 56 |
| 4.1.1 | Architektur | 56 |
| 4.1.2 | Lösungsstrategien zu den Anforderungen anWeb-Anwendungen | 57 |
| 4.2 | Java 2 Enterprise Edition (J2EE) | 63 |
| 4.2.1 | Architektur | 64 |
| 4.2.2 | J2EE-Anwendungen nach dem Model-View-Controller-Muster | 66 |
| 4.2.3 | Lösungsstrategien zu den Anforderungen anWeb-Anwendungen | 66 |
| 4.3 | NET Framework | 73 |
| 4.3.1 | Architektur | 73 |
| 4.3.2 | Lösungsstrategien zu den Anforderungen anWeb-Anwendungen | 74 |
| 4.4 | Web-Services | 80 |
| 4.4.1 | Architektur | 80 |
| 4.4.2 | Lösungsstrategien zu den Anforderungen anWeb-Anwendungen | 80 |
| 5. | Terminkalender als komponentenbasierte Web-Anwendung | 87 |
| 5.1 | Anforderungen an das Produkt | 87 |
| 5.1.1 | Begriffe für KALENDARO | 87 |
| 5.1.2 | Die Akteure von KALENDARO | 88 |
| 5.1.3 | Funktionale Anforderungen | 91 |
| 5.1.4 | Nichtfunktionale Anforderungen | 97 |
| 5.2 | Auswahl des Komponentenmodells | 97 |
| 5.2.1 | Common Object Request Broker Architecture | 98 |
| 5.2.2 | NET Framework | 99 |
| 5.2.3 | Java 2 Enterprise Edition | 100 |
| 5.2.4 | Web-Services | 100 |
| 5.2.5 | Ausgewähltes Komponentenmodell | 101 |
| 5.3 | Architekturentwurf | 101 |
| 5.3.1 | Architektur der Web-Anwendung | 102 |
| 5.3.2 | Architektur der Synchronisationsanwendung | 104 |
| 5.4 | Entwicklung der Web-Anwendung | 105 |
| 5.4.1 | Verwendete Entwicklungswerkzeuge und Plattformen | 105 |
| 5.4.2 | Der Persistenzmechanismus von KALENDARO | 108 |
| 5.4.3 | Entwicklung der Synchronisationsanwendung | 110 |
| 5.5 | Bewertung der Web-Anwendung und Schlussfolgerungen | 114 |
| 5.5.1 | Bewertung der Anforderungen aus dem Kriterienkatalog | 114 |
| 5.5.2 | Schlussfolgerungen | 118 |
| 6. | Ausblick | 119 |
| 7. | Zusammenfassung | 121 |
| Anhänge | 123 | |
| Anhang A | Anwendungsfälle | 123 |
| Anhang A.1 | Paket Terminkalender | 123 |
| Anhang A.2 | Paket Terminteilnahme | 126 |
| Anhang A.3 | Paket Suche | 128 |
| Anhang A.4 | Paket Verwaltung | 129 |
| Anhang A.5 | Paket Administration | 133 |
| Anhang A.6 | Paket Conduit | 135 |
| Anhang B | Datenbankschema | 138 |
| Anhang C | Document Type Definition der Synchronisationsdateien | 139 |
| Anhang D | WSDL Beschreibung der Web-Services zur Kalendersynchronisation | 141 |
| Glossar | 143 | |
| Abkürzungsverzeichnis | 147 | |
| Literatur | 151 |
[Schmietendorf 02]. Es soll den Anwendungsentwickler von komplexen Aufgabenstellungen, wie beispielsweise der Autorisierung und Authentifizierung oder der Überwachung, entlasten [Schmietendorf 02]. Ziel dabei ist es, vorhandene Sicherheits-Infrastrukturen von bereits bewährten Modellen zu integrieren [Backschat 02]. In einer J2EE Umgebung lassen sich Bereiche gemeinsamer Sicherheit festlegen. So können sich Komponenten die sich in einem gemeinsamen Container befinden und den gleichen Sicherheitsrichtlinien unterliegen, gegenseitig vertrauen. Dieser Sicherheitsbereich (Protection Domain) kann auch auf mehrere Container erweitert werden und zum Beispiel gemeinsam für den Web-Container und den EJBContainer gelten [Backschat 02]. (a) Vertraulichkeit: Für die Vertraulichkeit von Daten können Sicherheitsprotokolle wie das Secure Sockets Layer (SSL) Protokoll oder die Transport Layer Security (TLS) verwendet werden [Schmietendorf 02]. Mit der Standardisierung des Secure Sockets Layer durch die Internet Engineering Task Force im Jahre 1999 wurde das Secure Sockets Layer Protokoll mit dem neuen Begriff Transport Layer Security erweitert. Die aktuelle Transport Layer Security Version unterscheidet sich nur in wenigen Details von der aktuellen Secure Sockets Layer Version [Dierks 99] und wird daher in dieser Arbeit nicht gesondert beschrieben. Die Verantwortung einer sicheren Datenübertragung der J2EE Spezifikation liegt beim jeweiligen Container, deren Realisierung ist daher herstellerspezifisch. (b) Integrität: Die Integrität von Daten ist, wie die Vertraulichkeit, vom jeweiligen Container abhängig und wird üblicherweise durch Secure Sockets Layer realisiert [Backschat 02]. Secure Sockets Layer verwenden hierfür einen Message Authentication Code (Hash-Algorithmus MD5 oder SHA1), dessen Grundlage ein gemeinsamer geheimer Schlüssel bildet. Die Daten werden anschließend mit Hilfe symmetrischer Verschlüsselung verschlüsselt [Freier 96]. (c) Authentifizierung: Für Web-Anwendungen mit J2EE können zum Nachweis der Identität, drei verschiedene Mechanismen zum Einsatz kommen: die HTTP Basic Authentication, die Form Based Authentication und die SSL Mutual Authentication. Die jeweilige Methode kann über den Deployment Descriptor festgelegt werden [Backschat 02]. [...]
Die Anwendungsserver-Schicht besteht meist aus einem Web-Container für Servlets oder JSP Seiten und dem EJB-Container. Servlets sind Klassen der Programmiersprache Java, die dynamisch Anfragen (engl. requests) von Clients bearbeiten und darauf Antworten (engl. responses) erzeugen [Armstrong 04]. JSP Seiten sind textbasierte Dokumente, die als Servlets ausgeführt werden. Sie ermöglichen beispielsweise die Einbettung von Java-Quellcode in HTML Seiten. Im EJB-Container befindet sich die wichtigste Geschäftslogik mit den Enterprise JavaBeans. Die Enterprise JavaBeans können Informationen des Client-Programmes empfangen, wenn nötig verarbeiten und an die Enterprise Information System Schicht (kurz EIS-Schicht) zur Speicherung weiterleiten. Enterprise JavaBeans können auch den umgekehrten Weg einleiten, indem sie Informationen der EIS-Schicht empfangen, falls nötig bearbeiten und an das ClientProgramm weiterleiten [Armstrong 04]. Die Anwendungsserver-Schicht stützt sich auf die Java 2 Enterprise Edition, welche auf die Java 2 Standard Edition aufbaut und sie um serverseitige Erweiterungen ergänzt, um Web-Anwendungen und andere verteilte Anwendungen zu entwickeln [Backschat 02]. [...]
In der Präsentationsschicht können verschiedene Arten von Clients bedient werden. Neben Light-Clients die für gewöhnlich einen Browser repräsentieren, sind dies auch oft Small-Clients oder Fat-Clients. Zu den Small-Clients zählen mobile Geräte wie beispielsweise ein Handheld-Computer oder ein Mobiltelefon. In dieser Schicht können sich auch Anwendungen der Programmiersprache Java befinden, die so genannten Fat-Clients. Ein Beispiel für Fat-Clients sind Java-Applets, welche als Client-Anwendungen in einer virtuellen Maschine am Browser ausgeführt werden [Armstrong 04] [Göldi 02]. Ein weiterer Spezialfall sind externe Computersysteme von Geschäftspartnern, mit denen Daten ausgetauscht werden, zum Beispiel über Web-Services [Göldi 02]. Die Java Anwendungen der Präsentationsschicht stützen sich auf die beiden Editionen Java 2 Standard Edition (J2SE) und Java 2 Micro Edition (J2ME). Die erstgenannte Edition ist hauptsächlich zur Entwicklung von Desktop-Anwendungen und Applets gedacht. Die zweite ist speziell auf mobile Geräte ausgerichtet [Backschat 02]. [...]
In den Warenkorb
48,00 €
Link zur Arbeit:
http://www.diplom.de/ean/9783832481193
Arbeit zitieren:
Osterrieder, Christian Juli 2004: Komponentenmodelle für Web-Anwendungen, Hamburg: Diplomica Verlag
Schlagworte:
COBRA, J2EE, .NET, Web Services, Enterprise JavaBeans



