-
Notifications
You must be signed in to change notification settings - Fork 44
Middleware Design
Opensaber middleware is an independent set of plug-able software components which handles the data that goes into the registry. The middleware will be designed to perform a number of operations such as data manipulation, validation and application of rules specific to each registry. Each functionality will be an independent component and the middleware can be customised in such a way that it could be a mix and match of any number of these components which combine to form the middleware for any registry.
- Perform token based authentication and authorisation for each request
- Serialize the data
- Perform format changes such as conversions between JSON-LD and RDF formats
- Validate the incoming request data based on registry specific rules
Middleware is being currently designed using Interceptors in spring framework. As the name suggests, it intercepts incoming requests and outgoing responses of an application. Thus giving us a control on the data flow within the application. It provides handlers which are capable of manipulating the data within the request and response and also control the data that is sent to the view.
Spring interceptor is created by implementing the HandlerInterceptor interface in spring framework. This interface involves three methods - preHandle, postHandle and afterCompletion.
- preHandle - This method is executed before the handler of the request is invoked, for e.g. the controller in our application.
- postHandle - This method gets invoked after the handler invocation is complete, but before the response is rendered
- afterCompletion - This method gets invoked after the request is completed, mostly used for cleanups
- Interceptors are plug-able and configurable, hence they can be added or removed from the application anytime.
- They can be customised to run in any order
- They can be customised for each specific route, each route pattern within the application, or the entire application
- Custom ones can be created and configured as required
- They provide access to response before the view is rendered
- They also provide option to do cleanup after the view is rendered
This feature accepts data in JSON-LD format and converts to RDF format. Suppose an entity needs to be added to a registry. The data in the request is in JSON-LD format. The data needs to be converted to RDF format before it is saved into the database. This can be handled by an interceptor, which handles every incoming request to save data, validates the JSON-LD format and converts it into RDF before it reaches the handler i.e. the controller of the request.
This feature accepts data in RDF format and converts to JSON-LD format. When an entity is read from the database, it needs to be converted to JSON-LD before the response reaches the view. This can be handled by an interceptor, which handles every outgoing response and converts it into JSON-LD.
A token based authentication is a mechanism by which a unique token is generated for each user and this token is included in every request to authenticate or authorize the user. When a interceptor handles this scenario, it will accept the incoming request, read the token and validate it to authenticate/authorize the user. If the token is invalid, it will not proceed with the request and instead pre-handle it by sending an appropriate response to the user. It will prevent the request from reaching the handler of the request. Since interceptors are configurable, a custom authentication/authorization mechanism could also be used instead of this token based system.