DDF Catalog

Owned by Shaun Morris
Last updated: May 24, 2013Version comment
1 min read

Overview

Role

The

DDF

 Catalog provides a framework for storing, searching, processing, and transforming information.  Clients typically perform query, create, read, update, and delete (QCRUD) operations against the Catalog.  At the core of the Catalog functionality is the Catalog Framework, which routes all requests and responses through the system, invoking additional processing per the system configuration.

Design

The Catalog is composed of several components and an API that connects them together. The Catalog API is central to

DDF

's architectural qualities of extensibility and flexibility. The Catalog API consists of Java interfaces that define Catalog functionality and specify interactions between components. These interfaces provide the ability for components to interact without a dependency on a particular underlying implementation, thus allowing the possibility of alternate implementations that can maintain interoperability and share developed components.  As such, new capabilities can be developed independently, in a modular fashion, using the Catalog API interfaces and reused by other

DDF

 installations.

Ensuring Compatibility

The Catalog API will evolve, but great care is taken to retain backwards compatibility with developed components.  Compatibility is reflected in version numbers.  For more information, see the Software Versioning section in the Integrator's Guide Appendix.

Catalog Architecture

Unable to render {include} The included page could not be found.

Catalog Components

  • Catalog Framework — the core of the Catalog application, routes requests and responses between all Catalog Components
  • Catalog Plugins —  process Catalog operations, generally before and after they are executed
  • Data Components — representations of data in the Catalog, primarily metadata represented as a Metacard 
  • Endpoints — components that accept external requests and interface with internal components, normalizing the request and denormalizing the response 
  • Eventing — allows endpoints (and thus external users) to create a "standing query" and be notified when a matching Metacard is created, updated, or deleted
  • Federation —  provides the capability to extend the DDF enterprise to include Remote Sources, which can include other instances of DDF
  • Operations — represent all transactions that occur in the Catalog, including requests and responses 
  • Resource Components — used to work with Resources, i.e., the data represented by the cataloged metadata
  • Sources —  connect Catalog components to data sources, both local and remote
  • Transformers — transform data to and from various formats