Der Web Client

NextAusgangspunkt
Modulare Web Anwendungen sind eine vielschichtige Herausforderung. Insbesondere auch deshalb, weil Web Anwendungen naturgemäß unterschiedliche Technologien für den Client und den Server Teil einsetzen und weil sie sich in einem schnelllebigen Umfeld befinden, das eine Vielzahl an Lösungen und Umsetzungsstrategien anbietet.

Die gemeinsame Herausforderung aller Web Anwendungen aber ist die effiziente und beherrschbare Verbindung von Server Technologien und der clientseitigen Repräsentation von Daten, Logik und Bedienung in Form von HTML und JavaScript.

Dazu existieren zwei grundlegende Ansätze

  • Request/Response bei dem der Client “immer” eine “neue” Seite vom Server anfordert und erhält
  • Asynchrone Kommunikation (AJAX, WebSockets) bei dem der Client aktiv “nur” Teile von Seiten oder Daten je nach Bedarf vom Server abruft

Das Request/Response Verfahren, basierend auf dem HTTP Protokoll, ist das klassische Verfahren. Von Struts bis Java Server Faces existieren eine große Anzahl an Technologien und Frameworks, die im Kern monolithische Anwendungen (.war Paket) zur Generierung von HTML sind. Diese Technologien legen i.d.R. ihren Schwerpunkt auf serverseitige Verarbeitung (siehe z.B. JSF Life Cycle). Der Client ist im Prinzip “nur” eine Art Terminal, das Bildschirmmasken in Form von HTML abruft/erhält.

AJAX basierte Systeme arbeiten im Prinzip genau umgekehrt. Sie stellen den Client als “echte” Client Anwendung im Browser dar und nutzen den Server proaktiv um sich mit Daten zu versorgen. Daher stehen bei diesen Systemen HTML bzw. JavaScript Technologien und Frameworks im Vordergrund.

Die ISA Web Architektur
Die ISA Architektur bzw. Enterprise Apps vereinheitlichen auf einfache Weise beide Welten, indem sie für beide Prinzipien und alle Technologien eine einzige universelle Basis Plattform zur Verfügung stellen – Module.

Eine ISA Web Anwendung oder eine ISA Web API1 ist daher keine *.war Datei, kein Verzeichnis mit HTML Seiten und auch keine Sammlung von Scripten – eine ISA Web Anwendung ist ein ISA Modul(e), das beliebige andere Module nutzt und das in/über einen Browser bzw. generell über HTTP aufgerufen werden kann z.B.

http://integrating-architecture.de/ServiceBroker/web/?service=isa.web.FormDemo:getInfoSite[version=1.*] Go ->

Die obere URL ruft das Modul isa.web.FormDemo, das als unabhängige .jar Datei im zentralen Repository liegt mit dessen Service getInfoSite auf. Das Ergebnis ist in diesem Fall dann die entsprechende Seite. Oder ein einfacher Web API Service wie z.B.

http://integrating-architecture.de/ServiceBroker/web/?service=isa.web.FormDemo:getMessage data=[{_id:-1},true] Call ->

Das klingt vielleicht zunächst banal – eröffnet aber weitreichende Möglichkeiten – zum einen weil dem eindeutigen Java Modul alle Fähigkeiten (Kommunikation, Austauschbarkeit, Versionierung, Verwaltung etc.) eines ISA Moduls zur Verfügung stehen und zum anderen weil das Modul vollkommen frei in der Wahl der Mittel zur Erzeugung von Seiten oder beliebigen anderen Daten ist. Zum Beispiel:

  • selbst erzeugtes HTML und/oder Javascript (programmiert, generiert oder gelesen etc.)
  • Nutzung eines Java Web Frameworks
  • Nutzung eines JavaScript Frameworks
  • Lieferung von Daten aus jeder Quelle in jedem gewünschten Format … usw.

Im Browser wird lediglich eine einfache JavaScript Funktion benötigt, die einen ModulService Request entweder über http oder über AJAX auf dem Service Broker absetzen kann.

$ISA.callService({'module':'isa.web.FormDemo:getInfoSite', 'props':'[version=1.*]'}, data);

bzw. für Web-Browser Inhalte standardisiert

$ISA.getContent({'element':'isa-web-formdemo', 'module':'isa.web.FormDemo', 'props':'[version=1.*]'});

Diese Funktion ruft dann den Standarddienst getContent(…) auf, der hier als Konvention für das Web Interface von Modulen dient. Auf diese Weise kann jedes Modul auch im Web genutzt werden (siehe auch Web Formular Demo) ohne spezielle Programmierung, ohne spezielle Java Web Technologien und ohne Web Server Einschränkungen.

Das Prinzip

Eingebettete Web Module

Durch diesen Aufbau entsteht ein rekursiv, verlinktes System, das allen notwendigen Programm- und/oder Html Code automatisch und nach Bedarf zur Laufzeit im Client Browser zusammenstellen kann – wobei die Datenquelle nicht mehr auf den Web Server an sich beschränkt ist – sondern durch die serverseitigen, eindeutigen Java Module realisiert wird. Diese liefern neben dem Client Content (Html, JavaScript etc.) auch die benötigten Server Dienste und die Anwendungsdaten (z.B. als JSON Dokumente) und sind so gleichzeitig eine Web API.

Der Aufbau

Modulare Web Architektur

Auf diese Weise können Java Module wie serverseitige “Scripte” ähnlich wie bei PHP genutzt werden. Die notwendige Compilierung fällt dabei kaum ins Gewicht, weil keine ganze Anwendung gebaut und deployed werden muss.

Letzteres vereinfacht insbesondere die Entwicklung und den Test und reduziert dort die Turnaround-Zeiten erheblich. Das ISA Modulsystem eröffnet das Web zunächst völlig ohne zusätzliche Technologien, Konstrukte oder Verfahren … es gibt

  • keine Konfigurations- oder Mappingdateien (wie z.B. Web.xml oder Faces-config.xml)
  • keine festgelegten Verzeichnis oder Paketstrukturen
  • keine Template- oder Generierungsverfahren
  • keine Technologiegrenzen

Insofern ist das ISA Modulsystem und seine Anwendung im Web auch kein Web Framework im üblichen Sinne. Der “ISA Web Client” ist einfach die Möglichkeit Modularität und transparente Kommunikation für Web Anwendungen zu nutzen um deren Entwicklung von aufwendigen, starren und unveränderlichen Verfahren und Technologien zu befreien.

Die “ISA Web Client” Architektur ist dabei viel mehr als ein AJAX Aufruf – denn der ist an sich nur ein Stück unspezifische Kommunikationstechnik. Mit ISA wird er jedoch zu einem semantisch und inhaltlich wohl definierten Funktionsbaustein, der unabhängig von einer spezifischen Server Technologie ist.

_______________________
1: Die ISA Web Architektur unterscheidet nicht zwischen Web-Anwendung und Web-API so wie sich z.B. eine JSF Anwendung und eine REST API unterscheiden. Es gibt keine unterschiedlichen Technologien – sondern es werden für alle Anwendungsbereiche immer Module genutzt. (siehe auch … der Unterschied zu REST)