You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Next »

  1. Infrastructure  Deployment
    1. The API-X framework shall be deployable on a separate host from Fedora
      • HTTP requests from the outside world are routed to these instance(s) before being forwarded to their ultimate destination (Fedora, backend service, etc)
    2. The API-X framework shall be deployable within the same container as a Fedora instance
    3. The API-X framework shall be deployable as an extension to Fedora
      • This would allow standalone Fedora installs to deploy API-X extensions within them
    4. It shall be possible to deploy multiple instances of the API-X framework for the sake of scalability of high availability
    5. The API-X framework shall be deployable as OSGi bundles
      1. The API-X framework will be available as a Karaf Feature, for ease of deployment into Apache Karaf
  2. Extension Deployment
    1. Individual extensions shall be deployable as OSGi bundles
    2. Instances of extensions shall be hot deployable and removable at runtime
    3. API-X shall allow configuration of extensions through OSGi's own ConfigurationAdmin service
    4. Creating multiple instances of extensions via ConfgurationAdmin factory pattern shall be allowable
      • i.e separately configured instances of extensions may be created via means defined by OSGi. 
  3. Patterns
    1. API-X shall support a filtering pattern in extensions, where an HTTP request to an existing Fedora URI (or response) is routed through an extension and possibly modified in the process
      • The extension is free to do whatever it wants to the request, including route it to an alternate destination, or respond directly
    2. API-X shall support exposing new URIs associated with individual repository resources, bound to individual extensions
    3. API-X shall support exposing URIs associated with the global repository a whole, bound to individual extensions
    4. APi-X shall support a proxy pattern in extensions, where requests to a URI exposed by an extension are proxied to some other web service
      • This can also be seen as implicitly URL rewriting
  4. Service Discovery & Binding
    1. It shall be possible to enumerate the list of all extensions deployed and active within the framework
    2. It shall be possible to enumerate the list of extensions that provide services on a given object in the repository
    3. For any given object in the repository, it shall be possible to enumerate all URIs exposed by extensions
    4. API-X shall provide a mechanism for HTTP clients to discover all URIs exposed by extensions on a given object
    5. It shall be possible to bind extensions to all objects in the repository
    6. It shall be possible to bind extensions to specific objects in the repository, based on their rdf:type

 

  • No labels

All content on the LYRASIS Wiki is licensed under the CC BY (Attribution) license, unless otherwise noted.