A Patternkatalog. A.1 Abstract Factory. A.2 Agent. A.3 Application Controller

Transkript

1 A Patternkatalog A.1 Abstract Factory Es sollen Objekte in einer objektorientierten Klassenbibliothek erzeugt werden. Ein System soll von der Erzeugung, Zusammensetzung und Repräsentation seiner Objekte unabhängig sein. Die Objekte gehören verschiedenen Objektfamilien an, die für das System konfiguriert werden können. Innerhalb dieser Objektfamilien bestehen Abhängigkeiten zwischen den Objekten, die sichergestellt werden sollen. Eine Klassenbibliothek besitzt Objekte von denen nur ihre Schnittstellen bekannt sind und deren Implementierung gekapselt werden soll (Bridge (140)). Eine Abstract Factory kapselt das Erzeugen von Objekten und Objektfamilien. Sie besitzt für jedes zu erzeugende Objekt eine Methode. Dafür werden abstrakte Objekte definiert, deren Implementierung von der Abstract Factory zurückgegeben wird. Somit bleibt die Implementation der Objekte gekapselt und Systeme, welche die Abstract Factory benutzen bleiben unabhängig davon. Bridge (140), Layers (150), Singleton (163) (Gamma et al. 1997) A.2 Agent Genaue Erläuterungen sind im Kapitel 3.4 Agententechnologie zu finden. Self Service (159) (Adams et al. 2002) A.3 Application Controller Eine Anwendung benötigt für die Benutzeroberfläche eine Steuerungslogik. Einige Anwendungen besitzen sehr viel Logik in der Navigation durch die Bildschirmmasken. Diese Anwendungen besitzen definierte Regeln über die Struktur

2 140 A Patternkatalog der Benutzeroberfläche und Regeln in welcher Reihenfolge die Bildschirmmasken gezeigt werden. Diese sind zumeist abhängig von zuvor eingegebenen Werten o- der anderen Zuständen des Systems. Ein Application Controller bietet einen zentralen Punkt für die Behandlung der Navigation durch Bildschirmmasken und kontrolliert die Ablauflogik der Applikation. Hierfür verwaltet der Application Controller Kommandos, die auf das Datenmodell zugreifen und liefert danach, je nach Status des Systems oder des Kommandos, die richtige Anzeigemaske. Model View Controller (157), Front Controller (149), Domain Model (147) (Fowler 2003) A.4 Bridge Die Implementation einer Abstraktion soll von dieser entkoppelt werden, um sie unabhängig voneinander zu verändern, zu erweitern und wiederzuverwenden. Eine Abstraktion kann mehrere Implementationen besitzen, die in der objektorientierten Programmierung durch Vererbung realisiert werden kann. Dies bindet allerdings die Abstraktion und ihre Implementation eng aneinander. Das Brückenmuster trennt die Abstraktion von der Implementierung, in dem zwei unterschiedliche Klassenhierarchien verwaltet werden. Demnach gibt es eine Klassenhierarchie für die Schnittstellenbeschreibung und eine Klassenhierarchie für die spezifische Implementation. Alle Operationen der Implementation werden durch die Schnittstelle definiert. Somit können Implementationen von Klassenbibliotheken verändert werden, ohne die Struktur der Bibliothek an sich zu ändern. Das erlaubt zum Beispiel, dass ein erneutes Kompilieren der Programme, welche die Klassenbibliothek benutzen, bei Änderungen der Implementation nicht notwendig ist. Abstract Factory (139) (Gamma et al. 1997) A.5 Canonical Datamodel Alias Canonical Data Model Canonical Data Model(141)

3 A.6 Canonical Data Model 141 A.6 Canonical Data Model Applikationen, welche eigene Datenformate besitzen sollen über Messaging (156) integriert werden. Bei der Übertragung der Nachrichten kann zwischen zwei Applikationen ein Übersetzer (Message Translator (156)) benutzt werden, der die Nachrichten aus der einen Anwendung in die andere übersetzt und umgekehrt. Steigt allerdings die Anzahl der Anwendungen, die miteinander integriert werden sollen, führt dies zu einer großen Menge an Übersetzern, da für jede Verbindung zweier Applikationen ein Übersetzer benötigt wird. Zum Beispiel existieren bei sechs Applikationen, die alle miteinander integriert werden sollen 15 Übersetzer. Applikationen sollen über Messaging (156) integriert werden. Durch den Einsatz eines Canonical Data Model lässt sich die Anzahl der benötigten Übersetzer reduzieren. Ein Canonical Data Model stellt ein zentrales Datenmodell dar, welches applikationsunabhängig ist. Danach wird nur noch für jede Applikation ein Übersetzer benötigt, der aus dem und in das Canonical Data Model übersetzt. Von 15 Übersetzern werden dann nur noch sechs benötigt. Messaging (156), Message Translator (156), Mediator (152) (Hohpe et al. 2003) A.7 Command Alias Action, Transaction Im Bereich der Application Integration sollen Applikationen Anfragen an andere richten können. Aber auch bei der objektorientierten Entwicklung richten Objekte Anfragen an andere Objekte. Für ein Objekt soll ein Verhalten abgebildet werden. Durch ein Command wird ein Befehl als ein Objekt gekapselt. Dadurch können Anfragen parametrisiert, verwaltet, überwacht und rückgängig gemacht werden. Command Message (142), Application Controller (139) (Gamma et al. 1997)

4 142 A Patternkatalog A.8 Command Message Applikationen sollen im Rahmen der Application Integration Befehle an andere Applikationen richten. Applikationen benötigen oftmals Funktionen aus anderen Applikationen. Dafür können so genannte Remote Procedure Calls benutzt werden. Doch diese setzen eine synchrone Kommunikation voraus, so dass sie nicht für den Einsatz im Bereich Messaging (156) geeignet sind. Die Befehlsdaten werden mit Hilfe einer Command Message über das Messaging- System an eine andere Applikation gesendet. Diese Kommunikation erfolgt über einen Message Channel (153) und asynchron. Document Message (145), Event Message (147), Messaging (156), Message (152), Command (141) (Hohpe et al. 2003) A.9 Comparator Es sollen Sortieralgorithmen unabhängig von den zu sortierenden Objekten implementiert werden. Die Grundfunktion eines Sortieralgorithmus ist der Vergleich zweier Elemente (Sedgewick 1992). Für die Schaffung einer einheitlichen Schnittstelle zum Vergleich zweier Objekte wird ein Vergleicher (Comparator) eingesetzt. Einem Comparator werden zwei Objekte übergeben. Er vergleicht sie und liefert ein Ergebnis zurück, ob das erste Objekt größer, kleiner oder gleich groß ist. Für jeden Objekttyp kann so ein Comparator zur Verfügung gestellt werden, der zu jeder Zeit wiederverwendet werden kann.

