Einstieg JEE: Frage für Frage bis zum Erfolg :-)

[tuxedo]

Hallo,

angeregt durch meinen Post hier versuche ich nun in diesem Thread hier ein Paar Fragen beantwortet zu bekommen.

Also erstmal die Ausgangsbasis:

Ich möchte eine Serveranwendung basierend auf GlassFish. Web-Zugang kommt erstmal nicht in Frage. Netzwerkzugriff via meiner SIMON Bibliothek ist aktuell das Mittel der Wahl.

So. Erste Frage: Wo fängt die Anwendung an?
Bei einer normalen Serveranwendung würde ich hier und da, ausgehend von der main-Methode, Dinge initialisieren und dann den Socketserver (bzw. meine Registry) starten der auf eingehende Verbindungen lauscht.

Wie fang ich da mit JEE an? Gleich ne Bean erstellen? Welche? Session, Entity oder MessageDriven? Oder eine die ich noch nicht kenne?

Zweite Frage: Wie unterscheide ich die Beantypen?
Ich hab hier den einen oder anderen Beispielcode. Nur steht nirgends dabei welcher Beantyp wo verwendet wird. Anhand welcher Kriterien weiß ich was nun was ist?

Gruß
Alex

 

[maki]

Sehe da imho keinen vernünftigen Platz für SIMON, da JEE das schon kann, soz. die Weiterentwicklung von RMI

Der Server kümmert sich um alles und du musst nur doch die angebotenen Dienste nutzen, alles was du machen musst ist eine richtige Konfig zur Verfügung stellen, diese ist mit JEE6 sehr minimalistisch.

Sieh dir mal die Stateless SessionBean an, ist imho ein guter Einstiegspunkt, EntityBeans sind POJOs mit JPA annotiert, MDBs sind asynchron, zu unterscheiden an den Annotationen

 

[tuxedo]

Sehe da imho keinen vernünftigen Platz für SIMON, da JEE das schon kann, soz. die Weiterentwicklung von RMI

Über Sinn und Unsinn von SIMON in diesem Zusammenhang kann man durchaus streiten

Der Server kümmert sich um alles und du musst nur doch die angebotenen Dienste nutzen, alles was du machen musst ist eine richtige Konfig zur Verfügung stellen, diese ist mit JEE6 sehr minimalistisch.

Danke, aber soviel weiß ich schon. So ziemlich jede Seite im Netz gibt mir diese Info. Aber einafche Details oder Schritte gibts nicht. Wenn dann ist es gleich extrem Komplex und aufwendig.

Was ich mit Frage 1 gesucht habe ist schlicht und einfach ein Einstiegspunkt der mich von der Main-Methode einer normalen Anwendung zum "pendant" (ich weiß es ist nicht das gleiche, aber auch im JEE Bereich muss irgendwo etwas gestartet werden) der JEE Welt bringt.

Sieh dir mal die Stateless SessionBean an, ist imho ein guter Einstiegspunkt, EntityBeans sind POJOs mit JPA annotiert, MDBs sind asynchron, zu unterscheiden an den Annotationen

Okay, das ist ja schonmal ein Einstiegspunkt. Sun hat hierzu etwas parat: Building Your First Stateless Session Bean
Und Glassfish ebenso: https://glassfish.dev.java.net/javaee5/ejb/EJB30.html

Frage 1 und 2 sind damit schonmal zu 50% beantwortet. Danke.

Weitere Fragen folgen gewiss

- Alex

 

[tuxedo]

Frage Nummer 3: RPC mit JEE: Wie gut funktioniert das mit Callbacks übers Internet?
RMI hat da ja massive Probleme da TCP-Verbindungen in beiden Richtungen benötigt werden. Hat JEE hier etwas dazugelernt, oder darf man da keine Callbacks benutzen?

- Alex

[update]

Okay, Stateless Session Bean war das Stichwort. Was noch gefehlt hat war, dass Beans einen Lifeycle haben. Ich bin noch nicht durch mit lesen, aber sieht so aus als ob beim Deployen (oder wo auch immer) einer solchen Bean ejbXYZ Methoden aufgerufen werden, z.B. ejbCreate(). (The Life Cycle of a Stateless Session Bean (Enterprise JavaBeans)). Damit wäre die Frage nach dem "main()" pendant gelöst.

 

[mvitz]

Ja, wobei die Quelle sah jetzt eher nach EJB 2.x aus. In 3.x einfach eine Methode mit @PostConstruct annotieren.

 

[tuxedo]

