Login | Register
My pages Projects Community openCollabNet

Project home

If you were registered and logged in, you could join this project.

Summary A standards-based object relational mapping framework
Category construction
License Other OSI-certified license
Owner(s) abworx, thhal
Louis - a Frameworx project


What is there to know about Louis?


What is Louis?
Why does Louis exist?
What is the history of the Louis Project?
What exactly is O/R Mapping?
How does Louis relate to the Frameworx Project?

Functionality Scope

What exactly does Louis do?
What is OUTSIDE the scope of the Louis project?
How is Louis different from other O/R mapping products?
What problems can Louis be used to solve?
How is Louis used in an integration framework?
How can Louis be used in conjunction with other Frameworx components?


What functional units does Louis comprise?
What are the key technologies on which Louis depends?
What external components or systems does Louis require?
How database-independent is Louis?

Legal and Stuff

How is Louis licensed?
Why is the Project called "Louis"?
Contact Project Owner

What is Louis?

Louis is a meta-data driven object-to-relational mapper that can be accessed using standard JDBC interfaces and OQL query language, an Object Data Management Group (ODMG) standard. Louis provides a rich set of mapping capabilities and elaborated support for legacy database integration.

Information Models are created using standard UML modeling tools. Mappings, and resulting Data Models are also described in UML. Louis provides reverse engineering capabilities so that all UML artifacts can be generated from an existing database.

Why does Louis exist?

When the implementation of Louis commenced, the concept of O/R mapping was not as widely spread as it is today. A few proprietary O/R mappers where on the market, but their functionality was fairly limited and the cost of using them was high.

We saw the opportunity to advance the functional state of the art, while meeting established requirements for performance, scalability and vendor independence. We also wanted to build something that was modern, standards-based and integration-oriented, meaning that:

  • Standard UML would be used to model and maintain database-independent Information Model Schemas

  • JDBC with OQL would be the primary access mechanism.

  • O/R could be used to anchor nearly any type of service-oriented integration approach, while supporting nearly any legacy database.

Finally, we believe that O/R mapping technology should be open source.

What is the history of the Louis Project?

The Louis O/R mapper is the result of over four years of continuous development effort, and a decade of prior experience in the O/R mapping domain. The basic ideas behind Louis originate from earlier generation O/R mappers we had developed beginning in 1992. The scope was fairly narrow and the main objective was to give developers a tool to model objects and their relationships against an underlying database, while minimizing the application impact of changing database vendors.

This first-gen O/R mapper closely resembled today's JDO. Objects were brought into memory using filters. Attribute groups could be defined so that only parts of the object could be retrieved. Since the runtime was written in C++ and the object definitions where declared using an interpretative language, (this was long before Java and XML), the interfaces was of course proprietary.

We learned much about how to map an O/R model into SQL, both with respect to performance and flexibility. We also learned that bringing objects into memory is not always idea. In particular:

  • Fetch-groups are a fairly crude mechanism. Something more fine-grained is often called for.

  • The most efficient way to effect aggregations (average, count, sum, etc.) can be counter-intuitive.

  • Complex joins, projecting results from several tables, cannot be created dynamically.

  • Existing systems that use SQL must be completely rewritten in order to use in-memory objects.

  • Caching objects in the middle-tier is difficult and costly in a clustered environment.

  • Streaming protocols that enable the O/R mapper to be located elsewhere (e.g. close to the physical database) cannot be efficiently implemented.

Another lesson learned was that it is important to have elaborated primary key mapping mechanisms in order to map Legacy databases. We lacked support for this functionality (as do most O/R mappers today), which made O/R mapping useless in integration scenarios where queries involving direct access to legacy data were needed.

We brought all this experience together in creating Louis.

What exactly is O/R Mapping?

O/R mapping is a relatively well defined domain, and our ambition is to develop an O/R mapping package that is unequalled in:

  • functionality, flexible and agility

  • support for emerging standards

  • performance and availability

  • applicability to mission-critical use

  • support for integration-oriented use-cases

How does Louis relate to the Frameworx Project?

Louis is the foundation of the service-oriented application architecture that ties together all components developed in connection with the Frameworx Project. Although it can be used as a stand-alone O/R mapper, it is uniquely capable when used in conjunction with the Mies data composition framework, the Imhotep workflow framework and Frameworx-defined architectures for service-oriented application development or integration.

What exactly does Louis do?

Key functionality provided by Louis includes the following:

  • UML modeling of information model, mapping, and data model artifacts.

  • Full implementation of OQL 3.0 query language with Data Manipulation Language (DML) extensions.

  • Primary access mechanism using standard JDBC interfaces.

  • Automatic generation of initial mapping.

  • Forward (using information model as origin) and reverse schema generation.

  • Inheritance mapped using split, cohabitation, simple-type or hybrid mappings.

  • Outstanding legacy mapping capabilities featuring partial database mappings, reverse engineering and model generation, and support for composed primary keys.

  • Runtime control using Java Management eXtensions (JMX).

  • Runs directly from meta-data; no byte-code enhancements.

  • Referential integrity handled using constraints in the database, supplemented with triggers as needed.

  • Currently runs on Oracle, DB2, MS SQLServer, and PostgreSQL.

  • Layered API architecture makes the task of adding new databases very easy.

What is OUTSIDE the scope of the Louis project?

The following are examples of capabilities Louis will not provide:

  • Louis will not provide distributed query optimization capabilities. We expect that functionality, where required, to be provided by specialized third-party components that would Louis would see as another data source.

  • Louis does not deal with bringing persistent objects into memory. Instead, Louis delivers query result sets for further perusal by components such as the Mies data composition framework.

  • Louis will not provide a middle tier cache mechanism since that would (1) be problematic in a clustered environment and (2) complicate the query pushdown mechanism. The Mies framework has a simplistic but efficient caching mechanisms enabling caching of static data. Database vendors provide client-side database caches that can be used invisibly behind Louis.

  • Louis relies on its surrounding environment for connection pooling, transaction control and comparable generic functionality.

How is Louis different from other O/R mapping products?

  • Most O/R mappers focus on bringing information model objects into memory. Louis focuses on implementing standard JDBC interfaces, enabling full-blown query functionality on top of the information model.

  • Louis draws a clear separation of concern between composition of in-memory objects and O/R mapping per se, relying for example on the Mies data composition framework. Other O/R mappers will transform filter expressions into queries expressed in unmapped terms to obtain result-sets that reflect the unmapped data and then perform the mapping when creating in-memory objects. Louis in contrast, sits behind the query mechanism. Therefore, data objects do not need to be instantiated from the query results, since the query per se is already mapped. Specific data that needs to be fetched can be determined dynamically at runtime, and the most appropriate way of using it - e.g. building in-memory objects, generating XML events), etc. - c chosen based on context.

  • Performance has been a key stumbling block for O/R mapping products in the past. Louis realizes dramatic performance efficiency with an architecture that fully leverages the standard capabilities of backend databases.

  • Louis' query capabilities are of significantly superior efficiency. Although many O/R mappers claim to have a full-blown query language (as opposed to just query filtering), this is commonly implemented as pushdown filters, in combination with projections from an underlying in-memory object model. Louis transforms the entire query according to the mapping and utilizes the backend database optimizer to its maximum. The result of a query is transformed invisibly and on-demand.

  • Louis' is significantly more efficient in the way it makes changes in the backend database. Louis creates, changes and deletes objects using simple SQL operations such as INSERT, UPDATE, and DELETE. In contrast, most O/R mappers are unable to make simple but extensive changes (e.g. "increase all prices by 2% for products in the XYZ category") without having to bring all objects into memory, change them and then write them back. Louis transforms and pushes down the entire statement for execution by the database.

  • Louis reduces the performance impact of common functions such as constraint checking by delegating the maintenance of referential integrity to the backend database. The Data Model contains triggers, based on advanced inheritance mapping, that handle constraint checking that cannot be performed using standard constraints. Most O/R mappers implement this type of constraint checking in the client, increasing database calls and having very negative performance effects.

  • Louis can handle multiple mappings on top of a physical data simultaneously. This capability is fundamental to step-wise migration of large systems. A change in the database can be hidden from a majority of the code above Louis by use of a mapping that hides that change. Only new code, which is designed assuming the change, uses a mapping that exposes it.

  • Louis allows multiple mappings of an information model. One common scenario in which this capability is useful is where similar constructs (for example, "customer") are in different legacy databases. An information model can thus provide a unified access structure to those databases for a given application.

  • Louis provides unequalled legacy integration capabilities. O/R systems created primarily for forward engineering can handle a legacy system only if it conforms to certain implementation rules. However, legacy systems often contain idiosyncratic constructs that exist for historical reasons, which can be notoriously hard to map. Louis supports the mapping of primary and foreign key references to virtually any construct (including multiple columns and algorithmic transformations), requiring only some unique way of mapping between the database and object identifiers.

What problems can Louis be used to solve?

Louis can be used to solve problems typically addressed by O/R mappers, such as database dependence and mismatch between object orientation and relational storage. Moreover, unlike many advanced O/R mappers, Louis can be used where extreme performance or clustered production is required. For example, Louis could be used high-throughput content rendering by generating XML events directly from query results.

