...
The CMDA design specification maintains the basic concept of a Fedora disseminator, but implements it differently. For one, it provides an indirect binding of behavior definitions/mechanisms to digital objects. It also opens up more possibilities for dynamic service-to-object mapping/binding in Fedora. The core Fedora development team already has a prototype of the CMDA design and will begin moving towards a production release for Fedora 2.3 or 3.0. See: http://www.cs.cornell.edu/payette/fedora/designs/cmda/
(NOTE: there is similar work is being done by others such as OWL-S and Semantic Web Services.)
...
- JMS: While we already mentioned the repository as a JMS provider (sending out API-M event messages), we should also consider using JMS as an alternate interface for API-M operations themselves (i.e., send messages to request that an API-M operation be performed. To do this, we must define appropriate message types and payloads to map to API-M operations.
- Native Java: Consider exposing a native java interface of existing API-M. Might also consider exposing a simplified java interface that maps to existing API-M operations (not sure what this simplified concept means).
- Java Content Repository (JSR170): develop a JSR170 interface on Fedora to enable Fedora to play according to this standard. JSR-170 is a JDBC-like API for content repositories. Note that this may have significant benefits in positioning Fedora in the CMS market. (See: http://www.onjava.com/pub/a/onjava/2006/10/04/what-is-java-content-repository.html)
- Also, think about other possible approaches, and also what is necessary to better accommodate an inversion of control architectural pattern with Fedora (meeting with Citeseer in May)
...