CAS Technologie-Upgrade

Das Kreditentscheidungssystem CAS (Credit Approval System) ist seit mittlerweile fast vier Jahren sehr erfolgreich im Kundeneinsatz.

 

CAS Produktlogo - automatisierte Kreditentscheidungen mit CASDie technischen und architektonischen Grundlagen des Systems sind in Konzept- und Planungsphasen auf Basis der vor fünf Jahren verfügbaren Technologien entwickelt worden. Das ist - in der sich relativ schnell entwickelnden Welt der Application-Server basierten Webanwendungen - eine lange Zeit, in der sich die eingesetzten technischen Komponenten (JAVA EE2, JBOSS 4.3, JBOSS Portal 2.7, JSF 1.2, Hibernate etc.) zum Teil deutlich weiterentwickelt haben. Zusätzlich gab es eine Menge an Erfahrungen und Erkenntnissen, wie sich einzelne Architekturmerkmale im Praxiseinsatz unter Kosten und Nutzenaspekten bewährt haben.

Das ReDesign – CAS NT entsteht

JBoss

Im Laufe des Jahres 2013 wurde beschlossen, CAS mit einer neuen Version auf Basis des aktuellen Technologie-Stacks weiterzuentwickeln. Dabei sollten die bisherigen Erfahrungen mit der ersten Version analysiert und die daraus gewonnen besseren Ansätze in die Entwicklung einfließen. Da das System erfolgreich im Betrieb ist, sollte sich für den Anwender in Ablauf und Oberfläche der Anwendung möglichst wenig ändern, um Umstellungs- und Schulungskosten weitgehend zu vermeiden. Da sich im Rahmen des Technologie-Stacks die JBOSS-Technologie bestens bewährt hat, wurde als Basis ein aktuelles JBOSS Paket (7.2) gewählt. Es ergaben sich einige weitere wichtige Designänderungen, die im Folgenden näher beleuchtet werden.

Wie setzt man SOA am effektivsten ein?

Eine grundsätzliche Entscheidung bei der Konzeption der ersten CAS Version war die Realisierung als Serviceorientierte Architektur (SOA). Die Anwendung sollte intern möglichst flexibel mit Hilfe von lose gekoppelten Services agieren, die entweder als Webservice oder direkt als EJB Service aufgerufen werden.

CAS Portal

Dazu wurde eine Architektur entwickelt, die sehr stark vertikal nach fachlichen Gesichtspunkten die einzelnen Bausteine schneidet, so wie es in der Theorie dem idealen SOA Ansatz entspricht. Als Ergebnis gab es dann pro fachlichem Funktionsblock ein Modul, welches den gesamten fachlichen Code inklusive der Oberflächen enthielt, z.B. ein Modul Sicherheiten, ein Modul Kalkulation etc. Daraus musste eine übergangslose Integration hergestellt werden, um für den Anwender aus der Ansammlung von Services eine leicht bedienbare und konsistente Applikation zu erzeugen.

Es zeigte sich in der Analyse, dass dieser ideale SOA Architekturansatz zwar funktioniert und die Anwendung damit technisch extrem flexibel ist, aber diese Flexibilität in weiten Teilen gar nicht genutzt wird. Außerdem bringt eine extreme Entkoppelung zwar Vorteile wie z. B. getrenntes Deployment und Release-Management der einzelnen fachlichen Bausteine, dies wird jedoch erkauft mit Performancenachteilen (zum Beispiel sehr häufige Serialisierung von Objekten zwischen Bausteinen) sowie erheblichen redundanten Codebestandteilen.

