eCommerce

where business meets the net
Privathaushalte, Unternehmen und Bildungseinrichtungen verfügen zu einem immer höheren Prozentsatz über einen Internet-Anschluß. Dieses fast sprunghafte Wachstum begann ursprünglich mit der Idee des World-Wide-Web. Obwohl das Internet zu dieser Zeit schon länger existierte, war dies doch fast die erste Internet-Anwendung die eine Integration von Text und Bild in ansprechender Form ermöglichte. Zwischenzeitlich ist diese Integration auf eine Vielzahl weiterer Möglichkeiten ausgedehnt worden. Ton, Video, animierte Präsentationen und sogar ganze Programme in Form von Java Applets schmücken heute so manche Webseite, und ein Ende der Entwicklung ist momentan nicht absehbar.

Auch Unternehmen erkannten relativ schnell einige der Vorteile, die ihnen durch dieses neue Medium zur Verfügung standen. Informationen über die Produkte, die Mitarbeiter, das Firmenumfeld und die Unternehmensphilosophie können dem Kunde in kürzester Zeit zugänglich gemacht werden. Durch die geringen Distributionskosten besteht die Möglichkeit, die Informationsqualität der verfügbaren Dokumentationen bei gleichbleibenden Kosten wesentlich zu erhöhen. Diese Entwicklung hat Einfluß auf eine Vielzahl von Branchen, die bislang in die konventionelle Erstellung und Verteilung von Informationen eingebunden sind. So ist das große Engagement von Druckereien, Verlagen und Buchhandlungen im Internet nicht verwunderlich, gilt es doch verlorene Marktanteile an dieser Stelle wieder zurückzugewinnen.

Die zunehmend freiere Verfügbarkeit von Informationen und digitalen Produkten, zu teilweise verschwindenden Kosten, führte allerdings auch zu einer Veränderung des Kundenverhaltens. Notgedrungen sind deshalb ganze Branchen wie beispielsweise die Musik- und Videoindustrie oder Buchverlage auf der Suche nach Geschäftsmodellen, die das Medium Internet berücksichtigen. Aber auch Branchen mit Produkten, die weniger kopierfähig, sind interessieren sich für den neuen Handelskanal. Wenn schon Produktinformationen direkt ohne Zwischenstationen an den Kunden geliefert werden, dann liegt es nahe auf dem gleichen Weg auch die Bestellungen entgegenzunehmen.

Aus dieser Motivation heraus entstand der Wunsch einen möglichst großen Teil des bisherigen Produktions- und Verteilungsprozesses direkt mit Hilfe moderner Informationstechnik abzubilden. Die so neu entstandenen Wege werden mit Schlagworten wie "eCommerce", "eBusiness" oder auch "eTrading" beschrieben.

Nachfolgend wird dargestellt, welche Mechanismen sich hinter diesen Schlagworten verbergen und welche technischen Bedingungen für die verschiedenen Realisationsformen notwendig sind.

Hinter all diesen Schlagworten verbirgt sich aus informationstechnischer Sicht ein und dasselbe Grundprinzip. Der nachfolgende Artikel versucht dieses Prinzip darzustellen. Dabei werden die wichtigsten Randbedingungen, die durch die heutige Technik vorgegeben werden, berücksichtigt. Die Darstellung vernachlässigt dabei die notwendigen Sicherheitseinrichtungen (Firewall, verschlüsselte Datenübertragung, ...) zugunsten einer klareren Veranschaulichung. Die realen Systeme beinhalten selbstverständlich noch zahlreiche Sicherheitsstufen. Das vorgestellte Prinzip ist dabei aber immer noch vorhanden.

Die technische Begleitung auf dem Weg zum unternehmerischen Erfolg

Bestandsaufnahme in Firmen-LANs

Kleinere Unternehmen, insbesondere die aus den nicht informationstechnischen Branchen, verwalten ihre Kundendaten nach wie vor in Form von Karteikarten (dazu zähle ich auch Kundenlisten in einer Textverarbeitung). Der Karteikasten hat allerdings meist ausgedient, wenn der Kundenstamm und/oder die Produktanzahl die 50-er oder 100-er Hürde überschritten hat.

Der erste Schritt zur besseren Datenverwaltung besteht dann im allgemeinen in der Erfassung der Daten mit Hilfe von Tabellenkalkulationen. Doch auch hier ist aus informationstechnischer Sicht recht schnell eine Sackgasse erreicht. Die Daten

