Entwicklung und Evaluierung von Architekturkonzepten für E-Business-Transaktionszentren unter Berücksichtigung gegebener Standards und Schnittstellen

INHALTSVERZEICHNIS

THESEN

ABBILDUNGSVERZEICHNIS

TABELLENVERZEICHNIS

ABKÜRZUNGSVERZEICHNIS

1. EINLEITUNG
1.1. ÜBERBLICK UND MOTIVATION
1.2. AUFGABENSTELLUNG UND GLIEDERUNG DER ARBEIT
1.2.1. Aufgabenstellung
1.2.2. Gliederung der Arbeit
1.3. KONVENTIONEN

2. GRUNDLAGEN
2.1. EINLEITUNG
2.2. BEGRIFFSERKLÄRUNGEN
2.2.1. Die Begriffe E-Business und E-Commerce
2.2.2. Der Begriff des E-Business Transaktionszentrums

3. ANFORDERUNGEN AN EIN E-BUSINESS TRANSAKTIONSZENTRUM
3.1. ÜBERBLICK
3.2. DATENAUSTAUSCH MIT XML
3.3. ELEKTRONISCHE SERVICES

4. KONZEPTION EINES E-BUSINESS TRANSAKTIONSZENTRUMS
4.1. EINLEITUNG
4.2. DIE FUNKTIONSBEREICHE DES TRANSAKTIONSZENTRUMS
4.3. DIE INTERNE VERARBEITUNG DES TRANSAKTIONSZENTRUMS
4.3.1. Einleitung
4.3.2. Allgemeine Beschreibung
4.3.3. Der Transaktionskoordinator
4.3.4. Fehlerbehandlung
4.3.4.1. Direkter Abbruch
4.3.4.2. Mehrmaliges Wiederholen mit zeitlicher Verzögerung
4.3.4.3. Mehrmaliges Wiederholen in Wellen
4.3.5. Sicherheitsmechanismen
4.3.6. Entwicklungsumgebung
4.4. DIE VERBINDUNGSEINHEIT DES TRANSAKTIONSZENTRUMS
4.4.1. Einleitung
4.4.2. Verbindung mit dem Internet
4.4.3. Lastenteilung
4.4.4. Request Router
4.5. DATENAUSTAUSCH MIT DEM TRANSAKTIONSZENTRUM
4.5.1. Einleitung
4.5.2. Datenaustauschüber XML-Dateien
4.5.3. Der Exportvorgang
4.5.4. Der Data Aggregator im Detail
4.6. KOMPONENTEN DES TRANSAKTIONSZENTRUMS
4.6.1. Einleitung
4.6.2. Interne Softwarekomponenten
4.6.2.1. Überblick
4.6.2.2. Der Transaktionskoordinator
4.6.2.3. Empfang und Senden
4.6.2.4. Import und Export
4.6.2.5. Request Routing
4.6.2.6. Sicherheit
4.6.2.7. Visualisierung
4.6.2.8. Datenverarbeitungsprozesse
4.6.2.9. Datenhaltung
4.6.2.10. Datenpflege
4.6.2.11. Logistik und Versand
4.6.2.12. E-Services
4.6.3. Interne Hardwarekomponenten
4.6.3.1. Überblick
4.6.3.2. Peripherie
4.6.3.3. Datenbankserver
4.6.3.4. Data Warehouse und Data Mart
4.6.4. Die externe Umgebung
4.6.4.1. Externe Hardwaresysteme
4.6.4.2. Externe Softwaresysteme

5. EVALUIERUNG VON ARCHITEKTURKONZEPTEN
5.1. EINLEITUNG
5.2. DATENBANKSYSTEME UND E-BUSINESS UNTERSTÜTZUNG
5.2.1. Überblick
5.2.2. Oracle 8i
5.2.3. DB2 Version 7 von IBM
5.2.4. Tamino XML Datenbank von der Software AG
5.2.5. Bewertung
5.3. DIE XML-PLATTFORM DER SOFTWARE AG
5.3.1. Überblick
5.3.2. Bolero
5.3.3. Bolero Component Studio
5.3.4. EntireX
5.3.5. Tamino X-Bridge
5.3.6. Bewertung
5.4. BEA WEBLOGIC SERVER VERSION
5.4.1. Überblick
5.4.2. Kommunikation
5.4.3. Die Middleware Tuxedo
5.4.4. Unterstützung von Clustern
5.4.5. Entwicklungsumgebung
5.4.6. Bewertung
5.5. INTERSHOP ENFINITY
5.5.1. Überblick
5.5.2. Die Architektur
5.5.3. Kommunikation mit anderen Systemen
5.5.4. Die Entwicklungsumgebung
5.5.4.1. Templates
5.5.4.2. Pipelines
5.5.5. Bewertung
5.6. INTOS/M2, RELEASE
5.6.1. Überblick
5.6.2. Funktionsbereiche
5.6.2.1. E-Commerce
5.6.2.2. Data Interchange
5.6.2.3. Content Management
5.6.2.4. Collaboration
5.6.3. Bewertung
5.7. BEWERTUNG DER VORGESTELLTEN KONZEPTE

6. PRAXISBEISPIEL: DIE „FASHIONMARKET AG“
6.1. EINLEITUNG
6.2. DIE TÄTIGKEIT BEI DER FASHIONMARKET AG
6.2.1. Einleitung
6.2.2. Umstellung des bestehenden Systems
6.2.3. Der Aufbau der B2B-Plattform

7. SCHLUßBETRACHTUNGEN UND AUSBLICK

LITERATURVERZEICHNIS

KURZFASSUNG

Die elektronische Abwicklung von Geschäftsprozessen gehört zu den aktuellen TopThemen des Internet-Zeitalters. E-Business ist ein Geschäftsfeld, das zur Zeit von Euphorie beherrscht wird und enorme Wachstumschancen bietet.

Die Abwicklung von Geschäftsprozessen über das Internet erfordert von allen teilneh-menden Geschäftseinheiten die Bereitstellung geeigneter softwaretechnischer Struktu-ren, insbesondere die Unterstützung vorgegebener Schnittstellen. Der Anbieter von elektronischen Services hat für die Abwicklung und Verarbeitung der unterschiedlichsten Geschäftsprozesse Sorge zu tragen. Die vorliegende Arbeit stellt eine allgemeine Struk-tur für eine E-Business Plattform bereit, die als Intermediär externe Geschäftseinheiten integriert, die Abwicklung von Geschäftsprozessen zwischen Anbietern und Kunden er-möglicht und Standardformate für den Datenaustausch bereitstellt. Die bloße Abwick-lung von Geschäftsprozessen über das Internet ist durch heutige Technologien möglich. Darauf basierend, beschäftigt sich diese Arbeit mit der Aufgabe, für Unternehmen und Endkunden eine Architektur für einen zentralen elektronischen Transaktionsplatz zu schaffen und eine Grundlage für die softwaretechnische Analyse zu entwickeln.

Neben der Entwicklung eines Architekturkonzeptes werden Konzepte von auf dem Markt erhältlichen Systemen untersucht und bewertet. Anhand eines Praxisbeispiel wird außerdem dargestellt, wie ein bestehender Online Shop hin zu einer B2B -Plattform weiterentwickelt werden kann.

VORWORT

Ich danke Herrn Dr. Bernd Binder von der fashionmarket AG für die fachliche Unterstüt-zung.

Weiterhin rechne ich meinen Eltern hoch an, daß ich die Möglichkeit erhalten habe, in einem angenehmen und ungestörten Umfeld einen Gutteil meiner Arbeit zu Hause anfertigen zu können.

Abschließend danke ich Marius Obst für die konstruktive Hilfe beim Korrekturlesen der vorliegenden Arbeit.

Ilmenau, im März 2001

Klaus Meffert

THESEN

(1) Für den universellen Datenaustausch zwischen unterschiedlichen Applikationen wird sich die eXtensible Markup Language (XML) als Standard etablieren.

(2) XML wird von modernen Datenbanksystemen verstärkt unterstützt werden.

(3) Relationale Datenbanksysteme sind ungeeignet zur optimalen Speicherung und Ver- arbeitung von XML-Daten.

(4) Java wird sich für die plattformunabhängige Entwicklung von Applikation durchset- zen und behaupten.

(5) Java und XML sind Schlüsseltechnologien bei der Entwicklung moderner E-Business Anwendungen.

(6) Der Markt zur elektronischen Abwicklung von Geschäftsprozessen befindet sich momentan in einer Orientierungs- und Umstrukturierungsphase. E-Business wird sich in Zukunft auf dem Markt etablieren.

ABBILDUNGSVERZEICHNIS

ABBILDUNG 1: E-BUSINESS UMFELD

ABBILDUNG 2: MARKETPLACE EVOLUTION

ABBILDUNG 3: DIMENSIONEN DES WACHSTUMS

ABBILDUNG 4: GESCHÄFTSBEZIEHUNGEN

ABBILDUNG 5: TRANSAKTIONSZENTRUM UND UMGEBUNG

ABBILDUNG 6: FUNKTIONSBEREICHE DES TRANSAKTIONSZENTRUMS

ABBILDUNG 7: INTERNE STRUKTUR EINES TRANSAKTIONSZENTRUMS

ABBILDUNG 8: SEQUENZDIAGRAMM ZUR AUFGABE „STATISTIK ERSTELLEN“, TEIL

ABBILDUNG 9: SEQUENZDIAGRAMM ZUR AUFGABE "STATISTIK ERSTELLEN", TEIL

ABBILDUNG 10: WATCHDOG AGENT

ABBILDUNG 11: BIBLIOTHEKSSERVER

ABBILDUNG 12: VERBINDUNG EINES TRANSAKTIONSZENTRUMS MIT DER AUßENWELT

ABBILDUNG 13: LASTENTEILUNG

ABBILDUNG 14: DATENAUSTAUSCH ZWISCHEN SYSTEMEN

ABBILDUNG 15: IMPORT UND EXPORT VON DATEN

ABBILDUNG 16: DATENEXPORT HIN ZUM TRANSAKTIONSZENTRUM

ABBILDUNG 17: VERARBEITUNG VON EINGABE MIT REGELWERK

ABBILDUNG 18: FUNKTIONSDIAGRAMM EINES DATA AGGREGATORS

ABBILDUNG 19 - INTERNE SOFTWAREKOMPONENTEN

ABBILDUNG 20: ANFRAGEBEARBEITUNG DURCH DEN TRANSAKTIONSKOORDINATOR

ABBILDUNG 21: SOFTWAREKOMPONENTE MESSAGE HANDLER

ABBILDUNG 22: SOFTWAREKOMPONENTE EMPFANG/SENDEN.

ABBILDUNG 23: SOFTWAREKOMPONENTE IMPORT/EXPORT.

ABBILDUNG 24: SOFTWAREKOMPONENTE REQUEST ROUTING

ABBILDUNG 25: SOFTWAREKOMPONENTE SICHERHEIT.

ABBILDUNG 26: SOFTWAREKOMPONENTE VISUALISIERUNG

ABBILDUNG 27: SOFTWAREKOMPONENTE DATENVERARBEITUNGSPROZESSE.

ABBILDUNG 28: SOFTWAREKOMPONENTE DATENHALTUNG

ABBILDUNG 29: SOFTWAREKOMPONENTE DATENPFLEGE

ABBILDUNG 30: SOFTWAREKOMPONENTE LOGISTIK/VERSAND

ABBILDUNG 31: SOFTWAREKOMPONENTE E-SERVICES.

ABBILDUNG 32: SOFTWAREKOMPONENTE E-MARKETING

ABBILDUNG 33: INTERNE HARDWAREKOMPONENTEN

ABBILDUNG 34: HARDWAREKOMPONENTE DATENBANKSERVER

ABBILDUNG 35: DATA WAREHOUSE UND DATA MARTS

ABBILDUNG 36: HARDWAREKOMPONENTEN EINES EXTERNEN SYSTEMS

ABBILDUNG 37: SOFTWAREKOMPONENTEN EINES EXTERNEN SYSTEMS

ABBILDUNG 38: TAMINO XML DATENBANK ARCHITEKTUR

ABBILDUNG 39: BOLERO ARCHITEKTUR

ABBILDUNG 40: BOLERO UMFELD

ABBILDUNG 41: BOLERO UND ENTIREX

ABBILDUNG 42: TAMINO X-BRIDGE ARCHITEKTUR

ABBILDUNG 43: BEA WEBLOGIC SERVER SCHICHTENMODELL

ABBILDUNG 44: BEA WEBLOGIC CONNECTION POOL

ABBILDUNG 45: BEA WEBLOGIC ANWENDUNGSSCHICHTEN

ABBILDUNG 46: ARCHITEKTUR VON INTERSHOP.

ABBILDUNG 47: ENFINITY REMOTE XML INTERFACE

ABBILDUNG 48: INTOS ARCHITEKTUR DATA INTERCHANGE

ABBILDUNG 49: INTOS DATENAUSTAUSCH MIT ANDEREN SYSTEMEN

ABBILDUNG 50: FASHIONMARKET ALS GESAMTDIENSTLEISTER DER MODEBRANCHE

ABBILDUNG 51: GESTALTUNGSDIMENSIONEN UND EINFLUßFAKTOREN DES WEBAUFTRITTS

ABBILDUNG 52: RESTRUKTURIERUNG DER PRODUKTIVDATEN

TABELLENVERZEICHNIS

TABELLE 1: UNTERSCHIEDE ZWISCHEN EDI UND E-COMMERCE

TABELLE 2: UNTERSCHIEDE ZWISCHEN DATA WAREHOUSE UND DATA MART

ABKÜRZUNGSVERZEICHNIS

Abbildung in dieser Leseprobe nicht enthalten

1. EINLEITUNG

1.1. Überblick und Motivation

E-Business als Schlagwort für die elektronische Abwicklung von Geschäftsprozessen, unter Integration der Bereiche Einkauf, Logistik und Produktion, ist ein Thema, das im Zeitalter des Internets zunehmend an Bedeutung gewinnt. Die elektronische Geschäftsabwicklung wird geprägt durch das Verbinden und Einbinden heterogener Systeme und die Eingliederung verschiedenster informationstechnischer, betriebswirtschaftlicher und logistischer Konzepte, wie die nächste Abbildung verdeutlicht.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 1: E-Business Umfeld¹

