Bau betrieblicher Informationssysteme mit J2EE WS2004/5
Dies ist die Veranstaltungsseite zur Vorlesung und Übung "Bau betrieblicher Informationssysteme mit Java2 Enterprise Edition (J2EE)".Beschreibung
Betriebliche Informationssysteme (BIS) im Sinne dieser Vorlesung sind Softwaresysteme, die direkt die Geschäftsabläufe (im Bürobereich) von Firmen unterstützen oder abwickeln. In der Praxis sind BIS heute groß, komplex, heterogen und ständigem Wandel unterworfen. Java2 Enterprise Edition (J2EE) ist eine Sammlung von Spezifikationen von Sun, deren Implementierungen (die von unterschiedlichen Herstellern verfügbar sind) die Realisierung von BIS mit modernen Softwarearchitekturen und -methoden stark erleichtern. Dazu gehören insbesondere die Unterstützung für den Bau von Web-basierten Benutzungsschnittstellen, von transaktionsbehafteten Server-seitigen Komponenten, von persistenter Datenhaltung und von diversen Integrationsmechanismen. Die Vorlesung stellt die Aufgabenstellungen (nichtfunktionalen Anforderungen) vor, die beim Bau von BIS zu lösen sind und behandelt die diversen Teiltechnologien von J2EE aus dem Blickwinkel, was sie jeweils dazu beitragen und wie (und wie nicht) sie eingesetzt werden sollten. In der Übung werden an kleinen und mittelgroßen Beispielen die Grundzüge der J2EE-Programmierung behandelt. Ziel der Vorlesung ist eine überblickshafte Kenntnis von J2EE, samt einer Reihe grundlegender Entwurfsentscheidungen und technischer Details, sowie eine gewisse Urteilskraft für den sinnvollen Einsatz dieser Technologie für den Bau von BIS und ein Verständnis der wesentlichen Teilaufgaben und ihrer Hauptschwierigkeiten.Organisatorisches
Veranstalter
- LutzPrechelt (Vorlesung)
- Stephan Salinger (Übungsleitung)
Voraussetzungen/Zielgruppe, Einordnung, Leistungpunkte etc.
Siehe den Eintrag im KVV.Die Veranstaltung ist geeignet für Diplom, Master und Nebenfach. Man sollte zuvor die Vorlesungen Softwaretechnik und Datenbanksysteme gehört haben und gute Java-Programmierkenntnisse, Spaß am Arbeiten mit dem Rechner, eine präzise Arbeitsweise und genügend Zeit mitbringen.
Übungsbetrieb
Die Vorlesung ist nicht allzu kompliziert, aber die Übungen sind recht detailreich, fehleranfällig und dementsprechend zeitaufwendig.
Zur Teilnahme wird ein Rechner unter Linux oder Windows benötigt, der möglichst mindestens 512 MB Hauptspeicher und 1 Gigabyte freien Plattenplatz haben sollte. Es muss JDK 1.4.2 oder höher installiert sein. Teilnahme mit Mac ist grundsätzlich ebenfalls möglich, kann aber Tücken haben.
Jeder Teilnehmer sollte im Laufe der Veranstaltung mindestens eine seiner Lösungen in den Übungen vorstellen. Dabei sind die im Folgenden ausgeführten Regeln bzgl. der technischen Voraussetzungen und der Präsentationsinhalte und -struktur zu beachten.
Regeln bzgl. der technische Voraussetzungen bei der Präsentation von Lösungen in den Übungen
Die Lösung muss für die Präsentation als Distribution und im Sourcecode zur Verfügung stehen. Hierbei sind zwei Szenarien zulässig:1. Die Präsentation findet auf dem eigenen mitgebrachten Laptop statt
In diesem Szenario sind folgende Punkte zu beachten:- Der Rechner (bzw. die Graphikkarte) muss vorher für den Betrieb an einem Beamer konfiguriert und getestet sein.
- Die entwickelte Applikation sollte betriebsfertig installiert und somit direkt aufrufbar sein. Dies heißt z.B. für den Fall von Webapplikationen, dass die fertige Anwendung schon in einen lokalen Webcontainer „deployed“ und somit über einen Browser aufrufbar ist.
- Der Sourcecode sollte über die verwendete Entwicklungsumgebung (z.B. Eclipse) präsentiert werden. Hierbei sollten auch die einzelnen Schritte des Entwicklungsprozesses (Editieren, Compilieren, Deployen etc.) direkt durchführbar sein.
2. Die Präsentation findet auf dem Laptop des Veranstalters statt
Hierzu müssen der Sourcecode sowie die Distribution auf einem USB-Stick vorhanden sein. Im Einzelnen sind folgende Punkte zu beachten:- Die Distribution muss bei Desktopprogrammen direkt vom USB-Stick aus ausführbar sein.
- Bei J2EE-Applikationen muss die Distribution in Form eines passenden Archives zur Verfügung stehen. Bei Webapplikationen ist dies eine WAR-Datei. Das Deployment des Archives sollte auf jeden Fall vorher getestet sein. Es ist darauf zu achten, dass die Applikation einen eindeutigen Namen bekommt (<nachname>_<übungsnummer>), so dass nicht mit einem Konflikt mit bereits installierten Applikationen gerechnet werden muss.
- Die Distribution darf nicht abhängig von vorinstallierten Bibliotheken sein (muss diese also im Zweifelsfall mitliefern)!
- Im günstigsten Fall liegt der Sourcecode als Eclipse-Projekt vor, so dass er einfach in die vorhandenen Eclipseumgebung importiert werden kann. Sollte dies nicht der Fall sein, steht zur Präsentation der Sourcen Ultraedit zur Verfügung.
Damit all dies funktioniert, steht auf dem Laptop des Veranstalters eine Java/J2EE-Infrastruktur zur Verfügung, wie im Übungsblatt 2 beschrieben (nur zur Information: Der Laptop des Veranstalters läuft unter XP).
Falls weder ein eigener Laptop noch ein USB-Stick zur Verfügung steht, sollte man sich rechtzeitig (nicht erst am Tag der Präsentation) mit dem Veranstalter in Verbindung setzen.
Regeln bzgl. der Präsentationsinhalte und –struktur
Während der Präsentation muss die laufende Applikation vorgeführt und der entwickelte Sourcecode präsentiert werden. Das Wort Präsentation ist hier ernst zu nehmen: Der Präsentator versucht, seine Lösung strukturiert und gut verständlich dem Publikum darzulegen. Dies kann nur dann funktionieren, wenn man sich vorher Gedanken über die Präsentation macht! Es sind folgende Punkte zu beachten:- Es ist sicherzustellen, dass der Sourcecode in einem geeignet Font dargestellt wird, so dass er auch in den letzten Reihen des Raumes gelesen werden kann.
- Zu Beginn sollten die Ziele der Aufgabe noch einmal kurz rekapituliert und die speziellen Herausforderungen der Aufgabestellung klar umrissen werden.
- Die Präsentation der Sourcen sollte einen roten Faden durch die Applikation liefern. Hierbei sollte z.B. der Beschreibung in den Übungsblättern gefolgt werden (wobei Teilschritte, die nur mit der Einarbeitung in die Materie zu tun haben, weggelassen werden).
- Man sollte sich vorher überlegt haben, welche Teile eines Code-Dokumentes zentral sind und erläutert werden sollen. Das reine Vorlesen des gesamten Sourcecode reicht nicht!
- Wichtig ist es, dass Zusammenspiel der unterschiedlichen Teile der Applikation zu verdeutlichen. Dies betrifft z.B. den Kontrollfluss (ggf. unter Berücksichtigung des verwendeten Frameworks).
- Probleme, die beim Erstellen der Lösung auftraten (und hoffentlich gelöst wurden), sollten an den passenden Stellen wiedergegeben werden. Die betrifft auch Fehler, die bei der Entwicklung gemacht wurden. Vielleicht können andere daraus etwas lernen.
- Man sollte darauf eingerichtet sein, auf Nachfrage bestimmte Stellen des Codes im Detail zu erklären (Hintergrundwissen!).
- Da es in vielen Aufgaben auch das Ziel ist, eine Distribution (z.B. eine WAR-Datei) zu erzeugen, sollte in der Präsentation auch darauf eingegangen werden (z.B. WELCHE Bibliotheken WIE eingebunden wurden).
- Die Präsentation sollte eine professionelle Vorstellung der eigenen Arbeit sein.
Termine
- Vorlesung:
- Mo, 12-14 Uhr, Raum 005
- Übung:
- Mo, 14-16 Uhr, Raum 046
- Scheinklausur:
- Mo, den 14.02.2005, 12:01Uhr, Raum 005
- Klausureinsicht:
- Montag, 11.04.2005, 16:00 Uhr bis mindestens 16:30 Uhr im SR 051, Takustr. 9
Prüfungsmodalitäten
Kriterien für den Erwerb des Übungsscheins (Diplom) bzw. der Leistungspunkte (Bachelor) sind- die regelmäßige Bearbeitung der Übungsblätter;
- regelmäßige Teilnahme an den Übungen, einschließlich Vorführung und Erläuterung der Ergebnisse der Übungsaufgaben;
- Bestehen der Klausur.
Inhalt
Allgemeine Literatur
Spezielle Literatur
- EJB-Architekturbenchmark bei urbancode.com
Stoffplan
| Materialien (Folienzahl) | Inhalte | Zeit [45'] |
|---|---|---|
| 0 Einführung | 1 | |
| Einfuehrung (46) Reflection/Beans/RMI (18) | Betriebliche Informationssysteme (EIS); Java2 Enterprise Edition (J2EE); Lernziele; wichtige Java-Grundlagen | 1 |
| 1 Anforderungen und Randbedingungen | 1 | |
| Anforderungen (25) | Randbedingungen von EIS-Entwicklung; nichtfunktionale Anforderungen an EIS; Anwendungsbau vs. Fertigsoftware (z.B. ERP) vs. Anwendungsintegration (EAI) | 1 |
| ZIP | Übung 1: Java Reflection, Anforderungen | . |
| 2 Architektur von EIS | 4 | |
| Archit.einfuehrg. (15) | Grundbegriffe: Architektur und nichtfunktionale Anforderungen; Teilarchitekturen und Sichten; Evolution der Drei-Schichten-Architektur; Funktionale vs. physische Schichtung | 0.5 |
| Architektur (46) | Was bedeutet Architektur und warum braucht man sie? Architektonische Stile, Architekturmuster; Herleitung von Architekturen mit Unit Operations; Architektursichten; Facharchitektur versus technische Architektur |
1.5 |
| Übung 2: Installation und Inbetriebnahme einer J2EE-Infrastruktur | . | |
| EAI (34) EAI (7) | Enterprise Application Integration | 2 |
| ZIP | Übung 3: Java RMI | . |
| 3 Benutzungsschnittstellenschicht | 8 | |
| Einfuehrung (10) | Arten Web-basierter GUIs (reines HTML, DHTML, Javascript, Applet, Web Start); deren Vor- und Nachteile | 0.5 |
| Servlet (32) Ant (28) | Basistechnologie für Web-basierte Schnittstellen aller Art: Servlets; Exkurs: Automatisierung von Übersetzen, Einpacken, Deployment u.v.a.m. mit Ant | 1.5 |
| ZIP | Übung 4: Ant, .war, web.xml, Servlets | . |
| JSP (49) JSP-Tipps (11) | Trennung von Inhalt und Präsentation: Java Server Page (JSP), Entwurfsmuster Model-View-Controller; Verwendungshinweise für JSP | 2 |
| ZIP | Übung 5: Servlet für Binärdaten, Java Server Pages, JSTL, MVC | . |
| Struts (43) | Ein Framework zur Unterstützung einer sauberen Model-View-Controller-Struktur: Jakarta Struts | 2 |
| ZIP | Übung 6: Struts |
. |
| Portlets (68) | Modulares Zusammenbauen dynamischer Webseiten aus 'Portlets': abaXX elements Web-UI | 2 |
| ZIP | Übung 7: Portlets |
. |
| Zusammenfassung (--) | (Web-)Benutzungsschnittstellen: Zusammenfassung und Übersicht | -- |
| 4 Anwendungsschicht | 12 | |
| Einführung (8) | Nochmal Anforderungen: Verteilung, Transaktionen, Sicherheit, Verfügbarkeit, Skalierbarkeit | 1 |
| JNDI (18) | Zugang zu serverseitigen Komponenten: Java Naming and Directory Interface (JNDI) | 1 |
| Übung 8: Systemkonfiguration, JNDI | . | |
| EJB (85) JTA (18) Tipps (36) EJB-Schwächen (9) | Enge Integration mit verteilten, transaktionsgeschützten serverseitigen Komponenten: Enterprise JavaBeans (EJB); Manuelle Steuerung von Transaktionen: Java Transaction API (JTA); Verwendungshinweise zur EJB und Entwurfsmuster; Kritik an EJB | 4 |
| Übung 9: EJB, xdoclet |
. | |
| JMS (55) | Integration über Nachrichtenkopplung: Java Messaging Service (JMS) | 2 |
| Übung 11: JMS, AppServer-Konfiguration, xdoclet | . | |
| JCA (20) | Integration über Adapter: Java Connector Architecture (JCA) | 1 |
| Sicherheit (23) | Sicherheitsmechanismen in J2EE: Authentisierung ("Wer ist da?"), Authorisierung ("Darf der das?"), Verschlüsselung | 1 |
| Übung 12: Sicherheitsmechanismen |
. | |
| Webservices (37) | Integration über Webservices: SOAP (Fernaufrufe per XML über z.B. http), WSDL (XML-Beschreibungen der Schnittstellen von Webservices), UDDI (Finden von Webservices nach vorgegebenen Kriterien), JAX-RPC (Abbildung zwischen Java Klassen und Webservice-Schnittstellen) | 2 |
| Übung 13: Axis, WSDL, Webservice-Aufruf | . | |
| Zusammenfassung (--) | Zusammenfassung und Übersicht, Sonstiges (Workflow) | -- |
| 5 Datenhaltungsschicht | 2 | |
| -- | DBMS: relational vs. objektorientiert; Objektmodell vs. Persistenzmechanismus | -- |
| JDBC (28) EJB Entity Beans (30, s. oben) andere (11) | Persistenzmechanismen: JDBC, EJB Entity Beans, JDO, Apache Torque, Hibernate, Apache OJB, ofbiz Entity Engine | 2 |
| 6 Nachbemerkungen | 0 | |
| -- | Zusammenfassung und Übersicht; Was nicht behandelt wurde | -- |
Historie des Stoffplans
WS 2004/2005:- Weggelassen:
- ?
- Zugefügt:
- ?
- Verändert:
- ?
- erste Durchführung