Konzeption und prototypische Entwicklung einer CEP-Anwendung im Bereich E-Commerce

Inhaltsverzeichnis

Abstract

Abbildungsverzeichnis

Listingverzeichnis

Abkürzungsverzeichnis

1... Einleitung
1.1 Ziel dieser Thesis
1.2 Aufbau

2... Grundlagen
2.1 Begriffe im Zusammenhang mit EDA
2.2 Schlagworte im Umfeld von EDA und CEP
2.3 Der Begriff „Softwarearchitektur“
2.3.1 Kohärenz
2.3.2 Kopplung

3... Ereignisse in betrieblichen Anwendungssystemen
3.1 Die Global Event Cloud – Herausforderungen im Umgang mit Ereignissen
3.2 Grenzen von konventionellen Softwarearchitekturen
3.2.1 Geschäftssicht in konventionellen Architekturen
3.2.1.1 Betrachtung einzelner Ereignisse
3.2.1.2 Vergangenheitsperspektive
3.2.2 Technologiesicht in konventionellen Architekturen
3.2.2.1 Kommunikationsmodell
3.2.2.2 Ereignisverarbeitung

4... Event-Driven Architecture
4.1 Geschäftssicht in einer EDA
4.1.1 Echtzeit
4.1.2 Geschäftsprozesse
4.1.2.1 Ereignisgesteuerte Geschäftsprozesse
4.1.2.2 Betrachtung von Ereignismustern
4.2 Technologiesicht in einer EDA
4.2.1 Ereignisströme
4.2.2 Ereignisverarbeitung
4.2.3 Kommunikation der Anwendungskomponenten
4.2.3.1 Asynchronität
4.2.3.2 Push-Modus
4.2.3.3 Publish-Subscribe
4.2.3.4 Pull-Modus
4.2.3.5 Kommunikationsstruktur

5... Vom Architekturstil zur Unternehmensanwendung –
Konzeption einer CEP-Anwendung
5.1 CEP-Konzepte
5.1.1 Event Processing Agent
5.1.2 Ereignismodell
5.1.3 Ereignisregeln
5.1.4 Event Processing Engine
5.1.5 Event Processing Agent Typen
5.1.6 Event Processing Network
5.1.7 Vorteile eines Event Processing Networks
5.2 Vorgehensmodell
5.2.1 Vorgehen bei der Entwicklung einer CEP-Anwendung
5.3 E-Commerce Grundbegriffe
5.3.1 Abgrenzung
5.3.2 Transaktionsphasen bei E-Commerce
5.3.3 Elektronische Marktplätze
5.4 Einsatzmöglichkeiten und Ziele von CEP im Bereich E-Commerce
5.4.1 Überwachung von Artikelbeständen
5.4.2 CRM – E-Personalisierung
5.4.3 Erhöhung der Sicherheit in einem Online-Shop-System
5.5 Identifizierung der Ereignisquellen und –senken
5.6 Verwendete Technologien zur Implementierung der CEP-Anwendung
5.6.1 Spring44
5.6.2 Spring Integration
5.6.3 Esper….45
5.6.4 RabbitMQ
5.7 Erstellung eines Ereignismodells
5.7.1 Ereignisse in Esper
5.8 Konzeption eines Event Processing Networks
5.8.1 Event Processing Agent in Esper
5.9 Aufbau und Formulierung von Ereignisregeln
5.10 Die Behandlung von komplexen Ereignissen
5.11 Implementierung vorgestellter Konzepte
5.11.1 Administration in einer CEP-Anwendung
5.11.2 Umsetzung eines dynamischen EPN
5.12 Installationsinstruktionen

6... Schlussbemerkung
6.1 Konzeption und Entwicklung der CEP-Anwendung
6.2 Aktueller Entwicklungsstand
6.3 Ausblick

Literaturverzeichnis

Abbildungsverzeichnis

Abbildung 1 Positionierung von EDA

Abbildung 2 Schlagworte im Umfeld von EDA und CEP

Abbildung 3 enge und lose Kopplung

Abbildung 4 „up three points“ von Frank Hanley 1930

Abbildung 5 Sichten einer Event-Driven Architecture

Abbildung 6 Ereignisstrom mit mehreren Quellen und Ereignisobjekten unterschiedlicher Typen

