Conceptual architecture
The diagram below shows the high level functional blocks needed for a registry service implementation. This is not a formal component architecture. There are many ways that the registry service could be structured internally. The only formal component interfaces are the external interfaces defined in the Api specification which in turn reference open standard specifications, particularly SPARQL 1.1. The example functional breakdown shown here is meant to be illustrative, in order to understand the functionality that must be delivered, rather than prescriptive.
- Dispatcher
- Request processor
- Auth
- Audit trail
- Registry core
- RDF store
- Text index
- Federation manager
- Renderer
- Access UI
- Admin UI
All requests to the registry service are made over http(s) connections which are initially received by the dispatcher.
The dispatcher has the following responsibilities:
Forwarding. Parts of the registry URI space can be configured to forward to other remote services by means of an HTTP (status code 30x) response. This is configured by means of NamespaceForward or FederatedRegister registrations. The dispatcher provides an internal interface by which the registry core can dynamically update the set of forwarding rules current in effect.
Proxy. Optionally a registry service may support proxy forwarding as well as redirection. The advantage of this is that the delegation target URIs do not appear in the HTTP response. The disadvantage is that raises scaling challenges because the connection to the proxied service must be held open until a response (or timeout) is received and such connections can be a significant limiting factor on some implementation platforms. A registry service to chooses to implement proxy support MAY choose to aggressively cache remote responses to manage this cost.
Request filtering. Request which are not forwarded MAY be subjected to additional filtering rules including, but limited to, rejection of blocked user agents (e.g. banned crawlers), rejection of block IP addresses, request throttling to manage server load especially in response to suspected denial of service attaches.
Dispatch. All requests that are neither forwarded nor filtered are then dispatched to the relevant internal service. An implementation may choose to partition and structure the internal services and dispatch processing in many ways, including internal HTTP routing to replicated or specialized internal servers. In that case the dispatcher acts as a reverse proxy for the internal service architecture.
Logging. All external requests should be logged using normal web server logging practises.
In the example functional partitioning shown in this conceptual architecture then there are two dispatch targets the request processor which handles all registry specific APIs requests and the RDF Store to which raw SPARQL queries are routed.
The request processor takes all registry API requests passed by the dispatcher and determines if they are authorized to proceed. This involves:
- converting the request payload to an normalized internal presentation
- identifying the action requested and action target
- authenticating the requesting user
- testing if the user is authorized for the requested action on the target resource
- logging the request and authorization outcome in an audit trail log
If the action is authorized it is passed to an appropriate internal registry interface supplied by the registry core.
The registry service is required to support a range of MIME types in which the RDF request payload can be supplied. The mandatory types are application/rdf+xml and text/turtle. Optionally application/ld+json may be supported. The request processor is responsible for converting these request syntaxes into an internal RDF form for supply to the registry core.
The auth module provides the authentication and authorization services used by the request processor.
User authentication should be based on standard web service security practises, for example Basic Authentication over HTTPS. The credentials database for user authentication is a matter for the service implementation but SHOULD be separated from the registry RDF store.
The authorization process should support a role-based access control mechanism whereby users are assigned to roles and roles are permitted a range of actions on each sub-tree of the registry namespace.
In some registry service settings the roles and the users assigned to those roles may be publicly accessible in which case the role and role-user bindings MAY be held in the registry data store and/or may be accessible as configuration registers under the /service reserved namespace.
The audit trail is primarily responsible for recording all processed requests at the level of registry actions and the associated authorized user.
This supplements, not replaces, the dispatcher’s web server logs. The audit trail provides for more convenient application level trace back which can help with both service maintenance and verification.
It is up to the service operator to define the level of audit logging required for a particular implementation. This may range from no such logging required though to a complete journal-ed record sufficient to enable the entire registry state to be replicated in the event of complete storage and storage backup failure.
This module provides all of the “business logic” to implement the registry API actions as a set of transformations of the RDF representations held in the RDF store.
We describe its operation in terms of three sub-modules:
The bulk of the defined registry API provides a set of ways in the registry state can be updated. Specifically:
- Registration of new entities within a register.
- Creation of new sub-registers.
- Updating the description of a registered entity (whether the canonical description of a managed entity or the registered partial description of a referenced entity).
- Updating the metadata describing a registered entity (register item).
- Changing the status of a register item, a special case of the above.
- Deletion of registers and registered items (equivalent to changing the status to invalid).
The update logic provides implementations of each of these specific actions.
In all cases a set of action-specific validation steps is run before the action is permitted. The validation module provides common facilities reused by the separate action functions.
If the action is validated the logic for each action involves updating one or more of a register, a register item and an entity reference resource. In each case there are API specific rules to determine the new desired state including merging of current and submitted state, default-override rules and automated properties.
>>> working here
query
life cycle state
may be separated
may be replicated
version exposed to public endpoint may be isolated
| Component | Proof of Concept | Deployment |
| Dispatcher | Required, non scalable | Scalable forwarding |
| Request processor | Required | Required |
| Auth | No | Required |
| Registry core | Partial, some operations may be stubbed out | Full |
| RDF store | Required | Required |
| Text index | Local index | Index external registers |
| Federation manager | Stub | Full |
| Renderer | Required | Required |
| Access UI | Demonstration level | Full |
| Admin UI | No | Required |