Architektur von Workflow-Management-Systemen

Größe: px
Ab Seite anzeigen:

Download "Architektur von Workflow-Management-Systemen"

Transkript

1 Informatik Forsch. Entw. (1997) 12: Springer-Verlag 1997 Architektur von Workflow-Management-Systemen Stefan Jablonski Institut für Mathematische Maschinen und Datenverarbeitung (Informatik), Friedrich-Alexander-Universität Erlangen-Nürnberg, Martensstraße 3, D Erlangen ( Eingegangen am 23. August 1996/Angenommen am 4. Februar 1997 Zusammenfassung. Der Begriff Architektur wird im Bereich Workflow-Management sehr unterschiedlich interpretiert, weshalb eine Diskussion über Architekturen von Workflow-Management-Systemen nur sehr schwer möglich ist. Dieser Beitrag stellt deshalb drei zu beobachtende Interpretationen des Architekturbegriffs vor und erläutert deren Bedeutung. Schwerpunktmäßig wird daran anschließend die Interpretation des Architekturbegriffs aus Sicht einer Implementierung näher diskutiert, welche als die wesentliche angesehen wird. Ein Phasenmodell zur Entwicklung einer Architektur eines Workflow-Management-Systems und ein Schichtenmodell eines Workflow-Management-Systems im Sinne einer Abstraktionshierarchie werden abschließend vorgestellt. Schlüsselwörter: Workflow-Management, Software-Architektur, Middleware Abstract. The notion architecture is interpreted manifold in the workflow management area. Therefore, the discussion of architectures for workflow management systems is difficult. This article introduces three different interpretations of the notion architecture. In detail, the implementation-oriented interpretation of architecture is presented which is considered to be most important. A phase model for the development of a workflow management system architecture and a layered design model of a workflow management system are shown finally. Key words: Workflow management, software architecture, middleware CR Subject Classification: H.1.0, H.4.1, J.1 Einleitung Diskussionen im Bereich Workflow-Management werden häufig dadurch erschwert, daß die Vorstellungen über den Inhalt und den Aufbau eines Workflows (d.h. eines Workflow-Modells) beziehungsweise eines Workflow-Management-Systems eine beinahe beliebige Bandbreite annehmen. Diese unbefriedigende Situation beruht vor allem darauf, daß in den letzten Jahren eine Unmenge von kommerziellen Workflow-Management- Systemen und Forschungsprototypen entwickelt worden sind, welche mehr einer how I did it -Philosophie folgen, als sich an einer fundierten theoretischen Basis zu orientieren. Es ist selten ein Gebiet der Informatik binnen so kurzer Zeit mit einer solchen Menge von Systemen überschwemmt worden, wie es seit einiger Zeit im Bereich Workflow-Management zu beobachten ist. Dieser Beitrag erhebt nicht den Anspruch, die fehlende theoretische Basis für das Gebiet Workflow-Management zu liefern; er will auch nicht einen weiteren Architekturvorschlag für Workflow-Management-Systeme beisteuern. Ziel dieses Beitrags ist es vielmehr, eine Konsolidierung der vielen verschiedenen Architekturvorschläge vorzunehmen. Ausgehend von diesen Vorschlägen, welche auf jeweils spezifischen Anforderungen, Erfahrungen und Erkenntnissen beruhen, soll ein allgemeines Konzept einer Basisarchitektur vorgestellt werden. Aufgrund der vorgegebenen Kürze wird in diesem Beitrag nicht ein kompletter Architekturvorschlag gemacht; ein solcher kann in [9] ausführlich studiert werden. Aufgabe dieses Beitrags ist vielmehr, die Kriterien einer angemessenen Architektur für Workflow-Management-Systeme zu diskutieren. Dies soll dem Leser insbesondere ein besseres Verständnis für Architekturen von Workflow-Management-Systemen vermitteln; darüber hinaus soll er befähigt werden, verschiedene Architekturvarianten miteinander zu vergleichen und zu bewerten. Die Schwierigkeit der Diskussion einer allgemeinen Basisarchitektur liegt schon darin, daß der Begriff Ar-

2 73 chitektur sehr unterschiedlich interpretiert wird. In der Literatur lassen sich zumindest drei Perspektiven identifizieren, aus welcher der Architekturbegriff betrachtet wird. Systeminfrastruktur Aus Perspektive einer Systeminfrastruktur entspricht ein Workflow-Management-System einem sogenannten Framework, welcher dem Bereich der Middleware zuzuordnen ist. Die Architektur des Frameworks Workflow-Management ist demzufolge zu diskutieren. Benutzer Der Benutzer interpretiert die Architektur eines Workflow-Management-Systems als die Anordnung von Werkzeugen, welche ihm zur Modellierung und Ausführung von Workflows angeboten werden. Diese Werkzeuge gruppieren sich um ein Kernsystem, welches die Basisfunktionalität eines Workflow-Management-Systems erbringt. Implementierung Aus der Sicht der Implementierung eines Workflow- Management-Systems stellt sich ein solches als eine Menge von Modulen (Komponenten) zusammen mit gegenseitigen Beziehungen dar, welche die Funktionalität eines Workflow-Management-Systems realisieren. Obwohl die Interpretationen aus Sicht der Systeminfrastruktur beziehungsweise der Benutzer zweifelsohne von großem Wert sind, halten wir die Implementierungssicht für die wesentliche, weshalb diese in unseren Augen auch die eigentliche Architektur eines Workflow-Management-Systems konstituiert; sie wird in den Kapiteln 4 und 5 eingehend diskutiert. Aufgrund ihrer häufigen Verwendung werden allerdings auch die beiden anderen Sichtweisen in diesem Beitrag behandelt. Kapitel 2 erläutert Workflow-Management als Framework im Bereich der Middleware; Kapitel 3 stellt ein Workflow-Management-System aus der Perspektive eines Benutzers vor. Abschließend ordnet Kapitel 6 den Architekturvorschlag der Workflow Management Coalition den in diesem Beitrag eingeführten Klassifikationsschemata zu. 2 Workflow-Management als Framework im Bereich der Middleware Bernstein bezeichnet in [1] Middleware-Dienste als solche Dienste, welche zwischen einer sogenannten Systemplattform und den Anwendungen lokalisiert sind. Eine Systemplattform wird dabei gebildet durch die Systemhardware und das Betriebssystem. Dienste der Middleware müssen sowohl systemplattform- als auch anwendungsunabhängig sein. Middleware-Dienste müssen generisch für verschiedenartige Systemplattformen und Anwendungsgebiete sein. Sie sind in einer verteilten Systemumgebung einsetzbar und unterstützen standardisierte Schnittstellen und Protokolle. Abb. 1. Architektur eines Frameworks Frameworks sind gemäß [1] Softwareumgebungen, welche dazu dienen, Anwendungen effektiv und effizient entwickeln zu können. Ein Framework ist charakterisiert durch eine Schnittstelle, an welcher seine Funktionalität angeboten wird (API), eine Benutzerschnittstelle und eine Menge von Werkzeugen. Frameworks basieren auf allgemeinen Middleware-Diensten und können darüber hinaus spezialisierte Middleware-Dienste zur Verfügung stellen (vgl. Abb. 1). Auch Workflow-Management kann als Framework verstanden werden. TP-Monitore, welche Transaktionsdienste zur Verfügung stellen, Resource-Manager für sowohl Dateisysteme, relationale Datenbanken als auch Warteschlangen, Object-Broker-Dienste und Kommunikationsdienste (u. a. RPC) sind Middleware- Dienste, die in der Regel von einem Framework Workflow-Management benötigt werden. Dienste, welche darüber hinaus von einem Workflow-Management-System aufgebaut werden sind beispielsweise Kontrollflußsteuerung, Datenflußsteuerung, Auflösung organisatorischer Zuordnungsstrukturen, Historienverwaltung und Applikationsintegration. Daneben stellt das Framework Workflow-Management Werkzeuge zur Verfügung. In Kapitel 3 werden beispielhaft einige Werkzeuge vorgestellt (u. a. Arbeitsliste, Ablaufmonitor ). Oftmals wird die Architektur des Frameworks Workflow-Management mit der Architektur eines Workflow- Management-Systems verwechselt. Beide Betrachtungsweisen sind aber nicht deckungsgleich. Der konzeptionelle, architekturbezogene Aufbau eines Workflow-Management-Systems kommt bei einer Framework-Darstellung nicht hervor. Allerdings vermittelt diese Betrachtung eines Workflow-Management-Systems interessante Erkenntnisse über die Verbindung von Workflow-Management-Systemen zu Diensten einer Middleware.

3 74 3 Workflow-Management-Systeme als Werkzeugkasten für die Benutzer Tabelle 1. Zuordnung von Werkzeugen zu Benutzergruppen Systemverwalter Modellierungsphase Editor, Browser, Übersetzer, Debugger Ausführungsphase Ablaufmonitor Aus Sicht der Benutzer (Programmierer, Endanwender, Administratoren und Systemverwalter) bilden die Werkzeuge eines Workflow-Management-Systems zusammen mit dem eigentlichen Kernsystem Strukturierungskriterien einer Architektur. Die Verfügbarkeit von Werkzeugen in den verschiedenen Phasen eines Systementwicklungszyklus und die Anordnung beziehungsweise Integration dieser Werkzeuge sind den Benutzer interessierende Fragestellungen. Eine Architektur in diesem Sinne basiert auf einem Kernsystem, welches die Funktionalität eines Workflow-Management- Systems zur Verfügung stellt, und einer Reihe von Werkzeugen, die um diesen Kern gelagert sind, um den Benutzern an- oder verwendungsbezogene Funktionenbündel anzubieten. Demzufolge ist es angebracht, in diesem Kontext von der Werkzeugsicht eines Workflow-Management-Systems zu sprechen anstatt von seiner Architektur. Man könnte diese Sicht auch als die Konfiguration eines Workflow-Management-Systems aus Perspektive der Benutzer bezeichnen. In Übereinstimmung mit der Mehrzahl aller Workflow-Management-Systeme können zwei Phasen der Systembenutzung unterschieden werden: die Modellierungs- und die Ausführungsphase [10]. Während der Modellierungsphase werden Workflow-Schemata erstellt, wobei ein Workflow-Schema einer Ablaufbeschreibung auf Typebene entspricht. Ein solches Schema wird in der Ausführungsphase instantiiert, um konkrete Workflows, d.h. Abläufe, zu realisieren. Im Anwendungsfeld Workflow-Management sind mehrere Benutzergruppen zu unterscheiden. Workflows werden von Programmierern definiert. Endanwender führen Workflows aus. Administratoren überwachen die Ausführung von Workflows, stellen Analysen an und versuchen Abläufe zu optimieren. Systemverwalter sind für die Installation und Konfiguration eines Workflow-Management-Systems verantwortlich. Jeder Benutzergruppe (Programmierer, Endanwender, Administratoren, Systemverwalter) müssen bestimmte Werkzeuge zur Verfügung gestellt werden, welche sie bei der Ausführung ihrer Tätigkeiten unterstützen. Allgemein gesprochen entspricht ein Werkzeug einer bestimmten Konfiguration, Anordnung oder auch Bündelung von Funktionen am API eines Workflow- Management-Systems (vgl. Kapitel 2). Beispielsweise werden Funktionen zum Bearbeiten von Workflow-Instanzen im Werkzeug Arbeitsliste zusammengebunden, so daß ein Endanwender auszuführende Workflows bearbeiten kann. Nachfolgende Tabelle gibt einen Überblick über Werkzeuge, welche jeweils zur Modellierungs- bzw. Ausführungsphase eines Workflow-Management-Systems den Benutzergruppen zur Verfügung gestellt werden müssen. Die Aufzählung von Werkzeugen in Tabelle 1 erhebt keinen Anspruch auf Vollständigkeit. Allerdings werden die wesentlichsten Werkzeuge identifiziert. [9] bietet einen umfassenden Überblick über nützliche und gebräuchliche Werkzeuge, welche im Bereich Workflow- Management eingesetzt werden. 4 Anforderungen an die Architektur eines Workflow-Management-Systems Die wesentliche Aufgabe einer Systemarchitektur besteht darin, eine bestimmte Funktionalität umzusetzen bzw. zu erbringen. Die Kunst bzw. der Stil einer Modulzerlegung unter Berücksichtigung der (an eine Architektur) gestellten Anforderungen eine solche Funktionalität effektiv und effizient umzusetzen, wird als der Gegenstand einer Architektur betrachtet. Im Vorfeld der Definition einer Architektur müssen zwei Fragen beantwortet werden. Die erste Frage zielt auf das was ab, d.h. auf die zu implementierende Funktionalität. Im Kontext Workflow-Management kann diese vom Inhalt eines Workflow-Modells abgeleitet werden. Ein Workflow-Modell beschreibt die konstitutiven Eigenschaften eines Workflows (Kapitel 4.1). Im Rahmen der Umsetzung einer Architektur spielt auch die Frage nach dem wie eine entscheidende Rolle. Sie kann beantwortet werden, wenn der anwendungsspezifische Kontext einer Implementierung und Anforderungen an eine spätere Implementierung beschrieben werden. Hinweise auf typische Benutzerprofile, Angaben über mögliche Benutzerzahlen oder Anforderungen bezüglich Zuverlässigkeit und Verfügbarkeit sind hier zu diskutieren. Kapitel 4.2 widmet sich solchen Fragestellungen. 4.1 Workflow-Modell Ziel dieses Beitrags ist die Beschreibung einer allgemeinen Architektur von Workflow-Management-Systemen. Daher ist es auch notwendig, das zugrundeliegende Workflow-Modell so allgemein wie möglich einzuführen. Zur Beschreibung eines Workflow-Modells auf Ebene seiner konstitutiven Elemente kann man von einem Strukturmodell eines Workflows ausgehen. Ein solches Strukturmodell kategorisiert die wichtigsten Bestandteile eines Workflows. In diesem Beitrag orientieren wir uns an dem in [8] bzw. [9] vorgegebenen Strukturkonzept, welches die essentiellen Strukturelemente eines Workflow-Modells enthält. Es ist entwickelt worden im Zusammenhang mit der Konzipierung und Imple- Programmierer Endanwender Administrator Simulator, Animator, Typ-Organisator Konfigurator Arbeitsliste Ablaufmonitor, Analysator Ablaufmonitor, Konfigurator

4 75 mentierung des Workflow-Management-Systems MO- BILE. Es stellt aber keine Spezialentwicklung dar, sondern baut auf Konzepten auf, welche unter anderem bereits in benachbarten Forschungsbereichen (z. B. Software Process Modeling [5], Enterprise Modeling [19]) erfolgreich verwendet worden sind. Es sollte daher leicht möglich sein, diese allgemeinen Strukturelemente auf konkrete Ausprägungen einzelner Workflow-Management-Systeme herunterzubrechen (z. B. COSA [3], FlowMark [6], WorkParty [21]). Das allgemeine Strukturkonzept orientiert sich nach einzelnen Aspekten, welche in ihrer Gesamtheit einen Workflow ausmachen. Einige Aspekte werden hier beispielhaft vorgestellt; eine ausführliche Diskussion muß an dieser Stelle entfallen. Es sei auf die zitierte Literatur verwiesen. Der funktionale Aspekt beschreibt die funktionalen Ausführungseinheiten eines Workflows, welche zugleich die Rahmenstruktur bilden. Zwischen elementaren und kompositen Workflows kann unterschieden werden. Der verhaltensbezogene Aspekt eines Workflows konstituiert den Kontrollfluß zwischen einzelnen Workflows. Der zwischen Workflows zu realisierende Datenfluß wird im datenbezogenen Aspekt beschrieben. Organisatorische Zuordnungen, beispielsweise von Personen, welche einen Workflow ausführen sollen, werden vom organisatorischen Aspekt abgedeckt. Schließlich wird unter dem operationalen Aspekt die Einbindung von Applikationen in einen Workflow diskutiert. Neben diesen fundamentalen, für jedes Workflow- Management-System obligatorischen Aspekten sind Erweiterungen vorstellbar. Beispielsweise kann ein spezieller Sicherheitsaspekt eingeführt werden, wenn spezifische Anforderungen an die Sicherheit einer Workflow- Ausführung gestellt werden [9]. 4.2 Anforderungen Anwendungsbezogene Anforderungen. Oftmals wird die Entwicklung eines Workflow-Management-Systems unter falschen Prämissen betrieben. Workflow- Management-Systeme (sollten) leben von ihrer Flexibilität, in verschiedensten Anwendungsgebieten eingesetzt werden können. Die Breite dieses Einsatzes wird bereits daran erkennbar, daß Workflow-Management zur Middleware gerechnet wird (vgl. Kapitel 2). Ein breites Einsatzspektrum ist eines der wesentlichen Charakteristika einer Middleware-Technologie. Aufgrund neuer Einsatzgebiete von Workflow-Management-Systemen ist damit zu rechnen, daß die Funktionalität eines Workflow-Management-Systems erweitert werden muß. Das führt zur Erweiterung des dazugehörigen Workflow-Modells (vgl. Kapitel 4.1). Dies wiederum bedingt, daß dem Workflow-Management- System neue Komponenten hinzugefügt beziehungsweise bestehende Komponenten ausgetauscht werden müssen. Ein fest verdrahtetes, monolithisch aufgebautes System würde einer solchen Anforderung nicht genügen. Neue Einsatzbereiche führen auch dazu, daß immer öfter sogenannte Altsysteme ( legacy systems ) in den Workflow-Ablauf integriert werden müssen. Offenheit des Workflow-Modells beziehungsweise des Workflow- Management-Systems ist daher notwendig, um dieser Anforderung zu genügen. Workflows beschreiben Anwendungsprozesse, welche sich in der Regel über die Zeit ändern werden. Dynamische Anpaßbarkeit von Workflows an neue Anwendungssituationen, Versionsverwaltung und Konfigurationsmanagement werden gefordert, um diese Dynamik verwalten zu können. Es ist allgemein anerkannt, daß sich Workflow-Management-Systeme vor allem für solche Anwendungsgebiete eignen, welche relativ einfach strukturierte Anwendungsprozesse umfassen, denen ein hoher Repetitionsgrad zu eigen ist. Da die Anzahl der gleichzeitig auszuführenden Workflow-Instanzen in die Hunderte oder sogar in die Tausende gehen kann, ist Skalierbarkeit ein weiteres Kriterium Systembezogene Anforderungen. Die Anforderung nach Beherrschung einer verteilten und heterogenen Plattform ist ebenso auf die Breite des Einsatzgebietes eines Workflow-Management-Systems zurückzuführen. Dies ist sicherlich auch mit ein Grund, Workflow-Management im Sinne eines Frameworks auf allgemeine Middleware-Dienste zu basieren. Eine im Bereich Workflow-Management wichtige Anforderung bezieht sich auf die Zuverlässigkeit des Ausführungssystems. Fehlerfälle sind bei der Ausführung von Workflows leicht möglich, alleine schon deshalb, weil Workflow-Ausführungen sich in den Bereich von Stunden, Tagen und Wochen ziehen können. Eine einfache Transaktionssemantik, d. h. beispielsweise das Rücksetzen auf einen konsistenten Anfangspunkt einer Workflow-Ausführung, ist nicht anwendbar, da hierdurch zu viel bereits erfolgte Arbeit verloren gehen würde. Semantisch reichere Fehlerbehandlungsmodelle sind hier gefragt. Um ein Workflow-Management-System in einem möglichst breiten Feld einsatzfähig zu machen, muß die Implementierung eines Workflow-Management-Systems portabel sein. Wiederum kann das Aufsetzen auf allgemeinen Diensten einer Middleware-Schicht bei der Erfüllung dieser Anforderungen nützlich sein. Weitere, eigentlich für eine jede Implementierung geltende Anforderungen müssen an dieser Stelle noch genannt werden. Wartbarkeit und Korrektheit seien beispielhaft erwähnt. Sie sind aber mehr allgemein gültig und weniger charakteristisch für ein Workflow-Management-System. Daher kann auf eine weitere Diskussion dieser Anforderungen hier verzichtet werden Resümee. Nach der Aufzählung der verschiedenen Anforderungen an ein Workflow-Management-System stellt sich die Frage nach deren Umsetzbarkeit. In Anlehnung an [12, 13, 15] kann die Modularität eines Softwaresystems, in diesem Falle eines Workflow-Management- Systems, als eine notwendige Voraussetzung für die Umsetzung obiger Anforderungen identifiziert werden.

5 76 Neben der Modularität betrachten wir auch die Orthogonalität als ein wesentliches Entwurfskriterium bei der Gestaltung von Workflow-Management-Systemen. Orthogonalität definieren wir in diesem Kontext als die Eigenschaft, daß bei n gegebenen Sachverhalten kein Sachverhalt aus Zusammenstellung der restlichen n-1 Sachverhalte gewonnen werden kann. Angewandt auf das Gebiet Workflow-Management bedeutet dies beispielsweise, daß der Kontrollfluß nicht aus dem Datenfluß, aus dem funktionalen Aspekt oder aus einer Kombination dieser beiden Sachverhalte gewonnen werden kann. Orthogonalität hat für die Implementierung eines Workflow-Management-Systems weitreichende Konsequenzen, vor allem hinsichtlich der Modularisierung. Unter der Voraussetzung, daß das einer Architektur zugrundeliegende Workflow-Modell einem Strukturkonzept folgt, wie es in Kapitel 4.1 beschrieben worden ist, kann die Modulbildung innerhalb einer Architektur eng an dieses Strukturkonzept angelehnt werden. Insbesondere können Module so formuliert werden, daß sie der Implementierung genau eines der in Kapitel 4.1 vorgestellten Aspekte dienen. Die für eine Modularisierung notwendigen Vorbedingungen der internen Kohärenz, der schwachen Kopplung zu anderen Modulen und der Unabhängigkeit von Modulen [13, 14] können somit erfüllt werden. 5 Architektur eines Workflow-Management-Systems Die Entwicklung von Software vollzieht sich in verschiedenen Phasen [11]. Die frühen Phasen einer Systementwicklung (Analyse- beziehungsweise Entwurfsphasen) dienen dem Zweck, inhärente Problemstrukturen zu identifizieren und eine Lösung im Ansatz zu beschreiben. DeRemer und Kron charakterisieren diese Phase der Softwareentwicklung als programming-inthe-large [4]. Das Ergebnis dieses Entwicklungsschritts ist eine Menge von Modulen, welche zueinander in Beziehung gesetzt werden [17]. Nagl [15] bezeichnet das Resultat des programming-in-thëlarge als die Softwarearchitektur, welche alle logischen Komponenten (Module) eines Softwaresystems nebst ihrer gegenseitigen Beziehungen beschreibt (Kapitel 5.1). Dabei können die Module zur besseren Strukturierung in verschiedenen Schichten organisiert werden (Schichtenarchitektur; Kapitel 5.1.2). Wir bezeichnen die Softwarearchitektur auch als Implementierungsmodell, welches die funktionalen Eigenschaften eines Softwaresystems beschreibt [9]. Den Analyse- und Entwurfsphasen folgt die Implementierungsphase. Sie kann mit der Phase des programming-in-the small gleichgesetzt werden [4] und hat zur Aufgabe, die identifizierten Komponenten (Module) und deren Interaktionen zu realisieren [15]. Aufgrund der Mannigfaltigkeit der dabei in Betracht zu ziehenden Implementierungskonzepte sollte diese Implementierungsphase in zwei Teilphasen aufgespaltet werden. In einer ersten Phase werden Implementierungskonzepte selektiert. Hierunter ist beispielsweise zu verstehen, daß die Verbindung zweier Komponenten als Client-/Serverstruktur etabliert werden soll. Darüber hinaus kann festgelegt werden, daß die dabei zu realisierende Kommunikationsbeziehung asynchron über ein hochverfügbares Medium erfolgen soll. Das Ziel einer solchen Analyse ist beispielsweise die Auswahl einer persistenten Warteschlange als Kommunikationskonzept zwischen den Komponenten. Das Ergebnis dieser ersten Implementierungsphase ist die sogenannte Implementierungsarchitektur (Kapitel 5.2), welche unter anderen die Selektion von Implementierungskonzepten umfaßt [9]. Nachdem neben den Komponenten einer Architektur auch die grundlegenden Implementierungskonzepte ausgewählt worden sind, gilt es diese Konzepte zu instantiieren. Dies bedeutet, daß zum Beispiel eine geeignete Realisierung einer persistenten Warteschlange bestimmt werden muß. Beispielsweise wird entschieden, daß transactional queues des TP-Monitors ENCINA [18] eingesetzt werden sollen. Dieser zweite Abschnitt der Implementierungsphase entspricht der eigentlichen Implementierung (Kapitel 5.3). Die Softwarearchitektur (das Implementierungsmodell) zusammen mit der Implementierungsarchitektur eines Workflow-Management-Systems kann gleichgesetzt werden mit der Architektur eines Workflow-Management-Systems. Somit ist eine dritte Interpretation des Architekturbegriffs eingeführt, welche wir als die wesentliche erachten. Er läßt sich in zwei Perspektiven aufspalten: eine implementierungsunabhängige Perspektive, welche vom Implementierungsmodell gebildet wird, und eine implementierungsabhängige Perspektive, welche von der Implementierungsarchitektur bestimmt wird. Eine Umsetzung der Architektur eines Workflow-Management-Systems entspricht dann der Instantiierung einer Implementierungsarchitektur, d. h. der Implementierung. 5.1 Implementierungsmodell Das Implementierungsmodell entspricht dem implementierungsunabhängigen Teil der Architektur eines Workflow-Management-Systems. Es umfaßt die wesentlichen Module oder Komponenten eines Workflow-Management-Systems. Bezogen auf Abb. 1 beschreibt die Architektur, wie die am API des Frameworks Workflow-Management-System angebotene Funktionalität erbracht wird. Diese Schnittstelle ist Voraussetzung dafür, die in Kapitel 3 vorgestellten Werkzeuge zu realisieren Komponenten. Gemäß dem Strukturmodell für Workflows aus Kapitel 4.1 und dem in Kapitel eingeführten Konzepten Modularität und Orthogonalität, muß die Architektur eines Workflow-Management-Systems für jeden Aspekt (Strukturelement) des Workflow-Modells eine Komponente (Modul) beziehungsweise eine Gruppe von Komponenten vorsehen. Aus Gründen der einfacheren Darstellung soll in diesem Beitrag davon ausgegangen werden, daß jeder Aspekt durch

6 77 genau eine Komponente realisiert wird (vgl. Abb. 2). Darüber hinaus ist ein Modul (Steuermodul) erforderlich, daß die Ausführung eines Workflows kontrolliert. Dieses Modul ist von zentraler Bedeutung und koordiniert die Auswertung einzelner Aspekte. Im allgemeinen muß das Steuermodul bei der Bearbeitung eines Workflows folgende Schritte initialisieren und initiieren: Aufruf des Moduls funktionaler Aspekt, das die Ausführung eines Workflows beschreibt. Aufruf des Moduls verhaltensbezogener Aspekt, das die Menge der als nächstes auszuführenden Subworkflows bestimmt. Abb. 2. Architektur eines Workflow-Management-Systems aus Implementierungssicht Aufruf des Moduls datenbezogener Aspekt, das die Menge der auszuführenden Workflows mit Eingabeparametern versorgt. Aufruf des Moduls organisatorischer Aspekt, das die Menge der organisatorischen Elemente beschreibt, die auszuführende Workflows abarbeiten dürfen. Aufruf des Moduls operationaler Aspekt, wenn ein Applikationsprogramm innerhalb eines elementaren Workflows auszuführen ist. Das Steuermodul soll als Kern eines Workflow-Management-Systems bezeichnet werden. Die weiteren, die verschiedenen Aspekte eines Workflow-Modells realisierenden Module werden in der den Kern umgebenden Schale organisiert. Die Module des Kerns und der Schale realisieren die Basisfunktionalität eines Workflow-Management-Systems; sie werden Basismodule genannt. Sie dienen zum einen der Realisierung von Anwendungen (vgl. Abb. 1) und zum anderen der Definition von Werkzeugen. Werkzeuge benötigen neben der von Basismodulen zur Verfügung gestellten Funktionalität zusätzliche Funktionen, welche in speziellen Modulen umgesetzt werden (Modulgruppe Werkzeuge ). Zum Beispiel wird im Werkzeug Arbeitsliste, das die Schnittstelle eines Endbenutzers zum Workflow-Management-System darstellt, eine Funktion zum Aktualisieren seiner Einträge benötigt. Darüber hinaus werden in Abb. 2 nicht näher spezifizierte Hilfsmodule (Modulgruppe Hilfsmodule ) gezeigt. Sie realisieren Hilfsfunktionen, wie beispielsweise eine Funktion zur Vergabe von eindeutigen Workflow-Identifikatoren. Abb. 2 illustriert auch die Verknüpfung der Module des Implementierungsmodells; alle gezeigten Pfeile identifizieren eine benutzt -Beziehung. Man erkennt auch, daß die Module der Schale lediglich über das Steuermodul des Kerns miteinander kommunizieren. Dies hat zum Vorteil, daß bei Änderung eines Moduls, welche sich in einer modifizierten Schnittstelle ausdrücken kann, lediglich die Verbindung zwischen Modul und Steuermodul aktualisiert werden muß [2] Schichten. Eine Schichtenarchitektur besteht aus hierarchisch angeordneten Schichten. Eine Schicht ist Schichtenarchitektur eines Workflow-Management-Sy- Abb. 3. stems dadurch gekennzeichnet, daß sie eine Menge von Objekten o i in eine Menge von höherwertigen Objekten o i+1 überführt. Objekte o i+1 werden am oberen Ende einer Schicht angeboten. Somit stellt eine Schichtenarchitektur eine Veredelungshierarchie dar, welche sukzessive Objekte mit Funktionalität anreichert. Ein Durchgriff auf Module unterer Schichten kann realisiert werden, indem Objekte o i+1 direkt auf Objekte o i abgebildet werden. Ordnet man die in Abb.2 gezeigten Module in eine Schichtenarchitektur ein (Abb. 3), so wird die unterste Schicht durch die sogenannten Hilfsmodule gebildet, die grundlegende Funktionen für alle anderen Module realisieren. Die von den Hilfsmodulen aus Abb. 3 angebotenen primitiven Operationen werden von der Schale benutzt, um Operationen zu konstruieren, welche einzelne Workflow-Aspekte bearbeiten. Zum Beispiel wird eine Operation angeboten, welche den Kontrollflußaspekt eines Workflows realisiert. Unter anderem kann eine solche Operation berechnen, weche Workflows als nächstes ausgeführt werden müssen. Der Kern faßt Aspekt-Operationen zu Workflow- Operationen zusammen [9]. Eine Workflow-Operation führt beispielsweise einen Workflow aus oder versetzt einen Workflow in einen Wartezustand. Schließlich bie-

7 78 tet die Werkzeugschicht Operationen auf Workflows an. So können unter anderem in einem Ablaufmonitor alle Workflows bestimmt werden, welche gegenwärtig einen bestimmten Abarbeitungszustand aufweisen. Eine Schichtenarchitektur zeigt deutlich, welche Auswirkungen Änderungen von Modulen auf andere Module haben können. Werden Komponenten einer unteren Schicht modifiziert, so sind Änderungen (der Schnittstellen) von höheren Modulen sehr wahrscheinlich; das Umgekehrte gilt nicht. Komponenten der gleichen Hierarchieebene beeinflussen sich lediglich dann, wenn sie gegenseitig die Realisierung bestimmter Funktionen übernehmen würden. Eine solche Situation würde eintreten, wenn eine Funktion f, bisher von Modul M x einer Schicht S realisiert, ab sofort von einem Modul M y der gleichen Schicht umgesetzt wird. Dieser unerwünschte Effekt kann vermieden werden, wenn die Komponenten einer Schicht orthogonal (vgl. Kapitel 4.2.3) konzipiert sind. Hier ist a priori eine Verteilung von Funktionalität auf verschiedene Module gegeben. Dies hat zur Folge, daß Änderungen einer Komponente die weiteren Komponenten der gleichen Architekturschicht nicht beeinflussen. 5.2 Implementierungsarchitektur Beim Übergang von einem Implementierungsmodell auf eine Implementierungsarchitektur müssen vor allem drei Entscheidungen getroffen werden: Werden Module durch Aktivitätsträger des Betriebssystems unterstützt? Wie werden die (persistenten) Daten einer Komponente verwaltet? Wie wird die Kommunikation zwischen den Modulen realisiert? Erfahrungen mit Workflow-Management-Systemen zeigen, daß diese drei Fragestellungen zentral für eine Implementierungsarchitektur sind. Die in diesem Unterkapitel vorgestellte Implementierungsarchitektur stellt den implementierungsabhängigen Teil der Architektur eines Workflow-Management-Systems dar Zuordnung von Aktivitätsträgern. An der Frage nach der Zahl der unterstützenden Aktivitätsträger (Prozesse, Threads, etc; in [7] zum Begriff Faden abstrahiert) entscheiden sich Kriterien wie Nebenläufigkeit und Ausfallsicherheit. Nebenläufige Bearbeitung ist nur möglich, wenn mehrere Aktivitätsträger zur Implementierung eingesetzt werden bei gleichzeitigem Vorhandensein mehrerer Prozessoren. Gleiches gilt für Ausfallsicherheit. Steht nur ein Aktivitätsträger zur Verfügung, kann dessen Ausfall das gesamte System lahm legen. Im Kontext Workflow-Management bieten sich zwei alternative Strategien für die Zuordnung von Objekten zu Aktivitätsträgern an. Zum einen können Komponenten (Module) den Aktivitätsträgern zugeordnet werden; zum anderen können Aktivitätsträger für Workflow-Typen bzw. -Instanzen reserviert werden. Mehrere Strategien können hierbei verfolgt werden: 1. jeder Workflow-Instanz wird ein Aktivitätsträger zugeordnet 2. jeder Instanz eines Top-Level-Workflows entspricht ein Aktivitätsträger, wobei seine Subworkflows ebenfalls diesem Aktivitätsträger zugeordnet werden 3. alle Workflow-Instanzen eines Workflow-Typs werden von einem Aktivitätsträger realisiert 4. alle Workflow-Instanzen aller Workflow-Typen werden von einem Aktivitätsträger unterstützt Es ist offensichtlich, daß Skalierbarkeit weder durch die ersten beiden noch durch die vierte Strategie unterstützt werden kann. In den ersten beiden Fällen wächst die Anzahl der Aktivitätsträger proportional mit der Zahl der Workflow-Instanzen, was sicher bald auf die Grenzen eines Rechnersystems stoßen wird. Im dritten und vierten Fall kann eine effiziente Bearbeitung nicht mehr gewährleistet werden, wenn die Zahl der zu unterstützenden Workflow-Typen bzw. -Instanzen eine gewisse Größenordnung übersteigt. Darüber hinaus ist die Isolation von Fehlern bei diesen Realisierungsvarianten nicht gegeben. Bereits aus der kurzen Diskussion läßt sich ableiten, daß eine direkte Proportionalität zwischen Workflow- Typen oder -Instanzen und Aktivitätsträgern vermieden werden muß. Aufgrund der Verwendung eines aspektorientierten Ansatzes sowohl bei der Modellierung als auch bei der Definition von Komponenten der Architektur empfiehlt sich, Aktivitätsträger Komponenten (Modulen) zuzuordnen. Jede Komponente des Workflow- Management-Systems wird von einem Pool von Aktivitätsträgern unterstützt. Eine Komponente wird demnach als Serverklasse implementiert, welche mehrere Server umfaßt. Somit kann zum einen direkt auf die unterschiedliche Auslastung der Komponenten eingegangen werden. Beispielsweise kann die Komponente Arbeitsliste bei jedem Endanwender durch einen eigenen Aktivitätsträger realisiert werden, um den hohen Anforderungen eines Endanwenders bezüglich Antwortzeit zu genügen. Zum anderen können unkritische Komponenten (zum Beispiel verhaltensbezogener Aspekt ) bereits durch wenige Aktivitätsträger effizient unterstützt werden. Als Mischstrategie ist sicherlich auch eine Poolbildung denkbar, bei der mehrere Komponenten durch einen Aktivitätsträger realisiert werden Datenverwaltung. Es lassen sich verschiedene Klassen von Daten unterscheiden. In einer Typdatenbank werden alle Daten abgelegt, welche Workflow-Typen beschreiben. Eine Instanzdatenbank enthält Informationen über Workflow-Instanzen. Während die Typdatenbank eher statischen Charakter aufweist, ändert sich der Zustand der Instanzdatenbank ständig.

8 79 Bei der Diskussion von Verwaltungskonzepten für die Typ- und Instanzdaten wird davon ausgegangen, daß eine aspektorientierte Strukturierung der Architektur vorliegt. Somit kann a priori eine Fragmentierung der Daten nach Aspekten vorgenommen werden. Diese Fragmente werden den einzelnen Aspekten zugeordnet. Beispielsweise werden dem Modul verhaltensbezogener Aspekt Daten zugeordnet, welche Kontrollflußinformation auf Typ- und auf Instanzebene enthalten. Durch die aspektorientierte Fragmentierung und Zuordnung von Daten wird insbesondere die Nebenläufigkeit beim Zugriff erhöht, da Zugriffskonflikte verringert werden. Obige Strategie ist für alle Komponenten der Schale eines Workflow-Management-Systems zu verwenden. Eine Allokation von Daten kann problemlos gefunden werden, da die den verschiedenen Aspekten interessierenden Daten (aufgrund der Orthogonalität) zueinander disjunkt sind. Kritisch wird die Anwendung der Strategie erst dann, wenn die höheren Komponenten von Kern- und Werkzeugebene tangiert werden. Ohne ins Detail zu gehen, kann festgestellt werden, daß diese Komponenten Daten benötigen, welche insbesondere von den Komponenten der Schale auch benutzt werden müssen. Der daraus resultierende konkurrierende Zugriff muß bei der Definition einer Datenverwaltungsstrategie berücksichtigt werden. Datenreplikation wäre gut zur Verwaltung statischer Typdaten geeignet; aufgrund der hohen Dynamik von Instanzdaten sollte sie aber hierbei nicht angewandt werden Kommunikation. Bei der Auswahl eines Kommunikationsmechanismus muß zunächst abgewägt werden, ob er synchrone oder asynchrone Kommunikation unterstützen muß. Die Kommunikation des Werkzeugs Arbeitsliste mit dem Kernsystem erfordert hohe Effizienz, da ein Endanwender direkt auf das Ergebnis eines von ihm ausgelösten Arbeitsschritts wartet. In diesem Fall ist sicherlich synchrone Kommunikation der asynchronen vorzuziehen, da sie eher Antwortzeiten einzuhalten gestattet. An anderen Stellen, beispielsweise bei der Kommunikation zwischen einem Modul der Schale und dem Steuermodul, kann asynchrone Kommunikation besser geeignet sein, da hier eher durchsatzorientiert gearbeitet werden muß. Im Zusammenhang mit der Entscheidung zwischen einem synchronen und einem asynchronen Kommunikationsmittel wird ein weiteres Problem aufgeworfen. Wie eng sollen Aufrufender und Aufgerufener gekoppelt sein? Diese Kopplung hat entscheidenden Einfluß auf das Verhalten in Fehlerfällen. Bei einer engen Kopplung kann die Auswirkung eines Fehlers schlechter eingegrenzt werden als bei einer losen Kopplung. Letztere ist daher in den meisten Fällen vorzuziehen. Sie impliziert aber zumeist asynchrone Kommunikation. Schließlich ist die Zuverlässigkeit der Kommunikation ein Kriterium. Zuverlässige Kommunikation, zum Beispiel über eine persistente Warteschlange, bedeutet auch einen erhöhten Aufwand gegenüber einer Kommunikationstechnik, welche über ein nicht-persistentes Medium abgewickelt wird. Allerdings gehen hierbei Nachrichten nicht verloren. Eine endgültige Festlegung auf einen bestimmmten Kommunikationsmechanismus stellt einen Kompromiß zwischen mehreren Alternativen dar. Es ist nicht notwendig, für alle möglichen Kommunikationsbeziehungen den gleichen Kommunikationsmechanismus auszuwählen. Vielmehr sollten verschiedene Kommunikationsstrukturen optimal mit unterschiedlichen Kommunikationsmechanismen bedient werden. 5.3 Implementierung Hauptaufgabe der Implementierungsphase ist die Instantiierung der Implementierungsarchitektur. Insbesondere müssen Aktivitätsträger ausgewählt werden, konkrete Datenverwaltungs- oder Datenbanksysteme selektiert werden und Kommunikationsmechanismen installiert werden. Es würde den Rahmen dieses Beitrags sprengen, einzelne Softwaresysteme als Instantiierung der Konzepte Aktivitätsträger, Datenhaltung und Kommunikation vorzustellen. Sicherlich sind relationale Datenbanksysteme, persistente Warteschlangensysteme, RPC-Mechanismen und CORBA-Ansätze für den Bereich Workflow-Management gut geeignet. Beispielsweise stellt CORBA [16] einen validen Mechanismus dar, wenn es darum geht, Applikationen in einen Workflow einzubinden (operationaler Aspekt). Global ist eine solche Aussage aber nicht möglich, sie kann nur fallspezifisch zutreffen. 5.4 Diskussion Abschließend muß in diesem Unterkapitel bewertet werden, ob die in Kapitel 4.2 diskutierten Anforderungen von der hier vorgestellten Architektur erfüllt werden können. Sicherlich sind nicht alle Anforderungen bezüglich ihrer Umsetzbarkeit diskutierbar. Manche Anforderungen können erst entschieden werden, wenn eine konkrete Implementierung betrachtet wird. Die Erweiterbarkeit eines Workflow-Management- Systems ist aufgrund der modularen, auf Orthogonalität der Komponenten basierten Architektur gegeben. Skalierbarkeit kann erfüllt werden, wenn die in Kapitel 5.2 diskutierten Kriterien der Zuordnung von Aktivitätsträgern zu Workflow-Typen und -Instanzen bzw. zu Komponenten des Workflow-Management-Systems berücksichtigt werden. Die Beherrschung verteilter heterogener Basissysteme hängt im großen ganzen von der Auswahl der in der Phase Implementierungsarchitektur einzusetzenden Konzepte ab. Werden allgemeine Konzepte der Middleware verwendet, ist die Beherrschung verteilter, heterogener Anwendungssysteme gegeben. Die Portabilität eines Workflow-Management-Systems wird außerdem durch den Einsatz von Diensten der Middleware erhöht. Die Zuverlässigkeit der Verarbeitung hängt insbesondere davon ab, ob Datenbanksysteme und/oder per-

9 80 sistente Warteschlangensysteme verwendet werden. Fehlertolerante Strukturen für Aktivitätsträger erhöhen ebenfalls die Verfügbarkeit. Wartbarkeit bzw. Korrektheit des Systems können an dieser Stelle nicht definiert werden. Beide Kriterien hängen vor allem davon ab, wie eine Architektur instantiiert wird. 6 Einordnung des Architekturvorschlags der Workflow Management Coalition Aufgrund der zunehmenden Verbreitung des in Abb. 4 gezeigten Architekturvorschlags der Workflow Management Coalition (WfMC, [20]) wird in diesem Abschnitt diskutiert, wie dieser in die Architektur eines Workflow-Management-Systems eingeordnet werden kann. Er identifiziert fünf Schnittstellen zwischen nicht näher gerechtfertigten Komponenten eines Workflow- Management-Systems, wobei die Funktionalität dieser Komponenten nicht genau definiert ist. Bei Process Definition Servies, Administration and Monitoring Services und Workflow Client Applications (Schnittstellen 1, 2 und 5) handelt es sich um Werkzeuge, wobei letztere den Arbeitslisten entsprechen. Es ist nicht zu erkennen, warum gerade diese drei Werkzeuge explizit in eine Architektur Eingang finden und weitere Werkzeuge, wie sie unter anderen in Kapitel 3.0 eingeführt werden, nicht berücksichtigt werden. Invoked Applications (Schnittstelle 3) stellen Applikationsprogramme dar, welche zur Ausführung elementarer Workflows aufgerufen werden (vgl. Kapitel 4.1). Wiederum ist nicht zu erkennen, warum diese externen Programme in ein Architekturschema aufgenommen werden müssen. Sicherlich stellt die Integration von Applikationsprogrammen in Workflows eine bedeutende Aufgabe dar, sie ist aber eher einem Dienst Applikationsintegration zuzuordnen, der in der Schale eines Workflow-Management-Systems zu finden ist, als daß dieses Problem auf Ebene einer Architekturbeschreibung sichtbar werden sollte. Eine Workflow Engine umfaßt Dienste der Komponenten von Kern und Schale eines Workflow-Management-Systems, wobei auch diese Dienste im Vorschlag der WfMC nicht exakt definiert werden. Die Verbindung zu weiteren Workflow Engines (Schnittstelle 4) wird explizit erwähnt, da sich eine der zentralen Aufgaben der WfMC mit der Integration von verteilten Workflow Engines verschiedener Hersteller befaßt. Allerdings fehlt hier die Definition einer verteilten Ausführung eines Workflows. Das oftmals als Architekturbild bezeichnete Diagramm aus Abb. 4 entspricht nicht den Konventionen, welche an eine Architekturdarstellung gerichtet werden. Es bezeichnet vielmehr die Arbeitsgebiete der verschiedenen Arbeitsgruppen innerhalb der WfMC und darf nicht als Architekturkonzept herangezogen werden, was aber des öfteren fälschlicherweise getan wird. Eine Architektur, welche in die Schemata der Abb. 2 bzw. der Abb. 3 paßt, kann andererseits konform zu den Anforderungen der WfMC sein. Abb. 4. Schnittstellen des Architekturvorschlags der WfMC 7 Schlußbemerkung Ziel dieses Beitrags ist es, die Diskussionen von Architekturvorschlägen für Workflow-Management-Systeme zu vereinfachen bzw. prinzipiell erst zu ermöglichen. Aus diesem Grund wird eine allgemeine Basis- oder Rahmenarchitektur vorgeschlagen, welche den Vergleich und die Einordnung von Architekturen von Workflow-Management-Systemen erlaubt. Insbesondere werden Grundlagen und Anforderungen einer solchen Basisarchitektur vorgestellt, wodurch eine vertiefte Einsicht in die Problematik der Architekturentscheidung im Bereich Workflow-Management möglich wird. Darüber hinaus werden die zentralen Konzepte einer Architektur eingeführt. Die mögliche Einordnung von verschiedenen Workflow-Management-Systemen in diese allgemeinen Architekturvorschläge unterstützt die Aussagekraft des hier vorgestellten Ansatzes. Interessant ist hierbei, daß gerade der als ein solcher betrachtete Architekturvorschlag des internationalen Normungsgremiums WfMC im Bereich Workflow-Management nicht den Anforderungen an eine Architektur genügt. Eine kritische Auseinandersetzung mit diesem Vorschlag ist daher notwendig; die leider immer häufiger zu beobachtende unkritische Übernahme des Vorschlags ist bedenklich. Literatur 1. Bernstein, P. A.: Middleware: A model for distributed system services. Comm. ACM 39 (2), (1996) 2. Bussler, C., Jablonski, S.: Scalability and extensibility through modularity: Architecture of the MOBILE Workflow Management System. Proc. 5th International Workshop on Information Technologies and Systems, Amsterdam, The Netherlands (Dec. 1995) 3. COSA Reference Manual: Software-Ley GmbH (1994) 4. DeRemer, F. L., Kron, H. K.: Programming-in-the-large versus programming-in-the-small. IEEE Trans. Software Eng. 2 (2), (1976) 5. Humphrey, W. S.: Managing the Software Process. Reading, MA: Addison-Wesley IBM FlowMark: Programming Guide, Version 2.1. International Business Machines Corporation (1995)

10 81 7. Hofmann, F.: Was bieten Betriebssysteme den Anwendern? it + ti 38 (2), 6 11 (1996) 8. Jablonski, S.: Workflow-Management-Systeme Modellierung und Architektur. Thomson s Aktuelle Tutorien 9. International Thomson Jablonski, S., Bussler, C.: Workflow Management. Modelling Concepts, Architecture and Implementation. International Thomson Leymann, F., Altenhuber, W.: Managing business processes as an information resource. IBM Systems J. 33 (2), (1994) 11. Martin, J.: Information Engineering. Englewood Cliffs, NJ: Prentice-Hall McCall, J. A., Richards, P. K., Walters, G. F.: Factors in Software Quality, Vol.I III. Rome Air Development Center (1977) 13. Meyer, B.: Object-oriented Software Construction, Englewood Cliffs, NJ: Prentice-Hall Myers, G. J.: Software Reliability. New York: Wiley Nagl, M.: Modelling of software architectures: Importance, notions, experiences. Aachener Informatik-Berichte, RWTH Aachen Fachgruppe Informatik, Nr The Common Object Request Broker Architecture and Specification (CORBA): OMG, Framingham, MA (1992) 17. Parnas, D. L.: On the criteria to be used in decomposing systems into modules. Comm. ACM 15 (12), (1972) 18. Executive Programmer s Reference: Transarc Corporation (1994) 19. Vernadat, F.: Enterprise modeling and integration: Principles and applications. London: Chapman & Hall Workflow Process Definition Read/Write Interface, Workflow- ManagementC-WG Workflow Management Coalition (1995) 21. WorkParty: Technical information. Siemens Nixdorf Informationssystme AG (1994) Stefan Jablonski studierte Informatik mit Schwerpunktfach Datenbanksysteme an der Friedrich- Alexander-Universität Erlangen- Nürnberg. Dort promovierte er 1989 über das Thema Datenverwaltung in verteilten Systemen. Von 1991 bis 1994 gehörte er der Firma Digital Equipment GmbH an. Er war beteiligt an der Entwicklung eines Workflow-Management- Systems in der Activity Management Group (Palo Alto, USA). Seit 1994 ist er Professor für Datenbanksysteme an der Friedrich-Alexander-Universität Erlangen-Nürnberg.

Architektur und Implementierung von WfMS

Architektur und Implementierung von WfMS Vorlesung Wintersemester 2010/11 Workflow-Management-Systeme Kapitel 12: Architektur und Implementierung von WfMS Lehrstuhl für Systeme der Informationsverwaltung, Prof. Böhm Institut für Programmstrukturen

Mehr

Aspekte von WfMS und Architekturansätze für WfMS

Aspekte von WfMS und Architekturansätze für WfMS Kapitel 5: Aspekte von WfMS und Architekturansätze für WfMS WS 2007/08 Vorlesung WFMS - Jutta Mülle, IPD - Uni Karlsruhe 1 Aspekte eines Workflow-Management-Systems (1) Funktionaler Aspekt: beschreibt

Mehr

Client/Server-Systeme

Client/Server-Systeme Fachbereich Informatik Projektgruppe KOSI Kooperative Spiele im Internet Client/Server-Systeme Vortragender Jan-Ole Janssen 26. November 2000 Übersicht Teil 1 Das Client/Server-Konzept Teil 2 Client/Server-Architekturen

Mehr

1 Einleitung. Betriebswirtschaftlich administrative Systeme

1 Einleitung. Betriebswirtschaftlich administrative Systeme 1 1 Einleitung Data Warehousing hat sich in den letzten Jahren zu einem der zentralen Themen der Informationstechnologie entwickelt. Es wird als strategisches Werkzeug zur Bereitstellung von Informationen

Mehr

Befragung und empirische Einschätzung der Praxisrelevanz

Befragung und empirische Einschätzung der Praxisrelevanz Befragung und empirische Einschätzung der Praxisrelevanz eines Vorgehensmodells zur Auswahl von CRM-Systemen D I P L O M A R B E I T zur Erlangung des Grades eines Diplom-Ökonomen der Wirtschaftswissenschaftlichen

Mehr

6 Architektur-Mittel (WOMIT)

6 Architektur-Mittel (WOMIT) 6 Architektur-Mittel (WOMIT) Abb. 6-1: Positionierung des Kapitels im Ordnungsrahmen. Dieses Kapitel befasst sich mit der WOMIT-Dimension des architektonischen Ordnungsrahmens, indem es grundlegende Konzepte

Mehr

1 Problematik eines uneinheitlichen Verständnisses der SOA... 201. 2 SOA als unternehmensweites Architekturkonzept... 203

1 Problematik eines uneinheitlichen Verständnisses der SOA... 201. 2 SOA als unternehmensweites Architekturkonzept... 203 Mehr als alter Wein in neuen Schläuchen 199 1 Problematik eines uneinheitlichen Verständnisses der SOA... 201 2 SOA als unternehmensweites Architekturkonzept........... 203 3 Struktur einer SOA..................................

Mehr

CORBA. Systemprogrammierung WS 2006-2007

CORBA. Systemprogrammierung WS 2006-2007 CORBA Systemprogrammierung WS 2006-2007 Teilnehmer: Bahareh Akherattalab Babak Akherattalab Inhaltsverzeichnis: Verteilte Systeme Vergleich zwischen lokale und verteilte Systeme Verteilte Anwendungen CORBA

Mehr

Grob- und Detailplanung bei der Implementierung nutzen

Grob- und Detailplanung bei der Implementierung nutzen Softwarearchitektur Grob- und Detailplanung bei der Implementierung nutzen Bereich Realisierung Aktivität Softwareinkrement realisieren Ziele Vermitteln einer Orientierungshilfe für alle Entwickler Etablierung

Mehr

EAI - Enterprise Application Integration

EAI - Enterprise Application Integration EAI - Enterprise Application Integration Jutta Mülle WS 2005/2006 EAI - Folie 1 Überblick und Begriffsbildung Zusammenfassung und Ausblick hinweise EAI - Folie 2 Conclusion EAI Enterprise Application Integration

Mehr

1 YAWL Yet Another Workflow Language

1 YAWL Yet Another Workflow Language 1 YAWL Yet Another Workflow Language Das YAWL Workflow-Management-System wurde von Wil van der Aalst und seinem Team an der Eindhoven University of Technology entwickelt. Das System ist in seiner jetzigen

Mehr

Virtualisierung im IT-Betrieb der BA

Virtualisierung im IT-Betrieb der BA Virtualisierung, essenzielles Werkzeug in der IT-Fabrik Martin Deeg, Anwendungsszenarien Cloud Computing, 31. August 2010 Virtualisierung im IT-Betrieb der BA Virtualisierung im IT-Betrieb der BA Effizienzsteigerung

Mehr

Workflow-Management für CORBA-basierte Anwendungen

Workflow-Management für CORBA-basierte Anwendungen Wolfgang Schulze 2008 AGI-Information Management Consultants May be used for personal purporses only or by libraries associated to dandelon.com network. Workflow-Management für CORBA-basierte Anwendungen

Mehr

Softwareentwicklung mit Enterprise JAVA Beans

Softwareentwicklung mit Enterprise JAVA Beans Softwareentwicklung mit Enterprise JAVA Beans Java Enterprise Edition - Überblick Was ist J2EE Java EE? Zunächst mal: Eine Menge von Spezifikationen und Regeln. April 1997: SUN initiiert die Entwicklung

Mehr

Optimieren von Requirements Management & Engineering

Optimieren von Requirements Management & Engineering Xpert.press Optimieren von Requirements Management & Engineering Mit dem HOOD Capability Model Bearbeitet von Colin Hood, Rupert Wiebel 1. Auflage 2005. Buch. xii, 245 S. Hardcover ISBN 978 3 540 21178

Mehr

PFlow-Editor Entwicklung und Implementierung eines Modellierungswerkzeugs für ein Peer-to-Peer Production Workflow Management System

PFlow-Editor Entwicklung und Implementierung eines Modellierungswerkzeugs für ein Peer-to-Peer Production Workflow Management System PFlow-Editor Entwicklung und Implementierung eines Modellierungswerkzeugs für ein Peer-to-Peer Production Workflow Management System Fortgeschrittenenpraktikum bei Prof. Dr. Martin Wirsing vorgelegt von:

Mehr

Architektur und Implementierung von WfMS

Architektur und Implementierung von WfMS Vorlesung Wintersemester 2011/12 Workflow-Management-Systeme Kapitel 12: Architektur und Implementierung von WfMS Lehrstuhl für Systeme der Informationsverwaltung, Prof. Böhm Institut für Programmstrukturen

Mehr

Umsetzung von Geschäftsprozessen: Workflow-Managementsysteme. Knut Hinkelmann

Umsetzung von Geschäftsprozessen: Workflow-Managementsysteme. Knut Hinkelmann Umsetzung von Geschäftsprozessen: Knut Hinkelmann Das BPMS *) Paradigma Wo liegt unsere Wertschöpfung? Produkte Strategische Entscheidungen Wie erstellen wir unsere Produkte? Geschäftsprozesse Re-Engineering