Abbildung 7 Typische Verteilung von Ereignissen im Push-Modus

Abbildung 8 Verteilung von Ereignissen im Push-Modus mit einem Ereigniskanal

Abbildung 9 Verteilung von Ereignissen im Pull-Modus

Abbildung 10 Kommunikationsstruktur einer EDA

Abbildung 11 Complex Events

Abbildung 12 Elemente eines Event Processing Agent

Abbildung 13 Längenfenster zum Abspeichern von Ereignissen

Abbildung 14 Event Processing Agent Typen

Abbildung 15 Ein typisches Event Processing Network

Abbildung 16 Prozessschritte und –Phasen einer CEP-Entwicklung

Abbildung 17 Beispiel für einen zusammengesetzten Kontext bestehend aus einem zeitlichen und segmentierten Kontext

Abbildung 18 E-Business im Überblick

Abbildung 19 Phasen bei E-Commerce

Abbildung 20 Die Infrastruktur, in der sich die CEP-Anwendung befindet

Abbildung 21 Grafische Darstellung einer XML-basierenden Konfigurationsdatei von Spring Integration

Abbildung 22 Ausschnitt aus dem Ereignismodell einer CEP-Anwendung
für den Bereich E-Commerce

Abbildung 23 Sicherheitsstufen eines SecurityEvents

Abbildung 24 Event Processing Network der CEP-Anwendung

Abbildung 25 Oberfläche zur Darstellung eintreffender Ereignisse

Abbildung 26 Asynchrones Modell einer Web-Anwendung mittels Ajax

Abbildung 27 Control Bus Pattern

Abbildung 28 Tracking von Benutzeraktivitäten

Listingverzeichnis

Listing 1 Instanziierung eines Event Processing Agent mittels Esper

Listing 2 Implementierung eines EPA im Spring-Kontext

Listing 3 Implementierung einer Subscriber-Klasse im Spring-Kontext

Listing 6 Esper pattern matching

Listing 9 Ajax PeridicalUpdater

Listing 11 Ein Ausschnitt der UserTackingAgent-Klasse

Listing 12 Befehl zum Installieren der CEP-Projekte im Maven-Repository

Tabellenverzeichnis

Tabelle 1 Enge und lose Kopplung

Tabelle 2 Kategorien der Bestandveränderungen

Abkürzungsverzeichnis

Abbildung in dieser Leseprobe nicht enthalten

1 Einleitung

„The real world is mostly event-driven“^[1]. Roy Schulte, der Vizepräsident und Analyst im Business Intelligence Bereich der Gartner Inc., formulierte diesen Satz während eines Vortrages zu einem Bericht, der sich mit der wachsenden Rolle von Ereignissen in Unternehmensanwendungen beschäftigt.

Das Verhalten eines Objektes, welches auf ein Ereignis reagiert, ist event-driven. Eine Person ist event-driven, wenn sie auf bestimmte Reize der realen Welt reagiert. Unternehmen sind event-driven, da sie auf vorhersehbare und unerwartete Ereignisse von Kunden und Lieferanten reagieren müssen (auf das Stornieren einer Bestellung, auf den Ausfall eines Lieferanten wegen Insolvenz, oder auf eine Gesetzesänderung). Ereignisse sind in der realen Welt allgegenwärtig und haben somit direkte Auswirkungen auf die Steuerung betrieblicher Prozesse in einem Unternehmen.^[2]

Die Behandlung von Ereignissen durch Unternehmensanwendungen ist keineswegs eine neue revolutionäre Technologie. Allerdings werden Ereignisse lediglich dezentral als Aktivitäten oder Vorgänge erfasst. Somit kann die Ursache eines Ereignisses nur schwer zurückverfolgt und kausale Zusammenhänge zwischen Ereignissen nicht berücksichtigt werden.^[3]

Mit Event-Driven Architecture^[4] (EDA) als Architekturstil und Complex Event Processing (CEP) als Softwaretechnologie rücken Ereignisse in das Zentrum der Softwarearchitektur. Dies ermöglicht die Umsetzung von Anwendungssystemen, die Unternehmen zu mehr Agilität und Effizienz verhelfen. Ereignisse werden hierbei als Objekte behandelt, welche Beziehungen zueinander haben können. Folglich können Muster aus betrieblichen Ereignisströmen erkannt und abstrahiert werden.^[5]

