C&C Shared-Data View
C C Shared Data View
6.1 C&C Shared-Data View Packet 1: The Data Management Subsystem
6.1.1 Primary Presentation
6.1.2 Element Catalog
6.1.2.1 Elements and Their Properties[14]
[14] Often, the shared-data view also includes element properties dealing with data distribution, the kind of data stored or transmitted, and performance or capacity properties.
Properties of Data Management Subsystem elements are
- Name, given in the following table
- Whether the element is a data repository, a data accessor, a synchronization operation, a message, or a query
- A description of the element
| Element Name | Type | Description |
|---|---|---|
| DictServ (DS) | Data repository |
Data Dictionary/Server: The primary server interface to collection and collection-related information for the DMS and other subsystems. It allows DDICT client processes the capability to perform data searches, insertions, updates, or deletions to the collection information held in the DDICT database. The Data Dictionary offers two basic interfaces. DDICT Data Search: The Data Dictionary Server allows a user to specify search requests on the Data Dictionary database, using a GIParameter List. DDICT Data Insert and Delete: Provides a client process with the capability to insert and delete data within the Data Dictionary database. The Data Dictionary Service supports
|
| V0GW (V0 Gateway) | Data accessor | V0 Gateway: provides access to data and services between the SDSRV CSCI and the V0 IMS. V0 GTWAY services include inventory searches, requests for browse data, product requests, and price estimate requests. |
| AsterGW (ASTER Gateway) | Data accessor | ASTER Gateway: provides access to data and services between the ECS Science Data Server and the ASTER GDS. Services include inventory searches, requests for browse data, product requests, and price estimate requests. |
| MTool (Maintenance Tool) | Data accessor | Data Maintenance Tool: provides a graphical user interface (GUI) to insert, update, or delete schema information held in the DDICT database, allowing DAAC operations staff to maintain the data stored in the Data Dictionary database. The Data Dictionary Maintenance Tool also provides the following capabilities:
|
| RPC | Synchronization operation | Remote procedure call via CORBA interfaces. See Communications and Systems Management Segment. |
| Sybase | Data repository | Sybase SQL server. |
| SQL | Query | SQL query. |
6.1.2.2 Relations and Their Properties
The relation of this C&C view is attachment, dictating how components and connectors are attached to each other. The relations are as shown in the primary presentation; there are no additional ones.
6.1.2.3 Element Interfaces
Interfaces for the elements shown in this view are specified under the corresponding element in the module decomposition view (Volume II, Chapter 1). To identify those elements, consult Volume I, Chapter 4.
6.1.2.4 Element Behavior
[omitted]
6.1.3 Context Diagram
6.1.4 Variability Guide
None.
6.1.5 Architecture Background
6.1.5.1 Design Rationale
- Technology issues. The Data Management Subsystem contains hardware resources for the persistent storage of data dictionary and schema data across one or more DBMS servers and will be sized to meet the demands on a site-by-site basis. The primary technologies used within this subsystem are DBMS servers, host-attached spinning disk, possible use of channel-attached RAID disk, and a variety of communications capabilities. Pools of local X-terminals and display workstations support administration, help desk, and data repository maintenance activities. At sites where client request rates are low and the data collections and schema relatively few in number and in scale, the option exists to share server and data repository resources with the Data Server subsystem's Data Repositories. This possibility will be explored as the physical database analysis matures in the future.
- Interface design. Here is an informal view of how the interface to this subsystem is intended to work. It may provide some insight into the more rigorous interface specifications presented elsewhere. The subsystem consists of three services:
- A distributed search service, called the Distributed Information Manager (DIM)
- A service called the Local Information Manager (LIM), that acts as the gateway between the data management services used by a site and the distributed search services
- A Data Dictionary Service, which provides data names and explanations of the data and access operations in a distributed fashion
Both DIM and LIM accept queries and data access requests for execution but do not process the queries. Rather, they act as search agents on behalf of the users by identifying the sources of this data, transforming the search and access operations into requests that are acceptable to these sources. Users interface with their agent DIM or LIM to determine the status of a search or to obtain the search results. They are decoupled from the actual sources, as well as from the methods their DIM and LIM agents use to perform the searches and obtain optimal results.
Users formulate their queries by using query user interface programs that are part of the client subsystem. The query user interfaces will interact with the Data Dictionary Serviceoften transparently to the userto present the user with choicesfor example, of the data names applicable in a particular contextand interpret user input. Any intelligence available in the Data Dictionary about this data can be used by the query interfaces to formulate the search: to improve its accuracy, for example. The Data Dictionary service is accessible to the components that process queriesDIM and LIMand the components that formulate queries, user query interface programs. As a result, a query interface can make references to data dictionary concepts that DIM and LIM can interpret. For example, a sciences user may enter search parameter names taken from a particular context, such as Atmospheric Dynamics. The query program will insert a reference to Atmospheric Dynamics into the query. DIM and LIM can then interpret the parameter names in the proper context.
- Two levels of query processing. The SDPS Data Management architecture uses two levels of query processing: the distribution level, which is serviced by the DIM, and the site level, which is serviced by the LIM. The two levels are motivated by the following considerations.
- Different concerns. A LIM provides an interface to a site. The inner workings of the site are hidden by its LIM, and each site can implement its own, specialized version of a LIM. DAACs and SCFs thus have the ability to decide how to best organize their data internally. On the other hand, the network needs only one type of DIM implementation, regardless of the number of LIMs. As a result, DAACs and SCFs need not be concerned about tailoring a DIM design to their requirements and implementing and maintaining DIM software.
- Distributed query processing. Distributed query processing poses a number of difficult issues, which SDPS plans to address in an evolutionary manner. Over time, the DIM design will be changed to provide better optimization of distributed searches or enhanced capabilities for merging search results. With a separated DIM, none of these changes will force DAACs and SCFs to change their LIMs. Nor will DAACs and SCFs have to address the issues of distributed searching in a wide area network when they implement the LIM software.
- Data administration concerns. Separation of DIM and LIM also simplifies data administration. The responsibility of each site is clearly defined and confined to the LIM as its interface into the data and information network. It is not necessary to coordinate the definition of a single, integrated schema across all sites. Instead, each site defines its schema only and has freedom in deciding what information to make accessible through it.
- New LIM services for new clients. One of the objectives of SDPS is that it provide DIM and LIM implementations for ECS. However, other organizations may want to join the network by developing their own LIM services. Separating the DIM functions from the LIM will make their task easier. In addition, organizations, such as commercial software vendors or universities, may become interested in developing new DIM versions, perhaps with special features that provide improved search capabilities, such as those tailored to specific science disciplines. A DIM that is separate from LIM components and their site-unique aspects will facilitate their work.
[etc.]
6.1.5.2 Results of Analysis
None.
6.1.5.3 Assumptions
- The provider sites within ECS can interoperate at three levels: tightly coupled, loosely coupled, or minimally coupled. The main impact on which level of interoperation is chosen rests with the type of schema integration versus federation that is supported at the Distributed Information Management level of the data management architecture. ECS assumes a loose coupling, which provides the most provider site autonomy. This leads to a federated schema with a global core schema. An important issue arises concerning the process to establish and maintain this global core. Although the initial global core schema will be established as part of the ECS data modeling activity, ECS assumes that a group will be chartered to define procedures for ensuring that it is used and maintained.
[etc.]
6.1.6 Other information
[omitted]
6.1.7 Related View Packets
- Parent: None in this view. View packets in other views showing the Science Data Processing Segment (SDPS) are beyond views parents.
- Children: None
- Siblings: None.[15]
[15] Thus, the shared-data style is limited to the Data Management subsystem in ECS. This is an example of a system exhibiting different styles in different places.