Mehr

Workflow Management: Workflow (1)

Workflow Management: Workflow (1) Workflow Management: Workflow (1) Abgrenzung: Geschäftsprozeß Vorgang (Aktivität) Arbeitsablauf (Workflow) Arbeitsschritt (Work Item) Otto-von-Guericke-Universität Magdeburg Fakultät für Informatik Institut

Mehr

SOA goes real Service-orientierte Architekturen erfolgreich planen und einführen

SOA goes real Service-orientierte Architekturen erfolgreich planen und einführen Daniel Liebhart SOA goes real Service-orientierte Architekturen erfolgreich planen und einführen ISBN-10: 3-446-41088-0 ISBN-13: 978-3-446-41088-6 Inhaltsverzeichnis Weitere Informationen oder Bestellungen

Mehr

Hauptseminar Management von Softwaresystemen. Techniken der System-Integration EAI, Middleware, SOA, CORBA

Hauptseminar Management von Softwaresystemen. Techniken der System-Integration EAI, Middleware, SOA, CORBA Hauptseminar Management von Softwaresystemen Techniken der System-Integration EAI, Middleware, SOA, CORBA Betreuerin: Referent: Ulrike Hammerschall Alexey Krivoborodov Agenda Motivation Arten der Verteilung

Mehr

Erfassung von Umgebungskontext und Kontextmanagement

Erfassung von Umgebungskontext und Kontextmanagement Erfassung von Umgebungskontext und Kontextmanagement Jörg Schneider, Christian Mannweiler, Andreas Klein, Hans D. Schotten 13.05.2009 Inhalt 1. Einleitung 2. Anforderungen 3. Kontext Erfassung und Verteilung

Mehr

White Paper. Embedded Treiberframework. Einführung

White Paper. Embedded Treiberframework. Einführung Embedded Treiberframework Einführung White Paper Dieses White Paper beschreibt die Architektur einer Laufzeitumgebung für Gerätetreiber im embedded Umfeld. Dieses Treiberframework ist dabei auf jede embedded

Mehr

Entwicklung von Web-Anwendungen auf JAVA EE Basis

Entwicklung von Web-Anwendungen auf JAVA EE Basis Entwicklung von Web-Anwendungen auf JAVA EE Basis Java Enterprise Edition - Überblick Prof. Dr. Bernhard Schiefer Inhalt der Veranstaltung Überblick Java EE JDBC, JPA, JNDI Servlets, Java Server Pages

Mehr

Portierung einer Workflow-Engine auf Applikationsserver unter Verwendung EJB 2.0

Portierung einer Workflow-Engine auf Applikationsserver unter Verwendung EJB 2.0 Diplomarbeit im Fach Informatik Portierung einer Workflow-Engine auf Applikationsserver unter Verwendung EJB 2.0 Vorgelegt von Eugen Resch SS 2003 Betreuer: Prof. Dr. W. Spruth Lehrstuhl für Technische

Mehr

Wrapper und Konnektoren geht die Rechnung auf?

Wrapper und Konnektoren geht die Rechnung auf? Wrapper und Konnektoren geht die Rechnung auf? Klaudia Hergula DaimlerChrysler AG Forschung und Technologie Wissensaustausch / Austauschgruppe (FTK/A) HPC 0516, Epplestr. 225, D-70546 Stuttgart klaudia.hergula@daimlerchrysler.com

Mehr

CaseWare Monitor. ProduktNEWS CaseWare Monitor. Version 4.3. Mehr Informationen zu CaseWare Monitor und unseren anderen Produkten & Dienstleistungen

CaseWare Monitor. ProduktNEWS CaseWare Monitor. Version 4.3. Mehr Informationen zu CaseWare Monitor und unseren anderen Produkten & Dienstleistungen Mit der aktuellen Version hält eine komplett neu konzipierte webbasierte Anwendung Einzug, die sich neben innovativer Technik auch durch ein modernes Design und eine intuitive Bedienung auszeichnet. Angefangen

Mehr

Berichte aus der Medizinischen Informatik und Bioinformatik. Günther Schadow. Krankenhauskommunikation mit HL7

Berichte aus der Medizinischen Informatik und Bioinformatik. Günther Schadow. Krankenhauskommunikation mit HL7 Berichte aus der Medizinischen Informatik und Bioinformatik Günther Schadow Krankenhauskommunikation mit HL7 Analyse, Implementation und Anwendungeines Protokollstandards für medizinische Datenkommunikation

