Stefan Reichert

Stefan Reichert
Stefan Reichert, Diplom-Wirtschaftsinformatiker (FH), arbeitet als Software Engineer bei Zühlke Engineering in Hamburg. Er beschäftigt sich seit mehreren Jahren mit verteilten Java-Enterprise-Anwendungen, serviceorientierten Architekturen, Eclipse und Eclipse RCP. Seit einiger Zeit begeistert ihn die Entwicklung von Apps mit Android. Darüber hinaus ist er Buchautor und verfasst regelmäßig Fachartikel. Kontakt: stefan[at]wickedshell.net, http://www.wickedshell.net/blog
Beiträge dieses Autors

Enterprise Eclipse RCP: Continuous Integration

Die in den drei bisherigen Teilen vorgestellten Eclipse-Bordmittel, Methoden und Techniken stellen eine solide Basis zur Entwicklung von verteilten Anwendungen mit Eclipse RCP dar. Die Entwicklung einer verteilten Anwendung erfolgt in der Regel im Team. Nicht nur aus diesem Grund besteht die Notwendigkeit, die gesamte Codebasis automatisiert zu testen. Für gewöhnlich übernimmt diese Aufgabe ein System wie CruiseControl oder Hudson. Der vierte Teil der Serie über Enterprise Eclipse RCP beschäftigt sich mit dem Thema Continous Integration und zeigt, wie Eclipse-RCP-Anwendungen mithilfe von Plug-in-Tests als Ganzes getestet werden können.

Enterprise Eclipse RCP – Teil 3

Eclipse RCP etabliert sich zunehmend als Frontend für verteilte Anwendungen im Unternehmensbereich. Nachdem der zweite Teil der Reihe „Enterprise Eclipse RCP detailliert den Aspekt der Verteilung und das clientseitige Caching beleuchtet hat, beschäftigt sich der dritte Teil mit dem Thema Security und Fehlerhandling. Beide Bereiche sind stark mit dem Thema Verteilung bzw. Kommunikation verwoben, sodass sich Elemente der im Artikel beschriebenen Lösungen auf das im vorhergehenden Teil beschriebene Spring Remoting beziehen.

Enterprise Eclipse RCP – Teil 2: Remoting und Caching

Nachdem wir im ersten Teil von Enterprise Eclipse RCP einen Überblick über die Entwicklung von Enterprise-RCP-Applikationen gegeben haben, wollen wir uns in diesem Artikel mit dem Themenkomplex der Kommunikation zwischen Frontend und Backend beschäftigen. Wie bereits im Überblicksartikel dargelegt, gibt es verschiedene Varianten für die Architektur von verteilten Eclipse-RCP-Anwendungen: Client/Server, d.h. der Client greift direkt auf die Datenbank zu, und 3+ Tier, d.h. der Client kommuniziert mit einem Backend-System, das die Geschäftslogik enthält. In diesem Artikel wollen wir zeigen, wie eine Eclipse-RCP-Anwendung mit einer klassischen Drei-Schichten-Architektur umgesetzt werden kann. Dazu zeigen wir zunächst, wie die Kommunikation zwischen Frontend und Backend umgesetzt werden kann. Anschließend gehen wir auf mögliche Probleme ein und zeigen Lösungen hierfür auf.

Eclipse RCP im Test

Java hat zu Unrecht den Ruf, sich nur schlecht für die Realisierung von grafischen Benutzeroberflächen zu eignen. Insbesondere im Unternehmensumfeld wurde in den vergangenen Jahren vorzugsweise auf HTML gesetzt, um Java EE-Anwendungen mit Benutzeroberflächen zu versehen. Eclipse RCP vereinfacht die Realisierung von unternehmenstauglichen Desktopanwendungen. Dies bleibt jedoch nicht ohne Auswirkungen auf die Architektur der gesamten Enterprise-Anwendung.