5 A.10 Composite 143 interface Component +sampleoperation:void composite:composite 0..* Leaf Leaf Composite Composite -componentvector:vector +sampleoperation:void composite:composite +sampleoperation:void +add:void +remove:void +components:enumeratio composite:composite Abbildung 60: Klassendiagramm für ein Composite-Pattern A.10 Composite Bei der Programmierung eines Zeichenprogrammes können unterschiedliche Formen, wie Kreise, Rechtecke, Linien usw. erstellt werden. Der Benutzer kann diese einfachen Formen zu komplexeren Strukturen gruppieren, die wiederum Bestandteil einer größeren Struktur sein können. In Abbildung 60 ist ein Klassendiagramm für ein Composite-Pattern dargestellt. Das Interface Component definiert eine Methode sampleoperation, die von allen abgeleiteten Klassen (hier Composite für ein zusammengesetztes Objekt und Leaf für ein einfaches Objekt) implementiert werden muss. Somit ist für alle Bestandteile einer größeren Struktur gesichert, dass sie die gleiche Methode besitzen, die Implementierung jedoch unterschiedlich sein kann. A.11 Content-Based Router Eine betriebswirtschaftliche Transaktion (logisch eigenständige Funktion) soll durchgeführt werden. Dafür werden zwei unterschiedliche Applikationen benötigt, so dass sich die Transaktion in zwei Teile aufteilt. Für die Integration der beiden Applikationen soll Messaging (156) eingesetzt werden.

6 144 A Patternkatalog Durch den Einsatz eines Content-Based Routers wird jede Nachricht, basierend auf den Daten, an den richtigen Empfänger transportiert. Beispiel Eingehende Bestellungen sollen geprüft werden, ob die Güter in den Lagern vorhanden sind. Das Unternehmen besitzt zwei Lager (Plüschelefanten und Gummibälle). Jedes Lager hat sein eigenes Lagerverwaltungssystem. Je nach Typ der eingehenden Bestellung (Plüschelefanten oder Gummibälle) wird eine Prüfanforderung mit Hilfe eines Content-Based Router an das entsprechende Lager geschickt. Messaging (156), Message (152) (Hohpe et al. 2003) A.12 Content Enricher Zwei Applikationen sollen mit Hilfe von Messaging (156) integriert werden, obwohl eine dieser Applikationen nicht sämtliche für die Kommunikation notwendigen Daten besitzt. Durch die Nutzung eines Content Enricher werden die fehlenden Daten durch das Messaging-System hinzugefügt. Messaging (156), Message Translator (156) (Hohpe et al. 2003) A.13 Correlation Identifier Zwei Applikationen sind durch Messaging (156) miteinander verbunden. Sie nutzen für die Kommunikation einen Request-Reply (161)-Muster. Bei einer asynchronen Kommunikation über Messaging (156) können Anfragenachricht und Antwortnachricht nicht zugeordnet werden. Jeder Antwortnachricht wird ein Correlation Identifier zugeordnet, welcher dem eindeutigen Identifier der Anfragenachricht entspricht. Somit ist die Antwort der Anfrage zugeordnet. Messaging (156), Request-Reply (161) (Hohpe et al. 2003)

7 A.14 Document Message 145 A.14 Document Message Zwei Applikationen sind durch Messaging (156) miteinander verbunden. Die Applikationen sollen Daten miteinander austauschen. Dabei soll die Datenstruktur erhalten bleiben. Durch die Nutzung einer Document Message können Datenstrukturen zuverlässig übertragen werden. Der Unterschied zu einer Command Message (142) ist, dass bei einer Document Message der Empfänger entscheidet, wie er diese Nachricht weiterverarbeitet. Bei einer Command Message (142) wird dagegen der Empfänger aufgefordert einer bestimmte Funktion auszuführen. Document Message wird im Zusammenhang von Request-Reply (161) verwendet und als Antwort auf eine Command Message (142) gesendet. Messaging (156), Command Message (142), Event Message (147), Message (152) (Hohpe et al. 2003) A.15 Data Transfer Object Alias Value Object Zwei Komponenten sollen miteinander verbunden werden. Dafür stehen Schnittstellen zur Verfügung. Die Integration erfolgt durch eine Form von Remote Procedure Calls (zum Beispiel über Messaging (156)). Bei der Integration zweier Komponenten über entfernte Schnittstellen, können Aufrufe teuer sein. Beim Messaging (156) werden für jeden solchen Aufruf Nachrichten über ein Netzwerk verschickt, das kostet Zeit und eventuell Geld. Ein Data Transfer Object transportiert Daten zwischen Komponenten, um die Anzahl der Methodenaufrufe zu reduzieren. Es kann ebenfalls genutzt werden, um Daten zwischen zwei Schichten (Layers (150)) zu transportieren. Dafür werden mit einem Aufruf sämtliche Daten zurückgesendet die benötigt werden. Document Message (145), Command Message (142), Messaging (156), Layers (150), Service Layer (162) (Fowler 2003)

8 146 A Patternkatalog A.16 Datatype Channel Zwei Applikationen sollen über Message Channel (153) miteinander kommunizieren. Dabei senden sie verschiedene Typen von Nachrichten. Der Empfänger kann nicht unterscheiden, um welchen Typ von Nachricht es sich handelt, da diese bei der Nutzung nur eines Kanals gemischt werden. Für jeden Nachrichtentyp wird ein Datatype Channel eingerichtet, auf dem nur ein bestimmter Typ von Nachrichten gesendet wird. Der Empfänger kann so die Nachrichten unterscheiden. Eine weitere Möglichkeit diese Unterscheidung zu treffen ist die Nutzung eines Content-Based Router (143). Message (152), Message Channel (153), Messaging (156) (Hohpe et al. 2003) A.17 Decorator Alias Wrapper Es soll ein objektorientiertes Datenmodell erstellt werden. Eine Klasse soll um Funktionalität erweitert werden, ohne von dieser zu erben o- der diese Klasse zu verändern. Ein Decorator erweitert Objekte dynamisch um Zuständigkeiten. Er stellt eine flexible Möglichkeit dar, um Unterklassen zu bilden. Dabei wird einer Klasse Funktionalität hinzugefügt, ohne von der Klasse zu erben oder sie zu verändern. Zusätzlich besitzt der Decorator die gleiche Schnittstelle wie die zu erweiternde Klasse. Er leitet Funktionsaufrufe weiter und führt vor oder nach dem Weiterleiten zusätzliche Operationen aus. (Gamma et al. 1997)

9 A.18 Dependent Mapping 147 A.18 Dependent Mapping Bei der Gestaltung der Datenbankanbindung soll das Domain Model (147) (objektorientierte Datenstruktur) in eine relationale Struktur überführt werden. Für das Design der Software sind, für das Domain Model (147) und die Datenbankanbindung, verschiedene Layers (150) vorgesehen. In der objektorientierten Modellierung können zwei Klassen durch eine Komposition assoziiert werden. Dabei hat eine Klasse die Verantwortung über die andere Klasse, da diese eigentlich wesentlicher Bestandteil ist. In der Datenanbindungsschicht wird eine Klasse modelliert, welche die Abhängigkeitsbeziehung der beiden Klassen aus dem Domain Model (147) abbildet. Sie ist dafür verantwortlich, dass die entsprechenden Daten für beide Modellobjekte mit der Datenbank abgeglichen werden. Diese Abbildung zwischen Domain Model (147) und Datenbankanbindungsschicht nennt sich Dependent Mapping. Domain Model (147), Layers (150), Foreign Key Mapping (148) (Fowler 2003) A.19 Domain Model Bei der objektorientierten Anwendungsentwicklung soll das Datenmodell des Fachgebiets abgebildet werden. Das Fachgebietsmodell ist sehr komplex und besitzt viele Regeln und logische Abhängigkeiten. Die Objekte und Abhängigkeiten werden als Domain Model modelliert. Ein Domain Model ist ein Objektmodell, welches Daten und Verhalten gleichzeitig beinhaltet. (Fowler 2003) Event Message Applikation sind mit Messaging (156) verbunden.

