Diskussion:Jakarta Enterprise Beans

Webservices

Was haben WebServices hier in diesem Artikel zu suchen? Als Querreferenz ok, aber nicht unter EJBs.

Ja Du dafst nicht vergessen das man mit WebServices eine menge machen kann und EJB unterstützt diese nun mal! Ab der Version 3.0 is fast alles Web-Basiert. Ich frag mich da nur wo die Sicherheit bleibt.

Trotzdem, die WebServices in der Auflistung von EJBs zu haben ist fahrlässig und irritiert die Leser mehr als es nützt.

Ich habe die Formulierung so geändert, dass klar sein müsste, was genau die Spezifikation in Zusammenhang mit Webservices spezifiziert, nämlich wie eine EJB als Webservice aufgerufen werden kann. --Jpp 20:50, 8. Mai 2005 (CEST)

In der Tat ist ein Unterabschnitt WebServices im dem Kapitel EJB nicht korrekt. WebServices sind keine Enterprise JavaBeans, was dieser Abschnitt suggeriert. Die JEE-Spezifikation definiert lediglich eine Möglichkeit mit SessionBeans über einen WebService zu kommunizieren, bzw diese als WebService zu veröffentlichen.--Derkautz (Diskussion) 19:11, 5. Jul. 2014 (CEST)--

Stateless/Statefull

Fonzmann ergänzte: "Dabei können zustandsbehaftete Session Beans unterschiedliche Zustände annehmen und verfügen deshalb über eine Identität." Immerhin der Versuch einer Erklärung, aber mir zum Beispiel hilft das nicht so richtig. Zustandsbehaftete Session Beans haben also unterschiedliche Zustände aber wie kann ich das verstehen? Welche Zustände können das sein? Welche Bedeutung haben sie? Was ist eine Identität? Vielleicht kann das jemand präzisieren. --Berthold Werner 10:04, 18. Jul 2005 (CEST)

Ich habe den Absatz komplett neu formuliert. Ist er jetzt verständlicher? --jpp 12:22, 18. Jul 2005 (CEST)

Ja. Das hilft mir weiter. Vielen Dank. --Berthold Werner 14:51, 18. Jul 2005 (CEST)

Sorry aber deine Beschreibung hat etwas mystisches, kann ich als Entwickler nicht ganz nachvollziehen, hab eine Ergänzung hinzugefügt. --Sonntag.michael

Instanz einer Bean

Falls eine Entity Bean persistente Daten modelliert, wie nennt man dann die eigentliche Instanz der Bean?

-> Ich glaube man kann eine Entity Bean als Tabelle in einer Datenbank sehen und die Instanzen als als Einträge (Zeilen) dieser Tabelle oder war das nicht die Frage?

Engl. Wiki

Hallo,

wie meistens gibt en.wikipedia.org einen präziseren Einblick in die Materie: http://en.wikipedia.org/wiki/Enterprise_Java_Beans

Dieser Feststellung kann ich mich anschliessen. Da hilft nur eins: Tastatur frei und loslegen.... :-) --Michael Hüttermann 13:07, 27. Mai 2006 (CEST)

Einleitung nicht gut verständlich

Hi all

Ich finde den Unterschied zwischen Java Beans und EJB sehr wichtig so zu erläutern, dass überhaupt keine Missverständnisse mehr auftreten und dass man es kapiert hat. Ich finde die Einleitung wie sie hier steht zu wenig verständlich, sie ist ein wenig schwammig (jedenfalls meint das mein Hirn).

Ich finde es nicht gut dass man als Beispiel für Java Beans die Grafischen Elemente nennt, denn sie bringen eine selbst komplexe Thematik mit ein. Für mich ist es verständlicher Java Beans mit dem Modell aus dem MVC Paradigma in Verbindung zu bringen.

Gerne versuche ich eine deutlichere Formulierung, aber ich muss zuerst in meinem J2EE Buch lesen / Klarheit schaffen.

Vielleicht auch nur Ansichtssache, danke für euren Kommentar...

DTOs Anti-Pattern?

Meiner Wahrnehmung nach dienen Datentransferobjekte nicht nur den Entkopplung von der Persistenz, sondern auch der fachlichen Entkopplung der Entitäten von Ihrer Darstellung. Daher halte ich auch für JEE 5 Datentransferobjekte für eine sinnvolle Vorgehensweise. Woher stammt die Einstufung als Anti-Pattern? (Thomas Greve, 28.06.2006)

von mir.;-) Wie der Name schon sagt handelt es sich bei DTOs um Transfer Objekte. Dazu gibt es z.b. auch im Netz zahlreiche Quellen.--Michael Hüttermann 20:59, 28. Jun 2006 (CEST)