Angesichts des zunehmenden Konkurrenzdruckes und den stets neuen regulatorischen Auflagen, sind Unternehmen gezwungen, schnell zu reagieren und Anpassungen an ihren Geschäftszielen und -strategien vorzunehmen. Dabei liefert Business Intelligence den Entscheidungsträgern wichtige Informationen für diese Anpassungen. Jedoch basieren diese Informationen auf Daten aus der Vergangenheit. Daher werden neue Trends möglicherweise erst zu spät erkannt. Um dies zu vermeiden, ist es für Unternehmen wichtig Prozesse in Echtzeit abbilden zu können. Vor allem für den operativen Bereich ist esssentiell, den Zustand der Geschäftsprozesse in Echtzeit ablesen zu können, da mögliche Störungen negative Auswirkungen auf die Geschäftsziele haben können.^[6]

Typische Fragestellungen einer EDA sind demzufolge:

- „Wie kann die Fehlleitung eines Gepäckstückes möglichst frühzeitig erkannt werden?“
- „Wie oft wurde Artikel XY in den letzten 10 Minuten verkauft?“
- „Wo befindet sich der Container ABC in diesem Augenblick?“
- „Wie kann ein Verkehrsstau möglichst früh erkannt und entsprechende Maßnahmen (z.B. Senkung der Fahrtgeschwindigkeit) durchgeführt werden?“
- „Wie können RFID-Ereignisse in Echtzeit ausgewertet werden?“

Jedes Geschäftsfeld hat ähnliche Fragen. Viele verschiedene Aspekte des Geschäftsfeldes werden davon umfasst: die Führung des Unternehmens, die Entdeckung neuer Marktchancen, der Schutz des Unternehmens oder die Einhaltung von Richtlinien. Die hierfür benötigten Informationen befinden sich bereits verteilt in den Anwendungen eines Unternehmens – und zwar in Form von Ereignissen. Die Aufgabe von EDA und CEP ist es, diese Ereignisse zu verarbeiten, um „jetzt“ Antworten auf die gestellten Fragen zu erhalten.^[7]

1.1 Ziel dieser Thesis

Diese Thesis widmet sich dem Thema Event-Driven Architecture im Zusammenhang mit Complex Event Processing. Sie behandelt das Thema aus drei unterschiedlichen Perspektiven, die gemeinsam eine umfassende Gesamtsicht dieser noch jungen, aber zukunftsweisenden Form von Softwarearchitektur bzw. -technologie vermitteln sollen:

1. Fachliche Sicht: Welchen Nutzen bringen EDA und CEP für ein Unternehmen?
2. Konzeptionelle Sicht: Was verbirgt sich softwaretechnisch hinter EDA und CEP?
3. Praktische Sicht: Wie kann eine CEP-Anwendung realisiert werden?

1.2 Aufbau

Kapitel 2 – Grundlagen führt in die Thematik der Ereignisverarbeitung als Architekturstil ein. Hierbei wird der Begriff „Softwarearchitektur“ definiert und dessen Eigenschaften beschrieben.

Kapitel 3 – Ereignisse in betrieblichen Anwendungssystemen erläutert die fachliche Bedeutung von Ereignissen für Unternehmensanwendungen. Dabei werden auf die Unzugänglichkeiten von konventionellen Softwarearchitekturen in diesem Kontext eingegangen.

Kapitel 4 – Event-Driven Architecture konzentriert sich auf die grundlegenden Ideen, Prinzipien und Konzepte von Event-Driven Architecture. Es werden unter anderem die einzelnen Sichten und das Kommunikationsmodell einer EDA dargestellt.

Kapitel 5 - Vom Architekturstil zur Unternehmensanwendung – Konzeption einer CEP-Anwendung vertieft die konzeptionellen Inhalte aus Kapitel 3 und 4 systematisch, indem Complex Event Processing als die zentrale Technologie einer EDA vorgestellt wird. Die konkrete technische Umsetzung der präsentierten Konzepte erfolgt anhand der Open-Source-CEP-Engine Esper. Ein durchgehendes Fallbeispiel aus dem Bereich E-Commerce verdeutlicht exemplarisch, wie die vorgestellten Konzepte implementiert werden können.