Ja, wobei die Quelle sah jetzt eher nach EJB 2.x aus. In 3.x einfach eine Methode mit @PostConstruct annotieren.

In der Tat... Das ist auch einer der Punkte der mich bei vielen Tutorials verwirrt wenn's nicht explizit dabei steht. Aber damit werd' ich wohl klar kommen.

 

[The_S]

In der Tat... Das ist auch einer der Punkte der mich bei vielen Tutorials verwirrt wenn's nicht explizit dabei steht. Aber damit werd' ich wohl klar kommen.

Überall, wo es viele Annotations gibt, haste schönes JEE mit EJB 3.0 oder mit Glück sogar EJB 3.1. Alles ohne Annotations ist wohl meistens schreckliches EJB 2.x .

 

[tuxedo]

Ja, das scheint in der Tat ein geschickter Anhaltspunkt zu sein. Auch wenn ich Annotations in der Menge (noch) nicht wirklich mag.

Aber darf ich an Frage #3 erinnern ... bevor wir ganz vom Thema abschweifen

 

[byte]

Frage Nummer 3: RPC mit JEE: Wie gut funktioniert das mit Callbacks übers Internet?
RMI hat da ja massive Probleme da TCP-Verbindungen in beiden Richtungen benötigt werden. Hat JEE hier etwas dazugelernt, oder darf man da keine Callbacks benutzen?

Bin kein EJB Experte, habs das letzte mal in der Uni benutzt. Aber AFAIK benutzen EJBs unter der Haube RMI, um die Beans Remote zur Verfügung zu stellen. Du wirst hier wohl auf die gleichen Probleme stoßen wie bei reinem RMI. In der Regel werden EJBs so eingesetzt, dass Du irgendwo einen (oder mehrere) AppServer stehen hast, wo die EJBs deployed sind. Ein (oder mehrere) Webserver (Servlet Container) greifen nun auf die EJBs zu, um die Webanwendung für den Client (Browser) zu generieren. Dabei können App- und Webserver grundsätzlich auch identisch sein. Sind es verschiedene Server, müssen die Ports entsprechend offen sein.

Natürlich kannst Du EJBs grundsätzlich auch mit einer stink normalen Java Anwendung (Main Methode, RichClient) aufrufen. Da wirst Du aber das gleiche Problem mit den Ports haben wie bei RMI.


Von daher musst Du Dir erstmal überlegen, ob EJBs überhaupt das richtige für Dich sind. Ich sehe da auch nicht viel Platz für SIMON.

Worum gehts Dir überhaupt? Hast Du ein bestimmtes Ziel, das Du mit JEE erreichen willst? Oder willst Du einfach nur JEE lernen? Du musst ja nicht zwangsläufig EJBs machen, nur um JEE zu benutzen.

 

[FArt]

Aber AFAIK benutzen EJBs unter der Haube RMI, um die Beans Remote zur Verfügung zu stellen.

RMI wird zwar gerne als (Standard)Protokoll verwendet, aber das muss nicht sein. Applicationserver bieten in der Regel mehrere verschiedene Invokation-Layer an, die mit unterschiedlichen Protokollen realisiert sind. Wichtig dabei: es ist egal, welches Protokoll verwendet wird (aus Sicht der Entwickler)!

Auch wenn SIMON Vorteile gegenüber RMI hat (die diskutierte Art von Callbacks gibt es bei EJBs übrigens nicht und somit ist der Vorteil eigentlich schon dahin) ist es in der Regel nicht sehr sinnvoll ein Kommunikationsprotokoll zu verwenden, welches vom Container nicht direkt unterstützt wird, denn dann benötige ich keinen Applikationsserver, da ich defacto zwischen zwei VMs einfach eine beliebige Remotekommunikation betreibe und nicht von Remote auf EJBs zugreife. Damit verliert man natürlich auch alle Vorteile von EJBs, z.B. CMT, Security über JAAS (konfigurierbar am Container), ...

 

[tuxedo]

Aaaalso.

Ich möchte in erster Linie schon JEE lernen. Aber erstmal im kleinen und nicht gleich mit allen Features die die Eierlegende Willmilchsau JEE bietet.

Zur Sache mit RMI/SIMON/EJB:

Ich kann mir nicht so ganz vorstellen, dass EJB ohne integrierte Remote-Funktion nicht zu gebrauchen sind. Nicht jede Bean muss Remote erreichbar sein. Und EJB Remoting muss nicht das alleine Kommunikationsmittel mit der Außenwelt sein.

