Melden Sie sich hier an, um auf Kommentare und die Whitepaper-Datenbank zugreifen zu können.

Kein Log-In? Dann jetzt kostenlos registrieren.

Falls Sie Ihr Passwort vergessen haben, können Sie es hier per E-Mail anfordern.

Der Zugang zur Reseller Only!-Community ist registrierten Fachhändlern, Systemhäusern und Dienstleistern vorbehalten.

Registrieren Sie sich hier, um Zugang zu diesem Bereich zu beantragen. Die Freigabe Ihres Zugangs erfolgt nach Prüfung Ihrer Anmeldung durch die Redaktion.

08.01.1999 - 

Jahresrückblick, Teil 2/Der Geist aus der Kaffeetasse zauberte eine schöne neue Welt

Java wurde das universelle Bindeglied der DV-Infrastrukturen

Vom Standpunkt der Java-Entwickler gesehen, war 1998 eine interessante und gute Zeit. Denkt man an das Potential dieser Plattform und der darauf aufbauenden Technologien, dann werden die nächsten Jahre mindestens genauso spannend werden. Ulrich Kriegel gibt eine Vor- und Rückschau.

Java ist heute eine vieldiskutierte und auch in geschäftskritischen Anwendungen erfolgreich eingesetzte Programmiersprache. Gerade für Entwickler mit Erfahrungen auf dem Gebiet dynamischer objektorientierter Programmiersprachen wie Common Lisp, Eu Lisp oder Smalltalk ist Java die Sprache der Wahl. Sie integriert die innovativen Konzepte der oben genannten Programmiersprachen wie dynamisches Laden, Introspektion und automatische Speicherverwaltung in eine universelle und plattformunabhängige objektorientierte Programmiersprache. Java ist sauber definiert und einfach, so daß es auch vom Standpunkt der Softwaretechnologie das Potential besitzt, eine der Mainstream-Sprachen der nächsten Jahre zu werden. Das bedeutet jedoch nicht, daß die Sprache selbst kritiklos angenommen wird1), sie ist aber, um es frei nach Winston Churchill auszudrücken, von den schlechten Programmiersprachen die beste.

Ein noch bestehendes Problem ist die relativ schlechte Performanz bei der Abarbeitung von Java im Vergleich zu C und C++. Java- Programme werden in einen plattformunabhängigen Byte- Code kompiliert, der dann von einer plattformspezifischen virtuellen Maschine interpretiert wird. Hier zeichnen sich zwei Lösungswege ab. Zum einen wurde die Architektur der virtuellen Maschine der Java-Referenzimplementation von Sun Microsystems (Sun) vollständig überarbeitet. Diese als "Exact VM" bezeichnete virtuelle Maschine liefert in Verbindung mit der Hotspot-Technologie2) eine deutlich bessere Performanz als die "Classic"-VM. Zum anderen bieten verschiedene Hersteller bereits Prototypen nativer Compiler an, die Java-Anwendungen in effizient abarbeitbare plattformspezifische Images übersetzen. Erfahrungen aus dem Compiler-Bau für objektorientierte Lisp-Programme zeigen, daß die Performanz 3) von C/C++ durchaus erreichbar ist, die wahre Meßlatte stellen jedoch Fortran und Cobol dar.

Viele der jetzt in Java vorgestellten beziehungsweise schon realisierten Konzepte sind nicht neu und basieren auf etablierten Technologien. Der Mehrwert von Java besteht darin, daß eine einheitliche und beherrschbare Infrastruktur für diese Technologien bereitgestellt wird.

Die Entwicklung der Sprache Java selbst ist abgeschlossen. Heute spielt sich die Entwicklung auf dem Gebiet der Spezifikation von Schnittstellen ab, durch die sich Java erweitern läßt. Diese Spezifikationen werden von Sun Microsystems und Partnern entworfen und dann öffentlich diskutiert. Sun stellt zwar Referenzimplementationen für diese Spezifikationen bereit, es ist aber jedem Java-Lizenznehmer freigestellt, eigene Implementationen anzubieten. Da die Entwicklung an vielen Stellen parallel und mit großer Geschwindigkeit erfolgt, ist es nahezu unmöglich, den Gesamtüberblick zu behalten und die Entwicklung zeitlich einzuordnen. Es ist deshalb auch nicht möglich, die "Java- Highlights" des vergangenen Jahres zu benennen. Jedoch war 1998 - rein intuitiv - ein Jahr, in dem sich das Potential von Java als universelles Bindeglied in DV-Infrastrukturen herauskristallisierte. Das soll im folgenden anhand dreier Beispiele näher erläutert werden:

