Unisys' UREP Points the Way - Software Review - Evaluation

Taking a realistic approach to metadata repositories, UREP is a practical tool for coordinated management of the data models, object models, workflow environment is creating.

THE TERM "REPOSITORY," when used by itself, can be quite misleading because it suggests any kind of storehouse of information. In contrast, the Unisys Universal Repository (UREP), from Unisys Crop., Blue Bell, Pa., is not intended to store just any kind of data. There is an abundance of general database products, and UREP does not compete with them. UREP is designed to manage and store metadata, and can sit on top of several commercial database products.

Many consider "meta" the dreaded M-word because it tends to intimidate and confuse the uninitiated. We can demystify it by saying that a metadata repository is simply a storehouse of models, be they data models, object models, workflow models, business process models, etc. These models are very valuable corporate assets and managing them effectively is important.

A big challenge to effective management of metadata is the fact that there are different kinds of models, each of which uses very different constructs. For example, relational data models are defined in terms of data bases, tables, columns, etc., while object models are defined in terms of classes, associations, inheritance, etc. In the late 1980s and early 1990s, number of corporate metadata repository projects attempted to solve the problem by defining just one set of constructs that would be used for all models, in other words, they tried fundamentally to have only one kind of model. This goal proved to be utopian. It was very difficult to use the same kinds of constructs for very different kinds of models because of technical obstacles and because of the difficulty of getting all departments in a company to agree on the constructs they needed to produce their models. Even when agreement could be reached within a company, the problem quickly resurfaced when models had to be exchanged with other companies or when mergers with other companies occurred.

UREP represents a new class of metadata repository. It is predicated on the notion that there will be multiple kinds of models. With UREP, you define a kind of model by defining the constructs that are used for that kind of modeling, such as tables and columns for data models. UREP provides a set of rigorous formalisms for defining these constructs. The formal definition of a set of constructs for a model kind is called a metamodel.

With this approach, very different kinds of models can flourish. What binds them all together and makes it possible to manage them in an integrated fashion in that all the different kinds of models define their basic constructs via formal metamodels defined in a way that the metadata repository can understand. With a rigorous definition (i.e., a metamodel) in hand of all the constructs that make up a particular kind of model, the repository system can make sense of those constructs and hence knows enough about the anatomy of models of that kind to manage them effectively. Thus, models of different kinds can be managed in an integrated fashion in a common tools.

The user base of UREP consists of third-party tool vendors and large enterprises undertaking component-based development (CBD) and model-driven architectures. As CBD and modeling grow in popularity, the customer base for this kind of product will grow as well.

KEY ELEMENTS OF THE UREP INFRASTRUCTURE

RSM. The formalism used to define a metamodel-i.e., to define the constructs used to build models of a particular kind-is obviously the crucial fulcrum of a metadata repository. UREP's formalism is called the Repository Services Model (RSM). A formal description of a metamodel is expressed in terms of RSM.

RSM resembles the Universal Modeling Language (UML) fairly closely. Therefore, UREP uses Rational Rose from Rational Software, Cupertino, Calif., as the medium for describing a metamodel. The user creates UML-class diagrams to express the metamodel. Because RSM and UML are not identical, UREP provides some Rose add-ins to support extra properties on metamodel elements that the base Rose product does not support. However, to someone familiar with UML and Rose, the process, of defining a metamodel is straightforward. Figure 1 is a somewhat oversimplified example of a very basic metamodel for relational database models.

This simple metamodel defines the main constructs used for building data models for a relational database. The associations between these constructs are precisely defined. For example, the strong aggregation association (red diamond) between Table and Column says that a Column's lifetime is dependent on that of the aggregating Table; that is, if a Table is deleted from a model then all of its Columns must be deleted as well. Note that the constructs inherit from UrepNamed Versioned Object, one of the types defined in RSM. This inheritance is required in order for UREP to be able to manage instances of these constructs in a repository.

The versioning system can maintain multiple versions of any instance of any construct in a repository whose type inherits from UrepNamed VersionedObject (or UrepVersionedObject). The version histories of each element form a directed graph, where the direction corresponds to the evolution of the instance over time. The directed graph can be rewound and forwarded, so that older versions can be restored without losing the ability to jump forward again to later versions.

