Kolloqium Bachelorarbeit V1

Powerpoint master slide set

Atomares Interaktionslogging ber einenEnterprise-Service-BusNils [email protected] Studiengang InformatikMat.-Nr: 5944981Fachsemester: 6

Nils Meder | 19. Oktober 10 | Nr.

Agenda: Was wollen wir heute erreichen?EinleitungMotivationAnforderungsanalyseAnforderungen an das LoggingPrzisierung des ProblemsImplementierung und LsungsansatzLsungsmodellKomponentenZusammenfassung


Unternehmen werden soziale Netzwerke

Service-orientierte Architekturen (SOA)

MitarbeiterUnternehmenKunden

Nils Meder | 19. Oktober 10 | Nr.3Aufspaltung von IT-Funktionalitt in einzelne, an Unternehmensprozesse orientierte ServiceblckeKomponenten Dienste anbieten, oder angebotene Dienste anderer Systeme nutzen Vorteile gegenber gewachsenen SystemeFlexible Informationssysteme, um neue Geschftsmodelle schneller umsetzen zu knnen, Geschwindigkeit entscheidet werim Markt mithalten kann deshalb auch fr Management interessant

Vorteile von SOA

Flexible nderbarkeitLeichte WartbarkeitNeuer NutzenNeue VertriebswegeSkalierbarkeitOffenheit

Effizienz und Flexibilitt im Business

Nils Meder | 19. Oktober 10 | Nr.4flexiblenderbarkeit:DurchdieloseKopplungderKomponentenlassensichPro- zesse flexibel ndern und so an den Unternehmensprozess schnell anpassen. leichteWartbarkeit:DaProzesseausverschiedenenServiceszusammengesetztsind, werden redundante Implementierungen vermieden und die Wartbarkeit der Soft- ware erhht. neuerNutzen:InnerhalbeinerSOAistesmglichbereitsbestehendeSoftwareund Geschftslogik um neue Technologien zu erweitern und so einen neuen Nutzen fr das Unternehmen zu gewinnen. neue Vertriebswege: Wertvolle Geschftslogik kann von Unternehmen mit Hilfe von SOA auch auerhalb des eigenen Unternehmens angeboten werden. Diese Lo- gik kann dann von anderen Unternehmen kostenpflichtig genutzt werden. Skalierbarkeit:DurchdieMglichkeitbeiBedarfneueKomponentenflexibelindie Architektur einzubinden, wird die Skalierbarkeit erhht. Offenheit:DaService-orientierteArchitekturenaufkeinenproprietrenundfesten Technologien basieren, erfllen viele Middleware-Systeme die Anforderungen von SOA und knnen nach den Anforderungen der Unternehmen frei ausgewhlt und erweitert werden.

Sicht auf ProzesseOrchestrierungInterne ProzesseKommunikation ber zentrale InstanzChoreographiebergreifende ProzesseBeobachterperspektiveUnternehmensbergreifende Prozesse

Nils Meder | 19. Oktober 10 | Nr.Orchestrierung:Interne Prozesse vom Unternehmen angebotenen Dienste miteinander verbunden realer GeschftsprozessNachrichtenbasierte Kommunikation ber Instanzber exterenen Prozesse keine berwachung zentrale Instanz fehlt

ChoreographieUnternehmensgreifende Prozesse wie Teilprozsse koorperieren ber WS-CDL Art und Weise der Ausfhrung unbekanntBeobachterperspektive auch unternehmensbergreifende Prozesse werden betrachtetUnterschiedO. sieht nur Teilprozess der intern stattfindet, auerhalb der Grenzen und implizite Beziehungen bleiben unbekanntC. kennt diese Beziehungen, allerdings bleibt Umsetzung innerhalb der Unternehmen unbekanntWichtig zu wissen ob Prozess Erwartungen nach verhlt auf Fehler reagieren Recovery berwachung des Nachrichtenflusses Notwendigkeit eines Vermittlers

5

Besitzt Hot-Pluggable-Eigenschaft zur ErweiterungZentrale Instanz der bergreifenden WS-KommunikationMonitoring ber Log-MediatorKontrolle des choreographierten Nachrichtenflusses2002 zum ersten Mal von Roy Schulte beschrieben

Enterprise-Service-Bus (ESB)Probleme bei Zuverlssigkeit der Logging-Daten

Nils Meder | 19. Oktober 10 | Nr.- Verwendung von Synapse6

Datentransformation ist ein inhrenter Teil des Busses in einem ESB-Deployment. Da Datentransformation ein derartig integrierter Bestandteil eines ESBs ist, kann man es auch so betrachten, dass ein ESB den Impedanz-Unterschied 2 zwischen Anwendungen ausgleicht.

