The latest issue of the Object Watch newsletter contained an article in entitled Living on the right side of the counter (Java Data Objects). in which Roger Sessions asserts that Sun probably might want to deprecate EJB due to "The technical problems with EJB are well known, and include poor performance, machine affinity, and potential database corruption. But Java Data Objects (JDO) seems to solve none of these problems, and adds to them what I think is the worst implementation of a Distrust Divide in the industry."
In a TheServerSide exclusive, Craig Russell (Java Data Objects Specification Lead) responds to Roger's comments:
The whole middle tier architecture of J2EE is apparently lost on Roger Sessions. J2EE is a component architecture, wherein some components live in the middle tier and some components live in the client tier. There is a strong architectural barrier between the client side and server side components.
His "latte counter" example is too weak to adequately describe the security aspects of a middle tier server. Just as Z would not allow Roger to wander around back to scrounge for water, no reputable server would allow a client to wander around back to access server implementation objects like JDBC Connections, JDO PersistenceManagers, or JCA TransactionManagers.
The J2EE architecture identifies components that allow client access via a remote interface, and enforces security barriers around them. The remote components are called Enterprise Java Beans, and they come in several different flavors.
J2EE enforces a security contract on all communications between client and server components. This makes it impossible for the client to inadvertently or deliberately obtain access to any component that is supposed to be protected. Among the server components that deliberately do not have a remote interface, and therefore cannot be accidentally exposed to clients, are JDBC Connections and JDO PersistenceManagers.
JDO was designed as a local interface, with no inbuilt remote ability, no role-based security, and no inbuilt multi-address-space communications. All you get with JDO is transparent persistence for your Java objects, or transparent representation of your database objects as Java objects (depending on whether you look at the issue from the Java or the database perspective). So it is completely disingenuous for Roger to be "shocked, shocked" that JDO allows control over transactions by trusted components within the server.
Roger misunderstands the role JDO PersistenceManager and JDO instances play in this architecture. He claims that "if you want to give somebody the ability to retrieve an order, you must also give them access to the precious system caches." The "somebody" in this case is a trusted system component, not the client.
The point of components like JDO is not to expose them to clients, as Roger implies by his comments that "one could build business logic components ... that hide the details of Java Data Objects". The point of JDO is that business components need persistent storage of business objects, and what clients care about is the interface to the business components.
As a trivial example, a JDO instance might be the inventory item associated with an order line item from my order with an online bookstore. As the client, I really don't care to know anything at all about how my bookstore is going to manage its inventory; all I care about is whether they will deliver what I ordered, on time, at the price I agreed to pay. Roger calls this "hiding details ... no more satisfying or effective than hiding Entity Beans"; I call it common sense.
It is unfortunate that Roger Sessions has so completely misunderstood the architecture of J2EE and Java Data Objects, and worse, makes no attempt to understand the technology before spouting off.
I take full responsibility for the views expressed herein; they are my own, and not necessarily those of the good people at Sun who automatically deposit large sums into my personal account on a regular basis.