Client-Server-Lösungen werden unter dem stetig wachsenden Einsatz von Internet-Geschäftsanwendungen bereits als die neuen "Light-Legacy"-Anwendungen bezeichnet. Allerdings haben sie damit keineswegs ausgedient. Die Gartner Group prognostiziert, daß die Web-Technologie bis 1999 die heutigen Architekturelemente erweitern, nicht aber ersetzen wird.
Die Unternehmen müssen also herausfinden, wie sich Client-Server-Lösungen mit Internet- beziehungsweise Browser-basierten Anwendungen für die jeweiligen Belange optimal kombinieren lassen. Ziele in diesem Zusammenhang sind in der Regel die engere Integration einer Logistikkette, die leichtere Entwicklung und Implementierung neuer Geschäftsmodelle sowie eine bessere Kontrolle der Technologiekosten.
Dynamisch partitionierte Client-Server-Strukturen
Im folgenden soll erklärt werden, wie ein moderner "Client-Server-Modus" und ein "Browser-Modus" aussehen und sich ergänzen können.
Die meisten Client-Server-Implementierungen sind so aufgebaut, daß der Client die Interface-Logik sowie Teile der Anwendungslogik und der ständig benötigten Daten verwaltet. Auf dem Server liegen die primären Daten und die Applikationslogik (Prozeßverarbeitung).
Deutlich mehr Flexibilität versprechen dagegen Architekturen, bei denen eine dynamische Partitionierung von Daten und Logik möglich ist. Das heißt: Anwendungsobjekte lassen sich auf die im Netzwerk vorhandenen Hardwareressourcen (Prozessorleistung und Plattenkapazität) verteilen.
Über Werkzeuge auf dem "Desktop-Client" ist es möglich, die komplette Standardsoftware auf einem PC bereitzustellen oder die Verarbeitungslogik und die Daten auf verschiedene Server zu verteilen (Anwendungspartitionierung). Anhand von Administrationsrechten läßt sich eine Konfiguration zur Laufzeit ändern, etwa um das Datenvolumen im Netzwerk und den Workload auf der Server-Seite sinnvoll aufzuteilen oder um die Stärken bestimmter Server-Plattformen optimal zu nutzen.
Die damit verbundene "höhere Verantwortung" des Clients erfordert einen PC der Pentium-Klasse mit einem 32-Bit-Windows-Betriebssystem. Standards wie TCP/IP als Transportprotokoll, SQL als Zugriffssprache und C/C++ als native Implementierungssprache sind die wesentlichen Voraussetzungen für die Offenheit einer derartigen Lösung.
Für die Flexibilität, das heißt die Partionierung von Anwendungs- und Datenobjekten, ist ein "Deployment Server" notwendig - etwa ein Windows-NT-Rechner, der als Schaltzentrale (Object Broker) die Zuordnung der Objekte zu den jeweiligen Daten- oder Anwendungs-Servern zur Laufzeit übernimmt. Der Client erhält so automatisch alle neuen Informationen.
Mit der Internet-Technik läßt sich die beschriebene Client-Server-Architektur um einen Browser-Modus ergänzen. Im Browser wird die Anwendungslogik oder besser gesagt die Abarbeitungslogik in Form von Applets zur Verfügung gestellt. Diese befinden sich auf einem für diese Zwecke speziell konfigurierten Web-Server, der auch die Verbindung zur Standardsoftware herstellt. Die Applets werden auf Anfrage des Clients in dessen Hauptspeicher geladen und auf der Festplatte zwischengespeichert. Dazu bedarf es einer Standard-TCP/IP-Verbindung und der im Web-Browser enthaltenen Java Virtual Machine (JVM).
Im Browser-Modus werden somit gemischte Konfigurationen im Unternehmen unterstützt: PCs, NCs, Macintosh- und Unix-Rechner können über diese Schiene koexistieren. Der NC von IBM unterstützt gleichzeitig die 3270- oder 5250-Emulation, so daß sich außerdem noch Green-Screen-Anwendungen nutzen lassen. Durch die zentrale Wartung der Applets auf dem Web-Server entfällt die Pflege von Client-Server-Konfigurationen.
Einen Nachteil muß man allerdings in Kauf nehmen: Aufgrund der Plattformunabhängigkeit bieten Browser-basierende Anwendungen bislang nicht dieselben Integrationsmöglichkeiten mit anderen Desktop-Programmen wie ihre OLE-fähigen Pendants.
Bei der Entscheidung zwischen Java oder Active X spricht die Hardware-Unabhängigkeit für Java. Die Web-Browser-Funktionalität nur auf einem Windows-Betriebssystem zur Verfügung zu stellen wäre zuwenig. Java ist durch seinen Bytecode unabhängig von der eingesetzten Hardware. Zudem spielt der Faktor Sicherheit eine wichtige Rolle. Ob es das Memory Model, der Java Verifier, die Access Control List oder der Browser selbst ist: Java bietet auf jeder Ebene Sicherheitsfunktionen. Active X hingegen läßt den Zugriff auf das Betriebssystem zu und öffnet damit Tür und Tor für Sicherheitsverletzungen.
In der Praxis würde es wenig Sinn machen, die komplette Funktionalität der Standardsoftware auf dem Web-Client bereitzustellen, da es je nach Geschäftsszenario durch die Kommunikation zwischen Applet und Server zu erhöhter Netzbelastung und nicht vorhersehbaren Wartezeiten käme. Die Performance von Java-Applets hängt momentan stark von der eingesetzten JVM ab. Java selbst hat noch Probleme mit der Cross-Platform-Portabilität. Einige JVMs (etwa Symantec Cafe, Sun JDK, die Netscape-Welt und der MS-Explorer JIT Compiler) unterscheiden sich bezüglich Performance und Portabilität beträchtlich.
Die Größe eines Applets beispielsweise in J.D.Edwards Standardlösung "Oneworld" für das Enterprise Resource Planning (ERP) bewegt sich zwischen 4 und 50 KB, je nach Objekt (Spezifikation oder Anwendung). Die meisten Applets werden nur einmal über das Netzwerk in den Cache des Anwenders geladen und dort zwischengespeichert. Die im Cache vorhandenen Objekte stehen immer zur Verfügung und sind damit wiederverwendbar.
Als Java-Applets sollten alle Abfrage-, Änderungs- und Neuanlage-Bildschirme (bezogen auf ein einziges Datenobjekt) zur Verfügung stehen. Auf eine umfangreiche Parent-Child-Darstellung (Beziehung von Kopfsatz zu mehreren Datenobjekten: Header-Detail-Relation) sollte dagegen aufgrund der erhöhten Netzbelastung verzichtet werden. Der Benutzer sollte jedoch anhand einer Toolbox jederzeit die Möglichkeit haben, die komplette Funktionalität oder nur Teile daraus als Applet zur Verfügung zu stellen.
Ein Anwendungsbeispiel wäre die Erweiterung der Logistikkette und die damit verbundene Einbindung eines Kunden oder Lieferanten. Diesem könnten für einen speziellen Bereich der Standardsoftware, etwa der Auftragsabfrage, auch noch Einblicke in die komplette Fertigungsauftragssteuerung eingerichtet werden. Die Sicherheit für den Zugang über das Internet darf dabei auf keinen Fall unterbewertet werden.
Der Vorteil eines Ansatzes, bei dem Java-Applets eine neue Architekturschicht oberhalb der schon existierenden Geschäftsanwendungen bilden werden, läßt sich leicht an der heutigen Unternehmenssituation erkennen.
In den meisten Betrieben hat aufgrund der hohen Bereitstellungskosten bislang nur ein Teil der Mitarbeiter Zugriff auf die eingesetzte Standardsoftware. Gewünscht werden jedoch eine bessere Nutzung der vorhandenen Kommunikationsinfrastruktur sowie ein flächendeckender Zugriff auf die Unternehmensanwendungen.
Dieser Forderung tragen die Browser-PCs oder NCs Rechnung. Sie liefern nahezu jedem Anwender einen Realtime-Zugang zu wichtigen Informationen und lassen sich mit vergleichsweise geringem Aufwand installieren und warten.
Jobprofil bestimmt den Client-Modus
Allerdings muß der flächendeckende Zugriff je nach Anwender differenziert organisiert werden. Entsprechend den Jobprofilen benötigen einige User einen kontinuierlichen Zugriff und die gesamte Breite der Anwendungssoftware, während andere nur die Möglichkeiten der Statusabfrage oder der direkten Dateneingabe ausschöpfen. Daraus ergibt sich ein Benutzerspektrum, an dessen Enden jeweils der analytische und der aktionsorientierte Anwender stehen.
Der analytische Anwender sammelt, analysiert und bereitet Informationen auf, um sie anschließend etwa an Entscheidungsträger, Marketing, Einkauf und Bedarfsplanung weiterzuverteilen. Er benötigt dazu eine breite Palette von Software-Werkzeugen, so daß sich hier der Client-Server-Modus mit einem OLE-basierten, voll integrierten Desktop-Arbeitsplatz am besten eignet.
Der aktionsorientierte Anwender ist in der Regel auf jeder Organisationsebene zu finden, sei es in der Auftragserfassung, beim Fertigungspersonal oder unter den leitenden Angestellten. Er nutzt beispielsweise das Anwendungssystem, um den Auftragsstatus oder die Verfügbarkeit von Artikeln zu prüfen - eine Aufbereitung der Daten erfolgt dagegen nicht. Hier empfiehlt sich der Browser-Modus mit seinem intuitiven Point-and-click-Zugang zu den relevanten Informationen und mit seinem minimalen Trainingsaufwand.
*Thomas Xander ist Senior Technology Consultant bei der J.D. Edwards Deutschland GmbH in Langen.