Repository Technology: A Key Enabler for Business Application Development

Microsoft Corporation
Texas Instruments, Inc.

October 1996

In today's heterogeneous client-server development environment, information is distributed across the private information stores of the tools that generate or use that information. There is no mechanism for managing a business application as a structured collection of interdependent components, including documentation, code, and data. Even if an application-development team uses a shared source-code library, the application structure must be inferred from the directory or project structure and file types. It is difficult for a developer to identify opportunities for reuse of designs, code, or services, or for an administrator to evaluate the impact of a change in one component on other dependent components. Subsets of the information—for example, inventories of third-party components—may be maintained by administrators in specially designed databases that they manage separately from the tools that generated them.

Integral to Microsoft Corporation's development tools strategy is the vision of a shared application structure database: a database of descriptive information about the structure of applications that is integrated with the tools that generate and use the information. This vision will be realized through incremental enhancements to Microsoft's suite of development tools and technologies. Building on the Microsoft® SourceSafe® version control system technology, Microsoft plans to combine database management system (DBMS) technology and new OLE services to deliver improved support in five key repository technology areas:

• Team development: Facilities to help designers and programmers manage concurrent activity on different versions and configurations of application design and development
  
  
• Reuse: Facilities for cataloging and locating relevant designs, code, and services (interfaces)
  
  
• Dependency tracking: Facilities for establishing and querying relationships between objects
  
  
• Tool interoperability: Facilities that allow analysts, designers, developers, and administrators to move easily between tools across the development life cycle and to manage related versions and configurations of application building blocks
  
  
• Data resource management: Global metadata for an enterprise data warehouse and a resource (tracking and reuse) library of available services and components

Today, team development is primarily supported through tool-specific and third-party source code control systems. Reuse and dependency tracking, when available, are facilities specific to the objects understood by a specific tool or tool set. Microsoft believes that the next step is to formalize and extend these facilities, moving incrementally toward the vision of an extensible, shared repository for heterogeneous tool interoperability. Data resource management will become a natural extension of a dynamic information base that is managed as an integral part of the design, development, and deployment process.

Microsoft and Texas Instruments Are Working Together in Repository Design

Today, Microsoft application development tools each have private, tool-specific repositories: development tools such as the Microsoft Visual Basic® programming system and the Microsoft Visual C++® development system maintain project files of related source-code objects; deployment tools such as Microsoft Systems Management Server maintain information about the packages it is to deploy; and so forth. Microsoft plans to improve the quality of its development environment by integrating these tool-specific repository functions. But corporations large and small have said repeatedly that client/server development in the enterprise is and always will be heterogeneous. For example, Texas Instrument’s Composer by IEF™ may be used to generate application servers whose interfaces are invoked by Visual Basic application code. This means that to deliver on an integrated tool information base, an enterprise repository technology strategy must enable the following:

• One API: A standard set of semantics for repository services and an open interface for invoking them
  
  
• One place: Data-management and integration technology that supports querying repository information and browsing the repository by traversing relationships
  
  
• One representation: A common tool-information model that allows tools to share information described in the model and to extend the model to define new types of things

The joint Microsoft–Texas Instruments repository design strategy addresses all three of these requirements. By teaming together on repository strategy, the two companies gain complementary expertise and the industry gains the assurance that any resulting product will be open and extensible. Texas Instruments brings technical expertise in the areas of repository technology, information models and tools, drawing on its experience with Composer by IEF and next-generation application-development tools. Microsoft brings experience in building high-performance, high-functionality integrated desktop and server tools. The planned combined result will be an entirely new repository design intended, in the long term, for broad use by the industry’s diverse tools.

Microsoft and Texas Instruments are committed to a design that they can turn into products that directly enhance their own product lines. Further, the long-term success of both companies depends on helping corporations realize the vision of component-based application development. To this end, an extensible feature set that allows heterogeneous tools to interoperate across the development life cycle benefits tool vendors and business application developers.

Microsoft and Texas Instruments Share a Vision of Application Development

How successful an industry can be in agreeing on a common information model will depend on sharing a vision of applications and application building blocks. These building blocks include the following:

• Models of the problem domain, such as data models and process models
  
  
• Components of the solution domain, such as forms, tables and procedures
  
  
• Descriptions of the operational environment, such as deployed components, users, platforms and data
  
  
• Relationships among all of them

As an integral part of the repository design activity, Microsoft and Texas Instruments are building a shared vision of business application development based on components that can be distributed across a heterogeneous computing platform as necessary to meet the needs of the enterprise. The next evolution of client/server computing will be characterized by the following:

• Increased emphasis on team development, in which applications will be constructed from components that are built by different teams or even different companies
  
  
• Heterogeneous tool environment as a given, that is, autonomous teams or companies with their own tool suites, heterogeneous computing platforms, evolving development methodologies, legacy systems and tools, and competitive advantage
  
  
• Increasingly complex version and configuration management, because each component has its own development life cycle
  
  
• Increasingly complex management and deployment issues, because applications are not just distributed but rely on shared components, blurring the notion of "application" as a discrete set of code and data
  
  
• Renewed interest in the benefits of reuse, from both technology and business perspectives, that is, consistent usage of business rules across the applications that invoke or enforce them. An enterprise will look for reuse opportunities at all levels: design, code, component object building blocks, and run-time sharing.

Given the complexities in managing applications as shared structures of autonomous components, repository technology will be equally relevant to small corporations and large ones.

The Microsoft–Texas Instruments Repository Design Builds on Database Technology

The Microsoft–Texas Instruments repository design approach is intended to be built on top of a database system. There are several benefits to taking this approach:

• Ability to manage nonfile objects, such as entities, tables, definitions, and forms, as well as files
  
  
• Ability to define and manage complex relationships between objects, with enforced referential integrity
  
  
• Ability to support complex queries, including navigating relationships
  
  
• Availability of standard DBMS facilities such as transactions and backup and recovery

The design includes three components. The first is the repository engine, the run-time support for repository functions that facilitate metadata management. These functions include the following:

• Version and configuration management. Design data evolves, and the repository needs to store snapshots of that design at different times: the deployed version, the newly released version, and the next release under development. Configurations allow the user to group related versions into sets that have a common purpose, such as all the versions in the deployed product. Together, version and configuration management support team development by helping designers and programmers manage concurrent activity.
  
  
• Relationship management. By establishing different types of relationships between objects, developers can locate related sets of objects, and administrators can track dependencies in the deployed components. Tools can use relationships to navigate between objects. For example, while operating on design object X in one tool, a user can find out which objects are related to X and can move control to one of those objects by launching the object's viewer or editor. Relationships also are useful for analyzing a complex design. For example, one can navigate from a bug report to the test that demonstrates the bug to the programs that are exercised by the test.
  
  
• Schema management. By providing facilities to create and modify object types and classes, tool vendors can extend the repository.
  
  
• Query. By supporting complex queries over relationships and properties, users can browse the repository, both within the context of a specific configuration and across configurations.

The second component of the design is the Common Information Model. Texas Instruments and Microsoft will define a useful starting set of object types and relationships as the basis for tool interoperability. Through the repository engine services, the object types and classes defined in the Information Model will be extensible.

The third component of the design is a set of generic repository tools for schema management and browsing the repository.

Most of the active use of the repository will occur through the tools used in application design, development and deployment. Tool interoperability will be supported through a combination of standard database functions (such as schemas, queries and transactions) and the information model. The design will support a range of integration options for tools.

OLE Is an Enabling Technology

The object model for the repository will be based on OLE technology. The repository will be accessed through OLE objects. These objects will support some existing OLE interfaces (such as Automation) and some new repository-specific interfaces (such as those supporting relationships and version and configuration management).

As a migration strategy, it will be possible to store yesterday's files as well as today's OLE objects in the repository. For file objects, the repository will provide basic facilities for check-in/check-out, dependency tracking, and so forth. However, the more repository-oriented OLE functionality that an object supports, the more value the repository can offer in support of browsing and reuse.

Microsoft and Texas Instruments Are Committed to Open Process

The Microsoft–Texas Instruments relationship is focused on delivering a specification for—not an implementation of—the repository design. The first deliverables that the industry can expect to see are an interface-specification and tool-information model. The industry will be invited to comment on this specification through an open process. The final specification will be published.

Once the interface specification has been reviewed and finalized, anyone then could build a compliant repository engine. However, we expect most tool vendors will use it to understand how to write to the repository interfaces and extend compliant repository implementations with tool-specific object types and relationships.

Microsoft's implementation plans include a selected set of repository services that conform to the specification. Initial emphasis will be placed on supporting a few useful tool interoperability scenarios very well. Over time, independent software vendors and customers will use this new repository technology to store their tool-specific and application-specific information that requires repository engine functions, such as relationships and version and configuration management. Tool vendors can do this using their own information model, in which case this information will be well-tuned to the tools that use them but may be hard to share with other tools and applications that use a different information model. Information that needs to be shared should conform to the repository's common information model.

Microsoft and Texas Instruments plan to store design information using the repository's common information model. One of the early supported scenarios will facilitate sharing between Microsoft and Texas Instruments tools, and we will explore early extensibility opportunities with other major independent software vendors.