Architectural style -> Adoptable system -> Microkernel.

-

Background –

As we are talking about adaptable system, we have to think about heterogeneous system, we have huge number of different platforms and software stack. If you are thinking to build a system which is portable, you must agree that, you have to design it differently for different platforms. If you do so, you will notice that main (or say core) functionality are same, but you are rebuilding them again and again for different platforms, which is not at all a right way.

What I am trying to say is, core functionality will be same, doesn’t matter for which platform and how you build it. So is there any way I can take that core logic as a separate unit? Yes of cures there is, that is what you are reading about, its called “Microkernel”. Please look at below mentioned image for a high level understanding.



Microkernal –

Core logic/logics of your system, which will be common for all platforms.

Internal server -

There are some functionalities which are not core but are very important, those functionalities we can capture here. This will be an extended functionality, provided by microkernel. Only microkernel will have access to invoke it, so if any request which needs to be done apart from core functionality, microkernel will call internal server.

External server –

This will be an abstract layer, it will give you an interface to use system effectively. Different platforms use different polices to implement things, so your interface will vary as per different view or platform.

Adapter –

We need an adapter here, as we have to connect to heterogeneous systems.

Oh! Too much technical, let’s talk something non-technical. The kind of lifestyle we live today, we eat out very often. After ordering many different curries (“paneer do pyaza”, “Kadhai paneer”,”paneer lababdar”, etc) I have realized, all of them taste somewhat similar. Actually those fellow create same base curry for all different types. The moment you order any curry, they will use same base curry for different order and mix little different toppings and spices here and there as per curry type and that’s it. knowingly or unknowingly they have used Microkernel in their cooking business :)

UML Structure -





Sequence diagram -









 Thanks for reading it. To read more on design patterns and basic design principles please see my web page. You can also join me on FB or on G++. Please drop comments for any question related to this blog.

Comments

Post a Comment

Popular posts from this blog

Non-virtual interface idiom (NVI)

-
In almost every cases, it’s recommended to follow OOAD principles, but sometimes we should try to look some other alternatives, provided by programming languages, which could be a better options for certain situations. In C++, we can implement virtual function in private and we can redefine its behavior in derived class's private  and it will work in same way(did you try that?). When we define virtual function as private and expose a non-virtual public function to outer world, we call it “ non-virtual interface idiom ”. Non-virtual public function will internally call virtual function, in other words you are not exposing your virtual function to client. You will achieve high encapsulation, plus we can add pre and post execution/condition in the body of non-virtual public function. Call some set of functions, as prerequisite of calling virtual function, and after call returns from virtual function, again call some set of function as part of post cleanups/conditions,
Read more

Architectural patterns => Mud to structure => layers.

-
Image
Background - We apply mud to structure when a large system requires decomposition. If you notice, your application/requirement has verity of logical units which can be decomposed into a group of sub-tasks, first,  group them into different levels of abstraction. One abstract unit perform a totally different task(s) from other units, but any unit alone is not enough to give meaningful service to customer. Actually, different issues/solutions are splinted into different abstract units. Second,  after you divide them into different units, if you see a mix of low and high-level dependencies, where high-level operations depend on low-level operations, then assume those logical units as layers, third draw a dependency diagram between layers.  If control flows from high to low layer (or dependency diagram forms a stack, one layer on top of other), you can think of implementing it through layer pattern. Layer architecture - We can have many components in one layer. Layer
Read more

Software design vocabulary

-
My goal here is to do a logical grouping of tech jargon. Programming paradigm Structural programming [i.e. C language]. OOP: object-oriented design [i.e. C++/JAVA/C# etc] Concurrent programming paradigm Functional programming [i.e. Scala, Transactional-based model: Haskell] CSP - Communicating sequential process [i.e. Erlang, MPI] Solid First letter full form in SOLID context S Single responsibility principle  (SRP) O Open Close  principle (OCP) L Liskov's Substitution  Principle (LSP) I Interface Segregation   Principle (ISP)
Read more