Regulär geht man davon aus, dass die servergespeicherten Daten einer User Session immer nur von einem Thread zur selben Zeit gelesen bzw. geschrieben werden. Es ist zu aufwendig, jede Stelle im Code welche mit der User Session arbeitet vor Race Conditions durch Mutext-Objekte / Monitore zu schützen. Daher muss dafür gesorgt werden, dann ein Request aus einer User Session immer nacheinander aber nicht parallel verarbeitet werden. Im Folgenden wird ein Code-Beispiel für J2EE Web Applikationen gegeben.
Endlich ist es soweit. Der Web-Dienst OpenWishes.de, welcher dabei hilft den Geschenkestress zu überstehen und keine Geburtstage mehr zu vergessen, ist online und damit in der Public Alpha. Diese Plattform entstand in den letzten Monaten in Zusammenarbeit mit Markus Kühle und Markus Junginger. Ich nutze dieses Ereignis um einen Überblick auf die verwendeten Technologien zu geben.
Die Infrastrukturkomponenten des Systems sind Apache Tomcat 6, Apache und MySQL. Es wurde bewusst auf EJB oder Spring verzichtet, jedoch ist die Persistenzschicht mittels JPA / Hibernate umgesetzt. Die Web Tier ist mittels Java Server Faces 1.2 und Facelets realisiert, wobei die JSF-Komponentenbibliothek RichFaces 3.1 und DWR für die Ajax-Funktionalität eingesetzt wird. Für verschiedene Querschnittsbelange wie Exception-Handling, Transaktionshandling, Logging und Ermitteln von Statistikdaten kommt AspectJ zum Einsatz. Asynchrone und zeitgesteuerte Jobs werden mittels Quartz verwaltet. Eine interne Management-Schnittstelle setzt auf JMX / MX4J auf. Das Versenden von Mails wird über Apache Commons Mail realisiert.
Die Plattform selbst ist in Java implementiert, wobei voll auf die Syntax von Java 5 (Generics & Co) gesetzt wird. Durch die Verwendung von AspectJ und Java5 enstand unserer Meinung nach ein sehr erweiterungsfähiges und gut wartbares System da sich der Code auf das Wesentliche beschränkt. Wir hatten und haben das Gefühl, dass wir sehr produktiv bei der Entwicklung und Erweiterung des Systems arbeiten können.
Es gibt noch eine Menge zu tun – neue Features befinden sich in Entwicklung und warten auf das nächste Release. An dieser Stelle die Bitte um Feedback und die Aufforderung OpenWishes.de zu nutzen. Ich werde auf jeden Fall ab heute keine Geburtstage mehr vergessen!
Eine Java Serverapplikation muss oft in verschiedene Umgebungen (auch als Raum bezeichnet) installiert werden. Oft gibt es eine Testumgebeung, eine für die Integration und Fachtests, eine Schulungsumgebung und letztendlich eine Produktivumgebung. Für jede Umgebung müssen oft die Konfigurationsdateien und auch Deployment-Deskriptoren angepasst werden.
Gerade die Deployment-Deskriptoren wie “web.xml” (im WAR), “application.xml” (im EAR) unterscheiden sich marginal. Wäre es da nicht toll nur eine Deskriptor-Datei im Versionskontrollsystem zu halten und nur die marginale Änderungen mittels XSLT vorzunehmen. Natürlich wäre es das!
Mit Eclipse 3.3 gibt es endlich die Möglichkeit beim Speichern einer Java-Datei automatisch Code Bereinigungen und Formatierung durchzuführen. Die Einstellung hierfür kann im Eclipse-Projekt definiert werden und nicht ausschließlich Workspace-weit. Das ist ein Vorteil, denn dann können diese Einstellungen ins Versionskontrollsystem aufgenommen und somit implizit im gesamten Entwicklungsteam verfügbar gemacht werden. Auf diese Weise garantiert man eine einheitliche Formatierung im Projekt.
Dieser Artikel zeigt einen Ansatz, wie man in Java-Software-Projekten unerlaubte Abhängigkeiten zwischen Klassen / Paketen / Subsystemen / Layern erkennt und frühzeitig während der Entwicklung anzeigt. Dieser Ansatz verwendet AspectJ um Compile-Warnungen für Abhängigkeitsverletzungen zu definieren.
Eine nicht funktionale Anforderung an Software-Systeme wird gemeinhin mit dem Begriff “Security” umrissen. Ein Teilaspekt betrifft die Authorisierung von Benutzern / Fremdsystemen gegenüber bestimmten Diensten oder Daten. Bei mehrschichtigen Softwaresystemen, die eine Datenbank in der Ressourcenschicht einbinden, ist die Authorisierung oft Aufgabe der Geschäftsschicht.
Ein anderer Ansatz stellt die Realisierung der Authorisierung direkt in der Datenbank dar. Diesen Ansatz findet man oft in Alt-Systemen, bei denen zumal auch Geschäftslogik in der Datenbank in Form von Stored Procedures umgesetzt ist. Damit die Datenbank Authorisierungsfunktionen übernehmen kann, muss der tatsächliche Benutzer an die DB propagiert werden.
| |
Im Rahmen dieses Artikels möchte ich ein wenig Know-How für die Implementierung dieses Ansatzes in Verbindung mit dem Oracle-DBMS (Datenbankmanagementsystem), Connection Pooling im Weblogic Application Server und JDBC weitergeben. Dieses Know-How entstammt der Anbindung einer Produktdatenbank bei einem großen Deutschen Automobilhersteller. Zum Einsatz kommt eine proprietäres Feature des Oracle-DBMS – die Oracle-Proxy-Sessions.