Mehr

8.4 Überblick und Vergleich weiterer ERP-Systeme. G Oracle Applications 11 G PeopleSoft 7 G J.D. Edwards One World G BaanERP

8.4 Überblick und Vergleich weiterer ERP-Systeme. G Oracle Applications 11 G PeopleSoft 7 G J.D. Edwards One World G BaanERP 8.4 Überblick und Vergleich weiterer ERP-Systeme G Oracle Applications 11 G PeopleSoft 7 G J.D. Edwards One World G BaanERP Kapitel 8: ERP-Einführung 32 Architektur von Oracle Applications 11 G Logische

Mehr

Architektur einer GDI: Service-oriented Architecture (SOA)

Architektur einer GDI: Service-oriented Architecture (SOA) Modul 6: Voraussetzungen einer GDI Vertiefende Dokumente I Stand: 24.01.2012 Architektur einer GDI: Service-oriented Architecture (SOA) Zu den Hauptargumenten für eine Geodateninfrastruktur zählen unter

Mehr

Integration Services - Dienstarchitektur

Integration Services - Dienstarchitektur Integration Services - Dienstarchitektur Integration Services - Dienstarchitektur Dieser Artikel solle dabei unterstützen, Integration Services in Microsoft SQL Server be sser zu verstehen und damit die

