Service Level Agreements - wir brauchen Monitoring

Als nächste Etappe für den HTS steht eine weitere Komponente für die HTI an. Um den HTS tatsächlich einem Kunden als Dienst anbieten zu können, müssen bestimmte Dinge gewährleistet werden können:

• Es wird ein Dienst mit einer bestimmten Leistung erbracht,
• und er wird innerhalb einer gewissen Zeit erbracht.

Diese und noch weitere Kriterien werden in sog. Service Level Agreements (SLAs) festgehalten. SLAs beschreiben somit die Güte des Dienstes und bilden die Grundlage für eine vertraglich vereinbarte Dienstleistung, die durch ein IT-System erbracht wird.

Damit die HTI überhaupt sicherstellen kann, dass bestimmte Dienstleistungen innerhalb einer definierten Zeit erbracht werden können, benötigt sie eine Monitoring-Komponente.
Monitoring bezeichnet, grob gesagt folgendes:

• Es werden Prozesse beobachtet bzw. Daten ausgewertet, die zu nutzbaren Informationen verarbeitet werden. Statistiken können darüber geführt werden.
• Aus solchen Informationen wird versucht weiteres Wissen über den Prozess zu erlangen. Mit Hilfe von Trends kann man weiterhin versuchen Dinge vorauszusagen. Dass vorausgesagte Ereignisse tatsächlich eintreffen, kann natürlich nicht gewährleistet werden.
• Die Beobachtung erfolgt in "Echtzeit". Dies ist ein Hauptmerkmal des Monitorings.

Aktuell wird das Konzept dafür im Rahmen meiner Bachelorarbeit erarbeitet.

Hyperjaxb3 works

Die Umstellung der HTI auf ein Klassenmodell, das völlig selbständig mittels Maven, JAXB und dem Hyperjaxb3-Plugin erzeugt wird, ist geglückt. Nun braucht lediglich eine Änderung am Schema vorgenommen werden, und alle Änderungen sind sofort in den Modellklassen sichtbar. Dadurch, dass Hyperjaxb3 erlaubt, JPA-Konfigurationen in einem Custom Binding, JAXB bei der Übersetzung in Javaklassen mitzugeben, sind die JPA-Annotationen auch mit in den Modellklassen vorhanden.
Die Konsequenz ist, dass unsere Entityklassen bzw. das Konzept der parallelen Klassenhierarchie und das Mapping mit Dozer wieder überflüssig geworden ist. Da es bei jeder Änderung am Modell zu Problemen mit Dozer gekommen war, machte es das Entwickeln nicht gerade bequem.

Hyperjaxb3

In einem früheren Post hatte ich bereits über die Möglichkeiten der Generierung von Javaklassen aus XML und die Beschränkungen von JAXB berichtet. Zu diesem Zeitpunkt hatte ich nach alternativen gesucht, wobei ich schon über Hyperjaxb3 gestoßen war. Auf den ersten Blick schien dieses Framework keine mögliche Alternative bzw. Erweiterung zu bieten. Die Seite http://xircles.codehaus.org/projects/hyperjaxb3 war nicht wirklich aussagekräftig.
Vor einigen Wochen haben wir begonnen unser Projekt auf Maven umzustellen. Während dieser Zeit fanden viele Änderungen an den Interna der HTI statt, was zu vielen Fehlern führte. Oft war Dozer und unsere parallele Klassenhierarchie das Problem. Für den Zweck, dass man unterschiedliche Schichten oder Komponenten mit unterschiedlichen Domain-Klassen in einem System hat, ist es absolut sinnvoll Dozer als Mapper zu verwenden. Das Prinzip von information hiding ist es nur notwendige Informationen bekannt zu geben. Alles was nicht im Rahmen der Abarbeitung einer bestimmten Aufgabe liegt, ist geheim zu halten und sollte die entsprechende Schicht oder die Komponente nicht verlassen. Pro Schicht ein eigenes Domain-Modell zu haben, ist ganz im Sinne dieses Prinzips.
In unserem Fall gibt es kaum etwas zu verbergen. Einzig das Problem der Erhaltung der Persistenzkonfiguration, bei einer erneuten Generierung des Modells, war der Grund für die parallele Klassenhierarchie und den folglich notwendigen Mapper, Dozer, zu verwenden.
Daher haben wir nochmals recherchiert, ob es denn nicht noch andere Möglichkeiten gibt und sind durch das hinzugenommene Maven nochmals auf Hyperjaxb3 gestoßen. Diesmal haben wir eine andere Projektseite (http://confluence.highsource.org/display/HJ3/Home) mit recht guten Tutorials und mit Maven-Konfigurationen gefunden.
Der Mehrwert der Verwendung von JAXB mit Hyperjab3-Plugin ist enorm:

• Die Klassen des Domain-Modells werden bei jedem Buildvorgang mit erzeugt.
• Diese enthalten nun sogar die Persistenzkonfiguration (in Form von JPA-Annotationen).
• Daher wird die zweite Klassenschicht (unsere bisher als Entities bezeichneten Klassen) und folglich Dozer als Mapper überflüssig.

Für die technische Umsetzung ist noch zu erwähnen, dass nun jedoch für JAXB so genannte Custom Bindings definiert werden müssen. Man kann dies inline, also in dem Schema, oder extern in einer extra Binding-Datei (binding.xjb) tun. Ein Binding ist eine Regel in XML-Notation, der JAXB entnehmen kann, wie es bestimmte Mappings beim Marshalling und Unmarshalling von XML-Dokumenten auf Java vorzunehmen hat. Um unser Schema von domänen-fremden Inhalten sauber zu halten, haben wir uns natürlich für die externe Variante entschieden.

Die vollständige Migration der Alternative in das Produktivsystem ist in Arbeit und es bleibt abzuwarten in wie weit alles gut geht.