Hm, überzeugt mich nicht. Zwar beschreibt der Name "Transfer-Objekte" zutreffend deren technischen Zweck. Die architektonische Implikation, nämlich die Vermeidung zu enger Koppelung zwischen verschiedenen Schichten, liegt eher auf der Meta-Ebene. Dieser Vorteil bleibt auch bei POJO-Entitäten erhalten und sinnvoll. Man könnte das Pattern eventuell nach seinem nun primären Zweck "Entkoppelungsobjekte" nennen, da sie aber nach wie vor die gleiche technische Aufgabe erfüllen (wenn dies nun auch weniger technisch motiviert ist), halte ich das nicht für sinnvoll. (Thomas Greve, 03.07.2006)

Ich würde die Anti-Pattern-Frage damit in den Bereich der Meinung (im Gegensatz zu Information) verweisen. Die Bewertung „Anti-Pattern“ habe ich entfernt. (Thomas Greve, 14.11.2006)

Die Formulierung war komisch.

"Gewöhnlich ist mit JEE 5 die recht umständliche und mühselige Nutzung von "Datentransferobjekten" ein Anti-Pattern."

Aber laut Handbuch sind DTOs in JEE 5 Anti-Patterns. cljk 13:15, 14. Nov. 2006 (CET)

Was meinst du mit „Handbuch“? --jpp ?! 13:44, 14. Nov. 2006 (CET)

Sorry, meinte die EJB3-Spezifikation. Hätte schwören können, dass da was von DTO=anti pattern stand. Hab mir aber grad extra nochmal das PDF runtergeladen und von vorn bis hinten durchsucht und nichts mehr dazu gefunden. Ich nehme mein Statement also erstmal zurück. cljk 17:59, 14. Nov. 2006 (CET)

DTOs sind ein Architekturpattern, das völlig unabhängig von jeglicher Technologie betrachtet werden kann. Nur weil eine bestimmte Technologie sie nicht mehr aus technischen Gründen benötigt, ist es in Verbindung mit dieser Technologie noch lange kein Anti-Pattern. Sie erfordern einen gewissen Zusatzaufwand, dafür liefern sie Entkopplung. Ob das sinnvoll ist, ist im Einzelfall zu prüfen, eine Bewertung hier halte ich für zu pauschal. -tg

DTOs mögen überflüssig geworden sein - sie sind aber in EAOs (Entity Access Objects) aufgegangen, was man vielleicht auch erwähnen sollte --> http://www.datadisk.co.uk/html_docs/ejb/ejb3_integration.htm (nicht signierter Beitrag von Village Hero (Diskussion | Beiträge) 17:48, 15. Mär. 2011 (CET))

Du verwechselst anscheinend das Pattern DTO (siehe Transferobjekt) mit der konkreten Implementierung von DAOs (siehe Data Access Object) in EJB3/JPA. --Sebastian.Dietrich ✉ 18:23, 15. Mär. 2011 (CET)

EJB <-> Java Beans

EJBs basieren nicht auf Java Beans. Beide Sachen haben nichts miteinander zu tun. Die einleitung ist demnach falsch und muss wieder geändert werden. (nicht signierter Beitrag von 84.60.232.87 (Diskussion) )

Da hast du vollkommen recht, auch wenn die EJBs sich in der aktuellen Version 3.0 den POJOs wieder annähern. --jpp ?! 09:57, 8. Sep 2006 (CEST)

Ich würde trotzdem die Abgrenzung zu JavaBeans mit aufnehmen. Sowas in Richtung "EJBs sind container-managed JavaBeans" (nicht signierter Beitrag von Village Hero (Diskussion | Beiträge) 17:48, 15. Mär. 2011)

Bitte signiere Deine Beiträge mit --~~~~--Sebastian.Dietrich ✉ 18:17, 15. Mär. 2011 (CET) - Wie Jpp davor schon schrieb wäre diese Aussage aber falsch. EJBs sind eben NICHT container-managed JavaBeans, sondern was ganz anderes (technisch und konzeptionell) --Sebastian.Dietrich ✉ 18:17, 15. Mär. 2011 (CET)

Version 3.0

man könnte noch erwaehnen, dass Entity Beans seit 3.0 auch Vererbung unterstuetzen

Trennung der arten der SessionBeans?

Worin der Unterschied zwischen Zustandslosen und Zustandsbehafteten Session Beans liegt wird gut erläutert, aber warum man klar zwischen den beiden typen unterscheiden soll bleibt nach oberflächlicher Betrachtung des Artikels ein Rätsel. Hier währe ein plastisches Anwendungsbeispiel hilfreich.

Container-Managed Persistence (CMP) and Entity Beans are outdated.

Sollte hier unbedingt eingearbeitet werden, da man als Anfänger sonst leicht anfängt sich mit diesen beiden Themen und Tutorials zu beschäftigen, ohne zu wissen dass es neuere Methoden gibt. (nicht signierter Beitrag von 178.2.134.80 (Diskussion) 15:21, 19. Jun. 2011 (CEST))

Neue Bezeichnung

Eine Verschiebung des Artikels ist nötig. --37.4.226.220 12:35, 22. Feb. 2021 (CET)

Erledigt. --Fabian von Treuen (Diskussion) 10:13, 24. Feb. 2021 (CET)