Canvas now exposes the notification/alert capabilities and metadata retrieval as microservices which can be readily consumed. Earlier it was monolithic server side architecture with the UI and server components interwoven and exposed as single unit. Now the server side components have been restructured after implementing the independently functioning services (Microservices) by distributing the requests to individual microservice components.Benefits of implementing Microservices are:
- Independent deployment of modules.
- Load distribution in the server.
- Reduction in server startup from 7 seconds to 1 second.
- Cloning multiple copies of the container making it faster to process the requests. This increases application scalability.
The incoming requests are split and distributed across the container based on calls specific to server and calls specific to microservice components. Therefore instead of one server handling all the requests, these are routed across server components to process the request.
To deploy and orchestrate the services, Docker images are created to encapsulate the microservice and deploy those in the server. Docker images will be created for each microservice component to create a stable environment with the necessary WAR.Implemented Microservice componentsoffers Microservice capability for its existing functional modules which restructures the monolithic interwoven server-side architecture into independently functioning Microservices. However, by default all requests will continue to follow the existing route (monolith style). Implementation teams have the choice of either using the microservices offered by Canvas or use the default monolithic architecture. When using Canvas’ microservices, all client requests on your application will be distributed to respective individual microservice components to balance the load.
The functional capabilities that are now exposed as independent microservices that can be readily consumed are:
Metadata service
The Metadata microservice fetches the metadata of various Canvas components such as view, form, widget etc. Canvas provides two mechanisms for fetching the metadata namely, Java and Node JS. The Java service for fetching the metadata is inevitable whereas the Node JS is an optional one for the implementation teams. The Metadata service internally chooses to invoke a Mongo service or the in-memory cache to fetch the metadata based on the respective mechanisms chosen.- Node JS Metadata Service
The Node JS metadata service is an event-based model where each service request is processed as an event. The threads for handling each request are passed to event handlers to fetch the metadata from cache. The Node JS metadata service stores, retrieves, and processes data in JSON format, thereby avoids data conversion from JSON to Java objects (Maps) and vice versa. - Java Metadata Service
The Java metadata service is a thread-based model where each service request is processed as a thread. It loads the metadata from the database for the first time and stores it as an in-memory cache from which it serves the consecutive requests. The storage and retrieval of data involve data processing as it works with the table data directly. When the Node JS service is down, the requests to Node JS are routed to Java service to process them.
- Node JS Metadata Service
Business Data Cache service
The business data cache service fetches the application data such as user details, product details etc. to be displayed in grids, charts etc. The business data cache service exposes the data fetching operation as APIs and the data are retrieved from MongoDB cache. These APIs can be used to access the business data using named services where the service returns the data based on entitlements.Note The implementation teams have to provide their application JAR to Canvas team to bundle the application JAR along with this service to fetch business data from application tables.
- Authorization service
The authorization service handles the requests to fetch entitlements of a user. It returns the respective entitlement details mapped to the user from Redis storage. Therefore, for all incoming requests, Canvas checks the entitlements of the user using the authorization service. These entitlements will be verified to determine whether the request can navigate for further processing. Authentication service
The authentication service is a security mechanism that verifies the authenticity of the incoming request with the JSON Web Token (JWT ) security token attached to it. When the user logs in, Canvas creates a JWT with details embedded in it, which will help authenticate the subsequent requests. All further requests will have this JWT as a cookie and will be used to identify the User and Session.
- Notification service
The notification microservice is a standalone module that handles all requests to audit and alert events and sends out alerts/notifications to the end users via multiple channels like Email, SMS, Push Notifications and Inbox. These notifications can be sent based on priority viz. high, medium, low. Notification service also comes with a Quartz scheduler that can schedule a specific task to be executed at a specified time.
Refer the following topics for more information