Newsfeed abonnieren
E-World

Modulares Konzept für E-Commerce

Die neue E-Commerce-Lösung Enfinity von Intershop basiert auf modernen Softwarekonzepten wie dem Java Enterprise Model, CORBA, LDAP und XML. Der Application Server Power Tier von Persistence Software ist eine wesentliche Komponente in dieser Architektur.

Achim Scharf

Intershop ist eine der Erfolgsstories, wie man sie eigentlich nur aus dem Garagen-Mythos des Silicon-Valley kennt. Kurz nach der deutschen Wiedervereinigung (1990) gab Stephan Schambach im Alter von 19 Jahren sein Physikstudium in Jena auf, um seine Ideen in einer eigenen Firma umzusetzen. 1992 gründete er mit Partnern die Firma NetConsult (1997 in Intershop umbenannt). Im Jahr 1996 baute er die Niederlassung in den USA auf, von wo er das Unternehmen heute als CEO und President führt. Wilfried Beeck, Co-Founder und Finanzvorstand leitet die europäische Intershop Organisation. Er hat mehr als 15 Jahre Erfahrung in der europäischen und amerikanischen Softwareindustrie und war 1992 einer der 3 Gründer von Intershop Communications. Beeck studierte Mathematik und Informatik an der Universität Kiel. Karsten Schneider, Senior Vice President Business Development, ist der Dritte im Bunde. Der Elektronik-Ingenieur war vormals in der Entwicklung bei Carl-Zeiss in Jena tätig.

Baustein der Digital Economy

Die Vision des Unternehmens ist die "Digital Economy", die Online-Abwicklung der täglichen Transaktionen aller Unternehmen mit ihren Lieferanten und Kunden, und das möglichst in Echtzeit. Mit der Realisierung dieser Vision wird die automatische Abwicklung eines großen Teils der internen und externen Geschäftsprozesse über das Internet, im Regelfall sogar vollautomatisch direkt von Rechner zu Rechner, zur Normalität. Letzterer Punkt wird auch als "Silent E-Commerce" bezeichnet.

Entsprechend geht es in der Digital Economy um mehr als nur den einfachen Vorgang des Verkaufens bzw. Kaufens. Die Unternehmen sind am erfolgreichsten, die den Anforderungen ihrer Kunden in Bezug auf Schnelligkeit, Flexibilität, individuelle Anpassung und Sicherheit am besten gerecht werden.

In der Forrester-Studie vom November 2000 belegt Enfinity 1.1 den ersten Platz unter den Anbietern von E-Commerce-Plattformen. Laut Forrester bietet Enfinity 1.1 umfangreiche E-Commerce-Funktionalitäten, vor allem bei Bestellprozessen und im Marketing. "Intershop bündelt leistungsfähige Analyse-Tools (Cognos) und verfügt über Adapter zu Personalisierungssoftware (Net Perceptions und Autonomy). Enfinity basiert auf einem Applikations-Server, der eine erstklassige Datenanbindung und Transaktionsmanagement ermöglicht", so die Bewertung.

Und der Nachfolger Enfinity 2 bietet verbesserte Integrationsfähigkeiten, Erweiterbarkeit und Skalierbarkeit. Dies ermöglicht noch einfachere Anbindung an Marktplätze wie Commerce One und an betriebswirtschaftliche Standardsoftware wie SAP, PeopleSoft, Oracle, und Siebel.

Die Preise für diese Highend-Lösung liegen je nach Ausstattung zwischen 150.000 und mehr als 300.000 Dollar pro Lizenz. Enfinity ist eine komplett XML- und Java-basierte Sell-side E-Commerce-Standardsoftware für den Enterprise-Markt. Mit der umfassenden Unterstützung von XML, das sich zum technischen Standard für den Austausch von Produkt- und Transaktionsinformationen zwischen Käufern und Verkäufern entwickelt hat, lassen sich Produkte auf den führenden Handelsplattformen im Internet anbieten (sell anywhere).

Dazu gehören die großen Online-Marktplätze wie CommerceOne's, MarketSite.net, die Network-eCommerce-Plattform von Ariba sowie SAP's mySAP.com. "Durch die Unterstützung von CBL 2.0 für den E-Commerce-Dokumentenaustausch spielt Intershop eine entscheidende Rolle bei der Verbindung zwischen Käufer und Verkäufer innerhalb des globalen Handelsnetzes", so Chuck Donchess, Vice President, Marketing und Business Development bei Commerce One. "Intershop's Sell-side-Technologie macht Business-to-Business so einfach und problemlos wie Business-to-Consumer". Die "sell anywhere"-Möglichkeit durch XML schließt den elektronischen Handel über schnurlose Geräte durch das Wireless Application Protocol (WAP) sowie Maschine-zu-Maschine-Transaktionen ein.

Fortschrittliche Architektur

Ferner basiert Intershop Enfinity auf einer offenen Architektur und verfügt über spezielle Schnittstellen für Anbieter von Ergänzungsprodukten (Cartridges).

Enfinity verfügt über eine Komponeten-basierte Architektur, die projektbezogen zusammengestellt werden kann. Die einzelnen Komponenten werden durch einen neuartigen sogenannten Pipeline-Manager zu einem kompletten E-Commerce-Geschäftsprozess zusammengesetzt. Dadurch verringert sich nicht nur die Implementierungsdauer für komplexe E-Commerce-Anwendungen, sondern dies ermöglicht ebenfalls stark erweiterte Verkaufsfunktionalitäten, spontane Marketing-Aktionen, transparente Transaktionen zwischen allen E-Commerce treibenden Firmen und WAP-Unterstützung.

Enfinity wurde von Grund auf als skalierbare Multi-Plattform entwickelt. Jede Komponente der Architektur ist duplizierbar, um die Redundanz und erforderliche Skalierbarkeit zu erzielen. Eingebaute Sicherungsmechanismen sorgen für größtmögliche Daten- und Transaktionssicherheit.

Aufbauend auf einer intuitiven grafischen Benutzerführung, wird über das Management Center Enfinity bedient und verwaltet. Mit dem internen Visual Pipeline Manager lassen sich Pipelines einsehen, modifizieren und bei Bedarf neu erstellen oder man kann den gesamten Workflow der E-Commerce-Applikation ändern.

Die nächste Ebene besteht aus Transactivity Server und Katalog Server, dem Kernstück von Enfinity. Der Katalogserver erlaubt die rasche und komfortable Erstellung von elektronischen Katalogen und die Auslagerung von Diensten bei Einkäufern, anderen Verkäufern und Computern im vernetzten Markt. Dieser Server verwaltet Produktdaten und Bilder und die Darstellung von Produktkategorien und -hierarchien am Bildschirm. Der Transactivity Server verwaltet Transaktionsdienste für eine Vielzahl verschiedener Geschäftsprozesse, für die es wiederum eine Reihe passender Komponenten gibt.

Der Intelligent Merchandiser steuert viele eingebaute Features von Enfinity, die es ermöglichen, die Vorteile von intelligentem Merchandising zu nutzen. Dazu gehören Kundenprofile, Quervermarktung, Produktvergleiche, Einkaufslisten, Verkaufsaktionen, intelligente Warenkörbe und detaillierte Reports.

Die Transaction Engine steuert eine Vielzahl von Kundentransaktionen, die im Laufe eines Geschäftsverhältnisses anfallen. Die kontrollierte Abwicklung der Geschäftslogik erfolgt durch sichere Pipelets, welche die Geschäftsprozesse steuern. Dazu gehören der Warenkorb, die Preiskalkulation, Kundenanmeldung, Kontoverlauf, Kundenpflege, Verkaufspromotionen, Berechnung der Versandkosten, Rechnungslegung- und -verwaltung, Versandabwicklung sowie statistische Berichte.

Der Pipeline Orchestrator steuert und kontrolliert Geschäftsabläufe zwischen Enfinity und anderen bestehenden Geschäftssystemen. Gemeinsam mit dem Visual Pipeline Manager (das grafische Benutzerinterface für den Orchestrator) lassen sich neue Geschäftsabläufe erstellen, verwalten und ändern, um die Website beispielsweise neuen Marktbedingungen anzupassen. Das Hinzufügen neuer oder das Abändern bestehender Funktionen erfordert gewöhnlich zeitraubende und kostenintensive Programmieraufträge. Enfinity ändert dies grundsätzlich mit sogenannten Pipelines, die sich aus mehreren Pipelets zusammensetzen, um den Geschäftsverlauf innerhalb der IT-Infrastruktur eines Unternehmens abzubilden. Individuelle Pipelets handhaben spezielle Funktionen und sind zu einer Pipeline zusammengefügt, um einen bestimmten Geschäftsablauf zu verwalten. Innerhalb einer Pipeline können Pipelets hinzugefügt, geändert, entfernt oder ersetzt werden. Gegenüber anderen E-Commerce-Applikationen, die nur eine Pipeline für die Bestellabwicklung haben, bietet Enfinity 100 eingebaute Pipelines, welche die Erstellung von vielen verschiedenen Geschäftsprozessen ermöglichen und so die Funktionalität der Lösung ständig erweitern.