Die Abbildung zeigt Einflußfaktoren auf das zentrale Geschäftsfeld E-Business. Einige we-sentliche Einflußfaktoren basieren auf informationstechnischen, andere auf betriebswirt-schaftlichen Grundlagen. Die Bereiche Multimedia und Geschäftsprozesse können beiden Richtungen zugeordnet werden. Im Rahmen dieser Arbeit werden hauptsächlich die informationstechnischen Belange berücksichtigt, dabei steht die Betrachtung softwaretechnischer Aspekte im Vordergrund. Betriebswirtschaftliche und logistische Problematiken werden nur am Rande betrachtet.

Trotz aller Euphorie muß eine Unternehmung, die elektronische Dienste anbieten und Transaktionen abwickeln will, ein solides informationstechnisches Fundament besitzen. Zu oft konnte man beobachten oder sogar im Internet auf den entsprechenden Seiten von E-Commerce Anbietern selbst nachprüfen, daß die technischen Strukturen insgesamt nicht ausreichend durchdacht und nicht marktgerecht realisiert wurden². Dies gilt um so mehr für noch nicht im Internet vertretene Unternehmen, bei denen momentan kaum die Voraussetzungen dafür vorhanden sind, am elektronischen Handel teilzunehmen. Dies kann durch Fehlen geeigneter Schnittstellen oder durch mangelnde Voraussetzungen in der ITInfrastruktur des Unternehmens selbst bedingt sein.

Mittlerweile stellt sich für viele Firmen nicht die Frage, ob E-Business zu betreiben ist, son-dern wann der günstigste Zeitraum für den Markteintritt ist und wie sich dieser Eintritt ge-staltet. Der Wettbewerbsdruck im E-Business Markt wächst an, weil einerseits große Unter-nehmen den Markt penetrieren³ und andererseits Gesellschaft, Wirtschaft, Politik und tech-nologischer Fortschritt das E-Business Zeitalter begründen und antreiben⁴. Dies führt auf-grund der rasanten Geschwindigkeit, mit der dies vonstatten geht, zu einem relativ unkon-trollierten Wachstum, durch das sich der Markt im Laufe der Zeit selbst regulieren wird.

Motivation dieser Arbeit ist es, Strukturen und Mechanismen aus dem Gebiet der Softwa-retechnik zu entwickeln. Diese sollen nicht nur die Bereitstellung „ klassischer“ Services im E-Business ermöglichen, wie dies bei elektronischen Marktplätzen, Malls und Portalen der Fall ist, sondern auch die Voraussetzungen für eine tiefgreifende Integration von Geschäft-seinheiten schaffen. Ein wichtiger Grund für die Integration vieler Teilnehmer auf einer Plattform ist, daß die administrativen Kosten eines verteilten Systems wesentlich geringer sind als die von mehreren, von einander unabhängigen Systemen. Elektronische Services und Informationen sollen allen Kunden des Dienstes unter Berücksichtigung aktueller Stan-dards und Schnittstellen zugänglich sein.

Die in dieser Arbeit entwickelte Architektur, die die Bereitstellung und komplexe Abwick-lung elektronischer Geschäftsprozesse ermöglicht sowie Geschäftseinheiten integriert, Transaktionen abwickelt, und dabei als Informations-, Dienst- und Request-Broker, Ver-zeichnisdienst und Service Provider auftritt, wird im folgenden als „ E-Business - Transakti-onszentrum“ bezeichnet.

Die folgende Abbildung, die schematisch die prognostizierte mittelfristige Entwicklung des B2B⁵ Marktes darstellt, veranschaulicht die Notwendigkeit, zukunftsträchtige Strukturen zu besitzen.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2: Marketplace Evolution⁶

Ohne geeignete informationstechnische Strukturen ist es auf längere Sicht nicht möglich, den sich aufgrund des schnellen Wandels der Technologien ergebenden, wachsenden Anforderungen gerecht zu werden sowie nicht zu den Opfern der Konsolidierungs- und Restrukturierungsphase zu gehören.

Die Vorteile von E-Business sind bekannt, jedoch müssen vorhandene Risiken weitgehend durch ein ausgereiftes Konzept beseitigt werden.

1.2. Aufgabenstellung und Gliederung der Arbeit

1.2.1. Aufgabenstellung

Geschäftseinheiten⁷, die gemeinsam einen Dienst nutzen wollen, müssen sich in geeigneter Weise an diesen Dienst anbinden lassen. Die Anbindung erfolgt über Schnittstellen, für die sich mittlerweile einige Standards etabliert haben. Einerseits existieren Formate für den dateibasierten Austausch von Informationen, andererseits gibt es Protokolle für den Aus-tausch von Datenströmen über das Internet. Ein Schwerpunkt dieser Arbeit liegt in der Be-trachtung des dateibasierten Informationsaustausches. Gleichzeitig muß ein Dienst, der Geschäftsprozesse bereitstellt sowie entsprechende Mehrwertservices dazu anbietet, ent-sprechende Strukturen anbieten, die den angebundenen Einheiten die Abwicklung von Transaktionen erlauben.

Skalierbarkeit des Gesamtsystems steht bei E-Business stark im Vordergrund, da bei positivem Geschäftsverlauf die Anzahl der Teilnehmer am System extrem hoch sein kann. Ein theoretisches, ideales Ziel für ein E-Business Transaktionszentrum ist es, sich bezüglich des Kommunikationsumfangs dem World Wide Web so weit wie möglich anzunähern. Deshalb muß jede Komponente des Systems skalierbar sein. Wie in der nächsten Abbildung dargestellt ist, gibt es drei Hauptgründe für Wachstum: Steigerung des Datenvolumens, Erhöhung der Funktionalität und eine höhere Anzahl Anwender.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3: Dimensionen des Wachstums⁸

Jedes dieser genannten Kriterien muß in der Architektur eines E-Business Systems durch geeignete Maßnahmen entsprechende Berücksichtigung finden.

Aufgabe dieser Arbeit ist die Vorstellung eines Architekturkonzeptes, das verschiedene Aspekte eines E-Business Transaktionszentrums berücksichtigt. Darüber hinaus werden Konzepte von auf dem Markt befindlichen Systemen präsentiert und bewertet. Alle entwikkelten und vorgestellten Konzepte sind als Vorschlag zu verstehen und sollen helfen, für zukünftige Projekte softwaretechnische Analysen sowie das Treffen von Entwurfsentscheidungen durch Aufzeigen von Möglichkeiten zu vereinfachen.

1.2.2. Gliederung der Arbeit

Die Diplomarbeit gliedert sich im wesentlichen in fünf Teile:

Abbildung in dieser Leseprobe nicht enthalten

Im ersten und zweiten Kapitel wird die Aufgabenstellung und Motivation der Arbeit erläutert. Weiterhin werden Begriffe definiert sowie Grundlagen vermittelt.

Allgemeine informationstechnische Anforderungen an ein E-Business Transaktionszentrum werden im dritten Kapitel dargestellt.

Den Kern des vierten Kapitels bildet die Entwicklung eines Architekturkonzeptes für ein E-Business Transaktionszentrum, das softwaretechnische Belange berücksichtigt. Dieser Abschnitt bildet den ersten Hauptteil der Arbeit.

Das fünfte Kapitel beschäftigt sich mit der Vorstellung und Bewertung von Konzepten von auf dem Markt verfügbaren Systemen, die im Bereich E-Business eingesetzt werden können. Am Ende des Kapitels folgt eine Gesamtbewertung der in dieser Arbeit vorgestellten Konzepte. Dieser Abschnitt bildet den zweiten Hauptteil der Arbeit.

