Modulare Web Formular Demo

Die folgende Demo zeigt ein Web Formular, das als Enterprise Apps Modul isa.web.FormDemo-1.0.0 (siehe auch ISA Web Client) in diese WordPress Seite eingebunden ist. Das Java Modul befindet sich im zentralen Repository und beinhaltet die Services, die hinter den Schaltflächen liegen, sowie die Formularoberfläche.

Die Verarbeitung findet in Java, die Anbindung über Java Script im Browser statt, das ebenfalls dynamisch vom Modul geladen wird. Damit kann ein solches Java Modul wie ein serverseitiges Script (z.B. PHP) verwendet werden, das allen notwendigen Code (Java, Html, JavaScript) und damit auch alle Möglichkeiten vereint.

Als Backend für die Formulardaten dient hier eine Dokumenten-Datenbank (MongoDB) in der die gesendeten Daten als JSON Dokumente gespeichert werden. Die Datenbank ist als serverseitiges Modul eingebunden.

JavaScript Code für die Einbindung des Web-Formular-Moduls in diese Seite

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

Das eingebettete Formular Modul (s.a. WebClient Prinzip)

Ein Dialog auf Basis des Dojo Web Frameworks
http://integrating-architecture.de/ServiceBroker/web/?service=isa.web.FormDemo:getInfoSite[version=1.*]

Ein “REST” Service Aufruf auf dem FormDemo Modul
http://integrating-architecture.de/ServiceBroker/web/?service=isa.web.FormDemo:getMessage[version=1.*]data=[{_id:-1},true]

Ein gesperrter Service Aufruf über http GET
http://integrating-architecture.de/ServiceBroker/web/?service=isa.web.FormDemo:getContent[version=]

Eine POST Notification z.B. aus GitHub
SCM Repositories, CI Systeme und andere Entwicklungswerkzeuge bzw. Anwendungssysteme allgemein unterstützen häufig eine Web bzw. REST API zur remoten Nutzung und Kommunikation. GitHub z.B. bietet sog. WebHooks auf Basis von POST und JSON mit denen ein ISA System ohne Aufwand eingebunden werden kann. GitHub benötigt dazu nur eine entsprechende Web-Adresse, an die es dann entsprechende Nachrichten verschickt. Z.B.

  • Ein Notification Service-Endpoint für z.B. Commits
    http://integrating-architecture.de/ServiceBroker/?service=isa.System:doSCMNotification[version=1.*]

Auf diese Weise können ISA Module auch leicht zur Realisierung spezieller, eigener Funktionalitäten im Rahmen des Entwicklungsprozesses selbst genutzt werden – ohne dabei die fachliche Systemintegrität zu gefährden.

Der Unterschied zu REST
Die Beispiele zeigen, dass der Begriff “REST Service” für die ISA Web Schnittstelle eigentlich nicht passend ist, weil jedes ISA Modul automatisch und von sich aus über HTTP GET und POST ansprechbar ist (wenn erlaubt) und dafür weder auf dem Client noch auf dem Server etwas speziell programmiert werden muss. … siehe auch Netzwerk aus Modulen und Funktionen. ISA “REST” bietet zudem eine wesentlich klarere und einfachere URL Syntax, da alle benötigten Informationen als Modul-Resource-Identifier (MRI) in einem einzigen Parameter enthalten sind

  • /?service=<Modulname>:<Dienst>[<Property>=<Wert>, ...] data=[<Wert>, ...]

und nicht wie bei REST üblich in einer Mischung aus Pfad und Query Parametern. Zudem ist ISA “REST” inhaltlich nicht auf die üblichen HTTP Befehle (GET, POST, DELETE … etc.) beschränkt, sondern führt immer einen Modul-”CALL” aus. Die ISA Web Anbindung nutzt HTTP nur noch als Transportschicht – aber nicht mehr als Protokoll an sich und ist damit sowohl einfacher als auch semantisch viel klarer.

Insbesondere führt die modulbasierte ISA Web API keinen neuen Architekturstil für Anwendungen und/oder Dienste ein – dadurch werden weder Analysten noch Designer oder Entwickler gezwungen konkret funktionale Anforderungen auf generelle Methoden und abstrakte Ressourcen abzubilden.