SERVER CODE GENERATOR. For each kind of model it is necessary to generate a server that manages storage of models in a repository. The server code generator takes a metamodel as input and generates most of the code for the server. The generated code is C++. C++ classes are generated corresponding to each of the metamodel constructs. The generated classes have basic CRUD (create, read, update, delete) operations for managing instances of the constructs in a repository. For example, for our metamodel the generated Column class has operations for creating a Column, for getting and setting the data Type and length of a Column, and for deleting a Column. The generated Table class has, among other things, operations for getting and setting the Columns of which it is composed.

The generator not only produces the C++ class declarations, but it also generates most of the implementation code for the classes. It produces 100% of the code implementing the generated CRUD operations. It cannot generate implementation code for any operations that are declared in the metamodel. Our sample metamodel, for instance, declares an operation for the Database class that produces a list of all the column names for all of the tables in the database. The UREP server generator can generate the declaration of the corresponding operation in the C++ class, but it cannot generate the implementation because it does not understand the semantics (meaning) of the operation in the way that it understands the semantics of the generated basic CRUD operations.

When the code has been generated and any programmer augmentations finished, the resulting server manages the storage and retrieval of models of that particular kind. Clients that create, read, update, or delete models in a repository call the server, using its various generated CRUD operations to perform such work.

One of the most powerful aspects of UREP is that the implementations of the CRUD operations take into account subtle aspects of the metamodel, such as the life-cycle dependency implied by strong aggregation. In our example metamodel, the generated code guards against deleting a table without deleting the associated columns. To fully take advantage of the degree of automation that UREP's auto server generation provides, it is thus necessary to fill in all the properties of the metamodel precisely, such as multiplicities (0..1, or 0..*, etc.) on both ends of an association and aggregation characteristics, because the generated server's behavior is driven by these properties. For example, our model says, via multiplicities, that a Table cannot exist by itself outside the context of a Database. The generated server enforces that restriction, making it impossible to create an instance of Table that is not a property of a Database instance.

When you attempt to generate a server from a metamodel, UREP looks for inconsistencies in these properties and forces you to correct them before generation can proceed. Figure 2 shows portions of the generated C++ declarations of the CRUD operations corresponding to the Database class in our metamodel.

THE UREP API. UREP presents a C++ API that provides access to the repository system. The CRUD operations that are generated for a server actually call this API. Thus, one could use the API to hand code (in C++) a server for a model kind. However, that would be quite a painstaking task. The auto-generation of servers is provided to make it much easier to bring servers for new model kinds online.

For operations that are specified directly in the metamodel and which the programmer thus has to code by hand, this API is indispensable.

API TO DATABASES. UREP can use Versant, Oracle, or its own OSMOS as the database that physically stores models. UREP isolates the database from the rest of UREP by wrapping supported databases in a standard API. This API is part of the UREP API. Code that calls directly to Versant, Oracle, or OSMOS is separated by this abstraction layer.

CLIENT-SIDE BINDINGS. Since a generated metamodel server is C++ code, C++ clients are inherently supported. However, UREP has an option to generate bindings that support other kinds of clients. These bindings wrap the C++ server, For example, the COM Automation bindings wrap the C++ server so that the server appears to be a COM Automation object to a COM client. UREP also can generate bindings for Java clients and for remote (i.e., distributed) clients via a proprietary configuration of TCP/IP.

SPECIFIC METAMODELS PROVIDED. UREP comes with some already-implemented metamodels including, for each metamodel, a fully functional server, client-side bindings, and documentation. The relational database metamodel implementation supports the storage and manipulation of relational database models. The UML metamodel supports the storage and manipulation of UML-based object models. An upcoming release will support the Common Warehouse Metamodel, recently adopted by the Object Management Group (OMG).

XML. UREP has partial support for the OMG's XML Metadata Interchange (XMI) standard. Fundamentally, XMI is an algorithm for deriving a DTD from a metamodel. In other words, given a metamodel as input, XMI tells you how to automatically generate a DTD. If you feed an XMI generator a formal description of the constructs used to build a kind of model, the generator will produce a DTD that you can use to exchange models of that kind.

There are two basic forms of support for XMI. The first is support for XMI's algorithm for generating a DTD from a metamodel. Such support entails being able to read a formal metamodel as input and produce a DTD as output. The other form of support is being able to read and produce XML that conforms to a specific DTD generated via XMI for a particular metamodel. The UML metamodel's DTD--the DTD that the OMG has specified as the DTD for exchanging UML models--was generated this way.