Schließlich folgt im sechsten Kapitel ein Praxisbericht über die Konzeptionierung und Im-plementierung eines E-Business Systems bei der fashionmarket AG. Exemplarisch wird hier dargestellt, welche Lösungsansätze zur Umsetzung vom Konzept hin zum System verwendet wurden und wie das bestehende Online Shopsystem erweitert wurde.

Den Abschluß der Arbeit bilden die Schlußbetrachtungen und ein Ausblick auf mögliche zukünftige Entwicklungen.

1.3. Konventionen

Die in dieser Arbeit verwendeten Abkürzungen werden zusätzlich zur Beschreibung im Abkürzungsverzeichnis bei der ersten Verwendung in einer Fußnote erklärt und danach als bekannt vorausgesetzt.

Englische Begriffe und Terminologie, Abkürzungen, Firmennamen und Produktnamen werden zur Kennzeichnung kursiv gedruckt. Eine Ausnahme sind sehr häufig verwendete Begriffe wie XML und E-Business und gebräuchliche englische Bezeichnungen wie beispielsweise Client oder Server.

Abkürzungen, die im Plural verwendet werden, sind ohne nachgestelltes „ s“ geschrieben.

2. GRUNDLAGEN

2.1. Einleitung

Aufgrund des schnellen Wandels der Informationstechnologie werden manche Begriffe oft in unterschiedlicher Bedeutung verwendet. Die folgenden Begriffserklärungen dienen dazu, Grundlagen zu vermitteln sowie die Bedeutung von in dieser Arbeit häufig verwendeten Begriffen zu definieren und mögliche Doppelbedeutungen zu beseitigen.

2.2. Begriffserklärungen

2.2.1. Die Begriffe E-Business und E-Commerce

E-Commerce (Electronic Commerce) ist ein Teil des E-Business und beinhaltet die elektronische Abwicklung von Geschäftsprozessen zwischen Marktteilnehmern über Datennetze wie etwa das Internet.

Eine von vielen Definitionen für E-Commerce ist, daß in einem Unternehmen E-Commerce durchgeführt wird, wenn mindestens elementare Transaktionen wie Bezahlung und Liefe-rung über elektronische Märkte abgewickelt werden. Bestandteil des E-Commerce ist unter anderem der Kauf und Verkauf von Ware über Online Plattformen sowie das Management der zugehörigen Logistik.

E-Business erweitert dieses Umfeld durch umfassende Integration von Einkauf, Logistik und Produktion sowie durch Ermöglichen von Partnerschaften zwischen Kunden und Lieferanten sowie Kundenservice, Back Office und Front Office Dienste⁹. Unter E-Business versteht man also die Bereitstellung aller Voraussetzungen, um E-Commerce betreiben zu kön-nen¹⁰.

Am E-Business beteiligte Geschäftseinheiten, das können zum Beispiel Unternehmen, Privatkunden und Institutionen sein, stehen in unterschiedlicher Beziehung zueinander. Mögliche Beziehungen stellt folgende Graphik dar.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 4: Geschäftsbeziehungen

Hauptsächlich werden in der vorliegenden Arbeit Beziehungen zwischen verschiedenen Unternehmen (B2B) als auch zwischen Unternehmen und Kunden (B2C¹¹ ) betrachtet. Alle anderen Beziehungen spielen hier, so wie auch momentan auf dem Markt, eine unterge-ordnete Rolle. Neben den dargestellten Gruppen von Geschäftseinheiten wird in der Lite-ratur eine weitere Gruppe erwähnt, nämlich die der Angestellten, die mit „ E“ wie Employee abgekürzt wird. Weiterhin wird auch von Geschäftsbeziehungen zwischen Personen ge-sprochen, die man als Person to Person (P2P) oder Peer to Peer bezeichnet. Privatleute treten in diesem Fall nicht nur als Konsumenten, sondern auch als Anbieter auf, beispiels-weise als Verkäufer auf Auktionen.

2.2.2. Der Begriff des E-Business Transaktionszentrums

Kern dieser Arbeit ist die Ausarbeitung und Vorstellung von Architekturkonzepten für E-Business Transaktionszentren. Unter einem Transaktionszentrum wird eine zentrale Service-plattform verstanden, die zur Bereitstellung von elektronischen Services Transaktionen ab-wickelt. Dabei wickelt das Transaktionszentrum nicht nur Geschäftsprozesse ab, sondern stellt diese auch bereit. Das Transaktionszentrum ist ein Intermediär, also Vermittler, zwi-schen einzelnen Marktteilnehmern und Gruppen. Die nächste Graphik zeigt auszugsweise, welche Geschäftseinheiten an ein E-Business Transaktionszentrum angebunden sein kön-nen.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 5: Transaktionszentrum und Umgebung

Kern der dargestellten Abbildung ist das Transaktionszentrum, mit TAZ abgekürzt. An das Transaktionszentrum sind verschiedene Dienstnutzer wie Kunden, Dienstleister oder Ver-käufer angebunden. Die Linien zwischen Dienstnutzern stellen Beziehungen zwischen den angebundenen Geschäftseinheiten dar, die Linien zwischen Dienstnutzern und Transakti-onszentrum deuten eine direkte Verbindung zwischen diesen beiden Parteien an. Ein Transaktionszentrum integriert die Funktionalität von elektronischem Marktplatz, zen-traler Verwaltungsstelle und Transaktionsabwicklungszentrale und stellt sie den dargestell-ten Geschäftseinheiten zur Verfügung. Die bereitgestellte Funktionalität trägt zur Finanzie-rung des Transaktionszentrums bei, entweder direkt über entsprechende Abrechnungsmo-delle oder indirekt über Werbung.

Mittels eines Transaktionszentrums sind Kommunikations- und Geschäftsverbindungen jeg-licher Art realisierbar, sofern die Geschäftspartner über eine entsprechende Anbindung verfügen. Anbieter von Waren und Dienstleistungen, die an das Transaktionszentrum angebunden sind, können und sollen selbständig ihre Daten und Angebote administrieren. Dies kann beispielsweise mit Hilfe von Workflows geschehen. Das reduziert den Arbeitsaufwand für den Betreiber des zentralen Services und überträgt die Verantwortung hauptsächlich an die Geschäftspartner selbst.

Ein Transaktionszentrum orientiert sich zunächst, genau wie ein Marktplatz, ein Online Shop oder ein Portal, an einer Thematik. Dies kann etwa Mode, Sport oder der Buchhan-del sein, wobei es nicht ausgeschlossen ist, daß neue Themengebiete hinzukommen.

Im Gegensatz zum elektronischen Marktplatz bietet ein Transaktionszentrum nicht nur die direkten Verbindungen von B2B oder B2C, sondern auch darüber hinaus gehende, wie B2B2C¹² an. Die Funktionalität eines Transaktionszentrums geht hin bis zur Unterstützung von angebundenen Geschäftseinheiten über angebotene Zusatz- und Hilfsmodule. Diese vereinfachen die Anbindung und den Datenaustausch mit dem Transaktionszentrum. Anders als beim Portal, das noch weniger Funktionalität als ein Marktplatz besitzt, werden nicht nur Verweise auf andere Dienste angeboten. Darüber hinaus werden diese Dienste auch gesteuert und überwacht und tragen oft¹³ zum direkten Profit des Transaktionszen-trums bei.

Das Transaktionszentrum vermittelt Anbieter und Kunden, möglichst immer über den indirekten Weg, nämlich über die Plattform des Transaktionszentrums selbst. Es tritt beratend gegenüber Geschäftspartnern auf. Die Beratung findet weitgehend automatisch und auf elektronischem Wege über elektronische Services statt und nicht in der klassischen Form eines persönlichen Beraters.

Zum Betrieb eines Transaktionszentrums sind umfangreiche Hardware- und Softwareanforderungen zu erfüllen. Hauptsächlich kommen größere Firmen als Betreiber in Frage, davon ausgehend, daß der Betreiber eine entsprechende Plattform selbst entwickelt.

Ein Transaktionszentrum kann in drei logische Schichten unterteilt werden¹⁴:

Zum einen handelt es sich um die hardwaretechnische Realisierung des zugehörigen Systems. Diese umfaßt hauptsächlich die Netzwerkarchitektur, die verschiedenen notwendigen Server wie Datenbankserver, Anwendungsserver, File Server, aber auch Sicherheitsvorkehrungen wie Firewalls oder Performancesteigerung durch Lastenteilung. Ein weiterer Bestandteil ist die softwaretechnische Realisierung, also die Bereitstellung einer für den Betrieb geeigneten Infrastruktur. Dazu zählen Schnittstellen, Module und Applikationen zur Bereitstellung der notwendigen E-Business Funktionalitäten sowie Software im engeren Sinne wie zum Beispiel Datenbanksysteme.

Die dritte Komponente ist die Beschaffung von Informationen durch entsprechende Personen. Diese Informationen werden den Marktteilnehmern in Form von Mehrwertdiensten wie Newslettern zur Verfügung gestellt. Ergänzend dazu sind interne Daten und Informationen über Marktteilnehmer zu pflegen und Statistiken zu erstellen.

Wichtigster Bestandteil eines Transaktionszentrums ist der Kern des Systems, dessen Haupt-komponente der Transaktionskoordinator ist, wie er in dieser Arbeit genannt wird. Der Message Handler als Teil des Transaktionskoordinators ist dabei für die Verarbeitung, Auf-bereitung und Weiterleitung von Meldungen zuständig. Der Transaktionskoordinator hat insgesamt die Aufgabe, Abläufe zu steuern. Informationen werden in diesem Zusammen-hang auch als wichtige Komponente zur Erzielung und Beschleunigung einer möglichen Transaktion angesehen.

3. ANFORDERUNGEN AN EIN E-BUSINESS TRANSAK- TIONSZENTRUM

3.1. Überblick

Der Begriff des E-Business Transaktionszentrums ¹⁵ wurde im Kapitel Grundlagen bereits erläutert. In diesem Kapitel wird näher beschrieben, welche informationstechnischen Anforderungen ein solches Transaktionszentrum im allgemeinen zu erfüllen hat. Im darauf folgenden Kapitel werden dann informationstechnische Konzepte vorgestellt.

Wesentliche Bestandteile eines E-Business Transaktionszentrums, das in dieser Arbeit betrachtet wird, sind:

- Bereitstellen von Schnittstellen und Mechanismen zum Datenimport und -export
- Anbinden externer Systeme und Zusammenspiel mit diesen
- Bereitstellen von Dialogen und Masken zur Eingabe von Daten und Informationen
- Bereitstellen, Ermöglichen und Abwickeln von Geschäftsprozessen und elektronischen Services
- Koordinieren und Durchführen von Transaktionen
- Durchführen von Datenhaltung, Datenaufbereitung, Datenarchivierung und Datensi- cherung
- Bereitstellen von Zugriffsmöglichkeiten für Administratoren und Außendienst

Die Anforderungen an ein Transaktionszentrum sind vielfältig. Die Integration von Standards wie XML¹⁶ oder EDI ¹⁷ ist entscheidend, um möglichst vielen Geschäftseinheiten einen standardisierten Zugang zu ermöglichen. Das Sicherstellen von Hochverfügbarkeit und ausreichender Performance muß gewährleistet werden, damit Kunden dem Dienst Vertrauen entgegen bringen können und zufrieden sind. Das Absichern aller Daten, Transaktionen und Geschäftsprozesse gegen Datenverlust, Instabilität und unbefugten Zugriff ist zwar selbstverständlich, gestaltet sich in der Praxis aber schwierig.

Gleichzeitig ist sicherzustellen, daß der administrative Aufwands für den Betreiber des Transaktionszentrums so gering wie möglich ist. Eine steigende Anzahl von Dienstnutzern wirkt sich ansonsten negativ auf die Handlungsfähigkeit des Dienstbetreibers aus. Deshalb muß es für angebundene Unternehmen die Möglichkeit geben, sich im Rahmen des Mög-lichen selbst zu administrieren. Auf diese Weise wird der Dienstbetreiber entlastet und überträgt gleichzeitig Verantwortung und Arbeitsaufwand an seine Kunden. Im speziellen sind kundenspezifische Konfigurationen prädestiniert, von den Kunden selbst durchgeführt zu werden. Eine E-Business Plattform, egal welcher Gestalt sie ist, erhöht ihre Attraktivität enorm, wenn Kunden mit einer personalisierbaren und individualisierbaren Oberfläche arbeiten können.

Die angebotenen Dienste und Services bilden die Geschäftsgrundlage des Transaktions-zentrums. Sie müssen den Dienstnutzern erstens einen Nutzen bringen und zweitens gut verwendbar sein. Der Grad der Verwendbarkeit hängt mit von der Integrierbarkeit der je-weiligen externen Systeme ab. Die Vielfalt der angebotenen Dienste ist entscheidend für die Anzahl der nachfragenden Geschäftseinheiten nach diesen Diensten. Idealerweise er-laubt ein Transaktionszentrum seinen Kunden und Partnern die Einbindung von elektroni-schen Services in die E-Business Plattform. Ein Kunde, der auf diese Art über das Transak-tionszentrum seinen Dienst bereitstellt, kann dafür eine entsprechende Entlohnung erhal-ten. Will eine Geschäftseinheit einen Dienst nutzen, muß sie diesen zuerst ausfindig ma-chen. Bei wenigen angebotenen Diensten ist das unproblematisch. Erhöht sich die Anzahl, sind ausgeklügelte Verzeichnisdienste erforderlich. Die Einbindung externer elektronischer Dienste in das Transaktionszentrum ist in der Plattform E-Speak von Hewlett Packard mög-lich, wird im folgenden aufgrund der Komplexität des Themas aber nicht näher betrachtet.

Das E-Business Transaktionszentrum muß in der Lage sein, gewonnene Daten zu Informa-tionen verarbeiten zu können. Diese Daten werden durch Anbindung und Kommunikation mit den Dienstnutzern gesammelt und müssen weitgehend automatisch ausgewertet wer-den können. Die Kommunikation mit angebundenen Parteien bedeutet immer auch eine Kommunikation mit den jeweiligen externen Systemen. Für einfache Aufgaben ist der Aus-tausch von Dokumenten über Schnittstellen ausreichend, komplexere Aufgaben können möglicherweise nur durch direkte Kommunikation mit dem externen System selbst bewältigt werden. Ein entsprechender Mechanismus muß also bereitgestellt werden.

Insbesondere die Anbindung von Marktteilnehmern und der Informations- und Datenaustausch mit diesen ist ein wichtiger Punkt. Deshalb folgen im nächsten Abschnitt weitere Erläuterungen dazu.

