Catalog Plugin Design

Owned by Steve Lombardi (Deactivated)
Last updated: Nov 02, 2021 by Phillip Klinefelter
2 min read

Goals

  1. Provide a plug-in architecture with increased flexibility without redundant interfaces. Well defined extensibility points are necessary, but there currently is not a lot of contract re-use among the existing plugins.
  2. Allow the addition of plugins at any point in the life-cycle without the need to modify CatalogFrameworkImpl and related classes. 


Overview

Several approaches are possible: 

  • Create a super-interface, CatalogPlugin, that contains all the method signatures needed for any plugin. Have an abstract base class, CatalogPluginImpl, that has a "pass-through" implementation for each method. Extend the abstract base for a new plugin. 
  • Create an interface, CatalogPlugin, that conforms to the Catalog Framework but does not directly implement it. If the Catalog Framework need to change or grow, an intermediate adapter can transform requests into a format the CatalogPlugin expects and understands. 

In either case, the ordering problem can be solved using one of the following strategies: 

  • Have the CatalogPlugin expose data that can be used for sorting plugin execution in the correct order. Make this configurable via blueprint. 
  • Allow a collection of CatalogPlugin's be composed into a single, CompoundPlugin, which can be configured as needed (i.e. execute child plugins in order, etc) via blueprint. 


Plugin Symmetry

Our plugin structure is asymmetric. That is, a forward-backwards recursive strategy for the request-response chain won't work by default. 

  • Implementing the chain of responsibility (i.e. servlet filters) where possible should greatly reduce the number of interfaces needed (no need for pre-* and post-* interfaces). 
  • Should complement the CompoundPlugin strategy. 
  • Allow the plugin, at a predefined point in its life cycle, to defer itself and permit an earlier plugin to finish before it does (regression call). 


Camel Approach


Additional Notes

These are just some preliminary ideas. They are design considerations for the long term evolution of the software that arose from DDF-2500 and DDF-2502. 

Decision

Postpone for now and revisit for next major version of Catalog Framework API.