Pluggable Rule Engine Architecture for Knowledge Type Management
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Conventional rule engines have a rigid and inflexible core kernel that requires hard-coding various knowledge types, making it difficult and costly to interoperate with different reasoning engines and model complex business rules.
Innovation Solution
A pluggable rule engine architecture that decouples knowledge types from the core kernel, allowing for the discovery, registration, and addition of multiple knowledge types, such as workflows and Bayesian belief networks, through a service registry, assembler, weaver, and runtime services, enabling flexible and independent operation.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If knowledge types are hard-coded in the core kernel, then the system has a robust core kernel, but the system becomes rigid and inflexible
Solution Approach 1:
The patent segments the knowledge type handling functionality from the core kernel by introducing separate assembler services, weaver services, and runtime services. Each knowledge type (e.g., workflows, rules, Bayesian belief networks) is processed by dedicated services that can be independently added, removed, or modified without affecting the core kernel stability.
Solution Approach 2:
The patent introduces intermediary services (assembler services, weaver services, runtime services) that act as mediators between the core kernel and knowledge types. These services provide a decoupled architecture where the core kernel interacts with knowledge types through standardized interfaces, enabling flexibility while maintaining core stability.
2Adaptability or versatility
If multiple knowledge types are supported through hard-coding, then comprehensive functionality is achieved, but coding efforts and system complexity increase
Solution Approach 1:
The patent implements universal service interfaces (assembler service interface, weaver service interface, runtime service interface) that can handle multiple knowledge types through a common architecture. This multi-functional design allows the same service framework to process workflows, rules, Bayesian belief networks, and other knowledge types without requiring separate coding paths for each type.
Solution Approach 2:
By introducing intermediary services that standardize the interaction between the core kernel and various knowledge types, the patent reduces system complexity. These mediators provide a uniform interface layer that simplifies the integration of new knowledge types and reduces the coding efforts required to support multiple knowledge types.
3Adaptability or versatility
If the core kernel includes all knowledge type processing capabilities, then complete functionality is available, but storage and computing resources increase
Solution Approach 1:
The patent segments knowledge type processing capabilities into separate, optional services that are not permanently embedded in the core kernel. These services can be dynamically loaded and unloaded based on the specific knowledge types being used, reducing the permanent storage footprint and allowing computing resources to be allocated only when specific knowledge type functionalities are needed.
Solution Approach 2:
The patent implements a dynamic service registration and discovery mechanism where assembler services, weaver services, and runtime services can be added or removed at runtime based on the knowledge types being processed. This dynamic architecture allows the system to maintain complete functionality when needed while minimizing resource consumption when fewer knowledge types are in use.
Data Source
AI summary
Systems and methods for allowing pluggable knowledge types to be discovered, registered, and added to a rule engine are disclosed. An example method may include retrieving, by a processing device executing a rule engine, a list of pluggable services associated with a specified knowledge type; identifying a first pluggable service on the list of pluggable services; identifying one or more knowledge types that the first pluggable service is configured to process, wherein the one or more knowledge types comprise the specified knowledge type; and indexing, by the processing device, the first pluggable knowledge in the service registry by information identifying the one or more knowledge types.