Trennung von Front- und Backend in zwei EARs

jounnie

Grünschnabel
Guten Tag Zusammen!

Ich stehe gerade vor ein Problem: Ich muss FE von BE in 2 packages trennen (2 EARs). Das Backend sollte unabhängig von Frontend laufen (Ein Fronend ohne Backend läuft natürlich nicht. Ausser mit Mockups für Testing-Zwecke o.ä.)

Wie realisiere ich am besten die Kommunikation wenn ich EJB 3.0 (2.1 würde gehen, ist mir aber zu aufwändig) und Webservices aus architektorischen Gründen nicht anwenden kann?

Nun meine Lösungsansatz:

Kommunikation über RMI mit hilfe von Spring wie in der Spring-Doku beschrieben für jeder Service mit gemeinsame Interfaces und Entities.

Nun habe ich folgende maven projekte:

- FrontendWeb (war/web-projekt, Abhängigkeit: CommonJAR)
- FrontendEAR (ear-projekt, Abhängigkeit: FrontendWeb)

- BackendJAR (jar?!-projekt, Abhängigkeit: CommonJAR)
- BackendEAR (ear-projekt. Abhängigkeit: BackendJAR)

und natürlich:

- CommonJAR (beinhaltet entities und interfaces)

Das ganze ist im Moment rein theoretisch. Kennt sich jemand schon aus mit solchen Trennungen? Was haltet ihr von meiner Idee? Gibt es Komplikationen? und wie initialisiere ich Spring auf der Backend-Seite? Hatte bisher nur Erfahrungen mit einer BE/FE-Mischung und Spring wurde vom Struts aus als Plugin initialisiert.

Ein Danke im Vorraus ^^
Jonny
 

Nun habe ich folgende maven projekte:

- FrontendWeb (war/web-projekt, Abhängigkeit: CommonJAR)
- FrontendEAR (ear-projekt, Abhängigkeit: FrontendWeb)

- BackendJAR (jar?!-projekt, Abhängigkeit: CommonJAR)
- BackendEAR (ear-projekt. Abhängigkeit: BackendJAR)



Hallo,

erstmal wird mir iwie der Sinn noch nicht so klar. Warum 2 Ears?.. Nach Java EE Standards oder Konventionen, kommt das Frontend immer in eine .war und das Backend in ein EAR File. Wenn du das nachher deployst auf dein AppServer..dann hauste das .war ind den Webcontainer und das ear File in den EJB-Container und fertig..eine saubere Trennung von Frontend und Backend.
 
ich muss mich meinem Vorposter anschließen.

ein EAR beinhaltet das Frontend (WAR) und das Backend(EJB-JAR). Ich habe das aus anderen Gründen mal voneinander getrennt (Änderung in den Webressourcen ohne Service / Backendredeploy).

Deine Anwendungs-EJBs registrieren sich in irgend einem ENC, ohne Angabe findest Du alle beans im global JNDI. Diese kannst Du auch in einer nicht-mitdeployten Webanwendung ganz regulär adressieren, wenn Du in der web.xml und dem Deploymentdeskriptor Deines Server richtig die Beans definierst.

Was ich nicht ganz verstehe, ist es, EJB3 zu verbieten, aber Spring zu erlauben, denn zumindestens ist das IOC-Geraffel ziemlich ähnlich.

Bei einer Datenbankanwendung würde ich eher EJB nehmen, da Dir der Container einen Transaktionsmanager bereitstellt, den Du bei Spring erstmal reinfrickeln musst und meine Programmiererfahrung mir bisher das Gefühl vermitteln, dass das ganze Persistenzschichtzeugs in Spring viel unrunder läuft, als bei den Enterprisecontainern.

Welchen Appserver nutzt Du?
 
Hallo,

ja genau die Sache mit Spring habe ich auch net verstanden..also ich kann verstehen, dass man EJB 3 EJB 2.1. vorziehen sollte, aber das andere ist mir ein Rätsel. Hier in der Fiorma in der ich arbeite standen wir mal genau vor dem gleichen Problem. Spring bietet von haus aus keinen Transaktionsmanger an. Ist halt doof, wenn man eine TX-Klammer spannen möchte von da aus. Ich habe mich mit EJB 3.0 noch nicht so intensiv befasst..aber ich ahbe des öfteren gehört, dass Spring weiterhin etwas flexibeler und schlanker ist. Im Datenbankbereich habe ich bei Spring allerdings noch keine Schwächen festgestellt, ich persönlich finde es mit hibernate sogar 3mal einfacher und nachvollziehbarer. Aber Geschmackssache.

ich hoffe dir ist erstmal geholfen
 
btw, hibernate ist die EJB3 Persistence Referenzimplementierung und die Hibernate Annotations == EJB JPA

Das ist kein Unterschied. Das Zeug ist in EJB 3 nur deutlich sauber eingebettet.

Grüße
 
Danke für eure Tipps :)

Mir ist das schon klar, mit dem WARs, EJB & EJB-Clients aber wir benutzen Websphere 6.1 (J2EE 1.4). Ein Upgrade auf J2EE 1.5/5 wäre mit ein Feature Pack möglich, wird bei uns aber nicht freigegeben. Auf klar Deutsch: Keine EJB 3.0 möglich. Nur EJB 2.1. Erfreulicherweise ist Spring erlaubt :D

Darum komme ich auf Lösung mit RMI+Spring (Kommunikation zwischen FE & BE). Habe schon der erste Prototyp implementiert und funktioniert! Jetzt ist nur noch eine kleine Frage offen: Wie initialisiere ich der SpringContext auf BE seite? In einen Statischen Context? (static{}) oder in einen Servlet? Ich habe ja keine EJBs die in der Startzeit des BE gestartet werden.

Grüsse
Jounnie
 
das ist genau das problem

du kannst dir damit helfen, ein SLSB zu bauen, dass jeweils immer einen springcontext initialisiert und für den verlauf der sitzung vorhält.

du hast dann allerdings anzahl sitzungen tx-kontexte.
 
Zurück