# EJB3-Standard und dafür geeignetste SQL-Datenbank



## paulchen54 (8. Jun 2005)

Hi,

ich untersuche vor Beginn eines Projektes, das mittels EJB’s erstellt und Massendaten verarbeiten soll, welche gängige SQL-DB am besten geeignet ist.
Sind open-source(MySQL / PostGre) oder kommerzielle Systeme(ORACLE / DB2) besser geeignet ? 
 Das ausgewählte System soll dem zu erwartenden  EJB3-Standard am besten entsprechen !
Weiß jemand von Euch im Detail, was z.Bsp. für ORACLE / DB2 , was dagegen spricht…
Was ist mit Lastverhalten, Sicherheit, Konsistenz,  wie wird der JDeveloper als IDE  für ORACLE bewertet ?
Es sind eigentlich zu viele Fragen, aber im Forum gibt es ja Freaks, oder ??(Bleiglanz!).

Jede Antwort ist willkommen,

Grüße,
Rainer.


----------



## Bleiglanz (8. Jun 2005)

> Das ausgewählte System soll dem zu erwartenden EJB3-Standard am besten entsprechen!


In diesem Fall nimm halt eine Heissluftdatenbank!


EJB und Massendaten? Das ist Humbug!

Für Oracle/DB2 spricht einiges, dagegen der Preis und die Monströsität - und die Tatsache, dass ein vernünftiger Admin benötigt wird

Was untersuchst du eigentlich, erwartest du allen ernstes eine Diskussion der Vor- und Nachteile von Oracle oder DB2? Und was willst du mit EJB3, das ist erst übernächstes Jahr interessant??


----------



## paulchen54 (9. Jun 2005)

EJB und Massendaten? Das ist Humbug!

Warum denn das ? 
Wenn ich überschaubar viele Entity-Beans und ganauso überschaubar viele Session-Beans habe, sollte doch der Einsatz von EJB nicht verkehrt sein ?


Für Oracle/DB2 spricht einiges, dagegen der Preis und die Monströsität - und die Tatsache, dass ein vernünftiger Admin benötigt wird

Der Preis ist hier kein k.o.-Kriterium, das Projekt ist über mehrere Jahre geplant, einen vernünftigen Admin haben wir.

 Und was willst du mit EJB3, das ist erst übernächstes Jahr interessant?

Lt. Java-Magazin ist mit EJB3 in 2006 zu rechnen und es seien erste Implementierungen bereits verfügbar ???


----------



## Bleiglanz (9. Jun 2005)

ist doch alles Käse mit EJB3: die Flachwichser vom Java-Magazin haben jetzt schon einen Ständer wegen einem Standard, von dem nur Drafts verfügbar sind und der - wenn überhaupt - erst innerhalb der J2EE 1.5 eine Rolle spielen dürfte

Da ändern auch die völlig kindischen Early Access Pakete von JBoss und anderen nichts, weil ja der Standard noch nicht mal auf der Zielgeraden ist, sondern sehr vieles im Diskussionsstadium hängenbleibt.



> EJB und Massendaten? Das ist Humbug!
> Warum denn das ?
> Wenn ich überschaubar viele Entity-Beans und ganauso überschaubar viele Session-Beans habe, sollte doch der Einsatz von EJB nicht verkehrt sein ?


Die frage ist, was du unter Massendaten verstehst? Ich würde sagen, dass weder EJB in der J2EE1.4 Version noch die gängigen O/R Mapper (Hibernate, JDO, später auch EJB3) wirkdlich dafür geeignet sind.

Wenn du 1000 Zeilen in der Datenbank ändern willst, dann reicht da ein einfacher Update Befehl, mit obigen Modellen machst du erst mal einen SELECT, erzeugst dir 1000 Objektinstanzen im Hauptspeicher, änderst jeweils eine Property, und machst dann 1000 Updates nacheinander usw. usf. 