• lassen sich bei dieser Lösung nicht so ohne weiteres zueinander in Beziehung setzen,
• zur besseren Übersicht findet teilweise eine redundante Datenhaltung statt,
• die Wiederverwendbarkeit in anderen Applikationen ist nicht immer möglich
• ...

Dies bedeutet aus technischer Sicht die Vernetzung der Arbeitsplätze und die zentrale Datenhaltung auf einem Server im Netzwerk. Damit ergibt sich die folgende schematische Darstellung der heute in Unternehmen häufig anzutreffenden Informationstechnik.
 

Abbildung 1: Zentraler Server im lokalen Netz (LAN) der Firma

Die zentrale Datenhaltung wird in Abhängigkeit der notwendigen Arbeitsplätze unterschiedlich implementiert. Generell lassen sich hier jedoch die folgenden beiden Kategorien feststellen:

• Datenbanksysteme auf Basis gemeinsamer Dateizugriffe
• Datenbanksysteme mit zentralem Serverdienst

Datenbanksysteme auf Basis gemeinsamer Dateizugriffe

Der zentrale Netzwerkserver stellt bei diesen Systemen "nur" den geteilten Dateizugriff als Funktionalität (Dienst) zur Verfügung (siehe Abbildung 1). Das Datenbanksystem verwaltet die Zugriffe der Benutzer autonom, indem es in einer zentral gespeicherten Datei entsprechende Einträge vornimmt. Konkurrierende Zugriffe werden dadurch im allgemeinen erfolgreich verhindert.

Nachteil dieses Systems ist die nach oben eng begrenzte Geschwindigkeit und Effizienz. Da es sich ja genaugenommen nur um reine Dateilese- und schreibzugriffe handelt, müssen beispielsweise im Zuge einer Abfrage sämtliche Datensätze der beteiligten Tabellen über das Netzwerk zur eigentlichen Datenbankapplikation auf der Workstation übertragen werden. Der Server bietet außer dem Dateidienst keinerlei weitere "intelligente" Dienstleistungen. Erst auf der Workstation wird entschieden, welche Datensätze tatsächlich zum Abfrage-Ergebnis hinzugefügt werden und welche Datensätze verworfen werden. Dadurch wird ein großer Teil der Daten nutzlos übertragen, verringert dabei aber trotzdem die freie Übertragungskapazität des Netzwerks.

Zudem erreicht der zentrale Netzwerkserver mit zunehmender Benutzeranzahl seine Grenzen. Während seine Prozessorleistung evtl. noch lange mithalten könnte, bremsen ihn die vergleichsweise langsamen Dateiein/ausgabeoperationen aus. Sämtliche Benutzer greifen auf die gleichen Plattenbereiche zu. Lese- und Schreibaktivitäten lösen einander in bunter Reihenfolge ab. Der Server kann nur durch intelligente Caching-Mechanismen versuchen diese Operationen möglichst lange durchzuhalten.

Derartige Systeme haben insbesondere aus Kosten- und Administrationsgründen in SOHOs (Small Office, Home Office) ihre berechtigten Einsatzorte. Trifft man aber auf die oben beschriebenen "Flaschenhälse", so hilft nur der Umstieg auf echte Datenbankserver. Üblicherweise ist hier als Grenze eine Benutzeranzahl zwischen zehn und zwanzig Usern als Faustregel zu beachten. Ein sehr prominenter Vertreter dieser Kategorie ist Microsoft Access.

Datenbanksysteme mit zentralem Serverdienst

Ein Datenbankserver verwaltet seine Daten natürlich auch in Dateien. Allerdings haben die einzelnen Workstations, bzw. die dort ablaufenden Datenbankapplikationen, keinen direkten Zugriff auf diese Dateien. Sie formulieren vielmehr ihre "Wünsche" an die Datenbank unter Verwendung der "Structured Query Language (SQL)". Diese "Wünsche", oder Anfragen, werden über das Netzwerk zum zentralen Datenbankserver übertragen. Hier wartet ein autonomer Serverdienst mit eigener "Intelligenz" (z.B. mit einem Webserver vergleichbar) auf derartige Anfragen und bearbeitet sie anschließend direkt auf der Serverplattform (siehe Abbildung 2).
 

Abbildung 2: Netzwerk mit SQL-Datenbankserver

