Masterarbeit. Integration ereignisbasierter Middleware- Systeme in kontextbasierte Geschäftsprozesse

Transkript

1 Universität Hamburg Fakultät für Mathematik, Informatik und Naturwissenschaften Verteilte Systeme und Informationssysteme Masterarbeit Integration ereignisbasierter Middleware- Systeme in kontextbasierte Geschäftsprozesse Richard Günther Studiengang Wirtschaftsinformatik Matrikelnummer Fachsemester 4 Erstgutachter: Zweitgutachter: Professor Dr. Lamersdorf Professor Dr. Böhmann

2

3 Integration ereignisbasierter Middleware-Systeme in kontextbasierte Geschäftsprozesse III Inhaltsverzeichnis 1 Einleitung Motivation Zielsetzung Aufbau der Arbeit Grundlagen Einführung und Begriffsklärung Kontextbasierte Geschäftsprozesse Technische Integration Fachliche Integration Abschließende Betrachtung der konzeptuellen Ausgangslage Grundlagen der BPMN Ereignisbasierte Architekturen Charakteristika einer ereignisbasierten Architektur Aufbau einer ereignisbasierten Architektur Kommunikationen einer ereignisbasierten Architektur Sensordaten-Middleware-Systeme Untersuchung von Sensordaten-Middleware-Systemen Gemeinsamkeiten kontextbasierter Geschäftsprozesse Gemeinsamkeiten von Sensordaten-Middleware-Systemen Meta-Funktionen Meta-Protokoll Meta-Daten Zu integrierende Aspekte von Sensordaten-Middleware-Systemen Vorgehensweise zur Integration von Sensordaten-Middleware-Systemen Thematisch verwandte Arbeiten Entwurfsentscheidungen Gemeinsamkeiten bei der Modellierung ereignisbasierter Protokoll-Schritte Beispiel-Modellierungen Prototypische Umsetzung des Konzepts Webservice-Aufrufe in BPMN Workflow-Engine

4 IV Richard Günther 5.3 Proxy Interaktionsbeispiel Fazit und Ausblick Diskussion Risiken Chancen Zusammenfassung Ausblick Erweiterungen Verwandte Aspekte A Ereignisabfragen der Sensordaten-Middleware-Systeme B Übertragene Daten B.1 Jadex Event Stream Processing Architecture (JESPA) B.2 Global Sensor Network (GSN) B.3 EPCglobal: ALE-Middleware B.4 Sensor Web Enablement (SWE) C Zuordnung von systemspezifischen Funktionen zu Schritten des Meta-Protokolls... 1 D Meta-Daten... 1 D.1 Daten-Perspektive... 1 D.2 Ausnahmebehandlungs-Perspektive... 3 D.3 Service-Perspektive... 5 D.4 Zeit-Perspektive... 7 Literaturverzeichnis... 8 Abbildungsverzeichnis Tabellenverzeichnis Erklärung... 28

5 Integration ereignisbasierter Middleware-Systeme in kontextbasierte Geschäftsprozesse 1 1 Einleitung In diesem Kapitel wird eine Motivation zur Aufgabenstellung sowie die resultierende Zielsetzung eingeführt. Zum Abschluss wird überblicksartig der Aufbau dieser Arbeit vorgestellt. 1.1 Motivation Sinkende Produktionskosten begünstigen den zunehmenden Einsatz von Sensoren, die Umgebungsinformationen (Kontext) digital erfassen und so die physische und virtuelle Welt verbinden beispielsweise durch die Erfassung von Temperaturen, Wasserständen oder der Ankunft eines Containers. Im Zuge der steigenden Vernetzung sehen sich Unternehmen einer wachsenden Menge von geschäftsrelevanten Ereignissen ausgesetzt, auf die im Sinne der Wettbewerbsfähigkeit möglichst schnell zu reagieren ist [Luc01]. Unternehmen wie Google oder Dell integrieren diese Ereignisdaten in ihre Geschäftsprozesse, sodass sie vom Marktforschungsunternehmen Gartner als Real-Time Enterprise bezeichnet werden [S03]. Derzeit kann diese Integration jedoch nicht automatisiert erfolgen, sodass aus der manuellen Bereitstellung von Ereignisdaten höhere Latenzen resultieren. Eine Automatisierung würde der Tendenz folgen, Prozesse im Rahmen des Business-IT-Alignments auch zur Orchestrierung von IT-Systemen zu verwenden. Daraus ergibt sich jedoch die Anforderung an eine gemeinsame Modellierungssprache für folgende Prozessebenen: Technische Prozesse können von IT-Systemen interpretiert und ausgeführt werden Fachliche Prozesse Abstrahieren von technischen Details und genügen übergeordneten Prozesszielen Mit Einführung der Geschäftsprozessmodellierungssprache BPMN 2.0 durch die OMG existiert nun erstmals eine gemeinsame, standardisierte Sprache für beide Ebenen. Wünschenswert wäre nun, Ereignisdaten in beide Ebenen zu integrieren, um sie automatisiert verarbeiten und in übergeordnete Prozessziele integrieren zu können. 1.2 Zielsetzung BPMN 2.0 ermöglicht die Modellierung sowohl fachlicher als auch technischer Prozesse. Für die automatisierte Bereitstellung von Ereignisdaten in Geschäftsprozesse sind folglich zwei Dinge nötig: 1. Modellierung von Ereignisdaten auf fachlicher Ebene 2. Integration von Ereignisdaten in technische Prozesse Für die erste Aufgabe ist ein Handlungsrahmen zur Modellierung von Ereignisdaten für fachliche Modellierer auf Basis von BPMN 2.0 notwendig. Ziel ist, die resultierenden Prozesse durch Workflow-Engines ausführen lassen zu können. Voraussetzung ist eine Lö-

6 2 Richard Günther sung für die zweite Aufgabe: Zur Bereitstellung von Ereignisdaten auf technischer Ebene ist eine Integration der verschiedenen, proprietären Sensordaten-Middleware-Systeme nötig. Folgende Abbildung 1 skizziert die resultierenden Integrationsaufgaben. Abbildung 1: Aufgaben zur Integration von Ereignisdaten in Geschäftsprozesse Für die erste Aufgabe ist eine Integrationslösung für die verschiedenen, proprietären Sensordaten-Middleware-Systeme zu erarbeiten. Ziel ist, Prozesse mit Abstraktionen für Ereignisdaten durch verschiedene, ebenfalls proprietäre Workflow-Engines ausführen lassen zu können. Für die zweite Aufgabe ist die Entwicklung eines Handlungsrahmens zur Modellierung von Ereignisdaten für fachliche Modellierer auf Basis von BPMN 2.0 sinnvoll. Ziel ist, diese durch Workflow-Engines ausführen zu lassen. Diese müssen wiederum in der Lage sein, verschiedene Sensordaten-Middleware-Systeme anzusprechen, weswegen eine Verbindungskomponente (Connector) nötig sein könnte. 1.3 Aufbau der Arbeit Im Zweiten Kapitel werden grundlegende Begriffe von Kontext, Geschäftsprozess sowie die Integration technischer Systeme und fachlicher Modellierungssprachen und ebenen vorgestellt. Dabei wird die Bedeutung von BPMN 2.0 als gemeinsame Sprache für Business und IT herausgestellt. Im dritten Kapitel werden die Spezifikationen vier verschiedener Sensordaten- Middleware-Systeme aus Sicht der Anbieter (Funktionen der Systeme) und Nutzer (Anforderungen der Geschäftsprozesse) untersucht. Im Anschluss wird eine generische Datenund Interaktionsstruktur vorgestellt, mit der sich alle untersuchten Sensordaten- Middleware-Systeme ansprechen lassen. Im vierten Kapitel wird eine Vorgehensweise zur Integration von Ereignisdaten in Geschäftsprozesse vorgestellt. Dazu werden zunächst bereits vorhandene Ansätze hinsichtlich ihrer Eignung untersucht, um darauf aufbauend Entwurfsentscheidungen für die Modellierung zu begründen. Im Anschluss werden die erarbeiteten Modellierungskon-

7 Integration ereignisbasierter Middleware-Systeme in kontextbasierte Geschäftsprozesse 3 strukte vorgestellt. Als ersten Beleg der Durchführbarkeit werden Geschäftsereignisse, aus denen im dritten Kapitel Anforderungen an eine fachliche Modellierung von Ereignisdaten identifiziert wurden, mithilfe dieser Konstrukte modelliert. Im fünften Kapitel wird, als zweiter Beleg der Durchführbarkeit, die prototypische Umsetzung des Konzepts vorgestellt. Die Umsetzung der Integrationsstruktur für die verschiedenen Sensordaten-Middleware-Systeme wird mit einer exemplarischen Workflow-Engine kombiniert, um fachlich modellierten Prozessen den Zugriff auf Ereignisdaten zu ermöglichen. Im letzten Kapitel wird der vorgestellte Lösungsansatz diskutiert und im Kontext der überreifenden Integration betrachtet. Anschließend werden sich daran anknüpfende Aufgabenstellungen und Erweiterungsmöglichkeiten vorgestellt.

8 4 Richard Günther 2 Grundlagen In diesem Kapitel wird der Geschäftsprozessbegriff und seine Bedeutung für die Integration der fachlichen und technischen Ebenen eines Unternehmens vorgestellt. Nachdem so die konzeptuelle Ausgangslage beschrieben wurde, erfolgt die Vorstellung der Geschäftsprozessmodellierungssprache BPMN 2.0 mit einigen Notationselementen, die im weiteren Verlauf von Interesse sind. Schließlich werden ereignisbasierte Architekturen in Abgrenzung zu einer service-orientierten Architektur (SOA) vorgestellt sowie deren Aufbau erläutert. Die Verwendung einer ereignisorientierten Architektur eignet sich u.a. für Sensordaten-Systeme, deren Ziel allgemein das Erzeugen von einfachen oder komplexen Ereignissen aus physischen Messwerten ist. In dem Zusammenhang werden typische Kommunikationsmuster betrachtet. Abschließend werden einige relevante Sensordaten-Middleware- Systeme als Vertreter ereignisbasierter Systeme vorgestellt und hinsichtlich ihrer Abstraktionsebene eingeordnet, sodass im Ergebnis die Grundlagen für die verschiedenen Aspekte des Integrationsvorhabens vorliegen. 2.1 Einführung und Begriffsklärung In diesem Kapitel wird der Geschäftsprozessbegriff und seine Bedeutung für die ganzheitliche Integration verschiedener Aufgabenträger-Ebenen eines Unternehmens vorgestellt. Im Zuge der Integration technischer Sensordaten-Middleware-Systeme in fachliche Prozesse werden zunächst die Grundlagen prozessbasierter Integration auf technischer und fachlicher Ebene erläutert Kontextbasierte Geschäftsprozesse Im Jahre 1776 stellte Adam Smith den Grundsatz der Arbeitsteilung vor, der später von W. Taylor und H. Ford aufgegriffen und mit Einführung der Fließbandarbeit ab 1913 wirtschaftlich erfolgreich wurde [Sm07]. In der Wissenschaft beschränkte man sich lange darauf, das Koordinieren von Teilaufgaben und Verbessern betrieblicher Abläufe nicht prozessorientiert, sondern nur im hierarchischen Kontext von Aufbauorganisationen zu betrachten. Die daraus resultierende mangelnde Flexibilität, beispielsweise die Tatsache, dass Ford seine Autos in nur einer Farbe produzieren konnte, wurde allerdings zum Wettbewerbsnachteil. Als einer der ersten wies F. Nordsieck bereits 1932 auf die Notwendigkeit einer kundenorientierten Prozessorganisation hin [N32]. Dabei wird das Unternehmen nach durchgängigen Prozessen, die vom Lieferanten bis zum Kunden reichen, organisiert. Prozesse werden abstrakt als Folge zusammenhängender Aktivitäten gesehen, die jeweils einen Input konsumieren, einen Output erzeugen und das Ziel einer Leistungserstellung haben [LH07]. Geschäftsprozesse hingegen beziehen den Unternehmenskontext explizit mit ein, werden in der Literatur jedoch unterschiedlich definiert. Gadatsch liefert folgende, umfassende Definition [G98, G10, K07]:

9 Integration ereignisbasierter Middleware-Systeme in kontextbasierte Geschäftsprozesse 5 Ein Geschäftsprozess ist eine zielgerichtete, zeitlich-logische Abfolge von Aufgaben, deren Ausführung teilweise oder vollständig von Anwendungssystemen unterstützt werden können. Er dient der Erstellung von Leistungen entsprechend den vorgegebenen, aus der Unternehmensstrategie abgeleiteten Prozesszielen. Ein Geschäftsprozess kann formal auf unterschiedlichen Detaillierungsebenen und aus mehreren Sichten beschrieben werden. Geschäftsprozesse werden vornehmlich erstellt, um u.a. [R06, St06] vorhandene Abläufe zu dokumentieren sie mit gesetzlichen oder unternehmensinternen Vorgaben abzugleichen (Compliance Management [SGW10]) eine IT-gestützte Automatisierung vorzubereiten Dementsprechend adressieren sie überwiegend fachliche Anwender und haben zum Ziel, Prozesse möglichst verständlich zu kommunizieren. Der letzte Punkt verweist jedoch auf das zunehmende Interesse an der Prozessautomatisierung, die auf Grundlage immer leistungsfähigerer IT-Systeme stetige Effizienzgewinne verspricht. In Abgrenzung zum Geschäftsprozess wird ein Workflow als einen durch Anwendungssysteme unterstützten, steuerbaren Prozess beschrieben [L07, S.155]. Der Einbezug verschiedener Quellen ergibt folgende Definition [G10, G98, K07]: Ein Workflow ist ein formal beschriebener, ganz oder teilweise automatisierter Geschäftsprozess. Er beinhaltet die zeitlichen, fachlichen und ressourcenbezogenen Spezifikationen, die für eine automatische Steuerung des Arbeitsablaufs auf der technischen Ebene erforderlich sind. Die hierbei anzustoßenden Arbeitsschritte sind zur Ausführung durch Mitarbeiter und / oder Anwendungssysteme vorgesehen. Es wird deutlich, dass Workflow-Modelle entstehen, indem Geschäftsprozessmodelle derart verfeinert werden, dass sie automatisch verarbeitet werden können. Die automatische Verarbeitung bezieht sich allerdings nicht zwangsläufig auf einen vollautomatischen Ablauf, sondern auf eine Prozesssteuerung, die menschliche oder maschinelle Prozessbeteiligte einbindet und deren Ergebnisse weiterverarbeitet [FRH10]. Diese aktive Prozesssteuerung wird durch ein Workflow-Management-System realisiert. Weil Geschäftsprozessmodelle von Anwendern verstanden und Workflow-Modelle von Maschinen interpretiert werden sollen, unterscheiden sich die resultierenden Modelle grundlegend. Dementsprechend werden innerhalb eines Unternehmens die in Abbildung 2 gezeigten Modellierungsebenen unterschieden:

10 6 Richard Günther Abbildung 2: Ebenen eines integrierten Geschäftsprozessmanagements nach [G10] Die verschiedenen Modellierungsebenen werfen die Frage nach der Integrierbarkeit fachlicher und technischer Modelle auf, wie beispielsweise die Überführung von Geschäftsprozessen in Workflows. Das erfolgt üblicherweise in einem als Round-Trip bezeichneten Verfahren, in dem der Geschäftsprozess um technische Details einzelner Aktivitäten erweitert wird. Beispielsweise muss spezifiziert werden, wie der Methodenaufruf innerhalb des Workflow-Management-Systems lautet, welche Parameter übergeben werden und was im Fehlerfall passieren soll. Weil es bislang keine Modellierungssprache gibt, mit der sich sowohl fachliche aus als technische Modelle problemlos und ihrem Zweck entsprechend abbilden lassen, müssen fachliche Modelle mehr oder weniger geeignet durch Entwickler umgesetzt werden [A11]. Diese Integrationslücke zwischen Business und IT ermöglicht nur einen manuellen, potentiell fehlerbehafteten Round-Trip. Nachdem die automatische Ausführung von Geschäftsprozessen durch Workflows skizziert wurde, werden kontextbasierte Geschäftsprozesse als weiterer Schritt in Richtung automatisierter Prozesse vorgestellt. Die zugrundeliegende Vision des Pervasive Computing beschreibt die allgegenwärtige Präsenz von Informationstechnologien in Form kleiner, drahtlos miteinander kommunizierender Geräte [H03]. Zu diesen Geräten gehören sich selbstständig vernetzende Sensoren, die Informationen erfassen und digitalisieren. Sie erfassen den Kontext, definiert als jegliche Information, mit der sich die Situation einer Entität beschreiben lässt [ADB+99]. Kontextbasierte Systeme beziehen alle durch Sensoren erfassten Umgebungsinformationen mit ein und steuern auf dieser Grundlage das Systemverhalten [F09]. Dementsprechend beziehen kontextbasierte Geschäftsprozesse Zustandsinformationen der beteiligten Entitäten mit ein. Beispielsweise kann ein Prozess in Abhängigkeit von der Temperatur einer Produktionsmaschine entscheiden, ob die Produktionsmenge weiter gesteigert werden soll. Das setzt jedoch die Erfassung, Sammlung, Aggregation und Inter-

11 Integration ereignisbasierter Middleware-Systeme in kontextbasierte Geschäftsprozesse 7 pretation von Sensordaten sowie die geeignete Aufbereitung und Bereitstellung der daraus extrahierten Informationen für die Anwendung voraus, wofür typischerweise Sensordaten- Middleware-Systeme eingesetzt werden [F09]. Aufgrund ihrer Nähe zur technischen Ebene werden diese kontextbasierten Geschäftsprozesse von Wieland et al. als Smart Workflows bezeichnet und mit eigenen Modellierungssprachen modelliert [WNL08]. Entsprechend der Integrationslücke zwischen Business und IT ist es bislang nicht möglich, ein fachliches Modell automatisch weiterverarbeiten zu lassen. Die zugrundeliegende Problematik veranlasste u.a. Bucher und Winter [WGB09], den Begriff des integrierten Geschäftsprozessmanagements vorzustellen. Ziel ist die ganzheitliche Planung, Steuerung, Analyse und Unterstützung von Geschäftsprozessen unter Einbezug der strategischen, fachlichen und technischen Ebene [FRH10, G10, Ge98]. Grundsätzlich bedeutet Integration die Herstellung eines Ganzen durch Vereinigung oder Verbindung logisch zusammengehöriger Teile [H94]. In den beiden nachfolgenden Abschnitten werden daher sowohl technische als auch fachliche Integrationsansätze mit ihrer jeweiligen Integrationsaufgabe vorgestellt. Ziel ist, die Bedeutung des Geschäftsprozessbegriffs für die ganzheitliche Integration verschiedener Sichten auf betriebliche Abläufe herauszustellen Technische Integration Integrationsaufgabe: Einheitliche Anwendungslandschaft Die automatische Verarbeitung von Prozessmodellen im Rahmen eines Round-Trips zieht einen fachlich motivierten Integrationsbedarf technischer Ebenen nach sich. Ziel ist die prozessgesteuerte Zuweisung einzelner Aufgaben zu den korrespondierenden Anwendungssystemen. Um von Prozessen adressiert werden zu können, müssen die verteilten Komponenten eines Anwendungssystems als auch die gesamte Anwendungslandschaft einheitlich integriert werden [Sc06, K07, CHK+06]. Im vorherigen Abschnitt wurden Workflow-Management-Systeme zum automatischen Ausführen und Steuern von Workflows auf technischer Ebene durch Mitarbeiter und / oder Anwendungssysteme vorgestellt. Die zugrundeliegenden Zusammenhänge subsumiert Sinz unter dem Begriff des Informationssystems, indem er die in Abbildung 3 gezeigten Ebenen der Aufgaben und Aufgabenträger einführt:

12 8 Richard Günther Abbildung 3: Aufgaben und Aufgabenträger eines Informationssystems nach [Sc06] Ziel des Informationssystems ist folglich, Prozesse in Aufgaben zu zerlegen und diese von Anwendungssystemen unterstützen oder ausführen zu lassen. Aufgrund komplexer Unternehmensstrukturen wird dabei von verteilten Systemen ausgegangen. Diese treten als einheitliches System auf, bestehen hardwareseitig jedoch aus autonomen Komponenten, die miteinander kommunizieren (Verteilungstransparenz) [CHK+06]. Typischerweise gibt es verschiedene dieser Anwendungssysteme, die bei Ausführung eines Geschäftsprozesses interagieren müssen. Die Integration innerhalb verteilter Systeme sowie zwischen verschiedenen verteilten Systemen führt, sofern sie ohne methodische Grundlage erfolgt, zu sog. Spaghetti-Szenarien [Sc06]. Für diese ist charakteristisch, dass die Anzahl der Schnittstellen mit Aufnahme neuer Teilnehmer quadratisch anwächst. Folgende Ebenen werden von Integrationsbemühungen adressiert [LSL+08]: Datenintegration Anwendungssysteme werden auf Datenebene gekoppelt, entweder indem eine gemeinsame Datenbank verwendet wird oder die verschiedenen Datenbanken föderiert, also einheitlich zugreifbar gestaltet werden [TS08]. Funktionsintegration Nach erfolgter Datenintegration können logisch zusammenhängende Funktionen gruppiert werden. Dies geschieht entweder durch Fokussierung auf einen logischen Aufgabenträger, also beispielsweise eine Abteilung, oder auf einen Datenfluss, der beispielsweise aus einer Aufgabenstruktur resultiert. Objektintegration Objekte fassen Funktionen und Datenstrukturen zu logischen Einheiten zusammen und kommunizieren untereinander über Nachrichten. Ziel ist folglich die Integration der Kommunikationsstrukturen zwischen den Objekten eines Anwendungssystems. Prozessintegration Auf Prozessebene werden nicht primär die unterstützenden Anwendungssysteme betrachtet, sondern die Ablauflogik des Gesamtprozesses fokussiert. Folglich wird der Prozesskontext mit den zugehörigen Objekten und Daten integriert. Verschiedene Konzepte haben die Integration der ersten drei, technischen Ebenen in die Prozessebene zum Ziel. Bis Anfang der neunziger Jahre wurden diese drei Ebenen in monolithischen, also vollständig zentralen Block-Systemen umgesetzt. Im Zuge eines komponentenbasierten Architekturansatzes, der abgeschlossene, wiederverwendbare Softwareteile beinhaltet [OHE95], lassen sich grundlegend die in Abb. Abbildung 4 gezeigten drei Komponenten identifizieren [HGR+06]:

13 Integration ereignisbasierter Middleware-Systeme in kontextbasierte Geschäftsprozesse 9 Abbildung 4: Grobe Unterteilung eines Komponentenbasierten Architekturansatzes Der gezeigte Architekturansatz wird typischerweise von großen, betrieblichen Standardanwendungssystemen wie z.b. SAP R/3 verwendet. Die Präsentationskomponente ist sowohl für die Darstellung als auch die Benutzerinteraktion verantwortlich. Zur Verarbeitung gehört die implementierte Logik sowie die Koordination aller involvierten Systemteile. Für die Persistierung von Ein- oder Ausgabedaten ist die Datenhaltung zuständig. Ein weiterer Schritt in Richtung eines dezentralen, komponentenbasierten Systems ist die in Abb. Abbildung 5 gezeigte Zergliederung der Verarbeitungskomponente in folgende Elemente: Einzelne Funktionen als abgeschlossene, wiederverwendbare Dienste Das Workflow-Management für die Zuordnung von Aufgaben zu Funktionen Eine Middleware zur Integration der verschiedenen, oft heterogenen Systeme Abbildung 5: Bestandteile einer dezentralen, komponentenbasierten Architektur Weil einzelne Funktionen von verschiedenen, heterogenen Anwendungssystemen angeboten werden können, ist deren Kopplung durch eine Middleware empfehlenswert. Sie schafft Verteilungstransparenz, indem sie in einem heterogenen Systemumfeld [s.30 Rautenstrauch 1993] die Verbindung zwischen verschiedenen Systemen herstellt und Kommuni-

14 10 Richard Günther kation organisiert. Klassische Middleware-Systeme etablieren einheitliche Schnittstellen und stellen verteilte Daten, Funktionen und Objekte bereit. Dazu gehören unter anderen Remote Procedure Calls (RPC, [W76]) oder nachrichten-orientierte Middleware-Systeme (engl. Message-oriented Middleware, MOM [TS08]). Darüber hinaus bieten manche Lösungen die Transformation der ausgetauschten Nachrichten an, beispielsweise indem Adapter die Einbindung fremder Schnittstellen ermöglichen. Jede Funktion setzt eine Aktivität des Workflows um. Aufgabe des Workflow-Management-Systems ist die Steuerung der Abfolge von Aktivitäten sowie die Weiterleitung von Prozessdaten an die beteiligten Aufgabenträger [HGR+06, FRH10, TS08]. Zum ganzheitlichen Geschäftsprozessmanagement ist neben der Funktionsintegration durch eine Middleware sowie der Prozesssteuerung durch ein Workflow-Management-System jedoch noch die Integration von Rollen, Regeln, Ausnahmen, Benutzeroberflächen und die Überwachung von Service Level Agreements (SLAs, [B07]) notwendig [A11]. Enterprise Application Integration (EAI, [CHK+06]) wird als Lösung für das eingangs erwähnte, ganzheitliche Geschäftsprozessmanagement genannt. Grundsätzliche Idee ist die Erweiterung der vor allem auf Datenaustausch ausgelegten Middleware-Systeme um prozessorientierte Ansätze des Workflow-Managements. Ziel ist die Integration von Anwendungen über unterschiedliche technische und logische Infrastrukturen hinweg. [D02] Neben Middleware- und Workflow-Management- Funktionalitäten beinhaltet das Konzept die in Abb. Abbildung 6 gezeigten Komponenten: Abbildung 6: Komponenten eines Enterprise Application Integration-Werkzeugs [HGR+06] Ein EAI-Werkzeug benötigt eine Kommunikationsinfrastruktur, hier als Netzwerk bezeichnet. Darauf aufbauend werden die heterogenen Schnittstellen beliebiger Systeme mittels Adaptern vereinheitlicht und somit integriert. Eine Middleware leistet die Datenintegration, indem sie als Mediator zwischen verschiedenen Systemen agiert. Eine Integration der Systeme auf semantischer Ebene bietet jedoch nur das Nachrichtenmanagement, indem es Datentransformationen, zeitliche Synchronisationen oder Transaktionsdurchführungen

15 Integration ereignisbasierter Middleware-Systeme in kontextbasierte Geschäftsprozesse 11 anbietet. Im Rahmen des Prozessmanagements werden Modelle gepflegt, in Workflows überführt und deren Ausführung durch Metriken kontrolliert. Die Metadatenbank umfasst unternehmensweite Integrationsbeziehungen, Datenschemata sowie für die Administration notwendige Zusatzdienste. Folgende Abbildung Abbildung 7 konkretisiert die technische und fachliche Ebene aus Abb. Abbildung 2 und ordnet ihnen die vorgestellten Integrationskonzepte zu: Abbildung 7: Einordnung technischer Integrationskonzepte in die technische und fachliche Ebene nach [K07] Theoretisch lassen sich beliebige, fachlich motivierte Aspekte durch Integration der Prozessdefinition in das bestehende EAI-System umsetzen. Auf praktischer Ebene ergeben sich jedoch einige Schwierigkeiten. In einem 2006 durchgeführten Vergleich [Sc06] wird deutlich, dass nur die wenigsten EAI-Ansätze das eingangs vorgestellt Ziel des integrierten Geschäftsprozessmanagements umsetzen. Wo sie idealerweise eine vom fachlichem Integrationsbedarf ausgehende, durchgängige Betrachtung von der Applikations- bis hin zur Softwarekomponenten- und Datenstrukturebene ermöglichen sollten, fokussieren sie fast ausschließlich auf Integrationsaspekte der Softwarekomponenten- und Datenstrukturebene [Sc06]. Das äußert sich in der mangelnden Unterstützung automatischer Round-Trips, sodass häufig manuelle Anpassungen von fachlichen Modellierern sowie technischen Systemintegratoren nötig sind. Dementsprechend gelingt es den Systemen auch nicht, strategische Einflüsse automatisch zur technischen Ebene zu propagieren. Als Grund nennt Allweyer das Fehlen einer Modellierungssprache, die komplexe fachliche Anforderungen abbilden und automatisch in einen Workflow überführt werden kann [A11]. Der nachfolgende Abschnitt beschäftigt sich folglich mit Modellierungssprachen und ihrem Potential, die strategische und technische Ebene zu integrieren Fachliche Integration Integrationsaufgabe: Ganzheitliche Modellierungssprache Diese sollte im Sinne einer gemeinsamen Sprache sowohl die fachliche als auch technische Ebene abdecken. Bislang unterscheiden sich Modelle grundlegend, weil sie verschiedene Ziele haben. Fachliche Modelle adressieren Anwender, während technische Modelle

