Group: org.apache.oodt - All Dependencies
Catalog and Archive Workflow Management GUI Editor · Apache OODT Workflow Editor GUI
OODT Web Grid · The OODT grid services (product and profile services) use CORBA or RMI as their underlying network transport. However, limitations of CORBA and RMI make them inappropriate for large-scale deployments. For one, both are procedural mechanisms, providing a remote interface that resembles a method call. This makes streaming of data from a service impossible, because there are limitations to the sizes of data structures that can be passed over a remote method call. Instead, repeated calls must be made to retrieve each block of a product, making transfer speeds horribly slow compared to HTTP or FTP. (Block-based retrieval of profiles was never implemented, resulting in out of memory conditions for large profile results, which is another problem.) Second, both CORBA and RMI rely on a central name registry. The registry makes an object independent of its network location, enabling a client to call it by name (looking up its last known location in the registry). However, this requires that server objects be able to make outbound network calls to the registry (through any outbound firewall), and that the registry accept those registrations (through any inbound firewall). This required administrative action at institutions hosting server objects and at the institution hosting the registry. Often, these firewall exceptions would change without notice as system adminstrators changed at each location (apparently firewall exceptions are poorly documented everywhere). Further, in the two major deployments of OODT (PDS and EDRN), server objects have almost never moved, nullifying any benefit of the registry. This project, OODT Web Grid Services, avoids the prolems of CORBA and RMI by using HTTP as the transport mechanism for products and profiles. Further, it provides a password-protected mechanism to add new sets of product and profile query handlers, enabling seamless activation of additional capabilities.
OODT Process Control System JAX-RS service layer · A web application for exposing services form the underlying OODT Process Control System via the JAX-RS specification.
Apache OODT Configurable OPeNDAP Profile Server · A generic, configurable Apache OODT profile server implementation that easily connects to OPeNDAP data sources. Connections are configured via an XML configuration file, providing information on how to extract and translate datasets from OPeNDAP and THREDDS into OODT profiles.
XML-configured, DBMS-based Product and Profile Server · An XML-configured DBMS-based Product and Profile meant to easily sit on top of Web-Grid and other Product and Profile server contexts for rapid deployment and integration.
CAS PGE Adaptor Framework · Allows data processing jobs not written in conformance with the PCS PGE (Production Generation Executive) interface to be run within the PCS.
Catalog and Archive File Management Browser · The graphical front-end interface to the Catalog and Archive Service. This component provides the user of the CAS File Manager with a graphical environment in which they can view archived products' metadata, query for products with particular metadata, and export results of queries to the MS Excel(c) file format.
OODT CAS Virtual Catalog and Integration Service. · CAS Catalog is an effort to virtualize underlying catalogs for use in the CAS system. Heterogeneous catalog models are mapped to a common dictionary, and then integrated locally so that they may be queried across and ingested into.
OODT :: Archetypes · Ways to quickly get started with some of OODT's components
CAS Curation Interface · A web application for managing policy for products and files and metadata that have been ingested via the CAS component.
CAS Workflow REST Services · A set of REST-ful services for the Workflow Manager.
CAS File Manager Webapp Application · A webapp for managing products and files and metadata that have been ingested via the CAS File Manager component.