Man kann sich diesen Vorgang auch so vorstellen: Die Anwendung des Benutzers formuliert eine Anforderung an den Datenbestand der Firma (ich will alle Kunden aus dem Postleitzahlenbezirk 88). Die Auswertung, welcher Datensatz dieses Kriterium erfüllt und welcher nicht, findet nun aber nicht mehr lokal auf der Workstation statt. Vielmehr unterzeichnet die lokale Anwendung eine Abtretungserklärung und tritt damit ihre Anforderung an den zentralen SQL-Serverdienst ab. Dieser "treibt" nun die Forderung ein und liefert das Ergebnis an die lokale Anwendung zurück.

Damit wird nur das Ergebnis der Anfrage an die Workstations zurückübertragen. Die notwendige Übertragungskapazität des Netzwerks wird somit wieder auf die wirklich Datenmenge verringert. Die Software des Datenbankservers reduziert außerdem durch eine effiziente Datenhaltung die Anzahl der notwendigen Dateizugriffe. Konkurrierende Zugriffe werden direkt vom Datenbankserver selbst verwaltet. Beispiele für derartige SQL-Datenbankserver wären: Microsoft-SQL-Server, Oracle, DB2, Adabas D, PostgreSQL, MySQL.

Das Prinzip des netzgestützten Direktvertriebs -

Die "Königslösung"

Diese Lösung geht von Unternehmen aus, die ihre Datenhaltung über einen zentralen SQL-Server betreiben. Über diverse Tricks kann man auch mit einem " Datenbanksysteme auf Basis gemeinsamer Dateizugriffe" diese Lösung implementieren. Das ist aber nur eine Behelfslösung und angesichts der Vielzahl heute verfügbarer SQL-Server nicht zu empfehlen.

Um Produkte im Internet per Direktvertrieb an den Kunden zu bringen, gibt es eine Vielzahl technischer Varianten. Meist handelt es sich aber nur um Abwandlungen eines gemeinsamen Grundprinzips. Diese "Abwandlungen" resultieren im allgemeinen aus technischen oder finanziellen Einschränkungen des Unternehmens. Hier soll nun zuerst das Grundprinzip vorgestellt werden. Dabei werden technische und/oder finanzielle Überlegungen vernachlässigt. Diese Einschränkungen sind nämlich für große Unternehmen heute schon hinfällig und angesichts der fallenden Telekommunikations- und Hardwarekosten ist dies auch für kleinere Firmen zunehmend Realität.

Beginnen wir mit einem Brainstorming zu den Wünschen an eCommerce. Dabei könnte folgendes als grundsätzlicher Anforderungskatalog entstehen:

• Das Unternehmen verwaltet seinen Warenbestand wie gewohnt über ein datenbankgestütztes Warenwirtschaftssystem. Für den normalen Mitarbeiter ergeben sich keine Veränderungen.
• Bestellungen oder Angebotsanforderungen mußten bislang nach schriftlichem Eingang von einem Firmenmitglied erfaßt werden. Dies soll zukünftig der Kunde über das Internet selbst vornehmen.
• Bestellte Ware soll bei der aktuell verfügbaren Lagerstückzahl abgebucht werden.
• Die Auslieferung soll unmittelbar aus dem System heraus gestartet werden.
• Das gleiche gilt für die Bezahlung der Ware. Entweder über netzgestützte Zahlungsverfahren oder über automatisierte Rechnungserstellung soll auch hier eine schnellere Abwicklung eingeführt werden.
• Ein längeres Brainstorming formuliert evtl. auch die folgenden Wünsche:
• Unterschreitet der Warenbestand eines Produkts die eingestellte Mindestmenge, so soll das System bei den hinterlegten Herstellern/Anbietern selbständig die jeweiligen Tagespreise in Erfahrung bringen.
• Die Waren werden automatisch beim aktuell günstigsten Zulieferer bestellt.
• Auf elektronischen Marktplätzen/Börsen kann das System neue Anbieter des Produkts aufspüren und zur Integration in das Bestellwesen vorschlagen oder autonom aufnehmen.
• Die Mitarbeiter des eigenen Unternehmens nutzen insbesondere die Kommunikationskomponente mit den Herstellern, um den Materialbedarf (Bürobedarf oder Rohmaterial in produzierenden Firmen) des Unternehmens zu ordern.
• Das System soll auch als Forschungsinstrument hinsichtlich des Kaufverhaltens und der Interessen des Kunden arbeiten. Jedem Kunden des Systems wird sozusagen ein Softwareagent zur Seite gestellt, der ihn während des gesamten Aufenthalts im Geschäft begleitet und beobachtet. Ein intelligenter Agent nimmt dabei den Kunden auch an der "Hand" und führt ihn vor "Regale", die seiner Meinung nach für den Kunden (oder auch für das Unternehmen) interessant sind.
• ... machen Sie selbstständig in diesem Stil weiter ...

