Enki

From Eigenpedia

Jump to: navigation, search

This is the main page for the Enki open-source project, a library that implements the JMI and MDR APIs for a MOF metamodel and provides for the storage of model object instances in an RDBMS via automatically generated Hibernate O/R mapping.

Contents

Background

Farrago and other projects (e.g. LucidDB) built upon its framework were originally developed with dependencies on the Netbeans MDR project

  1. to generate interfaces (a model) from a UML metamodel,
  2. provide an implementation of the model, and
  3. to store instantiated elements of the model in a relational datastore (the RDBMS catalog).

By implementing the JMI API, MDR provides a mechanism for creating, associating, and querying elements of the model. MDR additionally provides an event system for detecting changes to the model's instantiated elements.

The metamodel in question represents Farrago's catalog and, ultimately, MDR was not designed to provide the reliability, availability, scalability and performance required (MDR's focus was on design-time metamodeling).

Enki provides an implementation of the JMI and MDR interfaces that meets the requirements of Farrago. In addition, it may be a good migration/enhancement path for other projects which were based on MDR originally; see the argouml-enki project for an example where this is being attempted. And of course, the technology may be of interest for use in non-MDR-based projects with similar requirements.

Project Documentation

See EnkiDocs.

Requirements

  • Support one or more metamodels in the same application simultaneously.
  • Support at least MySQL for RDBMS persistence, but preferrably allow for any RDBMS meeting some basic requirements.
  • MDR/JMI compatibility
    • Must implement existing Farrago usages of JMI/MDR APIs.
    • Must be compatible with MDRJDBC conventions (e.g., MOFID format)
    • Must allow existing MDR/MDRJDBC configurations to continue working
      • Note: the idea here is that some existing Farrago code used to initialize MDR gets abstracted by an Enki interface and Enki may be configured to simply delegate to the current MDR libraries.
    • Must be possible to upgrade from existing MDRJDBC-based repository
    • Must be able to support existing datatypes (e.g., hsqldb supports binary string columns of arbitrary length, which the LucidDB catalog relies on to store huge view definitions)
  • Transactions
    • Must provide support equivalent to MDR's coarse-grained read/write lock where needed for consistent access
    • May also support lower-consistency isolation levels such as dirty read
    • TBD: compatibility with MDR's autocommit transaction support
  • Scalability
    • Must support parameterized control over the size of a hard-reference cache
    • The memory footprint of a repository managed by Enki must be proportional to the amount of information actually being accessed (or the setting for the cache size parameter, whichever is larger)
      • Note that the MDR repository memory footprint is proportional to the total stored repository size when hsqldb is used for persistence
    • Must be no lock contention for concurrent read access to a repository managed by Enki
    • When the relevant data is fully cached, the read/write time for all repository structures (including ordered associations) must be no worse than the equivalent time for the MDR repository
    • TBD: requirements on read time for all repository structures when nothing has been cached yet; writeback time also

Licensing

Enki is released under the LGPL, version 2.1.

Issue Tracking

Issues for Enki are tracked in the ENK project in Eigenbase JIRA.

Source Code

Enki is hosted on Eigenbase's source control server as a separate top-level project at //open/enki. All Enki code is contained under the package org.eigenbase.enki. For use by Farrago, enki source and binary archives are checked into //open/dev/thirdparty and propagate via the usual branch integrations. Copyrights are assigned as in the Eigenbase green zone, as some green-zone Farrago code has been incorporated into Enki.

Why The Name Enki?

Well, it's short and easy to type (and also to pronounce). Neal Stephenson's Snow Crash came up at some point during early discussions. In that novel, Enki is the "primordial hacker." Per Wikipedia, Enki is "the master shaper of the world, god of wisdom and of all magic." He solicited other Sumerian gods "to use clay to form the first men, who would toil and farm so that the gods could relax." All that ties into the notion of code generation: forming the metamodel (clay) into the first men (model) so that the gods (Farrago et al) can relax. Plus Enki had a penchant for beer.

Retrieved from "http://pub.eigenbase.org/wiki/Enki"
Personal tools