Wir müssen viele Java-Web-basierte Anwendungen (für das gleiche Unternehmen) unterschiedlicher Größen, Bereiche und Lebensdauer entwickeln und warten. Einige von ihnen sind riesig und andere sind nur einfache Seiten, die nur wenige Monate (oder Tage) leben können, einige sind bereits implementiert und müssen refactoring werden.So teilen Sie Geschäftslogik zwischen mehreren Anwendungen
Eines haben sie jedoch gemeinsam: Sie benötigen Zugang zu (fast) den gleichen Informationen.
Problem
Aufgrund der Komplexität der Daten das Unternehmen übernimmt, müssen wir mit vielen verschiedenen Quellen behandeln, von denen einige von den alten Zeiten geerbt. Unsere Domänenobjekte können über viele dieser Quellen hinweg zugeordnet werden. Beispielsweise wird ein Vertragsdomänenobjekt unserer Hauptdatenbank zugeordnet, aber die zugehörigen (physischen) Dateien werden auf einem Dokumentenserver gespeichert, und die zugehörige Aktivität wird in einer NoSQL-Datenbank gespeichert. Das Hinzufügen, Entfernen oder Durchsuchen eines dieser Objekte erfordert daher viele interne Vorgänge.
Unsere Datenquellen sind (obwohl es jeder sein könnte):
- AS400 (unter Verwendung von DB2 als Datenbank)
- Documentum Document Manager
- Mongo DB
- Externe Web-Services
- Andere Legacy-Quellen
Wir verwenden normalerweise Glas sfish als Anwendungsserver und Maven als unser Build-Tool.
Tor
Unser Ziel ist es, eine Business-Schicht oder eine Bibliothek, die alle unsere Anwendungen zugreifen können zu erstellen, und es ist:
- Compact
- Consistant
- Leicht verwenden
- Pflegeleicht
- Erreichbar vom Menschen y verschiedene Kunden
Was wir bisher
Wir Wochen und noch können wir nichts völlig zufriedenstellend gefunden haben gekämpft haben, finden. Einige Lösungen:
-Pack alle Business-Logik in einem oder mehreren Gläsern: Sehr einfach zu teilen, aber allen Anwendungen müssen alle jar Abhängigkeiten und Konfigurationsdateien enthalten und sorgen für Sicherheit, Caching und andere Sachen. Schwierig zu warten (wir müssen die Jars für jedes Projekt aktualisieren, wenn Änderungen vorgenommen werden).
Erstellen Sie ein Ejb-Projekt, das die gesamte Logik enthält, und greifen Sie darauf remote zu: Einfache Wartung, Sicherheit, Caching und Konfiguration werden nur einmal implementiert. Wir haben Angst vor der Strafe der Remote-Anrufe. Wie wir in unseren Untersuchungen festgestellt haben, scheint es eine schlechte Übung zu sein (wir haben nicht viel Erfahrung mit ejbs).
Erstellen Sie ein Ear-Projekt mit allem drinnen und verwenden Sie lokalen Zugriff: Nun, das ist schneller als die Remote-Version, aber es ist eine Hölle zu pflegen.
Gehen Sie für OSGI: Wir haben ein bisschen Angst vor diesem, da es nicht so populär wie Ejb ist und wir es nie ernsthaft benutzt haben.
Gibt es eine übliche Praxis für diese Art von Problem?
Vielen Dank!
Seit einiger Zeit habe ich einige EJB. Können Sie erklären, warum Sie eine separate BL benötigen? Verwenden Sie für die Datenseite DAO-Muster? Wäre es möglich, durch diese auf mehrere Quellen zu mappen? Es sollte möglich sein, mehrere Datenquellen zu verwalten. –
Danke für die superschnelle Antwort! Das ist eigentlich die Hauptidee. Wir wollen DAOs verwenden, um all die schmutzigen Sachen einzukapseln. Das Problem besteht darin, wie Sie von den Client-Anwendungen auf diese DAOs zugreifen können. – danielsan
Ich würde einen osgi-Ansatz empfehlen, wenn Sie eine komplett neue App erstellen. Aber ich würde es nicht empfehlen, wenn Sie planen, viele Sachen zu portieren und wenn das Team neu für osgi ist. – techuser