Community:NCore/Implementation/Web Service Internals
From NSDLWiki
Contents[hide] |
Overvivew of the NDR API middleware Internals
The basic flow of information through the NCore web service and middleware is as follows:
- NDR API web request is recieved and parsed
- Depending on the API call in the request, the request is compared with authorization credentials (can agent X be making this request?) and passed through a series of filters which may modify aspects of the request.
- The request is then processed by some Action class, which performs a number of operations on an NDRAccess instance in order to fulfill the request.
- The result(s) for the request are returned to the user.
A more detailed explanation of the various components in their default configuration follows.
Action classes
Various Action classes perform the necessary functions for completing an NDR Web service API request. The current implementation (1.1) is based on Struts. In that sense, each Web API request maps to exactly one Action class to perform all necessary actions (such as Find, Add, Delete, etc).
Ideally, the only way these action classes can read or modify data in the repository is through an NDRAccess instance provided to them. This is the same NDRAccess interface as is exposed to developers via the Java API in the NCore toolkit. However, as of 1.1, that is not yet entirely the case. There are a few Action classes that assume that there is a Fedora instance underneath that all data is written to or read from. This will hopefully be remedied in future releases in the near future.
Filtered NDR Access
In the canonical NDR server installation, the NDRAccess is implemented by FilteredNDRAccess. FilteredNDRAccess intercepts calls to NDRAccess, invokes a configurable set of filters which may perform actions or modify objects passing into or out of the repository, and invokes a delegate NDRAccess instance to actually read or write to the repository.
Examples of filters include:
- ContentModelFilter, which enforces the NCore content model upon commit() of any object in the repository.
- HandleManagementFilter, which creates and registers handles for new objects.
- DefaultAuthorizationFilter which adds a default authorizedToChange relationship to new Aggregators or MetadataProviders (pointing to the Agent that owns it, if none is provided.
NDR Access Delegate
FilteredNDRAccess essentially acts as a decorator to an underlying NDRAccess "driver". With a suitable driver, the entire stack of services in the NDR middleware should work (soom that will be the case...). Different implements of this driver could allow for some interesting configrations and capabilities in the concept of this web service middleware. For example:
- NDR Web API -> Fedora. This is the default case
- NDR Web API -> Fez/Fedora.
- NDR Web API -> Multiple fedora instances.
- NDR Web API -> (Multiple) NDR Web API. This is essentially a single access point to a federation of NDR services.
Creating an NDRAccess driver means implementing the following interfaces:
