|
|
Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs
Page 4 of 6
In the past, most developers turned to the roll-your-own approach for projects that use relational databases for persistent storage. The two technologies used by this approach, JDBC, and, to a lesser degree, SQLJ, require a sound knowledge of the relational SQL technology and, of course, provide no transparency. While this approach works fine for projects with a relatively small object model, it can quickly lead to hard-to-maintain code because the mapping tends to be implicit/hardcoded in multiple locations in the source code.
Several companies have attempted to develop in-house proprietary persistence layers. Because such a project is a nontrivial, expensive task, only large and deep-pocketed organizations can bank on this approach. But why should even those with deep pockets reinvent the wheel?
Proprietary persistence layer solutions divide into two groups: object-relational (O/R) mapping tools and object databases.
Object-relational mapping tools
O/R tools have been around for quite some time, are quite mature, and are available from many vendors. The leading products
are TopLink from WebGain, CocoBase by Thought, Inc., and the Visual Business Sight Framework (VBSF) by ObjectMatter.
Though most O/R mapping products offer consistent, simple APIs, generally, some vendors could improve on their simplicity. Also, most could offer less intrusion, though VBSF does a good job in this respect. While all these products provide reasonable transparency, albeit narrowed down to relational backends, they all have proprietary APIs. Nothing is wrong with proprietary implementations, as long as they conform to an established multivendor interface. That is not the case for the products mentioned here. In addition, mapping techniques vary greatly from vendor to vendor, so porting between vendors would probably be a significant issue. And finally, some proprietary O/R mapping tools have prohibitive deployment licensing costs in addition to development licenses.
These tools are mature and well supported, so despite the objections above and assuming the trade-offs are understood and accepted, it might still make sense to use these tools in the near future, until existing multivendor and open source standards mature. In the long term, however, these vendors are on a collision course with the upcoming standard persistence layer implementations and, to survive, they might need to provide unique features.
Object databases
The object database situation proves worse than the situation with O/R mapping tools. If you are a middleware application
architect using these tools, you and the project are locked into a single mapping tool vendor. Moreover, you cannot replace
the whole data storage system easily. However, most major ODBMS vendors have pledged to support the upcoming JDO standard,
so this situation should improve.
Many projects use EJB CMP detailed by the J2EE specification and delivered by EJB container vendors. Limited and simplistic, the EJB 1.1 CMP specification failed to cover more advanced relationships. The new spec, CMP 2.0, is much improved; however, entity beans introduce significant overhead in terms of code maintenance and performance.