Hallo,

ich möchte Teile des Codes in Jsp/Servlets wiederwenden.
Z.B. holt sich Jsp oder Servlet die benötigten Information aus einer
Java Klasse und erzeugt dann dynamisch eine Seite.

So, soll die Java in einer Libary sein(Jar und Web_inf) oder eine J2EE Bean?
Was ist dort der Unterschied?

Wenn ich z.B. eine JNDI connection aufbaue, möchte ich
dies in eine Java Klasse kapseln. Soll ich die jetzt in einer
J2EE Bean oder in einer Jar datei deployen?

Vielen Dank.

Hallo,

die Fragen die du ansprichst, sind zentrale Fragen, die sich für moderne Architekturen stellen und die mit den verschiedensten Frameworks und Laufzeitumgebungen unterschiedlich abgebildet werden.
Wenn du die Fragen möglichst generisch und architekturell sauber lösen willst, müsstest du eine passende Laufzeitumgebung und frameworks auswählen.
Zentrale Javaklassen und beans sind eine Zwischenstufe zwischen straight runterprogrammieren und komplexe frameworks einzusetzten.

grössere Lösung:
Appserver(JBoss, Jonas, WebSphere Appserver) + Frontendframework(JSF, Struts) + evtl. Persistierungsframework(Hibernate)

kleinere Lösung:
Servletengine(Tomcat) + optinale frameworks wie JSF

noch grösser:
Restrukturierung der Funktionalitäten in Services(z.B. Webservices), Implementation dieser auf einem ApplikationServer oder ESB Plattform und seperates Design der Frontendkomponente.

Pragmatischer konnte ich grad nicht antworten. Falls du schon eine Laufzeitumgebung oder ein Framework einsetzt, gibt es dafür dann spezielle Vorgehensweisen wie mit Ressourcen usw. umgegangen wird.

Stimmt, ich habe vergessen die Umgebung zu benennen,
sorry nochmal. Ich verwende zur Zeit Jboss, deswegen kam
auch die Frage bei mir mit der EJB auf.

Ich weiss nicht ob ich lieber Klassen die ich wiedervewende
als Library (Jar datei und ab ins Web_inf/lib) oder sie
in EJB en soll.

Diese Klassen sind statisch d.h.
sie müssten einmal beim Server start erzeugt werden
und bleiben dann.

Das hängt stark von der Funktionalität der Javaklasse ab. Die Verwendung von JavaBeans erhöht am Anfang die Komplexität im Vergleich zu einfachen Javaklassen, hat jedoch entscheidende Vorteile bei der Wiederverwendbarkeit, Sicherheit und Skalierbarkeit.

Javaklasse kapselt Funktionalität, Transaktions-, Security, Skallierungsfeatures werden benötigt. -> EnterpriseBean
Javaklasse hält temporäre Informationen z.B. beim Begleiten einer Session und/oder steuert einen komplexeren Ablauf für einen Client. -> SessionBean
Javaklasse ist Abbild/Verantwortlicher von persistenten Informationen. -> EntityBean
Asynchrone messaging (JMS) Funktionalität erforderlich. -> MessageDrivenBean

gute Infos zu Beans: http://java.sun.com/j2ee/tutorial/1_...BConcepts.html

Hm, jetzt habe ich immer noch nicht die Frage beantwortet.
Also meine Empfehlung ist:
Wenn du schnell ans Ziel kommen willst, Java.
Wenn du dabei gern struktuiert vorgehen und dazulernen willst und das Thema EJB und Applicationserver eh interessant ist, JavaBeans.

Hallo zusammen,

ihr holt aber gleich weit aus . Bevor man so umfangreiche und komplexe Entscheidungen trifft, sollten ein paar Dinge klar sein: Kleine Logik in JSPs, sondern in Klassen die unabhängig von jedweder technologie sind. Begrifflichkeiten wie "Bean" oder "JavaBean" machen die Sachen nicht einfacher. Für denen einen sind es Klassen mit einfachen Gettern und Settern, für andere EJBs, für den nächsten wieder Springbeans.

Deswegen ist es IMHO absolut unfruchtbar sich erst darüber Gedanken zu machen, welchen Container man sich ins Haus holt, welches Framework man verwendet usw. Der erste - relativ untechnische - Schritt sollte sein, seine Anwendung logisch zu zerlegen, fachliche Subsysteme zu bilden und (nicht)funktionale Anforderungen mit in Betracht zu ziehen: mit welchen anderen Systemen muss ich reden, gibt es Infrastrukturvorgaben usw.

Um jetzt doch wieder zu den Technoogien zu kommen: ich halte es für sinnvoll etwas zu wählen, was den geringstmöglichen Einfluss auf das Design der Klassen, deren Testbarkeit usw. hat. Ich möchte nicht unbedingt die EJB VS. Spring Debatte aufmachen, aber ich habe das Gefühl das Projekte von einem kleineren Container profitieren. Es gibt sehr wenige Gründe (und es werden immer weniger) die für den Einsatz eines komplette AS sprechen. Witziger Weise hat sich das Management in meinem aktuellen Projekt (Bankumfeld) aus einem eigentlich sinnvollen Grund für einen AS entschieden (JMS über einen JCA Resourceadapter). Als dann allerdings die konkreten Anforderungen klar wurden, stellte sich raus, das die Kiste das, was wir genau brauchten, einfach nicht kann. Und das für einen 5stelligen Eurobetrag pro CPU . Jetzt ziehen wir den Resourceadapter mit 5 Zeilen XML in Spring selbst hoch und die App läuft auf den Devrechnern in nem Tomcat. Das ist aber auch nicht das erste mal, dass ich ähnliche Szenarien erlebt hab.

Genug gebasht. Kurz: man tut gut daran, sich im Code an so wenig wie möglich Technologien zu knüpfen.

Gruß
Ollie