10 148 A Patternkatalog Um Funktionsabläufe abstimmen zu können, werden Ereignismeldungen benötigt. Die Ereignismeldungen werden in einer Event Message verschickt. Sie dient der zuverlässigen und asynchronen Übertragung von Ereignismeldungen zwischen Applikationen. Command Message (142), Document Message (145), Messaging (156) (Hohpe et al. 2003) A.20 Filter Alias Pipes and Filters Pipes and Filters (158) A.21 Filter Chain Alias Pipes and Filters Pipes and Filters (158) A.22 Foreign Key Mapping Bei der Gestaltung der Datenbankanbindung soll das Domain Model (147) (objektorientierte Datenstruktur) in eine relationale Struktur überführt werden. Für das Design der Software sind, für das Domain Model (147) und die Datenbankanbindung, verschiedene Layers (150) vorgesehen. In der objektorientierten Modellierung können Klassen durch eine Aggregation verbunden sein. Dabei unterhält das Objekt einer Klasse mehrere Beziehungen zu Objekten der anderen Klasse (zum Beispiel: es gibt mehrere Hersteller für Plüschelefanten). Diese Assoziationsform kann durch Fremdschlüsselbeziehungen abgebildet werden. Dabei werden zwei Tabellen in der Datenbank angelegt (je Klasse eine Tabelle), wobei in der einen Tabelle die Primärschlüssel der assoziierten Tabelle als Fremdschlüssel speichert.

11 A.23 Front Controller 149 Dependent Mapping (147) (Fowler 2003, Heuer/Saake 1997) A.23 Front Controller Es soll eine Präsentationsschicht modelliert werden. Bei komplexen Benutzerschnittstellen kann es vorkommen, dass viele redundante Funktionen (zum Beispiel: Sicherheitsmechanismen oder Internationalisierungen) durchgeführt werden. Wenn jede Darstellungsmaske diese Funktionen implementiert, entsteht redundanter Code. Durch die Zusammenfassung der redundanten Bestandteile in einem Front Controller werden die Redundanzen beseitigt. Der Front Controller verarbeitet sämtliche Anfragen an die Benutzerschnittstelle und leitet nach der Ausführung der gleichen Funktionen die Anfrage an die entsprechende Darstellungslogik (Command (141)) weiter. Model View Controller (157), Application Controller (139) (Fowler 2003) A.24 Gateway Es soll ein Zugriff auf ein externes System oder eine externe Ressource geschaffen werden. Das externe System oder die externe Ressource besitzt eine eigene Schnittstelle (API). Wenn dieses externe System über diese API angebunden werden soll, wird das eigene System stark an dieses externe System gebunden. Durch die Schaffung einer generischen Schnittstelle als Gateway kann der Zugriff auf ein externes System über die spezielle API gekapselt werden. Dies ermöglicht ein Austauschen des externen Systems durch ein anderes mit der gleichen Aufgabe, ohne die Schnittstelle zu verändern. Der API-abhängige Code wird im Gateway zusammengefasst. Canonical Data Model(141) (Fowler 2003)

12 150 A Patternkatalog A.25 Identity Field Relationale Datenbanken ordnen jeder Datenreihe in einer Datenbanktabelle einen Primärschlüssel zu. Wenn eine Datenbank als Datenspeicher genutzt werden soll, müssen die Objekte im Arbeitsspeicher den Daten in der Datenbank zugeordnet werden können. Wenn der Primärschlüssel aus der Datenbank im Objekt als Identity Field gespeichert wird, kann dieses Objekt in der Datenbank zugeordnet werden. Foreign Key Mapping (148) (Fowler 2003) A.26 Iterator Es gibt verschiedene Implementierungen von Sammlungen (z. B. Listen oder Sets), die Objekte speichern. Alle Sammlungen müssen einen Mechanismus für das Auffinden eines Objektes bereitstellen. Ist dieser Mechanismus durch eine Schnittstelle vereinheitlicht, so bleibt die genaue Implementierung einer Sammlung verborgen. Auf diese Sammlung soll zugegriffen werden, um zum Beispiel die einzelnen Objekte in dieser Sammlung zu bearbeiten. Durch einen Iterator wird eine einheitliche Schnittstelle geschaffen, um auf Objekte in einer Sammlung zuzugreifen. (Gamma et al. 1997) A.27 Layers Es soll ein System entworfen werden, das Aufgaben auf verschiedenen Ebenen verbindet, und dafür die Operationen (Dienste) der unteren Ebenen benutzen soll. Ein System, dessen Größe eine Zerlegung erfordert. (Buschmann et al. 1998) Durch das Layer-Muster können Anwendungen strukturiert werden, die in Abstraktionsebenen mit Teilaufgaben zerlegbar sind. Dafür wird eine geeignete Anzahl von Schichten definiert, die aufeinander aufbauen. Begonnen wird auf der un-

13 A.28 Layer Supertype 151 tersten Schicht, welche die Basis des Systems darstellt. Danach werden die darauf aufbauenden Schichten definiert, die eine Strategie darstellen, um die Dienste der darunterliegenden Schicht zu verknüpfen. Buschmann et al A.28 Layer Supertype Ein Softwaremodell wurde in unabhängige Schichten Layers (150) aufgeteilt. Es kann vorkommen, dass die Objekte einer Schicht gleiche Funktionen besitzen, wie zum Beispiel das Speichern eines Identity Field (150). Die gleichen Funktionen werden in einem Layer Supertype zusammengefasst. Layers (150) (Fowler 2003) A.29 Lazy Load Objekte müssen erzeugt werden. Beim Erzeugen werden diese Objekte mit Daten gefüllt. Es gibt Objekte, die beim Erzeugen mit Daten aus einer Datenbank gefüllt werden müssen. In komplexen Modellen müssen dafür auch noch andere Objekte erzeugt werden. Dies kann dazu führen, dass die Objektinitialisierung viel Zeit in Anspruch nimmt. Ein Objekt, was beim Erzeugen nicht sämtliche Daten aus der Datenbank lädt. Durch diesen Lazy Load kann der Datenbankzugriff bei der Objekterzeugung optimiert werden. Die restlichen Daten werden nachgeladen, wenn sie benötigt werden. (Fowler 2003)

