This is a page where the requirements and ideas for a mapping workbench are gathered to be discussed and reviewed. OJBProjectPages/MWBConsolidatedRequirements will conain a consolidated requirements specification that is nicely formatted also for printing.

====================================================================================================== Vladimir Berezniker wrote:

Here are my 2 cents on the subject of object mapping tool:

I like MCV (Model-Contoller-View) model. In this model any software is broken down into two parts the engine(Model and Controller) and the View. Controller is the means to change the state of the model.

The Engine needs to be able to run whether there is a View attached to it or not. The Engine is the heart of the software. The Model defines data structures and the Controller defined rules that govern the data stored in the structures. It is the part that if you wished you can map out using UML. Engine is the implementation of the model and controller.

View is the presentation to the user of the state of the model that is retrieved through the controller. The view could also be interactive where it sends command back to controller to alter the state of the model.

In short the advantages of this approach would allow the software to become client/server (controller accessible through the network). Multiple views of the model. Multi user access for multi developer environments. Another application can automate tasks by talking to controller directly instead of trying to emulate user's actions in view. Also the view could be GUI, CLI or any new means that allow a human being to interact with the machine.

{{{ The object mapping tool is a actually three tools that utilize each others information.

files {{{ 2) FE - Create java, class, repository.xml, etc. from meta data (forward engineering)

layer should not be tied to OJB meta data layer. The reason is simple all object persistence mechanisms have to sacrifice ability to do everything for performance and that is absolutely correct in my book. However, the mapping tool does NOT actually move data and so should be able to store additional information that is not used during runtime. Plus I believe that if you make model generic enough people utilizing other persistence engines might give a hand. The more the merrier, right?

Sincerely, Vladimir Berezniker


ThomasMahler wrote: To have a complete set of mapping tools we will need at least:

1. Java to repository.xml and DDL (presumably XDoclet based) 2. XMI to Java and repository.xml and DDL (presumably XSL based transformation)

3. reading in a DB catalog, selecting tables and generating Java code and repository.xml (see existing reverse-Ddb tool and the existing Eclipse plugin)

4. reading in a DB catalog, selecting tables, reading in classes from the classpath, selecting classes to map, and performing the mapping of classes to table and of attributes to columns.

All four scenarios should reuse as much code as possible. My initial suggestion was to use the the central dataformat for all all transformations. This would lead to the following design: 1a. Java to repository.xml (XDoclet based) and parsing the DescriptorRepository from that file. Then there would be an additional DescriptorRepository to DDL Generator (similar to the RepositoryPersistor that can be used to generate a repository.xml file from a DescriptorRepository instance).

1b. Java to DescriptorRepository transformation (not based on XDoclet, thus some additional work required). Then again the DescriptorRepository to DDL Generator.

2. First a XSL transformation from XMI to Java sourcecode, then same procdure as in 1a or 1b.

3. After reading in and selecting tables a DescriptorRepository instance is constructed from the mapping information. The RepositoryPersistor is used to write the repository.xml file. Java source code can be generated by XSL transformation from the repository XML.

4. During the mapping process a DescriptorRepository instance is built upfrom the mapping information. The RepositoryPersistor is used to write the repository.xml file.

As you can see there is a lot of reuse possible and there are also several thing prepared in the metadata package for a cool mapping toolkit!

The tools should be available as - Swing based standalone app - Plugin for Eclipse, Netbeans, etc. - ant tasks for integration into ant based build routines


ThomasMahler: Axgen is an interesting candidate for the UML/XMI to repository business:

The idea: 1. Do entity modeling using argoUML 2. Generate Java classes, OJB repository and DDL script for DB creation


Very interesting existing solutions:

====================================================================================================== ======================================================================================================

MatthiasRoth wrote:

Here a list of a possible vision, aim and requirements:


To have in a short future a mapping workbench for OJB, to generate Classes from existing DB’s, to generate DB-Tables from existing Classes, to map existing Classes to existing DB-Tables. Start small but useful.


- Promote 100% of the OJB Framework.

- Simplify the work with OJB (Newbies und Jumpstarters)

- Simplify the work with DB’s (HSQL, Oracle, DB2, MSSql)

- Extensible for other Framework

- Support of different IDE’s like Eclipse, JBuilder …

- hidding technoligies like DDL,XML,XMI from user

- First full running version (reverse, forward, mapping) at end of July   



- easy architecture

- only real needed technologies (a closed system)

- extensible design

- graphical configuration of properties for the tool and for OJB


- graphical view of DB-Tables

- select one ore more than one DB-Tables to generate Classes or OJB files

- select one DB-Tables to get data form DB

- possibility to test the generated Classses with the OJB files

- graphical configuration of different JDBC DB-Connection

- possibility to test configured DB-Connection

- possibility to send SQL statements to DB and get the result

- possibility to generate Struts ActionForms


- graphical view of Classes

- select one ore more Class to generate DB-Tables and OJB files

- possibility to test the generated Tables with the OJB files

- graphical configuration of different JDBC DB-Connection

- possibility to test configured DB-Connection

- possibility to send SQL statements to DB and get the result


- graphical view of Classes and DB-Tables

- mapping of Classes to Tables and mapping of Class Attributes to Table Attributes

- graphical configuration of different JDBC DB-Connection

- possibility to test configured DB-Connection

- possibility to send SQL statements to DB and get the result


DbMeta and ClassMeta are two component witch are responsible to get the information from different data sources in a unique form. This two component will also be used from the OJBGenerator.

ClassGenerator is responsible to generate the Classes form the DbMeta-Modell and additional properties for the ClassGenerator component.

TableGenerator is responsible to generate the db tables or ddl or sql-scripts from the ClassMeta-Model and additional properties for the Table Generator.

ClassTableMapper is responsible to map the classes form the ClassMeta-model to the DbMeta-modle.

OJBGenrator is responsible to generate the proper OJB repository files from DbMeta-Model and ClassMeta-Model.

The view component makes the graphical representation of the different Meta-Model and to make it easy for an user to deal with the different components.

This design allows making the system changeable and extensible for other requirements. It will be possible to replace every component by an other component, if somebody does not like the default components.

====================================================================================================== ======================================================================================================

Florian wrote:

1. Goals

The goal of this effort is to create a database mapping tool. There shall be a plugin mechanism to easily integrate implementation for certain problem domains. It is not intended to extend functionality to create UML diagrams, as this is already covered by wide-spread, freely available tools.

2. Constraints

The tool shall be published under the Apache Software License. Therefore all components used must be available with a license that is deemed compatible with the Apache Software License by the Apache Foundation. All code directly contributed to the effort (i.e. not in form of a class library) must have the copyright assigned to the Apache Foundation to enable integration into an Apache project.

3. History

4. Requirements

5. Design

5.1 GUI framework

A GUI framework shall be used for creating the user interface. All graphical elements shall be designed with tool support (e.g. Netbeans) for easier maintenance, therefore there needs to be appropriate tool support for the framework. These tools must be available freely so more developers can contribute to the project. The following frameworks are taken into consideration for now:

Pardon the intrusion: I have used the TopLink Mapping Workbench, a proprietary O/R mapping tool, and found it to be adequate if not sexy. Based on that experience, I would suggest that it would be helpful to have the "Visual O/R mapping tool" generate an XML representation of the mappings, 1:1, 1:N, N:N, etc. A "back-end" process could then convert the XML to the underlying "native" mapping. The advantages? This would make the "front-end" attractive beyond the scope of this project. It would also allow the development of multiple front-ends... One using Swing for Sun One, another using SWT for Eclipse, etc. It would even allow the occasionaly odd-ball to generate the mappings using a text editor (shudder). Just a thought.

OJBProjectPagesReverseEngineering (last edited 2009-09-20 22:56:12 by localhost)