Kapitel 6 - Schlussbemerkung beleuchtet den Entwicklungsstand von EDA und CEP. Dabei werden die Ergebnisse aufgezeigt, die während der Entwicklungsphase der CEP-Anwendung, erarbeitet wurden. Abschließend wird ein Ausblick auf die Entwicklung und den Einsatz von EDA und CEP gegeben.

2 Grundlagen

Im ersten Abschnitt werden einige Grundbegriffe im Zusammenhang mit einer Event-Driven Architecture erläutert, um einen Einblick in die Thematik zu erhalten.

2.1 Begriffe im Zusammenhang mit EDA

Eine Event-Driven Architecture rückt Ereignisse in das Zentrum der Softwarearchitektur. Hierbei muss jedoch darauf hingewiesen werden, dass EDA nicht als Oberbegriff für alle Applikationen, die event-driven sind, angesehen wird. Im Folgenden werden Begrifflichkeiten, vom generellen zum spezifischen, erläutert, die in Verbindung mit Ereignissen stehen.^[8]

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 1 Positionierung von EDA
Quelle: (Chandy & Schulte, 2009, S. 34)

Ereignis (Event)„Ein Ereignis kann alles sein (eine Aktivität, ein Vorgang, eine Entscheidung).“^[9] „Generell bezieht sich ein Ereignis auf die Veränderung eines Zustandes, also typischerweise auf die Änderung des Wertes einer Eigenschaft eines realen oder virtuellen Objektes.“^[10]

Ein Ereignis kann nicht nur einen Vorgang der realen Welt repräsentieren, sondern es kann auch imaginär sein. Beispielsweise kann sich ein Autofahrer, der sich einer roten Ampel nähert, Ereignisse vorstellen, die passieren könnten, wenn er diese überfährt. Doch wenn der Autofahrer vor der Ampel hält, sind diese Ereignisse nicht real geworden – sie sind jedoch Ereignisse. In der Computersimulationen werden diese Ereignisse auch als virtuelle Ereignisse (virtual events) bezeichnet.^[11]

Ein Ereignis ist jedoch ein zu generelles Konzept, um die Erstellung von Geschäftsprozessen oder IT-Systemen zu unterstützen. Daher wird eine Unterteilung in Geschäftsereignisse vorgenommen:

Geschäftsereignis (Business event)„Ein Geschäftsereignis spiegelt einen fachlichen Sachverhalt wider und nimmt einen unmittelbaren Einfluss auf die geschäftlichen Prozesse.“^[12]

Das Stornieren einer Bestellung, das Eintreffen einer Bestellung, der Versand einer Ware oder die Unterschreitung eines vorgegebenen Schwellenwertes für den Lagerbestand einer Ware, sind Beispiele für Geschäftsereignisse, welche wiederum Bestandteile oder Auslöser von Geschäftsprozessen sind.

Ereignisobjekt (Event objects)„Ein Ereignisobjekt repräsentiert ein konkretes Ereignis.“^[13]

Ein Ereignisobjekt ist die elektronische Erfassung eines Ereignisses. Die Abbildung eines Ereignisses kann in einem beliebigen Datenformat (z.B. XML oder Java) erfolgen. Dabei enthält das Ereignisobjekt wichtige Informationen über das Ereignis und dessen Entstehung. Ferner soll das Ereignisobjekt diese Informationen nicht nur speichern, sondern auch an eine ereignisverarbeitende Komponente weiterleiten.

Ein Ereignisobjekt repräsentiert die Ausprägung eines Ereignistyps. Demnach kann eine Gruppe von Ereignissen einem bestimmten Ereignistyp zugeordnet werden (siehe Abschnitt 5.1.2).

Ereignisgesteuert (event-driven) „Als ereignisgesteuert wird das Verhalten eines Systems, Geräts, Softwaremoduls oder anderer Entitäten bezeichnet, dessen Verarbeitungsprozess durch das Eintreffen eines Ereignisses von einer internen oder externen Quelle ausgelöst wird.“^[14]

Event-driven ist eine Charakteristik von EDA. Doch dieses Verhalten wird auch in anderen Bereichen der Softwareentwicklung eingesetzt: Event-Driven Programming (EDP) wird in vielen Anwendungen verwendet. Damit lassen sich GUI-Anwendungen implementieren, die Benutzeranfragen mittels eines EventListener entgegennehmen und entsprechende Operationen durchführen.^[15] Weitere Beispiele sind in der Integration von Unternehmensanwendungen^[16], sowie in Entwurfsmustern wie das Observer Pattern^[17], zu finden.

Event-Driven Architecture (EDA) „Event-Driven Architecture ist ein Architekturstil, in dem einige Komponenten ereignisgesteuert sind und die Interaktion durch den Austausch von Ereignissen erfolgt.“^[18]

Dabei ist die lose Kopplung (teilweise sogar Entkopplung) der einzelnen Komponenten charakteristisch für eine EDA. Der Austausch von Ereignissen in einer EDA erfolgt in der Regel asynchron über eine message-oriented Middleware. Im Abschnitt 4.2.3 werden diese und weitere Kommunikationsmodelle in einer EDA vorgestellt. Im Zusammenhang mit EDA werden Ereignisse immer als Ereignisobjekte behandelt.

Complex Event Processing (CEP) „Complex Event Processing ist eine Softwaretechnologie, die es ermöglicht ereignisgesteuerte Informationssysteme zu verstehen und zu kontrollieren. Das zentrale Konzept ist hierbei die dynamische Verarbeitung von mehreren Ereignissen zur gleichen Zeit. Mit CEP ist es möglich kausale, temporale, räumliche und andere Beziehungen zwischen Ereignissen auszudrücken. Diese Beziehungen spezifizieren Muster, nach denen die Ereignismengen in Echtzeit durchsucht wird (event pattern matching).“^[19]

EDA ist demnach ein generelleres Konzept als CEP. Eine EDA ohne CEP wäre theoretisch möglich, wenn einzelne Ereignisse ohne kausale Zusammenhänge betrachtet werden. In dieser Arbeit ist der Begriff EDA jedoch immer im Zusammenhang mit CEP, als ereignisverarbeitende Technologie, zu verstehen.

2.2 Schlagworte im Umfeld von EDA und CEP

Im Jahr 2002 veröffentlichte LUCKHAM sein grundlegendes Buch: „The Power of Events: An Introduction to Complex Event Processing in Distributed Enterprise System“^[20], indem er die grundlegenden Konzepte der Ereignisverarbeitung zusammenführt.

„Das Buch stellt einen wesentlichen Meilenstein für die Etablierung der Ereignisorientierung als Fachdisziplin dar“. ^[21]

Inzwischen haben etliche Softwarehersteller^[22] professionelle Tools auf den Markt gebracht. Dadurch wurden verschiedene Schlagworte im Umfeld von EDA und CEP geprägt. Eine Auswahl dieser Schlagworte wird in der nachfolgenden Abbildung dargestellt.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2 Schlagworte im Umfeld von EDA und CEP
Quelle: (Bruns & Dunkel, 2010, S. 4)

Das Grundkonzept, welches sich hinter diesen Schlagwörtern versteckt, ist immer das Gleiche: Event-Driven Architecture und Complex Event Processing.^[23]

2.3 Der Begriff „Softwarearchitektur“

Der Begriff Architektur wird in der Wirtschaftsinformatik nicht einheitlich verwendet, da er in Zusammenhang verschiedener Anwendungsgebiete gebraucht wird.^[24]

Für diese Thesis soll die folgende Definition einer Softwarearchitektur gelten:

„Unter dem Begriff Softwarearchitektur versteht man eine strukturierte oder hierarchische Anordnung der Systemkomponenten, sowie die Beschreibung ihrer Beziehungen.“^[25]

Software ist demnach nicht als einzelne Komponente, sondern als Komposition mehrerer Teilsysteme zu verstehen. Diese Teilsysteme erfüllen gemeinsam eine Funktion für die, die Software entwickelt wurde. Ausschlaggebend für die Eigenschaften einer Softwarearchitektur sind der Grad der Kohärenz und der Kopplung.^[26]

2.3.1 Kohärenz