Wie aus den obigen Überlegungen bereits deutlich wird, bedeutet dies eine Verknüpfung von Teilen des unternehmenseigenen Warenwirtschaftssystems mit dem Internet. Dies kann aber nicht bedeuten, dass der potentielle Kunde auf seinem Rechner eine spezielle Clientsoftware des Systems installieren muß. Auch hier gilt, wie hoffentlich in den klassischen Ladengeschäften üblich: "Der Kunde ist König!". Die einzige Annahme, die über einen Internetkunden getrost gemacht werden kann, ist die clientseitige Verwendung eines Web-Browsers. Jeder Webbrowser ist in der Lage HTML-Seiten darstellen zu können. Jede weitere Annahme hinsichtlich Funktionalität auf Kundenseite ist für ein kundenorientiertes Unternehmen bereits eine Verletzung des "Königs Kunde". Diese Sonderfunktionalitäten sind nämlich in den Internetstandards nicht vorgesehen. Da sie oft auch Sicherheitsrisiken bergen, werden sie nicht selten vom Benutzer oder von der zentralen Netzadministration abgeschaltet. Viele Firmen haben hier aus den Erfahrungen mit Viren und Trojanern der Bauart "I-love-you" gelernt. Das Resultat sind
firmenweite Policies, die die Aktivierung dieser Funktionen verbieten. Die meisten Privatanwender haben diese Lektion allerdings noch nicht so richtig gelernt.

Für ein professionelles eCommerce-System bedeutet das im Klartext:

Die Verwendung clientseitig ablaufender Funktionen wie Javascript, JScript, Visual-Basic-Script, Java-Applets, ActiveX, Cookies, Flash, und wie die sonstigen Zutaten des Cocktails DHTML sonst noch heißen mögen, ist nicht als zwingend vorzusehen.

Damit muß sämtliche Funktionalität eines wirklich professionellen e-Commerce-Systems rein auf der Seite des Servers implementiert werden. Das Schema eines solchen Systems finden Sie in Abbildung 3 dargestellt und im nachfolgenden Abschnitt erläutert.
 

Abbildung 3: Technisches Grundprinzip für eCommerce im Internet

Der Datenfluß in der "Königslösung"

Der Datenfluß basiert beim Modell nach Abbildung 3 auf folgenden Elementen:

1. Der Kunde bedient das System nur durch den Abruf von HTML-Seiten. Rückmeldungen, beispielsweise welche Waren er bestellen möchte, werden über Hyperlinks mit anhängenden Daten (GET-Methode des Hypertext-Transfer-Protokolls, siehe Online-News Nr. 10 - Das Common Gateway Interface (CGI)) oder über Einträge in Formulare getätigt.
2. Die HTML-Seiten mit dem Warenangebot liegen beim Webserver nicht statisch vor. Sie werden vielmehr von einem serverseitigen Programm, das über die CGI-Schnittstelle des Webservers (httpd) gestartet wird, ständig topaktuell erzeugt. Dazu bedient sich das Programm einer Datenbankschnittstelle und greift direkt auf die Produktdaten des Warenwirtschaftssystems zu.
3. Die Pflege des Warenbestands wird nach wie vor über das Warenwirtschaftssystem des Unternehmens getätigt. Da dessen Datenbestand aber auch die Grundlage der dynamischen Webseiten ist, ist diese Bestandspflege gleichzeitig eine Pflege der Unternehmenswebsite. Wird also beispielsweise eine Preisänderung oder ein neues Produkt erfaßt, so spiegelt sich dies unmittelbar im Webangebot des Unternehmens wieder.
4. Auch der Warenkorb des Kunden wird serverseitig gespeichert. Clientseitig notwendige Funktionalität wie Javascript hatten wir ja aus Gründen der Kundenfreundlichkeit ausgeschlossen.

Session-Management