-Java in der unternehmensweiten Datenverarbeitung;

-Entwicklung von Javaspaces, einer Technologie zur einfachen Realisierung verteilter Anwendungen und

-von Jini, der intelligenten Netzwerk-Schnittstelle.

Gerade die letzten beiden Technologien besitzen das Potential, Teil einer allgemeinen Infrastruktur des 21. Jahrhunderts zu werden.

Der Einzug von Java in die Unternehmens-DV

Bei der Programmierung von Anwendungen im geschäftlichen Umfeld müssen bestimmte Randbedingungen betrachtet werden. Meist besitzen die Anwendungen eine Transaktionssemantik beim Zugriff auf Datenbanken, sie sind verteilt und müssen unternehmensweite Sicherheitsanforderungen erfüllen. Skalierbarkeit und Langlebigkeit sind ebenso gefordert wie die nahtlose Integration in die bestehende DV-Infrastruktur, die meist nicht homogen ist und aus einer Mischung aus Mainframes, Unix- beziehungsweise NT- Servern und einem Zoo aus Client-Rechnern besteht.

Als Folge dieser Anforderungen beschreibt in heutigen Geschäftsanwendungen häufig nur ein relativ kleiner Teil des Codes die eigentliche Geschäftslogik, während der große Rest die nötige Sicherheits- und Transaktionsinfrastruktur implementiert. Als ein Schritt zur Lösung dieses Problems wurde unter Mitwirkung führender Middleware-Anbieter das Enterprise-Javabeans-(EJB- )Komponentenmodell spezifiziert, dessen Version 1.0 im März 1998 veröffentlicht wurde. Es stellt eine logische Erweiterung der 1997 mit dem Javabeans-Konzept eingeführten allgemeinen Komponentenarchitektur für die Client-Seite dar. Um EJBs in die Unternehmensinfrastruktur einzubetten und anzupassen, werden dieselben Konzepte und Mechanismen eingesetzt, wie zum Beispiel Codepattern und Introspektion. Die EJB-Technologie spezifiziert jedoch eine Komponentenarchitektur für die Server-Seite, die gemäß dem Java-Credo "write once, run anywhere" die Schaffung von wiederverwendbaren, skalierbaren, robusten, protokollunabhängigen und austauschbaren transaktionalen Objekten und Anwendungen ermöglichen soll. Mit der Spezifikation werden mehrere Ziele verfolgt. Konzeptionell soll die Entwicklung der Geschäftslogik von der Entwicklung der Infrastruktur getrennt werden; technologische Ziele sind die Vereinfachung der Programmierung verteilter Anwendungen und eine einfache Integration bestehender Anwendungen.

Eine EJB-Architektur besteht prinzipiell aus drei Komponenten: einem EJB-Server, einem oder mehreren EJB-Containern und den eigentlichen EJBs. Der Server stellt Dienste zur Installation einer EJB bereit. Neben systemnahen Diensten ist das zum Beispiel die Verwaltung verteilter Transaktionen und Objekte. Container bilden eine sichere, skalierbare und transaktionssichere Umgebung für eine EJB.

Außerdem isolieren sie EJBs von der Spezifik des darunterliegenden Servers, indem sie eine Standard-Schnittstelle zwischen der EJB und dem Container, den "Enterprise Javabeans Component Contract", bereitstellen. Anbieter von Containern dürfen diesen Kontrakt erweitern, so daß sich über den Container auch eine Verbindung zu bestehenden Altanwendungen herstellen läßt. Die Container selbst sind transparent für den Client.

Die EJB-Spezifikation legt kein Objektprotokoll zur Kommunikation zwischen Client und EJB-Server fest. Statt dessen können Server verschiedene Protokolle wie IIOP (Internet Inter Object Request Broker Protocol), RMI (Remote Method Invocation), und DCOM (Distributed Common Object Model) unterstützen, so daß der Client nicht notwendig in Java implementiert werden muß. Es ist deshalb auch denkbar, daß Server angeboten werden, die das DCOM-Protokoll unterstützen und damit eine Integration von Windows-Clients ermöglichen.

Die eigentliche Geschäftslogik wird in Form von Geschäftsobjekten (Business Objects) realisiert und lebt in einem EJB-Container. Eng mit dieser Architektur sind die folgenden fünf Rollen verbunden.