Nils Meder | 19. Oktober 10 | Nr.wichtigsten Aufgaben des ESB zhlt die Fhigkeit Interoperabilitt zu schaffen darum bentigt Konnektivitt, Datentransformation und RoutingGroe Bedeutung Datentransformation: erlaubt es z.B. versch. Programmierspr. oder Plattformen zu intergierenTransformationsschritte fr Nutzer unbekannt Mediatoren innerhalb der ESB-SequenzVorbeugen von Performance Problemen Definition eines Zwischenformates SOAP Routing Dienste erhalten nur logische Endpunkte ESB erledigt das Routing zum physikalischen Endpunkt Nachrichten nur auf Anwendungsebene Erleichteung z.B. Einfhrung von Neusystemen7


Nils Meder | 19. Oktober 10 | Nr.Umleitung der NachrichtenProxyService leitet Nachrichten an LogginginstanzAnschlieendes Senden an EndpunktUnternehmensbergreifende KommunikationValidierung der ChoreographieProtokollierung ber den ESB

Nils Meder | 19. Oktober 10 | Nr.Zuverlssiges LoggingValidierung erfordert zuverlssige DatenFehler im Nachrichtenaustausch werden nicht geloggtLogging und Nachrichtenversand als Einheit atomarAutonomie muss erhalten bleibenFehler im Nachrichtenaustausch

Nils Meder | 19. Oktober 10 | Nr. Atomic - Either all of the changes within the scope of the transaction succeed, or none of them succeed.

Nils Meder | 19. Oktober 10 | Nr.Teil des ACID-Paradigmas und wird als Ganz-oder-gar-nicht- Eigenschaft bezeichnetzugesichert, dass alle Aktionen in einem bestimmten Rahmen entweder ganz ausgefhrt werden oder aber gar nichtTransaktionen setzten dies durch BEGIN COMMIT Kappselung von Aktionen durch diesen RahmenIn SOA komplizierter Transparenz, Autonomie und lose Kopplung muss erhalten bleibenNotwendig um auf Fehler mit Kompensation (Ausgleichtransaktionen) oder Recovery (Wiederherstellung bestimmter Systemzustnde)Zuverlssigkeit von Kommunikationen wird gesteigert11

Przisierung des ProblemsFehler in der Kommunikation zwischen ESB und LoggingAktion wird ausgefhrt, aber nicht/falsch geloggtValidierung auf Grundlage falscher DatenFehler in der Kommunikation zwischen ESB und ZielserviceAktion wird geloggt, kommt aber nicht/falsch zur AusfhrungKeine korrekte Validierung fr die Choreographie mglichLognachrichten in korrekter ReihenfolgeLogging ALLER NachrichtenAutonomie der UnternehmenZiel: Atomare InteraktionsprotokollierungAktion wird nicht geloggtAktion wird nicht ausgefhrtEinhaltung der Anforderungen

Nils Meder | 19. Oktober 10 | Nr.Mglichkeit 1: Fehler zwischen ESB und Logging Aktion wird ausgefhrt, nicht geloggt falsche Loggingdaten falsche ValidierungMglichkeit 2: Fehler zwischen ESB und Zielservice Aktion wird geloggt, nicht ausgefhrt falsche Loggingdaten falsche ValidierungBehebung durch Atomare Interaktionsprotokollierung, allerdings Einhaltung der AnforderungenReihenfolge muss korrekt sein, Alle Nachrichten die ausgefhrt wurden mssen im Log stehen, Unternehmen mssen autonom weiterarbeiten knnen12


Nils Meder | 19. Oktober 10 | Nr.LsungsmodellLogging verzgernBlockierendes SendenReaktions auf Fehler mglichErweiterungsmglichkeitenProxyService erweitern oder neu definierenMediator definieren

Nils Meder | 19. Oktober 10 | Nr.Grundlegende Idee ist Logging verzgern, bis Senden erfolgreich abgeschlossenNotwendig weil Nachrichten asynchron in Synapse an den Sendemechanismus weitergeben werden Notwendigkeit fr BLOCKIERENDES Senden Kontrollfluss bleibt bei Sendeinstanz Reaktion auf Fehler mglich (wichtig)

Zur Umsetzung mehrere Mglichkeiten:

- Die vorhandene ProxyService-Klasse erweitern: auf Funktionalitt der ProxyService-Klasse aufgebaut, um Mglichkeit erweitert, blockierend Nachrichten zu senden und anschlieend zu loggen eigene ProxyService-Klasse definieren: Mglichkeit greift tief in den Aufbau von Synapse ein, ersetzt den ProxyService durch eine eigene Klasse, welche zum einen spezielle Funktionalitt zum atomaren Loggen mitbringt, aber zum anderen die Funktionalitt der ProxyService-Klasse selbst implementiert Logging- und Sendefunktionalitt direkt in den ProxyService integriert.- ESB ber Mediatoren erweitern: auf die Erweiterbarkeit von Synapse aufgebaut, in dem Mediatoren dem ESB hinzugefgt werden, die den blockierenden Sendevorgang und den Protokollierungsprozess bernehmen und atomar kapseln. Synapse selbst und der ProxyService bleiben dabei unangetastet.

