Die verteilte Datenverarbeitung hat sich im großen Stil durch die Einführung von Client-Server-Architekturen verbreitet. Durch das Auseinanderreißen von Anwendungen in Client- und in Server-Teile entstand jedoch auch die Notwendigkeit, sie wieder zusammenzuflicken. Dazu müssen Service-Aufrufe einer Client-Komponente als Nachrichten über das Netz gesendet werden. Diese Aufgabe übernehmen Remote-Procedure-Call-(RPC-)Produkte wie der DCE-RPC oder der Microsoft-RPC, die Java Remote Methode Invocation (RMI) oder spezielle Object Request Broker (ORBs).

Dass diese Verfahren funktionieren, hat sich mittlerweile gezeigt - jedoch nur innerhalb eines dedizierten Netzes und bei einer homogenen IT-Landschaft - doch welches Unternehmen hat das schon. So kann beispielsweise eine Client-Anwendung, die in Java geschrieben ist, nicht ohne weiteres den Service einer als Component-Object-Model(COM-) Programm implementierten Visual-Basic-Anwendung aufrufen. Es gibt zwar Produkte, die dieses Manko beseitigen sollen - etwa Bridges zwischen den Methoden von COM und der Component Object Request Broker Architecture (Corba). Diese Hilfsmittel liefern jedoch keine Basis für eine generelle Lösung.

Da die gängigen Middleware-Ansätze also eine homogene Softwarelandschaft voraussetzen, waren Unternehmen bisher gezwungen, IT-Architekturen langfristig festzulegen und sich an einen oder wenige Hersteller zu binden: Man musste sich zwischen Client-Server-Architekturen auf Basis von Microsofts Technologie, Java oder Corba entscheiden. Für E-Business-Lösungen ist eine solche Festlegung gar nicht möglich, da sich ein externer Partner nicht das Verfahren vorschreiben lässt, mit dem seine

Kaum Vorschriften

IT-Systeme kommunizieren sollen. Lediglich die Internet-Technik und ihre standardisierten Protokolle (HTTP, HTML, XML etc.) können heute als selbstverständlich vorausgesetzt werden.