Few years see the flurry of activity in the repository marketplace that 1997 has brought: first, the entry of the desktop giant Microsoft, and not too long thereafter, the announcement of the joint
development and marketing partnership of Microsoft and Platinum.
Microsoft Repository targets software tool vendors who wish to use open information models to support the development, deployment, and reuse of component software.[1]
Repository Manager [is] a system to support the development and execution of software engineering tools for application development and other strategic requirements.[2]
The more things change, the more they stay the same? It’s deja vu all over again? Everything old is new again? To some observers, Microsoft’s effort brings to mind the ill-fated IBM Repository
Manager.
(For more details on this angle, see David Linthicum’s article on the Microsoft Repository in the June issue of DBMS magazine, and for those heavily into software archeology, the IBM Systems
Journal Vol. 29 No.2.) If all goes well, the Microsoft and Platinum developments are generally goodness, if for nothing other than raising the level of mass consciousness with regard to
repository–anything with the Microsoft name is likely to attract attention.
These developments may cause some confusion in those shops who have committed to the venerable Platinum Repository (PR). A comparison of the two products as they exist today reveals both
similarities and fundamental differences, and also casts new light on some basic concepts of repository. Does the similarity between the two software products extend beyond the name only? What
might we expect to see as a result of the Microsoft/Platinum agreements? What developers and data administrators need to know is: what is the likelihood of success for these products, separately
and collectively, and which will the repository of the future look like?
An apples-to-apples comparison at this time is a stretch at the very least, and may indeed be premature; but comparison is inevitable. The current practical differences between the products are
that PR is a widely-implemented and extensive set of software products, whereas the Microsoft Repository (MSR) at this point in time consists of:
- an ambitious, voluminous, abstract-yet-detailed (honest) specification
- a development tool encyclopedia which implements the specification
- an impressive set of business agreements for other implementations and interfaces.
As a practical experiment, I was able to follow the instructions in the MSR documentation to establish an instance of the MSR database and associate it with a Visual Basic project. For the benefit
of the real repository database geeks among us, the resulting MS Access database looked something like this:
A functional comparison of the two repositories at the specification level at this time is probably valid and valuable. The major differences at this level lie in 1) the scope of the software
activities supportable by each product spec, and 2) the role-passive or active–each plays within that scope. An active role played by a product implies that software/data specifications are
represented in the product in real time. A passive role means that specifications are initiated retroactively within the product. A repository product can be active or passive relative to any
given phase of the software life cycle: design, development, execution or maintenance. The conceptual design of the MSR allows for it to be active in design, development, execution and maintenance.
According to Microsoft, MSR “is a database that stores and shares software components along with their descriptive information”. The key new factor, relative to the more “traditional” PR, is
the storage of components-the executable’s themselves–in the repository. This is a truly object-oriented concept, quite similar to that of the Interface Repository component of an Object Request
Broker[3].
The Microsoft Repository has been initially targeted-no surprises here–at the client/server developer market. Its release coincides with that of Visual Basic 5.0, and it is delivered as an
optional add-on to that product. When used as such, it is actively involved in the activity of Visual Basic developers of desktop and client/server applications. The Platinum Repository has been in
use in mainframe shops for nearly a decade, and has more recently extended its scope into the Unix server world. Within its scope the PR has been essentially passive, relinquishing the more active
roles to more specialized tools.
It manages specifications-i.e., “descriptive information”–from design through development and maintenance, extending somewhat into the runtime environment in support of end-user documentation
and information discovery.
The conceptual differences are significant. PR presents its metamodel primarily in entity-relationship terms; MSR is grounded in the object world. The PR essentially is a tool; the MSR is intended
to be used to “develop tools”, therefore, the metamodel for MSR is much more abstract-its model is in the strictest sense a meta-meta model.
Different tools supported by the MSR can have different “information models”. An MSR tool model, then, could be compared to a Platinum Repository Dialog, such as those for Bachman, ADW, MVS batch
JCL, and so forth. The only example of an MSR information model to date is the Microsoft Development Objects Model (MDO Model); it describes the kinds of data that Visual Basic stores in the
repository. Microsoft has also announced a tool information model for data warehousing which will use the MSR. The PR metamodels, then, could be manifested, in total or in part, as one or more
future instances of MSR information models-a more detailed, specific layer “on top of” the MSR, as it were.
The common ground which may allow for a relatively simple integration of the two lies in the concepts of objects and their participation in relationships. Objects are initiated in PR by means of
ENT_IDs, relationships by source and target; objects in MR by object identifiers, relationships by origin and destination. A slight deviation from the common ground is the MR object identifier’s
uniqueness across instances of repository databases; therefore, the derivation and semantics of an MR object identifier are significantly more complex than the PR ENT_ID, which is simply a
sequential number. But anyone who has contemplated merging multiple instances of PR can relate to the potential value of unique IDs across repository instances, so here is one benefit we may expect
to come of the joint development effort.
To summarize, the recent announcements appear to bode well for the future of repository-if the players succeed in bringing their ambitious plans to fruition, and remain focused on avoiding a
repetition of the AD/Cycle disaster. The Platinum/Microsoft agreement may provide the means for Microsoft to extend its reach farther into the enterprise; conversely, it may extend the Platinum
Repository’s reach towards desktop development, as well as a more active role at execution time. A few of the potential benefits accruing to repository users include:
* A more active role for repository in the development and use of software
* More widespread acceptance and use of repository by new developer groups
* More comprehensive meta data
* Integration of components on diverse platforms
* Integration of meta data from diverse sources
An extensive set of documentation for the Microsoft Repository is available for browsing and/or download at their Web site, www.microsoft.com/repository. Details on the Microsoft/Platinum
agreements are available at www.platinum.com/.
- Microsoft Repository Programmer’s Guide
- IBM Systems Journal Vol. 29 No.2, “Repository Manager Technology”, p. 209
- The Essential Distributed Objects Survival Guide by Orfali, Harkey and Edwards provides an extensive description of Interface Repository, beginning on p.98.