Gerade bei der Einführung eines serverbasierenden Warenkorbs hat man allerdings erst einmal mit einer technischen Einschränkung zu kämpfen, die durch das Hypertext Transfer Protokoll (http) verursacht wird. Im World-Wide-Web wird nämlich jede Verbindung zwischen Server und Client nur für den Abruf einer einzelnen Seite aufgebaut und nach erfolgreichem Erhalt der Information sofort wieder beendet (http ist damit ein sogenanntes zustandsloses Protokoll). Außerdem sind die einzelnen Verbindungen aus Sicht des Webserverbetreibers so gut wie anonym. Der Betreiber kann zwar eine Client-IP-Nummer feststellen, kann diese aber keiner Einzelperson zuordnen. Durch den massiven Einsatz von Proxy-Servern bei fast allen Providern, können sich nämlich hinter einer einzigen IP-Nummer tausende von realen Kunden verbergen. Ein Warenkorb auf Basis der Client-IP-Nummer ist also leider nicht möglich.

Aus Sicht eines "elektronischen Geschäfts" ist es daher erst einmal unmöglich einen Kunden beim Gang durch den Shop zu "begleiten". Bedingt durch den ständigen Verbindungsabbau ist ein Seitenzugriff keinem Kunde eindeutig zuordenbar. In einem realen Kaufhaus könnte man sich das so vorstellen: Ein Kunde betritt das Kaufhaus und schaut sich ein Angebot an. Bevor er aber das nächste Angebot in Augenschein nimmt, verläßt er das Kaufhaus, kleidet sich evtl. sogar um und läßt sich den Bart abnehmen und betritt erst dann erneut das Kaufhaus. Diesen Vorgang wiederholt er in allen erdenklichen Verkleidungsvarianten bei jedem Angebot im Kaufhaus. Die Kaufhausbetreiber, in diesem Fall sind das die Webserverbetreiber, haben somit erst einmal keine Möglichkeit den Kunde eindeutig zu identifizieren und ein für einen Warenkorb notwendiges Kundenkonto zu führen. Damit scheint auch die Fiktion eines serverseitigen Warenkorbs erst einmal dahin zu sein.

Durch Verwendung eines Session-Managements kann dieses Problem jedoch behoben werden. Jeder Kunde, der den Webshop "betritt", erhält eine zufällige aber eindeutige Kennzahl - die sogenannte Session-ID. Diese Session-ID wird in einer von mehreren Varianten in die Webseiten, die der Kunde erhält, eingebaut und bei jedem nachfolgenden Seitenabruf an den Server zurückübermittelt, von diesem ausgewertet und erneut in Folgeseiten eingebaut. Anschaulich könnte man sich das so vorstellen: Der Kunde erhält einen zufälligen aber eindeutigen Strichcode auf die Hand gestempelt. Nun kann er sich so oft "verkleiden", wie er will, und ist doch bei jedem Besuch eindeutig identifizierbar. Der Webserver selbst speichert die vergebenen Session-IDs z.B. in einer Datenbank. Bei jedem Besuch des Kunden kann nun der Datensatz des Kunden erweitert werden, um beispielsweise Einkäufe abzulegen oder um den Weg des Kunden durch das Kaufhaus zu protokollieren. Dies erlaubt dann sogar eine individuelle Verhaltensanalyse des Kunden. Da ein Webshop ohnehin nur virtuell existiert, kann auf Basis dieser Verhaltensanalyse sogar jedem Kunden ein für ihn maßgeschneiderter Webshop präsentiert werden.
 

Zur Implementierung eines Session-Managements gibt es grundsätzlich die nachfolgend beschriebenen Mechanismen:

• Die Session-ID wird in jeden Hyperlink integriert, der in der Webseite enthalten ist. Dazu wird die Möglichkeit eines URL-Anhangs verwendet (GET-Methode eines http-Requests, siehe Online-News Nr. 10 - Das Common Gateway Interface (CGI)). In der Adresszeile des Browsers könnte das folgendermaßen aussehen (betreffender Teil ist fettgedruckt):http://www.der-supertolle-shop.de/angebot.pl?id= 3592FN9sa3&warengruppe=10

 

 
 
 

Da üblicherweise neben normalen Hyperlinks auch Formulare in solche Webseiten eingebaut sind, muß auch hier eine Lösung zur Übermittlung der Session-ID aus Formularen heraus geschaffen werden. Dazu wird die Session-ID als Hidden-Feld in Formulare eingebaut. Diese Formularfelder sind in der Webseite nicht sichtbar, ihr Wert wird aber bei der Betätigung einer Submit-Schaltfläche trotzdem an den Server übermittelt. Im HTML-Code sieht so ein Hidden-Feld beispielsweise so aus:

