Serviceorientierte Anwendungen setzen sich aus Services zusammen, die eine hohe Kohäsion aufweisen. Best Practices, wie beispielsweise die Kapselung und generische Programmiermethoden, erlauben es, Services als allgemeine, wiederverwendbare Komponenten auszulegen. SOA-Architekturen sind lose gekoppelt und orchestrierbar.
Die Evolution von monolithischen Systemen zu serviceorientierten Architekturen basiert auf der Erfahrung bei der Entwicklung und dem Betrieb von komplexen Softwaresystemen, bei der sich lose gekoppelte Systeme durchgesetzt haben. Die lose Koppelung wurde durch die Möglichkeiten der Messaging-Systeme (MOM) populär. Messaging-Systeme und klassische Hub-and-Spoke sowie Message Broker Architekturen zeichnen sich durch eine hohe Verfügbarkeit, Skalierbarkeit, asynchrone Kommunikation und sehr hohe Flexibilität durch Routingtabellen und standardisierte Datentransformationen aus.
Der Java EE Standard unterstützt optimal die Anbindung an Messaging-Systeme mit Message Driven Beans und der JMS-API. Die Anwendung von Messaging-Techniken ist dabei nicht nur auf die Applikationsentwicklung begrenzt, sondern wird häufig in Integrationsszenarien eingesetzt. Die Integration von komplexen Softwaresystemen bringt neue Herausforderungen mit sich, sodass die Vorteile von Messaging Systemen nicht ausreichend sind um Integrationsszenarien lösen zu können. Im Bereich der Integration von Softwaresystemen und dem Enterprise Application Integration (EAI) sind deshalb auch die Komponenten in ihrer Struktur flexibel ausgelegt. Die Flexibilität wird dort durch klar definierte Schnittstellen mit der Möglichkeit zur Adaptivität, der Unabhängigkeit von Protokollen (Protokolltransformationen), der Komposition und Orchestrierung (BPMN / BPEL) erreicht.
Beim Technologieschritt vom Message Broker zum Enterprise Service Bus (ESB) haben die Hersteller von SOA-Entwicklungswerkzeugen große Fortschritte erzielt. Integrationsszenarien sind dabei unabhängig von ihrer Komplexität, ohne eine Zeile Programmcode schreiben zu müssen, lösbar. Graphische Werkzeuge und die Normierung der Prozessdarstellungen (BPMN 2) erlaubt es, komplexe Geschäftsanforderungen mit Zeitabhängigkeiten, Parallelität und Verzweigungen zu modellieren. Ein in der Designphase erstelltes Modell bildet dabei die Basis für die automatisierte Generierung der Serviceartefakte und dem Deployment in der ESB Umgebung.
Die neue Generation von Werkzeugen verschiebt den Schwerpunkt von der Erstellung einer Applikation in Richtung Wartung und Erfordernissen des Betriebes. Die Verlagerung des Schwerpunktes wird erst durch die Reduzierung des Programmieraufwandes möglich, sodass mehr Zeit für die strategische Inbetriebnahme eines Softwareproduktes vorhanden ist. Die Hersteller von Softwareprodukten haben diesen Trend erkannt und mit der Common Event Infrastructure (CEI) einen standardisierten Layer definiert.
Der Nachrichtenfluss im CEI-Layer basiert auf dem Common Base Event (CBE) Format. Ein Nachrichtenfluss in einer CEI-Umgebung besteht aus Informationsmeldungen und Meldungen, die durch Fehlerszenarien produziert werden. Diese Meldungen fungieren als Ereignisse, die zeitnah bearbeitet und analysiert werden müssen, um den reibungslosen Betrieb einer Unternehmensanwendung sicherzustellen.
In der Eclipse Test & Performance Tools Platform (Eclipse TPTP) ist der Hyades-Framework integriert, der das Common Base Event Format nutzt. Strukturierte Detailinformationen eines Services, mit nach Kategorien angelegten Detailinformationen, eignen sich zur gezielten Analyse von Ereignismeldungen. Anders als bei herkömmlichen Trace-Frameworks wird ein standardisiertes und bereits in vielen Werkzeugen integriertes Format zum Austausch der Ereignismeldungen verwendet.
Eine CEI-Infrastruktur beinhaltet sowohl Ereigniserzeuger, die Services einer serviceorientierten Architektur und Infrastrukturkomponenten (Applikationsserver, Message Broker, ESB) als auch Ereignisempfänger, die Werkzeuge zum Auswerten der Ereigniskette. Zur Auswertung sind Analysemöglichkeiten mit Filtern und Navigationsmöglichkeiten in der Ereigniskette nötig, um Fehlerszenarien detailiert auswerten und bewerten zu können. Ohne Analysemöglichkeiten sind Fehlerbilder nur sehr schwer aufzubauen und Wiederholungsfehler kaum zu vermeiden.
Die CEI-Umgebung ist Teil des Autonomic Computings einem Paradigma das neben der Analyse von Nachrichtenflüssen weitergehende Funktionalitäten wie Selbstkonfiguration, Selbstmanagement und automatisierte Optimierungen beinhaltet.
Der Service Manager 2.0 ist eine Komposition von Applikationen, die zur Auswertung der Ereigniskette in einer CEI-Umgebung eingesetzt werden kann. Der Service Manager 2.0 stellt deshalb eine interessante Möglichkeit dar fehlerhaftes Verhalten zeitnah analysieren und auswerten zu können. Die Trennung des Monitorings der Services und damit verbunden schnellere Reaktionszeiten im Fehlerfall, sowie das Analysewerkzeug für die nachträgliche Analyse einer Fehlerkette, erlaubt gezielt Maßnahmen zum richtigen Zeitpunkt zu treffen.
Das Common Base Event Format definiert die Struktur von Ereignissen, die von verschiedenen Applikationen erzeugt werden, in einem einheitlichen, gemeinsamen Datenformat. Dieses Format wird von verteilten Applikationen zum Logging, Management und Problemerkennung verwendet, um eine standardisierte Auswertung der darin enthaltenen Informationen zu ermöglichen. Ausgetauscht werden sowohl technische als auch fachliche Informationen. Mit der Zusammenführung von technischen und fachlichen Daten lässt sich eine Vielzahl von Funktionen automatisieren.