Das Remote XML Interface ist die Verbindung zwischen Enfinity und externen XML-Systemen, um nahtlose und automatische Transaktionen zwischen Computen zu ermöglichen. Enfinity unterstützt auch das ICE-Protokoll innerhalb von XML, das für den Austausch von Inhalten zwischen Websites zuständig ist. Wenn eine Transaktion über den Transactivity Server abgewickelt wird, kann sich der elektronische Katalog auf derselben Site befinden, während die Produktinformation auf einer anderen Website abgebildet wird. Mit dem ICE-Protokoll ist es nunmehr möglich, die Transaktion auf einer fremden Website abzuwickeln, die von Enfinity mit den aktuellen Katalogdaten bedient wird.

Eines der wesentlichen Merkmale von Enfinity ist der modulare Ausbau durch Softwarekomponenten (Cartridges). Intershop bietet über 50 von ISVs entwickelte Applikationen an, die von Inhaltsverwaltung über Personalisierung und elektronischer Bezahlung bis hin zur Anbindung von Kundenverwaltungssystemen reichen.

Applikationsserver sichert Performance

Der Enfinity-Applikationsserver ist die Betriebsumgebung für den Katalogserver und den Transactivity-Server. Mit Enterprise Java Beans, Seitenkompiler, Sicherheitsfeatures und Session Handling unterstützt er die anderen Server und regelt den Datenfluss und -austausch. Darüber hinaus entspricht der Applikationsserver dem Enterprise-Java-Bean-Standard (EJB) und den Spezifikationen JDKTM 2.0, JWS 2.0 und JSPTM 1.0. EJBs repräsentieren das Enterprise Framework des Java-Komponentenmodells (Java Beans) für serverseitige Entwicklungen auf Basis einer Multi-Tier- und verteilten Objekt-Architektur. Das Modell ist sowohl für kleine als auch umfangreiche Geschäftsanwendungen mit hohen Transaktionsvolumina geeignet und unterstützt von Haus aus Web-basierte Anwendungen. EJBs sind schon heute der Industriestandard für die Entwicklung serverseitiger Java-Anwendungen und die Gartner Group schätzt, das im Jahr 2001 über 35% aller neuen Anwendungen mit Hilfe von EJBs gebaut werden.

Der PowerTier-Applikationsserver setzt sich aus einem Satz von Laufzeitdiensten und programmierbaren Anwendungs-Programmierschnittstellen (APIs) zusammen. Ein einzelner PowerTier-Server umfasst einen oder mehrere EJB-Container mit gehosteten Enterprise Beans sowie Services zur Automatisierung von infrastrukturellen Aufgaben wie gemeinsamem transaktionalen Caching, Synchronisation (PowerSync), Kommunikation und Integration sowie Container-Diensten. Die Interaktion zwischen Enterprise Beans wird vom Container gehandhabt.

Ein Alleinstellungssmerkmal von PowerTier ist der gemeinsam genutzte transaktionale Objekt-Cache. Als Daumenregel gilt, dass Anwendungen 10 Lese- auf einen Schreibzugriff in der Datenbank auslösen. Von diesen Leseoperationen greifen 80% auf dieselben Kerndaten in der Datenbank zu (80/20-Regel). Durch verbesserte Verfügbarkeit und Zugriffsmechanismen auf diese Kerndaten kann die Performance der Anwendung um Größenordnungen gesteigert werden. Power Tier cached daher oft genutzte relationale Daten im Arbeitsspeicher (siehe Kasten).

Mehrere Voraussetzungen stellte Stephan Schambach an einen zu integrierenden Applikationsserver: Java, XML, Lastverteilung, schnelles Caching sowie Lastverteilung. Der Applikationsserver Power Tier von Persistence Software erfüllte diese Anforderungen und fungiert als zentrales Element in der Enfinity-Architektur. Einerseits stellt er eine Basisfunktionalität sowie allgemeine administrative Unterstützung sowohl für den Transactivity Server als auch den Catalog Server bereit, andererseits erledigt er einige Initialisierungs- und Konfigurationsfunktionen.

Informationen wie Sprache und Währung, die im allgemeinen von diesen beiden Servern verwendet werden, laufen über den Applikationsserver. Wenn ein Surfer mit dem Store per Mausklick kommuniziert, wird auch die Frage nach der lokalen Sprache und der Währung gestellt. Enfinity unterstützt viele Sprachen und Währungen. Die Währung dient zur Präsentation und Berechnung der Preise, bei Dollar werden automatisch Cents für Teilbeträge herangezogen.

Neben den wesentlichen Anforderungen einer E-Commerce-Lösung wie Performance, Skalierbarkeit und Zuverlässigkeit ist eine weitere Funktionalität wesentliches Merkmal eines Applikationsservers, die Bereitstellung einer Abstraktionsschicht für die Datenbank-Schnittstelle. In Enfinity ist diese Schicht der Database Object Cache.

Der Database Object Cache Layer wurde mit PowerTier implementiert, indem dieser Applikationsserver als Container und Server für Enterprise Java Beans (EJB) fungiert. In Enfinity stehen auch die Entwicklungstools von Persistence mit der Enfinity Developer Edition (PowerTier Builder, ps-builder.exe) zur Verfügung, mit deren Hilfe sich schnell die passenden EJBs generieren lassen.

EJBs verwenden ein verteiltes Objektmodell, um die Datenbank-Abstraktionsschicht zu realisieren. Der Datenzugriff wird gekapselt und Entity Beans (persistente Java Beans) repräsentieren die Daten in der unterliegenden Datenbank. Diese Entity Beans leben über die Lebenszeit einer Session oder eines Servers hinaus und können von mehreren Clients gemeinsam benutzt werden. Weder ein Direktzugriff auf die Datenbank noch SQL zur Abfrage wird in diesem Konzept eingesetzt, sondern auf die Daten wird nur über die Java-Objekte mit dem PowerTier-EJB-Server zugegriffen. Für einen schnellen Zugriff auf die Datenbank nutzt PowerTier das native Datenbankprotokoll OCI (Oracle Call Interface) der zusammen mit PowerTier eingesetzten Client-Datenbank Oracle 8.0.4. Eine verteilte Enfinity-Umgebung erfordert mehrere separate Datenbanken für die Catalog und Tansactivity Server.

Der Database Object Layer unterstützt auch das Caching (siehe Kasten) sowie Persistenz. Der EJB-Server stellt System- und Management-Services wie Thread-Management oder den Connection Cache für die Datenbank zur Verfügung. Der EJB-Container ist für Status- und Session-Management (Persistenz) sowie für das Transaktions- und Lebenszyklus-Management zuständig. Bei der Entwicklung von Erweiterungen für den Server muss sich der Programmierer allerdings nicht um diese Details kümmern, diese Dinge handhabt der Database Object Layer. Der Programmierer braucht sich nur auf die Entwicklung der Geschäftslogik mit Hilfe der EJB-Interfaces und der bereitstehenden Klassen zu fokussieren.


E-Commerce und Caching

E-Commerce stellt an den Applikationsserver spezielle Anforderungen, beispielsweise Caching, um Katalogseiten dem Surfer schnell darbieten zu können.

Die einfachste Form ist Inhalts-Caching, das statische Informationen wie Dokumente aus den zentralisierten Systemen heraus und näher an die Anwender bringt. Das E-Commerce-Caching stellt für Transaktionen einen ähnlichen Mechanismus zur Verfügung. Es bewegt dynamische Daten und Prozesse im Netzwerk vorwärts und führt zu besserem Antwortverhalten für die Anwender bei gleichzeitig reichhaltigeren Personalisierungsdiensten und höherer Systemstabilität.

Ohne E-Commerce-Caching muss jede Transaktionsanfrage zentral bearbeitet werden. Das Zentralsystem ist damit der Engpass, aber auch ein Point of Failure. Daher muss bei jeder skalierbaren E-Commerce-Anwendung eine Dezentralisierung auf der Ebene des Applikationsservers stattfinden. E-Commerce-Caching ist am sinnvollsten für "lese-intensive" Applikationen, die im Web überwiegen, denn Internet-User sind mehr daran interessiert zu surfen, etwas über Produkte zu erfahren und Produkte zu vergleichen als Produkte zu kaufen.

