Tool-Radar: CaptainCasa Enterprise Client

Björn Müller

Vorne im Frontend: ein generischer, Swing-basierter Client. Hinten im Server: JSF. Das zusammen ergibt eine RIA-Lösung für operativ genutzte, umfangreiche, serverbasierte Anwendungssysteme.

Im Sommer 2007 formierte sich eine Gruppe mittelständischer Softwarehäuser, die für ihre Anwendungssysteme eine langlebige User-Interface-Lösung suchten. „Rich“ sollte das User Interface sein und insbesondere die Anforderungen operativer Benutzer abbilden: hohe Performance, Tastatursteuerung, Drag & Drop, komplexe Komponenten. Java-Standard-basiert sollte die Serverumgebung ebenfalls sein, denn hier gilt es, all das mitzunehmen, was standardbasierte Serverumgebungen so mit sich bringen: Skalierbarkeit, Failover-Konzepte, Security.

Alle Softwarehäuser brachten eine große Portion Ajax-Know-how mit – und die Erkenntnis: das Ajax-Eis hat seine dünnen Stellen. Probleme bei der Rendering-Performance, der Kompatibilität zwischen Browsern und der 7x24h-Stabilität – alles Dinge, die bei operativ genutzten Anwendungen kritisch sind.

Abb. 1: Beispiel-Workspace in CaptainCasa

Und somit besann man sich auf das gute „alte“ Java Swing im Frontend: mittlerweile sehr performant und stabil, auf allen Betriebssystemen im Client verfügbar und über Applet oder Webstart in Internetseiten einbindbar – sozusagen „Industry proven“ und mit neuer Aktualität durch Java FX und Java 1.6 Update 10.

Generische Swing-Client-Architektur

Kommen wir zum Wie der Swing-Nutzung – und zu der zunächst verwunderlichen Tatsache, dass man bei CaptainCasa gar nicht direkt mit Swing in Berührung kommt. Es sei denn, es werden neue grafische Komponententypen hinzugefügt.

Vorne im Client läuft eine generische Rendering Engine, die in Swing implementiert ist. Dieser Client kommuniziert über http(s) mit dem Server: Er bekommt vom Server eine XML-Layoutbeschreibung, rendert diese aus und schickt Requests, wenn der Benutzer entsprechende Eingaben tätigt. Eigentlich alles so, wie bei einem „normalen“ Browser, nur dass statt HTML ein bestimmtes XML über die Leitung geht. Dieses XML ist für die Belange von Rich Clients optimiert: Nur Änderungen werden übertragen und folglich auch nur Änderungen im Client gerendert. Entsprechend hoch ist die Clientperformance (Abb. 2).

Abb. 2: Client-Server-Kommunikation bei CaptainCasa

Fragt sich nun, wie das XML produziert wird, das der Client verarbeitet. Kommen wir also zum Serverteil.

JSF-basierter Server

JSF als serverseitiges UI-Framework wurde von Beginn an darauf ausgelegt, nicht nur den HTML-Browser zu unterstützen, sondern auch andere, Nicht-HTML-Browser. Letztlich ist die Kernfunktion von JSF ja die, einen Komponentenbaum mit Events zu versorgen und rekursiv auszurendern. Ob jetzt dabei HTML gerendert wird oder XML, liegt in der Natur der Komponente bzw. des Renderers.

Alle Komponenten, die von dem generischen Swing-Client unterstützt werden, liegen als entsprechende JSF-Komponenten vor. CaptainCasa bringt also keine eigene Serverumgebung mit sich mit, sondern zieht als Komponentenbibliothek in eine JSF-Serverumgebung ein.

Entwicklungsprozess

Das Layout einer Seite wird, so es statischer Natur ist, als XML-Definition innerhalb einer .jsp-Seite formuliert. Die Logik, die an das Layout angebunden wird, wird in Form von Managed Beans zur Verfügung gestellt und über JSF-Expressions in den Komponenten einer Seite referenziert. Seiten können beliebig ineinander geschachtelt werden.

Das Tool der Wahl zum Erstellen der .jsp-Seiten ist ein WYSIWYG-Layouteditor, der Bestandteil der Toolumgebung ist. Spezielle JSF-Kenntnisse sind somit von dem Anwendungsentwickler nicht gefordert.

Komponentenbibliothek

Die Komponentenbibliothek umfasst „normale“ Komponenten (Feld, Label, Checkbox etc.), Listen mit frei wählbaren Spaltenkomponenten, komplexe Tree-Komponenten, Reporting-Komponenten, Wizards, Popups usw. – bis hin zu Touchscreen-Komponenten. Schließlich liegt ja das Augenmerk auf operativ genutzten Anwendungen.

Der Zusammenbau der Komponenten ist an HTML-Konzepte angelehnt: Containerkomponenten enthalten Zeilen, in die dann die nächsten Komponenten platziert werden. Das Sizing einer Komponente geschieht entweder prozentual oder pixelbasiert, wobei alle Pixelwerte noch einmal eine Skalierung im Client durchlaufen.

Auf Basis der Komponenten können Styles definiert werden, über die verschiedene Standardattribute pro Komponente (z.B. Hintergrundgestaltung) gesetzt werden. Die Komponentenbibliothek ist erweiterbar.

Corporate Community

Hinter CaptainCasa steht eine Corporate Community: Diese trifft sich alle vier Monate, um Erfahrungen auszutauschen und Prioritäten der Entwicklungen zu definieren. CaptainCasa Enterprise Client ist keine Open Source. Aber: Community-Mitglieder haben entsprechenden Sourcenzugriff und entsprechende Rechte. Die Community ist offen – neue Mitglieder sind also willkommen.

Einstieg

CaptainCasa kann frei genutzt werden: ohne Garantien, ohne Service, aber frei. Den Download gibt es unter www.CaptainCasa.com. Der Download enthält eine komplette Einstiegsumgebung inklusive Tools und Dokumentation. Für Fragen und Anregungen gibt es ein Community-Forum.

Geschrieben von
Björn Müller
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.