16 12 Richard Günther von Maschinen interpretiert werden. Im Sinne eines integrierten Geschäftsprozessmanagements sollen fachlich erstellte Modelle jedoch die strategischen Einflüsse widerspiegeln und durch automatische Round-Trips in Workflows überführt werden können. Um zu untersuchen, inwiefern eine Modellierungssprache diese Anforderungen erfüllen kann, wird zunächst der Begriff des Modellierens genauer betrachtet. Ganz allgemein erfolgt eine Modellierung durch die Begrenzung auf einen Ausschnitt der Realität und die Abstraktion von Details, die für eine bestimmte Fragestellung nicht relevant sind [LH07]. Bornhövd et al. führen aus, dass zur Darstellung komplexer Prozesse mit allen relevanten Aspekten, wie Verzweigungsregeln, Ereignissen, ausführenden Organisationseinheiten, Datenflüssen usw. eine Notation notwendig sei. Sie legt fest, welche Symbole zur Repräsentation einzelner Prozesselemente benutzt werden, was sie bedeuten und wie sie kombiniert werden können [A09]. Ziel ist die Erstellung eines Modells, das von Dritten verstanden werden kann, sofern sie die Notation beherrschen. Allgemein lassen sich Notationen in formale und grafische Diagrammsprachen unterscheiden. Formale Sprachen beschreiben Geschäftsprozesse auf technischer Ebene in Form von Scriptsprachen wie z.b. XML. Mit XPDL (XML Process Definition Language, [WfMC-1]) und BPEL (Business Process Execution Language [OASIS-1]) existieren bereits Standards, die sich auf fachlicher Ebene jedoch als ungeeignet erwiesen haben. Dort eignen sich grafische Diagrammsprachen, die in datenfluss-, kontrollfluss- und objektorientierte Ansätze unterschieden werden: Abbildung 8: Einige grafische Diagrammsprachen nach [G10] Datenflussorientierte Ansätze entstammen der Softwareentwicklung, haben jedoch keine nennenswerte Bedeutung erlangt. Starke Verbreitung haben sowohl die Ereignisbasierte Prozessketten (EPK, [KNS92a]) als auch die Business Process Model and Notation (BPMN, [OMG-3]) aus dem Bereich der kontrollflussorientierten Sprachen erlangt 1. Vertreter objektorientierter Ansätze wie Activity-Diagramme (grobe, sehr abstrakte Prozessbeschrei- 1 Vgl.

17 Integration ereignisbasierter Middleware-Systeme in kontextbasierte Geschäftsprozesse 13 bungen) oder Use-Case-Diagrammen (Zusammenhänge zwischen Funktionen und Organisationseinheiten) werden zunehmend eingesetzt, eignen sich aber schlechter als kontrollflussbasierte Ansätze zur klassischen Prozessmodellierung [G10]. Die EPK ist eine weit verbreitete Notation zur Modellierung fachlicher Geschäftsprozesse und wurde im Umfeld von SAP-Einführungen durch das Modellierungswerkzeug ARIS der IDS Scheer populär. Sie wurde jedoch nicht standardisiert, erfährt von anderen Softwareherstellern nur geringe Unterstützung und eignet sich vergleichsweise schlecht zur Modellierung technischer Aspekte [FRH10]. Im Gegensatz dazu proklamiert die BPMN in der Anfang 2011 veröffentlichten Version 2.0, sich gleichermaßen für die Modellierung von technischen als auch fachlichen Modellen zu eignen [OMG-3] und folglich einen automatischen Round-Trip zu ermöglichen. Hintergrund ist, dass für alle Notationselemente eine Ausführungssemantik auf Grundlage eines formalen Metamodells spezifiziert wurde. Infolgedessen wird sie als Hoffnungsträger für ein integriertes Prozessmanagement gehandelt. Auch wenn BPMN 2.0 sowohl im technischen als auch fachlichen Bereich zunehmende Akzeptanz erfährt (FRH10, A09), kann sie nur als ein weiterer Schritt in Richtung eines integrierten Geschäftsprozessmanagements gesehen werden. Hintergrund ist, dass Geschäftsprozesse zwar hauptsächlich durch Kontrollflüsse spezifiziert werden, darüber hinaus jedoch auch Rollen- und Organisationsstrukturen, Regeln für das Zuweisen von Prozessverantwortung, Messpunkte für das Errechnen von Kennzahlen, Service Level zur Erfüllung nichtfunktionaler Anforderungen sowie komplexe Geschäftsregeln beinhalten [A11]. Derartige Zusammenhänge lassen sich, genau wie strategische Einflüsse, nur unzureichend modellieren und können daher nicht zur technischen Ebene propagiert werden. Nachdem der aktuelle Stand konzeptueller Integrationsansätze sowohl auf technischer als auch fachlicher Ebene vorgestellt wurde, erfolg im nachfolgenden Kapitel eine abschließende Zusammenfassung der integrationsbezogenen Grundlagen, auf denen diese Arbeit fußt Abschließende Betrachtung der konzeptuellen Ausgangslage Ausgehend von der technischen Ebene wurde in Kap das EAI-Konzept als mögliche Lösung für das ganzheitliche Geschäftsprozessmanagement vorgestellt. Es leistet zwar die technische Integration der Anwendungslandschaft, bietet jedoch keine automatischen Round-Trips, sodass die strategische und fachliche Ebene nur unzureichend integriert werden. Abhilfe verspricht die in Kap erwähnte Modellierungssprache BPMN 2.0, mit der fachliche Modelle erstmals automatisch in Workflows überführt werden können. Damit integriert sie wie in Abb. Abbildung 9 gezeigt die fachliche und technische Ebene:

18 14 Richard Günther Abbildung 9: Einordnung der BPMN 2.0 in die drei Integrationsebenen BPMN 2.0 kann die Integrationslücke zwischen Business und IT jedoch nicht vollständig schließen, weil sich komplexe organisatorische Zusammenhänge nur unzureichend abbilden lassen. Hierfür sind komplexe Fachkonzepte, wie sie beispielsweise das ARIS-Toolset bietet, notwendig. Derart erzeugte Modelle können jedoch nicht für automatische Round- Trips verwendet werden, sodass folgende zwei Punkte unvereinbar sind: 1. komplexe, organisatorische Zusammenhänge sowie strategische Einflüsse werden fachlich modelliert 2. fachliche Modelle können automatisch in Workflows überführt werden Trotz dieser Einschränkung begrüßt Allweyer die Verwendung von BPMN 2.0 durch technische und fachliche Anwender als die Verwendung einer gemeinsamen Sprache und weiteren Schritt in Richtung eines integrierten Geschäftsprozessmanagements [A11]. Dementsprechend wird die Notation der BPMN 2.0 als Grundlage für das Integrationsvorhaben dieser Arbeit verwendet und einige, grundlegende Notationselemente der BPMN 2.0 im nachfolgenden Abschnitt vorgestellt. 2.2 Grundlagen der BPMN 2.0 Nachfolgend werden einige grundlegende Konzepte der BPMN mit den dazugehörigen Notationselementen vorgestellt. Der Abschnitt bietet jedoch keine vollständige Übersicht aller verfügbaren BPMN-Notationselemente. Stattdessen werden hauptsächlich Notationselemente vorgestellt, die im Hinblick auf das Ziel dieser Arbeit von Interesse sind. Im Rahmen eines Prozesses müssen Dinge getan werden (Aktivitäten), eventuell unter bestimmten Bedingungen (Gateways), und es kann etwas passieren (Ereignisse) [FRH10]. Innerhalb von Bahnen (engl. Lanes) werden diese drei Elementtypen verschiedener Teilnehmer über Sequenzflüsse und außerhalb über Nachrichtenflüsse miteinander verbunden. Weitere Informationen können mit Artefakten dargestellt werden. Folgende Abbildung 10 zeigt die grundlegenden Elemente:

19 Integration ereignisbasierter Middleware-Systeme in kontextbasierte Geschäftsprozesse 15 Abbildung 10: BPMN-Kernelemente Sequenzflüsse dienen der Verknüpfung von Aktivitäten innerhalb eines Prozesses. Nachrichtenflüsse ermöglichen eine prozessübergreifende Kommunikation, und Assoziationen erlauben das Zuordnen von Artefakten zu Flussobjekten. Einen simplen Prozess zeigt folgende Abbildung: Abbildung 11: Modell eines einfachen Prozesses Zu beachten sind die unterschiedlichen Ränder der Ereignisse. Startereignisse haben einen einfachen Rand, Zwischenereignisse einen doppelten und Endereignisse einen fetten Rand. Die Aktivitäten (Mahlzeit zubereiten, Mahlzeit verzehren) zeigen an, was getan wird und werden üblicherweise aus einem Objekt und Verb gebildet, also Mahlzeit zube- reiten statt Zunächst muss die Zubereitung der Mahlzeit erfolgen. Ereignisse zeigen an, dass etwas passiert. Startereignisse (Hunger festgestellt) geben an, was passieren muss, damit der Prozess gestartet wird. Zwischenereignisse (Mahlzeit zubereitet) beschreiben einen Status, der im Prozess erreicht werden muss, bevor der Ablauf fortfährt, und Endereignisse (Hunger gestillt) zeigen, mit welchem Ereignis der Prozess endet. Die Ablauflogik lässt sich mithilfe von durchlaufenden Marken (engl. Token), wie in Abb. Abbildung 12 gezeigt, beschreiben. Grundlegend Begriffe werden wie folgt verwendet: In Schritt 1.) der Abbildung 12 hat die Aktivität Mahlzeit zubereiten einen eingehenden und einen ausgehenden Sequenzfluss. Analog zur Input-/ Output-Sichtweise konsumieren Ereignisse, Aktivitäten oder Gateways Marken, werden dadurch aktiviert, und leiten über die ausgehende(n) Kante(n) Marken weiter (außer beim Start- und Endereignis, die Marken erzeugen bzw. vernichten). Die

20 16 Richard Günther Aktivität Mahlzeit zubereiten wird in Schritt 2 also aktiviert, erledigt ihre Aufgabe, und leitet die Marke danach (in Schritt 3) weiter. Abbildung 12: Beschreibung der Ablauflogik mittels durchlaufender Marken In Bezug auf die Marken verhalten sich Ereignisse wie Aktivitäten bei Gateways hingegen ergibt sich eine andere Verhaltensweise. Gateways Angenommen, der Prozess aus Abbildung 12 wird wie folgt um exklusive Gateways erweitert: Abbildung 13: Verwendung eines exklusiven Gateways Der exklusive Gateway dient zur logischen Modellierung alternativer Pfade und kann in zusammenführender (A) oder verzweigender Funktion (B) verwendet werden. Der zusammenführende Gateway dient der Vereinigung mehrerer Sequenzflüsse. Entsprechend muss sichergestellt werden, dass nur von einer der eingehenden Sequenzflüsse (A1, A2 oder A3) eine Marke kommen kann. Beim verzweigenden Gateway wird aufgrund von Bedingungen entschieden, an welchen der ausgehenden Sequenzflüsse (B1, B2 oder B3) die Marke gereicht wird. Aufgrund der Exklusivität kann nur eine der ausgehenden Sequenzflüsse gewählt werden. Es ist nicht spezifiziert, wie Bedingungen formuliert oder geprüft werden, sodass sie entweder als Anmerkung, in Form von logischen Ausdrücken an den ausgehenden Sequenzflüssen ( schmeckt oder schmeckt nicht ) oder in Attributen (für die Ausführung durch eine Process Engine) gespeichert werden. Es wird davon ausgegangen, dass innerhalb eines Prozesses überall auf alle Daten zugegriffen werden kann [DG08]. Trifft keine der Bedingungen zu, kann ein Standardfluss (B3), gekennzeichnet

21 Integration ereignisbasierter Middleware-Systeme in kontextbasierte Geschäftsprozesse 17 durch einen kleinen Schrägstrich am Sequenzfluss, definiert werden. Dieser Standardfluss kann bei allen Gateways verwendet werden und verhindert, dass eine Marke fest hängt, wenn keine der beschriebenen Bedingungen zutrifft. Der parallele Gateway beschreibt parallel zu durchlaufende Sequenzflüsse: Abbildung 14: Verwendung eines parallelen Gateways Der verzweigende Gateway A erhält eine Marke als Eingabe, dupliziert dieses und reicht jeweils eine Marke an die Sequenzflüsse A1 und A2 weiter. Dadurch wird parallel das Steak gebraten und der Salat angerichtet. Der zusammenführende Gateway B wartet auf die Marken der beiden Sequenzflüsse B1 und B2, bevor er beide verschmilzt eine Marke weiterleitet. Der inklusive Gateway aktivieren: erlaubt, eine, mehrere oder alle ausgehenden Sequenzflüsse zu Abbildung 15: Verwendung eines inklusiven Gateways Der verzweigende Gateway A kann beliebig viele Sequenzflüsse aktivieren, muss aber mindestens einen wählen. Der zusammenführende Gateway B aktiviert seinen ausgehenden Sequenzfluss erst, wenn alle von A aktivierten Aktivitäten ausgeführt wurden. Daraus ergibt sich ein Problem, denn B muss wissen, wie viele Marken A weitergeleitet hat. Angenommen, das Modell wird wie folgt erweitert:

22 18 Richard Günther Abbildung 16: Problem bei Verwendung des inklusiven Gateways Beim Anrichten des Salats wird eine darin verborgene Spinne entdeckt, was den Hunger schlagartig verfliegen lässt. In diesem Falle müsste der Gateway B registrieren, dass eine Marke verschwunden ist. Zu prüfen, ob zwischendurch Marken aus dem Prozess ausgeschieden sind, ist für komplexe Prozesse sehr aufwändig. Im Rahmen einer automatischen Ausführung durch eine Process Engine ist das in machen Fällen sogar unmöglich, weshalb dieser Gateway mit Bedacht verwendet werden sollte. Der komplexe Gateway kommt zum Einsatz, wenn komplexe Sequenzflussregeln nicht aus einer umständlichen Kombination anderer Gateways, sondern mithilfe einer Regel beschrieben werden sollen: Abbildung 17: Verwendung eines komplexen Gateways Angenommen, der Hunger ist so groß, dass nach Fertigstellung von zwei Gerichten die Zubereitung des dritten abgebrochen und die Mahlzeit verzehrt werden soll. Gateway A aktiviert also zunächst alle drei Aktivitäten, aber Gateway B wartet nur auf zwei eingehende Marken, bis er das nachfolgende Ereignis aktiviert. Die dritte Marke wird konsumiert, ohne dass daraufhin etwas ausgelöst wird. Die zugrunde liegende Regel wurde in Abbildung 17 als Anmerkung abgebildet, wird jedoch im Hinblick auf eine automatische Ausführung in einem Attribut gespeichert.

23 Integration ereignisbasierter Middleware-Systeme in kontextbasierte Geschäftsprozesse 19 Ereignisse Nachdem vorgestellt wurde, dass Dinge getan werden (Aktivitäten), manchmal unter bestimmten Bedingungen (Gateways), sollen mit Ereignissen Dinge, die passieren, vorgestellt werden. In Abbildung 11: Modell eines einfachen Prozesses wurden bereits Start-, Zwischen- und Endereignisse verwendet. Grundlegend lassen sich Ereignisse nach eintretend und ausgelöst unterschieden. Eingetretene Ereignisse sind eher passiver Natur, da sie auf das Eintreten von Ereignissen warten. Beispielsweise wird ein Prozess nur dann gestartet, wenn das Startereignis durch ein (äußeres) Ereignis aktiviert wird. Die Symbole eingetretener Ereignisse, die stets darauf warten, etwas zu empfangen, sind unausgefüllt, wie beispielsweise das Symbol für Warten auf den Empfang einer Nachricht : Ausgelöste Ereignisse warten nicht auf den Eintritt eines Ereignisses, sondern werden durch den Prozess ausgelöst und verhalten sich dann wie eine Aktivität. Sie reagieren mit vordefinierten Aktionen und leiten danach sofort die Marke weiter. Der Vorteil gegenüber Aktivitäten ist, dass genau festgelegt ist, wann diese Aktivität erfolgt und nicht nur als zeitlich beliebig ausgeführtes Nebenprodukt einer übergeordneten, unbestimmten Aktivität [A09]. Beispielsweise wird ein Endereignis durch den Prozess ausgelöst, woraufhin der Prozess sofort beendet wird. Die Symbole ausgelöster Ereignisse, die bei Auslösung sofort etwas tun und dann weiterleiten, sind stets ausgefüllt, wie beispielsweise das Symbol für Versenden einer Nachricht : Als Nachrichten werden nicht nur Briefe, s oder Anrufe betrachtet, sondern prinzipiell alles, was an einen Empfänger adressiert ist und für diesen eine Information darstellt [FRH10, S. 54]. Startereignisse Startereignisse gehören zu den eintretenden Ereignissen, da sie lediglich etwas empfangen bzw. auf einen Auslöser reagieren können. Neben den unbestimmten Start-Ereignissen werden häufig zeitliche (beispielsweise um 12 Uhr eines Tages) und durch eine Nachricht ausgelöste Startereignisse (beispielsweise ein Auftragseingang) modelliert: Abbildung 18: Ein unbestimmtes sowie ein auf Zeitpunkt sowie auf eine Nachricht bezogene Startereignisse

24 20 Richard Günther Darüber hinaus gibt es noch folgende Startereignisse: Abbildung 19: Vier verschiedene Startereignisse Im Gegensatz zu einer Nachricht wird das rechts oben gezeigte Signal nicht direkt an einen Empfänger adressiert, sondern wie ein Broadcast 2 an die Allgemeinheit gesendet. Für den Start durch mehrfache oder parallele Ereignisse ist wiederum kein Ereignisformat definiert. Sie können als Anmerkung, logische Ausdrücke ( Ereignis 1 und Ereignis 2 ) oder Attribute abgebildet werden. Darüber hinaus existieren noch Startereignisse für Teilrpozesse. Sie reagieren auf bestimm- te Ereignisse, indem sie die Ausführung eines Teilprozesses auslösen. Für diese ereignisbe- handelnde Semantik werden unterbrechende und nicht-unterbrechende Startereignisse unterschieden. Folgende Abbildung 20 zeigt, dass sich nur die Ränder unterscheiden. Abbildung 20: Nicht-unterbrechendes Startereignise eines Teilprozesses Abbildung 21: Unterbrechendes Startereignise eines Teilprozesses Als Gegenstücke sind die Endereignisse zu sehen, die sich ebenfalls auf Haupt- oder Teil- prozesse beziehen. Endereignisse Endereignisse gehören zu den (vom Prozessfluss) ausgelösten Ereignissen. Generell wer- den Endereignisse mit einem dicken Rand dargestellt: 2 Mit Broadcast ist eine Nachricht gemeint, die im Rahmen eines Netzwerks alle Teilnehmer erreicht [RFC]

25 Integration ereignisbasierter Middleware-Systeme in kontextbasierte Geschäftsprozesse 21 Abbildung 22: Drei verschiedene Endereignisse Das End-Ereignis der mittleren Abbildung bedeutet, dass der Prozess beendet wird, jedoch noch eine Nachricht gesendet wird. Das rechts abgebildete End-Ereignis bedeutet, dass nicht nur die eingehende Marke konsumiert, sondern alle anderen, eventuell im Prozess befindlichen Marken entfernt werden. Das kann sinnvoll sein, wenn ein Prozess mehrere Endereignisse hat: Abbildung 23: Beispiel eines Prozesses mit zwei Endereignissen Wenn zuerst Aktivität 1 die Marke an Ende 1 leitet, ist der Prozess noch solange aktiv, bis auch die Marke von Aktivität 2 durch Ende 2 konsumiert wurde. Erreicht jedoch zuerst Ende 2 eine Marke, wird Aktivität 1 abgebrochen bzw. die dortige Marke entfernt, und so eine vollständige Terminierung des Prozesses erreicht. Das kann sinnvoll sein, um ein Festhängen des Modells durch Marken beispielsweise an parallelen Gateways, die keine zweite Marke mehr erhalten können, zu vermeiden [A09, S. 76]. Darüber hinaus stehen noch zwei weitere Endereignisse zur Verfügung: Abbildung 24: Endereignisse, die noch etwas auslösen Links wird bei Beendigung ein Signal an die Allgemeinheit gesendet. Es unterscheidet sich insofern von einer Nachricht, als dass nicht bekannt ist, wer das Signal empfängt und wer darauf reagiert. Rechts hingegen werden bei Erreichen alle aufgeführten Ereignisse ausgelöst, beispielsweise das Versenden von Nachrichten. Zwischenereignisse

26 22 Richard Günther Im Gegensatz zu Startereignissen, die nur eintretend und Endereignissen, die nur ausgelöst sein können, gibt es sowohl eintretende als auch ausgelöste Zwischenereignisse. Sie können im Prozess an beliebiger Stelle verwendet werden, wenn bei einem Prozessdurchlauf ein Ereignis, für das sich andere interessieren, ausgelöst wird - wie beispielsweise das Versenden einer Nachricht oder Auslösen eines Signals. auf Ereignisse reagiert wird wie z.b. auf das Eintreffen einer Nachricht oder Erreichen eines Zeitpunkts. Folgende Abbildung zeigt Beispiele für sendende (ausgelöste) und empfangende (eintretende) Zwischenereignisse: Abbildung 25: Sendende und empfangende Zwischenereignisse Zwischenereignis A sendet eine Nachricht, nachdem Aktivität 1 abgeschlossen wurde. Zwar könnte auch Aktivität 2 eine Nachricht senden, sodass ein Element weniger ausreichen würde aber so ist klar, dass die Nachricht genau nach Aktivität 1 und vor Aktivität 2, und nicht zu einem beliebigen Zeitpunkt während der Ausführung von Aktivität 2 gesendet wird. Darüber hinaus gibt es die in folgender Abbildung gezeigten Zwischenereignisse: Abbildung 26: Zeitliches, Bedingungs- und Signalbezogene Zwischenereignisse Zwischenereignis A beschreibt eine zeitliche Bedingung, auf die gewartet wird. Damit wird typischerweise nicht ein Zeitpunkt, sondern eine Zeitspanne beschrieben. Für Bedingungen allgemeiner Art eignet sich das Ereignis B. Die Zwischenereignisse C und D beschreiben das Senden und Empfangen von Signalen. Ereignis C gehört zu den ausgelösten Ereignissen und sendet ein Signal, um dann sofort zur nachfolgenden Aktivität weiterzuleiten, sodass es sich eigentlich um eine Aktivität handelt. Hier ist allerdings der genaue Sendezeitpunkt klar. Ereignis D gehört hingegen zu den eintretenden Ereignissen und reagiert daher erst, wenn ein Signal empfangen wurde. Entsprechend gibt es auch für mehrfache Ereignisse eine eintretende und ausgelöste Variante:

27 Integration ereignisbasierter Middleware-Systeme in kontextbasierte Geschäftsprozesse 23 Abbildung 27: Drei verschiedene Mehrfach-Zwischenereignisse Das Mehrfach-Zwischenereignis A wartet (da empfangend), bis eines der beschriebenen Ereignisse eintritt, während Ereignis B die beschriebenen Ereignisse auslöst und dann sofort zur nächsten Aktivität weiterleitet. Das Zwischenereignis C wartet, bis alle beschriebenen Bedingungen eingetreten sind, bevor es die Marke weiterleitet. Im vorherigen Abschnitt wurde das exklusive Gateway vorgestellt. Abhängig von den Bedingungen, die als Daten der Art schmeckt oder schmeckt nicht modelliert werden, erfolgt die Aktivierung einer der ausgehenden Sequenzflüsse. Das in Abbildung 28 vorgestellte Mehrfach-Zwischenereignis lässt sich auch als ereignisbasiertes, exklusives Gateway verwenden, das die Wahl eines ausgehenden Sequenzflusses in Abhängigkeit von Ereignissen vornimmt. Dementsprechend lässt sich der in Abbildung 13 durch einen datenbasierten, exklusiven Gateway Zusammenhang auch wie folgt Ereignisbasiert modellieren: Abbildung 28: Verwendung eines ereignisbasierten exklusiven Gateways Den wesentlichen Unterschied zum datenbasierten, exklusiven Gateway aus Abbildung 13 stellt die Modellierung der Bedingungen für die Wahl eines Sequenzflusses dar. Hier erfolgt sie über eintretende, also wartende, Bedingungen. Natürlich können auch sämtliche anderen eintretenden Zwischenereignisse wie Zeit, Signal, Nachricht oder mehrfaches Ereignis verwendet werden.

28 24 Richard Günther Angeheftete Ereignisse, hier am Beispiel eintretender Nachrichtenereignisse, können während einer laufenden Aktivität eintreten. Es gibt unterbrechende und nicht-unterbrechende angeheftete Elemente: Abbildung 29: Beispiel für ein unterbrechendes Zwischenereignis Die Marke gelangt im Rahmen eines Prozesslaufs zur Aktivität 1. In der linken Abbildung wird die Ausführung von Aktivität 1 sofort unterbrochen, wenn eine Nachricht eintrifft, und die Marke zu Aktivität 3 geleitet. In der rechten Abbildung dagegen wird, wenn die Nachricht während der Ausführung von Aktivität 1 eintrifft, eine neue Marke erzeugt und an Aktivität 3 geleitet. Parallel wird jedoch Aktivität 1 ausgeführt. Kollaborationen Mit Vorstellung von Aktivitäten, Gateways und Ereignisse wurden die grundlegenden Elemente innerhalb eines Prozesses vorgestellt. Interaktionen zwischen Prozessen lassen sich durch Pools (vgl. Abbildung 10: BPMN-Kernelemente) modellieren: Abbildung 30: In Kollaborationsdiagrammen wird mithilfe von Pools die Interaktion zwischen Prozessen modelliert

29 Integration ereignisbasierter Middleware-Systeme in kontextbasierte Geschäftsprozesse 25 Für Tante und Enkel wurden separate Pools verwendet, da sie unabhängig voneinander sind. Der Enkel hat keinen Einfluss auf das zusammengestellte Geschenk, und die Tante kann nicht beeinflussen, was der Enkel auf die Karte schreibt. Jeder Pool kann als Prozessverantwortlicher gesehen werden, der dort die volle Kontrolle hat allerdings nur dort, sodass ein Pool auch die Prozessgrenzen aufzeigt. Es gibt folglich keine übergeordnete Instanz, die den Gesamtablauf beider Pools koordiniert. Diese Abgrenzung ist für das automatische Ausführen von Prozessen sehr wichtig, denn dort muss die Process Engine jeden Pool ausführen und mit den anderen koordinieren [FRH10, S. 97]. Ein Pool kann in Bahnen (Lanes) unterteilt werden. Diese Unterteilung hat einen eher informativen Charakter, denn so lassen sich beispielsweise innerhalb eines Prozesses verschiedene Abteilungen, Rollen oder Anwendungssysteme abgrenzen. Beispielsweise könnte Abbildung 30 um den Onkel erweitert werden, sodass der Pool nun Großeltern heißt und Tante sowie Onkel beinhaltet: Abbildung 31: Kollaborationsdiagramm mit Pools und Bahnen In ihrer Einheit treten sie als Großeltern auf, intern sind jedoch sowohl Oma als auch Opa beteiligt. Wichtig ist, dass Nachrichtenflüsse nicht innerhalb Pools auftreten dürfen, da Nachrichten innerhalb eines Prozesses mit Sequenzflüssen dargestellt werden. Umgekehrt können Sequenzflüsse keine Prozessgrenzen überschreiten. Artefakte Da Artefakte keinen Einfluss auf die Ablaufsemantik des Prozessmodells haben, werden sie lediglich über Assoziationen (vgl. Abbildung 11: Modell eines einfachen Prozesses) eingebunden. Anmerkungen können völlig frei platziert werden und Hinweise oder Ergänzungen enthalten. Bei der Vorstellung von Gateways wurde erwähnt, dass bei der Entwicklung von BPMN davon ausgegangen wurde, dass alle Daten innerhalb eines Prozesses bzw. eines Pools beliebig abrufbar seien. Darum werden beispielsweise Bedingungen einfach als logische

