These are excellent requirements, and start to move the MDR in the direction
of a generalized CASE tool (metaCASE, actually).
However, I would like to lay out another use case: using the MDR APIs for
read-only system inventory work. This is more of a reverse
engineering/program understanding/enterprise application portfolio
management use case, in which versioning becomes somewhat less important.
An example use case would be:
1. Run a scanner against an RDBMS system catalog. Translate the proprietary
system catalog to standard CWM/XMI (Relational package).
2. Write the extracted system catalog to the repository.
3. Repeat for all RDBMSes in the shop.
4. User logs into Web site, queries repository. Repository emits XMI that
can be presented to user via XSLT transformation. This is where multi-user
architecture becomes important, not on the input side.
The reason I say that versioning is less important to this use case is that
the extracts can simply be completely refreshed, which simplifies a number
of issues tremendously. Delta processing is still useful for identifying new
elements for the inventory and enabling related administrative processes,
but great value can still be delivered without this.
The above use case is RDBMS-centric, but simply replace the RDBMS with
1. UML diagrams (UML metamodel)
2. J2EE servers (JMI -> EDOC metamodel?)
3. Enterprise messaging architectures (UML Profile for EAI)
4. ETL applications such as Informatica (CWM)
5. E/R modeling tools such as Erwin (CWM)
This probably seems like alien stuff, given the development tools focus of
MDR. But I can see *so much* potential in that generalized MOF API and XMI
for my problem domain, which is managing enterprise system inventories at
scale. Sure, Adaptive already does this -- but again, I am in a
bootstrapping problem with limited resources, and need the open source
implementations to prove my case. If people had been charging half a million
dollars for TCP/IP twenty years ago, it never would have gone anywhere.
If anyone else is interested in these types of use cases, please let me
know. Perhaps we can start an interest group list. There is also the
potential of leveraging some of our local software engineering students who
are always looking for projects.
P.S. W/r/t CASE: These types of requirements are also nontrivial, as the
history of 1st generation CASE tools shows. The issue of object lineage and
identity is a killer.
Even Erwin, with its limited domain of use (entity/relationship
diagramming), has had tremendous challenges precisely in the area of model
merge/delta with respect to the ModelMart RDBMS-based repository. (I worked
for Target, the large American retailer; when I left there a few months ago
there were about 35 outstanding issues we were pestering CA on, and this was
with respect to Erwin/ModelMart 3.5, supposedly mature technology)
Post by Holger Krug
Before speeking about the amount of work I would recommend to make some
requirement analysis first. Maybe we can use this thread to collect the
requirements for such a persistence layer. This definitely would help
anybody who wants to implement it later on quite a lot and is not very
much work for anybody of us.
1) Version management in a CVS like manner (different branches etc.)
2) Semantical diffs and merges (not based on a textual diff a some
textual representation, e.g. XMI, but based on the meta-model)
3) Merges also restricted to parts of the model (i.e. merge only the
changes I've made inside this containment hierarchy with the main trunk,
but not all the other changes I've made)