So, what is a repository anyways? ...
The American Heritage dictionary says:
- A place where things may be put for safekeeping.
- A warehouse.
- A museum.
- A burial vault; a tomb.
- One that contains or is a store of something specified: “Bone marrow is also the repository for some leukemias and lymphomas” (Seth Rolbein).
- One who is entrusted with secrets or confidential information.
Not very helpful. Some might say that a repository is any structured collection of data, but then how is it distinct from any database?
The Free On-Line Dictionary of Computing says:
1.
2.
This is getting closer.
I wouldn't limit repositories to CASE if by CASE we mean "Computer Assisted Software Engineering." I might be OK with it if we mean "Computer Assisted Systems Engineering," because now we're not just talking about the software development lifecycle, but also service management and its associated infrastructure. For either problem domain, there are some common characteristics of the data.
The concept of model is key to either conception of CASE: one may model information structures, business logic, runtime architectures, or infrastructure services (hard and soft). There are some common characteristics to all this data. Beyond needing the usual semantics of cardinality and declarative set constraints:
1. It is graph-centric (as someone just posted tonight on the erp4it list, it's more about the relationship than the data)
2. It requires robust inheritance semantics
3. It is often recursive (bill of materials or network)
4. Many to many relationships are very common
I am *not* going to argue that the relational model can't handle this; I would be crucified in the name of Codd. But I *will* argue (as others have) that the SQL-based relational database *paradigm* as currently implemented is not up to the task. Object-oriented semantics are far better suited for this work. This can be seen quite clearly in the relational metamodels for CASE tools such as Erwin and CA Advantage:Gen; they both exhibit typical design patterns for object/relational mapping, and the irony here is what they are modeling is (wholly for Erwin, in part for Advantage:Gen) relational metadata!
When tools comprehensively add such additional functionality (especially if they are targeted at supporting multiple metamodels), the end result is essentially an implementation of an object/relational persistence layer. The Adaptive repository does this on top of a relational database, while Rochade (another metadata vendor) goes straight for the object database.
So, can we standardize this core object semantics? There are a couple options: OQL (Object Query Language) and the OMG's Meta-Object Facility. I don't know much about OQL, so I'll stay quiet on that topic for now, but I am very curious if anyone else sees MOF and its related infrastructure as ultimately a challenge to OQL. In fact, I wonder what the OODBMS community in general thinks about the OMG's work.
Models and metamodels defined in XMI serve as a quasi-DDL for a MOF repository. Query/view semantics are being defined as I write this (this being one of the OMG's highest-participation specs), and that will give a DML capability. So at that point, what is the relationship with OQL?
In any case, we need a persistence architecture, preferably standards-based, and supporting OO semantics at the interface level. That seems to be the unavoidable conclusion.
-Charlie
