JEE Architektur

[AK4784]

Hallo Gruppe

Ich bin relativ neu in der Architekturschiene und möchte ein Projekt realisieren. Dazu habe ich mir die im Anhang befindliche Architektur überlegt. Ich würde gerne wissen, ob die Darstellung so korrekt und JEE konform ist. Für Verbesserungsvorschläge bin ich natürlich immer willkommen

Noch eine kleine Beschreibung zu meiner Darstellung:

1. Der Client verbindet sich via HTTP mit dem Apache HTTP Server
2. Der HTTP Server schickt die Anfrage über einen Loadbalancer an einen der beiden Tomcats weiter.
3. Als Servletcontainer würde ich Tomcat verwenden.
4. Die Faces Servlets greifen wiederrum auf die JSF Pages zu.
5. Die JSF Pages kommunizieren mit den Session Beans.
6. Die Session Beans wiederum mit den Entity Beans.
7. Und die Entity Beans kommunizieren mit der Datenbank.

Folgende Technologien würde ich zum Einsatz bringen:

- JBOSS als WebContainer, wenn ich das richtig verstanden habe, beinhaltet dieser bereits schin den Apache HTTP Server, einen Tomcat und JSF.
- Weiterhin würde ich für das objektrelationale Mapping Hibernate verwenden.
- als Datenbank würde ich Oracle verwenden

Das sind zunächst erstmal die grundlegenden Sachen. Habe ich noch etwas vergessen?

Wäre super, wenn ich ein Feedback bekommen würde!

Viele Grüße

 

[maki]

>> Dazu habe ich mir die im Anhang befindliche Architektur überlegt.

Was waren denn die Beweggründe sich für diese Architektur zu entscheiden?

Ich meine, Architektur hat auch immer etwas mit den zu lösenden Problemen zu tun

Ansosnten würde ich sagen, dass die JSF Seiten niemals direkt auf Session Beans zugreifen, wenn dann machen dass die ManagedBeans.
Dein ORM (Hibernate) taucht gar nicht im Diagramm auf, hast den komplette Persistenz Layer/Tier weggelassen, stattdessen aber fälschlicherweise ausgedrückt dass die EntityBeans mit der DB kommunizieren.
Liegt es vielleicht daran dass du Probleme hattest eine 4 Schicht-Architektur in 3 Schichten darzustellen?
Denn eigentlich sind das 4 Schicht Architekturen, wenn man die DB berücksichtigt. (Presentation,Business, Integration/Persistence, DB).

 

[FArt]

Wie maki schon sagte, so aus der hohlen Hand kann man keine genaue Aussage treffen.

Aber folgendes ist auffällig:
- Wieso planst du von Anfang an einen Apache mit Loadbalancing ein? Gibt es entsprechend nichtfunktionelle Anforderungen und dazu passende Analysen? Hast du über JBoss-Clustering nachgedacht?
- Hast du über die Verwendung von JBoss-SEAM nachgedacht?

 

[juniverse]

--schnipp--------

>> Dazu habe ich mir die im Anhang befindliche Architektur überlegt.

Was waren denn die Beweggründe sich für diese Architektur zu entscheiden?

Ich meine, Architektur hat auch immer etwas mit den zu lösenden Problemen zu tun

Ansosnten würde ich sagen, dass die JSF Seiten niemals direkt auf Session Beans zugreifen, wenn dann machen dass die ManagedBeans.
Dein ORM (Hibernate) taucht gar nicht im Diagramm auf, hast den komplette Persistenz Layer/Tier weggelassen, stattdessen aber fälschlicherweise ausgedrückt dass die EntityBeans mit der DB kommunizieren.
Liegt es vielleicht daran dass du Probleme hattest eine 4 Schicht-Architektur in 3 Schichten darzustellen?
Denn eigentlich sind das 4 Schicht Architekturen, wenn man die DB berücksichtigt. (Presentation,Business, Integration/Persistence, DB).

---schnapp--------