-Der EJB-Server-Anbieter erstellt die Server und veröffentlicht eine Schnittstelle4), so daß andere darauf aufbauend EJB-Container entwickeln können. Er ist ein Spezialist im Bereich verteilter Transaktionen, verteilter Objekte und systemnaher Dienste. Diese Rolle eignet sich für Anbieter von Betriebssystemen, Middleware oder Datenbanken.

-EJB-Containeranbieter implementieren EJB-Container für EJB- Server. Sie haben Erfahrungen auf dem Gebiet systemnaher Programmierung, eventuell auch in bestimmten Anwendungsbereichen. Typische Kandidaten sind Hersteller von Transaktions-Servern und Datenbanken.

-Der Anbieter von Enterprise Javabeans kapselt Teile der in einem Anwendungsbereich relevanten Geschäftslogik in Form von EJBs. Er hat Erfahrung in bestimmten Anwendungsbereichen, spezielle Kenntnisse auf dem Gebiet verteilter Transaktionen oder Datenbanken sind nicht erforderlich. Kandidaten für diese Rolle sind zum Beispiel Hersteller von Objektbibliotheken.

-Anwendungsprogrammierer kombinieren letztlich die EJBs unterschiedlicher Anbieter zu Anwendungen, für die gegebenenfalls noch Clients zu programmieren sind.

-Der Deployer ist ein Spezialist für eine spezielle EJB- Infrastruktur. Er ist verantwortlich für die Verteilung der EJBs und der Container. Vom Containeranbieter bereitgestellte Werkzeuge ermöglichen ihm die Anpassung an spezielle Laufzeitumgebungen.

Im Rahmen der EJB-Architektur können sich Entwickler voll auf die Implementation der Geschäftslogik konzentrieren, die Geschäftsinfrastruktur selbst wird durch zur Spezifikation konforme Enterprise-Javabeans-Server und -Container bereitgestellt. Besondere Werkzeuge zur Verteilung der Geschäftsobjekte und die Nutzung von Codepattern vereinfachen die Erstellung verteilter Anwendungen. Codepattern deklarieren bestimmte Eigenschaften eines Geschäftsobjekts, zum Beispiel dessen Verhalten im Kontext einer Transaktion. Werkzeuge generieren daraus Code, der sonst per Hand hätte erstellt werden müssen.

Entwickler können sich so auf die Realisierung der Geschäftslogik einer Anwendung konzentrieren, während die EJB-Infrastruktur alle anderen benötigten Dienste bereitstellt.

Viele Hersteller von Middle- ware haben bereits EJB-Server im Angebot beziehungsweise haben deren Auslieferung für die nahe Zukunft angekündigt.

Wie bereits erwähnt, können Containeranbieter Schnittstellen für den Zugriff auf nicht in Java implementierte Fremdanwendungen bereitstellen. Damit lassen sich dann EJBs implementieren, die existierende Geschäftsanwendungen kapseln. Der Vorteil für Entwickler besteht darin, daß sie von der Beachtung plattformspezifischer Besonderheiten befreit werden.

Ein anderer Weg für die Einbindung von Java in die unternehmensweite Datenverarbeitung wird von den Anbietern von Java-Entwicklungsumgebungen beschritten. Sie bieten in Form von Javabeans proprietäre Zugriffskapseln an, mit denen transparent über JDBC, der Java-Database-Connectivity-Schnittstelle, zum Beispiel auf Unternehmensdatenbanken oder über Corba (Common Object Request Broker Ar- chitecture) auf Fremdanwendungen zugegriffen werden kann. Teilweise wird sogar der Zugriff auf Mainframe-Anwendungen unterstützt, eine Einbindung von in Java implementierten Anwendungen in Netzwerk-Management-Systeme ist ebenfalls möglich.

Neben den Enterprise Java- beans gibt es Bestrebungen, Schnittstellen zu Technologien zu spezifizieren, die de facto Industriestandards darstellen, so daß mittels Java auch auf diese Technologien zugegriffen werden kann. Beispielhaft sei hier die ebenfalls im März 1998 freigegebene Spezifikation für den Java Message Service genannt, der den Entwicklern eine Standard- Schnittstelle für unternehmensweite Kommunikation bereitstellt, die Message Queues, Publish-und-Subscribe-Kommunikation und verschiedene Aspekte der Push/Pull-Technologie unterstützt.

