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.
