This is a page where the requirements and ideas for a mapping workbench are gathered to be discussed and reviewed. 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.

This design can be enhanced to allow objects to be mapped to other objects. and allow entire chains of the mapping then you pretty much will create Warehouse ETL tool.

I have noticed that the strongest point was that the tool needs to work for OJB first and while I agree I have to comment that Meta data 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:

All four scenarios should reuse as much code as possible. My initial suggestion was to use the org.apache.ojb.broker.metadata.DescriptorRepository 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


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:

Vision:

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.

Aim:

Requirements:

http://www.impart.ch/OJBTool/Design.gif

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:

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.

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.

History

Requirements

Design

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.

OJBReverseEngineering (last edited 2009-09-20 22:56:17 by localhost)