Viele bis heute realisierte verteilte Anwendungen beruhen auf einer synchronen Kommunikation zwischen Anbietern und Nutzern von Dienstleistungen. Die aus der Synchronität resultierende enge Kopplung führt zu einer hohen Komplexität bei der Anwendungsentwicklung und Pflege. Hinzu kommt, daß die verwendeten Technologien, seien es nun RPC, Corba oder Enterprise Javabeans, nicht immer dem Problem angepaßt sind, da die hiermit realisierten Protokolle immer auf einer Art Methodenaufruf basieren5). Viele verteilte Systeme lassen sich jedoch viel besser durch einen Fluß von Objekten zwischen den beteiligten Entitäten beschreiben.

Die im Mai 1998 freigegebene Javaspaces-Spezifikation in der Version 1.0 beschreibt einen einfachen Mechanismus zum Erstellen asynchron arbeitender verteilter Anwendungen. Der Mechanismus beruht auf einem Austausch von Objekten, so daß sich damit sowohl Daten als auch Funktionalität zwischen den Teilen einer verteilten Anwendung austauschen lassen.

Die auszutauschenden Objekte sind beliebige Java-Objekte, die folgende Bedingungen erfüllen müssen:

-Sie müssen eine spezielle Schnittstelle (zum Beispiel net. jini.space.Entry) implementieren. - Ihre öffentlichen Attribute dürfen nur Objektreferenzen enthalten.

-Die referierten Objekte müssen serialisierbar sein.

Man kann sich einen Javaspace, korrekt ausgedrückt einen Java- space-Server, als ein Behältnis für Objekte vorstellen. Die Schnittstelle zu diesem Behältnis ist sehr einfach gehalten und besteht nur aus vier Operationen. Außerdem kann der Javaspace- Server eine Nachricht versenden, wenn Objekte einer zuvor definierten Art in das Behältnis gelegt werden.

Der Zugriff auf Objekte innerhalb des Behälters erfolgt über den Objekttyp und die Objektattribute. Um ein Objekt in einem Javaspace zu finden, wird ein Template-Objekt angegeben, das denselben Typ wie das gesuchte Objekt aufweisen muß.

Multiple Operationen über mehrere Javaspaces

Alle im Template-Objekt spezifizierten Attribute müssen exakt mit den entsprechenden Attributen des gesuchten Objekts übereinstimmen, nichtspezifizierte Attribute wirken dabei wie "Wildcards". Operationen, die den Inhalt eines Javaspaces modifizieren, lassen sich transaktionssicher abarbeiten, wobei innerhalb einer Transaktion auch multiple Operationen über mehrere Java-Spaces möglich sind. Die Lebensdauer eines Objekts in einem Javaspace hängt vom Kontext ab. Objekte können automatisch nach einer vorgegebenen Zeit gelöscht werden oder permanent in dem Javaspace verbleiben.

Um Ausfallsicherheit und Lastausgleich zu gewährleisten, erfolgt jeder Zugriff auf einen Java- space-Server über ein lokales Proxyobjekt. Der Client besitzt keine Information über den Standort des Servers. Die Erzeugung des Proxyobjekts erfolgt für den Nutzer transparent in einem zweistufigen Verfahren, in dem mittels eines Lokator- und eines Finder-Objekts auf einen Javaspace-Server über dessen Namen zugegriffen wird.

Vergleicht man den in Javaspaces implementierten Mechanismus mit dem eines RPC-basierten Systems, so wird deutlich, daß durch Javaspaces der Aufwand zur Programmierung von verteilten Systemen stark reduziert wird. Bei RPC-basierten Mechanismen müssen Protokolle und Schnittstellen entworfen werden, Client und Server sind zu implementieren. Im Gegensatz dazu besteht der Hauptaufwand bei der Arbeit mit Javaspaces in der Spezifikation von Abläufen und der Struktur der Einträge, einer Tätigkeit, die viel besser dem zu lösenden Problem angepaßt ist. Es muß nur der Client implementiert werden, der Server ist schon Teil der Infrastruktur. Die Bestandteile einer auf Javaspaces beruhenden Anwendung sind nur lose gekoppelt, so daß sich die Anwendung selbst einfach skalieren läßt. Die Kommunikation zwischen den Bestandteilen ist asynchron, so daß im Gegensatz zur synchronen Kommunikation keine Probleme mit blockierten Kommunikationskanälen auftreten können.

