Verschiedene Applikationen mit der selben Datenbasis

[wachtda]

Hallo Zusammen

Ich habe eine EJB3-Applikation entwickelt (JSF, Seam, Hibernate auf JBoss AS) welche Sozusagen das Backend eines Systems darstellt.
In einem weiteren Schritt möchte ich nun das Frontend dieses Systems realisieren.

Da ich noch nicht wirklich Erfahrung mit grösseren J2EE Systemen habe , weiss ich nicht genau wie ich das angehen soll.
Eigentlich möchte ich, das Backend sowie das Frontend als zwei verschiedene Applikationen auf dem Server deployen. (Wovon ich mir eine bessere Wartbarkeit verspreche...)

Nun habe ich eigentlich zwei verschiedene Applikationen, welche aber mit der gleichen Datenbasis (DB und Entity-Beans) arbeiten. Welche möglichkeiten habe ich diese Trennung durchzuführen.
Welche Vorgehen haben sich bewährt?

Evtl. hat mir jemand eine gute Quelle (Link, Buch) für weitere Informationen?
:###

Danke und Gruss
Daniel

 

[Gast]

Verstehe die Frage nicht, JSF ist doch schon dein Frontend.

 

[wachtda]

Da habe ich wohl eine kleine Begriffs-Verwirrung verursacht:

Backend -> Applikation, für das Backoffice (Service Mitarbeiter)
Frontend -> Applikation, für das breite Publikum (Endkunden)

Eigentlich bilden die zwei erwähnten Applikationen ein Software-System, mit der selben Datenbasis
und Entity-Klassen.

Meine Frage ist nun, welche möglichkeiten habe ich mein Software-System in zwei Applikationen zu unterteilen.
Gibt es die Möglichkeit z.B. die Entity-Klassen ausserhalb der Applikationen zu deployen?

Danke für die Hilfe

 

[FArt]

Was machst du mit Funkitionalität, die sowohl von Service-Mitarbeitern als auch von Endkunden benötigt wird?

Tipp. keine gute Idee.

Verwende eine gemeinsame Logikschicht und führe Berechtigungen ein.

Die Präsentationsschicht kannst du dann trennen.

 

[wachtda]

Hallo FArt

Danke für Deine Antwort...
Ich würde die beiden Applikationen lieber trennen, damit ich z.B. bei einer Änderung am Backend nicht auch das Frontend neu deployen muss!

Klar, ich müsste die Logik für z.B. das Frontend neu machen.
(Wobei sich die Funktionalitäten so stark unterscheiden, dass es wohl nur sehr wenig redundanz geben würde)

Oder meinst Du, dass mein Ansatz überhaupt nicht üblich ist?
Welche Möglichkeiten gäbe es sonst noch, um die beiden Applikationen zu trennen?

 

[karatekid]

Hi wachtda,

FArt hat es schon korrekt beschrieben. Wenn beide Applikationen auf die gleiche Persistenz zugreifen, baue eine Middleware/Persistenzschicht und trenne die Frontendschicht in deine beiden Anwendungen auf.

Ich würde an deiner Stelle auch die Begriffe abändern. "Backend" und "Frontend" als Bezeichnung für Applikationen ist eher ungünstig.

 

[ps]

So wie du das vorhast gibt es sehr viel Ärger. Wenn du zweimal Entities deployst welche auf die selbe Datenbank zugreifen hast du ein Caching Problem (Entity Manager 1 weiß nichts von Entity Manager 2 und geht im zweifelsfall immer davon aus das sich in der DB nichts geändert hat wenn er es nicht war ;-) )

Davon abgesehen das dies allem widersprechen würde was ich von Software Architektur verstehe ^^

Deine Anwendung würde ich so aufbauen:

-- application-ejb.jar (<--- hier sind deine Session Beans, Entity Beans, etc enthalten. Der ganz EJB Kram und die Persistenz)
-- public.war (<--- hier kannst du dein öffentliches frontend reinpacken)
-- intranet.war (<--- hier packst du die intranet app rein - aber wahrscheinlich hat die ja sowieso einen anderen server?!)

je nachdem ob es noch viel spezielle logik gibt welche nur public oder intranet betreffen, kannst du auch noch public-ejb.jar und intranet-ejb.jar einführen... Anzumerken ist das in den WARs Entities und Session Beans nichts zu suchen haben. AFAIK kann man sie dort auch nicht wirklich deployen... das geht dann erst mit EJB3.1

 

[wachtda]

So wie du das vorhast gibt es sehr viel Ärger. Wenn du zweimal Entities deployst welche auf die selbe Datenbank zugreifen hast du ein Caching Problem (Entity Manager 1 weiß nichts von Entity Manager 2 und geht im zweifelsfall immer davon aus das sich in der DB nichts geändert hat wenn er es nicht war icon_wink.gif )

Davon abgesehen das dies allem widersprechen würde was ich von Software Architektur verstehe ^^

Klar, die Entities sollten nur einmal deployt werden!
Frage: Kann das .jar auch noch getrennt werden? Was mir vorschwebt ist, dass ich die Entitiy-Beans getrennt von den Session-Beans deployen möchte...
Die scheint wohl aber nicht zu gehen, habe bis jetzt noch keine Möglichkeit gefunden.

So müsste man nur den Teil der Applikation neu deployen, an dem Änderungen gemacht wurden.

 

[karatekid]

@wachtda
warum willst du das noch einmal trennen ? Du hast 3 Teile. Persistenz/Middleware + 2 FE Applikationen. Damit hast du doch die saubere Trennung die du willst. Anders macht es meiner Meinung nach nicht wirklich Sinn.

 

[wachtda]

@karatekid
Es ist halt problematisch, dass ich die gesamte Applikation neu deployen muss!
D.h. wenn ich Änderungen am End-User System mache (Middleware), muss ich
ich auch die Applikation für das Backoffice neu deployen...

Aber mir ist inzwischen klar geworden, dass es keine andere Möglichkeit habe.
(Ausser ich würde eine neue separate Applikation erstellen, was ich auf Grund der Wiederverwendbarkeit wirklich nicht machen möchte!)

Danke und Gruss

 

[ps]

@karatekid
Es ist halt problematisch, dass ich die gesamte Applikation neu deployen muss!

Naja.. nur wenn du ein EAR baust. Wenn du die EJBs direkt deployst und die WARs auch, dann kannst du jedes dieser Archive auch seperat neu deployen.