Plug-In Components

Key Insight

Plug-in components are standalone, independent units containing specialized processing, additional features, or custom code, designed to enhance or extend the core system's functionality. They are instrumental in isolating highly volatile code, thereby creating better maintainability and testability within an application. Ideally, these components should be independent of each other with no interdependencies. Communication between plug-in components and the core system is generally point-to-point, typically through a method invocation or function call to the plug-in component's entry-point class. Plug-ins can be compile-based, which are simpler to manage but necessitate redeploying the entire monolithic application when modified, added, or removed, or runtime-based, allowing dynamic addition or removal without redeploying the core system or other plug-ins, often managed by frameworks like Open Service Gateway Initiative (OSGi), Penrose, Jigsaw for Java, or Prism for .NET.

Point-to-point plug-in components can be implemented as shared libraries such as JARs, DLLs, or Gems, or as package names in Java or namespaces in C#. A recommended naming convention for namespaces is `app.plugin..`, for example, `app.plugin.assessment.iphone6s`, which clearly identifies it as a plug-in within a specific domain and context. Alternatively, plug-in functionality can be accessed remotely through mechanisms like REST or messaging. In this scenario, each plug-in can be a standalone service, potentially implemented as a microservice using containers. This remote access approach offers significant benefits, including improved component decoupling, enhanced scalability and throughput, the ability to make runtime changes without special frameworks, and support for asynchronous communications, which can substantially improve user responsiveness in scenarios like asynchronous device assessments.

Despite the benefits, remote plug-in access transforms the microkernel architecture into a distributed system, which increases overall complexity and cost, complicates deployment topology, and makes it challenging to implement and deploy for most third-party on-premise products. Furthermore, issues such as an unresponsive plug-in, particularly when using REST, can prevent request completion, a situation less common in monolithic deployments. The decision between point-to-point and remote communication must be based on specific requirements and a careful trade-off analysis. Plug-in components typically do not connect directly to a centrally shared database; instead, the core system manages database interactions and passes necessary data to maintain decoupling. However, plug-ins can possess their own separate data stores, such as a simple database or rules engine for specific assessment rules, which can be external, embedded, or in-memory, and are exclusively accessible to that plug-in. The architecture rates above average (three stars) for modularity, extensibility, testability, deployability, and reliability, owing to the isolated nature of plug-ins which simplifies changes and reduces risks.