Intuitiv bietet sich die Java- space-Technologie für die Nutzung in Workflow- und Customer-Management-Systemen, im Supply-Chain- Management, in Handels- und in Agentensystemen sowie für Publish- und Subscribe-Dienste an. Ende November 1998 wurde eine Referenzimplementation von Java- spaces freigegeben, so daß sich mit der Technologie experimentieren läßt. Eine erste Anwendung findet diese Technologie im Rahmen von Jini.

Systeme aus verteilten Rechnern werden heutzutage immer komplexer, ihre Wartung erfordert stetig wachsende Aufwände. Man denke nur an die Installation neuer Treiber, wenn zusätzliche Geräte im Netzwerk installiert werden. Eine Möglichkeit, diese Komplexität zu beherrschen, besteht darin, Netzwerke aus kooperierenden Geräten aufzubauen, die aktiv ihre Dienste anbieten. Die Geräte müssen dazu eine beschränkte Verarbeitungskapazität besitzen, wie sie zum Beispiel durch die Integration von Embedded Java erreicht werden kann. Jini (Java Intelligent Network Interface) ist eine Technologie zum Aufbau von Netzwerken aus kooperierenden Geräten.

Technisch ist Jini eine Software, die auf der Basis von Javaspaces übergreifend über verteilte virtuelle Java-Maschinen läuft und Java-fähigen Geräten eine Plug-and-play-Funktionalität zur Verfügung stellt.

Konzeptionell kann Jini als Erweiterung des Enterprise-Java- beans-Konzepts betrachtet werden. Sun bezeichnet den "Jini-Basar" auch als Föderation von Objekten in einem verteilten "Computing space". Über einen Discovery- und Join-Dienst wird Anbietern ein Platz in der Födera- tion zugewiesen. Der Lookup-Dienst heftet Angebotskarten an die Pinwand und erhält Anforderungen für Transaktionen. Um auch mobile Endgeräte zu unterstützen, die nicht permanent im Netzwerk präsent sind, wurde das Leasing-Konzept für Dienste eingeführt: Ein Dienst darf nur für eine bestimmte Zeit gemietet werden.

Nach Ablauf der Zeit muß gegebenenfalls ein neuer Leasing-Vertrag ausgehandelt werden. Jeder Dienst kann spezifizieren, wer ihn nutzen darf und ob er exklusiv für eine Partei oder für mehrere zur Verfügung steht.

Die einzelnen Dienste kommunizieren über Distributed Events, eine Erweiterung des aus der Javabeans-Spezifikation bekannten Ereignismodells. Dienste müssen sich bei einer Ereignisquelle registrieren, um die Ereignisse zu erhalten. Die Jini- Infrastruktur sorgt dann dafür, daß die entsprechenden Dienste lokalisiert und die Ereignisse zugestellt werden können.

Trotz der beschriebenen Funktionalität ist ein Jini-System sehr klein und einfach aufgebaut, die Jini-Implementation benötigt etwa 48 KB RAM. Die Kommunikation erfolgt über die Standard-RMI- Schnittstelle durch Grundoperationen von Javaspaces. Jini beinhaltet das Sicherheitssystem der Java-2-Plattform, durch die Nutzung von Javaspaces besitzt Jini die Möglichkeit der Transaktionsverarbeitung und persistenten Speicherung von Objekten.

In Verbindung mit entsprechender Hardware besitzt Jini ein großes Anwendungspotential. So könnten Drucker selbst ihre Treiber zur Verfügung stellen, wenn jemand den Druckdienst in Anspruch nimmt. Der Phantasie sind dabei kaum Grenzen gesetzt. So sind zum Beispiel Konferenzräume mit Jini-fähigen Geräten denkbar, die alle Dienste auf dem Desktop eines über eine Infrarot-Schnittstelle angeschlossenen Laptops anbieten. Präsentationen müssen dann nur noch über Drag und drop mit den entsprechenden Anbietern von Dienstleistungen verbunden werden, zum Beispiel mit einem Beamer. Probleme mit fehlenden Treibern gehören der Vergangenheit an.

Jini-fähige Haushaltselektronik kann ebenso in Netzwerke integriert und verwaltet werden wie die Infrastruktur von Gebäuden. Die Integration von Sprachkommunikation und Datenverarbeitung, die heute nur mit erheblichem Aufwand möglich ist, läßt sich über Jini-fähige Komponenten stark vereinfachen.