... <input type="hidden" name="id" value="3592FN9sa3"> ...

Sie finden hier die gleiche Session-ID wie im vorherigen GET-Beispiel.

Auch eine Mischung der beiden Verfahren ist jederzeit möglich. Dadurch kann jederzeit die gerade am einfachsten anwendbare Übermittlungsvariante eingesetzt werden.

• Eine andere Variante dieser Idee wird unter Verwendung von Cookies in die Tat umgesetzt. Wie schon weiter oben beschrieben, setzt dies allerdings die Freischaltung dieses Features auf Clientseite voraus. Ist dies nicht der Fall, scheitert ein Session-Management auf der Basis von Cookies. Der Serverbetreiber kann diese Funktionalität aber vor dem Einsatz von Cookies überprüfen und gegebenenfalls auf die erste Variante zurückschalten. Da bei der Verwendung von Cookies sogar ein Session-Management für Besuche im Zeitabstand von mehreren Wochen möglich ist, wird diese Variante auch eingesetzt.

Beim ersten Betreten des Webshops erhält der Kunde hier ebenfalls eine Session-ID, die er aber dieses Mal in Form eines Cookies selbst auf seine eigene Festplatte schreibt (siehe Online-News 12 - Cookies). Bei allen weiteren Seitenabrufen übermittelt er nun "freiwillig" die Session-ID an den Server zurück und erlaubt damit prinzipiell die Anwendung der gleichen Überwachunsverfahren (User-tracking) oder eines serverseitigen Warenkorb-Systems wie im ersten Session-Management.

Dieses Verfahren besitzt den Vorteil, dass die Cookies im Gegensatz zum vorigen Verfahren sogar einen Neustart des Browsers oder sogar ein Ausschalten des Rechners erlauben. Werden die Cookies vom Benutzer nicht gelöscht, so kann ein Kaufhausbesuch incl. des damals gezeigten Verhaltens evtl. ein Jahr oder noch länger zurückverfolgt werden.

Nachteilig wirkt sich hier wieder die notwendige Unterstützung durch den Client aus. Hat der nämlich die Unterstützung von Cookies deaktiviert (was durchaus einige Leute tun _ und es werden immer mehr), dann funktioniert der Cookie-basierende Weg nicht. Die vorige Variante funktioniert auf jeden Fall!

Das hört sich jetzt vielleicht kompliziert an und Sie fragen sich, ob das überhaupt so ohne weiteres programmierbar ist? Keine Sorge: Session-Management wird bereits durch eine Vielzahl von Servermodulen fix und fertig zur Verfügung gestellt. Ein richtig tiefes Know-how benötigt der Serverbetreiber nicht. Erst das "intelligente" Analysieren des Kundenverhaltens erfordert tatsächlich mehr Überlegungen.

Nun bleibt noch zu klären, welche Möglichkeiten der CGI-Prozeß hat, um den Datentransfer mit dem SQL-Server abzuwickeln.

Die Schnittstellen eines Datenbanksystems

Verabredungsgemäß hatten wir jegliche Funktionalität des Systems auf die Serverseite verlagert. Dort wird für jeden Seitenabruf über den Webserver ein CGI-Prozeß gestartet. Dieser hat nun die Aufgabe, mit dem SQL-Datenbankserver zu kommunizieren, um die Daten
für die angeforderten Informationen zu extrahieren. Dazu existieren heute die folgenden vier Möglichkeiten:

1. 1. Die Software wird für einen speziellen SQL-Datenbankserver maßgeschneidert. Dazu wird in einer adäquaten Programmiersprache das Application Programing Interface (API) des SQL-Servers benutzt und der Server damit direkt angesprochen. Wie es bei Maßanzügen aber so ist, bedeutet dies eine hohes Maß an Unflexibilität. Ein Austausch des eingesetzten Datenbankservers ist damit nämlich nicht mehr so ohne weiteres möglich. Selbst Skriptingsprachen sind davon teilweise betroffen. Eine sehr weitverbreitete Variante dieser Art von Datenbankzugriff ist die im CGI-Bereich anzutreffende embedded Skriptingsprache PHP. Erst in neueren Versionen wird hier versucht ein modulareres Konzept einzuführen.

