Applying Micro Kernel pattern for Messaging Middleware

I was browsing through my digital archive and chanced upon this old white paper of mine written in 2014. Excerpts re-published here.

1.     Abstract

The objective of this paper is to introduce Micro Kernel pattern as the foundation framework for a typical messaging middleware that process online service requests and provide standard functions of validation, routing, enrichment, mapping and orchestration of transactions.

2.     Problem Statement and Opportunities

• Considering the situation of constant changes, progressive building of capabilities, frequent changes to fundamental service functions (until the functions mature into stable state for payments), plug-n-play mode of adding interfaces to product platforms, phased on boarding of payment types, there is an opportunity to enhance the platform to an adaptable framework making it capable of participating in continuous integration delivery cycle.
• Case Study Note: The current architecture is already SOA based, loosely coupled set of services built using IBM Websphere Message Broker. The enhancement proposed here is primarily a driver to identify gaps and enhance the platform to as much resilient, adaptable and extensible as possible.

3.     Benefits of Enhancements

Some of the advantages identified in going for the changes

• Reduce cost of development and unit testing interfaces added by future projects
• Increased resilience of Accounting Hub services, as the components are simplified and the micro hub should abstract core system functions
• Simplified code base and refined set of framework components
• Improved regression of changes, as the core components will not be changed for adding interfaces
• Highly scalable platform architecture, with distinct components and functions to leverage improved processing performance
• Extensible architecture allowing for future enhancements to core functions in a modular pattern
• Automated Testing framework – The reorganised components allow for simplified regression test suite, which can be automated, though as a separate work execution independent of platform changes
• Continuous Integration – The changes will enable visionary strategy to build a platform that complies to cutting-edge “continuous integration” state, where by, a factory of events will drive continuous execution of change, SCM, build, deploy, configure and test the platform codebase automatically or event-driven.

4.     Architectural pattern – Microkernel

• Main objective of this paper is to propose an architectural pattern suitable for addressing the Resilience nature and futuristic vision of continuous integration – MicroKernel
• The Microkernel architectural pattern applies to software systems that must be able to adapt to changing system requirements. It separates minimal core functionality and customer-specific parts. The microkernel also services and a socket for plugging in these extensions and coordinating their collaboration
• This pattern, generally used to build operating systems and system software shells, is of late applied to application design as well.
• Encapsulate the fundamental services of application platform in a microkernel component
• Microkernel includes functionality that enables other components running in separate processes to communicate to each other; maintain system resources
• Internal servers, external servers, adapters, clients, microkernel form the core components of the pattern

5. Microkernel – components

• Microkernel – Main component of the pattern, Encapsulates system specific dependencies, Maintain system resources
• Internal Servers – Extends functionality provided by Microkernel, Consider as extensions which are accessible to microkernel only
• External Servers – Different servers implement different policies for specific application domains, Receives service requests from client applications using the communication facilities provided by the microkernel, interprets these requests, executes the appropriate services and returns results to the clients
• Adapters – Protect the client from implementation details of the microkernel, Uses communication mechanism provided by the microkernel
• Clients – Application that is associated with exactly one external server (thru adapter)

6. Microkernel – State Models

The core principle on which Microkernel pattern (and many other loosely coupled dynamic processing models) is built is to be able to work on top of a state machine that is configurable. The current design of Integration Hub is an application of deterministic finite state model – FSM.

• State transition table or event table is used to hold definition of states. The core state model is configured in the tables / DB to be picked up dynamically by core state machines and acted upon.
• The design for Integration Hub should cater for
• Pre-configured state transitions (e.g. flow of events after receiving requests, validation, etc)
• Dynamic state transitions (e.g. sequence of flows obtained from Ref Data Layer response, etc.)
• Ability to over-ride dynamic transition and force a particular sequence of events (e.g sub-flows could be parallel or sequence, etc.)

Flow controller and Map Router are the two major state machines to solve the many types of processing possible through the hub.

Flow controller will be the first and last major element that will be called multiple times during the course of a transaction processing and flow controller may call the same or different functions to achieve the state transition at each of the instances. The diagram below will provide an indication of how it will implemented

7. Microkernel – Typical Sequence Diagram

© Vinoth Krishnamoorthy