Thought inc.

The Dynamic O/R Mapping Company
  case studies
  tech support


Why Dynamic, Repository Based Mapping from CocoBase is the Key to Success for Database Access when Developing, Deploying and Maintaining your EJB Application.

CocoBase® Enterprise O/R Whitepaper


THOUGHT Inc. directly addresses the Data Access needs of the Enterprise Java Beans (EJB) platform with the CocoBase Enterprise Object to Relational Mapping Middleware. This provides a key tool for the Enterprise Application market as it retools to Enterprise Java Beans. Corporate spending on the EJB solution is expected to be over a billion dollars in the coming years with heavy increases each year. The critical nature of these applications requires mature tool-sets that deliver solutions today with future development to meet tomorrow's needs.

THOUGHT Inc.'s CocoBase supports EJB development, today, with it's dynamic repository based Object to Relational Mapping Tool delivering Container Managed Persistence and Bean Managed Persistence. Not only is CocoBase the only O/R tool optimized for EJB, but it is the oldest and most mature O/R tool available in Java. THOUGHT Inc. delivered the first O/R for Java, and now it has delivered the first O/R optimized for the J2EE EJB platform.

The EJB platform is a component based architecture that allows engineers to share and reuse their work in a standard and portable way. This means that Enterprise Java Beans require that data access be done in a standard and portable way as well. The CocoBase Tool achieves this, as it bridges the impedance mismatch from an Object Centric Java language to a Non-Object Centric Relational database structure. The CocoBase Tools allow the engineer to optimize both the object and relational model for best performance of the application, instead of tightly binding the structures the way many entry level O/R solutions do. Because CocoBase Enterprise O/R utilizes dynamic repository based mapping it can reduce development, deployment and maintenance time by up to 80%.

Typical Problems With Writing EJBs

What are the usual choices available for delivering data access by developers using Enterprise Java Beans? There are two typical directions to take;

1) Having the engineer hand code all of the database access code directly into the Entity Beans with embedded JDBC and SQL commands, and/or

2) Using a tool that does this for them such as a built in CMP generator which does not respond to or manage the myriad of items needed for enterprise level data. Such as the ability to provide code that can be quickly written, edited and maintained, that can scale to large numbers of users and retain high performance at all times.

Neither of those typical solutions accomplish the task without the aid of an O/R tool such as CocoBase.

The typical hand code scenario means that;

1. Up to 80% of the cost of the EJB application is in hand crafting database access in the objects.

2. Any changes that need to occur to the objects and data as the project progresses have to be done by hand, recompiled, regenerated and re-deployed.

3. Any mistakes to the EJB code or the JDBC driver code can be very costly with the average EJB objects including several thousand lines of code.

4. With each EJB hand crafted for the specific database, the ability to share this EJB with other databases or combinations of databases is limited and in almost all cases non-existent.

Beyond the immediate costs of labor and maintenance for hand coded access in EJB's, there is also the future considerations of scaling and performance of the company's application once it is deployed. Unfortunately, the object world of Java, introduces a whole new set of problems to solve in order to create scalable and high performance systems. The steps required to optimize an EJB aren't intuitive to many developers, and development organizations have a lot to gain from the experience of the CocoBase product's automatically optimized template based code generation.

Hand coding of objects can create many costly problems for the performance of an application, such as;

1. As the objects become larger with additional attributes, the pipe through which it must travel has to be larger and the CPU must be able to handle more interrupts. This means that the more complex your data, the larger the object, and the more round trips for attribute I/O. Unless you can afford unlimited upgrades in the size of the infrastructure, this becomes an expensive problem as more people try to access the data through the EJB application. CocoBase templates generate EJBs that have built in optimizations that developers can take advantage of that reduces network utilization, and improves overall application performance.

2. The underlying access is a function of the optimization of the objects themselves. With fat hand coded objects, the performance tends to decrease due to increased memory usage and other inefficiencies introduced.

3. The raw fetching of data with JDBC doesn't allow for caching, look ahead fetching or other optimizations that can radically speed performance. EJB is simply not a complete Enterprise infrastructure without CocoBase. CocoBase suits the needs of modern computing by providing a flexible architecture for corporate data access without sacrificing the performance, reliability or scalability of resulting applications.

The CocoBase Dynamic Repository Based Solution

CocoBase allows the programmer to easily build their EJB objects from the underlying data source. These objects can be immediately compiled, deployed onto an EJB Server and used by a client. In fact, CocoBase writes all of the code for the CMP & BMP Entity Beans with the additional files necessary for installation onto the specific targeted EJB Server. This is important to do in order to reduce the overall cost of deploying enterprise applications. With CocoBase these objects can be quickly created, changed on the fly as well as made to scale and perform. This allows programmers to quickly increase their productivity and to decouple the creation/administration of Database Maps and EJBs from the programmers who use them. Thus reducing the need for highly experienced database access engineers on a project.

CocoBase is able to achieve this time savings as well as increases in standard EJB performance with it's Dynamic Repository based Mapping. CocoBase does not put the data access code (jdbc/sql) in java objects, but instead places the Mapping information in a repository that can be easily accessed, changed and used to generate / regenerate the thousand's of lines of code in an EJB if necessary. This technology is broadly called "Mapping Middleware." Thought Inc. patented this basic concept and created a product line around it called CocoBase.



Copyright 2002, THOUGHT Inc., 657 Mission St., San Francisco, CA 94105 USA. All rights reserved. Copyright in these (any and all contained herein) documents is owned by THOUGHT Inc. This material is for personal use only. Republication and re-dissemination, including posting to news groups, is expressly prohibited without the prior written consent of THOUGHT Inc. This publication is provided "as is" without warranty of any kind, either express or implied, including, but not limited to, the implied warranties of merchantability, fitness for a particular purpose, or non-infringement, to also include any and all technical inaccuracies or typographical errors.


CocoBase is a patented product under patent #5857197.


CocoBase, THOUGHT Inc., Dynamic O/R Mapping, Dynamic Transparent Persistence and others are all trademarks of THOUGHT Inc. All other trademarks are owned by their respective owners.





Related Info

CocoBase® Whitepaper
How to Meet ROI Requirements for Persisting Data in Enterprise Applications with CocoBase®.

CocoBase® Whitepaper
Dynamic Transparent Persistence™ for the J2EE and J2SE Platforms.

CocoBase® Whitepaper
Why Dynamic Repository Based Mapping is the Key to Success for Database Access with CMP / BMP Entity Beans.

CocoBase® Whitepaper
Mapping Concepts - Details on how CocoBase Maps Data.