Pojedyncze EAR? Lub wiele EAR?

Question

Jesteśmy w trakcie opracowywania aplikacji opartej na JavaEE 6 do wdrożenia w JBoss EAP 6.1. Ta aplikacja ma 2 podstawowe mechanizmy prezentacji: konsolę administratora WWW i interfejs API usługi RESTful. W zapleczu zarówno konsola administracyjna, jak i interfejs API usługi RESTful opierają się na serii EJB do wykonywania logiki transakcyjnej i usług POJO do pobierania danych.

Jest całkowicie możliwe, że wydajność i potrzeby zasobów dla wszystkich tych różnych warstw mogą być różne. Usługi RESTful są raczej cienkie i całkowicie bezpaństwowe, podczas gdy konsola administracyjna jest stanowa i ma bardziej interaktywną funkcjonalność (a zatem wymaga więcej pamięci i przetwarzania). Ponieważ nasze komponenty EJB wykonują naszą główną transakcyjną logikę biznesową, wymagają większej mocy obliczeniowej niż nasze usługi danych POJO, które po prostu wysyłają zapytanie do bazy danych.

Biorąc pod uwagę taką konfigurację, czy bardziej sensownym rozwiązaniem byłoby wdrożenie pojedynczego pliku EAR (w wielu aplikacjach w konfiguracji klastrowej) ze wszystkimi tymi komponentami, czy też rozbicie poszczególnych składników na osobne pliki EAR? Mój sposób myślenia z oddzielnymi plikami EAR polega na tym, że mogę na przykład wdrożyć więcej instancji usług EJB, jeśli stwierdzę, że są z nimi problemy skalowalności, nawet jeśli konsola internetowa (na przykład) skaluje się dobrze.

Biorąc pod uwagę, że skalowalność każdej warstwy/komponentu jest różna, jakie podejście należy zastosować? Czy obciążenie związane z koniecznością wykonywania zdalnych wywołań EJB przez EAR jest zbyt wysokie, aby uwzględnić taki model? Każda rada jest WSPANIAŁA doceniona!

Answer 1

Sposób "Java EE" polegałby na wdrożeniu aplikacji jako pojedynczego pliku EAR w klastrze. Zakładam, że używasz lokalnych wywołań interfejsu z REST/konsoli administracyjnej do EJB-ów. Wdrożenie byłoby proste, jeśli nie potrzebujesz replikacji sesji (możesz używać sesji lepkich), wtedy skalowalność będzie bardzo dobra.

Jedyny dodatkowy element, który będzie potrzebny, to równoważenie obciążenia dla aplikacji internetowych (na przykład serwer Apache, który również będzie dbał o dekodowanie SSL, przesyłanie statycznych zasobów i, ewentualnie, buforowanie żądań, które mogą być buforowane).

Jedyny problem z taką konfiguracją może powstać w przypadku dużych obciążeń, na przykład EJB mogą jeść dużo zasobów serwera, więc przepustowość aplikacji internetowych będzie trudna do kontrolowania i może być poważnie zakłócona przez komponenty EJB. Jeśli używasz lepkich sesji, zawsze użytkownik jest przekierowywany na ten sam serwer, więc nie ma szansy na przeniesienie niektórych użytkowników do mniej obciążonego serwera, dopóki trwa sesja użytkownika.

Tak więc, jeśli planujesz duże obciążenia, sensowne byłoby utrzymywanie aplikacji internetowych i EJB na oddzielnych skrzynkach (lub maszynach wirtualnych), aby łatwiej było identyfikować wąskie gardła i łatwiej skalować tę warstwę, która tego wymaga.

Kara za to będzie:

1. zdalnego wywołania EJB. Jednak JBoss 6 ma dość zaawansowaną konfigurację pulami EJB, więc może to nie być taki straszny problem.
2. ruch sieciowy spowodowany przez te połączenia zdalne (więc jeśli przechodzisz między EJB i warstwą internetową dużo danych, może to być problem).

Answer 2

Na poparcie wielkich komentarzach Piotra:

Bundle je teraz razem i podzielić tylko czy rzeczywista potrzeba pojawia się w przyszłości.

Zastanów się, czy Martin Fowler's First Law of Distributed Object Design: Don’t distribute your objects! jest dobrym wytycznym - jeśli zamierzasz go złamać, przynajmniej rób to świadomie i na prawdziwe potrzeby biznesowe.