This week Sybase released the latest version (v12.5) its Adaptive Server Enterprise database. This new version features direct XML persistence (as opposed to storing as BLOBS), an entity bean container that runs in the database, and the integration of the file system with the database.

"
Sybase decided to run EJBs within the database, instead of constantly communicating with a separate applications server, to boost performance. Before, "the communication was done via the JDBC interface, and you had to make multiple queries to implement [or run] a single EJB method, which is inefficient," Traubitz said. By storing and activating beans in the database itself, and using internal shared memory instead of a network link for communications, processing speed can jump five to 10 times, especially for complex transactions.
"

Oracle attempted this approach in the past and it was supposed to kick-ass (on paper anyway). Does anyone have any experience with entity bean-database collocation?

Read Latest Sybase Release Aimed at Web Apps .
Read Sybases Press Release: Sybase Unveils Adaptive Server Enterprise 12.5, The Data Management System For An Intelligent Transition To e-Business.

Ever since the introduction of entity beans, I have wondered why (relational) database vendors didn't do this (and why application server vendors did (to be compliant, I guess)).

It seems that as EJB development matures, people are using different types of techniques to represent/access persistent data in an object-oriented fashion - DAO, JDO, Fast-Lane Reader etc. - to avoid the obvious communication drawbacks of entity beans in an out-of-database-process environment.

Therefore, to me at least, it seems logical to move entity beans to the database - much like a logical progression from stored procedures or a standardized object-relational database extension - and maybe to go as far as changing the EJB spec to not require entity beans support (not the container anyway) in a J2EE application server and to put that requirement on the database instead, basically generating a need for "J2EE certification" of database products, stirring the database market a little in the process.

And no, I am not in any way affiliated (or the opposite) with Sybase. ;-)

Cheers
/Par

"Ever since the introduction of entity beans, I have wondered why (relational) database vendors didn't do this (and why application server vendors did (to be compliant, I guess)). "

Doesn't that imply the ejb is on the same machine as the database??? WHy would you want to put that kind of constraint in your system? EJB's should be able to live anywhere, regardless of what kind of dbms you're running.

Maybe I took my argument a bit too far, but then again, that's the best way to start a discussion. ;-)

My main point is that it is obvious that performance-wise entity beans should reside inside the database engine (machine). This does not imply however, that entity beans (in theory) have to be deployed in the database (or even be executed there for simpler cases), which is probably what Floyd Marinescu is referring to in his question about experience with collocation (Floyd, please correct me if I'm wrong).

I agree that EJB:s should be able to live anywhere, regardless of your DBMS, but also regardless of your J2EE compliant app server. To achieve this goal while giving in to real-world requirements such as response-time and scalability, you would probably want EJB:s to be able to move from container to container at runtime to be executed where they have an optimal set of resources close at hand.

So, what I'm really getting at is that EJB:s should be transparently collocatable and not just between app servers from different vendors but also between app servers and databases. Whether this collocation should be on a class-by-class or JAR-basis I don't know. Maybe there is a need for a new concept of (declaratively configurable) "collocation units" to achieve this with ultimate flexibility...

Regardless, I believe that this requires not only that database vendors provide entity bean containers, but also that interoperability between containers from different vendors is made possible through standardization of the contaier to app server (and container to container) contracts which are mentioned as being white areas in the EJB spec.

Anyone knows if there is being work done in these areas, or if there exists such technologies/mechanisms already?


Have a nice weekend
/Par

------------------------
Par Eklund
MiddleMan Consulting AB
------------------------

How does it scale (out) though?
Sybase ASE only supports 4-way clustering (if I remember correctly). Scaling a database OUT is much tougher than scaling an APP server. That's one of the reasons why APP server lives.

That's true, but then again, isn't that true with all persistent stores, regardless of them being relational or object-oriented?

Take for example the issue of how to scale (out) entity beans in a clustered application server environment. Should you have a) one (or more) in-memory entity bean instance(s) on each application server instance in the cluster and load-balance between them through synchronization of the instances either between the application server instances through replication or through database synchronization, or b) one instance on one application server instance and direct all calls to that instance?

Either way, you have to synchronize with the underlying persistent data, which is probably handled best by a database server, having valid information at hand through shared-memory mechanisms rather than sockets. But then again, scaling out a database server will eventually require socket communication to achieve synchronization between machines...

Anyone knows how/if database engines overcomes "scale-out issues" in general, the EJB discussion taken aside?

Cheers
/Par

------------------------
Par Eklund
MiddleMan Consulting AB
------------------------

What the implication of this enhancement regarding J2EE deployment? Looks like they allow only EB to live in the DB server, while everything else live on the app server. This pretty much makes it impossible to use ear files to deploy enterprise appplications.

Does anyone else besides me sees all this entity-EJBs thing
being THE final way that will lead to the standardized OO databases that we were waiting for 10+ years?

I am willing to bet that this is Sun's original intent with EJB and
long term strategy: to make OO databases popular as they did
with OO programming.

Now RDBMS vendors integrate EJB in the db server, then EJB
becomes the db server...

Cristi Opris

"Does anyone else besides me sees all this entity-EJBs thing
being THE final way that will lead to the standardized OO databases that we were waiting for 10+ years? "

Umm, no.