14 152 A Patternkatalog A.30 Mediator Zwei Objekte oder Systeme sollen miteinander verbunden werden. Jedes dieser Objekte besitzt eine Schnittstelle. Wenn diese Objekte expliziten Bezug aufeinander nehmen, sind sie stark voneinander abhängig. Durch einen Mediator kann das Zusammenspiel der Objekte gekapselt werden. Er fördert die lose Kopplung der Objekte, indem er den direkten Bezug untereinander verhindert. Somit kann das Zusammenspiel der Objekte unabhängig verändert werden. Canonical Data Model(141) (Gamma et al. 1997) A.31 Message Zwei Applikationen (Message Endpoint (154)) werden durch Messaging (156) verbunden und sollen Daten über Message Channel (153) austauschen. Daten werden meist nicht als kontinuierlicher Datenstrom übertragen. Die Daten besitzen zudem eine eigene Struktur. Mithilfe von Messages werden diese Daten in ein einheitliches Format gebracht und können so durch einen Message Channel (153) übertragen werden. Eine Message (Nachricht) besteht deswegen aus Informationen für das Messaging-System und den Daten, die übertragen werden sollen. Die Daten für das Messaging-System, wie Sender, Empfänger etc. werden im Nachrichtenkopf gespeichert. Die zu übertragenden Applikationsdaten werden im Nachrichtenrumpf verpackt. Message Channel (153), Messaging (156), Document Message (145), Command Message (142), Event Message (147), Message Endpoint (154) (Hohpe et al. 2003)

15 A.32 Message Bus 153 A.32 Message Bus Es existieren verschiedene Systeme, die miteinander Daten austauschen sollen. Diese Systeme arbeiten selbstständig und sollen miteinander über Messaging (156) kommunizieren. Zwischen den Systemen besteht eine lose Kopplung, was bedeutet, dass diese Systeme nicht stark voneinander abhängig sind. Es sollen also Systeme zum Messaging-System hinzugefügt oder entfernt werden können, ohne die anderen Systeme zu stören. Message Bus stellt einen Kommunikationsmediator dar und strukturiert die verbindende Middleware zwischen den Systemen, so dass sie über Messaging (156) miteinander arbeiten können. Der Message Bus übernimmt dabei Aufgaben wie das Hinzufügen, Entfernen und Suchen von Systemen. Mediator (152), Messaging (156), Message Channel (153) (Hohpe et al. 2003) A.33 Message Channel Es existieren zwei Applikationen, die über Messaging (156) kommunizieren sollen. Diese Applikationen benötigen ein Messaging-System, welches den Austausch von Nachrichten ermöglicht. Durch einen Message Channel können Applikationen Nachrichten austauschen. Dabei schreibt die eine Applikation in den Message Channel, während die andere Applikation Nachrichten aus dem Message Channel liest. Messaging (156), Message Bus (153), Message (152), Request-Reply (161), Pointto-Point Channel(158), Publish-Subscribe Channel (159) (Hohpe et al. 2003)

16 154 A Patternkatalog A.34 Message Dispatcher Eine Applikation benutzt Messaging (156), um mit anderen Applikationen zu kommunizieren. Diese Applikation besitzt verschiedene Konsumenten von Nachrichten an einem einzigen Message Channel (153). Diese Konsumenten müssen koordiniert werden. Ein Message Dispatcher stellt einen Kommunikationsendpunkt (Message Endpoint (154)) dar. Dieser liest Nachrichten aus dem Message Channel (153) und verteilt diese an die Konsumenten der Applikation. Beispiel Ein Agentensystem soll mit einem anderen Agentensystem durch Messaging (156) zusammenarbeiten. Die Agenten der Agentensysteme sind die eigentlichen Konsumenten der Nachrichten. Deswegen wird auf jedem Agentensystem ein Message Dispatcher benötigt, der die Nachrichten an den richtigen Agenten weiterreicht. Messaging (156), Message Endpoint (154), Message Channel (153), Message (152), Agent (139) (Hohpe et al. 2003) A.35 Message Endpoint Applikationen sollen über Messaging (156) kommunizieren. Dafür sollen sie Nachrichten senden können. Die Applikationen sollen in der Lage sein über Message Channel (153) verbunden zu werden. Für diese Applikationen wird ein Message Endpoint gestaltet, der die Applikationen mit dem Message Channel (153) verbindet. So sind die Applikationen in der Lage Nachrichten zu senden und zu empfangen. Die Ausgestaltung des Message Endpoints kann zum Beispiel durch Message Dispatcher (154), Message Translator (156) u. a. gestaltet werden. Messaging (156), Message (152), Message Translator (156), Message Dispatcher (154), Message Channel (153) (Hohpe et al. 2003)

17 A.36 Message Expiration 155 A.36 Message Expiration Zwei Applikationen benutzen Messaging (156). Wenn eine Nachricht zu einer bestimmten Zeit nicht verarbeitet wurde, ist sie nutzlos und sollte ignoriert werden. Ein Sender dieser Nachricht möchte diese Information kenntlich machen. Im Nachrichtenkopf wird das Haltbarkeitsdatum der Nachricht hinterlegt. Mithilfe dieser Message Expiration können Empfänger der Nachricht erkennen, dass sie eventuell ungültig ist. Messaging (156), Message (152) (Hohpe et al. 2003) A.37 Message Store Messaging (156) ermöglicht durch asynchrone Kommunikation die lose Kopplung von Applikationen. Es kann vorkommen, dass eine Applikation eine Nachricht an eine andere sendet, obwohl diese nicht mit dem Messaging-System verbunden ist (offline). Das Messaging-System soll trotzdem sicherstellen, dass eine Nachricht ihren Empfänger erreicht. Durch das Speichern einer Nachricht in einem Message Store kann sie zu einem späteren Zeitpunkt zugestellt werden. Beispiel -Server erfüllen diese Aufgabe. Sie speichern eine solange zwischen bis der Empfänger diese Nachricht abholt oder erreichbar ist. Sollte die Nachricht bis zu einem bestimmten Zeitpunkt Message Expiration (155) nicht zustellbar sein, wird eine Mitteilung (Event Message (147)) an den Sender zurück gesendet (Return Address(161)). Messaging (156), Message (152) (Hohpe et al. 2003)

18 156 A Patternkatalog A.38 Message Translator Verschiedene Applikationen sollen über Messaging (156) Nachrichten austauschen. Diese Applikationen benutzen eigene Datenformate, so dass eine Applikation die Daten der anderen Applikation nicht versteht. Durch einen speziellen Filter, einem Message Translator, können die verschiedenen Datenformate übersetzt werden. Messaging (156), Filter (148), Canonical Data Model(141) (Hohpe et al. 2003) A.39 Messaging Unabhängige Applikationen mit unterschiedlichen Daten und auf verschiedenen Plattformen sollen zusammenarbeiten. Dabei sollen die Applikationen nicht nur ihre Daten austauschen (Datenintegration), sondern auch ihre Funktionen gegenseitig nutzen (Funktionsintegration). Messaging stellt eine Form der Application Integration dar. Dabei werden Daten als Nachrichten ausgetauscht. Hierzu können die Applikationen Ereignisse (Event Message (147)), Dokumente (Document Message (145)) oder Funktionsaufrufe (Command Message (142)) zu jeder Zeit, zuverlässig und asynchron versenden. Dafür werden Message Channel (153) für die Kommunikation eingesetzt. Sie transportieren die Nachrichten (Message (152)). Über Pipes and Filters (158) und Content-Based Router (143) kann der Nachrichtenaustausch gesteuert werden. Message Translator (156) helfen beim Übersetzen der applikations-spezifischen Datenformate. Die Applikationen werden durch spezielle Message Endpoint (154) an Message Channel (153) angebunden. Message (152), Message Channel (153), Pipes and Filters (158), Content-Based Router (143), Message Translator (156), Message Endpoint (154) (Hohpe et al. 2003)

19 A.40 Messaging Gateway 157 A.40 Messaging Gateway Eine Applikation soll über Messaging (156) an eine andere Applikation angebunden werden. Die Anbindung der Applikation an ein Messaging-System soll vom Rest der Applikation gekapselt werden. Der Rest der Applikation soll keine Kenntnis über den speziellen Aufbau des Messaging-Systems besitzen. Ein Messaging Gateway kapselt die spezifischen Methodenaufrufe des Messaging-Systems und verbindet die domänenspezifischen Methoden der Applikation mit dem Messaging-System. Messaging (156), Message Endpoint (154), Decorator (146), Gateway (149) (Hohpe et al. 2003) A.41 Model View Controller Eine interaktive Anwendung soll entwickelt werden, die eine flexible Mensch-Maschine-Schnittstelle besitzt. Für Benutzerschnittstellen gibt es häufig Änderungsanforderungen. Wenn Funktionalität einer Anwendung geändert wird, muss die Benutzerschnittstelle angepasst werden. Verschiedene Anwender des gleichen Systems haben unterschiedliche Anforderungen an das Aussehen (Corporate Design), wobei die Funktionalität gleich bleibt. Einige Anwendungen sind Erweiterungen von existierenden Anwendungen und benutzen das gleiche Datenmodell, fügen aber neue Funktionalität hinzu. Deswegen sollen Benutzerschnittstelle und Funktionalität getrennt entwickelt und verändert werden können. Durch die Trennung des Modells, der Oberfläche und der Funktionalität können diese Komponenten unabhängig entwickelt und verändert werden. Das Modell enthält die Daten und die Kernfunktionalität. Ausgabekomponenten (views) zeigen dem Anwender die Daten des Modells. Somit ist es möglich für jedes Modell mehrere Sichten anzulegen. Jede Ausgabekomponente besitzt eine eigene Steuerung (Controller), um Benutzereingaben zu empfangen und in Anfragen an das Modell umzuwandeln. (Buschmann et al. 1998)

20 158 A Patternkatalog A.42 Pipes and Filters Alias Filter, FilterChain Daten sollen zwischen Komponenten transportiert werden. Während der Kommunikation sollen Funktionen auf den Nachrichten ausgeführt werden, wie zum Beispiel das Ver- und Entschlüsseln von Nachrichten. Durch Pipes and Filters (Röhren und Filter) werden Funktionsschritte in kleinere, unabhängige Sequenzen (Filter) zerlegt und durch einzelne Kanäle (Pipes) miteinander verbunden. Content Enricher (144), FilterChain (148), Message Channel (153), Messaging (156) (Hohpe et al. 2003, Bien 2002, Buschmann et al. 1998) A.43 Point-to-Point Channel Eine Applikation benutzt Messaging (156), um Dokumente oder Remote Procedure Calls (RPCs) zu transportieren. RPCs werden genau einmal und an genau eine Applikation gesendet, um dort eine Funktion auszulösen. Wenn dieser RPC über Messaging (156) versendet und durch einen Message Channel (153) transportiert wird, sind dort potenziell mehrere Empfänger angeschlossen, welche die Nachricht mitlesen können. Wenn die Nachricht explizit durch einen Point-to-Point Channel transportiert wird, kann das Messaging System sicherstellen, dass genau der gewünschte Empfänger die Nachricht erhält. Message Channel (153), Publish-Subscribe Channel (159), Message (152), Messaging (156) (Hohpe et al. 2003, Adams et al. 2002)

21 A.44 Publish-Subscribe Channel 159 A.44 Publish-Subscribe Channel Eine Applikation nutzt Messaging (156) und soll Nachrichten an mehrere Empfänger senden. Daten werden als Nachrichten verpackt und über Messaging (156) zuverlässig an alle Empfänger versandt. Diese Nachricht wird über einen Message Channel (153) transportiert. Die Nachricht kann aber erst als verschickt zurückgemeldet werden, wenn sie jeder Empfänger erhalten hat. Erst wenn jeder Empfänger die Nachricht erhalten hat, kann sie aus dem Message Channel (153) entfernt werden. Er muss zusätzlich sicherstellen, dass jeder Empfänger die Nachricht nur einmal erhält. Wenn die Empfänger sich selbst koordinieren, widerspricht das dem Konzept der losen Kopplung beim Messaging (156). Das wird durch die Nutzung eines expliziten Publish-Subscribe Channel, welcher die Nachricht kopiert und an alle Empfänger versendet, gelöst. Die Empfänger melden sich beim Messaging-System an und erklären sich bereit bestimmte Nachrichten empfangen zu wollen. Wird eine Nachricht vom Sender in den Message Channel (153) geschickt, transportiert er eine Kopie der Nachricht an die Empfänger. Der Unterschied zu einem normalen Message Channel (153) liegt darin, dass beim Publish-Subscribe Channel die Nachricht kopiert wird und so viele Exemplare vorhanden sind, wie Empfänger existieren. Beim normalen Message Channel (153) existiert die Message (152) dagegen nur einmal und kann auch nur einem Empfänger zugestellt werden, selbst wenn mehrere am Message Channel (153) angeschlossen sind. Point-to-Point Channel(158), Message Channel (153), Message (152), Messaging (156) (Hohpe et al. 2003) A.45 Self Service Alias User-to-Business Hauptsächlich kleinen und mittelständigen Unternehmen ist es kaum möglich sich mit ihren Partnern elektronisch zu vernetzen. Mithilfe eines Self-Service-Portals lassen sich direkte Interaktionen zwischen einem Unternehmen und den Partnern durch Internet-Technologien gestalten. Diese

22 160 A Patternkatalog Interaktionen reichen von einfacher Informationssuche bis hin zur Ausführung von Geschäftsprozessen, wie das Platzieren einer Bestellung. (Adams et al. 2002, Barking und König 2002) A.46 Receipient List Eine Applikation möchte Nachrichten über einen Message Channel (153) an mehrere Empfänger senden. Die Liste der Empfänger kann vom Typ der Nachricht abhängig sein (z. B. Hotelanfragen nur an Hotels). Besitzt ein Message Channel (153) eine Recipient List kann er anhand der eingehenden Nachrichten die gewünschten Empfänger ermitteln und die Nachricht an diese senden. Messaging (156), Publish-Subscribe Channel (159), Content-Based Router (143) (Hohpe et al. 2003) A.47 Registry Es soll ein Objekt in einer Klassenbibliothek gefunden werden. Dafür kann ein Objekt aus dem Modell ausgewählt werden, dass eine Referenz zu dem gesuchten Objekt besitzt. Beispiel Es sollen alle Aufträge eines Kunden gesucht werden. Dafür kann das entsprechende Kundenobjekt auswählt werden und die Kundenaufträge abfragen. Es kann aber auch sein, dass zwar die Kundennummer bekannt ist, aber keine Objektreferenz existiert. In diesem Fall wird ein Suchmechanismus benötigt. Ein Registry-Objekt ist global bekannt und kann genutzt werden, um andere Objekte und Dienste zu finden. Meist werden Registries als Singleton (163) implementiert. Singleton (163) (Fowler 2003)