Einer Studie von Net Effect und Nielsen zufolge liegt die Anzahl von Surfern, die eine Transaktion anstoßen, bei nur durchschnittlich 5,75%. Das bedeutet, 94,25% der Besucher einer Web-Site bringen keinen Umsatz. Weiterhin belegt diese Studie, dass 67% der Besucher, die eine Transaktion auslösen, diese vor dem endgültigen Kauf wieder abbrechen. Im Vordergrund steht daher eindeutig das Sammeln von Informationen, die Recherche und der Vergleich, weniger der eigentliche Kauf. Jedoch belastet diese Recherche die IT-Infrastruktur des Anbieters. Und wie verwundbar Web-Server auch großer Internet-Shops sind, haben die jüngsten Angriffe von Hackern gezeigt. E-Commerce-Sites kann man nicht zentralisiert betreiben.

Durch die Eliminierung von Zugriffen auf das Backend-System verbessert E-Commerce-Caching die Systemleistung. Multiple Punkte für die Transaktionsverarbeitung ermöglichen eine fast unbeschränkte Skalierbarkeit, eine Verteilung der Transaktionslast sowie Fehlerredundanz. Ähnliche Ansätze gibt es ja bei verteilten Festplatten in RAID-Speichern oder verteilten Datenbanken auf mehreren Servern.

Das patentierte Caching von PowerTier basiert auf der Isolation der Transaktionen sowie einem Lock-Management, um ein vergleichbares Niveau an Transaktionsintegrität wie relationale Datenbanken zu bieten. Das Caching läuft allerdings im Speicher ab, so dass die Geschwindigkeit gegenüber einem Standard-RDBMS ungleich höher ist. Durch die Verlagerung der am häufigsten angeforderten Daten als gemeinsam genutzte und persistente Entity Beans in den Speicher sind die Daten für alle Anwender verfügbar, damit lassen sich auch überflüssige Datenbank-Aufrufe sowie die Overheads beim Instantiieren neuer Objekte bei individuellen Anfragen von Clients vermeiden. Andere Anwendungen können diese Daten nur auf Per-User-Basis cachen, was sehr vorteilhaft ist bei der Duplikation innerhalb des Speichers oder der Sicherstellung aktueller Daten. Weiterhin kann PowerTier nur Objektwerte an Clienten übergeben, womit unnötiger Netzverkehr vermieden wird.

Der PowerTier-Cache bietet damit eine objektorientierte Repräsentation des Backend-RDBMS einschließlich der Verbindungen zwischen Objekten, die als Pointer im Speicher gecached werden. Dieses patentierte objekt-relationale Mapping (ORM) beschleunigt die Abfrage von Daten erheblich und optimiert die Transformation von Anwendungsobjekten auf die unterliegende relationale Datenbank mit Hilfe nativer Datenbanktreiber.

Die Integrität von Transaktionen ist durch einen separaten Transaktions-Cache und folgenden Ablauf sichergestellt. Wenn ein gecachtes Objekt im Laufe einer Transaktion aktualisiert werden muss (1), wird eine Kopie des Objektes in einem separaten, isolierten Cache (2) angelegt, so dass andere Clients weiterhin auf das Objekt im Haupt-Cache (3) zugreifen können. Wenn das Update im isolierten Transaktions-Cache erfolgt ist, übermittelt PowerTier die Änderung zunächst zur Datenbank (4). Erst wenn diese Änderung von der Datenbank akzeptiert wurde, werden sie in den Haupt-Cache kopiert und stehen dort allen Clients zur Verfügung (5).

weitersagen: drucken
Termine

18. Juni - 22. Juni

In ganz Österreich

SAP Mittelstandstage

Print-Archiv
Folgen Sie uns
Leser empfehlen
MONITOR-Newsletter

Abonnieren Sie unseren Newsletter!

E-Mail:
Die von Ihnen angegebene E-Mail Adresse wird von MONITOR Online weder an Dritte weitergegeben noch zu anderen Zwecken verwendet.
MONITOR-Autoren
Dr. Manfred Wöhrl

Dr. Manfred Wöhrl ist Geschäftsführer der R.I.C.S. EDV-GmbH (Research Institute for Computer Science, www.rics.at), spezialisiert auf Securitychecks und Security-Consulting. ..mehr..

Die neuesten Artikel:

© Copyright 1983-2012 by MONITOR / Bohmann Druck und Verlag Gesellschaft m.b.H. & Co. KG (www.bohmann.at)

Add to Google  | Abo | Themenvorschau | Mediadaten | Inserate buchen | Kontakt | Impressum