EJB3 Enterprise Application Jak Portal & Client Web Apps - Architektura/Design

Question

Jak pokazano w powyższym pic, Mam aplikacji EJB3 Enterprise (plik EAR), który działa jako portal i posiada 3 Web aplikacje (pliki WAR), które komunikują się z tym samym datastore. Te 3 aplikacje internetowe nie są implementacjami portletów, ale zwykłymi aplikacjami sieci Web, które współdziałają z magazynem danych za pośrednictwem warstwy trwałości aplikacji korporacyjnej. Te webappy są rozwijane niezależnie, więc niektóre z nich używają Webservices z aplikacji Enterprise, a niektóre z nich używają EJB-Clients.

Ponadto, istnieje inna możliwość zastąpienia tych webapps (WEB app1, Web APP2 i Web App3) i za pomocą niezależnych Apps Przedsiębiorstwo komunikacji i transakcji z bazy danych, jak pokazano poniżej:

Teraz moje pytania są następujące:

1) Jaki jest najlepszy wariant spośród wymienionych 2 opcji (powyżej)?

2) W jaki sposób wpływa ona na zastąpienie tych aplikacji internetowych działających jako klienci w aplikacji Enterprise jako niezależne aplikacje korporacyjne (pliki EAR)?

3) Jaki jest lepszy model obsługi transakcji, funkcji SSO, skalowalności i innych czynników?

4) Czy są jakieś inne lepsze modele?

EDIT:

1) W pierwszym modelu, która metoda jest preferowanym sposobem interakcji z pliku EAR - usługi sieciowe lub EJB-client plik jar/Library (interfejsy i klasy użytkowe)?

2) W jaki sposób oba modele różnią się pod względem wykorzystania pamięci (RAM serwera) i wydajności. Czy jest jakaś znacząca różnica?

Answer 1

Ponieważ jesteś tak abstrakcyjny, zrobię to również. Jeśli usuniemy wszystkie bzyczące słowa jako "Portal", "Aplikacje korporacyjne" i tak dalej ... Na końcu mamy trzy aplikacje internetowe i wspólną bibliotekę lub framework (aplikację dla przedsiębiorstw).

Wyświetlanie aplikacji tak proste, jak to możliwe. Masz trzech programistów, którzy potrzebują rozwijać trzy aplikacje internetowe. Zapewnisz pewien wspólny kod przydatny do budowania swoich aplikacji. Model, z którego będziesz korzystać, będzie zależeć od tego, jaki kod Ci podasz.

1.- Zapewnisz tylko kilka utils i wspólny kod biznesowy. Może być klasyczna biblioteka pasująca do twoich potrzeb. (W środowiskach Java EE należy wziąć pod uwagę, w jaki sposób można wykorzystać zalety utrzymywania pamięci podręcznej poziomu 2 współdzielonej z fabryką sesji dla pojedynczego magazynu danych)

2.- Zapewnisz usługi współużytkowane jako trwałość, pamięć podręczną, bezpieczeństwo, audyt , i tak dalej ... Będziesz potrzebował warstwy usługi jako pierwszej opcji. Będziesz mieć wspólny stan, więc potrzebujesz tylko jednej instancji.

3.- Najczęstszym przypadkiem jest dostarczenie niektórych biznesowych interfejsów API i warstwy usług do typowych usług.

Nie wskazano żadnego wymogu, który zmusiłby użytkownika do zastosowania bardziej złożonego rozwiązania w danym scenariuszu.

EDIT:

o tym, czy jest ona preferowana RMI (EJB-klient) lub sieciowe. Zawsze używam rmi do komunikowania aplikacji geograficznie blisko. Korzystanie z niego jest proste, a protokół jest o wiele szybszy niż serwisy internetowe (możesz przeczytać wiele porównań dotyczących tego tematu, szukając wydajności usług rmi w google).
Z drugiej strony rmi jest bardziej sensowne dla sieciowej latencji, wymaga specjalnych konfiguracji firewalla i jest bardziej sprzężone z tymi usługami sieciowymi. Więc jeśli udaję się oferować usługi stronom trzecim lub łączę geograficznie rzadkie serwery, wolę usługi sieciowe, a nawet REST.

Na temat ostatniego pytania początkowo nie ma żadnej różnicy w kwestii wdrażania jednej lub dziesięciu aplikacji na tym samym serwerze. Opłata za wdrożenie będzie nieznaczna w stosunku do ogólnych kosztów związanych z korzystaniem z aplikacji. Oczywiście, musisz przyjąć to jako ogólne założenie. Oczywiście rozmiar i sposób wdrażania aplikacji będą miały wpływ na zużycie pamięci i inne.

Należy wziąć pod uwagę, że decyzje te można łatwo zmienić w zależności od potrzeb. Tak więc, jak już powiedziałem, możesz zacząć od prostego rozwiązania i jeśli napotkasz problem podczas wdrażania aplikacji, możesz łatwo zmienić strukturę uszu.

Answer 2

Jestem skłonny zgodzić się z Fedox. Jeśli nie ma powodu, aby wybierać jedno rozwiązanie z drugiego (uzasadnienie biznesowe, powód techniczny itp.), Możesz równie dobrze wybrać ścieżkę najmniejszego oporu. Według mnie byłoby to pierwsze rozwiązanie.

Ogólnie rzecz biorąc, rozpocznij od prostoty i zwiększ złożoność. Twoje rozwiązania nie mają żadnego znaczenia bez kontekstu. Aplikacja bankowa wymaga bloga na różne sposoby.

Nadzieja to pomaga

Answer 3

Jest to nowa platforma o nazwie Vitria's BusinessWare, jest to bardzo udany projekt, który jest wart miliony.
Teraz zobaczmy, jak to działa i co robi, abyśmy mogli zrobić to samo w teorii:
Łączy projekty z ich bazami danych, serwisami internetowymi z ich EJBs..etc. Z ich koncepcji możemy dowiedzieć się, co następuje:

1. Tworzenie głównego EJB bezstanowej fasoli (API), którego zadaniem jest przekazywanie wiadomości z:

   • usług internetowych do innych WEB- usługi
   • usługi internetowe dla webappów
   • webappy do innych serwisów internetowych

2. Celem tego EJB jest najpierw sprawdzenie w głównej bazie danych , a następnie przekazanie wywołań do innych modułów.

3. Tylko ta EJB ma dostęp do DB do bardziej bezpiecznych połączeń
4. Ten EJB będzie kolejki komunikatów aż modułów wysyłane są wolne przyjąć
5. Ten EJB będzie kontrolować wszystkie procesy w DB
6. To będzie określało, gdzie wysłać wiadomości: