Ich werde nur eine Antwort geben, und zwar aus eigener Erfahrung - sehen Sie sich das an middle-ware Entera, mit dem ich Erfahrung habe, schafft eine mittlere Schicht, in der die Unix-Box, die in C geschriebene Prozesse verwendet, mit dem Mainframe-System (DB2, COBOL) über ein in PowerBuilder geschriebenes Front-End interagiert (ich nenne den Namen der Firma nicht!).
Aus der Beschreibung, die ich gegeben habe, geht hervor, dass Entera eine Middleware ist, die eine Reihe von Dingen beherbergt - reibungslose Integration des Datenflusses unabhängig vom Endian-Format, die Möglichkeit für verschiedene Sprachen, mit dem Middleware-Broker zu sprechen (ein Broker ist ein CORBA o DCE Prozess, der mit 'The Open Group' konform ist und auf einem bestimmten Port lauscht) und wird durch eine IDL was einen Prozess als lokal erscheinen lässt - wenn Sie die in Remoting unter Microsofts .NET Framework verwendete Terminologie verstehen, liegen Sie nicht weit daneben! Die Middleware generiert Stubs, die zur Kompilierungszeit verlinkt werden und verwaltet die Erstellung des Prozesses, das Hosting an einem Port, Multi-Threading zur Laufzeit und auch die modernen Front-Ends (wie .NET, Java, PowerBuilder und sogar das unaussprechliche VB6...ok...VB.NET für die Puristen da draußen) können interagieren, indem sie eine Verbindung zum angegebenen Port an einer bestimmten IP-Adresse öffnen und mit Hilfe der generierten Stubs direkt mit ihm interagieren.
Aus dem Beschriebenen wird ersichtlich, wie den Altsystemen neues Leben eingehaucht werden kann und somit die Skalierbarkeit des Prozesses verbessert werden kann, wobei der größte Nachteil der Kostenfaktor ist, der sich auf mehrere tausend Dollar belaufen kann. Große Unternehmen, die Mainframes als Backend-Verarbeitungssysteme für die Fakturierung verwenden und enorme Umsätze erzielen, können sich offensichtlich ein solch teures Produkt leisten - für sie wäre es so, als würde man Pfennige in ein Wasserbecken werfen... Durch den Einsatz von Middleware, die den Geschäftsprozess verlängert und ihm neues Leben einhaucht, kann das Unternehmen eine ganze Reihe von Jahren in die Zukunft blicken, ohne sich um das Etikett "Legacy" zu sorgen.
Ich habe dies übrigens im Rahmen meiner BSc.-Abschlussarbeit in Wirtschaftsinformatik durchgeführt, die sich mit diesem kommerziellen Frontend befasste. Es gab eine Open-Source-Version der Middleware, die auf Sourceforge verfügbar war. FreeDCE aber die Entwicklungsanstrengungen sind zurückgegangen oder wurden eingestellt.
Edita: @cocotwo: Das ist genau das, was Middleware tut, wie Sie sagten, es ist ein Klempner-Tool ... Nachricht orientierte Middleware ist nicht wirklich von AFAIK gehört, weil ich mir vorstellen würde, die Prozesse (Funktionen) müssten aufgerufen werden, als ob sie lokal sichtbar innerhalb der Anwendungsdomäne des Front-Ends, um es einfach zu interagieren mit zu machen.
Die Verwendung von Nachrichten kann gegenüber RPC-Aufrufen den Vorteil haben, dass die Nachrichten in einer Warteschlange in einem sicheren Bereich aufbewahrt werden, falls eine Netzwerkunterbrechung auftritt - in diesem Aspekt kann ein gewisses Daten-Caching stattfinden, damit das Front-End unabhängig davon fortfahren kann... dies wäre in den Fällen nützlich, in denen der Status einer bestimmten Rechnungs-/Nachweisnummer aktualisiert werden soll - ein einseitiges Schreiben von Daten an das Back-End über die Middleware.
Okay, große Unternehmen verfügen über eine fortschrittliche Systeminfrastruktur, bei der Techniker rund um die Uhr im Einsatz sind, um einen reibungslosen Datenfluss zu gewährleisten, was ebenfalls berücksichtigt werden muss. Das Unternehmen, mit dem ich gearbeitet habe, hatte einen IBM Global Support-Vertrag zu erfüllen, um eine maximale Betriebszeit von 99 % mit sechs Neunen hinter dem Komma zu gewährleisten... mit Hot-Swapping/ausgewogenen Clustern/Spiegelungssystemen vor Ort...
Bei RPC hingegen müsste das Front-End neu gestartet werden, wenn die Verbindung unterbrochen wird, oder das Ereignis der Verbindungsunterbrechung behandeln. Es hängt wirklich davon ab, ob die Middleware, die die Nachrichten in die Warteschlange stellt, jede Nachricht in Echtzeit verarbeitet und die Ergebnisse sofort an das Front-End zurückgibt...
Hier haben beide (Message-Queueing und RPC-bezogene Middleware) ihre Stärken und Schwächen... und auch der Faktor der Kostenreduzierung wie Support, maximale Betriebszeit, Entwicklungsaufwand und Training - das ist hier ein großes Problem, da Middleware wirklich proprietär ist (obwohl sie dem Layout/Standard von 'The Open Group' folgt) und komplex einzurichten und das Ganze über Skripte zusammenzukleben ist.