Diese Modelle (EJB, O/R Mapper) können ihre Stärken nur dann ausspielen, wenn es um eine "überschaubar kleine" Menge von "Datenbankzeilen" geht, die man einfach als Java-Objekte manipulieren will.

Kleine Anmerkung am Rande: Ich fand die Versionshysterie immer schon übel ("habe 1.17.3.1 und jetzt ist die 1.17.3.2 herausgekommen, schnell installieren..."); aber was bei EJB3 abläuft ist wirklich ein Witz: jetzt drehen die Leute schon durch, BEVOR es "die neue Version" überhaupt gibt


----------



## paulchen54 (9. Jun 2005)

Hi Bleiglanz,

habe inzwischen Infos, dass div. Banken Ihre Aufgaben mit EJB-DB2 oder EJB-ORACLE bearbeiten, kann man nicht davon ausgehen , dass da auch eine größere Anzahl an DS's behandelt wird ?

Grüße
Rainer.


----------



## Bleiglanz (9. Jun 2005)

natürlich, aber da stecken dann Cluster von Applicationservern dahinter, die die Performance-Schwächen bei EJBs locker ausgleichen können

UND dabei spielt die Transaktionskontrolle (auch zwischen verschiedenen Datenbanken) eine ganz wichtige Rolle, was stark für EJBs spricht

Ist natürlich auch eine Geldfrage, hängt eben davon ab, was man machen will.

Prinzipiell würde ich trotzdem sagen, dass EJB für "Massendaten" (was immer das sein soll) eher nicht optimal sind


----------



## paulchen54 (9. Jun 2005)

Hi Bleiglanz,

hast mir schon geholfen,
werde Deine Hinweise und natürlich die Infos, die ich sonst noch im Netz dazu gefunden habe,  gründlich durchdenken und eine Argumentation für meinen Chief  vorbereiten, das will seeehr gut durchdacht sein (KLR!!!), am Ende wird nicht er bestraft ...

ich muß mich auch noch um die Probleme "IDE" und "Application Server" bemühen, da gibt jeder Hersteller in den Medien "sein Bestes", JBuilder vs. JDeveloper, Server von IBM oder BEA oder ORACLE... ich muss da noch 'ne Menge studieren,

evtl. melde ich mich wieder mit trivialities,

Grüße,
Rainer.


----------



## KSG9|sebastian (10. Jun 2005)

IDE:

IBM Rational Application Developer oder WebSphere Application Developer

Server:

WebSphere AppServer/PortalServer

Wenn das Geld da ist kann ich dir die beiden Teile sehr empfehlen.


----------



## Guest (12. Jun 2005)

Das ist eben das Verrückte an EJB. Solange man nur diese
simplen Beispiele von SUN nimmt, ist alles OK. Spätestens,
wenn es um Batchbetrieb oder größere Datenmengen geht,
greift man dann auf reines JDBC oder einen vernünftigen
OR-Mapper zurück.
Das Problem liegt einfach im Design. Da eine Entity-Bean 
nicht zwangsweise Daten einer einzelnen Tabelle enthalten 
muss, ist die Frage der Persistence nicht eindeutig geklärt
bzw. Batchupdates lassen sich in CMP so gut wie gar nicht
implementieren.
Fazit: Finger weg von EJB, wenn es absehbar ist, dass große 
Datenmengen hin und her geschaufelt werden.


----------



## Bleiglanz (14. Jun 2005)

> Sehr geehrter Herr/Frau Bleiglanz,
> 
> ich erwarte von Ihnen eine öffentliche Entschuldigung!
> 
> ...



Entschuldige mich hiermit in aller Form, nehme meine unflätigen Ausdrücke zurück und bleibe aber inhaltlich bei meinem Vorwurf, dass von EJB3 - für ernsthafte Entwickler -noch keine Rede sein kann.


Am Mittwoch den 25. Mai 2005 in den News beim Java Magazin