Einfache Anfrage-/Antwort-Interaktion:Anfrage durch vordefinierten ProxyService standardmig Sequenz von Mediatoren abgearbeitet, dann Senden Lsung da ersten Senden dann LoggenIN-Sequence: Anfrage durch definierten Mediator bernimmt das blockierende Senden (2) ber OperationClient (aus Framework) wartet auf Besttigung vom WebService (4)Wenn erfolgreich weiter zum LogMediator (5) Logging der Nachrichten anschlieend DropMediator, verhinderte weitere Verarbeitung der Nachrichtensequenz und damit das erneute Senden ber den StandardmechanismusResponses ber OUT-Sequence (6): Reihenfolge der Mediatoren bleibt erhaltenOperationClient arbeitet anders injektion der Nachrichten in den geffneten Eingangskanal des Startservices

Folge: atomarer Loggingprozess zuverlssige Daten fr die Validierung Unternehmen bleiben autonom (nur ESB wird angefasst)Erhhung der Garantien durch Einsatz von WS-RM fr ESB-Logging-Kommunikation14

Abgedeckte FehlerquellenVerbindung ESB und Logginginstanz (1) ber WS-RMGeffneter Kanal (2) vom StartserviceVerbindung ESB und Zielservice ber eigenen Mediator (3)Mgliche Fehler

Nils Meder | 19. Oktober 10 | Nr.Mgliche Fehlerquellen:1 die Verbindung ESB-Logging: im besten Fall besteht Zugriff auf die Logginginstanz, deshalb WS-RM zuverlssige Implementierung, zahlreiche Garantien, ggf. auch Einsatz der eigenen Implementierung weniger Garantien als WS-RM, trotzdem Verbesserung im Vergleich zum Ausgangssystem zuverlssige Lognachrichten2 die Verbindung ESB-Startservice: Eingangskanal bleibt wrend gesamter Kommunikation geffnet und steht unter Kontrolle des Startservices, beim Verbindungsabbruch reagiert der WebService entsprechend seiner Implementierung um einen konsistenten Zustand zu erreichen3 die Verbindung ESB-ZielService: um Autonomie zu erhalten KEIN WS-RM, eigenen Mediator zum blockierenden SendenGrenzen: Verlust der Ackknowledgements vom Zielservice wird nicht als solcher erkannt, Reaktion wie bei Verlust der gesamten Nachricht, ist allerdings zu vernachlssigen da System sehr ausgereift ist, dieser Fehler sehr selten vorkommt und auch WS-RM dieser Fehler nicht erkennt 15

KomponentenAtomicInteractionMediatorSendet Nachrichten blockierend an den ZielServiceberwacht fehlerfreie bertragungLeitet Nachricht weiter an den LogMediator

WebServiceLogMediatorNach erfolgreichem Senden erhlt dieser alle NachrichtenSendet Kopie der Nachrichten an LoggingInstanzAnschlieend ValidierungDropMediatorBricht die Bearbeitung der Nachrichtensequenz ab

SendMediatorLogMediatorDropMediator

Nils Meder | 19. Oktober 10 | Nr.-SendMediator: selbst implementierter Mediator, sendet ber OperationClient blockierend, bei erfolgreichem Senden, weiter mit LogMediator-dazu wird der Nachrichtencontext geclont und mit den Adressinformationen der OriginalNachricht angereichert-die geclonte Nachricht wird an den Endpunkt gesendet-wird mit der Abarbeitung fortgefahren LogMediator ELSE Abarbeitung wird abgebrochen und mit Recovery bzw. Kompensation begonnen (Implementierungsabhngig)

LogMediator: sendet eine Kopie der Originalnachrichten an eine Logginginstanz, auf Grundlage dieser Daten wird eine Laufzeitvalidierung der Choreographie durchgefhrtEs besteht direkter Zugriff auf Logginginstanz, deshalb Absicherung der Kommunikation ber WS-RM (Sandesha2) Garantien z.B. Besttigungen knnen angefordert werden etc. auch hier Senden ber AtomicInteractionMediator mglich, mit weniger Garantien, aber Mehrwert fr das Logging

DropMediator: BasisMediator aus Apache Synapse, bricht die Bearbeitung der Nachrichtensequenz abNotwendig da in der Standardvariante nach den Mediatoren an einen Endpunkt gesendet wird wrde doppeltes Senden bedeuten nicht gewollt, darum hier Abbruch16


Nils Meder | 19. Oktober 10 | Nr.ZusammenfassungZuverlssiges Logging

Atomare Protokollierung der NachrichtenEnterprise-Service-Bus als zentrale Instanz der ChoreographienAutonomie der Unternehmen bleibt erhaltenRecovery und Kompensation von Netzwerkfehlern

Nils Meder | 19. Oktober 10 | Nr.Vielen Dank fr Ihre Aufmerksamkeit!


Technology

Kolloqium Bachelorarbeit V1