C++ Event-Driven Plug-in Framework. (Plug-in architecture III)

Tags: , , ,

This is the third article of a three-part series, I recommend reading the previous articles on plug-in architecture: Plug-in architecture (I): Preliminary notes and Plug-in architecture II: JavaScript Event-Driven plug-in framework.

In this third article on plug-in architecture I present the implementation of a server side plug-in framework in C++ using JavaScript as script language. It is built on top of Microsoft C++ REST SDK and uses Mozilla's JavaScript engine Spider Monkey as JavaScript interpreter. The design of the server architecture is practically identical to the design of the client side plug-in framework. So I won't describe in detail the framework in this article, if you are interested in technical details please read the documentation in GitHub.

Index

  1. Example code
  2. Documentation
  3. Server-side C++ plug-in framework overview

Example code

C++ Plug-in Server

Documentation

Server-side C++ plug-in framework overview

This is an event-driven architecture: Plug-ins listen to events. When an event is fired by a remote client or by the server application the plug-ins listening to that event run and return a response. The response is returned to the client or the server application. Plug-ins can communicate. And even if the logic is based on events, a plug-in can be run using its id. Plug-ins can extend other plug-ins.

C++ event-driven framework
C++ event-drive plug-in framework flows.

As for the client-side the server plug-in framework central piece is the Plug-in Handler, it manages the life-cycle of plug-ins during the application runtime, it loads plug-ins from repositories, adds, executes and removes plug-ins. The Plug-in Handler handles events and manages plug-in execution failures. It also manages the inter-plug-in communication and their communication with other entities as well as plug-in extensiveness.

As said in precedent articles, “a plug-in is an object with a defined structure that extends an application. Plug-ins can be added from different sources, server side applications, or loaded from files, we call these last plug-ins packaged plug-ins. Server side plug-ins are also portable and can be customized through properties. They can also extend other plug-ins. Not all of them may be executed, some can just have useful functions or wait to be extended by others. They can communicate.”

Firing plug-in events, running plug-ins, sending messages to plug-ins can be done remotely via HTTP requests. For interfacing with remote clients the plug-in framework will use a Plug-in Controller.

When running a plug-in in the server side a runner object is used. Runners are classes that have functions to run scripts or executables and return a response.

continue reading >>