Im Zuge der Analyse eines Problems bzw. Anwendungsfalls, für den eine Softwarelösung vorgesehen ist, wird eine Aufteilung des gesamten Problemkontextes in klar abgrenzbare Teilprobleme angestrebt. Im Idealfall wird jedes Teilproblem mittels einer Teilkomponente des Anwendungssystems abgedeckt. Dies fördert die Einfachheit und Verständlichkeit eines Systems. Des Weiteren wird ein hohes Maß an Redundanzfreiheit erreicht, da sich nicht mehrere Teilsysteme mit demselben Teilproblem beschäftigen müssen. Somit ist eine starke Kohärenz ein angestrebtes Prinzip im Software Engineering.^[27]

2.3.2 Kopplung

Der Begriff Kopplung bezieht sich auf den Prozess, Dinge zu verbinden, so wie die Glieder einer Kette. Im Bereich Softwarearchitekturen bezieht sich Kopplung auf das Maß, inwieweit Softwarekomponenten voneinander abhängig sind.^[28]

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3 enge und lose Kopplung
In Anlehnung an: (Dunkel et al. 2008, S. 9)

Abbildung 3 (a) zeigt ein System, dessen einzelne Teilsysteme durch zahlreiche Verbindungen eng aneinander gekoppelt sind. Je höher der Umfang ist, in welchem ein System enge Kopplung implementiert, desto gefährdeter ist es, da Störungen, die auf Teilsysteme wirken, das gesamte System beeinflussen.^[29]

Der Abbildungsteil (b) zeigt hingegen ein System mit einer losen Kopplung. Hierbei wird versucht die Anzahl der Schnittstellen, zwischen den einzelnen Teilsystemen, möglichst minimal zu halten. Die m:n-Zuordnung wird durch eine m:1- bzw. 1:n-Zuordnung ersetzt. Dabei erfolgt die Zuordnung indirekt über einen Vermittler (z.B. MOM). Dadurch muss eine Änderung in Teilsystem A oder Teilsystem B nicht in das jeweils andere System propagiert werden.^[30]

Einen Vergleich zwischen enger und loser Kopplung bietet die Tabelle 1:

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 1 Enge und lose Kopplung
In Anlehnung an: (Krafzig, Banke, & Slama, 2007, S. 68)

Eine lose Kopplung ist besonders bei verteilten Systemen ein Qualitätsmerkmal.^[31]

3 Ereignisse in betrieblichen Anwendungssystemen

Unternehmen sind event-driven, da sie auf vorhersehbare und unerwartete Ereignisse von Kunden, Lieferanten und Konkurrenten reagieren müssen. Somit beeinflussen Geschäftsereignisse wesentliche Prozesse und Entscheidungen in einem Unternehmen.^[32]

Nachfolgend wird beschrieben, wie Ereignisse im Unternehmen auftreten und welche Herausforderungen bei der Ereignisverarbeitung entstehen können. Des Weiteren werden Grenzen der Ereignisverarbeitung in konventionellen Architekturstilen aufgedeckt.

3.1 Die Global Event Cloud – Herausforderungen im Umgang mit Ereignissen

LUCKHAM bezeichnet die Gesamtheit aller Ereignisse, in der sich ein Unternehmen bewegen muss, als Ereigniswolke (Global Event Cloud). Er beschreibt die Wolke als ungeordnete Menge an Ereignissen, die von verschiedenen Komponenten global (via Internet) an die Unternehmensanwendung übermittelt werden. Die Ereignisse können dabei, aufgrund unterschiedlicher technologischer Kommunikationsmöglichkeiten, in einer unerwarteten zeitlichen und kausalen Reihenfolge eintreffen. Einige Ereignisse können sogar fehlen, andere können in mehrfacher Ausführung eintreffen. Die Größe dieser Ereigniswolke steigt kontinuierlich. Demnach sehen sich Unternehmen mit einer anhaltend wachsenden Anzahl auftretender Ereignisse unterschiedlichster Art konfrontiert.^[33]

Die Ursachen für das stetige Wachstum der Global Event Cloud können in folgende Faktoren unterteilt werden:^[34]