23 A.48 Request-Reply 161 A.48 Request-Reply Zwei Applikationen kommunizieren über Messaging (156). Die Kommunikation wird durch einen Message Channel (153) abgebildet. Der Sender benötigt eine Antwort. Ein Message Channel (153) ist immer uni-direktional, was bedeutet, dass eine Nachricht immer nur in eine Richtung gesendet werden kann. Daraus ergibt sich, dass ansonsten der Sender ebenfalls als Empfänger am gleichen Kanal angemeldet ist. Folglich erhält er auch die Nachrichten, die er gerade abgesendet hat. Für die Kommunikation zwischen dem Anfrager (Requestor) und dem Antworter (Replier) wird ein Antwortkanal eingerichet. Zusätzlich wird eine Antwortnachricht modelliert, die einen Bezug zur Anfrage herstellt. Damit kann der Replier dem Requestor eine Antwort senden. Der Request Channel kann ein Point-to-Point Channel(158) oder ein Publish-Subscribe Channel (159) sein. Der Antwortkanal ist immer ein Point-to-Point Channel(158), da die Antwort nur an den Anfrager gesendet wird. Messaging (156), Point-to-Point Channel(158), Publish-Subscribe Channel (159), Command Message (142), Document Message (145) (Hohpe et al. 2003) A.48 Return Address Applikationen sind durch Messaging (156) miteinander verbunden und benutzen eine Request-Reply (161)-Kommunikation. Der Requestor sendet eine Nachricht an den Replier. Um zu antworten benötigt der Replier eine Information darüber, wer ihm die Anfrage gesendet hat. Wenn die Anfragenachricht (Request Message) den Absender (Return Address) enthält, kann der Replier daraus den Empfänger für die Antwort ermitteln. Messaging (156), Message (152), Request-Reply (161) (Hohpe et al. 2003)

24 162 A Patternkatalog A.49 Row Data Gateway Eine Applikation soll an eine Datenbank angebunden werden. Dafür muss das Domain Model (147) auf das Datenbankmodell abgebildet werden. Beispiel Es existiert ein objektorientiertes Datenmodell, welches auf ein relationales Datenmodell abgebildet werden soll. Durch die Ablage der Datenbankzugriffe im objektorientierten Datenmodell steigt die Komplexität des Domain Model (147). Tests werden durch die Datenbankzugriffe verzögert und die meisten Datenbankmanagementsysteme unterscheiden sich in der Auslegung der Structured Query Language (SQL), so dass beim Austauschen der Datenbank, meist auch die Klassen des Domain Model (147) angepasst werden müssen. Wenn jede Klasse des Domain Model (147) eine Tabelle in der Datenbank besitzt, entspricht eine Reihe in der Tabelle genau einem Objekt der Klasse. Die Zugriffsmechanismen werden durch ein Row Data Gateway gekapselt. Dabei wird ein Objekt erzeugt, dass als Gateway (149) dient und einem Dateneintrag zugeordnet ist. Für jede Reihe (Row) in der Datenbanktabelle wird eine Instanz erzeugt. Gateway (149), Domain Model (147) (Fowler 2003) A.50 Service Layer Eine Software soll durch Layers (150) strukturiert werden. Dabei setzen mehrere Komponenten auf dem Domain Model (147) auf. Die aufsetzenden Komponenten benutzen oftmals die gleichen Zugriffsmechanismen, wie Zugriffskontrollen, Transaktionsmechanismen, Koordination der Business Logic etc. Die Implementation dieser Mechanismen in separaten Komponenten verursachen Redundanzen. Ein Service Layer definiert eine Systemgrenze und die verfügbaren Operationen aus der Perspektive der aufsetzenden Komponenten. Layers (150), Domain Model (147) (Fowler 2003)

25 A.51 Service Stub 163 A.51 Service Stub Applikationen sind oft von Drittanbieter-Systemen abhängig. Beispiel Eine Software zur Überwachung von Aktienkursen benötigt einen Zugriff auf die aktuellen Börsenkurse. Jeder Zugriff verursacht Gebühren, die an den Anbieter (z. B. eine Bank) gezahlt werden müssen. Diese Systeme unterliegen oft Restriktionen, wie Zugriffszeiten, Kosten, die nicht unter eigener Kontrolle stehen und extern verursacht werden. Die zu entwickelnde Software muss trotzdem getestet werden. Durch das Entfernen von abhängigen und problematischen Systemen während der Testphase können diese Restriktionen kontrolliert werden. An Stelle des externen Systems wird ein Service Stub implementiert, der das gleiche Verhalten wie ein externes System anbietet, aber nur simuliertes Verhalten besitzt. Gateway (149), Bridge (140) (Fowler 2003) A.52 Singleton Eine Klassenbibliothek soll erstellt werden. Für manche Klassen soll nur eine Instanz zur Laufzeit erzeugt werden. Diese Erzeugung soll sichergestellt werden. Die Klasse wird als Singleton implementiert. Ein Singleton ist für die Erzeugung seines einzigen Exemplars zuständig und definiert eine statische Methode, damit andere Objekte das Exemplar anfordern können. Dabei stellt die Klasse sicher, dass kein weiteres Objekt von ihr erstellt wird. Beispiel Ein Registry (160) kann als Singleton implementiert werden. Es können mehrere Drucker an einem Rechner vorhanden sein, aber es sollte nur einen Druckerspooler geben. Dieser wird als Singleton implementiert. Registry (160) (Gamma et al. 1997)

26 164 A Patternkatalog A.53 Special Case Das Verhalten einer Klasse besitzt einen Spezialfall. Der Spezialfall darf nicht zu unerwünschten Zuständen der Software führen. Der Spezialfall (Special Case) wird in der Klassenstruktur mit berücksichtigt. Beispiel Leere Referenzen auf Objekte sind in der objektorientierten Softwareentwicklung unerwünscht, da sie meist zu Programmabstürzen führen. So kann es vorkommen, dass ein Kunde für ein System unbekannt ist, also nicht in einer Datenbank abgespeichert wurde (z. B. Neukunde). Anstatt ein leeres Objekt zu benutzen wird der Spezialfall ebenfalls in der Klassenstruktur berücksichtigt. Die besonderen Formen einer Message (152), wie Command Message (142), Document Message (145) und Event Message (147) sind Spezialfälle. (Fowler 2003) A.54 Splitter In Integrationslösungen können Nachrichten mehrere Elemente besitzen. Wenn z. B. ein Data Transfer Object (145) als Document Message (145) in einem Messaging-System versandt werden soll. Beispiel In einer Bestellung können Mengen sowohl für Plüschelefanten als auch für Gummibälle enthalten sein. Für beide Produkte soll die Verfügbarkeit geprüft werden. Dies geschieht in unterschiedlichen Lagerverwaltungssystemen. Die einzelnen Elemente der Nachricht sollen getrennt voneinander bearbeitet werden. Durch einen Splitter kann die Nachricht in eine Folge von individuellen Nachrichten zerlegt werden. Durch einen Content-Based Router (143) werden diese an die nachfolgenden Verarbeitungsschritte (Pipes and Filters (158)) verteilt. Messaging (156), Message (152), Message Channel (153), Content-Based Router (143), Pipes and Filters (158) (Hohpe et al. 2003)

