Action Framework

Description

The Action Framework was designed as a way to limit dependencies between Applications (apps) in a system. For instance, a feature in an App such as a Atom feed generator might want to include an external link as part of its feed's entries. That feature though does not have to be coupled to a REST endpoint to work nor does it have to depend on a specific implementation to get a link. In reality, the feature does not care how the link is generated, but mostly that the link will work in retrieving the intended entry's metadata. Instead of creating its own mechanism or adding an unrelated feature, it could use the Action framework to query out in the OSGi container for any Service that can provide a link. This does two things: (1) it allows the feature to be independent of implementations, and (2) it encourages reuse of common services. 

The Action Framework consists of two major Java interfaces in its api:

1. ddf.action.Action
2. ddf.action.ActionProvider

Usage

If wanting to provide a service such as a link to a record, one would implement the ActionProvider interface. An ActionProvider essentially provides an Action when given input that it can recognize and handle. For instance, if a REST Endpoint ActionProvider was given a Metacard, it could provide a link based on the Metacard's ID. An Action Provider provides an Action when given a subject that it understands. If it does not understand the subject or does not know how to handle the given input, it will return null. An Action Provider is required to have an ActionProvider id. The Action Provider must register itself in the OSGi Service Registry with the ddf.action.ActionProvider interface and must also have a service property value for id. An Action is mostly a URL that when invoked provides a resource or executes intended business logic. 

Taxonomy

An Action Provider registers an id as a service property in the OGSi Service Registry based on the type of service or Action that is provided. Regardless of implementation, if more than one Action Provider provides the same service, such as providing a URL to a thumbnail for a given Metacard, they must both register under the same id. Therefore, Action Provider implementers must follow an Action Taxonomy. 

The following is a sample taxonomy 

1. catalog.data.metacard shall be the grouping that represents Actions on a Catalog Metacard
   
   1. catalog.data.metacard.view
   2. catalog.data.metacard.thumbnail
   3. catalog.data.metacard.html
   4. catalog.data.metacard.resource
   5. catalog.data.metacard.metadata

Action ID service descriptions