Jae,
CMP & CMR are designed to meet the needs of fine-grained financial IT apps, and my
guess is that the needs of a CMS like Nukes wouldn't push the envelope. How fine
grained do you want?
JBoss surely handles constraints like Check (column type), NotNull, Primary Key,
ForeignKey/Reference; I'd have to dig a bit to say for sure about the Unique
constraint (no duplicates in a column) & Index.
But, personally, my hunch is that in the end it won't be a problem no matter what
granularity of constraint is required, and here's why:
Database constraints are about enforcing basic business rules; and EJBs are all about
business logic/rules. We're talking constraints because we care about data integrity
and referential integrity...and the key insight is that the constraints that really
matter are the ones in the App Server, rather than the Database Server.
Business logic lives in EJB. EJB knows more about the data than the DB ever
will. Java's type system is far more sophisticated than the SQL type system; as a
strongly typed language, Java can impose far finer constraints.
With CMP we can use the EJB constainer to take care of the integrity of the
data. With CMR we can use the EJB container to take care of the integrity of the
relationships.
The new way to think about things is that the center of the universe is J2EE
(JBoss), not the persistent store (RDBMS). The DB really should be seen increasingly
as just a place to persist the data when it's passive; what really matters is when the
data is active as objects living in the cache.
OK, it's possible to enforce rules through "application" or "database"...
A common misconception is that "since tables can be accessed via DB utilities and
other apps (bypassing the application checks), database-level enforcement via
constraints provides a better solution."
Well, IMHO, JBoss Nukes is a "greenfield"; no other app has access to the DB.
This is no legacy integration deal; it's a fresh start and we can do it the right way.
Nukes should own the DB; 100% of all DB access should go thru JBoss (even tho that
might look like a distributed cluster of numerous JBoss instances in some ISP farm a
few years from now).
But even if Nukes didn't own the database, and has to share it with other
apps: the better practice is to enforce rules through infrastructural contracts.
J2EE provides a whole slew of infrastructural contracts, from the low levels
of JCA up to the high levels of EJB CMR.
(look at JCA to understand about system level contracts (Connection,
Transaction, Security); look at org.jboss.ejb.plugins.cmp.jdbc.JDBCTypeComplexProperty
to see datatype mappings; look at EJB 2.0 CMP & CMR for the higher level contracts
regarding data integrity & referential integrity.)
anonymous wrote : I like the way Marc Fleury expressed it in his BLUE paper
(ÃÂWhy I Love EJBsÃÂ):
| anonymous wrote : 'Ok, so you understand that caches in memory,
alongside with your other logic, are the simplest way to build fast J2EE applications.
Now the natural question is ÃÂhow do we put data in these cachesÃÂ. Well, today
there is very little need to use your own database access code. This is another nail
in the coffin of the retrograde servlet to jdbc designs. The new persistence
framework, specified in EJB 2.0 is so powerful it should really be a standalone spec.
We will talk more about that in the RED paper. It is that silver bullet we were
looking for in serverside persistence. For those of you who donÃÂt know what it is,
CMP stands for ÃÂContainer Managed PersistenceÃÂ and this is the age-old promise
of automated mapping from the object domain to the database realm. To automate the
persistence is simple in simple cases and quite complex for everything else. The first
version of the persistence, the 1.1 version, was seriously lacking in various critical
aspects. The 2.0 version is however a blockbuster. It comes with Container Managed
Relationships, which let the container take care of the integrity of the
relationships. The addition of the abstract getters and setters offers another great
feature. It is the responsibility of the container to implement these. The nice part
is that the container can now follow with great granularity what data you access and
what data you write, thereby tracking most of the information it needs to optimize
your data access patterns. What this means is that a lot of the optimizations we
needed to do by hand in the 1.1 version are now automatically taken care of for you in
the container. If you are only reading a bean, we know it, if you are not modifying
all the fields we know it, if you are going to load certain data sets for certain
methods, we know it since you can give hints to the persistence engine and help it
optimize the loading and storing time. One of the interesting things we are seeing
with CMP2.0 is that everyone is dropping BMP for CMP. BMP is a fancy word for ÃÂJDBC
by handÃÂ and was the old way of letting you code your data access layer methods in
the body of an EJB. Today, almost no-one uses BMP anymore as the power of CMP is
proven and working.'
Indeed, "Cache is King", and if your contracts with the world outside the cache have
integrity, then your cache can handle the rest.
It feels like every month JBoss is making progress toward achieving a truly
transparent object persistence framework (which is a big reason why i've been tracking
(and applauding) that progress since '99).... it may not be at the holy grail quite
yet, but then again, what do you really need in order to support the requirements of
Nukes?
My starting guess was that JBoss already had all the support that Nukes would need,
which is why I've been scratching my head trying to figure out why there's all this
DDL cruft... trying to figure out where's the hole in my CMP knowledge...
So thanks, Julien, for giving us the scoop:
anonymous wrote :
| Unfortunately create/remove table were not good enough when we started the
project.
|
| We need index on some fields and at this moment it was not possible to add index
constraint on the cmp fields (now it is possible)
My hunch about JBoss/CMP having everything necessary was right..... perhaps a bit
optimistic for when the project was begun... but quite reasonable now...
So that gives me some encouragement to put in a plug for the benefits of doing Nukes
the right way --- (all interaction with DB via pure CMP2.0; data checking via code in
entity EJBs plus what CMP2.0 does automatically for us):
Doing it right will reduce the complexity of intalling Nukes at least 3:1 ...
which means boosting the installation success rate and applying more eyeballs to
finding real application bugs.
|
| Doing it right will reduce the number of "how do i get started" forum posts,
less time for the active coders to waste answering the same questions over and over on
the forums.... increase the number of active users, increase the number of happy
users, and increase the number of contributors.
|
| Doing it right will make it much easier and cleaner not only to install, but
also uninstall, leading to more willingness to upgrade and check new CVS snapshots
more frequently.
|
| Doing it right will give us nice side effects of providing the hooks needed
for batch construction, under-the-hood maintenance, plus dump & reload of the entire
Nukes database to pure XML. (I'll volunteer to help with writing the xml dump/(re)load
utility.)
|
| Doing it right will show off what JBoss has to offer, be a real good
reference for people doing apps on top of JBoss, and be a good proof-of-concept for
what Marc wrote in his BLUE paper.
And I'll even go so far as to make myself unpopular with everyone wanting instant
gratification: I vote for delaying a general release until the database-specific ddl
stuff is removed from setup.xml, and replaced with initialization data embedded in
regular old XML elements, and the DB tables are all created thru CMP. For the longterm
good of the Nukes project, it would be good to have a schema that we can be
backwards-compatible with. Risk of a future "gotcha" will be reduced when we know that
we are indeed generating, via CMP, a schema we can live with for a good long while.
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3822274#3822274
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3822274
-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id56&alloc_id438&op=click
_______________________________________________
JBoss-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-user
