Jak dzielić się logiką biznesową pomiędzy wieloma aplikacjami?

Question

Musimy rozwijać i utrzymywać wiele aplikacji internetowych Java (dla tej samej firmy) o różnych rozmiarach, zakresach i długości życia. Niektóre z nich są ogromne, a inne to tylko proste strony, które mogą żyć tylko kilka miesięcy (lub dni), niektóre są już wdrożone i wymagają refaktoryzacji.

Istnieje jednak jedna wspólna cecha, że ​​potrzebują dostępu do (prawie) tych samych informacji.

Problem

Ze względu na złożoność danych zajmuje się firma, mamy do czynienia z wielu różnych źródeł, niektóre z nich odziedziczyła od czasów starożytnych. Nasze obiekty domeny mogą być mapowane na wiele z tych źródeł. Przykładowo obiekt domeny Kontraktu jest mapowany do naszej głównej bazy danych, ale powiązane z nim (fizyczne) pliki są przechowywane na serwerze dokumentów, a związana z nim aktywność jest przechowywana w bazie danych NoSQL. Dlatego dodawanie, usuwanie, wyszukiwanie dowolnego z tych obiektów wiąże się z wieloma operacjami wewnętrznymi.

Nasze źródła danych są (choć może to być dowolna):

• AS400 (przy użyciu DB2 jako baza danych)
• Documentum menedżer dokument
• Mongo DB
• zewnętrzne serwisy internetowe
• Inne dotychczasowe źródła:

Zwykle używamy Glas sfish jako serwer aplikacji i maven jako narzędzie do budowania.

bramki

Naszym celem jest stworzenie warstwy biznesowej lub bibliotekę, że wszystkie nasze aplikacje mogą uzyskać dostęp i jest:

• Compact
• Consistant
• Łatwy w użyciu
• Łatwy w utrzymaniu
• Dostępne od człowieka y różnych klientów

Co odkryliśmy dotychczas

Mamy zmaga się przez kilka tygodni i nadal nie możemy znaleźć niczego w pełni zadowalające. Niektóre rozwiązania:

• Pakiet cała logika biznesowa w jednym lub kilku słoików: Bardzo łatwo udostępniać, ale wszystkie aplikacje będą musiały zawierać wszystkie zależności jar i pliki konfiguracyjne i dbać o bezpieczeństwo, buforowanie i inne rzeczy. Trudne do utrzymania (musimy zaktualizować słoiki dla każdego projektu, gdy są zmiany).

• Utwórz projekt Ejb zawierający całą logikę i uzyskaj do niego dostęp zdalny: Łatwe w utrzymaniu, bezpieczeństwa, buforowanie i konfiguracja tylko raz. Obawiamy się kary za połączenia zdalne. Jak zauważyliśmy w naszych badaniach, wygląda to na złą praktykę (nie mamy dużego doświadczenia z ejbami).

• Utwórz projekt uszu ze wszystkim w środku i korzystaj z dostępu lokalnego: Cóż, jest to szybsza wersja niż wersja zdalna, ale jest to piekło do utrzymania.

• Przejdź do OSGI: Trochę się tego boimy, ponieważ nie jest tak popularny jak Ejb i nigdy nie użyliśmy go poważnie.

Czy istnieje powszechna praktyka w tego rodzaju problemach?

Wielkie dzięki!

Answer 1

Nie polecam umieszczania całej logiki w 1 projekcie EAR i korzystaniu z dostępu lokalnego. Jeśli masz dużo kodu w jednym miejscu, będzie trudniej go przetestować, przetestować, wdrożyć itp.

Chciałbym stworzyć projekt masztu z modułami mutlti ze wspólnymi zależnościami. Jedna z zależności - usługa z logiką biznesową i dostępem DAO, która ujawni interfejs API. Dzięki projektowi Maven możesz łatwo kontrolować wersję plików POM. Różne projekty mogą działać z inną wersją wspólnej usługi. Maven zaopiekuje się kontrolą wersji. Wymaga to jednak pewnych wysiłków związanych z konfiguracją i wdrożeniem.

Inna opcja, o której wspomniałem - samodzielny plik EAR ze zdalnymi EJB, również powinna działać dobrze. Nie przejmuj się wydajnością i liczbą połączeń zdalnych, chyba że masz duże obciążenie. Po prostu buforuj zdalne moduły EJB na kliencie, aby uniknąć niepotrzebnego wyszukiwania JNDI.

Osobiście wolę pierwszą opcję ze współdzieloną zależnością zarządzaną przez Mavena. Jest przejrzysta i łatwa w utrzymaniu, łatwa w zarządzaniu wersjami, wdrażaniu, konfigurowaniu. W Maven nie musisz ręcznie zmieniać pliku JAR dla każdego projektu, możesz po prostu użyć narzędzi takich jak Nexus