30 26 Richard Günther Ausdrücke an den Sequenzflüssen dargestellt (vgl. Abbildung 13). Das kann zwar von einer Process Engine umgesetzt werden, aber in manchen Prozessen gibt es keinen gemeinsamen Datenpool. Und auch wenn es einen gibt, lassen sich datenbezogene Abhängigkeiten besser erkennen, wenn die Nutzung von Input- und Outputdaten explizit modelliert wird. Hierfür stehen Datenobjekte zur Verfügung, die allgemein Daten und Informationen in beliebiger Form abbilden. Neben ihrer Bezeichnung können sie noch in eckigen Klammern einen Status haben, wie z.b. [geprüft] oder [zu überarbeiten]. Sie geben an, von welcher Aktivität ein Datenobjekt ausgeht und von welcher es verwendet wird. Außerdem können sie mit kleinen Symbolen als Listen oder Input- / Output-Daten ausgezeichnet werden. Folgende Abbildung veranschaulicht die drei zur Verfügung stehenden Datenobjekte: Abbildung 32: Verwendung von Datenobjekten Das Datenobjekt A wird durch die drei Striche als Mehrfach-Datenobjekt ausgezeichnet. Dieser eignet sich, wenn nicht nur einzelne, sondern mehrere Datenobjekte, beispielsweise eine Liste, abgebildet werden sollen. Das Objekt B entspricht einem klassischen, einzelnen Datenobjekt, was von einer zur nächsten Aktivität gereicht wird. Wenn ein indirekter Datenaustausch erfolgen soll, beispielsweise indem ein Prozess in einen Datenspeicher schreibt und ein anderer daraus liest, wird das Datenspeicher-Objekt C verwendet. Nachdem grundlegende Modellierungsartefakte der BPMN 2.0 anhand einiger Beispiele vorgestellt wurden, werden im nachfolgenden Abschnitt ereignisbasierte Architekturen vorgestellt und in Abgrenzung zu service-orientierten Architekturen charakterisiert. 2.3 Ereignisbasierte Architekturen In diesem Kapitel werden ereignisbasierte Systeme und ihre Bedeutung für immer kürzere Reaktionszyklen von Unternehmen vorgestellt. In Abgrenzung zu serviceorientierten Architekturen (SOA, [M10]) werden anhand des Ereignisbegriffs typische Charakteristika vorgestellt sowie Aufbau und Funktionsweise ereignisbasierter Systeme erläutert. Da letztere auf Geschäftsprozessebene zu integrieren sind, werden außerdem typische Interaktionsmöglichkeiten vorgestellt.

31 Integration ereignisbasierter Middleware-Systeme in kontextbasierte Geschäftsprozesse Charakteristika einer ereignisbasierten Architektur Die Konzepte der serviceorientierten Architektur (SOA, [M10]) sowie der ereignisbasierten Architektur (EOA, [BD10]) stellen komplementäre Architekturstile dar, die sowohl eigenständig als auch in Kombination eingesetzt werden können. Auf Grundlage des Ereignis- Begriffs wird zunächst eine SOA skizziert und anschließend auf wesentliche Charakteristika einer EOA eingegangen. Im Anschluss werden Anwendungsbereiche für den Einsatz einer EOA vorgestellt. Zunächst werden die grundlegenden Begriffe vorgestellt. Ein Ereignis kann alles sein, was passiert oder von dem erwartet wird, dass es passiert und bezieht sich im Allgemeinen auf die Zustandsänderung eines Objekts. [Luc01] Ereignisse können unterschiedlich abstrakt sein beispielsweise stellt ein technisches Ereignis die von einem Sensor gemessene Temperaturänderung und ein fachliches Ereignis die Kündigung eines Vertrags dar [BD10]. Letzteres besteht in der Regel aus mehreren einfachen Ereignissen, für die Muster definiert werden können. Als Ereignismuster wird eine Menge von Ereignissen mit ihren Abhängigkeiten und dem jeweiligen Kontext bezeichnet. [Luc01] SOA ist ein Paradigma für die Strukturierung und Nutzung verteilter Funktionalität, die von unterschiedlichen Besitzern verantwortet wird [LME06]. Dabei werden IT- Komponenten zu Diensten (engl. Services) gekapselt, sodass ihre Leistungen zu höheren Diensten zusammengefasst angeboten werden können, was sich insbesondere für die Durchführung von Geschäftsprozessen eignet [LSL+08]. Eine ereignisgesteuerte Architektur hingegen setzt sich aus ereignisgesteuerten Komponenten zusammen und interagiert durch den Austausch von Ereignissen. Zentrales Konzept bei der Interaktion einer Unternehmensarchitektur ist die Verarbeitung von Ereignissen, um auf Ebene der Datenintegration Ereignisse aus einem oder mehreren Ereignisströmen zu Informationen zu verdichten [Luc01, BD10, LSL+08]. Durch die Fokussierung auf Services, die über ein Netzwerk verteilt sind, übertragt eine SOA die softwaretechnischen Prinzipien der Kapselung und losen Kopplung auf die unternehmensweite Anwendungsarchitektur. Durch die Kapselung von Fachlichkeit und Implementierung stellt die IT-Infrastruktur eines Unternehmens keine Menge von Applikationen, sondern eine Menge verfügbarer Services dar. Dementsprechend wird die fachliche Abfolge von Aktivitäten, durch einen Geschäftsprozess als linearer Ablauf beschrieben, durch die Orchestrierung von Services umgesetzt. Folgende Abbildung 33 verdeutlicht die Umsetzung von Geschäftsprozessen durch Services im Rahmen einer SOA:

32 28 Richard Günther Abbildung 33: Umsetzung von Geschäftsprozessen mittels Services im Rahmen einer SOA [DEF+08] Die Kommunikation zwischen Client (fragt einen Service nach) und Server (bietet einen Service an) erfolgt nach dem synchronen Request/Reply-Muster, sodass der Client blockiert wird, wenn der Server nicht antwortet [G06]. Zum Zeitpunkt eines Service-Aufrufs müssen technische Details wie Name, Adresse oder Übertragungsprotokoll des Services bekannt sein, woraus sich eine vergleichsweise enge Kopplung ergibt. Eine SOA eignet sich für ablauforientierte Prozesse mit synchronem Interaktionsmuster und damit für die Umsetzung klassischer Geschäftsprozesse. Folgende Abbildung 34 eines Geschäftsprozesses veranschaulicht die Bedeutung von fachlichen Ereignissen im Rahmen einer SOA: Abbildung 34: Einfacher Bestellprozess [Luc01] Dieser Prozess wird ausgeführt, sobald das Ereignis einer Kundenbestellung auftritt. Das Unternehmen wählt den günstigsten Lieferanten aus, fordert diesen auf, das Produkt direkt an den Kunden zu senden und schreibt anschließend eine Rechnung. Für eine automatische Ausführung werden Prozessregeln definiert, die auf Grundlage von Ereignissen nachfolgende Prozessschritte ausführen. Regeln der Form WENN <Ereignismuster X liegt vor> DANN <Ereignis Y emittieren>

33 Integration ereignisbasierter Middleware-Systeme in kontextbasierte Geschäftsprozesse 29 prüfen, ob eingehende Ereignisse dem Muster X entsprechen. Ist das der Fall, wird ein neues Ereignis Y emittiert und so der nächste Prozessschritt eingeleitet. Folgende Abbildung 35 stellt den Sachverhalt dar: Abbildung 35: Bestellprozess mit zugehörigen Ereignissen und Prozessregeln nach [Luc01] Beispielsweise sorgt das Auftreten des Ereignisses eine gültige Bestellung liegt vor für die Ausführung des nachfolgenden Prozessschritts Lieferanten auswählen. Im Rahmen einer SOA werden fachliche Ereignisse zum Anstoßen von Prozessschritten sowie zum Anzeigen des Prozessfortschritts verwendet. Abschließend lässt sich festhalten, dass der Schwerpunkt einer SOA auf der Ausführung vordefinierter, klar strukturierter Prozesse liegt. Geht es aber um das Extrahieren übergreifender, fachlicher Zusammenhänge aus Ereignissen oder das flexible Reagieren auf geänderte Zustände beteiligter Objekte, erweist sich eine SOA als zu statisch und unflexibel [DEF+08]. Firmen wie Google oder Dell sind einer Gartner-Studie zufolge so erfolgreich, weil sie Marktereignisse früh erkennen und flexibel darauf reagieren. Mit dem Ausspruch the world is mostly event-driven [S03] weist Gartner darauf hin, dass Unternehmen ständig auf Ereignisse von Kunden, Lieferanten, Konkurrenten oder dem Umfeld reagieren müssen. Tun sie das nahezu in Echtzeit, kommen sie damit dem von Gartner geprägten Begriff des Real Time Enterprise (RTE[A02]), eines Idealunternehmens mit hoch automatisierten Geschäftsprozessen und kleinsten Prozesslaufzeiten, sehr nahe [NM03]. Diesem Leitbild folgend geht es um die Verarbeitung von beobachtbaren Zustandsänderungen der Geschäftsprozesse. Diese Änderungen, von einer EOA als Ereignisse modelliert, müssen in operative Geschäftsprozesse integriert werden. Ein einzelnes Ereignis, wie beispielsweise in Abbildung 35 gezeigt, besitzt jedoch keine besonders hohe Aussagekraft. Beispielsweise lassen sich aus der Information, dass ein Auto gerade den Sensor eines Verkehrsleitsystems passiert hat, keine Erkenntnisse über den

34 30 Richard Günther aktuellen Verkehrszustand gewinnen. Nur wenn zwischen mehreren Ereignissen dieser Art ein Zusammenhang hergestellt wird, sie z.b. räumlich gruppiert werden, lässt sich die Verkehrslage qualitativ beurteilen. Ereignisse gewinnen folglich erst im Kontext anderer Ereignisse an Bedeutung, sodass Zusammenhänge und Beziehungen zwischen Ereignissen, als Ereignismuster spezifiziert, identifiziert werden müssen. Anschließend muss, im Sinne einer flexibel reagierenden Architektur, eine Aktion ausgelöst werden. Analog zur Struktur der WENN-DANN-Prozessregeln sind folgende Aufgaben zu bewältigen [BD10]: WENN: Komplexe Muster zwischen Ereignissen erkennen Dem Erkennen von Zusammenhängen, Abhängigkeiten und Korrelationen zwischen Ereignissen kommt eine besondere Bedeutung zu. Im Gegensatz zu einzelnen Ereignissen haben solche, die zueinander in Beziehung gesetzt werden, eine deutlich höhere Aussagekraft. In der Ereignis-Wolke müssen Ereignismuster identifiziert werden. Dabei sind folgende Zusammenhänge zu berücksichtigen [Luc01, BD10, DEF+08]: o Temporal (z.b. A ereignet sich vor B) o Kausal (z.b. A verursacht B, also ist A Bedingung für B) o fachliche Korrelationen (nur mit Kontextwissen möglich, z.b. alle Transaktionen einer Kreditkarte). DANN: Aktionen initiieren Wird ein Muster erkannt, soll darauf eine fachliche Reaktion erfolgen, etwa indem eine Nachricht versendet oder ein Service aufgerufen wird. Der letzte Punkt, der Service-Aufruf als Reaktion auf ein identifiziertes Ereignismuster, weist auf das Potential einer Kombination aus SOA und EOA hin. Statt Services mittels Prozessbeschreibungen zu Geschäftsprozessen zu orchestrieren, werden Muster in Ereignisströmen gesucht, um daraufhin Services anzustoßen. Eine SOA kann durch EOA intelligenter und reaktionsschneller werden. Diese Kombination wird als event-driven SOA oder advanced SOA bezeichnet [T06, NS06]. Basierend auf der Vorstellung des Ereignisbegriffs im Kontext einer EOA kann ihr Einsatz für die nachfolgenden Anforderungen als besonders sinnvoll identifiziert werden [BD10]: Komplexe Fachlogik Für komplexe Aggregationen, Korrelationen von historischen Daten oder das Erkennen komplexer Ereignismuster Große Datenvolumina Verarbeitung von bis zu mehreren Millionen Daten pro Sekunde Niedrige Latenz Zeitnahe Reaktion auf Ereignisse Agilität Einfache Änder- und Wartbarkeit von Komponenten der Unternehmenanwendungen aufgrund einer hohen fachlichen Agilität Nachfolgende Anwendungsbereiche basieren auf einer oder mehreren der genannten Anforderungen und profitieren folglich vom Einsatz einer EOA.

35 Integration ereignisbasierter Middleware-Systeme in kontextbasierte Geschäftsprozesse 31 Monitoring. Um betriebliche Systeme kontrollieren und überwachen zu können, müssen aufgrund der Abstraktion geeigneter Indikatoren oder Prozesskennzahlen komplexe Korrelationen zwischen großen Mengen von Daten möglichst zeitnah verarbeitet werden. Speziell beim Business Activity Monitoring (BAM, [E10]), wo geschäftsrelevante Informationen der operativen Entscheidungsunterstützung dienen, müssen die Informationen auf unterschiedlichen Abstraktionsebenen präsentiert werden. Darüber hinaus werden mit Drilldown-Abfragen kausale Zusammenhänge zwischen Ereignissen aufgezeigt, beispielsweise um Gegenmaßnahmen einleiten zu können. Auch im Bereich der Überwachung von Service Level Agreements (SLAs, [B07]), von Rechnernetzen, des Luftverkehrs sowie von Energienetzen eignet sich der Einsatz einer EOA. Sensornetzwerke. Sensoren verbinden die physische Welt mit der Informationsverarbeitung, indem sie Messdaten zu Ereignissen digitalisieren. Aufgrund der fallenden Kosten und wachsenden technischen Fähigkeiten werden Sensoren immer häufiger vernetzt, sodass die resultierenden Sensornetzwerke [MCA06] die Vision des Internet of Things, der ins Internet integrierten Alltagsgegenstände, in greifbare Nähe rücken [FM05]. Charakteristisch ist die kontinuierliche Erzeugung großer Datenmengen auf einem niedrigen Abstraktionsniveau. Diese muss zeitnah hinsichtlich relevanter Ereignismuster untersucht werden, um fachlich aussagekräftige Ereignisse zu erhalten. Die Verarbeitung von Ereignissen ermöglicht eine Verbindung der physikalischen Welt mit der IT-Infrastruktur. Enterprise Application Integration. Geschäftsprozesse beschreiben meistens abteilungs-, orts-, oder unternehmensübergreifende Abläufe. Dementsprechend ist im Rahmen einer Prozessausführung das Zusammenspiel mehrerer, meist heterogener Systeme notwendig, was eine hohe Agilität voraussetzt. Enterprise Application Integration (EAI, [K02]) kombiniert etablierte Schnittstellentechnologien mit einer nachrichtenorientierten Middleware, die das asynchrone Austauschen von Nachrichten erlaubt, und bietet so eine technische Infrastruktur für die gemeinsame Nutzung verteilter Daten. Der Austausch von Ereignissen über Systemgrenzen hinweg erfordert die Transformation, inhaltliche Anreicherung durch Kontextinformationen oder Erzeugen komplexer Ereignisse, wie sie beispielsweise von einer EOA angeboten wird. Im Verlauf dieses Abschnitts wurden der Ereignisbegriff zunächst im Kontext einer SOA und dann einer EOA betrachtet. Darauf aufbauend wurden verschiedene Anwendungsbereiche, die vom Einsatz einer EOA profitieren, vorgestellt. Nachdem auf diese Weise eine Vorstellung von dem einer EOA zugrundeliegenden Paradigma kultiviert wurde, soll im nächsten Abschnitt ihr typischer Aufbau vorgestellt werden.

36 32 Richard Günther Aufbau einer ereignisbasierten Architektur Im vorherigen Abschnitt wurden, analog zur Struktur der WENN-DANN-Regeln, das Erkennen von Mustern sowie die nachfolgende Reaktion als Aufgaben einer EOA genannt. Daraus ergeben sich folgende drei grundlegende Verarbeitungsschritte: 1. Erkennen. Ereignisse werden, beispielsweise durch Sensoren, unmittelbar erfasst. Generell wird von Ereignisquellen gesprochen. 2. Verarbeiten Der Strom eingehender Ereignisse wird hinsichtlich der Muster, die Beziehungen zwischen Ereignissen ausdrücken, analysiert. Darauf aufbauend können, sofern gewünscht, neue Ereignisse mit höherer fachlicher Aussagekraft erzeugt werden. 3. Behandeln Aufgrund der erkannten Muster werden Reaktionen, wie beispielsweise das Senden einer Nachricht oder Aufrufen eines Services, ausgelöst. Analog zu den drei Schritten lässt sich das allgemeine Verarbeitungsmodell einer ereignisbasierten Architektur in folgender Abbildung 36 darstellen: Abbildung 36: Verarbeitungsmodell einer ereignisbasierten Architektur nach [BD10, DEF+08, M06] Bei der Ereigniserkennung werden Ereignisse beispielsweise durch Sensoren erfasst und in Form von Ereignisobjekten an die Ereignisverarbeitung gesendet. Die Ereignisverarbeitung arbeitet auf Ereignisströmen, die von Ereignisobjekten unterschiedlicher Herkunft gespeist werden. Die Analyse und Verarbeitung des Ereignisstroms erfolgt mit Techniken des Complex Event Processing (CEP) [Luc01]. Mittels CEP wird der Ereignisstrom zeitnah nach Ereignismustern durchsucht, um den fachlichen Informationswert zu extrahieren. Werden stattdessen Ausschnitte von kontinuierlichen Ereignisströmen nach Ereignismustern durchsucht, spricht man vom Event Stream Processing (ESP, [Luc01]). Die CEP ist als Netzwerk aus leichtgewichtigen Event Processing Agents (EPAs) zu sehen,

37 Integration ereignisbasierter Middleware-Systeme in kontextbasierte Geschäftsprozesse 33 die im Sinne einer Aufgabenteilung zusammenarbeiten, und so eine erhöhte Verständlichkeit und verbesserte Wartbarkeit ermöglichen. Folgende Verarbeitungen kann ein EPA ausführen [DEF08]: Filtern von Ereignissen Die Menge eingehender Ereignisse wird hinsichtlich Typ (z.b. Ereignis vom Typ Auftragseingang ) oder Inhalt (z.b. Wert > ) gefiltert. Sortieren von Ereignissen Abhängig vom Inhalt eines Ereignisses werden sie in bestimmte Warteschlangen einsortiert. Aggregieren Bestimmte Inhalte von einfachen Ereignissen werden in aggregierten Ereignissen zusammengefasst. Transformation eines Ereignisses Hierzu gehören die Übersetzung in ein anderes Format oder das Anreichern des Ereignisinhalts durch weitere Kontextdaten. Erzeugung komplexer Ereignisse Anders als bei aggregierten Ereignissen erfolgt nicht nur eine Zusammenfassung der einfachen Ereignisse, sondern durch das Ziehen von Rückschlüssen mithilfe intelligenter Regeln wird eine höhere fachliche Bedeutung erreicht. Das Netzwerk von EPAs als Abfolge einzelner Verarbeitungsschritte kann graphisch durch ein Event Processing Network (EPN, [Luc01]) in folgender Abbildung 37 dargestellt werden: Abbildung 37: In einem Event Processing Network wird beschrieben, wie Event Processing Agents zusammenarbeiten Folgende Abbildung 38 zeigt den internen Aufbau des in Abbildung 36 gezeigten EPA eines Event Processing Networks:

38 34 Richard Günther Abbildung 38: Aufbau eines Event Processing Agents (EPA) nach [kap3] Im Ereignismodell werden die möglichen Ereignistypen, also die Eigenschaften, Beziehungen und Abhängigkeiten von Ereignissen verschiedener Abstraktionsebenen spezifiziert. Im Sinn einer losen Kopplung muss jedes Ereignis alle verarbeitungsrelevanten Daten beinhalten. Dazu gehören sowohl Metadaten wie Typ, Quelle und Auftrittszeitpunkt eines Ereignisses als auch die eigentlichen Nutzdaten [DEF08]. Ereignisregeln definieren Aktionen, die auszuführen sind, wenn ein Muster erkannt wurde. Jede Regel besteht aus einem oder mehreren Mustern und einer Aktion, die ausgeführt wird, wenn das Muster erkannt wird. Ereignismuster und regeln werden üblicherweise in einer Event Pattern Language (EPL) ausgedrückt [SC07, MFP06]. Bislang existiert jedoch kein Standard zur formalen Beschreibung von Ereignissen. Derartige Beschreibungen werden durch eine Engine, wie beispielsweise die verbreitete Open-Source-Engine Esper [Esper], ausgeführt. Aufgabe der Event Processing Engine ist der Abgleich des Ereignisstroms mit Mustern der Ereignisregeln und, sobald ein Muster gefunden wurde, das Ausführen der korrespondieren Aktion. Um auch vergangene Ereignisse prüfen zu können werden Ereignisse eines vorgegebenen Zeit- oder Längenfensters betrachtet (in der Abbildung 38 durch die Breite der Event Processing Engine skizziert). Wurde ein Muster identifiziert, erfolgt im Rahmen der Ereignisbehandlung z.b. ein Service-Aufruf oder die Benachrichtigung bestimmter Komponenten. Nachdem der Aufbau einer ereignisbasierten Architektur vorgestellt wurde, soll die Kommunikation zwischen den drei Architekturkomponenten für das Erkennen, Verarbeiten und Behandeln von Ereignissen im nachfolgenden Abschnitt erläutert werden.

39 Integration ereignisbasierter Middleware-Systeme in kontextbasierte Geschäftsprozesse Kommunikationen einer ereignisbasierten Architektur Im Zuge der Betrachtung von Kommunikationsaspekten ist es sinnvoll, von der im vorherigen Abschnitt eingenommenen verarbeitungs- zu einer rollenbasierten Sichtweise zu wechseln. Die drei Verarbeitungsschritte einer EOA (s. Unterkap2) Erkennen, Verarbeiten und Behandeln waren Ausgangspunkt für die verarbeitungsbezogene Betrachtung einer typischen EOA. Eine rollenbasierte Sichtweise, basierend auf dem Client-Server-Modell der Softwarearchitektur [TS08, RH08] weist der Ereigniserkennung die Rolle des Produzenten zu. Analog erfolgt die Reaktion auf ein Ereignis durch den Konsumenten eines Ereignisses, sodass sich folgendes abstraktes Kommunikationsschema ergibt: Abbildung 39: Abstraktes, rollenbasiertes Kommunikationsschema Anhand dieses Schemas lassen sich nun grundlegende Kommunikations- und Interaktionsmechanismen einer EOA vorstellen. Synchrone Interaktion [BHS07] Der Sender einer Nachricht oder eines Aufrufs wartet, bis eine Antwort erfolgt. Bis die Antwort ankommt, ist der Sender folglich blockiert. Typisches Beispiel ist die Request/Reply-Interaktion des HTTP-Protokolls. Asynchrone Interaktion [BHS07] Im Gegensatz zur synchronen Interaktion wartet der Sender einer Nachricht oder eines Aufrufs nicht auf die Antwort. Dieses nicht-blockierende Verhalten impliziert allerdings, dass die jederzeit eintreffenden Antworten verarbeitet werden können. Alternativ bietet sich die Verwendung einer nachrichtenorientierten Middleware an, weil dort Nachrichten zwischengespeichert und, analog zu einem - Postfach, vom Empfänger abgeholt werden können. EOA verwenden häufig eine asynchrone Kommunikation. Beispielsweise senden Produzenten ihre Ereignisdaten meistens als one-shots [SS07] an die Ereignisverarbeitung, sodass sie weder warten, bis der Empfänger die Verarbeitung abgeschlossen hat, noch eine Antwort erwarten. Push-Modus Den Zeitpunkt der Interaktion bestimmt der Sender. Beispielsweise bestimmt der Produzent, wann er seine Ereignisnachricht an die Middleware sendet. Pull-Modus / Polling Im Gegensatz zum Push-Modus bestimmt der Empfänger den Zeitpunkt der Interaktion, indem er beim Sender nachfragt. Nachrichtenbasierte Middleware Eine nachrichtenorientierte Middleware [SS07] dient als Mediator und ermöglicht eine indirekte Kommunikation, sodass sich Sender und Empfänger nicht gegenseitig kennen müssen. Im Zuge einer asynchronen Interaktion wird eine Nachricht an die Middleware gesendet und von dieser entweder an den Empfänger weitergeleitet oder zur Abholung bereitgehalten. Dazu verwaltet sie verschiedene Warte-

40 36 Richard Günther schlangen für die Nachrichten, sodass sich eine Analogie zum -Postfach besteht. Einzelne Ereignisabfragen (engl. One-Shot-Queries) Analog zu Datenbanksystemen werden einzelne Ereignisabfragen einmalig auf die aktuell im System bekannten Ereignisse angewendet, um daraus eine Antwort zu erzeugen [GRL+08]. Kontinuierliche Ereignisabfrage (engl. Subscriptions) Im Gegensatz zu einzelnen werden kontinuierliche Ereignisabfragen dauerhaft im System registriert (engl. Subscriptions). Statt sie einmalig auf eine Datenbasis anzuwenden, werden alle eingehenden Ereignisse hinsichtlich dieses Filters geprüft [GRL+08]. Publish/Subscribe-Interaktion Unter Verwendung einer nachrichtenorientierten Middleware wird der Nachrichtenaustausch einer EOA im Publish/Subscribe-Modus [XEP] realisiert. Der Produzent veröffentlicht (engl. published) seine Ereignisse in Form von Nachrichten an die Middleware. Dort haben sich im Vorfelde ein oder mehrere Konsumenten mit einer kontinuierlichen Ereignisabfrage registriert (engl. subscribe) und somit Ereignisbenachrichtigungen der Middleware abonniert. Bei Eintreffen einer neuen Ereignisnachricht werden alle interessierten Konsumenten im push-modus benachrichtigt und können die Ereignisnachricht von der Middleware im pull-modus abrufen. Die Benachrichtigung kann die relevanten, neuen Daten jedoch auch schon beinhalten, sodass der Konsument nicht mehr zur Middleware verbinden müsste. Die Verwendung der Publish/Subscribe-Kommunikation führt zu einem nebenläufigen Verarbeitungsmodell und damit zu einer losen Kopplung. Zusammen mit einer asynchronen Interaktion bildet sie die Grundlage für die erfolgreiche Integration heterogener Systeme im Rahmen der Enterprise Application Integration (vgl. Unterkap2). Das letztgenannte Publish/Subscribe-Vorgehen lässt sich anhand folgender Abbildung 40 veranschaulichen: Abbildung 40: Schritte eines Publish/Subscribe-Vorgehens Im ersten Schritt registriert sich der Konsument für Ereignisse eines bestimmten Typs. Dann publiziert der Konsument im push-modus seine Nachricht an die Middleware. Die Middleware benachrichtigt daraufhin den Konsumenten über die neue Ereignisnachricht, woraufhin dieser zur Middleware verbindet und die Nachricht abruft. In Analogie Im Gegensatz zu den Abonnements (engl. Subscriptions), die als kontinuierliche Ereignisabfragen registriert werden, lassen sich sog. One-shot-Abfragen abgrenzen. Sie werden einmalig übermittelt, und nach der Antwort