UREP currently provides the latter kind of support, and does so specifically for the UML metamodel's XMI DTD. UREP includes an add-in for Rational Rose that enables Rose to read and write models to and from XML streams that conform to the XMI DTD for UML. Unisys says that upcoming versions will provide more complete support.

THE UREP ENVIRONMENT

THE CORE ENGINE. UREP's core engine executes RSM and generates servers. Originally, metamodels were described by declarative code in UREP's Object Definition Language (no relation to ODMG or Microsoft ODL). An ODL declaration of a metamodel was the input to the server code generator.

MODEL IMPORT. When UML tools appeared on the market, UREP was updated such that it can import metamodel descriptions from Rational Rose. UREP imports a metamodel from Rose by generating ODL. The ODL is still the input to the server code generator.

As mentioned earlier, UREP provides a Rose add-in that allows the specification of additional properties for model elements beyond the standard properties that Rose supports. Figure 3 illustrates the extra tabs that the add-in introduces into the standard Rose dialog for specifying the properties of an association.

The Rose add-in also provides an addition to the Tools menu (Figure 4). Note the "Export to UREP" option, which runs a script that enters the metamodel description into the UREP system.

MODELERS WORKBENCH. UREP has a set of command-line programs that generate servers and client-side bindings, create repositories, etc. Later additions to the environment include the Modeler's Workbench, a visual tool that wraps the command-line programs. Figure 5 shows its most important menu, which wraps most of the command-line programs. When you execute one of the menu options, UREP actually shows you the command program that it calls, replete with the command-line options. The visual environment captures the output of the called command-line program into a text file.

ADMINISTRATOR'S WORKBENCH. The Administrator's workbench enables management of users, groups, and sessions with respect to a specific repository, as shown by Figure 6.

UNIVERSAL REPOSITORY EDITOR. The Universal Repository Editor is another important UREP visual tool. It can serve as a generic client to any server registered in a repository. It has dialogs that provide access to any server's CRUD operations and for calling operations declared in the metamodel.

When you complete a metamodel server you install it in the system to make UREP aware of its existence as part of the run-time repository. A list of installed servers is accessible through the UREP API. The editor uses the API in this fashion to present the user with a list of model kinds corresponding to the different metamodel servers. The API allows other generic clients to be written as well; i.e., clients that do not have to be recompiled in order to access newly registered metamodel servers. UREP has a Web-based read-only

repository browser that uses this generic capability.

In Figure 7, the editor has been configured to show the existing instances of the elements of our example database metamodel. These instances populate a repository created with the Modeler's Workbench and, taken together, describe a data model. The embryonic data model shown in Figure 7 has one Database, two Tables, and two Columns. Note that the attributes shown in the right panel are inherited from UrepNamedVersionedObject. Our Database construct inherits from this RSM type, as shown by Figure 1.

Figure 8 shows an expanded view of the single Database instance. Its name (another attribute inherited from UrepNamedVersionedObject) is "Chico" and it has two Tables named "Account" and "Customer." This hierarchical structure shows that the repository not only contains the instances of Database and Table but, in addition, contains the links between the Tables and their owning Database. These links are instances of the association between Database and Table, which was declared in the metamodel via UML. The editor's dialogs allow these links to be created, read, updated, and deleted by invoking the server's CRUD operations. For example, the editor allows you to add a new Table to a Database, or to remove one of the Tables owned by a Database. However, the server that was generated for our metamodel does not permit a Table to be removed if it has instances of Column that it owns, because our metamodel declares, via multiplicity specifications in UML, that a Column cannot stand alone; i.e. it must have a link t o an owning Table.

The editor can access repositories remotely via the proprietary distribution mechanism mentioned earlier.

ASSESSMENT

THE UREP CORE. UREP's greatest strengths are its architecture and the mature core engine that implements RSM. The architecture is based on the premise that there is more than one kind of model, and multiple metamodels are a fact of life. RSM has a lot of history behind it, and it has been fundamentally object-oriented from day one. Administrators can be quite confident that the software will run effectively. The versioning capabilities are very sophisticated, and closely tied in with an effective transaction system.

Performance with Versant and OSMOS is significantly better than performance with Oracle as the database. Since RSM is object-oriented, an object-oriented database will tend to be faster than a relational database because an object-relational transformation is not required.