Hab mal mehr schlecht als recht kurz was zusammenskizziert:

I: Interfaces zur Außenwelt: Remoting, SIMON, SOAP, Telnet, ....
EE und IE: interne und externe "Events" via JMS
M: Programmmodule wie z.B. Kundenverwaltung, Auftragsverwaltung, ... (nur als Beispiel)
API: Dieser klotz führt die einzelnen Module dynamisch zusammen und stellt sie den Interfaces zur Außenwelt zur Verfügung
Persistenz: Muss ich glaub nicht erläutern.

So. Unterhalb der API macht Remoting wenig Sinn, aber JEE, so wie ich das verstanden habe, durchaus. Klar, ich könnte auch J2SE in Verbindung mit JPA, JMS und Co. benutzen. Aber dann müsste ich alles "zu Fuß zusammenkleben". Mit JEE kann ich aber einfach Module hinzufügen und wegnehmen und hab eine schon passendes Framework für die Bindung der einzelnen Komponenten.

Oberhalb der API kann ich ja anschließen was ich will. Auch hier wäre ich gern modular. Nur liegt mein Hauptaugenmerk halt auf SIMON.

 

[Noctarius]

Was du da aufgezeichnet hast klingt eher nach einem ESB (Enterprise Service Bus)

 

[tuxedo]

Mag sein. Aber im kleinen Rahmen taugt JEE ohne extra ESB hierfür doch sicherlich?!

Und um auf Frage 3 und die erste Antwort darauf zurück zu kommen:

Wenn man da keine Callbacks kennt, dann heisst das, dass Clients via JMS und dergleichen über Feedback vom Server benachrichtigt werden müssen?!

- Alex

 

[maki]

Nur liegt mein Hauptaugenmerk halt auf SIMON.

Das Problem ist, dass es keinen wirklichen Platz für SIMON in einem JEE Container gibt, wozu SIMON ohne Callbacks?
Du darfst zB. auch keine eigenen Threads starten in einer EJB, kein [c]java.io.File[/c] benutzen, da läuft alles etwas anders, ein sog. "Managed-Environment" eben

Hoffe du fast das nicht als Kritik an SIMON auf, will damit nur sagen das es vielleicht besser wäre das Hauptaugenmerk in einer neuen Umgebung nicht auf etwas zu legen, was da eigentlich nicht rein passt, vor allem wenn JEE sowieso schon für alles standartisierte Lösungen bietet, da läuft alles etwas anders als in der JSE.

 

[tuxedo]

Das Problem ist, dass es keinen wirklichen Platz für SIMON in einem JEE Container gibt, wozu SIMON ohne Callbacks?
Du darfst zB. auch keine eigenen Threads starten in einer EJB, kein [c]java.io.File[/c] benutzen, da läuft alles etwas anders, ein sog. "Managed-Environment" eben

Ah *licht aufgeh*, so langsam leuchtet's mir was du versuchst zu sagen. Aber so richtig verstehen werd' ich's wohl erst wenn ich's ausprobiert hab

Hoffe du fast das nicht als Kritik an SIMON auf, will damit nur sagen das es vielleicht besser wäre das Hauptaugenmerk in einer neuen Umgebung nicht auf etwas zu legen, was da eigentlich nicht rein passt, vor allem wenn JEE sowieso schon für alles standartisierte Lösungen bietet, da läuft alles etwas anders als in der JSE.

Iwo ... Manchmal braucht's halt nen großeren Hammer (oder eben try&error) bis ich etwas verstanden hab

Aber um auf byte's letzten Satz zurück zu kommen:

Du musst ja nicht zwangsläufig EJBs machen, nur um JEE zu benutzen.

Kann mir das mal jemand etwas erläutern? Dachte EJB und CO. wären der Kern des ganzen JEE geraffels.
Klar, ich kann auch nen J2SE Server basteln der JMS, JPA, etc. benutzt und dann noch ein Plugin-System (bitte plugin mehr im Sinn von loser kopplung von Modulen verstehen, statt dinge wie Eclipse-Plugin im Hinterkopf zu haben) integrieren. Das ist eigentlich das was dachte dass es JEE unter anderem liefert.
Oder bin ich da absolut auf dem Holzweg?

 

[byte]

Kann mir das mal jemand etwas erläutern? Dachte EJB und CO. wären der Kern des ganzen JEE geraffels.
Klar, ich kann auch nen J2SE Server basteln der JMS, JPA, etc. benutzt und dann noch ein Plugin-System (bitte plugin mehr im Sinn von loser kopplung von Modulen verstehen, statt dinge wie Eclipse-Plugin im Hinterkopf zu haben) integrieren. Das ist eigentlich das was dachte dass es JEE unter anderem liefert.