41 Integration ereignisbasierter Middleware-Systeme in kontextbasierte Geschäftsprozesse 37 Nachdem die rollenbasierte Kommunikation vorgestellt wurde, lässt sich das Verarbeitungsmodell einer EOA wie folgt um die grau markierten Komponenten zur Umsetzung der Kommunikation erweitern: Abbildung 41: Kommunikationskomponenten einer Ereignisbasierten Architektur (EOA) Nachfolgend werden die gezeigten, im Rahmen der Interaktion notwendigen Komponenten vorgestellt. Ereigniskanal Sowohl die Integration der Ereignisquellen in die Ereignisverarbeitung als auch die Integration der Ereignisverarbeitung in die operativen Systeme geschieht mittels Ereigniskanälen. Diese können unterschiedlich implementiert sein, beispielsweise mittels Remote Method Invocation (RMI, [RMI]) oder CORBA [OMG] für den Aufruf entfernter Services, Web Services [WS] für eine HTTP-basierte Kommunikation oder durch eine nachrichtenorientierte Middleware. Letztere wird bevorzugt verwendet, da sich der asynchrone Nachrichtenaustausch als einfache und geeignete Lösung für die Kommunikation heterogener Komponenten erwiesen hat. Adapter und Schnittstellen Generelles Ziel ist es, den Zugriff auf einzelne Komponenten von deren Implementierung zu kapseln, um wechselseitige Implementierungsabhängigkeiten zu vermeiden. Dabei kommen folgende Komponenten zum Einsatz [BD10, C93]: In-Adapter Häufig sind Komponenten der Ereigniserkennung wie beispielsweise Sensoren nicht in der Lage, ihre Daten im passenden Format an die Ereignisverarbeitung zu senden. In-Adapter wandeln die proprietären Ereignisdaten in das interne Datenformat der Ereignisverarbeitung um. Auf diese Art

42 38 Richard Günther und Weise lassen sich beliebige, heterogene Komponenten durch das Erstellen eines passenden In-Adapters integrieren. Out-Adapter Dienen der Transformation von Ereignissen des internen Verarbeitungsformats in eine serialisierte Nachricht und senden es an den Ereigniskanal. Fassade Auch operative Anwendungssysteme können Ereignisse erzeugen, die von der Ereignisverarbeitung berücksichtigt werden sollen. Dazu erzeugen sie Ereignisse und senden sie an die Middleware, wo sie in speziele eine Warteschlange einsortiert werden. Die Ereignisverarbeitung kann sie sich von dort abholen und intern weiter verarbeiten. Schnittstellen Operative Anwendungssysteme verwenden Schnittstellen, um dem Ereigniskanal Nachrichten zu entnehmen und in Objekte des Zielsystems, beispielsweise C++-Objekte, umzuwandeln und die entsprechenden Methoden aufzurufen. Analog zu Ereignisquellen lassen sich auch operative Anwendungssysteme durch Definition einer geeigneten Schnittstelle integrieren. Ereignisbasierte Architekturen wurden hinsichtlich Charakteristika, Aufbau und Funktionsweise vorgestellt. Sie eignen sich für verschiedene Anwendungsbereiche, in denen große Mengen von Ereignissen verarbeitet und entsprechende Aktionen ausgelöst werden. Im Hinblick auf die Erfordernisse der Wirtschaft, immer schneller und mit hoher Flexibilität auf auf Ereignisse im Unternehmensumfeld reagieren zu können, werden nachfolgend Sensordatenverarbeitende Systeme als Untersuchungsgegenstand festgelegt. Im Hinblick auf die Interaktionsmöglichkeiten wurden die Rollen der Produzenten (veröffentlichen Ereignisse, z.b. Sensoren) und Konsumenten (empfangen spezifische Ereignisse, z.b. Benachrichtigungssysteme) identifiziert. Im nachfolgenden Abschnitt werden ausgehend von diesen beiden Rollen die Architekturen verschiedener Sensordatenverarbeitender Systeme skizziert. 2.4 Sensordaten-Middleware-Systeme Technisch gesehen stellt ein Sensor, indem er physische Parameter in digitale Signale umwandelt, die Schnittstelle zwischen physischer und digitaler Welt dar. Aufgrund der sinkenden Preise und gleichzeitig steigenden Leistungsfähigkeit werden Sensoren immer häufiger eingesetzt beispielsweise für Frühwarnsysteme, Umgebungsüberwachungen oder im Gesundheitswesen [BEJ+11, GSN-1]. Wissenschaftliche Arbeiten beschäftigten sich zunächst im Rahmen des Sensor Networks mit der Frage, wie eine effiziente Netzwerktopologie räumlich verteilter Sensoren realisiert werden kann. Das ist insbesondere im Hinblick auf ihre vergleichsweise schwachen Verarbeitungsressourcen und im Falle einer Funkverbindung begrenzten Energievorräte wichtig [GKK+03]. Darauf aufbauend kann ein Sensor Web realisiert werden. Es beschreibt ein per Internet erreichbares Sensor Network, dessen Sensordaten auf Grundlage von Protokollen und Schnittstellen aufgefunden, abgefragt und verarbeitet werden können [BPR+08,

43 Integration ereignisbasierter Middleware-Systeme in kontextbasierte Geschäftsprozesse 39 DJJ+05, BR07. Entsprechend dem softwaretechnischen Prinzip der Kapselung kann das Sensor Web als Middleware zwischen Sensoren und Applikationen gesehen werden. Grundsätzlich können sensordatenverarbeitende Systeme, wie in Abbildung 42 gezeigt, mithilfe der Applikations-, Middleware- und Sensor-Ebene klassifiziert werden [BEJ+11]: Abbildung 42: Ebenen zur Klassifizierung von sensordatenverarbeitenden Systemen nach [BEJ+11] Die resultierenden Klassen werden im Folgenden überblicksartig charakterisiert. 1) Sensor Web Portals Unter Verwendung eines zentralen Portals können Konsumenten und Produzenten Sensordaten austauschen. Produzenten können ihre Sensoren anmelden und deren Sensordaten auf der Plattform verfügbar machen. Konsumenten können das Portal nach für sie interessanten Sensordaten durchsuchen. Zwei Vertreter sind Sensorpedia [GRT09] und Pachube ( [Pa11]) 2) Sensor Network Management Systems Systeme dieser Ebene betrachten die Kommunikation zwischen Sensoren auf Netzwerk-Ebene. Aufgrund der erweiterten Einsatzmöglichkeiten sind insbesondere Wireless Sensor Networks (WSNs) von Interesse. Dazu gehören Aufgaben wie z.b. das verteilte Verwalten und Abfragen von Sensordaten [hifi:17,43,40,3,35], effiziente Routing-Protokolle [AY05,LCC+09], die Verarbeitung von Datenströmen [hifi: 12,30,1,10,11] oder Lokalisationsdienste [RBN+08,CLT09]. Einen Überblick verfügbarer Systeme und Architekturen bietet Wang in [WCL08]. 3) Sensor Web Infrastructures Ziel dieser Middleware-Systeme ist die Bereitstellung von Sensoren über das Internet und dem Anbieten einheitlicher Schnittstellen. Sie haben keine eigene Netzwerkfunktionalität und bauen daher auf Systemen der Klasse 2) auf. Der Einsatz einer Middleware als Mediator zwischen Applikation und physischen Sensoren ist

44 40 Richard Günther angesichts der heterogenen Sensoren mit ihren bislang nicht standardisierten Kommunikationsschnittstellen obligatorisch. 4) Internet of Things / Web of Things Mit Internet of Things wird das Erfassen eindeutig identifizierbarer Gegenstände durch Computer und ihre daraus resultierenden digitalen Repräsentationen bezeichnet [AS09]. Darauf aufbauend beschreibt das Web of Things die Vernetzung kleiner, internetfähiger Geräte durch deren Integration in das Internet [GTP+09]. Eine populäre Vorstellung ist die Integration von Alltagsgegenständen in das Internet, wie z.b. Sportschuhe, die selbstständig Laufleistungen im Internet veröffentlichen. Einen weiteren Schritt geht das Ubiquitous Computing mit der Vision vernetzter, intelligenter Gegenstände [Gr06]. Das Web of Things verwendet, analog zum Internet, das HTTP-Protokoll, um einheitliche Schnittstellen zur Integration netzwerkfähiger Geräte anzubieten. Ein Beispiel ist das Sensor Web 2.0 [MCF+08] mit dem Ziel der Erstellung eines Web-Mash-ups durch die Kombination von Services, die heterogene Sensoren repräsentieren. Systeme der Klasse 1) werden im weiteren Verlauf nicht betrachtet, da sie vorwiegend als Konsumenten auftreten und keine direkte Integration heterogener Sensoren ermöglichen. Diese müssen bereits über entsprechende Schnittstellen verfügen, um als Produzenten eingebunden werden zu können. Dieser Integrationsaspekt wird zwar von Systemen der Klasse 4) adressiert, allerdings nur in begrenztem Umfang. Insbesondere für komplexe Anwendungsfälle, für die erweiterte Zugriffsfunktionalitäten in Bezug auf das Auffinden, Zugreifen, Steuern und Verarbeiten von Ereignissen erforderlich sind, dürften Systeme der Klasse 4) nicht ausreichen. Nachfolgend werden daher einige Vertreter der Systemklasse 3) betrachtet. Als klassische Mediatoren bieten sie Schnittstellen für Produzenten und Konsumenten (Sensoren und Applikationen, vgl. Kap ) und beinhalten Funktionen zur Verarbeitung von Sensordaten. Konsumenten können sich registrieren und dabei in Form eines Ereignismusters angeben, für welche Sensordaten sie sich interessieren. Die für sie interessanten Daten erhalten sie bei Auftreten des spezifizierten Ereignisses im push-modus zugesendet oder können sie im pull-modus abrufen. Darüber hinaus ist es erklärtes Ziel des Sensor Webs, Sensoren von Applikationen steuern zu können. Die Produzenten werden unter Berücksichtigung ihrer oft proprietären Schnittstelle eingebunden und stellen ihre Daten ebenfalls im push- oder pull-modus zur Verfügung. EPCglobal In enger Kooperation mit Industriepartnern wurde die Entwicklung eines auf der RFID- Transpondertechnik basierendes Internet of Things vorangetrieben. Grundlage ist der Electronic Product Code (EPC) als Format zur eindeutigen Identifizierung [GS1-3]. Darüber hinaus wurde die Kommunikation zwischen RFID-Tag und Lesegerät, der Transport der RFID-Daten zu den Applikationen sowie das unternehmensübergreifende Auffinden von Informationen zu einer EPC durch das EPCglobal-Netzwerk standardisiert. Damit wird die Rückverfolgung von Produkten, die im Warenverkehr verschiedene Stationen passieren, ermöglicht. Beispielsweise vermerkt Unternehmen A den Ausgang eines Produkts lokal in

45 Integration ereignisbasierter Middleware-Systeme in kontextbasierte Geschäftsprozesse 41 seiner Datenbank sowie im EPCglobal-Netzwerk, sodass dieses Ereignis von Unternehmen B abgerufen werden kann. Die Architektur gibt folgende, in Abbildung 43 gezeigten Rollen und Schnittstellen vor: Abbildung 43: EPCglobal-Architektur am Beispiel eines Produkttransports zwischen zwei Unternehmen Der EPC Informationsservice (EPCIS) stellt die Schnittstelle des Unternehmens zum übergreifenden EPCglobal-Netzwerk dar. Dazu gehören Object Name Server sowie eine EPC Event Registry [GS1-1, Th06] Die Middleware spezifiziert Schnittstellen, um Sensordaten der Lesegeräte zu verarbeiten und sie in Form von Ereignissen (Application Level Events, ALE) für Applikationen bereitzustellen. Lesegeräte erfassen, z.b. im Rahmen einer Warenannahme, die EPC jedes Produkts Jedes Produkt kann über einen RFID-Tag, der einen EPC trägt, eindeutig identifiziert werden. Im Hinblick auf das Ziel dieser Arbeit wird die Middleware näher betrachtet. Sie agiert als Mediator zwischen Konsumenten (Applikationen) und Produzenten (Sensoren, RFID- Lesegeräte) und wird über eine Menge von Schnittstellen spezifiziert. Konsumenten definieren in einer Event Cycle Spec (ECSpec), für welche Ereignisse sie sich interessieren: den Ort (physisch oder logisch) des Lesegeräts die Start- und Endzeitpunkte des Beobachtungszeitraums die gewünschte Vorverarbeitung der Antwort (z.b. Filter oder Gruppierungen, jedoch keine komplexen Ereignisse) Unter Angabe einer ECSpec kann der Konsument auf drei Arten über Ereignisse informiert werden [GS1-2]: Subscribe-Push Er registriert sich für bestimmte Ereignisse. Wenn sie auftreten, erhält er eine push- Nachricht Subscribe-Pull Er registriert sich einmalig für bestimmte Ereignisse, muss aber jede Antwort explizit im Pull-Modus anfordern

46 42 Richard Günther Pull Er fragt bestimmte Ereignisse nach und erhält (einmalig) eine Antwort Während sich Konsumenten zur Laufzeit an- und abmelden können, müssen die Produzenten mit ihren Schnittstellen während der Umsetzung eines solchen Systems implementiert worden sein, denn die Spezifikation der Schnittstellen sieht keine Konfiguration von Sensoren vor. In der EPCglobal-Spezifikation wird die Middleware nur über Rollen und Schnittstellen definiert. Aufgrund der angebotenen Sensordatenvorverabeitung bietet sich jedoch eine ereignisbasierte Implementierung (vgl. EDA-Kapitel) an. Dazu passt, dass die Bereitstellung von Echtzeit-Informationen als Vorteil gegenüber klassischen, serviceorientierten Systemen proklamiert wird. Entsprechend findet in Fosstrak [FRM07], die Open-Source-Implementation der EPCglobal-Spezifikation, eine Kombination aus ereignisbasierter und serviceorientierte Architektur Verwendung. SAP Auto-ID Infrastructure Ziel der Auto-ID Infrastructure (AII, [BLH+04]) ist die Integration von hauptsächlich RFIDbezogenen Sensordaten in Geschäftsprozesse. Generell soll die Lösung skalierbar sein, auf existierenden Standards und offenen Protokollen wie EPCglobal, HTTP und XML basieren sowie das Verarbeiten von komplexen Ereignissen unterstützen. Darüber hinaus soll die Lösung Unterstützung für die Ausführung auf verteilten Systemen bieten. Die resultierende Architektur wird in folgender Abbildung 44 vorgestellt: Abbildung 44: Architektur der Auto-ID Infrastructure [BLH+04] Device Layer Heterogene Sensoren werden mithilfe einer API, die Basisoperationen zum Lesen und Schreiben von Daten sowie eine Publish/Subscribe-Schnittstelle anbietet, eingebunden. Device Operation Layer

47 Integration ereignisbasierter Middleware-Systeme in kontextbasierte Geschäftsprozesse 43 Mehrere Device Controller (DC) koordinieren verschiedene Sensoren und bieten Funktionen zum Aggregieren und Filtern der empfangenden Sensordaten. Innerhalb eines DC wird die Nachrichtenverarbeitung von einem Data Processor mit folgenden Funktionen durchgeführt: Filtern von Ereignisnachrichten Anreichern um Kontextinformationen Aggregieren von Ereignisdaten Schreiben von Daten, beispielsweise in den Speicher eines RFID-Tags Zwischenspeichern von Ereignisnachrichten Transformieren zwischen Datenformaten Data Processors können orchestriert werden, um komplexe Nachrichtenverarbeitungs- und Filteroperationen durchzuführen. Business Process Bridging Layer Die Auto-ID Node nimmt die Verknüpfung eingehender Sensordaten mit korrespondierenden Geschäftsprozessen vor. Dazu verfügt sie über einen Regelsatz, mit dem eingehende Ereignisnachrichten abgeglichen werden. Regeln geben an, welche Schritte bei Eingang einer bestimmten Nachricht auszuführen sind und ermöglichen das Verwalten von Geschäftslogik auf verarbeitungsnaher Ebene. Beispielsweise kann definiert werden, dass für ein per RFID-Tag erkanntes Objekt für dieses ein Status-Update durchgeführt werden soll. Enterprise Application Layer Systeme des Supply Chain Managements (SCM), Customer Relationship Managements (CRM) oder Asset Managements verschiedener Anbieter erfolgt auf dieser Ebene. Die Kommunikation zwischen Auto-ID Node und Applikationen geschieht mit XMLkodierten Webservices, während für die interne Kommunikaiton zwischen Auto-ID Node und darunterliegenden Ebenen ein proprietäres Format verwendet wird. Die Verwendung von Webservices deutet auf eine SOA hin. Inwiefern ereignisbasierte Mechanismen umgesetzt wurden, ist aufgrund der spärlichen technischen Dokumentation nicht ersichtlich. Sensor Web Enablement (SWE) Eine wesentliche Herausforderung beim Realisieren eines Sensor Webs ist das automatische Auffinden und Einbinden von heterogenen Sensoren. Folglich hat die SWE-Initiative zum Ziel, Sensoren über das Internet auffindbar, abfragbar und konfigurierbar zu machen und somit Interoperabilität zwischen Sensoren und Applikationen zu ermöglichen [BPR+08]. Auf Grundlage von Webservices wurde eine SOA mit einheitlichen Schnittstellen umgesetzt, wobei das Vorgehen dem publish-find-bind-paradigma [IBM00] folgt. Das Framework beinhaltet folgende Pakete:

48 44 Richard Günther Information Model: interne Kodierung von Daten / Metadaten Service Model: Webservice Schnittstellen für den Zugriff, das Beauftragen sowie Benachrichtigen von Sensoren bzw. Sensordaten Darunter werden die in Abbildung 45 gezeigten Standards / Best Practices subsumiert: Abbildung 45: Überblick über das SWE Framework [JBW10] Folgende Aufgaben werden von den einzelnen Elementen erfüllt [JBW10, BPR+08]: SWE Information Model SWE Common: Gemeinsame Basis von Datenkonstrukten, die von allen Elementen benutzt werden Sensor Model Language (SensorML): Format zur Beschreibung von Metadaten eines Sensors, ohne die Messwerte nicht interpretiert werden könnten. Observations & Measurements (O&M): Modelle und XML-Schemata zur Beschreibungen von Messwerten sowie deren Abhängigkeiten und Austauschmöglichkeiten. Transducer Markup Language (TransducerML): Analog zur Sensor Model Language werden Sensor-Metadaten in einer für Datenströme optimierten Form beschrieben SWE Service Model Sensor Observation Service (SOS): Zugriff auf Daten und Metadaten von Sensoren. Konsumenten können angeben, für welche Daten sie sich interessieren (basierend auf thematischen, räumlichen und zeitlichen Filtern). Die Daten sind mit Formaten des Information Models (O&M für Sensordaten, SensorML für Metadaten) kodiert.

49 Integration ereignisbasierter Middleware-Systeme in kontextbasierte Geschäftsprozesse 45 Sensor Planning Service (SPS): Konfigurieren der Sensoren, um den Messvorgang zu steuern. Sensor Alert Service (SAS): Konsumenten können einen Alarm definieren, z.b. wenn Temperatur > 50 Grad, und angeben, wie sie bei Eintreten benachrichtigt werden wollen die eigentliche Benachrichtigung übernimmt dann der WNS (nachfolgend beschrieben). Web Notification Service (WNS): Asynchrone Benachrichtigungskomponente, die von SPS und SES benutzt werden kann, um Konsumenten über Ereignisse zu informieren. Die eingangs genannte Herausforderung im Rahmen der Umsetzung eines Sensor Webs wird mit diesen Spezifikationen erfolgreich adressiert. Als problematisch benennen Moodley und Simonis in [MS06] jedoch die fehlende formale Ontologie der Daten- und Service-Kodierungen. Mit den pragmatisch spezifizierten Kodierungen können zwar räumliche und zeitliche Konversionen vorgenommen werden, aber es fehlen explizit zeitliche und räumliche Operatoren wie z.b. davor, danach, währenddessen, innerhalb, außerhalb oder benachbart. Diese sind für eine dynamische Datenverarbeitung jedoch notwendig. Eine zweite Schwäche stellt die fehlende Publish/Subscribe-Funktionalität für Produzenten dar, denn Sensordaten werden im pull-modus von den Sensoren abgeholt. Diese müssen folglich über einen internen Puffer verfügen. Diese Nachteile sollen jedoch in der Anfang 2011 angekündigten Weiterentwicklung SWE 2.0 [BEJ+11] behoben werden. Als wesentliche Neuerung wird SAS von dem neuen SES (Sensor Event Service) abgelöst. Während im SAS Ereignisse nur nach den vier Vergleichsoperatoren >,<, = und gefiltert werden können, bietet SES darüber hinaus durch Integration einer formal spezifizierten- EML (Event Pattern Markup Language, [OGC-08]) die Verarbeitung von logischen und räumlichen Filtern sowie die Angabe komplexer Ereignismuster. Bislang hat die Veröffentlichung jedoch nur den Status eines Diskussionspapiers und entbehrt konkreter Schnittstellen. Im Hinblick auf die Zielsetzung dieser Arbeit sind insbesondere die SAS-, SOS- und WNS- Standards von Interesse. Das in Abbildung 46 gezeigte Szenario zeigt das Zusammenspiel der drei Komponenten:

50 46 Richard Günther Abbildung 46: Szenario für den Einsatz einiger SWE-Komponenten [BEJ+11] Konsumenten melden sich beim SAS an und legen fest, bei welchen Ereignisse sie auf welche Art und Weise alarmiert werden wollen z.b.: Wenn eine Windgeschwindigkeit > 20m/s gemessen wird, soll eine SMS gesendet werden. Tritt das Ereignis ein, benachrichtigt der SAS den Konsumenten unter Nutzung des WNS, um die SMS zu senden. Der SAS hat also nur die Aufgabe, Alarme auszulösen, während der SOS Sensordaten für Applikationen zum Abruf im pull-modus bereitstellt. Mit 52 North [52N] wurde die SWE-Spezifikation exemplarisch umgesetzt und steht als Open-Source-Software zur Verfügung. Zwischen den Komponenten erfolgt die Kommunikation mit Webservices, während intern ereignisbasierte Mechanismen umgesetzt wurden. Die zugrundeliegende Architektur stellt also eine Kombination aus EOA und SOA dar. PULSENet Der Anbieter von hauptsächlich militärischen Produkten Northrop Grumman stellt mit PULSENet [FMF09] eine auf Standards basierende Architektur zum Auffinden, Abfragen und Steuern von heterogenen Sensoren sowie deren Meta- und Sensordaten vor. Dazu wurden die beiden Standards SWE und IEEE 1451 [NIST] kombiniert und auf Basis der Open-Source-Implementierung des SWE-Standards von 52 North [52N] umgesetzt. Mit Blick auf das OSI-Ebenenmodell [Os94], in der anwendungs- und transportorientierte Ebenen unterschieden werden, wird das Vereinheitlichungspotential einer Kombination der SWE- und IEEE 1451-Spezifikationen deutlich. So werden die anwendungsorientierten Ebenen des OSI-Modells, beispielsweise Session und Presentation, von den SWE-

51 Integration ereignisbasierter Middleware-Systeme in kontextbasierte Geschäftsprozesse 47 Spezifikationen mittels Webservice-Schnittstellen vereinheitlicht. Die IEEE Spezifikationen hingegen beziehen sich vorwiegend auf die unteren, transportorientierten Ebenen, wie beispielsweise Physical und Data Link. Die nachfolgende Abbildung 47 verdeutlicht die Integration beider Standards in die Architektur durch die Sichtweise auf den PULSENet-Client, der zentralen Steuerungskomponente: Abbildung 47: Überblick der PULSENet-Architektur Während die Sensoren 1-3 bereits über SWE-konforme Schnittstellen verfügen und folglich direkt über die SOS-, SAS- und SPS-Schnittstellen abgefragt und gesteuert werden können, dient der Sensor Listener Service (SLS) zur Integration beliebiger, proprietärer Schnittstellen in die SWE-Architektur. Vermutlich aufgrund der kommerziellen Verwendung werden jedoch weder zu übertragene Daten noch die angebotenen Methoden und Kommunikationsprotokolle näher spezifiziert. Global Sensor Network (GSN) GSN [GSN-1, GSN-2] hat zum Ziel, auf Grundlage vernetzter GSN-Server mit jeweils zugeordneten physischen Sensoren ein Sensor Web zu realisieren. Dazu wird mit virtuellen Sensoren eine logische Sicht auf physische und / oder andere virtuelle Sensoren ermöglicht. Beispielsweise können die Sensoren zwei verschiedener Server in einem virtuellen Sensor zusammengefasst und direkt angesprochen werden - die Beschaffung der erforderlichen physischen Sensordaten wird vor dem Konsumenten verborgen. Auf jeden dieser logisch referenzierten Datenströme eines virtuellen Sensors können SQL-basierte Abfragen angewendet werden. In folgender Abbildung sind zwei GSN-Server gezeigt, die miteinander kommunizieren, um dem virtuellen Sensor 3 die beiden physischen Sensoren 2 und 3 des GSN-Servers 1 zuzuordnen. Dazu ruft der Query Manager von Server 2 Methoden des Webservice Interfaces des GSN-Servers 1 auf. Folgende Abbildung 48. zeigt die Architektur zweier GSN-Server und deren Interaktion im Rahmen eines virtuellen Sensors:

52 48 Richard Günther Abbildung 48: Architektur eines GSN-Servers nach [GSN-1] Über das Webservice Interface kann der GSN-Server angesprochen werden, beispielsweise um Datenströme eines Sensors zu erhalten. Mit Methoden zur Verschlüsselung sowie einer elektronischen Signatur stellt der Integrity Service die Integrität und Vertraulichkeit der angefragten Daten sicher, während Zugriffsberechtigungen durch die Access Control-Komponente verwaltet werden. Der Query Manager verwaltet alle kontinuierlichen Ereignisabfragen (vgl. Kap ), die z.b. von virtuellen Sensoren gestellt werden, und sendet diesen Ereignisnachrichten zu. Das kann ereignisbasiert oder im pull-modus erfolgen. Die Storage-Komponente dient dem Speichern von Datenströmen innerhalb eines bestimmten Zeitraums. Die logische Zuordnung von physischen zu virtuellen Sensoren übernimmt der Virtual Sensor Manager. Dazu gehört eine Fehlerkorrektur auf Ebene der ursprünglichen Sensordaten, um z.b. Lesefehler und Duplikate herauszufiltern. Die Kommunikation zwischen Produzent und Konsument erfolgt über Webservices, intern zwischen GSN-Servern mit XML-RPC. Infolgedessen liegt eine Kombination aus SOA und EOA, da die interne Verarbeitung ereignisbasiert geschieht, vor. Socrades Ziel des Socrades-Integrationsframeworks 3 ist das Einbinden beliebiger heterogener Geräte und Veröffentlichen ihrer Fähigkeiten in Form von Webservices. Im Rahmen einer SOA interagieren sowohl Produzenten als auch Konsumenten über Webservices mit Socrades. Im Gegensatz zum SWE (s.o.), wo standardisierte Schnittstellen definiert werden, können die angebotenen Webservices verschiedener Geräte variieren. Bereits Webservice-fähige Geräte werden mit ihren Diensten aufgenommen, während für andere Adapter, die ihre Funktionen in Webservices überführen, zu erstellen sind. Das Integrationsframework ver- 3 Siehe aufgerufen am

53 Integration ereignisbasierter Middleware-Systeme in kontextbasierte Geschäftsprozesse 49 fügt über Methoden zum Zugreifen von Daten, dem Auffinden von Diensten sowie zur Ereignisbenachrichtigung. Socrades setzt sich aus folgenden Komponenten der in Abbildung 49 gezeigten Ebenen zusammen [SKG+09]: Abbildung 49: Ebenen des Socrades Integrationsframeworks nach [SKG+09] Die in Abbildung 49 gezeigten Ebenen erfüllen verschiedene Funktionen, die nachfolgend überblicksartig vorgestellt werden. Application Interface Applikationen wird die Möglichkeit gegeben, alle integrierten Geräte per Webservices anzusprechen und so ganze Geschäftsprozesse aus Services zu orchestrieren. Nach diesen kann unter Angabe eines Namens oder einer Beschreibung gesucht werden. Das Ergebnis eines Serviceaufrufs kann direkt zurückgeliefert oder per Benachrichtigung ausgeliefert werden. Desweiteren können sich Applikationen im Rahmen eines Publish/Subscribe-Vorgehens über Ereignisse benachrichtigen lassen. Service Management Applikationen können die Orchestrierung mehrerer Services in Form unterspezifizierter, weil möglicherweise temporär nicht verfügbarer Produzenten, BPEL- Workflows (vgl. Kap ) angeben. Diese werden automatisch ausgeführt. Der Aufruf jedes einzelnen Services wird erfasst, um anschließend leistungs- oder kostenbezogene Kennzahlen für die Ausführung eines Geschäftsprozesses generieren zu können. Device Management Wegen der bereits erwähnten temporären Unerreichbarkeit beispielsweise mobiler Geräte wird permanent der Status jedes Geräts überwacht, um einen Serviceaufruf ggf. zwischenspeichern und später ausführen zu können. Security