Jini-Technologie beschränkt sich aber nicht nur auf die Integration von Geräten. Es ist auch denkbar, daß Softwarekomponenten ihre Dienste im Netz anbieten: Textverarbeitung, Tabellenkalkulation oder Suchmaschinen fallen einem im ersten Augenblick ein, betriebliche Informations- und Planungssysteme im zweiten.

Schaut man sich die Lizenznehmer dieser Technologie an, so befinden sich viele Hersteller von DV-Hardware unter ihnen. Mit Jini ist es möglich, Platten direkt in ein Netzwerk zu integrieren und Speicherdienstleistungen bereitzustellen. Wird diese Idee weiterverfolgt, dann ist es nur ein kleiner Schritt zu verteilten Rechnerarchitekturen, die aus separaten Jini-fähigen Komponenten wie CPUs, Speicherbänken etc. bestehen. Die Dienste werden bei Bedarf in Anspruch genommen, zur Koordinierung und Kommunikation benötigt der Client nur noch ein einfaches Jini-fähiges Endgerät.

Eine schöne neue Welt oder alles nur Fiktion? Möglicherweise beides. Auf den Javadays 98 wurde jedenfalls von einem Computer zur Berechnung eines Fraktals berichtet, in dem innerhalb eines Jini-Netzwerks mehr als zehntausend Java-Ringe 6) zusammengearbeitet haben."

Anmerkungen:

1) Siehe zum Beispiel die Sektion Sprachkritik auf der JIT''98 in Frankfurt/Main.

2) Mit dem Codenamen Hotspot bezeichnet Sun Microsystems eine neue Generation von "Just-in-time- Compilern", die den Code permanent optimieren. Dabei werden häufig betretene Code-Teile, die Hotspots, stärker optimiert als zum Beispiel Code-Teile, die nur einmal betreten werden.

3) Die Exact Vm und Teile der Hotspot-Technologie stehen für die JDK ab Version 1.1.7 für Solaris schon zur Verfügung.

4) In der Version 1.0 der EJB-Spezifikation ist die Schnittstelle des EJB-Servers noch nicht standardisiert. Für spätere Versionen ist das jedoch nicht auszuschließen.

5) Vom Standpunkt der Softwaretechnik können dann konzeptionelle Brüche zwischen den einzelnen Phasen der Anwendungsentwicklung auftreten, die Wartung und Pflege derartiger Anwendungen zusätzlich erschweren.

6) Ein Java-Ring ist ein Ring, der eine virtuelle Java-Maschine enthält. Die darin gespeicherte Information läßt sich unter anderem zur Erteilung von Zugangsberechtigungen oder für Abrechnungszwecke verwenden.

Angeklickt

In puncto Java-Entwicklung war 1998 ein sehr interessantes Jahr. Zur Zeit spielt die Musik auf dem Gebiet der Spezifikationen von Schnittstellen, durch die sich Java erweitern läßt; die Entwicklung der Sprache selbst scheint abgeschlossen. Tatsache ist, daß Java in die unternehmensweite Datenverarbeitung Einzug hält, ferner, daß Javaspaces verteilte Anwendungen realisieren hilft und Jini, quasi wie der Geist in der Flasche, den Aufbau von Netzwerken unterstützt, die Dienstleistungen und Produktvertrieb vorhalten; Sun spricht in diesem Zusammenhang von einer Föderation von Objekten.

Wie ein Basar

Man kann sich ein Jini-Netzwerk als einen Basar vorstellen, in dem Händler ihre Waren anbieten. Ein Kunde informiert sich an einer Pinwand am Eingang des Basars, welche Händler präsent sind und was für Dienste sie anbieten. Er verhandelt dann mit einem oder mehreren Händlern, wann und wie lange er deren Dienst in Anspruch nehmen will. Möchte ein neuer Händler auf dem Basar seinen Stand eröffnen, so meldet er sich bei der Marktaufsicht und läßt sich einen freien Stand zuweisen. Sobald der Stand eingerichtet ist, wird die Karte des Händlers an die Pinwand geheftet. Händler können auch als Kunden auftreten oder sich verbünden, so daß sie selbst fremde Dienste nutzen oder komplexere Dienste anbieten können.

Dr. Ulrich Kriegel ist Projektleiter im Fraunhofer-Institut für Software- und Systemtechnik (ISST), Berlin, und beschäftigt sich mit Software-Architekturen und -technik.