Louis is also applicable to problems for which use of O/R mapping technology would not be typically obvious. Example include:

  • Stepwise migration from a legacy system. Louis can provide mappings that make old code unaware of changes made to the physical database. Those mappings can be used in conjunction with new mappings that expose new functionality.

  • Preservation of existing schemas. Louis' support for nested or iterative information modeling (without reduced run-time performance) allows creation of "virtual" information models, in which databases are aggregated into a new model while leaving the original database intact and functional, or unique, arbitrarily transformable views of a larger information model are accessed by different applications.

In all cases, Louis completely shields the developer from the SQL coding or concerns of the physical database, allowing developers to work solely in UML. Important to note is that the normalized schemas that Louis generates are also denormalizable where performance considerations require.

How is Louis used in an integration framework?

Louis can be an integral element of a service-oriented integration framework. When used in combination with the Mies data composition framework, integration is made possible in three different layers.

  • Louis integrates well with most legacy databases such that the legacy database can be modeled as object-relational schemas in the information model.

  • Since Louis' primary access mechanism is JDBC, it can replace other JDBC databases, providing a step-wise migration of the JDBC client software.

  • Systems using Mies can run Louis in parallel with other JDBC data sources. Mies will soon provide support for data sources that conform to the Java Connectivity Adapter (JCA) standard as well.

How can Louis be used in conjunction with other Frameworx components?

Louis is most closely related to the Mies data composition framework, and both components will be deployed together in many cases. (In fact, O/R mapping products typically lack a clear separation of concern between object mapping and data composition and often provide both types of functionality.) Louis exposes JDBC in terms of one or several object models, which makes it a natural data-source for the data composition using Mies.

In straightforward systems, where a lesser degree of separation of concern between layers can be accepted, JDBC source can be used directly by other system elements. In more complex systems the separation between higher order business abstractions and data organization in the information model becomes critical. In such cases, Mies (or a comparable framework) typically would be used on top of JDBC to hide the composition of the information model from other rest of the system.

What functional units does Louis comprise?

Louis consists of a runtime component and a model generation tool-set.

The run-time comprises:

  • an implementation of JDBC 3.0.

  • an OQL query parser.

  • a query transformer.

  • an agnostic data model implementation and several vendor specific ports.

The runtime is built on JMX technology and schemas, mappings, and database connections are configured using javax.management.MBean properties.

Louis' current toolset also contains model generation tools that minimize the work of mapping implementation. A default Mapping and Data Model can be generated automatically from an Object Model, as can the reverse.

What are the key technologies on which Louis depends?

Louis depends on:

  • J2SE (version 1.4 or above).

  • Java DataBase Connectivity (JDBC).

  • Unified Modeling Language (UML).

  • Java Management eXtensions (JMX).

  • Object Query Language (OQL).

  • Structured Query Language (SQL).

  • XML and XML Metadata Interchange (XMI).

What external components or systems does Louis require?

Louis is designed to run in any J2EE application server environment. Louis can also run as a standalone component, provided that a JMX implementation is available.

How database-independent is Louis?

Louis comes with built-in support for:

  • Oracle

  • IBM DB2

  • Microsoft SQLServer

  • PostgreSQL

  • Moreover, the effort required to support any other database fully supporting the SQL-92 standard and providing a JDBC 3.0 driver would typically be trivial.

    However, Louis uses sub-selects, outer joins, unions, and triggers, so standard support for those capabilities is also required.

    How is Louis licensed?

    Louis, like other software initiated within The Frameworx Project, is available under "Apache-style" (BSD-based) licensing.

    Why is the Project called "Louis"?

    Like other projects originated by the Frameworx Project, Louis is named after a "famous dead architect", in this case Louis Kahn, considered one of the greatest architects of the twentieth century. Kahn's work is unique in its use of simple, platonic forms and his reliance on elemental materials such as brick and poured concrete. Kahn's aim was to develop a new architecture that was rooted in the International Style but had the permanence and monumentality he found in the structures of the ancient and classical worlds. For more information on Louis Kahn, see www.greatbuildings.com.


    Go Here!


    Status & Roadmap


    Design Overview

    Developer Guide

    Developer FAQ

    Use Cases

    White Papers


    Try it!

    Founding Team

    Thomas Hallgren
    Founding Architect & Developer

    Peer Torngren
    Architect & Developer

    Nils Unden
    Architect & Developer

    Henrik Lindberg
    Architect & Developer

    Related Topics

    Coming soon