54 50 Richard Günther Sowohl Produzenten als auch Konsumenten müssen im Rahmen einer Interaktion die ihren Rollen entsprechenden Berechtigungsnachweise (engl. Credentials) vorweisen. Platform Abstraction Wenn die zu integrierenden Geräte über keine Service-Schnittstelle verfügen, etwa weil sie nachrichten- oder datenzentriert kommunizieren, muss diese Verhaltensweise mittels Adapter in Service-Schnittstellen überführt werden. Außerdem wird eine einheitliche Sicht auf das entfernte Aktualisieren oder Installieren von proprietärer Software auf die integrierten Geräte angeboten. Zwar wird beschrieben, welche Kommunikationsprotokolle sowohl auf Konsumenten- und Produzentenseite verwendet werden, aber eine Spezifikation der Schnittstellen oder zu übertragenden Daten erfolgt nicht. Bekannt ist, dass die Integration nicht Webservicefähiger Geräte über DPWS (Devices Profile for Webservices, [DPWS]) und OPC UA (OPC Unified Architecture, [OPC]) erfolgt [BDR+09]. Die Webservices entsprechen den WS-* Spezifikationen [WS04] auf Basis von SOAP [So07] und WSDL [WS07]. JESPA JESPA versteht sich als Middleware für die Vermittlung kontextbasierter Sichten zwischen Produzenten und Konsumenten von Sensordaten. Aus Sicht des Konsumenten besteht die Aufbereitung von Sensordaten in der Orchestrierung von Agenten. Der Konsument registriert sein Interesse an speziellen Ereignissen und wird, sofern diese auftreten, informiert. Im Zuge der Registrierung kann er mittels Workflow angeben, wie die Ereignisdaten vorverarbeitet werden sollen beispielsweise transformiert, mit Kontextdaten angereichert oder durch externe Dienste verändert. Derartige Dienste werden von Agenten gekapselt, was neben der einfachen Austauschbarkeit von Implementierungen die verteilte Ausführung auf verschiedenen Systemen ermöglicht. Die Kommunikation erfolgt über einen asynchronen Nachrichtenaustausch auf Basis von Interaktionsmustern, sodass die beteiligten Komponenten Teil einer lose gekoppelten EOA sind. Die Architektur umfasst folgende drei Ebenen: Application Layer Konsumenten registrieren sich in dieser Ebene, um bei Eintritt spezieller Ereignisse benachrichtigt zu werden. Durch die Angabe eines Ereignismusters sowie eines BPMN-basierten Workflows geben sie an, wie diese nach ihrem Auftreten verarbeitet und als Application Level Event (ALE) an den Konsumenten ausgeliefert werden. Beispielsweise können Ereignisdaten durch Agenten aggregiert, gruppiert, transformiert oder mit zusätzlichen Kontextdaten angereichert werden. Die Ereignismuster werden in einer SQL-basierten Esper EQL/EPL [Es] Syntax formuliert.

55 Integration ereignisbasierter Middleware-Systeme in kontextbasierte Geschäftsprozesse 51 Network Layer Aufgabe dieser Ebene ist das Erkennen von Ereignissen, für die sich Konsumenten registriert haben sowie die anschließende Weiterverarbeitung gemäß dem vom Konsumenten angegebenen Workflow. Sobald ein interessantes Ereignis erkannt wurde, wird ein Agent instanziiert, um die nachfolgende Aufbereitung zu koordinieren. Umgekehrt ist es auch möglich, Daten von dem Application Layer an die Sensoren weiterzuleiten, beispielsweise wenn in den Speicher eines RFID-Tags geschrieben werden soll. Network Edge Mithilfe von protokollspezifischen Adaptern werden proprietäre Sensoren eingebunden. Die von ihnen übermittelten Ereignisdaten werden hinsichtlich Duplikaten oder Lesefehlern gefiltert, um sie dann zur weiteren Verarbeitung an den darüberliegenden Network Layer zu reichen. Für JESPA ist bekannt, welche Funktionen auf Produzenten- und Konsumentenseite zur Verfügung stehen, welche Kommunikationsprotokolle genutzt werden und welche Daten dafür zu übertragen sind. Die Kommunikation umfasst mittels Adapter eine Vielzahl verschiedener Schnittstellen, während die interne Verarbeitung ereignisbasiert ist. Nachfolgende Architekturen sind zwar auch der Systemklasse 3): Sensor Web Infrastructures (vgl. Abbildung 42: Ebenen zur Klassifizierung von sensordatenverarbeitenden Systemen nach [BEJ+11]) zuzuordnen, können aufgrund ihrer spärlichen Dokumentation jedoch nur kurz skizziert werden. Insbesondere Architekturentscheidungen hinsichtlich der internen und externen Kommunikation werden häufig nur unzureichend erläutert. Streamware Mit Streamware [GRL+08] wird die Integration heterogener Sensoren auf Basis einer service-orientierten Architektur, mit verteilten sowie zentralen Komponenten und einem einheitlichen Datenschema vorgestellt. Die Kommunikation geschieht mittels Webservices und die Sensoren können im push- oder pull-modus ihre Daten veröffentlichen. Mehrere Sensoren einer Domäne werden durch einen Server verwaltet, der die zur Integration erforderlichen Adapter vorhält. Applikationen richten kontinuierliche Ereignisabfragen an einen zentralen Knoten, der sie auf die korrespondieren Server aufteilt, die Teilergebnisse zusammensetzt und nachher als Resultat zurückgibt. Das einheitliche, deklarative Datenschema entspricht dem einer relationalen Datenbank, sodass Messdatenabfragen in einer SQL-ähnlichen Syntax formuliert und das Ergebnis mit Funktionen wie Sum, Aggregate oder Group by angepasst werden. Die Referenzimplementierung verwendet eine GUI zum

56 52 Richard Günther Kombinieren der benötigten Sensoren - allerdings werden keine Angaben zu Schnittstellen oder Protokollen zur Integration des Systems gemacht. IrisNet IrisNet [GKK+03] realisiert eine Sensor Web Infrastructure als agentenbasiertes System. Die Architektur kennt Service Agents (SA), die Sensordaten sammeln und vorverarbeiten kann sowie Organizing Agents (OA), die für das Speichern der Sensordaten in eine verteilte, XML-basierte Datenbank zuständig sind. Die Abfragen werden in XPath formuliert und an ein hierarchisches Schema gesendet, das die Knoten- und Datenorganisation repräsentiert. Trotz der hierarchischen Aufteilung ist keine Orchestrierung verschiedener Knoten, etwa im Rahmen eines Workflows, vorgesehen. Eine Spezifizierung der Schnittstellen, Protokolle und zu übergebenden Daten der Konsumenten- und Produzentenseite wird nicht vorgestellt. SWAP (Sensor Web Agent Platform) SWAP [MS06] bietet eine SOA, in der Aufgaben von Agenten durchgeführt werden. Durch die Verwendung SWE-konformer Schnittstellen wird die Integration heterogener Sensoren in Workflows der Applikationsebene ermöglicht. Die zugrundeliegende Architektur besteht aus den drei Ebenen für die Verwaltung von Sensoren, Informationen und Applikationen. Jeder Ebene sind Agenten zugeordnet, sodass die jeweilige Funktionalität gut gekapselt und leicht austauschbar ist. Eine Spezifizierung der Schnittstellen, Protokolle und zu übergebenden Daten der Konsumenten- und Produzentenseite wird nicht vorgestellt. GeoSwift In der ursprünglichen Version 1.0 [LTC05,LT05] ermöglicht eine zentrale Client-Server- Architektur das Abfragen, Visualisieren und Analysieren von geografischen Sensorinformationen in einem globalen Kontext. Das geschieht auf Grundlage der von SWE spezifizierten Webservice-Schnittstellen. Beispielsweise bieten Produzenten Schnittstellen der SOS-Spezifikation an und kodieren ihre Antworten gemäß der O&M-Spezifikation. In der Version GeoSwift 2.0 [Li08] wird hingegen eine dezentrale P2P-Architektur vorgestellt, um eine bessere Skalierbarkeit zu erreichen. Da kein zentrales Register Auskunft über die Positionen der aktiven Sensoren geben kann, wird eine als P2PSAM bezeichnete (Peer-to-Peer Spatial Access Method) Zugriffsmethode vorgestellt. Dabei kann jeder beliebige Knoten Anfragen von Konsumenten entgegennehmen und auf Grundlage einer verteilten Hash- Tabelle die zur Abfrage einzubeziehenden Knoten identifizieren. Nachdem auf Grundlage einer Klassifizierung sensordatenverarbeitender Systeme einige Middleware-Systeme vorgestellt wurden, werden einige im nächsten Kapitel hinsichtlich ihrer Funktionen untersucht. Grundsätzliches Ziel ist das Identifizieren der lösungsübergreifend angebotenen Funktionalitäten.

57 Integration ereignisbasierter Middleware-Systeme in kontextbasierte Geschäftsprozesse 53 In diesem Kapitel wurde zunächst der Geschäftsprozessbegriff und seine Bedeutung für die Integration der fachlichen und technischen Ebene eines Unternehmens vorgestellt. Als Sprache, die sich für beide Ebenenen eignet, wurde BPMN 2.0 identifiziert, sodass grundlegende Notationselemente vorgestellt wurden. Um sich dem Integrationsvorhaben dieser Arbeit zu nähern, wurden anschließend ereignisbasierte Architekturen in Abgrenzung zu service-orientierten Architekturen vorgestellt. Ein typischer Anwendungsbereich für ereignisbasierte Architekturen sind Sensordaten-Middleware-Systeme, deren Aufgabe das Erzeugen von einfachen oder komplexen Ereignissen aus physischen Messwerten ist. In dem Zusammenhang wurden typische Kommunikationsmuster vorgestellt und anschließend einige relevante Vertreter von Sensordaten-Systeme vorgestellt und hinsichtlich ihrer Abstraktionsebene eingeordnet. Damit wurden grundlegende Zusammenhänge rund um das Integrationsvorhaben vorgestellt, sodass im nachfolgenden Kapitel die Anforderungen an die Integration von Ereignisdaten in Geschäftsprozesse untersucht werden können. Weil Sensordaten-Middleware-Systeme über keine einheitlichen Schnittstellen verfügen, ist außerdem eine integrierte Sicht auf diese nötig.

58 54 Richard Günther 3 Untersuchung von Sensordaten-Middleware-Systemen Im vorherigen Kapitel (vgl. Kap ) wurde deutlich, dass die Verwendung der Modellierungssprache BPMN 2.0 die Integrationslücke zwischen Business und IT verringert, sofern keine komplexen Organisationszusammenhänge abzubilden sind. Neben einigen BPMN- Notationselementen wurden ereignisbasierte Architekturen und darauf aufbauend verschiedene Sensordaten-Middleware-Systeme vorgestellt. Letztere werden auf technischer Ebene über Schnittstellen angesprochen und können, wie in Abbildung 50 gezeigt, in die drei Integrationsebenen des vorherigen Kapitels (vgl. Kap ) eingeordnet werden: Abbildung 50: Einordnung der Sensordaten-Middleware-Systeme in die drei Ebenen Zur Identifizierung der Integrationsanforderungen werden nachfolgend zwei Sichtweisen eingenommen, aus denen folgende Fragen resultieren: 1. Weisen kontextbasierte Geschäftsprozesse Gemeinsamkeiten bei der Verwendung von Sensordaten auf? 2. Weisen die verschiedenen Sensordaten-Middleware-Systeme systemübergreifende Gemeinsamkeiten auf? Im nachfolgendenden Abschnitt werden Untersuchungen zu beiden Fragen vorgestellt. Ziel ist, die je Frage identifizierten Gemeinsamkeiten der Geschäftsprozesse / Systeme in Übereinstimmung zu bringen. So finden einerseits die Anforderungen der Benutzer (Geschäftsprozesse) und andererseits die Möglichkeiten der Anbieter (Sensordaten- Middleware-Systeme) Eingang in das Integrationsvorhaben. 3.1 Gemeinsamkeiten kontextbasierter Geschäftsprozesse Nachfolgend wird ermittelt, wie Sensordaten in typischen Geschäftsprozessen verwendet werden, um daraus Anforderungen an eine Integration von Sensordaten abzuleiten. In Kapitel wird der Kontext durch die von Sensoren erfassten Informationen definiert. Für Geschäftsprozesse ist der physische Kontext, z.b. beschrieben durch Position, Temperatur oder Luftfeuchtigkeit, von Interesse [Ro06, F09]. Grundsätzlich wird immer die Umgebung eines Objekts, das stationär oder beweglich sein kann, beobachtet. Im ersten Fall des Environment Monitoring [HP09, LLS+07] wird z.b. ein Fluss, eine militärische oder industri-

59 Integration ereignisbasierter Middleware-Systeme in kontextbasierte Geschäftsprozesse 55 elle Anlage überwacht. Im zweiten Fall des Logistic Monitorings [K10] werden bewegliche Elemente wie z.b. ein Container oder ein Patient überwacht. Eine Kombination aus beiden liegt z..b. vor, wenn ein Patient Sensoren am Körper trägt, um den Herzschlag zu messen und parallel die Temperatur seiner Wohnung durch stationäre Sensoren erfasst wird [ICL06, CGF10]. Aus der Vielzahl möglicher Szenarien werden nachfolgend drei Prozesse vorgestellt. Environment Monitoring: Produktionsmaschine Auf Grundlage des Environment Monitorings stellen Lucke et al. das Konzept der Smart Factory vor [LCW08]. Es beschreibt eine kontextbasierte Produktionsumgebung, die flexibel auf physische Ereignisse reagiert, indem dezentrale Entitäten im Rahmen von Produktionsprozessen kommunizieren. Einen Beitrag liefern Nicklas et al. mit ihren als Smart Workflows bezeichneten, kontextbasierten Prozessen [WKN+07, WNL08, WKN08]. In abgewandelter Form zeigt Abbildung 51 ihr Beispiel eines Smart Workflows: Abbildung 51: Integration von Sensordaten einer Produktionsmaschine nach [WKN+07, WKN08] In der Interaktion 1) hat ein Sensor an der Bohrmaschine das Ereignis Verschleiß festgestellt, worüber die Sensordaten-Middleware den Prozess benachrichtigt. Das setzt voraus, dass sich der Prozess vorab für Benachrichtigungen dieses Typs bei der Sensordaten- Middleware registriert hat. Der Prozess prüft nun, ob das Ersatzteil im Lager vorrätig ist, und falls die Antwort ja lautet, wird in 2) die Registrierung für eine Benachrichtigung

60 56 Richard Günther des Ereignistyps Einbau erfolgreich dargestellt. Die korrespondierende Benachrichtigung erfolgt in 3), womit der Prozess abgeschlossen ist. Als Interaktion mit der Sensordaten-Middleware ist die Benachrichtigung zu nennen. 1. Benachrichtigung Eine Benachrichtigung gemäß des publish-/ subscribe-verfahrens setzt voraus, dass sich der Konsument vorab unter Angabe des gewünschten Ereignistyps registriert hat. Beispiele: Schritte 1) und 2) In diesem Beispiel erschöpft sich die Funktion von Sensoren in dem Auslösen von Prozessen, wofür sich auch eine reine SOA geeignet hätte (vgl. Kap. 1.3). Im nachfolgenden Beispiel hingegen werden große Mengen von Messdaten erfasst und aufbereitet. Darüber hinaus wird das Auffinden und Ansprechen weiterer Sensoren dargestellt. Environment Monitoring: Wasserstände beobachten Die steigende Häufigkeit von Überflutungen, Orkanen, Waldbränden und anderen Naturkatastrophen hat das Interesse am Environment Monitoring verstärkt. Beispielsweise hat die Europäische Kommission gemeinsam mit der European Space Agency (ESA) das Programm Global Monitoring for Environment and Security [ESA-09] aufgelegt. Als eines von vielen bemüht sich z.b. das SANY-Projekt (Sensors Anywhere, [Hav]) um die Integration von Sensoren über nationale und softwaretechnische Grenzen hinweg. Sensoren haben vielfältige Einsatzmöglichkeiten wie z.b. das Messen von Wasser- und Luftmassenbewegungen, Luft- und Bodenfeuchtigkeit, Luft- und Wasserqualität in Städten oder von Niederschlagsmengen. Die Space for Geoinformation -Initiative der niederländischen Regierung [SfG] sowie das Wupperverband-Projekt der Wasserüberwachungsbehörde Nordrhein-Westfalen [Wup] haben die Überwachung von Wasserständen einzelner Flussabschnitte zum Ziel. Neben der Vorhersage von Überflutungen und Veränderungen des (Grund-)Wasserspiegels wird die Unterstützung von lokalen Anwohnern, Wassersportlern und Beförderungsunternehmen durch Sensordaten angestrebt. Übereinstimmend ergeben sich folgende drei Anwendungsfälle [BEJ+11, ERC09]: Zugriff auf Zeitreihen der Sensordaten und Aufbereitung / Visualisierung der Daten Benachrichtigungen bei kritischen Ereignissen Einbezug fremder Sensoren Einen beispielhaften Prozess zeigt Abbildung 52:

61 Integration ereignisbasierter Middleware-Systeme in kontextbasierte Geschäftsprozesse 57 Abbildung 52: Geschäftsprozessmodell eines Anwendungsfalls aus dem Bereich des Environment Monitoring Abgebildet sind die beiden Prozesse Regelfall und Ausnahme. Während der erste den Regelfall darstellt und zur Aufgabe hat, die Sensoren A, B und C abzufragen (Schritte 1 und 2) und deren Daten aufzubereiten, behandelt der zweite die Ausnahme eines erhöhten Wasserstands. Die Nachricht 3) Wasserstand > 20 kann jederzeit asynchron auftreten, sofern sich vorab für derartige Ereignistypen registriert wurde (nicht abgebildet). Um entscheiden zu können, ob die Hochwasser-Schleusen geschlossen werden müssen, benötigt der Ausnahme-Prozess weitere Daten. Also wird geprüft, ob flussaufwärts weitere Sensoren existieren (Discovery) und erhält als Resultat den Sensor Z. Dessen Sensordaten werden ebenfalls abgefragt und im weiteren Verlauf wird angenommen, dass die Schleusen geschlossen werden müssen. Damit die veröffentlichten Sensordaten stets dem letzten Stand entsprechen, muss die in 3) erhaltene Sensordaten-Nachricht jedoch mit dem Regelfall-Prozess synchronisiert werden. Die Interaktionen 1), 2), 4), 5), sowie 6), 7) entsprechen dem klassischen Request-Reply-Muster, während Interaktion 3) eine Benachrichtigung darstellt. In Schritt 8) und 9) werden die vorhandenen Sensoren rekalibriert, um bei dem ungewöhnlich hohen Wasserstand möglichst genaue Messwerte zu liefern. Mit dem Auffinden von Sensoren nach verschiedenen Kriterien, hier der Geo-Position, sowie dem Steuern von Sensoren kommen zu den zuvor genannten noch zwei weitere Interaktionsformen hinzu:

62 58 Richard Günther 2. Abfrage Den Zeitpunkt der Abfrage von Sensordaten bestimmt der Konsument. Da er auf seine Anfrage eine Antwort erhält, handelt es sich um eine synchrone Kommunikation gemäß des Request / Reply-Musters. Beispiele: Schritte 1) und 2), 4) und 5), 6) und 7) 3. Auffinden Für spezielle Fälle kann es notwendig sein, bislang unbekannte Sensoren auffinden und ansprechen zu können. Beispiel: Schritte 4), 5) 4. Steuern Sensoren müssen ausgerichtet, kalibriert oder programmiert werden. Während in den vorherigen Fällen Daten von den Sensoren zu Konsumenten propagiert wurden, liegt hier der umgekehrte Fall vor: Konsumenten senden Daten an die Sensoren. Beispiel: Schritte 8) und 9) Während es in den beiden vergangenen Beispielen um die Beobachtung eines bestimmten Ausschnitts der physischen Umgebung geht, werden nachfolgend Sensoren zur Erfassung von beweglichen Objekten, hier Containern, eingesetzt. Auch im wirtschaftlichen Umfeld lassen sich durch den Einsatz von Sensoren im Zuge einer zunehmenden Automatisierung erhebliche Effizienzverbesserungen erreichen. Logistic Monitoring: Container Das Transportvolumen von Containern wächst, genau wie die beim Transport erfasste Datenmenge, seit Jahren an. Parallel dazu weist Montreuil darauf hin, dass Container in den USA im Durchschnitt nur zu 60% gefüllt und eine globale Transporteffizienz von weniger als 10% erreicht wird [M11]. Um eine verbesserte Transporteffizienz zu erreichen, sind Logistikunternehmen also auf eine zunehmende IT-Unterstützung angewiesen. Mithilfe von Sensoren lassen sich gleich zwei Aspekte unterstützen: Die automatische Abfertigung ein- und ausgehender Güter an Warenumschlagsplätzen sowie das Überwachen verderblicher Güter während des Transports. Kiziltoprak et al. stellten den Smart Container [KSH+08] vor, der seine Umgebung erfasst, z.b. die Temperatur oder Luftfeuchtigkeit, und sich selbstständig bei Warenumschlagsplätzen registriert. Für das automatische Erfassen von Waren wurde mit EPCglobal bereits eine Lösung auf Grundlage von RFID-Tags vorgestellt (vgl. Kap. 2.4). Beispielhaft lässt sich für den Bereich des Logistic Monitoring der in Abbildung 53 gezeigte Prozess anführen:

63 Integration ereignisbasierter Middleware-Systeme in kontextbasierte Geschäftsprozesse 59 Abbildung 53: Geschäftsprozessmodell eines Anwendungsfalls des Logistic Monitoring Der Prozess wird initialisiert, sobald Nachricht 1) über die Ankunft eines Containers eintrifft. Vorgelagert, aber nicht abgebildet war wiederum eine Registrierung für derartige Ereignisse. Zunächst wird mit Nachricht 2) und 3) die Sensordaten-Historie des Transportwegs abgerufen, um anhand der Lieferliste zu prüfen, ob z.b. die Temperatur zu hoch für die geladenen Waren war [CCC+07]. Wenn das nicht der Fall war, wird der Inhalt des Containers abgerufen mit Nachricht 4) und 5) - mit der Lieferliste verglichen, um eventuelle Reklamationen in die Wege zu leiten [CCC+07]. Findet sich dafür kein Anlass, kann die weitere Verarbeitung der Waren erfolgen. Aus der Perspektive kontextbasierter Geschäftsprozesse, repräsentiert durch drei beispielhafte Prozesse des Environment und Logistic Monitoring, lassen sich zusammenfassend folgende Anforderungen festhalten: 1. Abfragen von Sensordaten 2. Benachrichtigen bei bestimmten Ereignissen 3. Auffinden von Sensoren 4. Steuern von Sensoren Für jede ist die Angabe bestimmter Daten notwendig: Anforderung Daten 1. Benachrichtigen Registrierung als Konsument (vgl. Kap ) Gewünschte Sensoren Ereignisfilter 2. Abfragen Gewünschte Sensoren Ereignisfilter 3. Auffinden Sensoren nach Kriterien auffinden

64 60 Richard Günther 4. Steuern Daten an Sensoren senden Tabelle 1: Grundsätzlich benötigte Daten der vier von Seiten der Geschäftsprozesse identifizierten Anforderungen an eine Interaktion mit Sensordaten-Middleware-Systemen Diese vier Anforderungen stellen resultieren aus der Sicht von Geschäftsprozessen als Konsumenten von Ereignisdaten. Im nachfolgenden Abschnitt werden die systemübergreifenden Gemeinsamkeiten der Sensordaten-Middleware-Systeme untersucht. Dabei wird unter Verwendung einer systemunabhängigen Methodik untersucht, welche funktionalen Gemeinsamkeiten identifiziert werden können. Diese Gemeinsamkeiten werden anschließend zur Erfüllung der vier Interaktionsformen von Geschäftsprozessseite verwendet. Ziel ist die Vorstellung einer systemneutralen, konsolidierten Repräsentation von Sensordaten- Middleware-Systemen auf Geschäftsprozessebene. 3.2 Gemeinsamkeiten von Sensordaten-Middleware-Systemen Nur für wenige der in Kap. 2.4 vorgestellten Sensordaten-Middleware-Systeme liegen Spezifikationen oder Schnittstellenbeschreibungen vor. Dazu gehören EPCglobal, GSN, JESPA und SWE, die nachfolgend betrachtet werden. In Bezug auf die zu untersuchenden Aspekte verschiedener Sensordaten-Middleware-Systeme lässt sich eine Analogie aus dem Bereich der Multiagentensysteme (MAS, [Li07]) anführen. Das Agents and Artifacts-Paradigma beschreibt die Interaktion zwischen autonomen Agenten und Artefakten ihrer Umwelt [OPR+09, RVO08]. Im Sinne einer generischen Interaktionsbeschreibung werden Artefakte durch folgende Aspekte beschrieben: Funktionen (angebotene Dienste) Protokolle (Interaktionsmuster) Daten (Format der In- und Output-Daten) Analog lässt sich die objekt- oder komponentenbasierte Sichtweise in Softwarearchitekturen anführen, denn die in Kap. 2.4 vorgestellten Sensordaten-Middleware-Systeme sind als Objekte zur Kapselung von Sensoren und Bereitstellung von Sensordaten zu sehen [TS08, RH08]. Sie bieten verschiedene Funktionen (z.b. die Abfrage spezifischer Ereignisdaten), akzeptieren Daten (z.b. ein XML-kodierte Ereignismuster) und legen in Protokollen die Interaktionsreihenfolge fest. Damit ergeben sich folgende Integrationsaspekte für jedes Sensordaten-Middleware-System: 1. Funktionen 2. Protokolle 3. Daten Das resultierende weitere Vorgehen zeigt Abbildung 54:

65 Integration ereignisbasierter Middleware-Systeme in kontextbasierte Geschäftsprozesse 61 Abbildung 54: Vorgehen zur Identifizierung von Gemeinsamkeiten verschiedener Sensor- daten-middleware-systeme Zur Identifizierung systemunabhängiger Elemente werden zunächst je System die angebotenen Funktionen vorgestellt, um die systemübergreifend angebotenen Meta-Funktionen zu identifizieren. Diese Meta-Funktionen werden innerhalb von Protokollen zu Interakti- onsmustern orchestriert, für die wiederum ein systemübergreifendes Meta-Protokoll her- ausgearbeitet wird. Die im Meta-Protokoll übertragenen Daten werden wiederum je System untersucht, um im Anschluss eine systemübergreifend anzutreffende Datenrepräsentadienen schließlich zur Erfüllung der geschäftsprozessseitigen Anforderungen an die Integration von tion (Meta-Daten) zu erhalten. Diese drei Meta-Beschreibungen Ereignisdaten Meta-Funktionen Um die Meta-Funktionen zu identifizieren, werden zunächst für jedes betrachtete System die angebotenen Funktionen ermittelt. Teilweise haben Systeme aufgrund ihrer Entwickoder Anwendungsumgebung funktionale Alleinstellungsmerkmale, die nicht von anderen geteilt und damit folglich nicht übernommen lungs- werden. JESPA Wie bereits in Kap. 2.4 beschrieben, vermittelt JESPA kontextbasierte Sichten zwischen Produzenten und Konsumenten von Sensordaten. Über Schnittstellen registrieren sich