Außerdem ist im Rahmen des abzubildenden Prozesses (der Kreditentscheidung) die Koppelung zwischen einzelnen Bausteinen so eng, dass ein getrennter Einsatz ohnehin nicht sinnvoll ist und ein getrenntes Deployment somit keine Vorteile bringt. Um dieses Dilemma aufzulösen, wurde zwar das grundlegende Konzept einer SOA Anwendung beibehalten und es werden weiterhin Funktionen in gekoppelten Services verwendet. Jedoch werden einzelne Module nur noch da mit der notwendigen flexiblen Austauschbarkeit versehen und eingesetzt, wo auch ein konkreter Anwendungsfall im Einsatz bei verschiedenen Kunden besteht. Ein Beispiel für die Notwendigkeit eines solchen flexiblen Moduls ist die Kundenstammdatenverwaltung, die bei jedem CAS Kunden unterschiedlich aussieht und daher mit dem passenden Adapter angekoppelt werden muss. Auch bei der Konzeption von SOA Anwendungen ist es also extrem wichtig, die Balance zwischen den Kosten bzw. Nachteilen einer strikten SOA Konzeption und einer Konzeption im Sinne von „SOA dort, wo es tatsächlich sinnvoll ist und genutzt wird“ sorgfältig abzuwägen. Extreme Flexibilität kostet immer Aufwand und damit Geld und kann kein Selbstzweck sein, sondern muss Mehrwert im Sinne von Wiederverwendbarkeit und insbesondere geringerer TCO liefern.

Portal vs. Webanwendung

Eine weitere wichtige Entscheidung musste im Hinblick auf die Implementation und Integration der Oberfläche getroffen werden. JSF als Mittel der Programmierung der einzelnen Portlets (respektive Seiten) der einzelnen Funktionen stand außer Frage. In der ersten Version von CAS wurde das JBOSS Portal als Oberflächenklammer und zentrale Steuerungskomponente genutzt. Bei einer Umstellung dieser Komponente auf das neue JBOSS GateIn Portal hätte sich die Frage gestellt, wie wir innerhalb von CAS weiter verfahren. Eine Analyse ergab auch hier, dass wir von den eigentlichen Portalfunktionalitäten lediglich ca. 20% genutzt haben, wesentliche Funktionen wie zum Beispiel benutzerindividuelle Portalkonfiguration sind in einer Anwendung wie CAS nicht erforderlich oder widersprechen sogar einer konsistenten Benutzerführung und gefährden damit ggfs. die Supportfähigkeit.  

CAS Agora

Deswegen entschieden wir, die Menge an Portlets in eine geschlossene Webanwendung in JSF 2.1 zu überführen. Diese Änderung ermöglicht eine deutlich bessere Kontrolle und Wartbarkeit der Oberfläche, da diese nicht mehr von einer darunterliegenden Portalkomponente abhängig ist. Die genutzten Portalfunktionen wie ein Single-Sign-on oder ein durchgängiges Design stellt entweder der JBOSS Application Server selbst zentral zur Verfügung oder die entsprechenden Funktionen wurden von uns in eigenem Code realisiert und optimiert. Die „user experience“ wird besser und der genutzte Programmcode ist gleichzeitig schlanker und effizienter.

JSF2 erleichtert die Implementierung eigener Oberflächenkomponenten durch seine composite components. In einzelne Deployments zerlegt, können Komponenten samt Oberfläche nahtlos anderen Anwendungen zur Verfügung gestellt werden. Damit ist ein zentraler Vorteil der Wiederverwendbarkeit nach wie vor gegeben: Eine an verschiedenen Stellen benutzte Funktion wie z. B. die Kundensuche wird nach wie vor nur einmal entwickelt, aber an vielen Stellen innerhalb von CAS als auch in weiteren Webanwendungen dieser Architektur verwendet.

Um den Portalgedanken eines Prozessportals nicht zu verlieren, gibt es eine zentrale Komponente AGORA, an der sich alle auf dem JBOSS im Rahmen dieses Frameworks entwickelten Webanwendungen anmelden und die den zentralen Anlaufpunkt für den Anwender bilden. 

Im Sinne der SOA Architektur stellt diese Komponente für alle Anwendungen zentrale Dienste (Daten zum angemeldeten User, Statistik und Verwaltungskomponenten etc.) bereit.

Ansprechpartner: Olaf Port; Turn on Javascript!