Wie funktionieren Enterprise Beans



  • Ich programmiere schon eine längere Zeit in Java. Nun möchte ich mir mal JEB angucken. Damit man diese ausführen kann braucht man einen J2EE Applicationserver.

    Nun gibt es verschiedene Beantypen wie Session Bean's, EJBHome, EJBObjects. Wenn ich das alles richtig verstanden habe, braucht der Application Server diese , damit er mehr Leistung rausholen, oder diese persistent halten kann.

    Wenn ich jetzt nun eine Anwendung schreibe, die im Application Server laufen soll, muss dann jede Klasse von diesen EJB Objekte erben oder implementieren?

    Angenommen ich habe schon eine Java Anwendung die sich aus ca. 50 Klassen zusammen setzt. Nun möchte ich diese Anwendung gerne für einen Application Server umschreiben. Muss ich dafür wirklich jede Klasse anpassen? 😕

    Danke



  • Hi

    wieso willst du deine anwendung eigentlich auf EJB umschreiben, was erhoffst du dir davon?
    mehrbenutzerfähigkeit, Persistenz,...

    was verwendet deine app bisher bzw was macht sie? einfach etwas berechen, Datenbank zugriffe, ...

    ja es gibt verschiedene Beans. SessionBeans (statefull und stateless für die Buisnenslogik) und EntityBeans(bigts glaub auch 2 unterarten. für die Persistenz) und noch ein zwei andere. (den aktuellen stand kenn ich nicht)

    deine klassen müssten diese implementieren.

    2. Frage Jein. Kommt drauf an was alles in eine bean rein soll. Jede klasse eine bean? oder alles in eine Bean?

    kommt somit auf diene app an. wenn du alles in eine SessionBean stecken willst must du eigentlich nur eine Bean Interface basteln (währe eine zusätzliche klasse). und die Datenobjekte anpassen, die nach ausen gereicht werden. Diese müssten Serialisierbar sein. Nur ist die frage ob's das wirklich bringt. Den jeder kleient arbeitet mehr oder weniger mit seinem eigenen Objekt und seinem eigenen daten, nur das es auf dem server ausgeführt wird und nicht auf dem client. und persistent ist das nun auch noch nicht.

    gruss Termite



  • Termite_ schrieb:

    Hi
    wieso willst du deine anwendung eigentlich auf EJB umschreiben, was erhoffst du dir davon?
    mehrbenutzerfähigkeit, Persistenz,...

    was verwendet deine app bisher bzw was macht sie? einfach etwas berechen, Datenbank zugriffe, ...

    Wir werden Mitte bis Ende diesen Jahres versch. Schulungen zu J2EE, EJB haben, da unsere Firma dies in die Produktpalette aufnehmen will. Ich will mir vorher schon mal einige Grundkenntnisse aneignen.

    Die Anwendungen werden primär Datenbankanwendungen sein.

    Termite_ schrieb:

    ja es gibt verschiedene Beans. SessionBeans (statefull und stateless für die Buisnenslogik) und EntityBeans(bigts glaub auch 2 unterarten. für die Persistenz) und noch ein zwei andere. (den aktuellen stand kenn ich nicht)

    deine klassen müssten diese implementieren.

    2. Frage Jein. Kommt drauf an was alles in eine bean rein soll. Jede klasse eine bean? oder alles in eine Bean?

    kommt somit auf diene app an. wenn du alles in eine SessionBean stecken willst must du eigentlich nur eine Bean Interface basteln (währe eine zusätzliche klasse). und die Datenobjekte anpassen, die nach ausen gereicht werden. Diese müssten Serialisierbar sein. Nur ist die frage ob's das wirklich bringt. Den jeder kleient arbeitet mehr oder weniger mit seinem eigenen Objekt und seinem eigenen daten, nur das es auf dem server ausgeführt wird und nicht auf dem client. und persistent ist das nun auch noch nicht.

    gruss Termite

    Nee, es sollte schon wie eine normale Anwendung aussehen. Also jede Aufgabe seine eigene Klasse, schön nach MVC trennen. Halt wie man normale Client-Server Anwendungen auch programmieren würde. Nur halt auf EJB Basis.

    Was ich leider immer noch nicht ganz verstehe ist, wozu müssen die Klassen die verschieden EJB Typen erweitern/implementieren? Wegen der Persistenz?

    Danke!



  • Hi

    so weit ich das bisher verstanden hab ( darf grad selber damit kämpfen ) gibt es 2 arten von Beans. die Session bean, in der deine buisnes logik implementiert werden sollte(nicht persistent). heist sicherheitsabfragen, berechnungen, z.B. zu einem Auftrag für ein Angebot erstellen(Status ändern, Buchungen durchführen, Materiallisten erstellen, ...)... und die EntityBeans. die sind für die datenbank verantwortlich (persistent). Dort können dann für jedes einzelnes feld geter und seter angelegt werden bzw auch komplexere dinge. Die EntityBean kümmert sich dann selbständig um die DBeinträge. Vorteil ist das man die DB tauschen können soll ohne dabei die calass fils anpassen zu müssen.

    Die ableitung ist notwendig, da der EJB server die beans verwaltet und managet, und auch unterschiedlich behandelt. Er ruft dann in bestimmten situationen Methoden des Interfaces auf damit deine bean entsprechend reagieren kann. z.B. wird eine EntityBean benachrichtigt wenn sie geladen oder gelöscht wird. ggf kann es ja auch vorkommen das der server objekte wiederverwendet, z.B. aus geschwindigkeitsgründen. (ich hab dort zumindest noch nichts implementieren müssen)

    Am Anfang hat mich vorallem der wust an Dateien verwirrt der da benötigt wird. LocalInterface, LocalHomeInterface, HomeInterface, und die BeanFile selber und dann noch die ganzen XML Dateien und das dan noch schön sauber in ein jar file verschnüren. Das dann noch dem Server verfüttern ohne das der sich gleich daran verschluckt. 😡
    Die fehlermeldungen zumindestens vom JBoss sind hin und wieder auch nicht gerade aufschlussreich gewesen. Hat er die bean nu geschluckt oder nicht.
    Was auch noch ein böser fehler war, die Datenobjekte die zwischen Client und server ausgetauscht werden müssen Serialisierbar sein (auch die unterelemente)

    Hast du schon mal ein einfaches HelloWorld mit jbos Realisiert? Elise hat glaubich mal was zusammengeschrieben was mir zumindestens am anfang geholfen hat. (hier mal im forum suchen)

    Ist jetzt schon ungefähr klar was für eine Entwicklunsumgebung eingesetzt werden soll? Viele Teile bei den Beans lassen sich automatisieren. Gerade die Erstellung der Interface Dateien und der XML dateien. z.B. mit XDoclet

    ggf kann ich mal mein erstes hello world Bean zusammen packen. muss nur noch mal schauen ob die noch lauffähig ist oder ob ich die wieder geschredderd hab.

    gruss termite



  • Hi,

    Wollte nur mal sagen, dass es auf www.theserverside ein ebook (legal und kostenlos) zum Download angeboten wird.

    Hier noch ein genauer Link: http://www.theserverside.com/books/wiley/masteringEJB/index.tss

    Ach ja lass dich am Anfang von der Komplexität nicht abschrecken in ein paar Monaten sollte man die Grundlagen drauf haben.

    Ps: Dies macht die sache mit dem EJB's noch einfacher: http://xdoclet.sourceforge.net/xdoclet/index.html

    Hoffe konnte helfen.



  • Kurz zusammengefasst kann man sagen:

    Es gibt 3 Arten von EJBs:

    - Entity Beans (entspricht einem Datensatz, z.B. Kunde, Buch)
    - Session Bean (statefull oder stateless; entspricht einem Anwendungsfall z.B. Login)
    - Message Driven Beans (für asynchrone Vorgänge, z.B. dem Zahlungsvorgang)

    Zur Erstellung einer Entity oder Session Bean muss folgendermaßen vorgegangen werden (stichpunktartig und unvollständig):
    z.B. wollen wir eine EntityBean Book erstellen:

    1. HomeInterface definieren mit dem Namen der Bean + Home (hier also BookHome)
    public interface BookHome extends EJBHome
    

    Das Interface erweitert EJBHome und beinhaltet create und find-Methoden. Per HomeInterface erhält man Zugriff auf das Remote Interface
    2) RemoteInterface definieren (nur der Name der Bean)

    public interface Book extends EJBObject
    

    Das RemoteInterface beinhaltet alle Businessmethoden (getter/setter), also hier z.B. getTitle(), setISBN() usw
    3) Die Bean selbst implementieren

    public class BookBean implements EntityBean
    

    Der Name ist dabei der Name der Bean + Bean (hier also BookBean). Abgeleitet wird dabei von der entsprechenden Klasse. Hier werden nun alle Methoden des RemoteInterfaces implementiert sowie ggf. eine CreateMethode.
    Die Vorgehensweise bei der Implementierung einer EJB unter EJB1.1 und EJB2.0 unterscheiden sich dabei.


Anmelden zum Antworten