66 62 Richard Günther Produzenten und veröffentlichen ihre Daten. Resultierende Ereignisdaten können von Konsumenten im pull-modus abgerufen werden, jedoch wird diese Funktion aktuell von den Entwicklern überarbeitet. Dasselbe gilt für das Abrufen von Metadaten. Anschließend registrieren sich Konsumenten unter Angabe Esper EQL/EPL-basierter Ereignismuster [Es], und erhalten die entsprechenden Daten bei Auftreten zugesendet. Die Ereignisdaten können auch pull-basiert abgerufen werden, Darüber lässt sich mittels Workflow spezifizieren, wie die Ereignisdaten vorverarbeitet werden sollen. Aufgrund dieser generischen Beschreibungsmöglichkeit lassen sich beliebige Services inner- und außerhalb von JESPA in die Vorverarbeitung einbinden. Desweiteren verwendet JESPA Token für die Zugriffskontrolle sowie die Abrechnung ggf. kostenpflichtiger Dienste. Im Ergebnis bietet es die folgenden Funktionen: Sensordaten-Middleware-System Jespa Produzent Funktionen 1 Produzent registrieren a 2 Daten veröffentlichen a 3 Produzent entfernen a 4 Metadaten abfragen r* Konsument 5 Ereignisdaten per pull erhalten r* 6 Ereignismuster abonnieren a 7 Ereignisdaten per push erhalten a 8 Abonnement abmelden r* 9 Vorverarbeitung per Workflow spezifizieren 10 Token-Konzept a * = Wird aktuell überarbeitet Tabelle 2: Funktionenkatalog der Sensordaten-Middleware JESPA a GSN Grundlegende Abstraktion zur Realisierung eines Sensor Webs ist der virtuelle Sensor (vgl. Kap. 2.4). So werden verteilte Sensoren logisch gruppiert, während die zugrunde liegende Kommunikation vor dem Konsumenten verborgen wird. Produzenten werden registriert und veröffentlichen ihre Daten im push- oder pull-modus. Konsumenten können sich alle verfügbaren Sensoren eines physischen GSN-Servers anzeigen lassen, Ereignismuster mit SQL-basierten, logischen Operatoren definieren und die resultierenden Ereignisdaten per push oder per pull erhalten. Darüber hinaus lassen sich die virtuellen Sensoren verwalten, sodass im Vergleich zu JESPA die in * = Wird aktuell überarbeitet Tabelle 3 gezeigten Funktionen angeboten werden:

67 Integration ereignisbasierter Middleware-Systeme in kontextbasierte Geschäftsprozesse 63 Produzent Konsument Funktionen Sensordaten-Middleware-System Jespa GSN 1 Produzent registrieren a a 2 Daten veröffentlichen a a 3 Produzent entfernen a a 4 Metadaten abfragen r* a 5 Ereignisdaten per pull erhalten r* a 6 Ereignismuster abonnieren a a 7 Ereignisdaten per push erhalten a a 8 Abonnement abmelden r* a 9 Vorverarbeitung per Workflow spezifizieren 10 Token-Konzept a r 11 Logisches Gruppieren von Sensoren r a * = Wird aktuell überarbeitet Tabelle 3: Funktionenkatalog der Sensordaten-Middleware GSN a r EPCglobal Ziel von EPCglobal ist das Bereitstellen von jederzeit, per Internet verfügbaren Produktinformationen [C06]. Es bezieht sich ausschließlich auf RFID-Tags, die jeweils eindeutige EPCs tragen, und von verschiedenen Unternehmen im Rahmen logistischer Prozesse gelesen werden (vgl. Kap. 2.4). Jedes Unternehmen speichert Kontextinformationen zu EPCs, mit denen es Kontakt hatte. Diese dezentral gespeicherten Datensätze werden von einem zentralen Object Name Service (ONS, Teil des EPCIS) indiziert, sodass sie von Dritten aufgefunden werden können. Im EPCIS werden darüber hinaus domänenspezifische Ereignisse verwaltet und im Hinblick auf eine Integration in Geschäftsprozesse vorverarbeitet. Beispielsweise gibt ein Aggregations-Ereignis auf abstrakter Ebene an, dass die EPCs mehrerer Artikel gelesen und einer Lieferungs-Nummer zugeordnet wurden, sodass entsprechend das Ereignis einer eingetroffenen Warenlieferung vorliegt. Im Hinblick auf das Ziel dieser Arbeit wird jedoch nur die ALE-Middleware, die von Sensoren erfasste RFID-Tags in Form von ALE der darüberliegenden EPCIS-Schicht anbietet, betrachtet. Aufgrund des Anwendungskontextes, Warenumschlagsplätzen mit statischem Aufbau, werden Lesegeräte nicht per Schnittstelle, sondern in der Einrichtungsphase des Systems eingebunden. Für den Abruf von Ereignisdaten können Muster unter Verwendung proprietärer Syntaxelemente formuliert werden. Der pull-basierten Abruf von Sensordaten kann auf zwei verschiedene Arten erfolgen: serverseitig zustandslos und zustandsbehaftet [TS08]. Im ersten Fall erfolgt die Abfrage wie ein one-shot, d.h. der Konsument gibt alle nötigen Spezifikationen wie Sensor, Zeit, benötigte Daten an, was der Server entsprechend beantwortet. Im zweiten Fall registriert der Konsument vorab eine Ereignisabfrage, um künftig unter Bezug auf

68 64 Richard Günther diese Registrierung Daten im pull-modus abzurufen. Das push-basierte Abrufen von Ereignisdaten unter Angabe von Ereignismustern erfolgt wiederum gemäß des publish-/ subscribe-paradigmas. Desweiteren können Sensoren, analog zu GSN, logisch gruppiert werden. Zusätzlich bietet die ALE-Middleware das Schreiben von Daten in den Speicher der RFID-Tags. Im Vergleich zu den vorherigen Middleware-Systemen weist EPCglobal die in Tabelle 4 gezeigten Funktionen auf: Produzent Konsument Funktionen Sensordaten-Middleware-System Jespa GSN EPCglobal 1 Produzent registrieren a a r 2 Daten veröffentlichen a a r 3 Produzent entfernen a a r 4 Metadaten abfragen r* a a 5 Ereignisdaten per pull erhalten r* a a 6 Ereignismuster abonnieren a a a 7 Ereignisdaten per push erhalten a a a 8 Abonnement abmelden r* a a 9 Vorverarbeitung per Workflow spezifizieren a r r 10 Token-Konzept a r r 11 Logisches Gruppieren von Sensoren r a a Dienst zum Auffinden verteilter Sensordaten Dienst zum Auffinden verteilter Sensoren 14 Sensoren steuern r r a * = Wird aktuell überarbeitet Tabelle 4: Funktionenkatalog der Sensordaten-Middleware ALE-Middleware des EPCglobal-Frameworks r r r r a a SWE Im Vergleich zu den bislang betrachteten Middleware-Systemen stellt SWE das umfassendste Konzept bereit. Es bietet im Rahmen der Sensor Web-Idee das Auffinden, Konfigurieren und Abfragen von heterogenen Sensoren und legt ISO-Standards und Spezifikationen für die Schnittstellen vor, was die Akzeptanz und Integration von Sensordatenbasierten Anwendungen fördert. Neben den bereits in Kap. 2.4 vorgestellten Diensten SPS, SOS, WNS sowie SAS mit seinem Nachfolger SES wird noch der Catalogue Service (CS-W, [NWV07]), ein Dienst zum dynamischen Auffinden von Sensoren, spezifiziert. Die beiden Dienste SES und SOS bieten Sensordaten an, unterscheiden sich jedoch beim Zugriff. SOS

69 Integration ereignisbasierter Middleware-Systeme in kontextbasierte Geschäftsprozesse 65 bietet das pull-basierte Abrufen von Sensordaten durch Sensordaten- Archivierungssysteme [BPR+08]. SES hingegen realisiert auf Basis der von OASIS veröffentlichten Webservice-Spezifikationen WS-Notification [OASIS-06, OASIS-06-2] eine publish-/subscribe-funktionalität. Sie ermöglicht das Abonnieren von Ereignisdaten gemäß ihrer Einordnung in Themenbereiche (sog. Topics) [BEJ+11]. Die Spezifikationen der SES- Schnittstellen haben jedoch bislang nur den Status eines Diskussionspapiers und können sich folglich ändern. SOS bietet das Filtern von Ereignisdaten auf Grundlage der Filter Encoding Specification (FES, [OGC-10]), die eine systemneutrale Kodierung SQL-ähnlicher Projektionen, Selektionen und Sortierungen spezifiziert. SES bietet neben FES die beiden folgenden Filtermöglichkeiten an: XPath 1.0 [W3C-99] Filtert auf Syntax-Ebene einzelne Teile eines XML-Dokuments, also einzelner Ereignisdaten. EML [OGC-08-2] Filtert den Informationsgehalt mehrerer Ereignisse von Ereignisströmen und erweitert FES um die Sicht auf Zeitfenster sowie die Erzeugung von komplexen Ereignissen. Im Vergleich zu den Funktionen der anderen Systeme bieten die beiden SWE-Dienste SOS und SES folgende, in Tabelle 5 gezeigten Funktionen an: Produzent Konsument Funktionen Sensordaten-Middleware-System Jespa GSN EPCglobal SWE 1 Produzent registrieren a a r a 2 Daten veröffentlichen a a r a 3 Produzent entfernen a a r a 4 Metadaten abfragen r* a a a 5 Ereignisdaten per pull erhalten r* a a a 6 Ereignismuster abonnieren a a a a 7 Ereignisdaten per push erhalten a a a a 8 Abonnement abmelden r* a a a 9 Vorverarbeitung per Workflow spezifizieren a r r r 10 Token-Konzept a r r r 11 Logisches Gruppieren von Sensoren r a a a Dienst zum Auffinden verteilter Sensordaten Dienst zum Auffinden verteilter Sensoren a a 14 Sensoren steuern r r a a Legende: Fett = von allen Systemen übereinstimmend angeboten, r r r r a a

70 66 Richard Günther * = wird aktuell überarbeitet Tabelle 5: Funktionenkatalog der SWE-Dienste SES und SOS zusammen mit den Funktionen der anderen Systeme. Die fett markierten Zeilen der Tabelle zeigen, welche Funktionen von allen betrachteten Systemen übereinstimmend angeboten werden, und stellen eine erste Eingrenzung hinsichtlich zu integrierender Elemente dar. Die produzentenseitigen Funktionen 1 3 werden zwar von EPCglobal nicht angeboten es beschränkt sich auf den statischen Unternehmenskontext werden aber dennoch aufgenommen, da sie Teil jeder dynamischen Sensordaten-Middleware sein müssen. Auch das Abfragen von Sensor-Metadaten (4) sowie Abrufen von Sensordaten im pull-modus (5) wird übereinstimmend angeboten, da es im Falle von JESPA aktuell überarbeitet wird. Das logische Gruppieren von Sensoren hingegen wird zwar ebenfalls übereinstimmend angeboten, ist jedoch als administrative Funktion auf Metadaten-Ebene zu sehen, die nicht direkt vom Ziel dieser Arbeit adressiert und somit nicht weiter betrachtet wird. Für die Funktionen 1 8 wird im nachfolgenden Abschnitt, gemäß des Identifizierungsvorgehens (vgl. Abbildung 54), das gemeinsame Protokoll ermittelt Meta-Protokoll Für die im vorherigen Abschnitt ermittelten gemeinsamen Funktionen werden nun, unterteilt nach den betrachteten Sensordaten-Middleware-Systemen, die entsprechenden Interaktionsmuster vorgestellt. Ziel ist das Identifizieren gemeinsamer Protokolle, für die im nächsten Kapitel die gemeinsame Struktur der übertragenen Daten identifiziert wird. Zur Visualisierung werden Sequenzdiagramme, eine von der UML entwickelte Modellierungssprache [K06], verwendet. Protokolle bestehen aus Interaktionsschritten, die jeweils eine Funktionalität zwischen Akteuren beschreiben. Beispielsweise weist das in Abbildung 55 gezeigte Protokoll zwei Schritte zwischen A und B und einen Schritt zwischen B und C auf. Abbildung 55: Beispielhaftes Sequenzdiagramm

71 Integration ereignisbasierter Middleware-Systeme in kontextbasierte Geschäftsprozesse 67 Schritt 1) zeigt einen synchronen und 2) einen asynchronen Aufruf, wobei letzterer mehrfach wiederholt werden kann (dargestellt durch den selbstbezogenen Pfeil). Die Schritt 3) dagegen besteht nur aus dem synchronen Aufruf von B nach C. Auf Grundlage dieser Notationselemente werden nachfolgend die Protokolle der betrachteten Sensordaten- Middleware-Systeme vorgestellt. Im Sinne einer systemübergreifenden Interaktionsbeschreibung werden die in Kap vorgestellten Produzenten- und Konsumentenrollen verwendet. JESPA Die Sensordaten-Middleware JESPA weist die in Abbildung 56 dargestellten Interaktionsschritte auf: Abbildung 56: Interaktionen mit der Sensordaten-Middleware JESPA Schritt 1) zeigt die Registrierung eines Sensors an JESPA in Form eines synchronen Aufrufs. Das anschließende Übermitteln von Sensordaten durch asynchrone, mehrfache push- Aufrufe ist in 2) dargestellt. Der Sensor ist JESPA nun bekannt und hat bereits Daten veröffentlicht, sodass sich Konsumenten in 6) unter Angabe eines Ereignismusters für Benachrichtigungen registrieren können. Sobald das gewünschte Ereignis auftritt, werden dem Konsumenten die entsprechenden Ereignisdaten per asynchronem push-aufruf in 7) zugesendet. Das Abonnement kann, gezeigt in 8), wieder abgemeldet werden und in 3) entfernt der Produzent den Sensor wieder.

72 68 Richard Günther GSN Die Interaktionsschritte von GSN werden in folgender Abbildung 57 dargestellt: Abbildung 57: Interaktionen mit der Sensordaten-Middleware GSN In 1) wird zunächst der Sensor mittels synchronem Aufruf registriert, um die Daten wahlweise im push- oder pull-modus zu veröffentlichen (2-a und 2-b). Das Pendant zur Registrierung stellt das Entfernen des Sensors in 3) dar. Dazwischen modellieren die beiden Interaktionen 4-8 das pull- und push-basierte Abrufen von Sensordaten. Der Schritt 4-a) ist optional und dient dem Abfragen der Namen aller aktiven Produzenten, um in 4-b) die gewünschten Metainformationen auf einen Produzenten einschränken zu können. Alternativ können in 4-b) jedoch auch die Metainformationen aller aktiven Produzenten abgefragt werden. Diese Informationen beinhalten u.a. Datenfelder, die sich in 5) durch einen pullbasierten Aufruf beliebig oft abfragen lassen. Alternativ wird ein Ereignismuster definiert

73 Integration ereignisbasierter Middleware-Systeme in kontextbasierte Geschäftsprozesse 69 und in 6) im Rahmen des publish-/ subscribe-vorgehens abonniert. Die Ereignisdaten werden dann in 7), ggf. mehrfach, im push-modus an den Konsumenten gesendet. Schließlich kann der Konsument das Abonnement in Schritt 8) wieder entfernen. Anzumerken ist noch, dass GSN die Zusendung von Ereignisdaten im push-modus sowohl verbindungslos als auch verbindungsorientiert anbietet [TS08]. Im ersten Fall baut GSN für jeden Aufruf eine neue Verbindung zum Konsumenten auf, währenddessen im zweiten Fall die anfangs initiierte Verbindung des Konsumenten zu GSN aufrechterhalten und für die Übermittlung von Daten verwendet wird. EPCglobal Bei der ALE-Middleware von EPCglobal werden Sensoren nicht dynamisch registriert, sondern vorab im Rahmen der Einrichtungsphase eingebunden, sodass nur die Schritte 4-8 für das pull- und push-basierte Abrufen von Ereignisdaten modelliert werden. Desweiteren bietet die ALE-Middleware Konsumenten an, Daten in die RFID-Tags zu schreiben. Diese Funktionalität ist allerdings nicht Teil der Meta-Funktionen und wird daher nicht weiter betrachtet. Folgende Abbildung 58 zeigt die Interaktionsschritte: Abbildung 58: Interaktionen mit der Sensordaten-Middleware EPCglobal

74 70 Richard Günther Sowohl für das Abfragen von Sensordaten auf pull- als auch push-basis müssen in den Schritten 4-a und 4-b die Namen und Eigenschaften der verfügbaren Sensoren abgefragt werden. Der Schritt 5-1) ist komplementär zu denen von 5-2), da im ersten Fall das Konzept eines zustandslosen und im zweiten eines zustandsbehafteter Servers verwendet wird [SS07, TS08]. Im ersten Fall wird in Form eines synchronen Aufrufs eine Ereignisabfrage übermittelt, zudem die resultierenden Ereignisdaten den Rückgabewert darstellen (oneshot). In 5-2 a) hingegen wird zunächst eine Ereignisabfrage registriert, in 5-2 b) abgefragt und in 5-2 c) wieder entfernt. Der Unterschied ist, dass die Abfrage nicht mit jedem Aufruf übermittelt werden muss, sondern vom Server gespeichert wird. Das push-basierte Zusenden von Sensordaten hingegen wird in 6-8) beschrieben. Das Abonnieren für Ereignisdaten geschieht hier in zwei Schritten: Zuerst wird in 6-a) das Ereignismuster am System registriert, um diesem danach in 6-b) Abonnenten hinzuzufügen. Das Zusenden von Ereignisdaten geschieht in 7), während in 8-a) und 8-b) das Abmelden des Abonnements sowie Entfernen des Ereignismusters gezeigt wird. SWE Wie eingangs erwähnt, werden vom SWE-Framework die beiden Dienste SOS (pull-abruf von Ereignisdaten) und SES (push-zusendung von Ereignisdaten) betrachtet. Die zugehörigen Interaktionsschritte werden in folgender Abbildung 59 dargestellt:

75 Integration ereignisbasierter Middleware-Systeme in kontextbasierte Geschäftsprozesse 71 Abbildung 59: Interaktionen mit der Sensordaten-Middleware SWE Weil die beiden Dienste SOS und SES betrachtet werden, werden die Schritte 1-3 in a und b unterschieden. Prototypische Systeme sehen vor, dass sich Sensoren sowohl beim SOS- als

76 72 Richard Günther auch SES-Dienst anmelden [BEJ+11]. Das Registrieren von Produzenten geschieht in 1-a) und 1-b) per synchronem Aufruf, während das Veröffentlichen von Sensordaten beim SOS in 2-a) per synchronem und beim SES in 2-b) per asynchronem Aufruf geschieht. Das Entfernen eines Produzenten, dargestellt in 3-b), bietet hingegen nur die SES-Schnittstelle an. Das Abrufen von Metadaten gliedert sich, analog zum Registrieren von Produzenten, für die beiden Dienste in die Schritte 4-a) und 4-b) und beinhaltet einen synchronen Aufruf. Das pull-basierte Abrufen von Ereignisdaten am SOS wird in 5) gezeigt, während sich der Konsument am SES zunächst, gemäß des publish-/ subscribe-paradigmas, unter Angabe eines Ereignismusters anmelden muss. In 7) werden die Ereignisdaten per asynchronem Aufruf zugesendet. Das aktive Abonnement wird in 8) wieder abgemeldet. Gemeinsamkeiten Bei Betrachtung aller Protokolle, dargestellt durch Interaktionssequenzen und ihren einzelnen Schritten, können einige Gemeinsamkeiten festgestellt werden. Deutlich wird, dass die push-funktionalität (vgl. Schritt 6-8 der Tabelle 5) dem publish-/subscribe-paradigma entspricht und folglich eine standardisierte Vorgehensweise aufweist. Nachfolgende Tabelle 6 zeigt alle Unterschiede auf und schlägt jeweils eine Vereinheitlichung vor, um daraus resultierend eine von allen Systemen getragene Modellierung aufzuzeigen: Unstimmigkeit Vereinheitlichung Synchrone / Asynchrone Aufrufe Im Gegensatz zu den anderen Systemen macht EPCglobal auf Ebene der ALE- Middleware häufig Gebrauch von asynchronen Aufrufen. Abfragen der Produzenten-Metadaten Im Gegensatz zu SWE bieten GSN und EPCglobal die Eingrenzung der angeforderten Metadaten auf einen Produzenten, sodass vorab die Namen aller Produzenten abgefragt werden müssen. Abonnieren von Ereignisdaten Im Gegensatz zu den anderen Systemen sieht die ALE-Middleware von EPCglobal Asynchrone Aufrufe können als synchrone mit leerem Rückgabewert modelliert werden. Es werden synchrone Aufrufe modelliert. Ausnahme: push-benachrichtigungen [TS08] Da die beiden SWE-Dienste SOS und SES das Eingrenzen nicht und GSN nur optional anbieten, wird im weiteren Verlauf kein Vorgelagerter Schritt zum Ermitteln der Produzentennamen modelliert. Metadaten werden mit einem Aufruf abgefragt. Da die beiden Aufrufe 6-a) und 6-b) keinen Rückgabewert haben, können die beiden

77 Integration ereignisbasierter Middleware-Systeme in kontextbasierte Geschäftsprozesse 73 zwei Schritte zum Abonnieren von Ereignismustern gemäß des publish-/subscribe- Verfahrens vor. Produzenten stellen Daten per push oder pull bereit Sowohl GSN als auch SWE ermöglichen das Veröffentlichen von Ereignisdaten per pullund push-modus. Input-Belegungen in einem einzigen Aufruf zusammengefasst werden, sodass eine Realisierung des publish-/ subscribe-vorgehens erreicht wird. Das Abonnieren geschieht in Schritt 6. Da alle betrachteten Systeme das pushbasierte Veröffentlichen von Ereignisdaten anbieten, wird dieses im weiteren Verlauf modelliert. Produzenten veröffentlichen ihre Daten im push-modus. Tabelle 6: Annahmen zur Vereinheitlichung der verschiedenen Protokolle Die im vorherigen Abschnitt identifizierten Meta-Funktionen ergeben, unter Anwendung der in Tabelle 6 getroffenen Vereinheitlichungen, das in Abbildung 60 gezeigte Meta- Protokoll:

78 74 Richard Günther Abbildung 60: Meta-Protokoll der verschiedenen Sensordaten-Middleware-Systeme Für diese Interaktionsschritte sind nun, entsprechend der in Abbildung 54 dargestellten Vorgehensweise zur Identifikation von Gemeinsamkeiten verschiedener Sensordaten- Middleware-Systeme, die systemübergreifend übertragenen Daten zu ermitteln Meta-Daten Auf Grundlage des im vorherigen Abschnitt erarbeiteten Meta-Protokolls (vgl. Abbildung 60) wird nun für jede Sensordaten-Middleware untersucht, welche Daten in den jeweiligen Interaktionsschritten übertragen werden. Ziel ist die Identifizierung systemübergreifender Daten zur Repräsentation der gewünschten Informationen. Im Hinblick auf die Untersuchung der Daten, die jedes System im Rahmen des Meta- Protokolls überträgt, muss zunächst die einheitliche Beschreibung der verschiedenen Sprachen zur Formulierung von Ereignisfiltern ermöglicht werden.

79 Integration ereignisbasierter Middleware-Systeme in kontextbasierte Geschäftsprozesse 75 Wie in Kapitel erläutert wurde, ergeben sich für sensordatenverarbeitende Systeme die drei grundlegenden Verarbeitungsschritte Erkennen, Verarbeiten und Behandeln. Während das Erkennen von Ereignissen durch Sensoren sowie das Behandeln von Mustern durch Reaktionen von der Funktions- und Protokollbeschreibung abgedeckt wird, muss die Verarbeitung bzw. Filterung noch näher betrachtet werden. Folgende Abbildung 61 skizziert den Vorgang der Ereignisfilterung: Abbildung 61: Filterfunktionalität von sensordatenverarbeitenden Systemen nach [BD10] In Kapitel wurde schon erwähnt, dass Ereignismuster in verschiedenen Sprachen formuliert werden. JESPA verwendet Esper-Ausdrücke mit SQL-ähnlicher Syntax, GSN definiert Filter durch die Kombination mehrerer SQL-Abfragen über Datenströme, die ALE-Middleware von EPCglobal verwendet eine um XPath-Ausdrücke erweiterte SQL- Syntax und SWE erlaubt die Formulierung von Filtern in XPath 1.0, dem ISO-Standard FES sowie EML. Allen Filterbeschreibungssprachen gemeinsam ist die inhärente Nähe zur SQL- Syntax, die zwar keine vollständige Abbildbarkeit, aber eine Einordnung der Filter in Projektion (SELECT-Klausel) und Selektion (WHERE- Klausel) der Relationenalgebra [M04] ermöglicht. Dazu werden auf Datenebene die Eingabeströme referenziert, sodass sich das in Tabelle 7 gezeigte Filter-Schema anwenden lässt: 1) Eingabe 2) Filter 3) Ausgabe FROM WHERE SELECT Tabelle 7: Schema einer Ereignisdatenabfrage Beispielsweise lässt sich die die vereinfachte Abfrage nach bestimmten Ereignissen wie folgt in SQL-ähnlicher Syntax formulieren: SELECT * FROM Eingabestrom WHERE Temperatur > 20 In Bezug auf die Formulierung von Filtern wird eine Zuordnung von Elementen der verschiedenen Filterbeschreibungssprachen in die drei SELECT, FROM und WHERE-Klauseln vorgenommen und in Anhang A vorgestellt. Anhang B hingegen weist für jedes System

80 76 Richard Günther und für jeden Schritt des Meta-Protokolls die übertragenen Daten aus, versteht sich jedoch nicht als vollständige Auflistung jeden Systems. Gemäß der Entscheidung, auf Protokoll- Ebene von synchronen Aufrufen auszugehen (vgl. Tabelle 6), werden je Protokollschritt Input- und Outputdaten unterschieden. Einzige Ausnahme stellt die push- Benachrichtigung eines Konsumenten dar, die asynchron erfolgt. Auf Grundlage der Zusammenstellungen des Anhangs A und B werden für jeden Schritt des Meta-Protokolls die von verschiedenen Systemen übereinstimmenden Meta-Daten bestimmt. Damit wird der letzte Schritt des Vorgehens zur Identifizierung von Gemeinsamkeiten verschiedener Sensordaten-Middleware-Systeme vollzogen (vgl. Abbildung 54: Vorgehen zur Identifizierung von Gemeinsamkeiten verschiedener Sensordaten-Middleware-Systeme). 1): Produzent registrieren. Bei der Registrierung eines Produzenten werden zwei Aspekte beschrieben: der Produzent und die vom Produzenten zu erwartenden Daten. Letztere durch Strukturen, Typen und Einheiten beschrieben, während Fähigkeiten und Eigenschaften des Produzenten durch Schlüssel-Wert-Paare oder einfache Zeichenketten angegeben werden. SWE modelliert die Ereignisdaten eines Produzenten mit Datenfeldern, die mehrere Attribute beinhalten (vgl. Anhang B.4). <swe:field name="offset"> <swe:quantity definition="urn:ogc:def:phenomenon:cgi:2007:offset" gml:id="q23525"> <swe:uom link:href="urn:ogc:def:uom:ucum:m"/> </swe:quantity> </swe:field> JESPA dagegen modelliert Ereignisdaten in einer EventTypeMap, die mehrere Datenfelder eines Ereignisdatensatzes mit jeweiligem Namen und Datentypen abbildet (vgl. Anhang B.1). <eventtypemap eventtypename="mytemperatureeventstream"> <type name="temperature" class="int" /> <type name="timestamp" class="long" /> <type name="location" class="string" /> </eventtypemap> Analog modelliert GSN je Produzenten eine Struktur, die für jeden Wert Namen und Datentyp definiert (vgl. Anhang B.2). <output-structure> <field name="image" type="binary:jpeg"/> <field name="temperature" type="double"/> </output-structure>