1. Fachliche Komplexität: Prozesse von Unternehmen sind heutzutage eng entlang der gesamten Zuliefererkette (supply chain) gekoppelt. Diese Vernetzung bedarf einer Abstimmung, damit die verschiedenen Systeme integriert werden können. Die kommunizierten Daten beinhalten eine Vielzahl von relevanten und irrelevanten Geschäftsereignissen, die es zu unterscheiden gilt. Dieser Komplexitätsanstieg ist auf die fortschreitende Nutzung und Möglichkeit der Informationstechnologie (besonders des Internets) zurückzuführen
2. Technische Komplexität „ Nahezu jedes größere Unternehmen sieht sich mit einer komplexen, heterogenen IT-Infrastruktur konfrontiert, die über viele Jahre gewachsen ist. “^[35] Dies bezieht sich sowohl auf die unterschiedlichen hardwaretechnischen Plattformen, als auch auf die softwaretechnologischen Umgebungen. Diese Komplexität wird in den nächsten Jahren durch den Boom mobiler Endgeräte, erhöhter Sicherheitsanforderungen und dem erfassen physikalischer Daten aus der Umwelt, mittels RFID-Technologie, stark zunehmen.

Das Symbol der Wolke verdeutlicht ebenfalls, dass der Zustand eines Anwendungssystems (in Echtzeit) für den Betrachter verborgen bleibt. Deshalb können keine qualifizierten Aussagen über die Auswirkungen von auftretenden Ereignissen auf den operativen Geschäftsprozess und somit auf die Erreichung der Geschäftsziele getroffen werden. Die Anforderung an IT-Systeme ist allerdings die Fähigkeit vorherzusagen, wie bestimmte Konstellationen von Ereignissen, Geschäftsprozesse und –ziele beeinflussen.^[36]

3.2 Grenzen von konventionellen Softwarearchitekturen

Die Behandlungen von Ereignissen in konventionellen^[37] Softwarearchitekturen beschreibt LUCKHAM wie folgt:

„Enterprise Systems have a common problem: Their activities are driven by events and they produce zillions of events per hour or day. But there is no technology that enables us to view those events and activities that are going on inside these systems in way that humans can understand. To be sure, given the primitive tools we have at the moment, we can see the events. But making sense of them is the problem!”^[38]

Demnach werden Ereignisse in konventionellen Softwarearchitekturen, lediglich für grafische Benutzungsoberflächen verarbeitet. Somit findet eine wirkliche Ereignisverarbeitung nur bedingt statt. Die Ursachen hierfür, können in eine Geschäfts- und in eine Technologiesicht unterteilt werden.^[39]

3.2.1 Geschäftssicht in konventionellen Architekturen

Wie bereits in Abschnitt 3.1 erläutert, haben Geschäftsereignisse einen wesentlichen Einfluss auf die Abläufe in Unternehmen. Aus fachlicher Sicht sind hierbei die folgenden Aspekte und Grenzen bemerkenswert.

3.2.1.1 Betrachtung einzelner Ereignisse

Ereignisse werden nur singulär betrachtet, wodurch sich lediglich eingeschränkte Erkenntnisse gewinnen lassen. Ein einzelnes Geschäftsereignis kann einen Geschäftsprozess auslösen, etwa setzt der Eingang einer Auftragsstornierung den Prozess der Auftragsstornierung in Gang. Zwischen Ereignissen können jedoch häufig komplexe Zusammenhänge existieren. Daher müssen sie in einem Kontext betrachtet werden. Beispielsweise ergibt sich aus dem Ereignis A: „Kunde A bezahlt in Berlin mit Kreditkarte 1234“ und Ereignis B: „Kunde A hebt in Kapstadt mit der Kreditkarte 1234 tausend Euro ab“, die im Abstand weniger Minuten auftreten, das komplexe Ereignis „Verdacht auf Kreditkartenbetrug“. Bei isolierter Betrachtung beider Ereignisse wäre der mögliche Kreditkartenbetrug erst wesentlich später erkannt worden.^[40]

3.2.1.2 Vergangenheitsperspektive

Die Analyse des Unternehmenszustandes erfolgt in konventionellen Unternehmensanwendungen aus der Vergangenheitsperspektive. Typische Fragestellungen sind hierbei: „Wie hoch war der Gewinn im letzten Monat?“ oder „Wie viele Besucher haben im letzten Monat etwas gekauft?“. Diese Analyse erfolgt über die Abfrage erfasster Daten aus einem Datenbanksystem (diese Aufbereitung der Unternehmensdaten wird auch als Business Intelligence bezeichnet).^[41]