3.2. Datenaustausch mit XML

Datenaustausch zwischen Transaktionszentrum und angebundenen Geschäftseinheiten geschieht über festgelegte Datenformate. In der vorliegenden Arbeit wird betrachtet, wie dies durch Austausch von Dokumenten vonstatten gehen kann. Ein automatisches Aus-handeln eines Datenaustauschformates zwischen den beteiligten Parteien, wie es Hewlett Packard auf seiner Marktplatzoberfläche E-Speak anbietet, wird hier nicht behandelt. Ebenso wird der Austausch von Daten per Streaming oder per direkter HTTP¹⁸ -Übertragung nicht untersucht, da für diese und andere Vorgänge genau wie für den Aus-tausch von Daten über Dokumente die Problematik des Datenformates im Vordergrund steht.

Im Rahmen dieser Arbeit wird das XML-Format als universelles Datenaustauschformat vor-geschlagen. Grund ist die trotz der erst kurzen Existenz von XML die starke Marktverbrei-tung und -akzeptanz. XML wird als der Nachfolger von EDI angesehen. EDI war vor Vor-handensein von XML ein wichtiger Bestandteil in der elektronischen Abwicklung von Ge-schäftsprozessen.

XML ist eine Metasprache und Auszeichnungssprache, die sich aufgrund ihrer Vorteile nicht nur im Bereich E-Business immer mehr als Standard etabliert. Als Metasprache bietet XML die Möglichkeit, andere Sprachen zu beschreiben und mittels der eigenen Grammatik na-mens DTD¹⁹ eigene Sprachen zu definieren. XML wurde vom W3C²⁰ definiert und ist frei verfügbar und verwendbar, da nicht durch Patente, Copyrights oder sonstige Eintragungen geschützt.

Während die weit verbreitete HTML²¹, die genau wie XML eine Auszeichnungssprache ist, keine Trennung zwischen Semantik und Inhalt zuläßt und im Gegensatz zu XML unflexibel ist, wird mit XML der Inhalt eines Dokuments vollständig von der Semantik und der Darstellung getrennt. Durch die Möglichkeit, mittels der DTD eigene Auszeichnungselemente²² zu definieren, ist die Möglichkeit auf formale Überprüfbarkeit²³ von XML-Dokumenten auf Korrektheit gegeben. Zudem wird durch die Möglichkeit der freien Definition zusätzlicher Sprachelemente eine entsprechende Flexibilität gewährleistet.

XML ist wie HTML aus der SGML²⁴ als Untermenge hervorgegangen. Die SGML existiert seit Mitte der 80er Jahre und wurde in der ISO 8879 Norm zum internationalen Standard für die Beschreibung von Dokumenten. Problem bei SGML war jedoch die sehr komplexe Syntax, die den Einsatz von SGML aufwendig und teuer machten, weshalb dieser Ansatz abgelehnt wurde. Mit XML wurde dann eine Sprache geschaffen, in der die Nachteile von SGML durch Verminderung der Komplexität behoben und die gewünschte Funktionalität beibehalten wurde²⁵.

EDI als bisheriges Markenzeichen der elektronischen Geschäftsabwicklung ist nicht mehr zeitgemäß. Die folgende Tabelle zeigt die Diskrepanzen.

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 1: Unterschiede zwischen EDI und E-Commerce²⁶

XML und EDI besitzen jeweils unterschiedliche Ausrichtungen. Demzufolge sind die Fähigkeiten dieser beiden Standards von einander abweichend. Mit XML/EDI wurde eine Sprache geschaffen, welche die Vorzüge von XML und EDI ineinander vereint. XML/EDI ist noch nicht etabliert und noch in der Reifungsphase und deshalb ungeeignet, hier anstelle von XML betrachtet zu werden.

3.3. Elektronische Services

Geschäftsgrundlage eines E-Business Transaktionszentrums sind elektronische Services. Zur Abwicklung dieser werden Transaktionen ausgeführt. Zu unterscheiden sind elektronische Services im allgemeinen und im speziellen Sinne. Allgemeine Services finden sich in großer Zahl im Internet, sei es auf elektronischen Marktplätzen, auf Portalen oder in Shopping Malls. Es handelt sich im Prinzip um geschäftsbegleitende Zusatzdienste. Teilweise sind derartige Dienste Bestandteil des Kerngeschäftes. Ein Beispiel ist die Darstellung von Pro-dukten in einem Online Shop. Für Endkunden ist eine umfangreiche, gut gestaltetet Prä-sentation notwendig, die im Prinzip Teil des Geschäftsprozesses „ Produktverkauf“ ist. Für den Verkauf von Produkten an Händler reicht eine einfache Darstellung aus, manchmal auch nur die Eingabe von Artikelnummern. Die Stammfunktionalitäten eines E-Business Systems richten sich also nach dem Empfänger der Leistung. Unabhängig vom Empfänger einer Leistung sind die informationstechnischen Funktionalitäten. Sie stellen die Basis für die Abwicklung von Geschäftsprozessen dar. Dazu zählt die Speicherung und Verarbeitung von Daten und Informationen, die Anbindung an andere Systeme und auch die Bereitstellung einer Plattform zur Ausführung von Programmen. Prozesse, die unabhängig von der Art der Geschäftstätigkeit sind, können ebenfalls den informationstechnischen Grundlagen zugeordnet werden. Insbesondere handelt es sich um Import und Export von Daten oder Administration und Konfiguration elementarer Systemkomponenten.

4. KONZEPTION EINES E-BUSINESS TRANSAKTIONS- ZENTRUMS

4.1. Einleitung

Kern dieses Kapitels ist die Vorstellung eines Konzeptes für ein E-Business-Transaktionszentrum. Das vorgestellte Konzept stellt im wesentlichen eine Systemarchitektur dar, die zur Abwicklung und Bereitstellung von E-Business Transaktionen und Geschäfts-prozessen geeignet ist. Es kann sich dabei aufgrund der Komplexität und der vielen unter-schiedlichen Anforderungen nicht um eine vollständige Berücksichtigung aller Belange und Notwendigkeiten handeln, sondern vielmehr um die Ausarbeitung eines grundsätzlichen, allgemeinen Ansatzes. Das hier vorgestellte Konzept basiert größtenteils auf eigenen Überlegungen. In einigen Teilen wurden Architekturkonzepte von auf dem Markt verfüg-baren Systemen in modifizierter Form eingebunden, die im nächsten Kapitel vorgestellt werden.

Das im vorliegenden Kapitel vorgestellte Konzept für ein E-Business-Transaktionszentrum kann im wesentlichen in drei miteinander verknüpfte Funktionsbereiche unterteilt werden, die in Abbildung 6 dargestellt sind. Jeder Funktionsbereich wird im Detail in den folgenden Abschnitten dieses Kapitels erläutert.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 6: Funktionsbereiche des Transaktionszentrums

4.2. Die Funktionsbereiche des Transaktionszentrums

Die grau hinterlegten Elemente sind Teile des Transaktionszentrums. Alle anderen Komponenten sind Teil externer Systeme.

Im Funktionsbereich „ Interne Verarbeitung“ findet die interne Bearbeitung und Weiterleitung von Informationen und Daten bzw. Anfragen innerhalb dieses Bereiches statt. Dies wird durch den Transaktionskoordinator als wichtigen Bestandteil des Transaktionszentrums und Hauptbestandteil der Komponente „ Interne Verarbeitung“ gemanagt. Diese Komponente ist der eigentliche Kern des Transaktionszentrums.