> Mittwoch, 25. Mai 2005
> Java-Persistenz: Bei J2EE 5.0 ist das letzte Wort noch nicht gesprochen
> 
> Beim umstrittenen Thema der Persistenz scheint in der Expertengruppe des JSR 244 (J2EE 5.0) noch immer keine Einigkeit zu bestehen. War bislang ein Persistence API als Mischung aus den Konzepten von Hibernate, Oracle TopLink und JDO geplant, könnte es nun sein, dass gesamte Thema vertagt und auf das Release 6.0 der J2EE verschoben wird. Ein Blick auf die Page des JSR lässt folgende Notiz erkennen:
> ...



Aus obigem Artikel (ab 12. Mai am Kiosk)


> Dias Persistenz-API von EJB3.0 wird im Jahr 2006 verabschiedet werden
> ...
> Erste Implementierungen sind bereits verfügbar, diese müssen sich dann natürlich noch der endgültigen Standarddefinition anpassen
> ...
> ...



Einfach lächerlich, wenn man sich anschaut wie lange WebLogic und Websphere für die J2EE1.4 gebraucht haben, dann sind die ersten ernsthaften Appserver für J2EE1.5 erst 2007/2008 zu erwarten

Schön wer sich da heute schon Gedanken machen kann


----------



## KSG9|sebastian (14. Jun 2005)

LOL


----------



## Martin Wessel (15. Jun 2005)

> bleibe aber inhaltlich bei meinem Vorwurf, dass von EJB3 - für ernsthafte Entwickler -noch keine Rede sein kann.



Die vielen Standards haben Java erfolgreich gemacht. Die Abstimmung dauert halt.

Ich finde aber dass der ernsthafte Entwickler sich schon informieren muss was ihn in der Zukunft erwartet.
Wann diese Zukunft dann Wirklichkeit wird, das hängt von sehr vielen Faktoren ab.
Aber er sollte eben einiges aus den neuen Standards lernen. 
Man sollte erkennen dass der Persistenzmechanismus von EJB 1-2 sehr starke Einschränkungen hat.

Der Persistenzstandard in Java wird EJB 3 sein. 
Er vereinigt die Konzepte von verschiedenen ebenfalls erfolgreichen Technologien/Standard: JDO, TopLink, Hibernate. (Die Reiheinfolge und Gewichtung variert hier je nach Herkunft des Autors.)

Übrigens: JDBC ist in dieser List abschichtlich nicht drinne.
JDBC ist der Standard um mit einer relationalen Datenbank zu reden. Nicht mehr, aber auch nicht weniger.




> Einfach lächerlich, wenn man sich anschaut wie lange WebLogic und Websphere für die J2EE1.4 gebraucht haben, dann sind die ersten ernsthaften Appserver für J2EE1.5 erst 2007/2008 zu erwarten



Das Gute an der neuen Persistenz-API von EJB 3.0 ist, dass es eben auch ohne Appserver funktioniert. Man muss also nicht warten.


----------



## paulchen54 (15. Jun 2005)

Danke für die sachliche Bewertung des Dialogs,

Grüße und evtl. see you later,
Rainer.


----------



## Bleiglanz (16. Jun 2005)

> Man sollte erkennen dass der Persistenzmechanismus von EJB 1-2 sehr starke Einschränkungen hat.


Das stimmt natürlich, dafür haben sie im hier und heute teilweise schon recht viele Vorteile

Wenn ich heute ein Projekt am laufen habe - und "wegen der EJB3 Perspektive" auf JDO setze, dann ist das eben eine Fehlentscheidung, da die Migration auf EJB3 so oder so nicht glatt gehen wird - so wars in der IT-Welt immer und so wirds immer sein. 

Welche Persistenzengine man einsetzt sollte auf Grund ganz anderer Kriterien entschieden werden.

Ich würde - wenn die Rahmenbedingungen es erlauben - heute tatsächlich bei CMP2.1 bleiben, denn das wird mit Sicherheit in den nächsten Appservern unterstützt

Solange die einfachsten Dinge in der EJB3-Spec fehlen (welche Annotationen GENAU, wie wird das Mapping GENAU aussehen usw.) kann man einfach überhaupt NICHTS damit anfangen