Die Speicherung von Ereignissen in einer Datenbank ist zu langsam, es sei denn es handelt sich um eine in-Memory Datenbank, sodass keine aktuelle Sicht auf das System möglich ist.^[42]

Abbildung 4 zeigt, dass die kausalen Zusammenhänge eines Ereignisses zeitlich begrenzt sein können, da sie sich durch nachfolgende Ereignisse verändern können. Selbstverständlich ist es wichtig zu erfahren, warum bestimmte Ereignisse ausgelöst wurden, jedoch ist es für moderne Unternehmen sehr viel wichtiger Vorhersagen zutreffen, die auf aktuellen Ereignissen basieren.^[43]

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 4 „up three points“ von Frank Hanley 1930
Quelle: (Hanley, 2005)

[...]

---

^[1] (Schulte, 2006)

^[2] Vgl. (Chandy & Schulte, 2009)

^[3] Vgl. (Bruns & Dunkel, 2010, S. 23)

^[4] Für EDA gibt es keine deutsche Übersetzung und auch keine einheitliche Schreibweise. Daher wird fortan die folgende Schreibweise verwendet: Event-Driven Architecture

^[5] Vgl. (Bruns & Dunkel, 2010, S. 3 - 5)

^[6] Vgl. (Bruns & Dunkel, 2010, S. 24 ff.)

^[7] Vgl. (Luckham, 2012, S. 51)

^[8] Vgl. (Schulte, 2006, S. 33)

^[9] Vgl. (Luckham & Schulte, 2010, S. 5)

^[10] Vgl. (Bruns & Dunkel, 2010, S. 48)

^[11] Vgl. (Luckham, 2012, S. 52)

^[12] (Bruns & Dunkel, 2010, S. 48)

^[13] Vgl. (Luckham & Schulte, 2010, S. 5)

^[14] Vgl. (Luckham & Schulte, 2010, S. 15)

^[15] Vgl. (Taylor, Yochem, & Phillips, 2009, S. 65)

^[16] Vgl. (Hohpe & Woolf, 2003)

^[17] Vgl. (Gamma, Helm, Johnson, & Vlissides, 1994, S. 293 ff.)

^[18] Vgl. (Luckham & Schulte, 2010, S. 16)

^[19] Vgl. (Luckham, 2002, S. xv - xix)

^[20] (Luckham, 2002)

^[21] Vgl. (Bruns & Dunkel, 2010, S. 10)

^[22] Beispielsweise Oracle, CEP, IBM, Tibco, StreamBase Systems und Progress

^[23] Vgl. (Bruns & Dunkel, 2010, S. 4)

^[24] Vgl. (Aier, 2007, S. 103 ff.)

^[25] (Balzert, 2001)

^[26] Vgl. (Dunkel et al. 2008, S. 7)

^[27] Vgl. (Dunkel et al. 2008, S. 8)

^[28] Vgl. (Krafzig, Banke, & Slama, 2007, S. 68)

^[29] Vgl. (Aier & Winter, 2008, S. 3)

^[30] Vgl. (Aier & Winter, 2008, S. 4)

^[31] Vgl. (Dunkel et al. 2008, S. 9)

^[32] Vgl. (Bruns & Dunkel, 2010, S. 13)

^[33] Vgl. (Luckham, 2002, S. 28 - 30)

^[34] Vgl. (Bruns & Dunkel, 2010, S. 15 - 18)

^[35] (Bruns & Dunkel, 2010, S. 15)

^[36] Vgl. (Bruns & Dunkel, 2010, S. 18)

^[37] Unter konventionellen Softwarearchitekturen werden alle Architekturstile zusammengefasst, die die Ereignisverarbeitung nicht als zentrales Konzept verwenden.

^[38] (Luckham, 2002, S. 6)

^[39] Vgl. (Bruns & Dunkel, 2010, S. 23ff.)

^[40] Vgl. (Bruns & Dunkel, 2010, S. 25 - 26)

^[41] Vgl. (ebd., S. 24 -25)

^[42] Vgl. (Luckham, 2012, S. 15)

^[43] Vgl. (Luckham, 2012, S. 4)