81 Integration ereignisbasierter Middleware-Systeme in kontextbasierte Geschäftsprozesse 77 Alle Repräsentation können mittels Schlüssel-Wert-Paare abgebildet werden. Im Falle von SWE ist dafür jedoch die Einführung einer zusätzlichen Ebene zur Verschachtelung erforderlich. Folgende Tabelle 8 beschreibt die resultierende, systemübergreifend anwendbare Datenstruktur. Struktur <EventTypeSet name=" "> <EventType name=" "> <Key>Value</Key> <Key>Value</Key> </EventType> </EventTypeSet> Beispiel Set1, (Wasserstand, ( (Typ, double), (Einheit, Meter), ) ) Tabelle 8: Struktur zum Beschreiben der Ereignisdaten eines Produzenten Bei der Verwendung ist zu beachten ist, dass JESPA und GSN nur einen EventType je Produzent definieren, während SWE mehrere benötigt. Die Daten zum Beschreiben eines Produzenten hingegen unterscheiden sich in allen Systemen grundlegend. Während JESPA Identifikationsdaten unter anderem zur Abrechnung verwendet und beschreibende Daten in Zeichenketten bereitstellt, nutzt GSN dazu Schlüssel-Wert-Paare und SWE detaillierte SensorML-Dokumente [OGC-07]. Daher werden Produzenten nachfolgend durch unbestimmte Schlüssel-Wert-Paare beschrieben. Daraus ergibt sich die in Tabelle 9 gezeigte Datenstruktur für den Schritt der Produzentenregistrierung. Bedeutung Input Producer-ID Schlüssel-Wert-Paare identifizieren und beschreiben den Produzenten. -Key / -Value / EventTypeSet EventTypeSets entsprechen einem Ereignisdatensatz, der Ereignisdatenfelder beinhaltet und die Ausgabe eines Produzenten beschreibt. -EventType EventTypes entsprechen einzelnen Ereignisdatenfeldern, die durch Schlüssel- Wert-Paare beschrieben Beispiel (Seriennummer, ), (Ort, Hamburg), (Set1, (Wasserstand, ((Einheit, Meter), (Typ, double)), (Temperatur, ((Einheit, Celsius), (Typ, integer)), )

82 78 Richard Günther werden. --Key / --Value / Output Success War die Operation erfolgreich? True Tabelle 9: Datenstruktur einer Produzentenregistrierung Nachdem eine Meta-Datenstruktur für die Registrierung eines Produzenten am System vorliegt, dieser Daten veröffentlichen. Die korrespondierende Meta-Datenstruktur wird im nachfolgenden Schritt 2) vorgestellt. 2): Ereignisdaten veröffentlichen. Diese Funktion wird nur von JESPA und SWE spezifiziert. Weil sowohl SES und SOS von SWE als auch JESPA die übertragenen Werte an Zeitstempel binden, lässt sich wiederum die aus Schritt 1) bekannte Struktur der verschachtelten Schlüssel-Wert-Paare verwenden. Die Zuordnung der empfangenen Daten geschieht auf Basis der übermittelten Produzentenidentifizierung. Daraus ergibt sich die in Tabelle 10 gezeigte Datenstruktur für den Schritt der Veröffentlichung von Ereignisdaten durch Produzenten. Da es sich um einen asynchronen Aufruf handelt, erfolgt keine Unterscheidung in In-/Output-Daten. Bedeutung Producer-ID Schlüssel-Wert-Paare identifizieren und beschreiben den Produzenten. -Key / -Value / EventDataSet Zu jedem Zeitstempel werden Name und Wert der aufgetretenen Ereignisdatenfelder aufgeführt. -EventData Ereignisdatenfelder werden durch Schlüssel-Wert-Paare beschrieben. --Key / --Value / Beispiel (Seriennummer, ), (Ort, Hamburg) (Set1, ( _15:37:00, ((Wasserstand, 12), (Temperatur, 17)), ( _15:38:00, (Wasserstand, 10), (Temperatur, 18)), ) Tabelle 10: Datenstruktur zur Veröffentlichung von Ereignisdaten durch Produzenten 3): Produzent entfernen.

83 Integration ereignisbasierter Middleware-Systeme in kontextbasierte Geschäftsprozesse 79 Diese Funktion wird von JESPA, GSN und dem SES-Dienst von SWE angeboten. Während JESPA und GSN den Produzenten mit Schlüssel-Wert-Paaren bzw. dem Namen identifizieren, verlangt SES eine Zeichenkette mit der Registrierungsreferenz. Übereinstimmend lassen sich ein oder mehrere Schlüssel-Wert-Paare zur Identifizierung verwenden. Daraus ergibt sich die in Tabelle 11 gezeigte Datenstruktur für den Schritt der Entfernung eines Produzenten. Bedeutung Input Producer-ID Schlüssel-Wert-Paare identifizieren und beschreiben den Produzenten. -Key / -Value / Output Success War die Operation erfolgreich? Beispiel (Seriennummer, ), (Ort, Hamburg) True Tabelle 11: Datenstruktur der Entfernung eines Produzenten Nachdem in den Schritten 1-3 die Interaktion aus Sicht von Produzenten betrachtet wurde, erfolgt nun die Untersuchung der konsumentenseitigen Interaktion. Zunächst fragt dieser im nachfolgenden Schritt beschreibende Informationen über die vorhandenen Ereignisdaten und Produzenten ab. 4) Metadaten abfragen Metadaten beschreiben Fähigkeiten und Datenstrukturen der aktiven Produzenten und sind daher Voraussetzung für eine Ereignisdatenabfrage durch Konsumenten. In Bezug auf Bereitstellung der Daten lassen sich zwei Unterschiede feststellen: Die ALE-Middleware und GSN liefern zu einem vom Konsumenten zu spezifizierenden Produzenten Metadaten. GSN bietet aber auch, analog zu den beiden SWE-Diensten SES und SOS, eine vollständige Auflistung aller aktiven Produzenten in einem Dokument, das nach Kategorien strukturiert ist. Hier bietet SWE den umfassenderen Ansatz und stellt die nachfolgend konkretisierten Kategorien bereit [OGC-08-2]: 1. Service Identification: Allgemeine Servicebeschreibung der SWE-Instanz. 2. Operations Metadata: Spezifizierung der API durch Methoden und Transportprotokolle. 3. Filter Capabilities: Filtermöglichkeiten.

84 80 Richard Günther 4. Observation Offerings: Sensordatenangebote 4 mit Beschreibung und Spezifizierung der verfügbaren Ereignisdaten. In diese Kategorien lassen sich die Informationen der anderen Systeme einordnen, was beispielhaft für GSN gezeigt wird [GSN-1]: Info: Allgemeine Informationen zum Produzenten Teilmenge von 1. Adressing-Predicates, Wrapper: Logische Adressdaten des Produzenten Teilmenge von 4. Output Structure: Ausgabestruktur Teilmenge von 4. Processor: Daten der SQL-basierten Abfrageverarbeitung Teilmenge von 3. Die vier von SWE angebotenen Metadatenkategorien werden noch weiter aufgeteilt, in der Tiefe jedoch von keinem der anderen Systeme angeboten. Beispielsweise bieten die anderen Systeme beim Punkt 1. Service Identification nur Zeichenketten an. Für die beiden Punkte 2. Operations Metadata und 3. Filter Capabilites lassen sich keine übereinstimmenden Daten feststellen, wohl aber für Punkt 4. Observation Offerings. Teil dieser Kategorie ist die Beschreibung der Ausgabestruktur eines Produzenten, die jedes der betrachteten Systeme anbietet. Hier lässt sich die bereits in Schritt 1) der Produzentenregistrierung vorgestellte Struktur der EventTypeSets mittels verschachtelten Schlüssel-Wert-Paaren verwenden. Folgende Datenstruktur beschreibt die Metadaten eines Produzenten. Bedeutung Beispiel Input / / / Output Service Identification Allgemeine Servicebeschreibung (Funktion, Veröffentlicht Temperaturdaten), -Key / -Value / EventTypeSet EventTypeSets entsprechend (Set1, einem Ereignisdatensatz, der (Wasserstand, Ereignisdatenfelder beinhaltet ((Einheit, Meter), und die Ausgabe eines (Typ, double)), Produzenten beschreibt. (Temperatur, -EventType EventTypes entsprechen ((Einheit, Celsius), 4 SOS bietet in der aktuellen Version 1.0 das logische Gruppieren mehrerer Sensoren in einem Sensordatenangebote (Observation Offering). In der geplanten Version 2.0 soll es jedoch je Produzent ein solches Angebot geben [BEJ+11].

85 Integration ereignisbasierter Middleware-Systeme in kontextbasierte Geschäftsprozesse 81 einzelnen Ereignisdatenfeldern, die durch Schlüssel- Wert-Paare beschrieben werden. --Key / --Value / InvolvedProducer Logische Gruppierung: Die Identifikationen der beteiligten Eingabeproduzenten werden aufgelistet. -Key / -Value / (Typ, integer)), ) (id,117), (Seriennummer, 232), Tabelle 12: Datenstruktur zur Beschreibung von Fähigkeiten und Ausgabedaten aktiver Produzenten durch Konsumenten. Nachdem der Konsument einschätzen kann, ob der Produzent die gewünschten Ereignisdaten anbietet, kann er sie im nächsten Schritt abfragen. 5): Ereignisdaten abfragen (pull-modus) Abfragen, die im pull-modus gestellt werden, können sich nur auf vergangene Ereignisse, deren Werte vom System gespeichert wurden, beziehen. Ähnlich zu Abfragen an Datenbanksysteme [KE11] reicht die SQL-Syntax zur Beschreibung von Ereignisfiltern aus. Komplexe Ereignismuster hingegen beziehen sich auf zukünftige Ereignisse, werden in Verbindung mit dem publish- / subscribe-paradigma registriert und haben das Übermitteln von Ereignisdaten im push-modus zur Folge (s. Schritt 6-8). Abgesehen von der proprietären Abfragesprache der ALE-Middleware lassen sich die Abfragesprachen problemlos den drei SQL-Klauseln zuordnen. So verwenden GSN und SOS von SWE die SQL-Syntax, letztere jedoch über den Umweg der systemneutralen Kodierung mittels FES. Aufgrund der Komplexität der Selektionen im WHERE-Teil wird jede Klausel durch einen Ausdruck repräsentiert. Die Datenstruktur der Ausgabe wurde bereits im vorherigen Schritt ermittelt, sodass analog zum Veröffentlichen von Ereignisdaten in Schritt 2) übereinstimmend das korrespondierende EventDataSet zurückgegeben wird. Das Prinzip der verschachtelten Schlüssel-Wert-Paare kann eignet sich sowohl für einfache Rückgabewerte wie z.b. bei JESPA sowie komplexeren Gruppierungen z.b. bei SWE-Diensten oder der ALE- Middleware. Dazu muss nur die Anzahl der verschachtelten Ebenen angepasst werden. Nachfolgend wird, analog zu den Ereignisdaten, von zwei Ebenen ausgegangen. Die Inund Outputdaten lassen sich, wie in Tabelle 13 und Tabelle 14 gezeigt, strukturieren. Input

86 82 Richard Günther Name Bedeutung Beispiel Select Projection Datenfelder, per Name heap, oder XPath-Ausdruck Person/age, referenziert. urn:property:river1, From Input Namen der Eingabeströme, Reader13.Temperature:time(10), ggf. Zeit- offering:3, /Anzahlbegrenzung (View) Person/Alter, Where Selection SQL-basierter Filterelemente name = werner group by alter sowie Gruppie- rungs- und Sortierungselemente. Tabelle 13: Datenstruktur des Inputs einer pull-basierten Abfrage von Ereignisdaten durch Konsumenten. Output Bedeutung EventDataSet Der Ereignisdatensatz weist Zeitstempel auf, denen Ereignisdatenfelder zugeordnet sind. Die Beschreibung erfolgt durch Schlüssel- Wert-Paare, die auf zwei Ebenen verschachtelt sind. -EventData Ereignisdatenfelder werden durch Schlüssel-Wert-Paare beschrieben. --Key / --Value / Beispiel (Set1, ( _15:37:00, ((Wasserstand, 12), (Temperatur, 17)), ( _15:38:00, (Wasserstand, 10), (Temperatur, 18)), ) Tabelle 14: Datenstruktur des Outputs einer pull-basierten Abfrage von Ereignisdaten durch Konsumenten. Möchte der Konsument dagegen Ereignisanfragen an die Zukunft stellen und bei deren Auftreten benachrichtigt werden, gibt er im Rahmen eines Abonnements sein Ereignismuster an. Die entsprechende Datenstruktur zur Registrierung eines Ereignismusters wird im nächsten Schritt vorgestellt. 6): Ereignismuster abonnieren

87 Integration ereignisbasierter Middleware-Systeme in kontextbasierte Geschäftsprozesse 83 Alle betrachteten Systeme bieten eine publish-/subscribe-funktionalität und damit das Übertragen von Ereignisdaten im push-modus an, aber nur JESPA und der SES-Dienst von SWE ermöglichen die Formulierung komplexer Ereignismuster. Dafür sehen sie Esper bzw. EML vor, die beide auf der Auswertung von Ausdrücken basieren und sich auf syntaktischer Ebene nur geringfügig unterscheiden (vgl. Anhang A). Beide definieren Ereignismuster oder Eingabeströme mit Zeit-/Anzahlbegrenzungen innerhalb der FROM-Klausel und verwenden SQL-basierter Filtermechanismen im WHERE-Teil der Abfrage. Entsprechend kann die FROM-Klausel unterschiedliche Ausdrücke beinhalten, für die im Rahmen dieser Arbeit keine allgemeingültige Abstraktion gefunden werden soll. Mit Blick auf die Komplexität der Abfragen werden die Klauseln durch je eine Zeichenkette repräsentiert. Weiterhin kann der Konsument eine Identifikation des angemeldeten Abonnements erwarten, um bei mehreren registrierten Abfragen jeden Datensatz seinem entsprechenden Abonnement zuordnen zu können. Während die beiden SWE-Dienste dafür eindeutige SubscriptionIDs vergeben, kombiniert JESPA dazu ConsumerReference und Ereignismuster. GSN und EPCglobal hingegen akzeptieren Namen, die der Benutzer festlegt, und gehen also von deren Eindeutigkeit aus. Im Hinblick auf die zu erwartende Praxistauglichkeit eines derartigen Systems wird nachfolgend die Rückgabe einer SubscriptionID angenommen. Folgende Tabelle 15 beschreibt die resultierende Datenstruktur. Input Name Bedeutung Beispiel Select Projection Datenfelder, per Name oder XPath-Ausdruck referenziert. From Source Namen der Eingabeströme, anderer Ereignismuster oder Ausdrücke von Ereignismustern. Where Selection SQL-, FES- oder EML- Ausdruck. heap, Person/age, urn:property:river1, Sensor1.Temperature, SomeOtherPattern, pattern [ every a=serviceorder -> b=productorder WHERE timer:within(1 min) ], Pattern1.A BEFORE Pattern2.B ConsumerReference Kontaktmöglichkeit und Identifizierung des Konsumenten.

88 84 Richard Günther Tabelle 15: Datenstruktur eines Abonnements von Ereignismustern durch Konsumenten. Output SubscriptionID Success Bedeutung Identifikation, unter der die Middleware das Abonnement verwaltet. Gibt an, ob die Operation erfolgreich war. Beispiel True Tabelle 16: Output-Datenstruktur eines Abonnements von Ereignismustern durch Konsumenten Nachdem der Konsument angegeben hat, für welche Ereignisse er sich interessiert, erhält er diese von der Sensordaten-Middleware bei Auftreten im push-modus zugesendet. Der nächste Schritt stellt die entsprechende Datenstruktur vor. 7): Ereignisdaten empfangen Im Gegensatz zu einfachen Ereignisdaten, die im Schritt 5) an den Konsumenten gesendet werden, ist für komplexe Ereignisse mit hoher Aussagekraft nicht mehr der Auftrittszeitpunkt maßgeblich. Vielmehr werden, wie beispielsweise beim SES-Dienst von SWE, die einzelnen Ereignisdatensätze aus Schritt 5) in Bezug zueinander gesetzt oder, wie bei JESPA, durch beliebige Schlüssel-Wert-Paare beschrieben (vgl. Anhang B.1). Sofern auf die Ausrichtung nach Zeitstempeln verzichtet wird, eignet sich die bereits vorgestellte Datenstruktur aus verschachtelten Schlüssel-Wert-Paaren. Je nach Komplexität, beispielsweise um Listen von Werten darzustellen, kann eine weitere Verschachtelung erfolgen. Der Fall wird jedoch nur beispielhaft abgebildet, während im weiteren Verlauf die Verschachtelung auf zwei Ebenen beschränkt wird. Da es sich um einen asynchronen Aufruf handelt, erfolgt keine Unterscheidung in In-/Output-Daten. SubscriptionID EventDataSet Bedeutung Identifikation des Abonnements, auf das sich die Ereignisdaten beziehen. Der Ereignisdatensatz weist die in der Abfrage spezifizierten Elemente auf, denen Ereignisdatenfelder zugeordnet sind. Die Beschreibung erfolgt durch Schlüs- Beispiel (Wasserbeschaffenheit, (Wasserstand im Jahresdurchschnitt, 12), (Temperaturdurchschnitt aller Sommermonate, 26.2), (Wasserstände am 15. eines

89 Integration ereignisbasierter Middleware-Systeme in kontextbasierte Geschäftsprozesse 85 sel-wert-paare, die auf zwei jeden Monats, Ebenen verschachtelt sind. (12,11,13,11,12)), -EventData Ereignisdatenfelder werden durch Schlüssel-Wert-Paare beschrieben. --Key / --Value / Tabelle 17: Datenstruktur einer push-basierten Übertragung von Ereignisdaten an den Konsumenten. Der Konsument kann das aktive Abonnement wieder abmelden, wenn er keine weiteren Ereignisdaten erhalten möchte. Die zugehörige Datenstruktur wird im nächsten Schritt vorgestellt. 8): Abonnement abmelden Zur Abmeldung eines Abonnements reicht die Identifikation des Konsumenten (JESPA) oder die Identifikation des Abonnements (GSN, EPCglobal und SES von SWE) aus (vgl. Anhang B). Nachfolgend wird eine beliebige Identifikation des Abonnements, beschrieben durch eine Zeichenkette, als Input erwartet. Da synchrone Aufrufe verwendet werden, ist die anschließende Bestätigung obligatorisch. Bedeutung Beispiel Input SubscriptionID Identifizierung des Abonnements durch ID des Konsumenten 17 / der Ereignisab- frage Output Success Gibt an, ob die Operation True erfolgreich war. Tabelle 18: Datenstruktur Abonnement-Abmeldung vom Konsumenten. Zusammenfassend lässt sich festhalten, dass auf Grundlage des Agents and Artefacts- Paradigmas für jedes der untersuchten Sensordaten-Middleware-Systeme die angebotenen Funktionen, Protokolle und Daten aus ca Seiten Spezifikationsdokumenten extrahiert wurden. Im Anschluss wurden systemunabhängige Meta-Funktionen, -Protokolle und Daten identifiziert. Diese Beschreibungen ermöglichen eine integrierte Sicht auf die untersuchten Sensordaten-Middleware-Systeme. Im nachfolgenden Kapitel erfolgt die Zuordnung der Meta-Funktionen, -Protokolle und Daten zu den von Geschäftsprozessseite erfassten Anforderungen.

90 86 Richard Günther 3.3 Zu integrierende Aspekte von Sensordaten-Middleware- Systemen In den vorherigen Abschnitten wurden sowohl fachliche Anforderungen an die Integration von Ereignisdaten als auch technische Gemeinsamkeiten verschiedener Sensordaten- Middleware-Systeme identifiziert. Beide Sichtweisen sollen nun in Übereinstimmung gebracht werden, um eine systemneutrale, konsolidierte Repräsentation von Sensordaten- Middleware-Systemen zum Ziel der Integrationsbemühungen auf Geschäftsprozessebene zu machen. Die Anforderungen 1. Abfragen von Sensordaten und 2. Benachrichtigen bei Ereignissen (vgl. Tabelle 1) werden von den Meta-Funktionen (Tabelle 5) erfüllt. Die beiden Anforderungen 3. Auffinden und 4. Steuern von Sensoren werden vom EPCglobal- und SWE- Framework angeboten, jedoch sehr unterschiedlich realisiert. EPCglobal bezieht sich nur auf RFID-Tags und versteht unter Steuern von Sensoren das Schreiben von Werten in den Speicher der Tags. SWE hingegen stellt mit SensorML (vgl. B.4) eine vollständige Beschreibungssprache zum Ansteuern von Sensoren zur Verfügung. Das Auffinden von Sensoren realisieren beide Systeme mithilfe von Discovery- und Nameserver-Diensten, verfolgen jedoch unterschiedliche Kohäsionsziele (vgl. Kap. 2.4). Die Integration solcher Mechanismen würde den Umfang dieser Arbeit übersteigen, wird jedoch nachdrücklich als Erweiterungsmöglichkeit dieser Arbeit deklariert. Die im weiteren Verlauf erarbeiteten Erkenntnisse dürften als Grundlage dienen. Aus diesen Gründen weist Tabelle 19 die im weiteren Verlauf betrachteten Schritte 1-8 des Meta-Protokolls aus. Produzent Konsument Middleware-Systemen (vgl. Kap ) erfüllt 1 Produzent registrieren a 2 Daten veröffentlichen a 3 Produzent entfernen a 4 Metadaten abfragen a 5 Ereignisdaten per pull erhalten a 1. Abfragen 6 Ereignismuster abonnieren a 7 Ereignisdaten per push erhalten a 8 Abonnement abmelden a 9 Vorverarbeitung per Workflow spezifizieren 10 Token-Konzept Logisches Gruppieren von Sensoren Dienst zum Auffinden verteilter Sensordaten Funktionen von Sensordaten- Geschäftsprozess- Anforderungen (vgl. Kap. 3.1) Voraussetzungen für 1. und Benachrichtigen

91 Integration ereignisbasierter Middleware-Systeme in kontextbasierte Geschäftsprozesse 87 Dienst zum Auffinden verteilter 13 Sensoren r 3. Auffinden 14 Sensoren steuern r 4. Steuern Legende: Fett = übereinstimmende Funktionen Tabelle 19: Übereinstimmung zwischen sensordatenverarbeitenden Systemen und kontextbasierten Geschäftsprozessen Im vorliegenden Kapitel wurde untersucht, welche Anforderungen von Geschäftsprozessseite an die Integration von Ereignisdaten bestehen. Zusätzlich wurden die Spezifikationen vier verschiedener Sensordaten-Middleware-Systeme untersucht und eine generische Daten- und Interaktionsstruktur identifiziert, mit der alle untersuchten Systeme angesprochen werden können. Auf Grundlage dieser Integrationsleistung kann im nachfolgenden Kapitel eine Vorgehensweise zur systemunabhängigen Integration von Ereignisdaten in Geschäftsprozesse vorgestellt werden.

92 88 Richard Günther 4 Vorgehensweise zur Integration von Sensordaten- Middleware-Systemen Im vorherigen Kapitel wurden geschäftsprozessseitige Anforderungen an die Integration von Ereignisdaten von Geschäftsprozessseite identifiziert und mit den Meta-Funktionen, - Protokollen und Daten eine integrierte Sicht auf verschiedene Sensordaten-Middleware- Systeme erarbeitet. In diesem Kapitel wird deren Integration auf Geschäftsprozessebene vorgestellt. Zuerst werden thematisch verwandte Arbeiten präsentiert, um im Anschluss grundlegende Architekturentscheidungen für die Integration von Ereignisdaten auf fachlicher und technischer Ebene zu treffen. Ziel ist die Identifizierung einer Vorgehensweise zur fachlichen Modellierung von Ereignisdaten, die auch die technische Ebene einbezieht. Den Abschluss bilden einige exemplarisch modellierte Anwendungsbeispiele. 4.1 Thematisch verwandte Arbeiten Im Sinne eines ganzheitlichen Geschäftsprozessmanagements (vgl. Kap ) sollte die Integration von Ereignisdaten in Geschäftsprozesse sowohl auf fachlicher als auch technischer Ebene erfolgen. Weil die BPMN 2.0-Notation aber erst vor wenigen Monaten veröffentlicht wurde, adressieren die meisten Ansätze eine der drei in Abbildung 62 gezeigten Integrationsaufgaben. Dort steht BPMN 1.x stellvertretend für alle fachlichen Modellierungssprachen, die über keine eindeutige Ausführungssemantik verfügen. Abbildung 62: Integration von Ereignisdaten vor der Veröffentlichung von BPMN 2.0 Aufgabe 1) bezieht sich auf die Transformation von fachlichen zu technischen Modellen. Entsprechende Ansätze bieten Modelltransformationen, die mit Hilfe von Algorithmen bereits teilweise automatisch durchgeführt werden können. Mit Einführung von BPMN 2.0 sind derartige Modelltransformationen für die meisten Anwendungsbereiche jedoch obsolet geworden. Aufgabe 2) hingegen thematisiert die Modellierung von Ereignisdaten auf fachlicher Ebene, beispielsweise durch die Erweiterung der BPMN-Notation um weitere

93 Integration ereignisbasierter Middleware-Systeme in kontextbasierte Geschäftsprozesse 89 Elemente. Aufgabe 3) bemüht sich um die Einbindung von Ereignisverarbeitenden Systemen auf technischer Ebene, indem eine Sensordaten-Middleware an die Workflow-Engine angebunden wird. Um die Rolle von BPMN 2.0 für das vorliegende Integrationsvorhaben besser zu verstehen, werden nachfolgend einige Ansätze für Aufgabe 1) skizziert. Dies geschieht jedoch nur überblicksartig, weil Modelltransformationen mit BPMN 2.0 obsolet geworden sind. 1) Transformationen zwischen fachlichen und technischen Modellen Transformationsansätze von fachlichen in technische Modelle (vgl. [ODH+06, W05]) und umgekehrt (vgl. [WDG+08, SKL09]) beziehen sich auf spezifische Sprachen, sodass verschiedene Kombinationen wie z.b. BPMN-zu-XPDL oder BPEL-zu-BPMN thematisiert werden. Grundsätzlich verfügt jeder Transformationsansatz über Abbildungsvorschriften, die für ein Element der Sprache A das korrespondierende Element der Sprache B enthalten. Demzufolge wird ein Modell analysiert und rekursiv in Teil-Modelle zerlegt, bis für jedes Teil eine der vorliegenden Transformationsregeln anwendbar ist. Weil Modelle verschachtelte Strukturen aufweisen erlauben, muss zunächst mithilfe komplexer mathematischer Verfahren die Modellvalidität bestätigt werden was angesichts der fehlenden, formalen Spezifikation etablierter Modellierungssprachen wie BPMN 1.2 oder EPK problematisch ist (vgl. Diskussion in der Literatur bezüglich der Semantik des OR-Operators, u.a. [Me07]) In der Folge verstehen sich die Ansätze als Best-Practice-Lösungen, deren Resultate des Öfteren manuell nachgebessert werden sollten. Einen sprachunabhängigen Ansatz stellen Küster et al. [KH09] vor. Sie entwarfen einen Editor, der BPMN-Notationselemente in beliebige Sprachen, u.a. auch BPEL, transformiert. Voraussetzung sind stets Zuordnungsvorschriften zwischen Ausgangs- und Zielsprache. Diese Ansätze weisen jedoch keinen Bezug zu Ereignisdaten auf und werden daher nicht näher vorgestellt. Der nachfolgende Ansatz von Wieland et al. bezieht jedoch Ereignisdaten in eine solche Modelltransformation ein. EPK-Modelle zu BPEL-Workflows transformieren [WNK09, WMK+08] Grundlegende Idee ist, dass EPK-Modelle im Wesentlichen den Kontrollfluss zwischen Funktionen sowie die Reaktionen auf Ereignisse festlegen. Entsprechend schlagen sie die halb-automatische Extraktion von BPEL-Workflows sowie komplexen Ereignisabfragen aus EPK-Modellen vor. Folgende Abbildung skizziert die Vorgehensweise:

94 90 Richard Günther Abbildung 63: Vorgehensweise zur Extraktion von Workflows und komplexen Ereignis- mustern aus EPK-Modellen [WMK+08] Aus den Funktionen eines EPK-Modells wird automatisch ein abstrakter BPEL-Workflow erzeugt, während die Ereignisse extrahiert und wiederum automatisch- zu Ereignisdefini- tionen zusammengefasst werden. In Form eines technischen Reports wird die fünf Schritte umfassende Methodik vorgestellt [WMK+08]. 1. Erstellen des EPK-Modells Die EPK-Modellierung erfolgt mit einem geeigneten Werkzeug wie z.b. dem Open- Source-Werkzeug Oryx5 2. Extrahieren der Ereignisse Die per EPK modellierten Ereignisse werden extrahiert, um sie in Schritt 4 zur Formulierung komplexer Ereignismuster für Ereignisquellen (Rückgabewerte von Funktionen oder auch Sensoren) verwenden zu können. 3. Den EPK-Prozessverlauf Prozessverlauf zum BPEL-Workflow transformieren EPK-Ereignisse und Funktionen werden auf Grundlage von Transformationsmustern zu Blackbox- und Nachrichten-Aktivitäten von BPEL umgewandelt. Die Im- plementierung der Blackbox-Funktionen geschieht manuell, während die Operato- ren durch äquivalente BPEL-Konstrukte nachgebildet werden. 4. Komplexe Ereignisse definieren Aus den in Schritt 2) extrahierten, einfachen Ereignissen werden manuell komplexe Ereignismuster mit einer geeigneten Sprache wie z.b. EPL (vgl. Kap ) definiert. 5. Ausführbarkeit gewährleisten Die Blackbox-Aktivitäten müssen durch Funktionsaufrufe implementiert, interne Variablen definiert und der Datenfluss sichergestellt werden. Darüber hinaus müssen Ereignisquellen wie z.b. Rückgabewerte von Funktionen, Trigger oder Sensoren zu den korrespondieren Ereignissen aus Schritt 2) zugeordnet werden, um ein ausführbares Modell zu erhalten. Dieser Schritt wird durch einen technischen Mo- dellierer vorgenommen. 5 Siehe

95 Integration ereignisbasierter Middleware-Systeme in kontextbasierte Geschäftsprozesse 91 Die vorgestellte Methodik ordnet fachlich modellierte, komplexe Ereignisse den korrespondieren Workflows zu. Allerdings können komplexe Ereignismuster auf fachlicher Ebene nur implizit im Rahmen des Transformationsvorgangs modelliert werden. Richtig ist, dass sich EPK-Modelle besser zur Modellierung ereignisbasierter Abläufe als z.b. BPMN eignen, weil sie Ereignisse als zentrales Element zur Beschreibung von Zustandsänderungen verwenden. Allerdings existiert für EPK keine ausführbare Semantik, weswegen sich auch diese Arbeit auf best-practice-transformationsmuster von [VVK09, G-B08] stützt. Darüber hinaus wird angenommen, dass Ereignisquellen (z.b. Sensoren) der Workflow- Engine bekannt sind was eine Anpassung der Workflow-Engine an die Sensordaten- Middleware voraussetzt. Zusätzlich existiert nach wie vor die von Allweyer genannte Problematik der fachlichen und technischen Beteiligten bei der Modellerstellung, die potentiell zu fehlerhaften Modellen führt (vgl. Kap ). Den Ansätzen zur Transformation fachlicher in technische Modelle wurden kurz skizziert, obwohl sie mit BPMN 2.0 für die meisten Anwendungsbereiche nicht mehr nötig sind. Damit ergibt sich die in Abbildung 64 gezeigte Situation: Abbildung 64: Integration von Ereignisdaten nach der Veröffentlichung von BPMN 2.0 Zum Round-Trip, also der Überführung fachlicher in technische Modelle, wird eine XML- Repräsentation des fachlichen Modells um technische Details wie z.b. die Adresse eines Webservices erweitert. Letzteres kann nicht automatisch geschehen, sodass nur von einem semi-automatischen Verfahren gesprochen werden kann. Dennoch wird die eingangs genannte Lücke zwischen fachlicher und technischer Ebene mit Einführung von BPMN 2.0 geschlossen, sodass für die beiden verbliebenen Integrationsaufgaben 2) und 3) auf eine gemeinsame Notation zurückgegriffen wird. Nachfolgend werden sowohl Ansätze zur Modellierung von Ereignisdaten auf fachlicher Ebene (Aufgabe 2) sowie der Anbindung einer Sensordaten-Middleware an die Workflow-Engine (Aufgabe 3) vorgestellt. 2) Modellierung von Ereignisdaten auf fachlicher Ebene

96 92 Richard Günther Auf fachlicher Ebene besteht die Möglichkeit, das bestehende Metamodell um neue Elemente zu erweitern oder Kombinationen von bestehenden Elementen eine neue semantische Bedeutung zuzuweisen, um Ereignisdaten und muster zu modellieren. Im Sinne der Interoperabilität ist letzteres wünschenswert. Die Verwendung bestehender Notationselemente erlaubt jedoch keine explizite Modellierung von Ereignisdaten. Hintergrund ist, dass die bestehenden Prozessmodellierungssprachen wie BPMN oder EPK eine kontrollflussorientierte Sicht einnehmen, im Zuge dieses Integrationsvorhabens jedoch um einen verhaltensbasierten Ansatz erweitert werden sollen. BEMN-Notation [BDG+07, DGB07] Barros et al. haben 13 Ereignismuster identifiziert, wie z.b. das Definieren von zeitlichen Ereignisfolgen (A tritt auf, B jedoch nicht) [BGD07]. Von diesen lässt sich nur ein Bruchteil in BPMN 1.x und BPEL modellieren, sodass anschließend eine formale Syntax zum Abbilden von Ereignismustern vorgestellt wurde, mit der sich auch komplexe Ereignismuster durch Verschachtelungen abbilden lassen. Grundlage sind BPMN-Notationselemente sowie Symbole zum Verbinden von Ereignissen (AND, OR) sowie Zeit- und Datenfiltern [DGB07]. Beispielsweise lässt sich das Szenario eines Bankbetrugs, bei dem eine Zahlung ohne zugrunde liegende Rechnung eingeleitet wird, wie in Abbildung 65 gezeigt darstellen: Abbildung 65: Beispiel der BEMN-Notation zum Darstellen von Ereignismustern nach [DGB07] Immer, wenn eine ausgehende Zahlungsanweisung auftritt und keiner eingegangenen Rechnung zugeordnet werden kann, wird ein Alarm ausgelöst. Ereignismuster dieser Art können mithilfe von Ereignisbasierten Gateways (vgl. Kap. 2.2) an Prozesspfade des fachlichen Modells angebunden werden. Unklar ist allerdings, wie eine Kontext-Infrastruktur einzubinden ist [AEE+10] sowie die Frage, wie diese Elemente auf technischer Ebene verarbeitet werden sollen. Entsprechend ist bislang keine automatische Verarbeitung fachlicher Ereignismuster durch Workflow-Engines möglich. Desweiteren ist fraglich, ob die Modelle komplexer Ereignismuster dem Ziel grafischer Modelle nach Verständlichkeit

97 Integration ereignisbasierter Middleware-Systeme in kontextbasierte Geschäftsprozesse 93 noch gerecht werden. Eine Abstrahierung liefern die Autoren Kunz et al. in ihrem nachfolgend vorgestellten Ansatz. EPL-Syntax mit BPMN-Notationselementen darstellen [KFP+10] Auf Ebene von Sensordaten-Middleware-Systemen werden komplexe Ereignismuster mittels einer Event Processing Language (EPL, z.b. [Esp09]) formuliert. Die syntaktische Nähe zu SQL-Statements veranlasste die Autoren, die Klauseln Select, From und Where mit BPMN-Notationselementen darzustellen. Im Gegensatz zum BEMN-Ansatz wird darauf verzichtet, die Bedeutung der Where-Klausel zu visualisieren, da sie in Form eines formalen Ausdrucks wie z.b. XPath annotiert wird. Der Vorteil ist, dass zur Modellierung auf fachlicher Ebene bereits bestehende BPMN 2.0-Elemente verwendet werden, sodass die Prozessausführung mit jeder BPMN 2.0-konformen Workflow-Engine erfolgen kann. Die Tätigkeit der CEP-Komponente einer Sensordaten-Middleware (vgl. Kap ) wird durch die Aktivität Check Stream for Pattern modelliert, sodass sie Teil einer Workflow-Engine sein muss. Folgende Abbildung 66 zeigt den Ansatz: Abbildung 66: Ansatz zur grafischen Modellierung einer EPL-Abfrage an eine Sensordaten-Middleware [KFP+10] Die beiden Elemente Stream und Datafield entsprechen den From- und Select-Klauseln der EPL-Abfrage. Die angehängte Bedingung enthält den formalen Ausdruck der Where- Klausel. Resultieren aus der Abfrage Ereignisse, wird der im EPW gekapselte Sub-Prozess ausgeführt und optional der übergeordnete Prozessverlauf unterbrochen. Bemerkenswert ist, dass dieser Ansatz keine neuen Notationselemente einführt, sondern bestehende BPMN 2.0-Elemente verwendet, sodass auf fachlicher Ebene Interoperabilität gewährleistet wird. Die beiden vorgestellten Ansätze zur Modellierung von Ereignisdaten auf fachlicher Ebene unterscheiden sich in ihrer Aussagekraft. Die vorgeschlagene BEMN-Notation führt neue Notationselemente ein, sodass Ereignisdaten explizit modelliert werden können. Diese Erweiterung muss jedoch auf technischer Ebene nachvollzogen werden, um derartige Prozesse ausführen zu können. Somit sind die Prozesse von bestimmten Workflow-Engines

98 94 Richard Günther abhängig, was dem Ziel interoperabler Prozesse widerspricht. Der Ansatz, EPL-Statements semi-explizit mit bestehenden BPMN-Elementen zu modellieren, ermöglicht diese Interoperabilität von Prozessen allerdings lassen sich Ereignisse nur implizit modellieren. Nachfolgend werden Ansätze zur Erweiterung der Workflow-Sprache BPEL vorgestellt. Zwar stammen die Ansätze aus der Zeit vor BPMN 2.0, liefern dennoch interessante Aspekte bezüglich der Integration von Ereignisverarbeitenden Systemen in eine Workflow- Engine. 3) Integration Ereignisdatenverarbeitender Systeme auf technischer Ebene Ereignisbasierte BPEL-Erweiterung [AEE+10] Im Hinblick auf ein ereignisbasiertes Prozessverhalten schlagen von Ammon et al. folgende drei Elemente vor, um BPEL zu erweitern: Ereignis-Abonnement Das Element dient zur Verwaltung aktiver Ereignis-Abonnements von Konsumenten, wobei jedes Abonnement aus dem gewünschten Produzenten, der Abonnement-Laufzeit und dem Ereignismuster besteht. Letzteres kann durch einen beliebigen formalen Ausdruck beschrieben werden. Ereignis-Benachrichtigung Sofern Ereignisse ein Ereignismuster passieren, wird eine Benachrichtigung erzeugt. Sie beinhaltet einen Ereignisnamen sowie einen beliebig zusammengesetzten Inhalt. Letzterer kann aus mehreren Prozessvariablen gebildet werden. Ereignismuster Beschrieben werden Ereignismuster durch Ausdrücke einer beliebigen formalen Sprache wie z.b. XPath. Diese Elemente schlagen die Autoren als einen ersten Schritt in die Richtung von ereignisbasierten, ausführbaren Prozessen vor, liefern aber keine prototypische Implementierung. Context4BPEL [WKN+07, WKN08, WNL08] Im Sinne einer Erweiterung von BPEL um Ereignisdaten schlagen die Autoren Wieland et al. folgende Elemente vor: Ereignis Ereignisse werden durch eine formale Beschreibungssprache wie z.b. Esper-EPL beschrieben und können asynchron auftreten. Mit Event Handlern kann der Workflow auf ihr Eintreten reagieren. Abfrage Mit einer synchronen Abfrage kann der Workflow Ereignisdaten, die z.b. mit EPL definiert wurden, abfragen. Entscheidung Als Teil einer Anwendungslogik können Ereignisse hinsichtlich Ort, Zeit und Identifikation als Grundlage für Entscheidungsoperatoren dienen (sog. primärer Kontext, s. [GBH+05]). Beispielsweise kann ein XOR-Konnektor den ausgehenden Pfad

99 Integration ereignisbasierter Middleware-Systeme in kontextbasierte Geschäftsprozesse 95 in Abhängigkeit von der Frage, welcher Sensor zuletzt einen Wert übermittelt hat, wählen. Zusammen mit dem Smart Factory-Beispiel (vgl. Kap. 3.1) stellen die Autoren zur Anbindung einer Sensordaten-Middleware die Verwendung von Context Integration Processes vor [WKN08, WNL08]. Sie werden als Workflows definiert und kapseln den Zugriff auf die Sensordaten-Middleware, sodass der Workflow nur indirekt auf die Schnittstellen der Middleware zugreift. Die bislang vorgestellten Ansätze zeichnen sich durch die Begrenzung des Problemfelds auf fachlicher oder technischer Ebene aus. So stellen fachliche Ansätze zwar z.b. eine erweiterte Notation vor, überlassen aber die Transformation in einen Workflow sowie die Einbindung der Sensordaten-Middleware dem technischen Modellierer. Umgekehrt thematisieren einige e Ansätze die Einbindung einer Sensordaten-Middleware auf technischer Ebene, bieten jedoch keine Visualisierung und Transformation von Ereignisdaten für fach- liche Modellierer. Neben dem EPK-basierten Ansatz zum Erzeugen von Workflows aus ereignisbasierten Prozessen nehmen noch die beiden nachfolgend vorgestellten Lösungen eine sowohl fachliche als auch technische Sicht ein. vbpmn: Kontext-adaptive Workflows [DZK11, DZ11] Die Autoren Döhrig et al. stellen BPMN-Workflows vor, die zur Laufzeit flexibel auf Ereignisse reagieren können. Besonders für dynamische Bereiche mit einer großen Bandbreite möglicher Ereignisse ist die klassische Vorwegnahme aller erwarteten Ereignisse im Rahmen der Modellierung zu umständlich. Stattdessen führen sie innerhalb eines Workflows Adaptive Segmente ein, in die verschiedene, vorgefertigte Workflow-Muster eingefügt werden. Nachfolgende Abbildung 67 zeigt ein adaptives Segment: Abbildung 67: Adaptives Workflow-Segment, in das verschiedene Workflow-Muster einauf Grundlage der Kontextinformationen. Die nachfolgende Form beschreibt den Aufbau der Business gefügt werden können nach [DZK11] Welches Muster eingefügt wird, entscheiden Business Rules Rules: ON entry-event IF <data-context> THEN APPLY <pattern( segment, parameters )>

100 96 Richard Günther Natürlichsprachig beschrieben entscheiden sie bei Aktivierung des vorherigen Sequenzflusses, welches Muster in Abhängigkeit von den Kontext-Daten auszuführen ist. Beispielsweise kann eine zusätzliche Aufgabe eingefügt werden, wenn die Kontextdaten einen zusätzlichen Bedarf ausweisen. Bislang wurden Workflow-Muster für Änderungs-, Zeitund Ausnahmebehandlungen erstellt. Allerdings umfassen die Kontextinformationen keine komplexen, sondern nur einfache Ereignisse. vbpmn erweitert das BPMN-Metamodell, z.b. um die in Abbildung 67 gezeigten Notationselemente. Außerdem geht es davon aus, dass die (einfachen) Ereignisse bereits Teil der Workflow-Engine sind. Während kontext-adaptive Workflows klar das Feld der Geschäftsprozessmodellierung adressieren, zeigen die nachfolgend vorgestellten, kommerziellen Tools interessante Möglichkeiten zur grafischen Modellierung von Ereignisdatenverarbeitungen auf. Kommerzielle Tools Losgelöst von der klassischen Geschäftsprozessmodellierung bieten verschiedene, teilweise proprietäre und monolithische Lösungen die Extraktion von komplexen Ereignisdaten aus dem täglichen Datenaufkommen eines Unternehmens. Diese Tools erlauben das Modellieren von Ereignisfiltern mit einer grafischen Oberfläche. Grundlage ist dabei die CEP- Komponente, die jede Sensordaten-Middleware aufweist (vgl. Kap. 3.1). Der jährlich veröffentlichte Magic Quadrant des Marktforschungsunternehmens Gartner Research vergleicht zwischen den verschiedenen Herstellern die Reife der zugrundeliegenden Vision sowie ihre Fähigkeit, diese Vision am Markt durchzusetzen [SHR+10]. Gemäß dieser Einschätzung sind die Lösungen von TIBCO, IBM, SyBase, StreamBase und weiteren (z.b. Progress Apama 6 ) führend. Sie bieten das grafische Formulieren von komplexen Ereignismustern an, was exemplarisch für das Produkt Aleri Studio von SyBase (ehem. Coral 8) gezeigt wird. Eine ablauforientierte Sicht beschreibt die Transformation der Daten durch verschiedene, hintereinander geschaltete Filter- oder Verarbeitungsfunktionen. Die Verarbeitung von Input-Daten mittels eines Filters sowie eines Patterns kann in Aleri Studio, wie in Abbildung 68 gezeigt, modelliert werden: 6 Siehe (Zugriff am )

101 Integration ereignisbasierter Middleware-Systeme in kontextbasierte Geschäftsprozesse 97 Abbildung 68: Kombination eines Filters und Ereignismusters mit dem CEP-Tool Aleri Studio Die Input-Daten beinhalten die Felder Symbol, Price, Shares und TradeTime. Der Filter selektiert alle, deren Symbolname IBM entspricht, während das Ereignismuster jede Sekunde eine bestimmte Ereigniskombination prüft. Letztlich bieten diese Systeme jeweils eigenständige Lösungen, die sich auch in Geschäftsprozesse integrieren lassen allerdings an die jeweils proprietäre Sensordaten-Verarbeitungskomponente gebunden, was dem Ziel dieser Arbeit von modular austauschbaren Komponenten widerspricht. Unter Berücksichtigung der bis vor kurzem bestehenden Lücke zwischen fachlicher und technischer Modellierung wurden die verschiedenen Integrationsansätze auf fachlicher und technischer Ebene vorgestellt. Auf fachlicher Ebene wurde zwischen expliziten und impliziten Ereignismodellierungen unterschieden. Erstere erfordern eine Erweiterung der BPMN-Notation und binden auf technischer Ebene den Prozess an eine angepasste Workflow-Engine, während letztere die mit BPMN 2.0 gewonnene Interoperabilität zwischen BPMN 2.0-konformen Prozessen und Workflows erhält. Auf technischer Ebene wurden Ansätze zur Erweiterung der Workflow-Sprache BPEL um ereignisbasierte Konstrukte vorgestellt. Den Abschluss bildeten kontext-adaptive Workflows, mit denen in Abhängigkeit von Ereignisdaten verschiedene Workflow-Muster ausgeführt werden, sowie das Modellieren von Ereignisdatenverarbeitungen mit kommerziellen Tools. Mit Einführung von BPMN 2.0 müssen nur noch die beiden folgenden Integrationsaufgaben gelöst werden: 1. Ereignisdaten sollen auf fachlicher Ebene modelliert und auf technischer Ebene von einer Workflow-Engine ausgeführt werden können. 2. Eine Sensordaten-Middleware soll an die Workflow-Engine angebunden werden.

102 98 Richard Günther An einigen Stellen wurde deutlich, dass ein Konflikt zwischen der Erweiterung der BPMN- Notation und der Interoperabilität von Prozess und Workflow-Engine besteht. Im nachfolgenden Abschnitt werden diesbezüglich grundlegende Entwurfsentscheidungen getroffen. 4.2 Entwurfsentscheidungen Im vorherigen Abschnitt wurden drei Integrationsaufgaben identifiziert, von denen eine bereits von BPMN 2.0 gelöst wird. Für die verbleibenden Aufgaben - Integration von Ereignisdaten auf fachlicher und technischer Ebene - wurden verschiedene Ansätze vorgestellt. Den Abschluss bildete die exemplarische Betrachtung eines kommerziellen CEP- Tools, mit dem beliebige Kombinationen von Ereignisdatenverarbeitungen mit proprietären Notationselementen modelliert werden können. Nach diesem Überblick des aktuellen Stands in Literatur und Forschung, sollen nun grundlegende Entwurfsentscheidungen den Weg für die Integration von Ereignisdaten in BPMN 2.0-basierte Prozesse ebnen. Konkret geht es um folgende zwei Aufgaben (vgl. Abbildung 64): 1. Technische Ebene: Interoperabilität mit einer Sensordaten-Middleware Die untersuchten Sensordaten-Middleware-Systeme weisen verschiedene Schnittstellen auf, für die bereits in Kapitel einheitliche Meta-Schnittstellen identifiziert wurden. Fraglich ist, wie die Kommunikation zwischen Workflow-Engine und Sensordaten-Middleware organisiert werden soll. 2. Fachliche Ebene: Modellierung von Ereignisdaten und abfragen BPMN dient zur ablauforientierten Beschreibung von Prozessen, soll jedoch um einen ereignisbasierten Verhaltensansatz erweitert werden. Dazu könnten neue Notationselemente eingeführt oder bestehende Elemente semantisch überladen werden. Für die erste Aufgabe wurde im vorherigen Kapitel mit Spezifizierung der Meta- Funktionen, -Protokolle und Daten bereits eine Basis zur technischen Integration geschaffen (vgl. Kap. 3.2). Allerdings stellt sich die Frage, wie die Anbindung einer Sensordaten- Middleware erfolgen soll. Hintergrund ist, dass weder Sensordaten-Middleware-Systeme noch Workflow-Engines über einheitliche Schnittstellen verfügen (vgl. Kap. 3.2), weil dieser Aspekt nicht Teil der BPMN-Spezifikation ist. Entsprechend unterscheiden sich beispielsweise die beiden Open-Source Workflow-Engines Activiti und jbpm: Erstere bietet eine REST-API 7 an, während jbpm nur interne Zugriffsmöglichkeiten bereitstellt 8. Eine Lösung bieten invasive und nicht-invasive Ansätze, wobei Invasivität häufig im medizinischen / biologischen Sprachgebrauch vorkommt, im Zusammenhang dieser Arbeit jedoch wie folgt verstanden wird: 7 Siehe 8 Siehe

103 Integration ereignisbasierter Middleware-Systeme in kontextbasierte Geschäftsprozesse 99 Invasivität. Das bestehende System wird um neue Elemente erweitert. Daraus resultierende Verbesserungen führen zur Bildung spezifischer Unter-Klassen, die jedoch zu eingeschränkter Interoperabilität mit anderen Systemen führen kann. Nach [A03, LSV05]. Letztere hat ihren Ursprung im militärischen Sprachgebrauch, ist aber schon lange im Bereich der Softwarearchitektur etabliert, und wird im Zusammenhang dieser Arbeit mit folgender Bedeutung verwendet: Interoperabilität. Die Fähigkeit verschiedener IT-Systeme, im Rahmen einer Zusammenarbeit untereinander Services anzubieten, in Anspruch zu nehmen und allgemein miteinander zu kommunizieren. Nach [Dod05, PP04, B04]. Interoperabilität wird häufig durch eine Menge von Funktionen und Protokollen determiniert, die alle beteiligten Systeme unterstützen. Entsprechend liegt es nahe, austauschbare Systeme zu betrachten: Austauschbarkeit. Unter Erhaltung der Interoperabilität können beteiligte IT-Systeme ausgetauscht werden. Der gemeinsame Funktionsumfang muss weiterhin angeboten werden, was bei invasiven Erweiterungen mit zusätzlichem Aufwand einhergeht. Nach [RH08, HGR+06] Ein auf technischer Ebene invasiver Ansatz wäre also die Erweiterung der Workflow- Engine oder Sensordaten-Middleware, um mit dem jeweils anderen System zu kommunizieren. Ein nicht-invasiver Ansatz hingegen sieht die Verwendung eines Proxy als Vermittler zwischen den Systemen vor [SS07]. Folgende Abbildung 69 skizziert die Ansätze: Abbildung 69: Invasive und nicht-invasive Ansätze zur Integration einer Sensordaten- Middleware auf technischer Ebene

104 100 Richard Günther Die ersten beiden Ansätze stellen die Interoperabilität durch invasive Erweiterungen sicher, was mit einem Verlust der Austauschbarkeit einhergeht. In der dritten Variante hingegen bleibt die Austauschbarkeit sowohl von Workflow-Engine als auch Sensordaten- Middleware erhalten. Das ist grundsätzlich wünschenswert und dank der in Kap. 3.2 spezifizierten Meta-Schnittstellen umsetzbar. Soll künftig eine der beiden Komponenten ausgetauscht werden, muss lediglich der Proxy angepasst werden. Dieses Prinzip der Kapselung von Anwendungslogik ist charakteristisch für das objektorientierte Paradigma aktueller Software-Architektur [RH08]. Aus diesen Gründen wird auf technischer Ebene die Verwendung eines Proxy (Ansatz 3) gewählt. Im Anschluss ist die zweite Aufgabe der Integration von Ereignisdaten auf fachlicher Ebene zu betrachten. Wiederum lassen sich invasive und nicht-invasive Ansätze unterscheiden. Der in Abbildung 70 gezeigte Entscheidungsbaum verdeutlicht die Situation: Abbildung 70: Invasive und nicht-invasive Integration von Ereignisdaten auf fachlicher Ebene Beide Varianten ziehen Konsequenzen nach sich. Die Erweiterung der BPMN-Notation setzt voraus, dass die Workflow-Engine erweitert oder ein Präprozessor eingebunden wird. Die Modellierung von Ereignisdaten mit den vorhandenen Elementen kann hingegen nur implizit geschehen, da BPMN nicht für die Beschreibung ereignisbasierter Systeme konzipiert wurde. Folgende Abbildung 71 zeigt notwendige Erweiterungen für die beiden Ansätze aus Perspektive der Datenverarbeitung während eines Round-Trips.

105 Integration ereignisbasierter Middleware-Systeme in kontextbasierte Geschäftsprozesse 101 Abbildung 71: Invasive und nicht-invasive Varianten zur Integration von Ereignisdaten auf fachlicher Ebene mit ihren Auswirkungen auf den Round-Trip Die invasiven Varianten 4-a) und 4-b) gehen von explizit modellierten Ereignisdaten aus. Dafür müsste BPMN um spezifische Elemente erweitert werden, wie es beispielsweise Barros et al. in ihrem BEMN-Ansatz vorschlagen (vgl. Kap. 4.1). Infolgedessen ist entweder ein Präprozessor (4-a) oder eine Erweiterung der Workflow-Engine (4-b) notwendig, um die spezifischen BPMN-Notationselemente weiterverarbeiten zu können. Auf B, der Proxy, kann dennoch nicht verzichtet werden, weil die verschiedenen Workflow-Engines den Sensordaten-Middleware-Systemen keine einheitlichen Schnittstellen anbieten. In der nicht-invasiven Variante 5) werden Ereignisdaten nur implizit modelliert, wie es beispielsweise Kunz et al. mit ihrer grafischen Modellierung der EPL-Syntax vorschlagen (vgl. Kap. 3.3). Weil nur standardkonforme BPMN-Elemente verwendet werden, ist keine Erweiterung nötig. Im Grundsatz besteht ein Zielkonflikt zwischen der Austauschbarkeit und einer expliziten Ereignismodellierung. Entsprechend kann für beide Aspekte argumentiert werden. Austauschbarkeit. Richtig ist, dass die explizite Ereignismodellierung als ein Ziel dieser Arbeit zu sehen ist. Der inhärente Nachteil, nämlich der Verlust von Austauschbarkeit, ist jedoch auch im Hinblick auf den Nutzen für Anwender zu betrachten. Die meisten Unternehmen planen ihre Geschäftsinfrastruktur nicht komplett neu from the scratch, sondern möchten den ereignisbasierten Ansatz lediglich integrieren. Infolgedessen werden Lösungen, die kompatibel zur bestehenden Infrastruktur sind, deutlich häufiger eingesetzt. Als Gegenbeispiel lassen sich viele der in Kap. 3.3 vorgestellten, spezifischen Lösungsansätze anführen. Sie behandeln einen Teilaspekt der Frage, wie Ereignisdaten fachlich oder technisch eingebunden werden könnten und stellen Lösungen vor, die den Anwender zwingen, weitreichende Veränderungen an bestehenden Systemen vorzunehmen oder Komponenten wie z.b. die Workflow-Engine komplett auszutauschen. Viel sinnvoller ist dagegen