Die nächsten drei Varianten (siehe Abbildung 4) sind wesentlich flexibler. Sie erlauben es über eine standardisierte Schnittstelle auf einen SQL-Datenbankserver zuzugreifen. Die Flexibilität wird dabei jeweils über ein modulares Konzept erreicht, bei dem der serverspezifische Teil in Form eines maßgeschneiderten Datenbanktreibers nachgeladen wird. Damit ist zwar auch hier beim Umstieg auf einen neuen SQL-Server eine Anpassung notwendig, wobei sich diese aber in den meisten Fällen auf den Austausch eines einzigen Werts (nämlich den des zu verwendenden Treibers) reduziert.
 

2. 2. Bei Perl-Skripten erfolgt der Datenbankzugriff über die Kombination aus dem universellen Database Interface (DBI) und einem für die jeweilige Datenbank passenden Database Driver (DBD). Das Database Interface (Perl-Modul DBI.pm) läßt sich hier unabhängig vom eingesetzten SQL-Datenbankserver programmieren. Für den eigentlichen Datenbankzugriff verwendet das DBI einen maßgeschneiderten DBD. Das Nachladen des notwendigen Treibers übernimmt das DBI.
3. 3. Der Datenbankzugriff erfolgt über die Open Database Connectivity (ODBC) Schnittstelle. Dieser Standard wurde von der Firma Microsoft implementiert und offen gelegt. Dadurch existiert heute für fast jeden Datenbankserver auch der passende ODBC-Treiber. Um damit einen Datenzugriff zu implementieren, wird auf Systemebene einer Workstation (Systemsteuerung bei allen MS-Windwos-Varianten) eine ODBC-Datenquelle konfiguriert. Anschließend kann mit Hilfe von ODBC-fähigen Datenbankfrontends, wie z.B. MS-Access, auf die Daten zugegriffen werden (siehe hierzu auch den Artikel zur Anbindung eines MySQL-Servers via ODBC in dieser Ausgabe).
4. 4. Ein für den Anwendungsprogrammierer sehr artverwandtes Konzept wird bei Java-Anwendungen über die Java Database Connectivity (JDBC) Schnittstelle erreicht. Allerdings werden die Datenquellen dabei nicht auf Systemebene vorkonfiguriert, sondern die Anwendung lädt sich den entsprechenden JDBC-Treiber selbst nach und übergibt dabei die passenden Verbindungsparameter. Programmierer, denen die ODBC-Funktionsaufrufe schon bekannt sind, werden die JDBC-Aufrufe sehr bekannt vorkommen. Hier wurde versucht ein Höchstmaß an Kompatibilität zu erreichen.

Abbildung 5: Zugriffsvarianten auf SQL-DB-Server mit DBI, ODBC u. JDBC

Abweichungen von der Ideallösung

Das oben beschrieben Idealszenario kann schon heute umgesetzt werden. Es gibt insbesondere von den namhaften "Enterprise Resource Planning" (ERP) - Herstellern (z.B. SAP) die notwendigen Module um die zugehörigen Firmensysteme und -datenbanken (bei SAP wäre das beispielsweise R3) an das Internet anzubinden. Es muß aber nicht immer so groß sein. Auch kleinere Lösungen lassen sich hier ohne größere Probleme implementieren. Es gibt in vielen Firmen aber die eine oder andere Einschränkung die eine sofortige Umsetzung der Ideallösung verhindern.

Das Problem - und deshalb habe ich absichtlich die Bestandsaufnahme des Firmen-LANs an den Anfang dieses Artikels gestellt - beginnt bereits bei der Datenhaltung im lokalen Netzwerk. Häufig wird hier mit proprietären Systemen gearbeitet. Schnittstellen gibt es evtl. gar nicht und, falls doch, gibt es in der Firma kein Know-how zum Aufbau eines eCommerce-Systems nach obigem Muster. Damit die eCommerce-Site, wie oben beschrieben, online gehen könnte, bedarf es nämlich auch einer firmeninternen DV-Abteilung. Eine Standleitung muß beispielsweise die Site ans Internet anbinden. Firewall-Lösungen zum Schutz des firmeneigenen Netzes (vor allem auch des sensiblen Datenbankservers) sind aufzubauen. Auch die firmeninterne Logistik darf bei der Planung nicht vernachlässigt werden. Was hilft schließlich das schönste System, wenn niemand den Versand der bestellten Ware veranlaßt oder Rechnungen nicht ausgedruckt werden!

