Differences between revisions 1 and 2
Revision 1 as of 2005-03-22 05:43:34
Size: 14309
Editor: anonymous
Comment: missing edit-log entry for this revision
Revision 2 as of 2009-09-20 22:56:12
Size: 14313
Editor: localhost
Comment: converted to 1.6 markup
Deletions are marked like this. Additions are marked like this.
Line 1: Line 1:
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. 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.
Line 233: Line 233:
http://www.impart.ch/OJBTool/Design.gif {{http://www.impart.ch/OJBTool/Design.gif}}

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:

  • Software design

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.

  • Mapping tool components

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

  • - Data store (database, xml, etc) tool. Data store meta data e.g. Databases, tables, columns, relationships, etc. - Object tool. Object's meta data. Object definitions, hierarchy, inheritance, relationships. - Data store to Object bridge. Connect data store meta data with object meta data
  • *** Data Store tool (DS tool)
    • Data store had two main tasks
      • 1) Reverse engineering (RE) - Created Data store meta data from data store 2) Forward engineering (FE)- Create data store DDL statements
  • *** Object tool. (O tool)
    • 1) RE - Create object meta data from OJB's repository.xml, other persistence mechanism config files, java and class }}}

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

  • ** Data store to Object bridge
    • 1) Objects from data store (DS -> O)

      • a) Obtain data store metadata (imported or reverse engineered) b) Derive object meta data from data store metadata c) Correct./Enhance object metadata d) Generate object files (java, xml, etc)

      2) Data store from object (O -> DS)

      • a) Obtain object metadata (imported or reverse engineered) b) Derive data store meta data from object metadata c) Correct./Enhance data store metadata d) Generate DDL files

      3) Inside out (DS <-> O)

      • a) Obtain object metadata (imported or reverse engineered) b) Obtain data store metadata (imported or reverse engineered) c) Link data store meta data to object metadata
    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:

  • Forward engineering*

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

  • Reverse engineering*

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)

  • mapping proper*

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 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 - 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: http://axgen.sourceforge.net

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:

- 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   

Requirements:

General

- easy architecture

- only real needed technologies (a closed system)

- extensible design

- graphical configuration of properties for the tool and for OJB

Reverse

- 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

Forward

- 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

Mapping

- 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

Design

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

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

  • read & edit OJB repository declaration

  • read database schema
  • read existing java source hierarchy
  • read existing class file hierarchy (i.e. .jar files)
  • transformation forward and backward between problem domains where possible (e.g. database schema -> java source files, OJB repository -> database)

  • functionality must be accessible from a graphical environment as well as from command line
  • extensive test suite for at least those funcational blocks that are not dependending on a graphical user interface, testing procedures for graphical components where possible and feasable.

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:

  • SWT (by IBM, tool support is unknown)
    • Pros: ?
    • Cons: ?
  • AWT (included in JRE, free tools are available).
    • Pros: Quick due to native implementation of widgets.
    • Cons: Possible incompatiblitites between Java platforms.
  • Swing (included in JRE, free tools are available)
    • Pros: Very portable, widespread tool support.
    • Cons: Possibly not the quickest solution.


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)