Du kannst durchaus JEE ohne EJBs benutzen. Du kannst z.B. ohne weiteres JPA auch in normalen JSE Anwendungen verwenden. Du musst Dir dann halt nur eine JPA Implementierung runterladen und einbinden. Du kannst auch problemlos JMS ohne EJBs benutzen. JMS klappt auch prima nur mit einem Servlet Container (Tomcat). Du kannst auch problemlos Remote Services über Servlets bereitstellen. Dann brauchst Du auch keine EJBs, es reicht ein einfacher Tomcat aus.

Das ist jetzt nicht nur theoretisches Geschwafel. In der Praxis gibts viele, die bewusst auf EJBs verzichten, um die Architektur nicht unnötig aufzublähen:

Use what you like and toss what you don't need. Ebay didn't feel compelled to use full blown J2EE stack. They liked Java and Servlets so that's all they used. You don't have to buy into any framework completely. Just use what works for you.

Quelle: High Scalability - High Scalability - eBayArchitecture

 

[FArt]

SIMON in einem AS könnte sinnvoll sein, wenn es über eine Schicht (InvocationLayer) gekapselt ist.

Der Entwickler programmiert gegen die EJB Spec. Zur Laufzeit wird dann SIMON zur Kommunikation verwendet. SIMON (oder EJB, oder HTTP oder was auch immer darunter steckt) ist (außer über eine Konfiguration) nicht sichtbar.

Wenn Tuxedo "im Kleinen" anfangen möchte, ist es suboptimal gerade die EJB Remotekommunikation "einzusparen": das widerspricht dem Konzept von EJBs und einem AS.

Callbacks (wenn man sie denn benötigt) werden gerne über JMS geregelt.

 

[tuxedo]

@byte:
Okay, JEE ohne EJB ... Servlets will ich vorerst auch nicht. Das heisst aber auch, dass ich eigentlich keinen ApplicationServer brauch?! Womit ich dann wieder beim "zu fuß zusammenkleben" wäre...

 

[FArt]

@byte:
Okay, JEE ohne EJB ... Servlets will ich vorerst auch nicht. Das heisst aber auch, dass ich eigentlich keinen ApplicationServer brauch?! Womit ich dann wieder beim "zu fuß zusammenkleben" wäre...

"Das ist ein Bingo!" (aus welchem Film stammt dieses Zitat? *G*)

 

[Deadalus]

@tuxedo

Dein Problem ist du denkst viel zu technisch. Die JEE wurde aus dem Grund spezifiziert, dass du dir keine Gedanken über die Technik dahinter machen sollst. Statdessen erhählst du ein komplettpaket um Verteilte Anwendungen zu entwickeln. Der Focus für dich liegt dabei auf Anwendung. Um die Verteilung kümmern sich die vielen einzelnen Implementierungen der JEE-Spezifikationen die handlich geschnürt in einem Applikation Server zu dir kommen.

Willst du JEE lernen versuche dich von deinem bisherigen Ansatz zu lösen und arbeite mit der JEE so wie es die Plattform dir vorschlägt und lass dir in bestimmten Punkten die Arbeit von ihr Abnehmen.

Ich würde dir entweder zum Kauf eines Buches raten oder dir ein paar Tutorials durchzuarbeiten. Die von Netbeans sind eigentlich sehr gut gemacht:
Java EE & Java Web Learning Trail - NetBeans Tutorials, Guides and Articles

 

[tuxedo]

Okay. Dann hab ich ja fast schon alles:

- Eclipselink für JPA
- JMS für lose Kopplung und Events
- SIMON/RMI/SOAP/<whatever> für die Kommunikation nach außen

Fehlt nur noch eine "Technik" mit der ich Module "beim starten" (wie das deployen beim JBoss-Start) "erkenne" und benutzen kann.

 

[FArt]

Okay. Dann hab ich ja fast schon alles:

- Eclipselink für JPA
- JMS für lose Kopplung und Events
- SIMON/RMI/SOAP/<whatever> für die Kommunikation nach außen

Fehlt nur noch eine "Technik" mit der ich Module "beim starten" (wie das deployen beim JBoss-Start) "erkenne" und benutzen kann.

Das ist m.E. eine Auslegung von JEE, der ich mir so noch nicht bewusst war.
Deadalus trifft den Nagel auf den Kopf.

 

