Ich würde einen Cache zum Schluss installieren, der die aktuellsten Daten gespeichert hat: unser hält 50MB-Daten. Wenn die 50MB voll sind, werden die Datensätze, die am längsten ungenutzt rumliegen, verworfen (LRU: Least Recently Used)
Persönlich würde ich einen Cache nicht als Bestandteil einer Mittelschicht definieren. Die Mittelschicht bündelt Anfragen und bildet die 'Geschäftslogik' ab (Schulwissen).
Um auf das Problem der verteilten System zu kommen, fehlt mir das Fachwissen: Denn es gibt mit Sicherheit fertige Systeme (CORBA, ORB etc.).
Ich bastel gerade an einer Studie für so ein System. Die Eckpunkte sind
1. Einzelne miteinander kommunizierende Module (
DLL) können jederzeit ausgetauscht werden, ohne das System herunter zu fahren. Die Module sind auch per Remote austauschbar
2. Der Aufruf der einzelnen Methoden/Prozeduren erfolgt nach einer einheitlichen Schnittstelle:
Code:
CALL Module.Function InParam OutParam ResultParam
Die Parameter sind dabei
XML/JSON oder was Du willst.
3. Einem Modul, das ein anderes Modul aufruft, ist es egal, wo konkret dieses Modul installiert ist. Alle Appserver tauschen ständig ihre installierten Module aus, Konflikte (also Mehrfachinstallationen eines Moduls) werden schnell erkannt und angezeigt. Der Appserver leitet einen CALL ggf. an die richtige Stelle weiter und transportiert das Ergebnis auch gleich weiter zum Aufrufer.
Eigentlich besteht das ganze System 'nur' aus einer sehr robusten
DLL-Verwaltung mit
TCP Anbindung, denn alle Module sind ihrerseits
DLL. So lässt sich das gesamte System jederzeit upgraden, austauschen und verbessern.
Vielleicht wäre diese Architektur ein guter Ansatzpunkt für Euch.