Mehr

Service-Orientierte Architekturen

Service-Orientierte Architekturen Hochschule Bonn-Rhein-Sieg Service-Orientierte Architekturen Kapitel 7: Web Services IV Exkurs über Sicherheitsanforderungen Vorlesung im Masterstudiengang Informatik Sommersemester 2010 Prof. Dr. Sascha

Mehr

Guten Tag! CampusSource. Die CSE Integration Platform. CampusSource Engine. Christof Pohl Softwareentwicklung Medienzentrum Universität Dortmund

Guten Tag! CampusSource. Die CSE Integration Platform. CampusSource Engine. Christof Pohl Softwareentwicklung Medienzentrum Universität Dortmund Engine Die CSE Integration Platform Guten Tag! Christof Pohl Softwareentwicklung Medienzentrum Universität Dortmund Integriertes Informationsmanagement mit der Engine - A2A vs. EBI Folie 2 Integration

Mehr

Was ist Software-Architektur?

Was ist Software-Architektur? Was ist Software-Architektur? Stephan Schulze Martin Knobloch 28.04.2004 Seminar: Software-Architektur Humboldt Universität zu Berlin sschulze knobloch@informatik.hu-berlin.de Gliederung Begriffsbestimmung

Mehr

Integrating Architecture Apps for the Enterprise

Integrating Architecture Apps for the Enterprise Integrating Architecture Apps for the Enterprise Ein einheitliches Modulsystem für verteilte Unternehmensanwendungen Motivation und Grundkonzept Inhalt Problem Ursache Herausforderung Grundgedanke Architektur

Mehr

Softwarewiederverwendung und Patterns

Softwarewiederverwendung und Patterns Begrifflichkeiten und Beschreibungssystematik Begriffe Literatur zu Patterns Übersicht über die behandelten Konzepte Beschreibungsschema 97 Begriffe Glossar Patterns (Muster) sind ein Mittel der Wiederverwendung

Mehr

Liste der Handbücher. Liste der Benutzerhandbücher von MEGA

Liste der Handbücher. Liste der Benutzerhandbücher von MEGA Liste der Handbücher Liste der Benutzerhandbücher von MEGA MEGA 2009 SP4 1. Ausgabe (Juni 2010) Die in diesem Dokument enthaltenen Informationen können jederzeit ohne vorherige Ankündigung geändert werden

Mehr

Über dieses Buch. Kapitel 1. 1.1 Einleitung

Über dieses Buch. Kapitel 1. 1.1 Einleitung Kapitel 1 Über dieses Buch 1.1 Einleitung Dieses Buch behandelt das Vorgehensmodell Kanban und seinen Einsatz in Softwareentwicklungsprojekten. Kanban ist ein Vorgehensmodell der schlanken Softwareentwicklung

Mehr

Objektorientierter Software-Entwurf Die Unified Modeling Language 4 1

Objektorientierter Software-Entwurf Die Unified Modeling Language 4 1 Objektorientierter Software-Entwurf Die Unified Modeling Language 4 1 Die Unified Modeling Language Die UML (hier in der Version 0.9) ist ein Satz von Notationen zur Beschreibung objektorientierter Softwaresysteme.

Mehr

Egon Börger (Pisa) S-BPM. Über den praktischen Gewinn. einer wissenschaftlichen Fundierung

Egon Börger (Pisa) S-BPM. Über den praktischen Gewinn. einer wissenschaftlichen Fundierung Egon Börger (Pisa) S-BPM Über den praktischen Gewinn einer wissenschaftlichen Fundierung Dipartimento di Informatica, Università di Pisa, Pisa (Italia) boerger@di.unipi.it Copyright c Egon Börger, Dipartimento

Mehr

CORBA-Konzept. Ziele. Common Object Request Broker Architecture CORBA. Plattformunabhängige Kommunikation Transparente Verteilung von Objekten

CORBA-Konzept. Ziele. Common Object Request Broker Architecture CORBA. Plattformunabhängige Kommunikation Transparente Verteilung von Objekten CORBA-Konzept Ziele Common Object Request Broker Architecture CORBA Plattformunabhängige Kommunikation Transparente Verteilung von Objekten CORBA-Konzept Object Management Group Spezifiziert den CORBA-Standard

Mehr

Geschäftsprozessmanagement

Geschäftsprozessmanagement Geschäftsprozessmanagement Der INTARGIA-Ansatz Whitepaper Dr. Thomas Jurisch, Steffen Weber INTARGIA Managementberatung GmbH Max-Planck-Straße 20 63303 Dreieich Telefon: +49 (0)6103 / 5086-0 Telefax: +49

Mehr

Scheinaufgabe im Fach Web Engineering

Scheinaufgabe im Fach Web Engineering Otto-von-Guericke-Universität Magdeburg Fakultät für Informatik Institut für Verteilte Systeme Scheinaufgabe im Fach Web Engineering Thomas Thüm 07. August 2006 Matrikel: 171046 Lehrveranstaltung: Web

Mehr

Vorlesung. Modelle für Geschäftsprozesse und Services. Prof. Dr. Karsten Wolf

Vorlesung. Modelle für Geschäftsprozesse und Services. Prof. Dr. Karsten Wolf Vorlesung Modelle für Geschäftsprozesse und Services Prof. Dr. Karsten Wolf Was ist ein Geschäftsprozess? Beispiele: Bearbeitung eines Schadensfalls in einer Versicherung Kreditüberprüfung in einer Bank

Mehr

Automatisierung Vom definierten Geschäftsprozess zum automatisiert ablaufenden Workflow

Automatisierung Vom definierten Geschäftsprozess zum automatisiert ablaufenden Workflow Automatisierung Vom definierten Geschäftsprozess zum automatisiert ablaufenden Workflow Konzepte und Ansätze der Workflow-Automatisierung und deren technischer Grundlage Joachim Brunold 25.02.2010 Version

Mehr

Workflow-Management-Systeme

Workflow-Management-Systeme Workflow-Management-Systeme Vorlesung im Wintersemester 2007/2008 Dipl.Inform. Jutta Mülle Universität Karlsruhe, Fakultät für Informatik Institut für Programmstrukturen und Datenorganisation (IPD) Lehrstuhl

Mehr

Open Grid Services Architecture (OGSA)

