Ein paar zentrale Aussagen von "Bitter EJB"
Session State: falls Session State wirklich notwendig ist, kann er auf drei Arten
gespeichert werden (S.144-149):
- auf dem Client (als Cookie oder per URL rewriting). Der State wird
dann bei jedem remote Methodenaufruf als Parameter mitgegeben
- auf dem WebServer als HttpSession
- als Statefull Session Bean - das einige Vorteile gegenüber der HttpSession
hat
"Draw a clear line between an object-oriented local domain model (functionality reuseable across multiple use cases) and a procedural remote service layer" (S.64) Geschrieben vor dem SOA-Hype.
"In many cases, the number of network round-trips determines application performance success or failure." Also:
 | kein remote Zugriff auf Entity Beans (z.B. nur Local
Interfaces mit CMR), nur
Zugriff über Session Facade, die ein DTO liefert (S.219) Etwas Verschwendung ist auch bei Local Interfaces noch dabei, weil Transaction- und Security-Container-Code auch dabei ausgeführt wird. (S.47, siehe auch unten das Zitat von S.276) Begriff "dependant objects" der J2EE Patterns ist überholt, sollte sogar in EJB-Spec. einfliessen, gestrichen zugunsten von Local Interfaces. |
BMP oder CMP? in Spec 1.x, eher BMP, in Spec 2.x überwiegen die Vorteile von CMP einschliesslich CMR (relationships)
Anti-Pattern Application Joins: relationship ist nicht als CMR
definiert, sondern wird im Application Code gehandelt.
Anti-Pattern Application Filter: eine Menge von Objekten wird geladen und
dann in Java conditional code zur Auswahl der Objekte, insbesondere in einer
Schleife. Besser: die Datenbank ist für Filterung und Join zuständig.
Anti Pattern Rusty Keys: der Primärschlüssel soll kurz sein, z.B. 32 oder 64 bit, kein String, kein GUID
EJB – Reentrancy (S. 238): die Spec verbietet ja zirkuläre Aufrufe zwischen EJBs ( A ruft B, welches wiederum A ruft). Das kann erlaubt werden, wenn A und B in derselben JVM laufen, erzwungen mit LocalInterfaces, no remote Interfaces.
Kapitel 8 vergleicht drei Alternativen für die Persistenz:
- EJB CMP
- JDBC (z.B. für reporting, oder GUIs, die lediglich die Datenbank
darstellen)
- OO persistence frameworks wie z.B. JDO oder TopLink
Die Auswahl der Persistenz-Lösung sollte folgenden Kriterien berücksichtigen:
| CMP | JDBC | JDO / pers. framew. | |
| J2EE integration - security | yes | no | no |
| J2EE integration - JTA | yes | yes | yes |
| J2EE integration - JCA | n/a | yes | yes |
| Simplicity | very difficult to learn with many pitfalls | basic usage is well understood for traditional relational problems, complex OO can get unbearably complex | basic and complex OO models are equally simple to use. |
| Java language alignment | Many Java language features, such as inheritance and pass- by- reference, are not supported or are treated differently | No. SQL is a relational language. Data in tabular form, only primitive data types. | yes |
| Deployment flexibility | Requires an EJB container Can be used with many types of data stores |
No container required | No container required. Can be used with RDBMS and OODBMS |
| Query Language | EJBQL (no dynamic queries) | SQL | JDOQL |
Das grundsätzliche Problem mit Entity Beans bringt er folgendermaßen auf den
Punkt:
"The entity bean specification provides four major services: declarative and
distributed transactions, declarative security, scalability and fail-over
support, and data persistence. When you look closely, you'll notice a
significant mismatch between the way persistence is used and the way the other
three services are typically used - the latter are fine, and the former is
coarse." (S.276)