Developers of metamodel servers must have excellent C++ skills, particularly if there are requirements for enhancement of the generated server code. The code that the developer must enhance is all C++ and, as per the tendency with C++, is quite complex. Unisys recently demonstrated a beta version of a pure Java implementation of UREP, code named UREP/Java Component Repository (UREP/JCR), which will interoperate with the C++-based product.

INTEGRATION WITH UML. The integration with modern UML tools is also very important. UREP has grown with the times and the fact that metamodels can now be described with popular industry UML tools rather than using the old ODL approach is a big plus.

UML aficionados who use UML to describe UREP metamodels will find some disconcerting differences between what UREP expects and what is considered standard UML. This is due to the fact that RSM predates UML and thus is not entirely aligned with it. For example, when I attempted to export the metamodel shown in Figure 1 to UREP, UREP complained, saying that the multiplicity on the composite end of a composition association (i.e., a "strong aggregation") must be multivalued. This contradicts the very definition of composition in UML, which states that a component can be owned by at most one composite. UREP expresses some of the semantics of UML-style composition via the extra dependent property supported by the Rose add-in.

The good news is that a future release of UREP will conform to the OMG's Meta Object Facility (MOF), which Unisys played a major role in defining. The MOF constructs for defining meta-models are very tightly aligned with UML, so the disparaties between RSM and UML will be overcome.

The fact that an implementation of he UML metamodel is bundled with UREP is important. This means that UREP is already configured to manage UML models in repositories. The meta-model implementation is full-featured. UREP architects have been intimately involved in the definition of the UML metamodel at the OMG, and are well positioned to support this technology.

SEPARATION OF CONCERNS. An aspect of UREP that could stand improvement and that will be remedied by MOF-compliance is the tight coupling of implementation classes with logical metamodel constructs. Consider our simple metamodel in Figure 1. The fact that the logical elements of the metamodel (Database, Table, and Column) must inherit from specific RSM classes makes it difficult to reuse the metamodel in a non-RSM context. The MOF, on the other hand, makes a clean separation whereby a logical metamodel is technology-neutral and is used as input for generating artifacts of specific implementation environments. For example, the MOF has an algorithm for generating CORBA IDL from a logical metamodel, and Sun Microsystems is working on an algorithm for generating Java code from a metamodel. A technology-neutral metamodel can thus be used in many contexts. When XML started to sweep the industry, the neutrality of the MOF made it quite straightforward to develop the XMI algorithm for generating an XML DTD from a met amodel.

FACILITIES FOR DISTRIBUTION OVER A NETWORK. UREP does not support CORBA; it uses a proprietary TCP/IP-based technology for allowing clients and servers to communicate over a network. However, Unisys has announced that the beta pure-Java version of the product is MOF-compliant and supports the MOF-based CORBA interfaces.

ROUND-TRIP ENGINEERING. The round-trip engineering facilities of UREP are limited. There is some support, in that it is possible, after generating and enhancing the server code to iterate back to the metamodel to add new elements and then update the server code accordingly. However, round-trip engineering does not work as well when making more complex modifications to the metamodel, once programmers have made enhancements to the generated server code. Unisys says that upcoming products will provide more sophisticated round-trip engineering support.

DOCUMENTATION. The documentation provided with UREP is mostly a set of reference manuals. These are quite thorough, and are in the form of PDF files. I was also given a prerelease copy of an HTML-based tutorial, which took me through the basic mechanics quite nicely. The implementation of the UML metamodel comes with a Windows help file.

I also took the UREP training course. Unisys offers a two-day architecturally oriented class, and an additional three days for developers. Despite the fact that the documentation is reasonably good, this is a complex product. I recommend that architects who are going to be involved with UREP take at least the two-day class. Developers should take all five days.

CONCLUSION

UREP is arguably the first and most mature metadata repository product architected to support multiple metamodels. It is a practical tool for coordinated management of the increasing volume of data models, object models, workflow models, and business process models that the corporate environment is creating. Moreover, as key architects of the MOF, Unisys should be able to provide a smooth upgrade path to a future MOF-aligned version of UREP.

David S. Frankel is chief scientist at Genesis Development Corp. (www.gendev.com). West Chester, Pa., a company that specializes in bringing component strategies and solutions to e-commerce. He is a member of the OMG Architecture Board, and is co-chair of the OMG's Business Object Initiative Working Group.

COPYRIGHT 2000 Wiesner Publications, Inc.
COPYRIGHT 2000 Gale Group