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

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

Aspekte von WfMS und Architekturansätze für WfMS

Aspekte von WfMS und Architekturansätze für WfMS Kapitel 8: Aspekte von WfMS und Architekturansätze für WfMS 1 Aspekte eines Workflow-Management-Systems (1) Funktionaler Aspekt: beschreibt die funktionalen Einheiten, d.h. die Workflows selbst bzw. ihre

Mehr

Java 2, Enterprise Edition Einführung und Überblick

Java 2, Enterprise Edition Einführung und Überblick Universität aiserslautern AG Datenbanken und Informationssysteme Seminar Datenbank-Aspekte des E-Commerce Java 2, Enterprise Edition Einführung und Überblick m_husema@informatik.uni-kl.de Vortragsinhalte

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

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

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

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

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

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

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

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

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

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

Abschlussklausur Geschäftsprozessmodellierung und Workflowmanagement

Abschlussklausur Geschäftsprozessmodellierung und Workflowmanagement Abschlussklausur Geschäftsprozessmodellierung und Workflowmanagement (Wintersemester 2007/2008, Freitag, 08.02.2008, Leo18) Es können maximal 120 Punkte erreicht werden. 1 Punkt entspricht etwa einer Minute

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

Informationssystemanalyse Use Cases 11 1

Informationssystemanalyse Use Cases 11 1 Informationssystemanalyse Use Cases 11 1 Use Cases Slide 1 Als ein populäres Mittel um Anforderungen zu erfassen und Systeme zu beschreiben, werden Use Cases benutzt. Sie bilden die Basis für eine umfassendere

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

Einflussfaktoren auf eine Softwarearchitektur und ihre Wechselwirkungen Entwurfsentscheidungen systematisieren

Einflussfaktoren auf eine Softwarearchitektur und ihre Wechselwirkungen Entwurfsentscheidungen systematisieren 1 Einflussfaktoren auf eine Softwarearchitektur und ihre Wechselwirkungen Entwurfsentscheidungen systematisieren W3L AG info@w3l.de 2011 2 Agenda Softwarearchitektur und Architekturentwurf Definition Überblick

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

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

EINFÜHRUNG IN DIE WIRTSCHAFTSINFORMATIK -ÜBUNGEN- Marina Tropmann-Frick mtr@is.informatik.uni-kiel.de www.is.informatik.uni-kiel.

EINFÜHRUNG IN DIE WIRTSCHAFTSINFORMATIK -ÜBUNGEN- Marina Tropmann-Frick mtr@is.informatik.uni-kiel.de www.is.informatik.uni-kiel. EINFÜHRUNG IN DIE WIRTSCHAFTSINFORMATIK -ÜBUNGEN- Marina Tropmann-Frick mtr@is.informatik.uni-kiel.de www.is.informatik.uni-kiel.de/~mtr FRAGEN / ANMERKUNGEN Vorlesung Neue Übungsaufgaben MODELLIERUNG

Mehr

Vortrag von: Ilias Agorakis & Robert Roginer

Vortrag von: Ilias Agorakis & Robert Roginer MDA Model Driven Architecture Vortrag von: Ilias Agorakis & Robert Roginer Anwendungen der SWT - WS 08/09 Inhalt Was ist MDA? Object Management Group (OMG) Ziele Konzepte der MDA Werkzeuge Vor- und Nachteile

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 und Qualität. Tjard Köbberling

Architektur und Qualität. Tjard Köbberling Architektur und Qualität Tjard Köbberling Gliederung Überblick Architektur und Qualität? Architekturentwurf Anforderungsanalyse Strukturierung Architekturbeschreibungen - Sichten Fallbeispiel 2 Architektur

Mehr

Abb. 1: Schematische Architektur WebLogic-Server

Abb. 1: Schematische Architektur WebLogic-Server Forms 11g im Weblogic-Server Vertrautes in neuem Gewand Stephan La Rocca TEAM GmbH Paderborn Schlüsselworte: Oracle Weblogic Server, Forms 11g, Administration, Konfiguration, New Features. Einleitung Mit

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