> Der Persistenzstandard in Java wird EJB 3 sein.
> Er vereinigt die Konzepte von verschiedenen ebenfalls erfolgreichen Technologien/Standard: JDO, TopLink, Hibernate. (Die Reiheinfolge und Gewichtung variert hier je nach Herkunft des Autors.)


Erinnert ein bischen an die Bäckerblume: "Die besten philosophischen Erkenntnisse aus 2000 Jahren" 

Man nehme alles Gute und Schöne 
werfe alles in einen Topf
umrühren
fertig

Das ist noch keine Garantie, dass das Endprodukt wirklich soooo unglaublich gut sein wird wie jetzt alle glauben.

Zumal Toplink/JDO/Hibernate nicht wirklich viel gemeinsam haben, aber "alles POJO" scheint ja den meisten als Argument zu genügen.



> Das Gute an der neuen Persistenz-API von EJB 3.0 ist, dass es eben auch ohne Appserver funktioniert. Man muss also nicht warten.



doch, auf den Standard sebst auf jeden Fall

und die Perpektive, eine EJB3 Engine in einen J2EE1.4 Server zu packen ist ja wohl auch gruselig


----------



## paulchen54 (16. Jun 2005)

Hi, Herr Wessel und Bleiglanz ,

so gefällt mir der Disput.
Ihr liefert beide bedenkenswerte Argumente,
wenn dann  noch die Meinungen aus unserer Truppe dazukommen, wird die Entscheidung bzgl. der AusgangsFrage (s.oben) nicht realitätsfremd und vom Wunsche getragen  beantwortet werden...

Viele Grüße und Danke

Rainer.


----------



## Martin Wessel (17. Jun 2005)

Hallo,

ich möchte nun nochmal alles aus meiner Sicht zusammenfassen.

Gruss


*Themenbereich Mapping*


_Frage: Einsatz von EJB 2 mit Massendaten?_

Generell eher nicht. 
A1: EntityBeans sind Komponenten deren Erzeugung viel Ressourcen kostet.
A2: Der Test von EntityBeans ist relativ aufwendig.

_Frage: Einsatz von CMP mit EJB 2?_

Nicht mehr ganz neu anfangen.
A1: ... 
A3: Bindung an den AppServer
A4: Bindung der Datenhaltung an EJB Architektur.

Bestehende Anwendungen aber noch erweitern.
- Portierung wird gehen. Das liegt schon im Interesse jedes AppServer Herstellers.
Führt aber auch wieder zu A3.

_Frage: Einführung des EJB 3 Persistenz API?_

Hängt davon ab, wann man mit dem System in produktiven Betrieb sein muss.

Die Entwicklung solte sich die Konzepte von EJB 3 auf jeden fall anschauen.

A5: Man muss neue Technologien kennen, auch wenn man noch mit älteren Technologien arbeitet.



Aus A1, A2, A3 folgere ich ->  Einsatz von POJO und SessionBeans

zu A1: POJOs sind nun keine Komponenten mehr.
zu A2: Der Test der POJOs ist einfacher
zu A3: Keine Bindung der POJOs an den Applikationsserver

Nehme ich noch A4 hinzu folgere ich -> Einsatz von POJO generell

zu A4: Ich bin jetzt von der Java Basistechnologie unabhängig.
       Einsatz in J2EE, J2SE möglich. 
       Bei J2ME gelten besondere Rahmenbedingungen zu Größe der Umgebung, 
       ist aber auch möglich.

_Frage: Massendatenverarbeitung mit POJO?_

Für Nein spricht:
A6: Die Massendatenverarbeitung ist auch gleichzeitig absolut zeitkritisch
A7: Auch die Erzeugung von POJOs ist aufwendig
A8: StoredProcedures sind viel schneller

Für Ja spricht:
A9: Werden die Daten in der Datenbank geändert, müssen auch die POJOs aktualisiert werden.
    Dieser Aufwand kann auch erheblich sein.
A10: Die POJOs für die Massendatenverarbeitung sind nicht komplex und der Mapper kann das
     Laden der POJOs optimieren, deshalb greift A7 nicht voll. 

_Frage: Ist EJB 3.0 wirklich der vollendete Java persistenz Standard?_

Nein.
Es wurde das Beste von allen vorhandenen Technologien genommen.
Alle wollen am Ende nur das eine: "Mache möglichst einfach Java Objekte persistent".
Genau damit sind auch alle Technologien angefangen. Daraus einen Standard 
für die gesamte Java-Gemeinde durchzusetzen ist mit JDO leider nicht gelungen.
Aber am Ende hat man sich dann ja doch wieder auf einen Standard (EJB 3) geeiningt.

Einige Aspekte sind im Moment noch nicht festgelegt. Genau da ist noch das Potential 
die beste Lösung zu erhalten. Der Standard ist noch beweglich. 
Aber auch bei EJB 3 wird irgendwann mal der Zeitpunkt kommen wo man feststellt, dass
es eigentlich bessere Lösungen geben würde. 
Und genau diese muss man dann einbauen oder einen neuen Standard festlegen.


*Themenbereich Datenbank*

Hierbei gibt es sehr viele Fragen die jeder Datenbankbetreiber beantworten muss.

1) Wichtigtkeit der Daten
1.1) Wie wichtig sind die Daten die gehalten werden müssen?
1.1.1) Was passiert beim Verlust von Teilen der Daten?
1.1.2) Was passiert beim Totalverlust der Daten?
1.2) Was passiert wenn auf die Daten für eine bestimmte Zeit nicht zugegriffen werden kann?
1.3) Wie reagiert das Gesamtsystem wenn falsche Daten geliefert werden?
Hört sich komisch an. Aber jeder Datenbestand hat Fehler und unvollständige Daten.


2) Menge der Daten
2.1) Welche Datenmenge muss gehalten werden?
2.2) Wie schnell muss auf die Daten zugegriffen werden können?
2.2.1) Müssen alle Daten gleich schnell zugreifbar sein?
2.3) Vieviele Zugriffe auf die Daten gibt es pro Zeiteinheit?


Aus diesen und noch vielen anderen Fragen ergeben sich dann 
technische Anforderungen an das mögliche Datenhaltungssystem.

- Datenvolumen
- Verfügbarkeit
- Performance

Daraus ergibt sich dann die Art des Datenhaltungssystems:
- Dateisystem
- Datenbank (Host, RDBMS, ODBMS)

Auch die Kosten darf man natürlich nicht vergessen:

* Anschaffungskosten
 Software
 - Gundpakete
 - Zusatzpakete
 Hardware
 Personal

* Entwicklungskosten
 Software
 Hardware
 Personal

* Betriebskosten
 Software
 Hardware
 Personal

* Rückstellungen für die Wiederherstellung der Datenhaltung
 Software
 Hardware
 Personal

* Kosten für die Migration auf ein neues System (Denn nichts hält ewig)
 Software
 Hardware
 Personal


Ich habe die Kostenliste absichtlich so lang gemacht. Denn die vielen existierenden Posten
werden gerne vergessen wenn es um die Frage open-source oder Kommerzielle Software geht.


Hierzu noch eine Analogie: (Mit Autos, weil das immer gut ankommt.)

Ich bringe mein 5 Jahre altes Auto regelmäßig zu einem Vertragshändler.
Ich verlasse mich darauf, daß dort mein Auto fachkundig und nach den 
neuesten Erkenntnissen des Fahrzeugherstellers geprüft und gewartet wird.

Ich habe nicht die Zeit (und die Lust) mir eine andere Werkstatt zu suchen
die mein Auto gleich gut pflegt und wartet.
Denn ich will das Auto fahren von A (da wo ich bin) nach B (da wo ich hin will)
und nicht von Werkstatt zu Werkstatt.

Ich mache hier also eine Kosten/Nutzenrechnung unter den Rahmenbedingungen,
die ich mir selber, ganz persönlich aufgestellt habe. 
Ich darf jetzt auch nicht meckern: "Die Werkstatt ist aber zu teuter?" (Das gilt nicht)
Ich habe mir das Auto auch nicht als Bausatz schicken lassen, obwohl das vielleicht billiger ist.


Und genau so eine Kosten/Nutzenrechnung muss eben auch der Betreiber einer
Datenhaltung machen und diese auch dokumentieren.


----------



## paulchen54 (20. Jun 2005)

Hallo Herr Wessel,

vielen Dank für Ihre komplexen Ausführungen, da gibt es für uns noch eine Menge mehr zu bedenken,
als mir anfangs klar war.
Unsere  Entscheidung werden wir also nicht übers Knie brechen, hier müssen alle Beteiligten gehört werden.
Wir werden die "kollekive  Weisheit"   einschließlich Ihrer brauchen und dann den besten Extrakt daraus ziehen.

Für Ihre Aufmerksamkeit bzgl. dieses Themas bedanke ich mich ganz besonders und verbleibe
mit besten Grüßen, evtl. bis später,

Rainer.


----------



## Bleiglanz (21. Jun 2005)

paulchen54 hat gesagt.:
			
		

> Unsere  Entscheidung werden wir also nicht übers Knie brechen, hier müssen alle Beteiligten gehört werden.
> Rainer.



Schwurbel


Schwurbel


Am besten auf EJB4 warten


----------



## Guest (21. Jun 2005)

Bleiglanz hat gesagt.:
			
		

> paulchen54 hat gesagt.:
> 
> 
> 
> ...



Hi Bleiglanz,

stehe sicherlich nicht schon so tief in  der Gesamtsituation "EJB3"  wie Du, wie denn auch, bin somit wegen der neuen Aufgabe auf Input von Leuten wie Dir auch angewiesen, deshalb bitte ich um Nachsicht wegen meiner für Dich so wirken müssende "Naivität", aber gerade deswegen gehe ich unvoreingenommen an die Sache...
....bleib mir trotzdem gewogen !!!


Viele Grüße,

Rainer.


----------



## paulchen54 (21. Jun 2005)

Anonymous hat gesagt.:
			
		

> Bleiglanz hat gesagt.:
> 
> 
> 
> ...


----------



## Bleiglanz (22. Jun 2005)

ich plädiere ja nur für eine gewisse Lockerheit!

solange die EJB3 noch im DRAFT Stadium ist, braucht man meiner Meinung nach noch keinen Gedanken daran verschwenden

es sei denn man arbeitet bei der "Furture Development AG", die heute schon viel Geld für das Nachdenken über Implementierungstechniken im Jahr 2008 ausgibt


----------



## paulchen54 (22. Jun 2005)

Bleiglanz hat gesagt.:
			
		

> ich plädiere ja nur für eine gewisse Lockerheit!
> 
> solange die EJB3 noch im DRAFT Stadium ist, braucht man meiner Meinung nach noch keinen Gedanken daran verschwenden
> 
> es sei denn man arbeitet bei der "Furture Development AG", die heute schon viel Geld für das Nachdenken über Implementierungstechniken im Jahr 2008 ausgibt



Hi Bleiglanz,

ich arbeite natürlich nicht bei der "Furture Development AG", 

wir beginnen unser erstes Projekt mit EJB's und wollen vorher halt Input aus Erfahrungen holen,
nicht nur den EJB-Standard betreffend, sondern angefangen vom Designer über den AppServer bis hin zur dazu am besten vorbereiteten DB, dann natürlich die Kosten überschlagen, wieviele Lizenzen kosten wieviel...
Wir haben einen längeren Entwicklungszeitraum geplant, deswegen auch die Denke über EJB3 usw.

Also, es ist ein komplexes Problem und ich bin über jede ernstgemeinte Info, gern auch konträr zum mainstream, dankbar...

In diesem Sinne,
bis später,

Grüße,

Rainer.


----------