Anfragen von einem externen Absender werden durch eine Sendeeinheit zu einem Request Router weitergeleitet. Der Request Router wählt je nach Absender der Anfrage ein anderes Ziel innerhalb des Transaktionszentrums. Für das Empfangen von Anfragen durch externe Empfänger funktionieren Request Router und Empfangseinheit in analoger Weise genauso wie für den Sendevorgang von externen Absendern hin zum Transaktionskoordinator.

Die Sende- und Empfangseinheit dient also einerseits zur Verbindung des Transaktionszen-trums mit den unterschiedlichen Dienstnutzern wie Mitgliedern der Community, Admini-stratoren, dem Außendienst oder externen Systemen. Andererseits findet hier auch eine Lastenteilung statt, indem ein- und ausgehende Anfragen auf vorhandene Webserver ver-teilt werden und auf diese Weise für eine hohe Verfügbarkeit sorgen. Es handelt sich hier um den Teil des Transaktionszentrums, der für die Bereitstellung und Darstellung von Daten und Informationen für externe Systeme und Benutzer zuständig ist. Ebenso ist dieser Teil für die Bereitstellung der Schnittstellen nach außen verantwortlich, also hin zu externen Systemen.

Zudem befindet sich in diesem Teil des Systems die sogenannte DMZ²⁷, also die entmilitarisierte Zone, die durch entsprechende Sicherheitsmechanismen wie Firewalls abgesichert wird und sich hinter der Firewall im Bereich sensibler Systemkomponenten wie Datenbankserver oder Anwendungsserver befindet.

Um Daten und Informationen zwischen externen Systemen und dem Transaktionskoordi-nator austauschen zu können, bedarf es, einer zusätzlichen Komponente, die in der vorhe-rigen Abbildung mit Data Aggregator benannt ist. Diese zusätzliche Komponente ist zur Verarbeitung der vielen existierenden heterogenen Datei- und Datenbankformate notwen-dig.

Betrachtet man den Fall, daß es n Formate gibt, existiert die Möglichkeit, Austauschfilter zwischen allen n Formaten zu realisieren. Einerseits bedingt das eine hohe Komplexität und andererseits ist dieses Vorgehen nicht angemessen, da externe Daten hauptsächlich von Transaktionszentrum lesend verarbeitet werden. Deswegen bietet sich die Möglichkeit an, ein gemeinsames Austauschformat für Daten zu wählen, welches vom Transaktions-zentrum akzeptiert wird. Kann in den Fällen, in denen Daten vom Transaktionszentrum an externe Systeme geliefert werden, die entsprechende Applikation im externen System dieses Format nicht verarbeiten, werden für diesen Fall weitere Standardformate angeboten. Von den Standardformaten wird ein Format oder ein Set von Formaten für jeweils ein spezielles externes System vereinbart. Diese zusätzlichen Formate werden nicht direkt aus dem Datenbestand erzeugt, sondern erst aus dem Standardaustauschformat heraus bei Bedarf nachträglich generiert.

Zur Erleichterung des Vorgangs des Datenaustausches für externe Systeme werden vom Transaktionszentrum Zusatzmodule angeboten, die das eben Beschriebene leisten. Darauf wird später in diesem Kapitel in der Beschreibung des Data Aggregators detaillierter eingegangen, der ein solches Zusatzmodul darstellt.

4.3. Die interne Verarbeitung des Transaktionszentrums

4.3.1. Einleitung

Die nächste Abbildung zeigt den im vorigen Abschnitt dargestellten Teil der internen Verarbeitung im Detail, mit dem Transaktionskoordinator als Hauptbestandteil. Die Grafik stellt eine grobe Übersicht vorhandener Hard- und Softwaremodule dar. Dabei deuten Verbindungslinien zwischen Funktionseinheiten eine logische Zusammengehörigkeit an, und Pfeile weisen auf Daten- und Prozeßflüsse hin. Auf die einzelnen Funktionsbereichen wird später im Detail eingegangen.

Anmerkung:

In der folgenden Abbildung sind die Softwaremodule des Teilbereichs „ Interne Verarbei-tung“ der Übersichtlichkeit halber nur schematisch direkt mit dem Transaktionskoordinator (TAK) verknüpft. In Wirklichkeit arbeiten Softwaremodule wie etwa Import/Export, Statistik oder Empfang/Senden zwar mit dem Transaktionskoordinator zusammen, befinden sich aber auf möglicherweise unterschiedlichen Anwendungsservern und stellen eigenständige Module dar. In der Abbildung wird nur der logische Zusammenhang veranschaulicht.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 7: Interne Struktur eines Transaktionszentrums

4.3.2. Allgemeine Beschreibung

In der vorherigen Abbildung dargestellt sind der Transaktionskoordinator als zentrales Element und daran angebundene Hard- und Softwarekomponenten. Der Transaktionskoordinator ist als Zentrale innerhalb der internen Verarbeitung des Transaktionszentrums zu verstehen. Die interne Verarbeitung nimmt sich aller ins System kommenden Meldungen, Transaktionen und Prozesse an und ruft zu ihrer Verarbeitung entsprechende Komponenten auf. Hardwarekomponenten sind weniger mit dem Transaktionskoordinator logisch verbunden, so wie dies bei Softwarekomponenten der Fall ist, sondern sind vielmehr Träger von Programmen, Daten und Informationen. Im nächsten Abschnitt wird die Arbeitsweise des Transaktionskoordinators anhand eines Beispiels erläutert.

Die Hard- und Softwarekomponenten gliedern sich wiederum in Komponenten, die in ei-ner Grundversion vorhanden sein sollten²⁸ und solche, die als Erweiterung der Grundver-sion hin zu einer leistungsfähigeren bzw. erweiterten Version zu betrachten sind. Ausgangspunkt der Unterteilung in Grundversion und erweiterte Version ist ein Projekt, welches im Kapitel „ Praxisbeispiel: Die fashionmarket AG “ noch vorgestellt wird. Das Pro-jekt war so ausgelegt, daß zuerst und in relativ kurzer Zeit eine lauffähige Minimalversion entstehen mußte, die sich für Vorführungszwecke, Herausstellung der Funktionalität und Praxisbeispiele eignet. Später war daraus durch Erweiterung die vollständige Produktivver-sion zu erzeugen. Deshalb ist die Herausstellung einiger Komponenten als zur Grundversi-on zugehörig auf das Projekt bei fashionmarket abgestimmt, könnte im allgemeinen aber in dieser Form ebenfalls verwendet werden.

Generell ist eine Unterteilung in Grundversion und Vollversion bei der Projektplanung in-sofern oft unabdingbar, als bis zu einem bestimmten, kritischen Zeitpunkt eine vorzeigbare und zumindest teilweise funktionsfähige und lauffähige Lösung vorhanden sein muß. Man denke nur an Messeversionen oder Marketingpräsentationen von Vorabversionen und Re-leases.

In der Abbildung ebenfalls zu erkennen ist die Anbindung an externe Systeme wie Warenwirtschaftsanwendungen oder SAP, im speziellen auch an Auswertungseinheiten wie Data Warehouses, worauf später genauer eingegangen wird.

4.3.3. Der Transaktionskoordinator

Wie zuvor beschrieben, fungiert der Transaktionskoordinator als Zentrale bei der Verarbeitung von mehrstufigen Prozessen. Das nächste Beispiel verdeutlicht die Arbeitsweise dieser Zentrale.

Aufgabe ist es im Beispiel, eine Statistik in Form eines Dokumentes zu erstellen und dieses an zuständige Stellen zu verteilen. Die einzelnen Kriterien sind in der nächsten Liste angegeben. Alle Kriterien sind der Reihenfolge nach abzuarbeiten, sofern in der Abarbeitung kein Fehler auftritt. Die Aufgabe gliedert sich in mehrere Teile, die in der Reihenfolge der Nennung abzuarbeiten sind. Die Aufgabe lautet:

a) Zeitpunktgesteuertes Erstellen einer Statistik über Abverkäufe (als vertraulich ange- nommene Daten)
b) Berücksichtigung eines bestimmten Zeitraums und von Abverkaufsartikeln aus einer bestimmten Artikelgruppe
c) Konvertieren der Statistik vom Standardausgabeformat²⁹ in ein vom Empfänger ab- hängiges Zielformat
d) Verschlüsseln der Zieldatei, für deren Entschlüsselung die Empfänger der Statistik entsprechende Schlüssel haben
e) Versehen der verschlüsselten Datei mit einem Ursprungszertifikat
f) Weiterleiten an zuständigen Sachbearbeiter zu einem bestimmten Zeitpunkt über einen bestimmten Übertragungsweg
g) Senden einer Kopie der Statistik in einem anderen Zielformat an einen Sachbear- beiter einer Außenstelle
h) Erwarten einer Empfangsbestätigung sowohl vom Empfänger des „ Originals“ als auch der „ Kopie“ der Statistik
i) Backup der erstellten Statistik im Ursprungsformat auf einem Backupsystem / File Server

Zur Erledigung vorstehender Aufgabe müssen dem System einige spezifische Parameter übergeben werden:

a) Statistik erstellen
a. Statistik Abverkauf
b. nur bestimmte Artikelgruppen
c. für einen bestimmten Zeitraum
b) Ein Original ist für den ersten Empfänger und eine Kopie ist für den zweiten Emp- fänger zu erstellen
c) Adressen der Empfänger
d) Übertragungsweg pro Empfänger
e) Pro Empfänger ein Schlüssel für Kryptographie
f) Für jeden Empfänger ein vorgegebenes Zielformat
g) Zeitpunkte, wann jeder Empfänger sein Dokument erhalten soll

Einige Parameter müssen nicht übergeben werden, da sie dem System öffentlich bekannt sind, so etwa:

a) Zertifikat
b) Ablageort von und für Daten, meist File Server oder Datenbanken
c) Ablageort für Backups, meist File Server

Das folgende Sequenzdiagramm zeigt auf den nächsten zwei Seiten die Reihenfolge, in der die einzelnen Module aufgerufen werden.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 8: Sequenzdiagramm zur Aufgabe „ Statistik erstellen“ , Teil 1

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 9: Sequenzdiagramm zur Aufgabe "Statistik erstellen", Teil 2

Ablauf im System und involvierte Module:

Die Namen der involvierten Module sind der besseren Lesbarkeit wegen im folgenden unterstrichen.

1. Definition des Ereignisses

Das Ereignis „ Abverkaufsstatistik“ mit den oben beschriebenen Parametern ist dem System nach einmaliger Definition bekannt und in einer entsprechenden Datenbank abgelegt.

2. Eintragen des Ereignisses

Der Message Handler erkennt, daß die Statistik zeitpunktgesteuert zu erzeugen ist und erstellt einen entsprechenden Eintrag in der Terminüberwachung der Ereignissteuerung.

3. Auslösen des Ereignisses

Bei Eintreten des definierten Zeitpunktes feuert die Ereignissteuerung eine Meldung an den Message Handler und teilt auf diese Weise mit, daß das Ereignis „ Abverkaufsstatistik“ gestartet werden muß.

4. Start der Prozeßkette

Der Message Handler kümmert sich ab jetzt um die Weiterleitung der verschiedenen An-forderungen an die zuständigen Module, um die Statistik zu erstellen und den Empfängern zukommen zu lassen. Dazu wird zuerst das Statistikmodul beauftragt, eine Statistik über Abverkäufe für einen bestimmten Zeitraum und Artikel einer bestimmten Gruppe zu erstel-len.

5. Rückmeldung eines aufgerufenen Moduls

Nachdem die Statistik erstellt wurde, meldet das Statistikmodul dem Message Handler den Erfolg der Abarbeitung.

6. Export der erstellten Statistik in das Zielformat

Der Message Handler weiß nun, daß auf einem bestimmten File Server die gewünschte Statistik in einem Ursprungsformat vorliegt und sendet diese Informationen zusammen mit einem gewünschten Zielformat an das Exportmodul weiter.

7. Ablage des erstellten Zielformates

Das Exportmodul fertigt nun ein Exemplar der Statistik im vorgegebenen Zielformat an und legt die Datei auf einem dem Message Handler bekannten File Server ab. Statt eines File Servers könnte man sich auch einen Datenbankserver vorstellen, der jede Art von Informa-tion speichert.

[...]

---

¹ Nach [MER99], S. 6.

² Beispiel: bis ins 4. Quartal 2000 war die Yahoo! Shopping Mall für teilnehmende Anbieter finanziell und organisatorisch eine Zumutung und für Besucher wenig bedienerfreundlich.

³ Beispiel: eVita von der Deutschen Post als elektronischer Marktplatz samt eigenem Shop und elektronischem Arbeitsmarkt.

⁴ Vgl. [KUN00].

⁵ B2B = Business to Business.

⁶ Quelle: [DUB00], S. 55.

⁷ Hiermit sind neben Anbietern von Dienstleistungen oder Waren auch Kunden (privat oder kommerziell) des Dienstes gemeint.

⁸ Vgl. [MAR98], S.92.

⁹ Vgl. [LOM00], S.1.

¹⁰ Vgl. [KAL00], S.1.

¹¹ B2C = Business to Consumer.

¹² B2B2C bedeutet hier, daß ein Kunde (C) indirekt über einen Zwischenhändler (B) mit einem anderen kommerziellen Anbieter (B) in Geschäftsbeziehung steht.

¹³ Die Abwicklung von Geschäftsprozessen ist Hauptbestandteil des Transaktionszentrums. Andere Dien-ste wie Newsletter oder elektronische Foren stehen nicht im Vordergrund, sondern sind Zusatzservices.

¹⁴ Siehe auch [MAR98], S.96.

¹⁵ Im folgenden oft mit TAZ abgekürzt.

¹⁶ XML = eXtensible Markup Language.

¹⁷ EDI = Electronic Data Interchange.

¹⁸ HTTP = Hyper Text Transfer Protocol.

¹⁹ DTD = Document Type Definition.

²⁰ W3C = World Wide Web Consortium.

²¹ HTML = Hyper Text Markup Language.

²² Auch „Tags“ genannt.

²³ Es gibt bei XML die Unterscheidung in gültige und wohlformulierte Dokumente, worauf hier nicht näher eingegangen werden soll.

²⁴ SGML = Standard Generalized Markup Language.

²⁵ Vgl. [ALB99].

²⁶ Quelle: [KUN00].

²⁷ DMZ = De-Militarized Zone.

²⁸ In der Abbildung grau hinterlegt.

²⁹ Etwa XML.