27 A.55 Template View 165 A.55 Template View Es sollen dynamische HTML-Seiten als Benutzeroberfläche einer Web-Anwendung erstellt werden. Programmiersprachen sind nicht geeignet lange HTML-Seiten zu erzeugen. Des Weiteren sollen nach dem Model View Controller (157)-Muster die Darstellung vom Modell und von der Steuerungslogik getrennt werden. Eine dynamische HTML-Seite besitzt zudem statische Elemente und dynamische Elemente. Zumeist werden die statischen Elemente durch Web-Designer erstellt, die keine Kenntnis von der Ablauflogik besitzen. Durch Hinzufügen von Textmarken in statischen HTML-Seiten, welche zur Laufzeit dynamisch durch Daten ersetzt werden, entstehen Template Views (vordefinierte Masken). Beispiel Java Server Pages (JSP) bieten diese Art der dynamischen HTML-Seitenerstellung an. Dabei wird eine HTML-Seite durch Textmarken ergänzt. Ein Application Server ersetzt diese zur Laufzeit durch Daten. Two Step View (165), Model View Controller (157) (Fowler 2003) A.56 Two Step View Eine Web-Anwendung wird entworfen, die aus einer Menge von dynamischen HTML-Seiten besteht. Diese Seiten sollen in einem einheitlichen Layout erscheinen und die gleiche Bedienfunktionalität anbieten. Zudem soll die Oberfläche auf verschiedenen Endgeräten unterschiedlich dargestellt werden können. Die dynamischen Seiten können durch Template View (165) erstellt werden. Dadurch können aber globale Layoutänderungen nur durch eine Änderung jeder einzelnen Seite erfolgen. Folglich enthalten diese Seiten teilweise redundante Implementationen. Durch Two Step View wird die Erstellung der HTML-Oberfläche in zwei Transformationsschritte aufgeteilt. Der erste Schritt (First-Stage View) enthält nur die logische Repräsentation der Modelldaten in einer einheitlichen Struktur für alle Seiten (Canonical Data Model(141)). In einem zweiten Schritt (Second-Stage View) wird die logische Repräsentation des First-Stage View in die endgültige Darstellung transformiert. Dadurch können globale Änderungen im Second-Stage View vorgenommen werden, ohne die erste Transformation ändern zu müssen.

28 166 A Patternkatalog Außerdem können verschiedene Layouts für ein und dieselbe Oberflächenmaske erstellt werden, in dem jeweils ein Second-Stage Translator erstellt wird. Beispiel Der größte Vorteil liegt in der Unterstützung von verschiedenen Layouts für ein und die selbe Oberflächenmaske. Bei einem Single-Stage View (Template View (165)) wird für jedes Layout ein Modul pro Web-Seite und Darstellung benötigt. Durch einen Two Step View wird für jede Maske ein First-Stage-Modul und ein Second-Stage-Modul für die gesamte Anwendung eingesetzt. Bei 20 Darstellungsmasken und 4 verschiedenen Layouts werden im Single-Stage View 80 Module benötigt, wobei beim Two Step View nur 24 Module gebraucht werden. Template View (165) (Fowler 2003)

29 Abbildungsverzeichnis Abbildung 1: Grundmodell der SoA... 6 Abbildung 2: Abstraktionsebenen des Integrationsbegriffs Abbildung 3: Hierarchieebenen und Informationssysteme eines Unternehmens Abbildung 4: Entscheidungsfindungsprozess mit Zielvariablen Abbildung 5: Dichotomie des MCDM Abbildung 6: Vom Monolithen zur Client/Server-Architektur Abbildung 7: Beispiel für eine dreistufige Client/Server-Architektur mit Betriebsmitteln Abbildung 8: Weitergehende Spezialisierung bis hin zur Komponentenbauweise Abbildung 9: Anwendungssystem, Middleware und Betriebssystem Abbildung 10: BCArch: Generelle Architektur komponentenbasierter Anwendungssysteme Abbildung 11: Abhängige Komponenten-Anwendungs-Frameworks Abbildung 12: Komponenten eines betrieblichen Anwendungssystems Abbildung 13: (Produkt-)Lebenszyklus einer Fachkomponente Abbildung 14: Ordnungsrahmen für komponentenbasierte betriebliche Applikationen Abbildung 15: E-Business entlang der Wertschöpfungskette Abbildung 16: CRM-Komponenten Abbildung 17: Wertschöpfungskette und PRM bei fester Beziehung Abbildung 18: Wertschöpfungskette und PRM bei loser Beziehung Abbildung 19: Informationsportal Abbildung 20: Shared Business Function Abbildung 21: Service Oriented Architecture (SOA) Abbildung 22: Grobarchitektur eines EAI-Werkzeugs Abbildung 23: Notation einer Klasse Abbildung 24: Vererbung Abbildung 25: Assoziation Abbildung 26: Aggregation Abbildung 27: Aktivitätsdiagramm Abbildung 28: Zustandsdiagramm Abbildung 29: Sequenzdiagramm Abbildung 30: Denken als Informationsverarbeitung Abbildung 31: Mediator Abbildung 32: Zwei-dimensionales Content Addressable Network Abbildung 33: Konzept-Überblick Abbildung 34: Entwurf des Mediators (Verteilungsdiagramm) Abbildung 35: Message Channel Abbildung 36: Kommunikation zwischen Agenten... 92

30 168 Abbildungsverzeichnis Abbildung 37: Anfragekanal (Request Channel) Abbildung 38: Message Bus Abbildung 39: Aufbau der Nachrichten (Klassendiagramm) Abbildung 40: Nachrichtentypen (Klassendiagramm) Abbildung 41: Messaging-System ohne Event-Messages Abbildung 42: Messaging-System mit Router Abbildung 43: Request Channel des Messaging-Systems Abbildung 44: Reply Channel des Messaging-Systems Abbildung 45: Aufbau eines P2P-Knoten (Verteilungsdiagramm) Abbildung 46: Schichten des Mediators (Paketdiagramm) Abbildung 47: Aufbau der Präsentationsschicht (Komponentendiagramm) Abbildung 48: Funktionsweise der Präsentationsschicht (Sequenzdiagramm) Abbildung 49: Dienste-Schicht (Klassendiagramm) Abbildung 50: Modell - benutzerorientiert (Klassendiagramm) Abbildung 51: Entscheidungsfindung (Klassendiagramm) Abbildung 52: Data Transfer Objects (Klassendiagramm) Abbildung 53: Data Source Bridge (Klassendiagramm) Abbildung 54: IDSS-Szenario Abbildung 55: Cyber-Ego Abbildung 56: Architektur des mobilen IDSS Clients Abbildung 57: PIG Kommunikationsfluss Abbildung 58: Zahlungsflüsse im PIG-Geschäftsprozess Abbildung 59: SHERPA Abbildung 60: Klassendiagramm für ein Composite-Pattern

