>Does someone have a compelling argument as to why EJB *doesn't* support
>layered architecture?
It is not that that it does not support a layered architecture, it is that
with Entity Beans it supports one specific type of layered architecture,
namely the one with a relational database in the back. This is of course
one very common and useful architecture, but there are also a bunch of
scenarios when they IMHO are not:
Let's say you have a legacy banking system somewhere in a dungeon
complete with deterministic, batch oriented programs to connect to.
Add to that a gate keeper - sorry - system administrator for
that system who tells you that "batch on-demand is expensive", "That's
a lot of CPU-time" and other expressions not so often heard in the Java
community. The task is to wrap it all in a nice layered arch. so that
this system can be accessed from, umh ... let's say the internet ;-)
One nice idea would be to wrap this as an object that has caching,
some sort of transactional approach towards the batch-process ...
something like a Entity Bean on steroids, able to connect to the legacy
system as a resource through the J2EE server.
This bean would not have a primary key since the legacy system does
not have one, the cache would be kept all day until batch-time, really
not something where the current Entity Bean interface is suitable.
It's not that Entity Beans are all that bad, it is just that I do
not find them good enough at the moment. I hope that in the future
the current Entity Beans will be named "Relational Entity Beans", a
subset of the more general "Entity Beans" which has a lot of pluggable
implementations.
/Marcus
Marcus Ahnve
Sun Java Center
Sweden
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
