Donnerstag, 29. September 2011
Service Portale als Integrationslayer
In vielen Betrieben steht heute eine Vielfalt von Applikationen im Einsatz, die jede einen Teil der geschäftlichen Prozesse abdeckt. Der Endkunde, sollte diese Stückelung jedoch nicht wahrnehmen, sondern alle Funktionen in einer für ihn logischen Gruppierung vorfinden. Um diese Brücke zu schlagen, muss ein Element geschaffen werden, das die verschiedenen Applikationen integriert und in einer übergreifenden Oberfläche verfügbar macht.
>> Newsletter Bericht als PDF runterladen
1. Die Herausforderung
In vielen Betrieben steht heute eine
Vielfalt von Applikationen im Einsatz, die jede einen Teil der geschäftlichen
Prozesse abdeckt. Diese Applikationen sind untereinander in der Regel über Batch-Jobs
und Schnittstellen verbunden, bilden aber eine relativ lose Landschaft, in der
die Grenzen zwischen den Applikationen häufig mehr durch die Geschichte als
durch funktionale Logik bestimmt werden.
Der Endkunde, der das Service Portal nutzt,
sollte diese Stückelung jedoch nicht wahrnehmen, sondern alle Funktionen in
einer für ihn logischen Gruppierung vorfinden.
Um diese Brücke zu schlagen, muss ein Element
geschaffen werden, das die verschiedenen Applikationen integriert und in einer
übergreifenden Oberfläche verfügbar macht.
2. Lösungsansätze
2.1. Service Orientierte Architektur
Der in den letzten Jahren stark verfolgte
SOA-Ansatz sieht vor, dass jede Applikation ihre Funktionen in der Form von
Services, d.h. technischen Schnittstellen für andere Applikationen, anbietet.
Eine neu zu erstellende Frontend-Applikation nutzt dann diese Services und
stellt alle diese Funktionen dem Benutzer zur Verfügung. Diese
Frontend-Applikation übernimmt auch alle übergreifenden Aufgaben wie
Benutzerauthentifizierung, Navigation etc.
Dieser Ansatz erlaubt eine klare Trennung
der Verantwortlichkeiten und eliminiert die technologie-bezogenen
Abhängigkeiten zwischen den Applikationen und dem Frontend, da die in der Regel
verwendete Webservice-Technologie hier als allgegenwärtige Brücke fungiert.
In der Praxis ist dieser Ansatz jedoch
aufwändig, weil für jede Erweiterung oder Anpassung mehrere Teile angepasst
werden müssen: die eigentliche Applikation anhand der neuen fachlichen
Anforderungen; die Schnittstellendefinition (Vertrag zwischen den Systemen),
sowie die Implementationen der Schnittstellen in Applikation und Frontend, um
die Funktionalität für das Frontend verfügbar zu machen; schliesslich das
Frontend selber, um eine Benutzerschnittstelle für die Funktion anzubieten.
Einerseits ist der Aufwand recht hoch, weil viele Teile anzupassen sind,
andererseits entstehen so auch planerische Abhängigkeiten, welche hinderlich
sein können.
Hinzu kommt, dass in diesem Ansatz das
Frontend Abläufe und Funktionen aus allen Applikationen und Bereichen vereint
und daher die Entwicklung des Frontends sehr viel Fachwissen aus allen
betroffenen Bereichen und viel fachliche Koordinationen mit den Applikationen
erfordert. Dies schränkt die Autonomie der Systeme effektiv ein.
2.2. Portal mit Reverse Proxy
Im Unterschied zum SOA-Ansatz bieten die
Applikationen in diesem Modell keine technische Schnittstelle für Umsysteme,
sondern direkt eine Benutzerschnittstelle für Endbenutzer an. Somit ist die
gesamte fachliche Verantwortung bei der Applikation, was bezüglich
Knowhow-Verteilung und Flexibilität in der Weiterentwicklung eine Erleicherung
darstellt.
Das vorgelagerte Portal übernimmt die nicht
applikations-spezifischen Aufgaben wie z.B. die Authentifizierung des Benutzers
sowie applikations-übergreifende Aufgaben wie das Session-Handling, die
Verwaltung der Navigation und das Layout.
In diesem Fall werden die Anfragen vom
Benutzer/Browser zunächst durch das Portal entgegengenommen und analysiert und
anschliessend an die zuständige Applikation weitergeleitet. Die gesamte
fachliche Verarbeitung erfolgt in der Applikation, welche dann auch die Antwort
(in Form einer gewöhnlichen HTML-Seite) aufbereitet. Diese Antwort wird dann
wiederum vom Portal analysiert und bei Bedarf ergänzt oder angepasst und anschliessend
an den Browser zurückgegeben.
Dieser Ansatz vereint den für die
Weiterentwicklung wichtigen Aspekt der Autonomie der Systeme mit einer
integrierten, flexiblen Benutzerführung für den Endkunden und einer sehr klaren
Aufteilung der Verantwortlichkeiten zwischen den Systemen.
3. Referenz-Implementation: TaxMe-Portal der Steuerverwaltung des
Kantons Bern
Die oben skizzierte Portal-Architektur
wurde im TaxMe-Portal der Steuerverwaltung des Kantons Bern implementiert und
hat in den letzten Jahren die erwarteten Vorteile vollumfänglich zur Geltung
gebracht. Die folgenden echten Szenarien zeigen, wie sich dies in der Praxis
geäussert hat.
3.1. Neue Applikationen und Funktionen
In den letzten 3 Jahren wurden mehrere neue
Applikationen und zahlreiche neue Funktionen in bestehenden Applikationen in
das Portal eingeführt. Dazu war in keinem Fall eine Codeanpassung am Portal
notwendig. Vielmehr konnten die Applikationen anhand ihrer jeweiligen
Release-Pläne realisiert oder weiterentwickelt werden; die Einbindung der neuen
Funktionen in das Portal war dann lediglich eine Konfigurationsanpassung,
welche die Systemverantwortlichen selber vornehmen konnten.
Gegenüber dem früher praktizierten
SOA-Ansatz konnte die Durchlaufzeit für solche Anpassungen deutlich reduziert
werden, da jeweils nur noch eine Applikation ohne Abhängigkeiten zu
berücksichtigen und zu planen war.
3.2. Neuer Anmeldemechanismus axsionics Internet Passport
Als Alternative zur klassischen Codeliste
kann für die Anmeldung am TaxMe-Portal seit einiger Zeit auch das axsionics
Internet Passwort verwendet werden. Die entsprechenden Erweiterungen wurden am
Portal und dem zuständigen Backend-Login-Service vorgenommen; keine der
Applikationen musste für diese neue Möglichkeit angepasst werden.
3.3. Aufschaltung von Erklärungen zu einer Funktion
Nach der Produktivschaltung einer neuen
Funktion zeigt sich eine Häufung von Supportanfragen, weil eine Formular für
viele Endkunden nicht verständlich ist.
Durch die (wiederum rein konfigurative) Anpassung der Navigation im Portal wird
auf die betroffene Funktionsseite ein Hinweisblock (aus dem CMS) eingebunden,
welcher die Unklarheit erwähnt und auf weitere Erläuterungen (immer noch im
CMS) verweist. Die CMS-Seite mit den Erläuterungen wiederum wird mit der
eigentlichen Funktion verlinkt.
Durch die Möglichkeit, die Benutzerführung
so ohne Anpassungen in der Fachapplikation und damit ohne Abhängigkeit von einem
Release flexibel anzupassen, kann das Volumen von Supportanfragen (und damit
auch die entsprechenden Kosten) kurzfristig reduziert werden. Auf den nächsten
ordentlichen Release hin kann die Applikation selbstverständlich optimiert
werden, so dass die hinzugefügten Hinweise wieder entfernt werden können.
4. Architektur
4.1. Authentifizierung im Portal
Die Authentifizierung der Benutzer (d.h. die
Abklärung, wer einen Aufruf ausführt) wird vom Portal gesteuert.
Dazu nutzt das Portal sogenannte Security
Token Services (STS), welche jeweils für einen bestimmten Anmeldemechanismus
die angegebenen Daten prüfen und ein signiertes Token ausstellen, das die
erfolgreiche Anmeldung bestätigt. Die Benutzerschnittstelle (Web-Interface)
kann entweder direkt im STS oder aber im Portal realisiert werden (im letzteren
Fall erfolgt die Anbindung des STS gemäss SOA über Webservices).
Durch die modulare Architektur kann ein
einziges Portal verschiedene Arten von Benutzern und Anmeldeverfahren
unterstützen. Insbesondere interessant ist dies z.B. im Zusammenhang mit
Anmeldemechanismen wie der SuisseID oder axsionics Internet Passport, da die
entsprechende Komplexität ausschliesslich im Portal bzw. den relevanten STS
berücksichtigt werden muss und nicht in den Fachapplikationen.
Das Portal initialisiert dann mit dem
Token, das sich aus dem Anmeldevorgang ergibt, die neue Benutzersitzung.
4.2. Session-Handling inklusive Navigation
Das Portal führt für jeden angemeldeten
Benutzer eine Sitzung mit allen relevanten Daten. Am Anfang der Sitzung werden
die Applikationen angefragt, welche Funktionen sie für diesen Benutzer
anbieten. So können die Applikationen für verschiedene Arten von Benutzern
verschiedene Funktionen anbieten; welche Kriterien sie dafür verwenden, steht
ihnen völlig frei.
Das Portal stellt dann anhand der
verfügbaren Funktionen und der konfigurierten Sitemap für den Benutzer eine
persönliche Navigation zusammen. Diese Navigation dient dann zum Aufbau von
Menüs, Krümelnavigation etc., aber auch für die Verlinkung zwischen
Applikationen.
Die so zusammengestellte persönliche
Navigation enthält typischerweise eine Mischung aus statischen Seiten mit
Erklärungen (jeweils aus dem CMS stammend) und von Funktions-Seiten aus
Applikationen. Der Aufbau der Sitemap und damit die Anordnung der verschiedenen
Arten von Seiten in der Navigation ist reine Konfiguration im Portal und somit
von den Applikationen unabhängig. Dies schafft eine hohe Flexibilität bei
Anpassungen.
Die Zusammenstellung der Seiten in der
Navigation erfolgt aus Prozess-Sicht und fachlichen Überlegungen; sie soll den
für den Kunden logischen Ablauf abbilden und nicht, welche Fachapplikation eine
bestimmte Funktion anbietet. Entsprechend oft sind benachbarte
Navigationspunkte Funktionen verschiedener Applikationen und gleichzeitig die
Funktionen einer einzelnen Applikation in verschiedenen Bereichen der Sitemap
verstreut.
4.3. Reverse Proxy mit Anreicherung
Jeder Applikation wird ein Pfad in der Url
zugewiesen, z.B. www.portal.ch/app1/xxxx geht an app1. Alle HTTP-Requests auf
eine solche Url werden dann an die Applikation weitergeleitet, wobei das Portal
die Daten aus der Benutzersitzung, insbesondere das Anmelde-Token, sofern der
Benutzer angemeldet ist, als HTTP-Header hinzufügt. So kann die Applikation
diese Informationen nutzen.
Zudem verwaltet das Portal Cookies, so dass
die Applikation alle Möglichkeiten, die sie mit einem normalen Browser ohne das
zwischengelagerte Portal hätte, auch nutzen kann. Cookies der Applikationen
können sitzungsbezogen sein oder im Benutzerprofil persistiert werden. Jede
Applikation sieht nur ihre eigenen Cookies, so dass hier keine Konflikte
entstehen können.
Die Applikation kann die von ihr
bereitgestellte HTTP-Antwort mit einem HTTP-Header kennzeichnen, um das Portal
zu veranlassen, die Seiten in das Portal-Layout zu überführen. Dazu entnimmt
das Portal dann ein bestimmtes div aus dem HTML-Body und fügt dieses in das
Portal-Layout ein, bevor es die finale Antwort an den Browser ausliefert. Ohne
entsprechenden Header werden die Antworten 1:1 weitergeleitet, so dass auch
AJAX-Szenarien, Binär-Antworten etc. möglich sind.
4.4. Branding, Navigation, Linking
Normale Inhaltsseiten, die mit dem
entsprechenden HTTP-Header gekennzeichnet sind, werden vom Portal in eine
einheitliche Darstellung gebracht: Das Portal liefert Header, Navigation,
Footer sowie entsprechende CSS-Stylesheets etc., so dass die Darstellung über
die Applikationen hinweg einheitlich ist (dies setzt selbstverständlich voraus,
dass alle Applikationen sich an einem einheitlichen Styleguide orientieren und
die entsprechenden HTML-Konstrukte und CSS-Klassen verwenden).
Zudem wird die Navigation dargestellt,
wobei der aktive Punkt hervorgehoben wird. Die Applikation muss daher nicht
wissen, wo die aktive Funktion in der Navigation untergebracht ist. Benachbarte
Navigationspunkte können von verschiedenen Applikationen stammen und/oder für
verschiedene Benutzer verschieden sein.
4.5. Verknüpfung und Zusammenführung von Applikationen
Da das Portal die HTML-Antwort der
Applikation vor der Auslieferung an den Browser verarbeitet, kann es darin
enthaltene Platzhalter ersetzen. Typische Anwendungen für diese Möglichkeit
sind applikationsübergreifende Links (definiert durch abstrakte Funktions-IDs,
welche das Portal durch echte Urls ersetzt) sowie sogenannte Portlets.
Portlets erlauben es, Inhalte aus verschiedenen
Applikationen in einer Seite darzustellen. Dazu setzt die Applikation, welche
den Request für die aktuelle Seite verarbeitet hat, Platzhalter mit
spezifischen CSS-Klassen und Markierungen ein. Das Portal erzeugt daraus
jeweils einen weiteren Request an die darin referenzierte Applikation und
ersetzt den Platzhalter durch die von dieser anderen Applikation gelieferte
Antwort. Auf einer Seite können durchaus mehrere Portlets vorkommen und diese
können Daten aus verschiedenen Applikationen beziehen.
Insbesondere in Kombination mit der
Einbindung des CMS als Applikation schafft diese technische Möglichkeit eine
grosse Flexibilität: Applikationen können z.B. Platzhalter für
Erläuterungstexte anbieten, die dann im CMS gepflegt werden; umgekehrt
können CMS-Seiten statt nur Erläuterungen auch direkt aktuelle Daten aus
Applikationen einbinden und so eine flüssigere Benutzerführung ermöglichen.
5. Zusammenfassung
Der Einsatz eines Portals mit Reverse Proxy
Technologie stellt eine hoch attraktive Kombination von integrierter
Benutzerführung und Unabhängigkeit der Applikationen dar. Der ausgeprochen
modulare Aufbau einer solchen Lösung schafft sowohl bezüglich Weiterentwicklung
als auch bezüglich Deployment maximale Flexibilität und stellt damit eine
zukunftsgerichtete, solide Basis dar.
Selbstverständlich ist nie eine einzelne
technische Lösung für jede Aufgabenstellung geeignet – genau deshalb bietet
GARAIO eine ganze Palette von Lösungsansätzen und -technologien an, z.B. auch
auf der Basis von Microsoft SharePoint. Gerne sprechen wir auch mit Ihnen über
Ihre Bedürfnisse im Bereich Service Portale und über mögliche Lösungen.
Ihre Kontaktperson:
Leo von Wyss
Senior Consultant, Partner
<< zurück zum Newsletter