Zumindest das Problem mit der fehlenden Standleitung läßt sich lösen. Dazu wird der vertriebsrelevante Teil des firmeninternen Warenwirtschaftssytems in einer eigenen Datenbank abgebildet. Diese Replikation wird dann bei einem Provider, der Datenbankserver anbietet und CGI-Programme erlaubt, installiert. Nun muß zu regelmäßigen Abständen ein Abgleich der Datenbestände zwischen den beteiligten Systemen vorgenommen werden, und schon funktioniert es auch so (siehe Abbildung 6).
 

Abbildung 6: Eine "kleinere" Lösung

Der Repliaktionsmechanismus wird im Normalfall selbst bei bestehender Standleitung aus Sicherheitsgründen verwendet. Es ist immerhin ein nicht zu vernachlässigendes Risiko, irgendwelche Internetkunden auf Basis der realen Datenbestände operieren zu lassen. Wie leicht verirrt sich hier evtl. einmal ein ambitionierter Hacker auf diese eCommerce-Site und findet dann auch noch tatsächlich ein Loch? Die Konsequenzen eines 100%-igen Datenverlusts für eine Firma muß ich hier wohl nicht näher ausführen! Oder stellen Sie sich einfach einmal vor, welche Außenwirkung es hat, wenn bekannt wird, dass der gesamte Kundenstamm der Firma von Hackern ausgespäht wurde!

Eine weitere Vereinfachung ergibt sich, wenn der Datenbankserver (bei näherer Betrachtung stellt man fest, dass das nur ein einzelner Serverdienst ist) und der Webserver in Form eines einzigen Rechners implementiert wird. Diese Variante dürfte die am weitesten verbreitete überhaupt sein.

Selbst wenn innerhalb des Unternehmens gar keine Datenbank implementiert ist, lohnt sich wegen der einfachen Datenverwaltung der Einsatz eines Datenbankservers beim Provider. Evtl. ist das ja dann auch der Beginn zur firmeninternen Umstrukturierung.

Ein Ausblick zum Schluß

Die in dieser Einführung vorgestellten Konzepte berühren scheinbar hauptsächlich die betriebswirtschaftliche Welt. Bei der Umsetzung sieht man jedoch, dass auch die Informationstechnik von diesen Entwicklungen sehr stark berührt wird. Sie ist für die Implementierung dieser Techniken in den Unternehmen verantwortlich.

Aber auch andere Bereiche von Unternehmen sind zunehmend mit diesen Umwälzungen konfrontiert. So gibt es heute schon Firmen, die ihre Produktion an das Internet ankoppeln. Der Kunde stellt dabei seine Wunschkonfiguration zusammen und überträgt diese über Internet-Technologien an den Hersteller. Nach einer Freigabe im Unternehmen können die Konfigurationsdaten direkt in der Produktionsanlage zur Herstellung des Produkts genutzt werden. Derartige Systeme sind bereits heute in der Zusammenstellung von Rechnersystemen oder bei der individuellen Möbelfertigung im Einsatz (Schema siehe Abbildung 7).

Die Überwachung und Fernsteuerung von Anlagen oder Bürokomplexen (Facility Management) stellt ein weiteres Gebiet für diese Technik dar. Mit den entsprechenden Sicherheitstechniken (Virtual Private Networks (VPNs), Firewall, Backupsysteme, ...) ist es ohne weiteres möglich diese Tätigkeiten ebenfalls internetbasiert abzubilden.

In beiden Fällen wird das vorgestellte System um einen weiteren Server erweitert. Er realisiert die Umsetzung der Daten aus der Datenbank in die Steuerungsinformationen des Fertigungssystems bzw. die Übertragung der Istzustände aus einer Anlage in die Datenbank. Letztere ist wiederum die zentrale Drehscheibe für den Zugriff aus dem Internet.

Abbildung 7: Internet-gekoppelte Produktionsanlage

Fazit: Die Vernetzung aller Unternehmensbereiche untereinander sowie mit dem Internet ist bereits heute Realität. Sie kann wegen der immensen Komplexität in der Schule nur rudimentär nachgestellt werden. Das reicht aus meiner Sicht jedoch auch vollkommen aus. Für "die Schule" scheint es mir wichtig den Lernenden einen Überblick über die hier vorgestellten Zusammenhänge zu geben. Je nach Schulart bietet sich eine fachbezogene Umsetzung in fächerübergreifendem Unterricht an.