next up previous contents
Next: 6 Application of the RASSP Reuse Approach Up: Appnotes Index Previous:4 Implementation of the RASSP Configuration and Authorization Management Models

Reuse Methodology and Implementation Appnote

5.0 The RASSP Reuse Data Manager Architecture

As described above, sources of reusable designs may include those created within an engineering design organization, CAD tool libraries, CAD tool-independent libraries, released designs managed by product data management (PDM) systems across the enterprise, related business and engineering information, and component vendor data, among others. To query and access these heterogeneous sources of design data, the RRDM provides designers with a common view of the virtual reuse repository. Syntactic and semantic differences among the various source file systems, libraries and repositories are resolved through a common vocabulary representing their union and mapping algorithms that relate the source vocabularies to the common view. The underlying knowledge engine that manages the common vocabulary, maps that vocabulary to the various distributed sources of reusable engineering design data in the environment, and provides a common user interface / single entry point from which users can search for, view and access candidate designs and related information is known as the Sandpiper Software Intelligent Information Broker (IIB). This section details the high-level architecture and concept of operations of the IIB as applied in the RASSP environment.

The environment in which the RRDM operates is illustrated in Figure 5 - 1, and consists of the following components:

Figure 5 - 1: RASSP Reuse Data Manager Environment

End users include, among others, designers who interact with the system directly or through integrated applications such as product data management (PDM) systems, workflow managers, CAD tools, or other systems in their environment.

The intelligent information broker (IIB) provides the capability for users to search for and retrieve design knowledge (or other related engineering and business information) stored in their distributed environment through the common vocabulary. This vocabulary is implemented as a group of internal repositories of descriptive information that describe the terms defined for the domain, the locations and characteristics of source repositories, characteristics of the mapping from source repositories to the common vocabulary, user authentication information, and so forth. The IIB provides the capability to search stored meta-data for design knowledge, regardless of whether the objects themselves are managed by the broker or externally.

The information broker (shown as an "application server") acts as middleware, integrating end users (or "clients") with the various sources of design knowledge in their virtual environment. IIB functionality has been partitioned between the application server, JavaŠ applets integrated with the user's Web Browser, and the source database servers that comprise the cooperating environment. Integration of external applications is enabled through Common Object Request Broker Architecture (CORBA) application programming interfaces (APIs).

Figure 5 - 2 highlights the prototype IIB architecture as implemented in the RASSP environment. As mentioned above, users interact with the system either directly through a JavaŠ-enabled web browser or through other applications that have been integrated with the IIB through CORBA-compliant APIs. As stated in the Architecture of the RASSP Enterprise System, section 2, a number of enhancements are planned over the course of the next 18 to 24 months that include commercialization of the broker and development of ancillary tools to support its implementation in various environments.

At the heart of the IIB is the Perspectives Server, which provides the intelligent search and information brokering function in support of user requests. From these user requests, it generates queries to the associated source repositories. The Perspectives Server maps the user's query from either the common vocabulary or a customized, user-specific vocabulary to the physical back-end repository implementation notation (e.g., SQL, C++), returning the requested data to the user in a user-specified format.

Figure 5 - 2: Sandpiper Software Intelligent Information Broker Context

The IIB provides native support for sets of tightly-coupled back-end database servers. These tightly-coupled federations have similar schemas and may be mapped to one another and the common domain vocabulary through a single source vocabulary. For source repositories that are sufficiently dissimilar, separate (distinct) source vocabularies will be integrated with the IIB. A single federation of source repositories may be represented by multiple vocabularies, each providing different views (e.g., by a standard, by taxonomy, by function, by product) of the underlying data. User selection between these views enables access to the data in a manner most appropriate to the task at hand.

The Perspectives Server also describes the mapping between the users' preferred view and the common vocabulary for a domain. The user's custom view may include attributes from multiple classes, constraints on display characteristics, such as preferred currency or units of measure, and so forth. These views are also encoded as ontologies based on Ontolingua and KIF.


next up previous contents
Next: 6 Application of the RASSP Reuse Approach Up: Appnotes Index Previous:4 Implementation of the RASSP Configuration and Authorization Management Models

Approved for Public Release; Distribution Unlimited Dennis Basara