Applikationsentwicklung Architekturübungen

Applikationsentwicklung Architekturübungen Applikationsentwicklung Architekturübungen Aufgabe : Systeme und Subsysteme Gegeben ist das umfangreiche Softwaresystem eines modernen Passagierflugzeuges von der Steuerung und Navigation bis zum Bordunterhaltungssysstem

Mehr

Vortrag im Rahmen des Arbeitskreis i Informatik an der Schule. Prof. Dr. Stefan Sarstedt 04.02.2009

Vortrag im Rahmen des Arbeitskreis i Informatik an der Schule. Prof. Dr. Stefan Sarstedt 04.02.2009 Service-orientierte Architekturen (SOA) Ein Einblick Vortrag im Rahmen des Arbeitskreis i Informatik an der Schule Prof. Dr. Stefan Sarstedt 04.02.2009 Programmieren heute und damals 2009 182910* *************************************TRACE

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

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

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

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

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

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

Integration mit Service Repositories zur SOA Governance

Integration mit Service Repositories zur SOA Governance Integration mit Service Repositories zur SOA Governance Nürnberg, 10.11.2009 I N H A L T 1. SOA Governance 2. Service Repository 3. Modelle und Service Repository 4. Modell-Driven SOA I N H A L T 1. SOA

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

Online Analytical Processing

Online Analytical Processing Online Analytical Processing Online Analytical Processing Online Analytical Processing (OLAP) ermöglicht die multidimensionale Betrachtung von Daten zwecks E rmittlung eines entscheidungsunterstützenden

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

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

Wiederholung: Informelle Definitionen. Wiederholung. Wiederholung. Unser Beispiel: Dienstreise. Beobachtungen

Wiederholung: Informelle Definitionen. Wiederholung. Wiederholung. Unser Beispiel: Dienstreise. Beobachtungen Wiederholung Wiederholung: Informelle Definitionen Workflow-Management ein Modethema Historie der Management-Systeme Anwendung Anwendung Anwend. UIMS Anwend. UIMS Paradigmenwechsel: Daten -> Prozeß DBMS

Mehr

6. Modellierung von Informationssystemen. 6.1 Einleitung 6.2 Konzeptuelles Modell 6.3 OASIS Spezifikation 6.4 Execution Model 6.

6. Modellierung von Informationssystemen. 6.1 Einleitung 6.2 Konzeptuelles Modell 6.3 OASIS Spezifikation 6.4 Execution Model 6. 6. Modellierung von Informationssystemen Spezialseminar Matr. FS 2000 1/10 Volker Dobrowolny FIN- ITI Quellen: Oscar Pastor, Jaime Gomez, Emilio Insfran, Vicente Pelechano The OO-Method approach for information

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

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

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

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

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

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

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

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

Softwareanforderungsanalyse

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

Mehr

Vorlesung vom 18.04.2005 - Einführung in die geschäftsprozessorientierte Unternehmensführung