Open Grid Services Architecture (OGSA) Open Grid Services Architecture (OGSA) IBM Red Paper; Fundamentals of Grid Computing, 2002 A d v an ced M id d lew are P ro f. D r. C h. R eich rc h @ fh-furtw angen.d e http://www.informatik.fh-furtwangen.de/~reich/advancedmiddlewareallg.ss05/index.html

Mehr

Abbildung 3-1: Clients und Server C+S

Abbildung 3-1: Clients und Server C+S Abbildung 3-1: Clients und Server C+S Abbildung 3-2: Interaktions-koordinations-arten Abbildung 3-3: Zuverlässige Nachrichtenübertragung a) durch individuell quittierte Nachrichten b) durch Quittierung

Mehr

Seminar Business Process Management und Workflow-Technologie: Grundlagen, Produkte, Forschung

Seminar Business Process Management und Workflow-Technologie: Grundlagen, Produkte, Forschung IBM WebSphere Process Server Seminar Business Process Management und Workflow-Technologie: Grundlagen, Produkte, Forschung AGENDA 1. Überblick 2. WebSphere Process Server 3. Komponenten 4. Präsentation

Mehr

A classification and comparison framework for software architecture description languages

A classification and comparison framework for software architecture description languages A classification and comparison framework for software architecture description languages Christian Gerth Seminar Architekturbeschreibungssprachen Prof. Dr. Heike Wehrheim Fachgebiet Spezifikation und

Mehr

Data Lineage goes Traceability - oder was Requirements Engineering von Business Intelligence lernen kann

Data Lineage goes Traceability - oder was Requirements Engineering von Business Intelligence lernen kann Data Lineage goes Traceability - oder was Requirements Engineering von Business Intelligence lernen kann Andreas Ditze MID GmbH Kressengartenstraße 10 90402 Nürnberg a.ditze@mid.de Abstract: Data Lineage

Mehr

Tier-Konzepte. Vertiefungsarbeit von Karin Schäuble

Tier-Konzepte. Vertiefungsarbeit von Karin Schäuble Vertiefungsarbeit von Karin Schäuble Gliederung 1. Einführung 3. Rahmenbedingungen in der heutigen Marktwirtschaft 3.1 Situation für Unternehmen 3.2 Situation für Applikationsentwickler 4. Lösungskonzepte

Mehr

Adlerblick So gewinnen Sie einen Überblick über ein DWH Dr. Andrea Kennel InfoPunkt Kennel GmbH CH-8600 Dübendorf Schlüsselworte Einleitung

Adlerblick So gewinnen Sie einen Überblick über ein DWH Dr. Andrea Kennel InfoPunkt Kennel GmbH CH-8600 Dübendorf Schlüsselworte Einleitung Adlerblick So gewinnen Sie einen Überblick über ein DWH Dr. Andrea Kennel InfoPunkt Kennel GmbH CH-8600 Dübendorf Schlüsselworte DWH Projekt, Methodik, Stärken und Schwächen, Übersicht, Weg der Daten,

Mehr

11. Konfigurationsverwaltung

11. Konfigurationsverwaltung 11. Konfigurationsverwaltung 139 11. Konfigurationsverwaltung 11.1 Grundlagen Ändern Sie noch eben schnell" Die allzu einfache Möglichkeit, Software zu ändern, verursacht eine Menge von Problemen, zum

Mehr

SmartExporter 2013 R1

SmartExporter 2013 R1 Die aktuelle Version wartet mit zahlreichen neuen Features und umfangreichen Erweiterungen auf. So können mit SmartExporter 2013 R1 nun auch archivierte Daten extrahiert und das Herunterladen der Daten

Mehr

inxire Enterprise Content Management White Paper

inxire Enterprise Content Management White Paper inxire Enterprise Content Management White Paper inxire Enterprise Content Management Einleitung Die Informationstechnologie spielt eine zentrale Rolle für den Informationsaustausch und die Zusammenarbeit

Mehr

1 Einleitung. 1.1 Caching von Webanwendungen. 1.1.1 Clientseites Caching

1 Einleitung. 1.1 Caching von Webanwendungen. 1.1.1 Clientseites Caching 1.1 Caching von Webanwendungen In den vergangenen Jahren hat sich das Webumfeld sehr verändert. Nicht nur eine zunehmend größere Zahl an Benutzern sondern auch die Anforderungen in Bezug auf dynamischere

Mehr

Von der UML nach C++

Von der UML nach C++ 22 Von der UML nach C++ Dieses Kapitel behandelt die folgenden Themen: Vererbung Interfaces Assoziationen Multiplizität Aggregation Komposition Die Unified Modeling Language (UML) ist eine weit verbreitete

Mehr

Grid Computing. Einführung. Marc Lechtenfeld. Seminar Grid Computing Sommersemester 2004 Universität Duisburg-Essen

Grid Computing. Einführung. Marc Lechtenfeld. Seminar Grid Computing Sommersemester 2004 Universität Duisburg-Essen * Grid Computing Einführung Marc Lechtenfeld Seminar Grid Computing Sommersemester 2004 Universität Duisburg-Essen Übersicht 1 Problematik 2 Systemanforderungen 3 Architektur 4 Implementation 5 Projekte

Mehr

PROZESSE INTEGRIEREN leicht gemacht EFFIZIENTE PROZESSE

PROZESSE INTEGRIEREN leicht gemacht EFFIZIENTE PROZESSE PROZESSE INTEGRIEREN leicht gemacht DURCH TransConnect Geschäftsprozesse ableiten mit der Universal Worklist (UWL) Integrationsszenarien effektiver verwalten und transportieren Optimierte Personalverwaltung

Mehr

Geschäftsprozesse & Workflow: WfMC Referenzmodell

Geschäftsprozesse & Workflow: WfMC Referenzmodell Seminar E-Services WS 02/03 Geschäftsprozesse & Workflow: WfMC Referenzmodell Jacqueline Tran & Marco Glier Gliederung 1. Workflow 2. Workflow Managementsysteme (WfMS) 3. Workflow Management Coalition

Mehr

Message Oriented Middleware am Beispiel von XMLBlaster

Message Oriented Middleware am Beispiel von XMLBlaster Message Oriented Middleware am Beispiel von XMLBlaster Vortrag im Seminar XML und intelligente Systeme an der Universität Bielefeld WS 2005/2006 Vortragender: Frederic Siepmann fsiepman@techfak.uni bielefeld.de

Mehr

Softwareanforderungsanalyse

Softwareanforderungsanalyse Softwareanforderungsanalyse Evolution von Anforderungen Burkhardt Renz Institut für SoftwareArchitektur der Technischen Hochschule Mittelhessen Wintersemester 2015/16 Evolution von Anforderungen Anforderungen

Mehr

7.4 Analyse anhand der SQL-Trace. 7.3.5 Vorabanalyse mit dem Code Inspector

7.4 Analyse anhand der SQL-Trace. 7.3.5 Vorabanalyse mit dem Code Inspector 7.4 Analyse anhand der SQL-Trace 337 7.3.5 Vorabanalyse mit dem Code Inspector Der Code Inspector (SCI) wurde in den vorangegangenen Kapiteln immer wieder erwähnt. Er stellt ein paar nützliche Prüfungen

Mehr

SAP Support On Demand - IBMs kombiniertes Service-Angebot für SAP Hosting und SAP Application Management Services (AMS)

SAP Support On Demand - IBMs kombiniertes Service-Angebot für SAP Hosting und SAP Application Management Services (AMS) (IGS) SAP Support On Demand - IBMs kombiniertes Service-Angebot für SAP Hosting und SAP Application Services (AMS) Martin Kadner, Product Manager SAP Hosting, GTS Klaus F. Kriesinger, Client Services Executive,

Mehr

Softwaretechnik (Medieninformatik) Überblick: 6. Objektorientiertes Design

Softwaretechnik (Medieninformatik) Überblick: 6. Objektorientiertes Design Softwaretechnik (Medieninformatik) Überblick: 6.1 Einleitung 6.2 Verfeinerung des Klassenmodells 6.3 Sequenzdiagramme 6.4 Umsetzung der Analysekonstrukte in das Design 6.5 Fallstudie 6.6 Software Kontrakte

Mehr

09.06.2003 André Maurer andre@maurer.name www.andre.maurer.name Wirtschaftsinformatik FH 3.5 Fachhochschule Solothurn, Olten

09.06.2003 André Maurer andre@maurer.name www.andre.maurer.name Wirtschaftsinformatik FH 3.5 Fachhochschule Solothurn, Olten Aktuelle Themen der Wirtschaftsinformatik Zusammenfassung 09.06.2003 André Maurer andre@maurer.name www.andre.maurer.name Wirtschaftsinformatik FH 3.5 Fachhochschule Solothurn, Olten 1 Serverseitige Webprogrammierung

Mehr

Kurzübersicht Diplomarbeit

Kurzübersicht Diplomarbeit Thema: Konzeption und Implementierung einer Basisarchitektur für eine regelbasierte Client-/Server-Anwendung für das Workflow Management Ort: Bundesamte für Wehrtechnik und Beschaffung, Wehrtechnische

Mehr

Dipl. Inf. Ali M. Akbarian

Dipl. Inf. Ali M. Akbarian Dipl. Inf. Ali M. Akbarian 2012 Einführung Globalisierung, Innovation und Kundenzufriedenheit sind auch in Zukunft die wichtigsten Herausforderungen der Unternehmen. Diese Herausforderungen verlangen:

Mehr

Effizientes Änderungsmanagement in Outsourcing- Projekten

Effizientes Änderungsmanagement in Outsourcing- Projekten Effizientes Änderungsmanagement in Outsourcing- Projekten Dr. Henning Sternkicker Rational Software IBM Deutschland GmbH Sittarder Straße 31 52078 Aachen henning.sternkicker@de.ibm.com Abstract: Es werden

Mehr

SOA Starter Kit Einführungsstrategien und Einstiegspunkte

SOA Starter Kit Einführungsstrategien und Einstiegspunkte SOA Starter Kit Einführungsstrategien und Einstiegspunkte Benjamin Brunner Berater OPITZ CONSULTING Bad Homburg GmbH SOA Starter Kit Seite 1 Agenda Wer sollte eine SOA nutzen? Welche Ziele kann eine SOA

Mehr

PIWIN II. Praktische Informatik für Wirtschaftsmathematiker, Ingenieure und Naturwissenschaftler II. Vorlesung 2 SWS SS 08

PIWIN II. Praktische Informatik für Wirtschaftsmathematiker, Ingenieure und Naturwissenschaftler II. Vorlesung 2 SWS SS 08 PIWIN II Kap. 3: Verteilte Systeme & Rechnernetze 1 PIWIN II Praktische Informatik für Wirtschaftsmathematiker, Ingenieure und Naturwissenschaftler II Vorlesung 2 SWS SS 08 Fakultät für Informatik Technische

Mehr

ALM mit Visual Studio Online. Philip Gossweiler Noser Engineering AG

ALM mit Visual Studio Online. Philip Gossweiler Noser Engineering AG ALM mit Visual Studio Online Philip Gossweiler Noser Engineering AG Was ist Visual Studio Online? Visual Studio Online hiess bis November 2013 Team Foundation Service Kernstück von Visual Studio Online

Mehr

GeoShop Netzwerkhandbuch

GeoShop Netzwerkhandbuch Technoparkstrasse 1 8005 Zürich Tel.: 044 / 350 10 10 Fax.: 044 / 350 10 19 GeoShop Netzwerkhandbuch Zusammenfassung Diese Dokumentation beschreibt die Einbindung des GeoShop in bestehende Netzwerkumgebungen.

Mehr

Von Kleinen Apps zu Großen Produkten

Von Kleinen Apps zu Großen Produkten Von Kleinen Apps zu Großen Produkten Alexander Schulze Innotrade GmbH, Germany jwebsocket.org 13. 14. Februar 2012 Radisson Blu Hotel Hamburg, Germany Heutige Session Agenda Mitivation und Ziele Anforderungen

Mehr

Model Driven SOA. < J Springer. Anwendungsorientierte Methodik und Vorgehen in der Praxis. Gerhard Rempp Mark Akermann Martin Löffler Jens Lehmann

Model Driven SOA. < J Springer. Anwendungsorientierte Methodik und Vorgehen in der Praxis. Gerhard Rempp Mark Akermann Martin Löffler Jens Lehmann Gerhard Rempp Mark Akermann Martin Löffler Jens Lehmann Model Driven SOA Anwendungsorientierte Methodik und Vorgehen in der Praxis Mit Illustrationen von Martin Starzmann < J Springer Inhaltsverzeichnis

Mehr

IT-basierte Erstellung von Nachhaltigkeitsberichten. Diplomarbeit

IT-basierte Erstellung von Nachhaltigkeitsberichten. Diplomarbeit IT-basierte Erstellung von Nachhaltigkeitsberichten Diplomarbeit zur Erlangung des Grades eines Diplom-Ökonomen der Wirtschaftswissenschaftlichen Fakultät der Leibniz Universität Hannover vorgelegt von

Mehr

Normfall 7.2. Whitepaper. Erstellen eines Normfall Projektspeichers auf Basis einer vorhandenen Installation von:

Normfall 7.2. Whitepaper. Erstellen eines Normfall Projektspeichers auf Basis einer vorhandenen Installation von: Normfall 7.2 Whitepaper Erstellen eines Normfall Projektspeichers auf Basis einer vorhandenen Installation von: Microsoft SQL Server 2008 R2/2012/2014 2014 Normfall GmbH Alle Rechte vorbehalten. Vorbemerkungen

Mehr

16 Architekturentwurf Einführung und Überblick

16 Architekturentwurf Einführung und Überblick Teil III: Software-Architekturentwurf 16 Architekturentwurf Einführung und Überblick 16.1 Software entwerfen Warum? Beim Arbeiten im Kleinen nicht oder nur ansatzweise (Detailentwurf) Größere Software

Mehr

Projektmodell Softwareentwicklung: Unified Software Development Process / Unified Process (Teil I)

Projektmodell Softwareentwicklung: Unified Software Development Process / Unified Process (Teil I) Projektmodell Softwareentwicklung: Unified Software Development Process / Unified Process (Teil I) Historisch Kulturelle Informationsverarbeitung Hauptseminar: KLIPS 2.0 Dozent: Prof. Dr. Thaller Referent:

Mehr

Szenarien zu Hochverfügbarkeit und Skalierung mit und ohne Oracle RAC. Alexander Scholz

Szenarien zu Hochverfügbarkeit und Skalierung mit und ohne Oracle RAC. Alexander Scholz Hochverfügbar und Skalierung mit und ohne RAC Szenarien zu Hochverfügbarkeit und Skalierung mit und ohne Oracle RAC Alexander Scholz Copyright its-people Alexander Scholz 1 Einleitung Hochverfügbarkeit

Mehr

Praktikum aus Softwareentwicklung 2. Web Services. Java Praktikum SS 2010 Gerald.Ehmayer@borland.com

Praktikum aus Softwareentwicklung 2. Web Services. Java Praktikum SS 2010 Gerald.Ehmayer@borland.com Web Services Java Praktikum SS 2010 Gerald.Ehmayer@borland.com 1 Web Services Einführung Definition, Eigenschaften, Anwendungen... JAX-RPC Überblick, Architektur... JAX Übersicht, Architektur Java Praktikum

Mehr

Software Engineering mit Übungen. Franz-Josef Elmer, Universität Basel, HS 2015

Software Engineering mit Übungen. Franz-Josef Elmer, Universität Basel, HS 2015 Software Engineering mit Übungen Franz-Josef Elmer, Universität Basel, HS 2015 Software Engineering 2 Organisation Ort: Seminarraum 05.002, Spiegelgasse 5 Ablauf: 15:15 Vorlesung Prüfung: Schriftlich,

Mehr

Grundlagen des Grid Computing

Grundlagen des Grid Computing Grundlagen des Grid Computing Grid Middleware Toolkits: glite ICA Joh.. Kepler Universität t Linz glite Grid Middleware für das LHC Grid Wurde im Rahmen des EGEE Projekts entwickelt Basiert auf dem Globus

Mehr

Der erste Teil dieses Buches setzt sich grundlegend mit Postfix auseinander. Wir beginnen mit einer Einführung in das SMTP-Protokoll, dann bereiten

Der erste Teil dieses Buches setzt sich grundlegend mit Postfix auseinander. Wir beginnen mit einer Einführung in das SMTP-Protokoll, dann bereiten I. Grundlagen Der erste Teil dieses Buches setzt sich grundlegend mit Postfix auseinander. Wir beginnen mit einer Einführung in das SMTP-Protokoll, dann bereiten wir das Umfeld und das Betriebssystem für

Mehr

OpenCms jbpm Workflow Engine. OpenCms und jbpm Workflow Engine

OpenCms jbpm Workflow Engine. OpenCms und jbpm Workflow Engine OpenCms und jbpm Workflow Engine Geschäftliche Abläufe in einem Unternehmen folgen zu einem großen Prozentsatz beschreibbaren Prozessen, den so genannten Geschäftsprozessen. Diese Erkenntnis führte zum

Mehr

Remote Communications

Remote Communications HELP.BCFESDEI Release 4.6C SAP AG Copyright Copyright 2001 SAP AG. Alle Rechte vorbehalten. Weitergabe und Vervielfältigung dieser Publikation oder von Teilen daraus sind, zu welchem Zweck und in welcher

Mehr

Systeme 1. Kapitel 10. Virtualisierung

Systeme 1. Kapitel 10. Virtualisierung Systeme 1 Kapitel 10 Virtualisierung Virtualisierung Virtualisierung: Definition: Der Begriff Virtualisierung beschreibt eine Abstraktion von Computerhardware hin zu einer virtuellen Maschine. Tatsächlich

Mehr

Der BPM-Lebenszyklus in Theorie und Praxis. Prof. Dr. Mathias Weske

Der BPM-Lebenszyklus in Theorie und Praxis. Prof. Dr. Mathias Weske Der BPM-Lebenszyklus in Theorie und Praxis Prof. Dr. Mathias Weske Hasso Plattner Institut 2 An-Institut der Universität Potsdam, aus privaten Mitteln von SAP- Gründer Hasso Plattner finanziert Bachelor

Mehr

1 Einleitung. 1.1 Unser Ziel

1 Einleitung. 1.1 Unser Ziel 1 Dieses Buch wendet sich an alle, die sich für agile Softwareentwicklung interessieren. Einleitend möchten wir unser mit diesem Buch verbundenes Ziel, unseren Erfahrungshintergrund, das dem Buch zugrunde

Mehr

Informationswirtschaft II Rational Unified Process (RUP)

Informationswirtschaft II Rational Unified Process (RUP) Informationswirtschaft II Rational Unified Process (RUP) Wolfgang H. Janko, Michael Hahsler und Stefan Koch Inhalt Historische Entwicklung Kennzeichen von RUP Lebenszyklus und Phasen Arbeitsabläufe Das

Mehr

Informationswirtschaft II

Informationswirtschaft II Rational Unified Process (RUP) Informationswirtschaft II Wolfgang H. Janko, Michael Hahsler und Stefan Koch Seite 1 Inhalt Historische Entwicklung Kennzeichen von RUP Lebenszyklus und Phasen Arbeitsabläufe

Mehr

Oracle 10g und SQL Server 2005 ein Vergleich. Thomas Wächtler 39221

Oracle 10g und SQL Server 2005 ein Vergleich. Thomas Wächtler 39221 Oracle 10g und SQL Server 2005 ein Vergleich Thomas Wächtler 39221 Inhalt 1. Einführung 2. Architektur SQL Server 2005 1. SQLOS 2. Relational Engine 3. Protocol Layer 3. Services 1. Replication 2. Reporting

Mehr

Abbildung 1: Titelbild (Quelle: http://www.oobject.com/algorithmic-architecture/follymorph-continuum-group-finalpresentation/3267/)

Abbildung 1: Titelbild (Quelle: http://www.oobject.com/algorithmic-architecture/follymorph-continuum-group-finalpresentation/3267/) Abbildung 1: Titelbild (Quelle: http://www.oobject.com/algorithmic-architecture/follymorph-continuum-group-finalpresentation/3267/) Enterprise Continuum Wiederverwendung von Unternehmensarchitekturen Modul

Mehr

SOA und Prozessmanagement: Herausforderung und aktuelle Arbeiten

SOA und Prozessmanagement: Herausforderung und aktuelle Arbeiten SOA Prozessmanagement: Herausforderung aktuelle Arbeiten Projekt-Kurzvorstellung beim Gründungstreffen des EMISA-Arbeitskreises Entwicklung agiler, prozessorientierter Informationssysteme Reiner Siebert,

Mehr

ARISTAFLOW. Workflow-Funktionen in seiner Software kommen von AristaFlow. AristaFlow BPM Plattform

ARISTAFLOW. Workflow-Funktionen in seiner Software kommen von AristaFlow. AristaFlow BPM Plattform [ ARISTAFLOW [ Die Workflow-Funktionen in seiner Software kommen von AristaFlow. Das leicht zu integrierende Framework zur flexiblen Workflow-Steuerung für jede Anwendung Würden Sie ein Datenbank-Management-System

Mehr

Informelle Definitionen. Electronic Commerce. Workflow-Management. Historische Sicht. WfM etwas Neues? Geschäftsprozeßmodellierung.

Informelle Definitionen. Electronic Commerce. Workflow-Management. Historische Sicht. WfM etwas Neues? Geschäftsprozeßmodellierung. Informelle Definitionen Präzisere Definitionen folgen! Insbesondere: Workflow Geschäftsprozeß Geschäftsprozeßmodellierung und Workflow-Management Workflow / Geschäftsprozeß Arbeitsablauf in einem Betrieb

Mehr

Echtzeitfähige Ereignisgetriebene Scheduling-Strategien

Echtzeitfähige Ereignisgetriebene Scheduling-Strategien Friedrich-Alexander-Universität Erlangen-Nürnberg Ausgewählte Kapitel eingebetteter Systeme Echtzeitfähige Ereignisgetriebene Scheduling-Strategien Sven Kerschbaum 1. Einführung Bei einem eingebetteten

Mehr

Mobile Agenten am Beispiel JADE (Java Agent DEvelopment Framework) Vorstellung in der Übung zu Konzepte Verteilter Systeme

Mobile Agenten am Beispiel JADE (Java Agent DEvelopment Framework) Vorstellung in der Übung zu Konzepte Verteilter Systeme Mobile Agenten am Beispiel JADE (Java Agent DEvelopment Framework) Vorstellung in der Übung zu Konzepte Verteilter Systeme Agenda Mobile Agenten allgemein JADE - Java Agent DEvelopment Framework Anwendungsfall

Mehr

SDD System Design Document

SDD System Design Document SDD Software Konstruktion WS01/02 Gruppe 4 1. Einleitung Das vorliegende Dokument richtet sich vor allem an die Entwickler, aber auch an den Kunden, der das enstehende System verwenden wird. Es soll einen

Mehr