31 Tabellenverzeichnis Tabelle 1: Merkmale eines Peer-to-Peer-Netzwerks Tabelle 2: Merkmalsausprägungen eines Peer-to-Peer-Netzwerks im Beziehungsmanagement Tabelle 3: Kontaktlisten

32 Abkürzungsverzeichnis A2A Agent to Agent acrm analytisches CRM API Application Programming Interface ARIS Architektur Integrierter Informationssysteme ASP Application Service Providing B2B Business to Business B2C Business to Consumer BAPI Business Application Programming Interface BCArch Business Component Architecture BCLifeCycle Business Component Lifecycle BPEL4WS Business Process Execution Language for Web Services CAN Content Addressable Network CAN Controller Area Network CD Compact Disc CIC Customer Interaction Center CoBCoM Common Business Component Model CORBA Common Object Request Broker Architecture CRM Customer Relationship Management CTP Customer Touch Point DB Datenbank (engl. Database) DCOM Distributed Component Object Model DBMS Database Management System DRM Digital Rights Management DTD Document Type Definition DTO Data Transfer Object DVD Digital Versatile Disc DWH Data-Warehouse EAI Enterprise Application Integration ERP Enterprise Resource Planning FQDN Fully Qualifying Domain Name GB Gigabyte GIS Geographisches Informationssystem GPRS General Packet Radio Service GPS Global Positioning System GSM Global System for Mobile communication HTML Hyper Text Markup Language HTTP Hypertext Transfer Protocol IDSS Intelligent Driver Support System IT Informationstechnologie IuK Informations- und Kommunikations(technologie) J2EE Java 2 Platform, Enterprise Edition JVM Java Virtual Machine JXTA Juxtaposed

33 172 Abkürzungsverzeichnis K kcrm KDD KI KMU L LBS MADM MAS MCDM MODM MOM OASIS ocrm OLAP OMA OMG ORB P2P PDA PIG PRM QoS RAPPeL RPC SCM SHERPA SLA SoA SOAP SQL SRM TCO TB U UDDI UML UMTS VL VoIP VP W3C WFMS WML WSCI WSDL Kunde kommunikatives CRM Knowledge Discovery in Databases Künstlich Intelligenz Kleine und Mittlere Unternehmen Lieferant Location-based Services Multi-Attribute Decision Making Multi-Agenten-System Multiple-Criteria Decision Making Multi-Objective Decision Making Message-oriented Middleware Organization for the Advancement of Structured Information Standards operatives CRM Online Analytical Processing Object Management Architecture Object Management Group Object Request Broker Peer to Peer Personal Digital Assistant Personal Information Guide Partner Relationship Management Quality of Service Requirements-Analysis Process Pattern Language Remote Procedure Call Supply Chain Management Shared ERP Architecture Service Level Agreement Service-oriented Architecture Simple Object Access Protocol Structured Query Language Supplier Relationship Management Total Cost of Ownership Terabyte Unternehmen Universal Description, Discovery and Integration Unified Modeling Language Universal Mobile Telecommunications System Vorlieferant Voice over Internet Protocol Vertriebspartner World Wide Web Consortium Workflow Managementsystem Wireless Markup Language Web Service Choreography Interface Web Service Definition Language

34 Index 173 WSFL WWW XHTML XLANG XML XSL XSLT Web Services Flow Language World Wide Web Extensible Hypertext Markup Language XML Business Process Language Extensible Markup Language Extensible Stylesheet Language Extensible Stylesheet Language Transformer

35 Literatur Aalst, W. v. d. (2003): Don t go with the Flow: Web services composition standards exposed. IEEE Intelligent Systems, Januar/Februar Adams, J., Koushik, S., Vasudeva, G., Calambos, G. (2002): Patterns for e-business. A Strategy for Reuse. IBM Press. 3. Auflage; Double-Oak - USA. Alexander, C., Ishikawa, S., Silverstein, M. (1977): A Pattern Language: Towns, Buildings, Construction. Oxford University Press. Anderson, D. (2001): Peer-To-Peer: Harnessing the Benefits of a Disruptive Technology, Kapitel 5. SETI@home, S O Reilly & Associates, Inc. Arkin, A. et al. (2001): Web Service Choreography Interface 1.0, com/software/xml/developers/wsci/wsci-spec-10.pdf, 2001 Auberle, A., Klosa, A. (2001): Informieren. In M. Wermke, A. Klosa, K. Kunkel- Razum, W. Scholze-Stubenrecht (Hrsg.), Duden Das Herkunftswörterbuch Etymologie der deutschen Sprache, Band 7, S Dudenverlag, 3. Auflage. Ba, S., Whinston, A. B., Zhang, H. (1999): Building Trust in the Electronic Market through an Economic Incentive Mechanism. In Proceedings of the 20th International Conference on Information Systems, Charlotte, North Carolina, USA, S Baecker, D. (1999): Organisation als System Aufsätze. Suhrkamp Taschenbuch Verlag, Frankfurt am Main. Ballestero, E., Romero, C. (1996): Dynamic Choices in Economics: A Compromise Approach. In M. Tamiz (Hrsg.), Multi-Objective Programming and Goal Programming Theories and Applications, S. 11 ff. Lecture Notes in Economics and Mathematical Systems, Springer Verlag Berlin. Balzert, H. (1999): Lehrbuch Grundlagen der Informatik. Spektrum, Heidelberg, Berlin. Balzert, H. (1998): Lehrbuch der Software-Technik: Software-Management, Software-Qualitätssicherung, Unternehmensmodellierung. Spektrum, Heidelberg, Berlin. Barak, V. (1997): Systemintegration: Strategien für die Informatik. Gabler, Wiesbaden. Barking, U., König, P. (2002): Ganzheitliche Prozessunterstützung durch eine integrierte SRM-. HMD 39 (228), S Becker, J. (1990): CIM Integrationsmodell. Springer; Berlin u. a. Beckmann, H., Vlachakis, J., Kelkar, O., Otto, B. (2002): Eine integrierte, offene SRM-Plattform zu Unterstützung von Beschaffungsprozessen mittelständischer Unternehmen. HMD 39 (228), S Beimborn, D., Mintert, S., Weitzel, T. (2002): Web Services und ebxml. Wirtschaftsinformatik 44 (3), S Bensaou, M. (1999), Portfolios of Buyer-Supplier Relationships, In: Sloan Management Review, Jg. 40 (1999), Nr. 4, S Berner Fachhochschule (2003): Web Services im egovernment,