das ist ein heißes thema.. und ziemlich frickelig..

offengestanden ist mir die genaue rolle von hibernate, insbesondere in hinblick auf die ab ejb3 benutzte jpa funktionalität auch nicht ganz klar...;( (und im übrigen der grund dass ich mich hier heute angemeldetet habe..:toll

wenn ich das richtig verstanden habe, läuft dass or mapping dort doch mit den annotations und "auf wundersame weise" schön transparent im hintergrund ab...
(oder nicht..??), will heißen, dass der appcontainer, per configuration und per default mit irgendeinem persistance provider... ich glaube toplink läuft bei jboss 5 ....
alles für einen übernimmt. (d.h auch die hibernate konfiguration??) das würde ja beglückender weise bedeuten, dass man sich darum nicht kümmern müsste... sondern einfach die annotations in den beans konfiguriert.... zumindest die grundkonfiguration.

und wenn das so ist, muss man sich dann überhaupt mit dem geraffel von der erm.xml von hibernate und so auskennen?

und wie ist das mit oracle oo features... mit types und so.. oder sind das features für jdbc only sinnvoll sind?
diese oo features nutzt doch sicher ein hibernate nicht, oder stellt sich das auf die db dahinter ein? fragen über fragen..



ist das so? wo steig ich unsinnigerweise falsch aus, und wo bitteschön gibts gute bücher , die mal diese ganze neue "ich hab da mal ein framework" gewirr effizient entschlüsseln... das prob. ist .... ich hab teilweise das gefühl im kreis zu lesen...:rtfm:
anny suxx, anyoneortwo?!:noe:



(ach ja, den hibernate thread hab ich schon gefunden, bin aber nur unwesentlich(aber ein bischen) schlauer..)

 

[foobar]

das ist ein heißes thema.. und ziemlich frickelig..

offengestanden ist mir die genaue rolle von hibernate, insbesondere in hinblick auf die ab ejb3 benutzte jpa funktionalität auch nicht ganz klar...;( (und im übrigen der grund dass ich mich hier heute angemeldetet habe..:toll

wenn ich das richtig verstanden habe, läuft dass or mapping dort doch mit den annotations und "auf wundersame weise" schön transparent im hintergrund ab...(oder nicht..??), will heißen, dass der appcontainer, per configuration und per default mit irgendeinem persistance provider... ich glaube toplink läuft bei jboss 5 ....
alles für einen übernimmt. (d.h auch die hibernate konfiguration??)

Naja, nicht ganz. Ein Appserver stellt dir eine JPA-Implementierung z.b. Hibernate oder Toplink zur Verfügung. Wenn du JPA nutzt, spielt es keine Rolle welche Implementierung dahinter liegt.

das würde ja beglückender weise bedeuten, dass man sich darum nicht kümmern müsste... sondern einfach die annotations in den beans konfiguriert.... zumindest die grundkonfiguration.

Ja, du kannst die Mappings entweder in den Beans selber vornehmen oder in XML. Die Hibernate und JPA Konfiguration ist ja nicht so wild. Du mußt nur angeben mit welcher DB(Url,Typ,etc) du connecten willst. Die meiste Arbeit stekct sowieso in den Mappings.

und wenn das so ist, muss man sich dann überhaupt mit dem geraffel von der erm.xml von hibernate und so auskennen?

Kenntnisse des darunter liegenden ORM sind auf jeden Fall sinnvoll.

und wie ist das mit oracle oo features... mit types und so.. oder sind das features für jdbc only sinnvoll sind?
diese oo features nutzt doch sicher ein hibernate nicht, oder stellt sich das auf die db dahinter ein? fragen über fragen..

Du mußt Hibernate sagen, welche JDBC-Implementierung du nutzen willst z.b. MySql, Oracle etc. Davon abhängig wird dann DB-spezifischer Sqlcode generiert. Ausserdem legt der Typ auch fest, ob z.b. Subselects verwendet werden können.