Vorlesung vom 18.04.2005 - Einführung in die geschäftsprozessorientierte Unternehmensführung Vorlesung vom 18.04.2005 - Einführung in die geschäftsprozessorientierte Unternehmensführung 08.30 Begrüßung durch Dipl.-Kfm. Björn Simon organisatorische Grundlagen der Veranstaltung (Hinweis auf obligatorische

Mehr

Übungen zu Softwaretechnik

Übungen zu Softwaretechnik Prof. Dr. Dr. h.c. M. Broy Lösungsblatt 11 Dr. H. Ehler, S. Wagner 23. Januar 2004 Übungen zu Softwaretechnik Aufgabe 16 Qualitätseigenschaften Broker-Pattern Beurteilen Sie das in Aufgabe 15 benutzte

Mehr

OTRS-TFS-Konnektor. Whitepaper. Autor: advanto Software GmbH Mittelstraße 10 39114 Magdeburg

OTRS-TFS-Konnektor. Whitepaper. Autor: advanto Software GmbH Mittelstraße 10 39114 Magdeburg OTRS-TFS-Konnektor Whitepaper Autor: advanto Software GmbH Mittelstraße 10 39114 Magdeburg Tel: 0391 59801-0 Fax: 0391 59801-10 info@advanto-software.de Stand: Mai 2015 Inhaltsverzeichnis 1 Idee... 3 2

Mehr

Java Applet Alternativen

Java Applet Alternativen White Paper Java Applet Alternativen Version 1.0, 21.01.2014 Tobias Kellner tobias.kellner@egiz.gv.at Zusammenfassung: Aufgrund diverser Meldungen über Sicherheitslücken in Java haben in letzter Zeit Browser-Hersteller

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

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

Standard Inhaltsverzeichnis für Software-Anforderungsspezifikation

Standard Inhaltsverzeichnis für Software-Anforderungsspezifikation Standard Inhaltsverzeichnis für Software-Anforderungsspezifikation Inhaltsverzeichnis 1. Zweck, Veranlassung... 1 2. Allgemeines... 1 2.1 Zweck der Software-Anforderungsspezifikation... 1 2.2 Freigabe

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

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

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

Technische Beschreibung: EPOD Server

Technische Beschreibung: EPOD Server EPOD Encrypted Private Online Disc Technische Beschreibung: EPOD Server Fördergeber Förderprogramm Fördernehmer Projektleitung Projekt Metadaten Internet Foundation Austria netidee JKU Linz Institut für

Mehr

Musteraufbau eines Anforderungsprofils zur Einführung neuer Software

Musteraufbau eines Anforderungsprofils zur Einführung neuer Software Musteraufbau eines Anforderungsprofils zur Einführung neuer Software Ottostr. 15 96047 Bamberg Tel. +49/951/98046200 Fax +49/951/98046150 email: info@softcondev.de www: softcondev.de INHALT Vorwort Diese

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

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

Softwaretechnik. Fomuso Ekellem WS 2011/12

Softwaretechnik. Fomuso Ekellem WS 2011/12 WS 2011/12 Inhalt Wiederholung Weitere Begriffe Programmierung im Großem (Programmierung von Software als Ganzes) Prozess-Modelle 2 Wiederholung: Prozesse Prozesse sind hierarchische Gruppierungen von

Mehr

4 Architektur-Perspektiven (WO)

4 Architektur-Perspektiven (WO) 4 Architektur-Perspektiven (WO) Abb. 4-1: Positionierung des Kapitels im Ordnungsrahmen. Dieses Kapitel befasst sich mit der WO-Dimension des architektonischen Ordnungsrahmens. Es erläutert, auf welchen

Mehr

Business Process Execution Language for Web Services (BPEL4WS)

Business Process Execution Language for Web Services (BPEL4WS) Hauptseminar und Vorlesung Web Services WS 2003/04 Business Process Execution Language for Web Services (BPEL4WS) Patrick Sauter 2/17 Vortrag - Überblick Definition, Zielsetzung und Allgemeines einfacher

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

Marketing Update. Enabler / ENABLER aqua / Maestro II

Marketing Update. Enabler / ENABLER aqua / Maestro II Marketing Update Enabler / ENABLER aqua / Maestro II Quartal 01/2012 1 Kommentar des Herausgebers Liebe Kunden und Partner, dieser Marketing Update gibt Ihnen einen kurzen Überblick über die aktuell verfügbaren

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

Grid-Systeme. Betrachtung verschiedener Softwareplattformen zur Realisierung von Grids und Vorstellung des Globus Toolkit. 07.06.2002 Grid Systeme 1

Grid-Systeme. Betrachtung verschiedener Softwareplattformen zur Realisierung von Grids und Vorstellung des Globus Toolkit. 07.06.2002 Grid Systeme 1 Grid-Systeme Betrachtung verschiedener Softwareplattformen zur Realisierung von Grids und Vorstellung des Globus Toolkit 07.06.2002 Grid Systeme 1 Gliederung Vorstellung verschiedener Plattformen Globus

Mehr

Without knowledge management our services would be unthinkable. Arthur D. Little

Without knowledge management our services would be unthinkable. Arthur D. Little Without knowledge management our services would be unthinkable. Arthur D. Little Weshalb Wissensmanagement? Wissen ist die Gesamtheit der Informationen, Kenntnisse und Fähigkeiten einer Person, die zur

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

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

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

Eignet sich Eclipse RCP als Enterprise Plattform? 2. Mai 2006 Lars Stucki & Edwin Steiner www.inventage.com

Eignet sich Eclipse RCP als Enterprise Plattform? 2. Mai 2006 Lars Stucki & Edwin Steiner www.inventage.com Eignet sich Eclipse RCP als Enterprise Plattform? 2. Mai 2006 Lars Stucki & Edwin Steiner www.inventage.com Eignet sich Eclipse RCP als Enterprise Plattform? Einführung Demos Corporate Governance Asset

Mehr

Der Rational Unified Process

Der Rational Unified Process Philippe Kruchten Der Rational Unified Process Eine Einführung Deutsche Übersetzung von Cornelia Versteegen An imprint of Pearson Education München Reading, Massachusetts Menlo Park, California New York

Mehr

Grundlagen Software Engineering

Grundlagen Software Engineering Grundlagen Software Engineering Rational Unified Process () GSE: Prof. Dr. Liggesmeyer, 1 Rational Unified Process () Software Entwicklungsprozess Anpassbares und erweiterbares Grundgerüst Sprache der

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

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

WSO2 Middleware Platform Vorlesungsbegleitendes Praktikum soa

WSO2 Middleware Platform Vorlesungsbegleitendes Praktikum soa WSO2 Middleware Platform Vorlesungsbegleitendes Praktikum soa Dr. Stefan Pietschmann, PF Service-Oriented Enterprise Applications, T-Systems MMS Dresden, 22.10.2013 About US PF42 Service-oriented enterprise

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

Java und XML 2. Java und XML

Java und XML 2. Java und XML Technische Universität Ilmenau Fakultät für Informatik und Automatisierung Institut für Praktische Informatik und Medieninformatik Fachgebiet Telematik Java und XML Hauptseminar Telematik WS 2002/2003

Mehr

Workflowmanagement. Business Process Management

Workflowmanagement. Business Process Management Workflowmanagement Business Process Management Workflowmanagement Workflowmanagement Steigern Sie die Effizienz und Sicherheit Ihrer betrieblichen Abläufe Unternehmen mit gezielter Optimierung ihrer Geschäftsaktivitäten

Mehr

COMOS/SAP-Schnittstelle

COMOS/SAP-Schnittstelle COMOS/SAP-Schnittstelle White Paper Optimierter Datenaustausch zwischen COMOS und SAP Juni 2010 Zusammenfassung Ein konsistenter Datenaustausch zwischen Engineering-Anwendungen und ERP-Systemen ist heutzutage

Mehr

1. Grundbegriffe des Software-Engineering

1. Grundbegriffe des Software-Engineering 1. Grundbegriffe Software Engineering 1 1. Grundbegriffe des Software-Engineering Was ist Software-Engineering? (deutsch: Software-Technik) Teilgebiet der Informatik, das sich mit Methoden und Werkzeugen

Mehr

Grundlagen von Datenbanken

Grundlagen von Datenbanken Grundlagen von Datenbanken Aufgabenzettel 1 Grundlagen Datenbanken: Kurzer historischer Überblick (1) Anwendung 1 Anwendung 2 Datei 1 Datei 2 Datei 3 Zugriff auf Dateien ohne spezielle Verwaltung 2 Exkurs:

Mehr

Software Engineering Analyse und Analysemuster

Software Engineering Analyse und Analysemuster Software Engineering Analyse und Analysemuster Prof. Adrian A. Müller, PMP, PSM 1, CSM Fachbereich Informatik und Mikrosystemtechnik 1 Klassendiagramme in der Analyse Im Rahmen der Anforderungsanalyse

Mehr

Metadata Service Respository (MDS) - Sehen, lernen, verstehen!

Metadata Service Respository (MDS) - Sehen, lernen, verstehen! Metadata Service Respository (MDS) - Sehen, lernen, verstehen! Carsten Wiesbaum esentri AG Schlüsselworte Metadata Service Repository, MDS, Oracle Fusion Middleware Einleitung Früher oder später wird jeder

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

4 Planung von Anwendungsund

4 Planung von Anwendungsund Einführung 4 Planung von Anwendungsund Datenbereitstellung Prüfungsanforderungen von Microsoft: Planning Application and Data Provisioning o Provision applications o Provision data Lernziele: Anwendungen

Mehr

Bachelor Thesis an der Fachhochschule Kiel, Fachbereich Wirtschaft. Sommersemester 2011. : Prof. Dr. Doris Weßels

Bachelor Thesis an der Fachhochschule Kiel, Fachbereich Wirtschaft. Sommersemester 2011. : Prof. Dr. Doris Weßels Handlungsempfehlungen zur Nutzung von Social Media zur Gestaltung von Wissensmarktplätzen am Beispiel des europäischen Förderprojektes Win-Vin: Wissen nutzen im Norden Bachelor Thesis an der Fachhochschule

Mehr

4 Grundlagen der Datenbankentwicklung

4 Grundlagen der Datenbankentwicklung 4 Grundlagen der Datenbankentwicklung In diesem Kapitel werden wir die Grundlagen der Konzeption von relationalen Datenbanken beschreiben. Dazu werden Sie die einzelnen Entwicklungsschritte von der Problemanalyse

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

VBA-Programmierung: Zusammenfassung

VBA-Programmierung: Zusammenfassung VBA-Programmierung: Zusammenfassung Programmiersprachen (Definition, Einordnung VBA) Softwareentwicklung-Phasen: 1. Spezifikation 2. Entwurf 3. Implementierung Datentypen (einfach, zusammengesetzt) Programmablaufsteuerung

Mehr

3 Anwendungsarchitektur und Entwicklungsumgebung

3 Anwendungsarchitektur und Entwicklungsumgebung 21 3 Anwendungsarchitektur und Bei den Entwicklern von Web-basierten Dialogsystemen hat sich im Laufe der Zeit eine Vorgehensweise im Design von Anwendungen entwickelt, dies es ermöglicht, flexible Web-Dialoge

Mehr

Automatisierte Durchführung von Transporten in der Automic (UC4) Automation Engine - ONE Automation

Automatisierte Durchführung von Transporten in der Automic (UC4) Automation Engine - ONE Automation WF2Trans Automatisierte Durchführung von Transporten in der Automic (UC4) Automation Engine - ONE Automation Aus unserer langjährigen Erfahrung in Kundenprojekten wissen wir, dass ein klares und eindeutiges

Mehr

Enterprise Service Bus

Enterprise Service Bus Enterprise Service Bus Christopher Weiß 25.01.2010 Gliederung 1 Motivation und Einordung Integrationsformen 2 Definition und Eigenschaften Definitionen Eigenschaften 3 Aufbau und Konzepte Aufbau Produkte

Mehr

Software Design Patterns. Ausarbeitung über. Security Patterns SS 2004

Software Design Patterns. Ausarbeitung über. Security Patterns SS 2004 Ausarbeitung über SS 2004 Dennis Völker [dv04@hdm-stuttgart.de] Steffen Schurian [ss59@hdm-stuttgart.de] Überblick Sicherheit sollte eine Eigenschaft moderner, verteilter Anwendungen sein, jedoch ist ein

Mehr