[tuxedo]

Das ist m.E. eine Auslegung von JEE, der ich mir so noch nicht bewusst war.

Ist das jetzt gut oder schlecht ?

Deadalus trifft den Nagel auf den Kopf.

Okay, hatte Daedalus' Beitrag erst jetzt gesehen :-(

Ich denke ich muss mein Vorhaben etwas umformulieren:

Ich hab nen groben Aufbau einer Client-Server Anwendung im Kopf. Eigentlich sollte das ganze ziemlich "lightweight" werden. Bin dann aber nochmal über JEE gestolpert und dachte das ist eine tolle Lösung, weswegen ich die Threads hier eröffnet hab.

Mittlerweile bin ich an folgendem Erkenntniss-Stand angelangt:

- JEE exakt so nutzen wie es gedacjht ist und "keine extrawürste" mit dazu tun, und sich der JEE philosophie blindlings hingeben. Das ist die eine Lösung
- JEE vorne wie hinten abspecken und nur das rauspicken was man wirklich braucht und hier und da ein wenig selbst implementierten Kleber einsetzen. Das ist die andere Lösung

Erfahrung mit der ersteren ist sicherlich nützlich im Business-Umfeld und mit Anwendungen die schnell an größe und Umfang gewinnen, da hier schon viel erdacht und bereits gelöst ist.

Letztere Variante könnte für kleinere Vorhaben schnell zum Ziel führen, mit der Bedingung dass man einige Ecken und Kanten selbst glätten muss und man evtl. nochmal die gleiche Erfahrung macht wie die, die JEE dahin gebracht haben wo es jetzt ist.

Naja, mal schauen welchen Weg ich nun letztendlich gehe. Ich denke ich werde beides durchlaufen müssen um hinterher sagen zu können: Der andere Weg wäre besser gewesen.

Danke mal soweit für alle "Mitentscheidungshelfer" und "Fragenbeantworter".

- Alex

 

[byte]

Solange wir nicht wissen, was Du überhaupt für Probleme lösen willst, können wir Dir auch bei der Auswahl des Werkzeugs nicht wirklich weiterhelfen.

Grundsätzlich muss man sich bei diesem Thema aber halt die Frage stellen, wie die Infrastruktur am Ende aussehen soll. Setzt man auf den kompletten JEE Stack inkl. EJBs, dann ist ein JEE-ApplicationServer zwingend erforderlich. Plant man hingegen, das ganze möglichst Lightweight aufzuziehen, dann kann man auch gut auf den ApplicationServer verzichten und sich auf die Teile von JEE konzentrieren, die auf einem Servlet Container laufen.

Für viele Webanwendungen ist eine zusätzliche EJB Schicht IMHO vollkommen überflüssig. Eine Service-Schicht aus einfachen POJOs + JPA im Business Model ist da vollkommen ausreichend. Als Konsequenz brauche ich dann gar keinen AS. Es reichte ein einfacher Tomcat oder Jetty. Das hat Sun offenbar nun auch eingesehen und die JEE Profile eingeführt.

Wer sich mal die Architekturen bekannter großer Anwendungen anguckt, der sieht, dass der Trend klar hin zu leichtgewichtigen Servern und Stateless Services geht. Der Trend geht auch eher weg von Datenbanken und hin zu Caching (Twitter hält neuerdings alle Daten im RAM und benutzt die DB nur noch als Backup). Google App Engine läuft intern mit mehreren 10.000 Jetty Instanzen. usw.

(my 2 cents und so)

 

[FArt]

Ich gehe jetzt mal auf die Begriffe "client-server" und "lightweight" ein:

Spring und Sping-Remoting... das ist der Clou.

Davon kann man bei Bedarf (auch später) immer noch auf JEE umschwenken, durch eine von Spring geförderte saubere Trennung ist das relativ ordentlich geregelt.

 

[Noctarius]

Und Spring Remoting gibt es sogar mit SIMON *hust*

 

[FArt]

Und Spring Remoting gibt es sogar mit SIMON *hust*

Na dann ist die Welt ja wieder in Ordnung.

Was machen wir morgen, Brain?
Das was wir jeden Tag machen, Pinky. Die Weltherrschaft an uns reißen...

 

[bronks]

... Das hat Sun offenbar nun auch eingesehen und die JEE Profile eingeführt ...

Was ist damit gemeint? Hast Du evtl. einen Link für mich?

 

[byte]

google einfach nach 'jee 6 profiles'