[jBoss-Dev] CocoBase / JBoss 2.0 Integration

[Rob Castaneda]

Hi,     Below is my investigation work on JBoss/CocoBase integration (codenamed CocoBoss ;-) . It describes how CocoBase works and what has to be done to get them married. If anyone has previous experience with CocoBase then I would *really* appreciate your feedback on this.  There is a list of issues/questions at the bottom of the doc.       Marc - it seems we can't try out the new EntityPersistenceStore yet!       I'm off to the mountains for a few days, and start putting a simple implementation together next week.       regards,   -Rob         CocoBase / JBoss 2.0 Integration  ============================   Notes and Architecture 0.1 - July 21, 2000   CocoBase offers powerful object to relational Editable Mapping "Optimized for Enterprise JavaBeans" that Generates CMP & BMP Entity Beans and works with any Standard EJB Server. This document gives a *very* brief outline to the architecture of how CocoBase works and how it can/will be integrated with JBoss 2.0   I ran through the tutorials and dissected what code was being generated, and from where etc, and came up with the following.   CocoBase offers 2 levels of support for EJB containers, BMP and CMP. Both are discussed below   BMP support ===========   Cocobase supports the generation of BMP EJB's that are 'configured' to work in a particular EJB container.   At the heart of the Cocobase architecture is a MAP, which provides a level of indirection between an EJB and the fields that it maps to inside a realtional database table. MAPs are generated with the CocoAdmin gui tool, which connects to a database and queries the metadata. Fields defined in a MAP can correspond to data in various tables, hence the complex mappings.   Once you have a MAP defined, you can then generate a BMP bean from the CocoAdmin tool which has fields that correspond to the MAP. CocoBase will generate all the required code for implementing the MAP to database schema.   CocoBase caters for the differences between each EJB container through some modifyable templates, which are used in the source code generation process. For JBoss integration, we need to write a set of templates for the generation and deployment of JBoss BMP beans, and Deployment Descriptors       CMP Support ===========   The second level of support that CocoBase offers is CMP support. I originally was under the impression that CocoBase was a service that was running and we'd have to implement the org.jboss.ejb.EntityPersistenceStore interface and plug it into a Persistence Manager of the Container. However it is not.   CocoBase implements CMP using BMP. By this I mean that you give it a CMP bean, it will then flow through a wizard and generate a BMP bean which extends your CMP bean. ( It uses the templates from the BMP support for the container differences). It then changes the deployment descriptor to use the new BMP generated Bean Class, rather than the original CMP bean class. And deploys the Bean into the container.   For this CMP support we need to implement an interface com.thought.CocoAdmin.CmpInstaller.CmpDeployerInterface  which enables us to define how to deploy beans into JBoss   What is to be done ==================   1) Templates need to be created for JBoss for CocoBase to use it with BMP. These should be tested HEAVILY.  templates are needed for things such as obtaining DataSources from JNDI, the JBoss XML file etc. Most of it we *should* be able to get from other templates for other containers. 2) The Deploy Tool Interface needs to be implemented. The guys from thought.inc already gave us a sample.   Possible Issues / Things I need to clarify ======================================== 1) When is the full BMP implementation going to be in a build of JBoss, I'm under impression its in the next build (real soon) I'd like to use this, if possible. 2) Marc, can we get someone from thought.inc to read over the above and clarify my investigation and possibly point out any areas I've missed 3) Does thought.inc have a set of Beans that they run supported containers through to 'certify' the implementation?, this would save heaps of time.