 Proteus Framework Redefining the plugin

Why a new framework?  Present approaches (e.g. OSGi) use non-standard approaches that create too many breaking points  Designing a plugin architecture for both scalability and supportability requires an extra level of design often overlooked  Few developers embrace the built-in plugin capabilities of the Java platform

Forward Compatibility  Definition: the ability of an SDK to ensure that plugins written in version n continue work without recompilation in version n+1  As the architect of a plugin-driven application, how do you guarantee forward compatibility when the plugin consumer has imported your interfaces into their binaries?

What’s wrong with OSGi?  In a word: nothing  However, it may not be the right framework for your application. Why pick Struts over Spring? Why use Spring over pure EJB? Advocates of each of these frameworks can quickly enumerate why they felt (or chose) one framework over the other. One framework doesn't solve every problem

OSGi vs Proteus  Both embody the notion of SOA in a Virtual Machine  Modularity is at the core of both designs  Plugins (or Bundles, in OSGi parlance) are published, found by a consumer dynamically at runtime, and bound in order to issue service invocation requests  OSGi relies on the MANIFEST.MF metadata to publish (export) its plugins (bundles)  Proteus relies on compiled code, Plugin Archetypes that define a class of service, and core Java SE’s Service Provider Interface (SPI) architecture

Runtime vs Compile Time  OSGi relies on "proprietary” MANIFEST.MF metadata to wire up services  Googling shows just how hard time consuming it can be to wire up existing libraries into OSGi  Inherent class loader problems come along for free  Proteus adopts the standardized Java Service Provider Interface (SPI) architecture built-in to Java SE  No wiring beyond declaring the factory in META-INF/services  Not designed to solve the “2 versions of the same library” problem

Comparing Coding Styles  OSGi String serviceName = Service.class.getName(); ServiceReference ref = ctx.getServiceReference(serviceName); Service svc = (Service) ctx.getService(ref)); svc.callSomeMethod();  Proteus INamespace ns = new Namespace(“com.foo”, “Bar”); IPluginRegistrar pluginRegistrar = delegate.getPluginRegistrar(ns); MyService svc = pluginRegistrar.createPlugin(new Version(1), MyService.class); svc.callSomeMethod();

Breaking Dependencies  Instead of the plugin consumer directly importing the plugins actual interface, the plugin consumer needs to import a proxy that represents a specific version of a plugin interface.  Java includes native support for dynamic proxy objects!  Plugin consumer achieves compile type type checking, but they do so by compiling against a specific version of a proxy interface instead of the actual physical interface used by the actual plugin  Look at the last slide again- notice the explicit version request of a proxy interface, 1.0 of MyService.

GoF Interface Development  Develop against an interface, not an implementation  Proteus, like OSGi, forces the developer to embrace this fundamental tenant of object oriented development  Plugin Archetype is a physical construct that drives interface over implementation development at the plugin level  Comprised of a namespace and a set of versioned interfaces  Typically deployed in a single.jar file  Plugin Archetype = Category of Plugin

Versions: First Class Citizens  Semantic Versioning   Major.Minor.Patch  Versions must increase over time  Minor version may include new, backwards compatible functionality  1.0 is forward compatible with 1.1  1.1 is not backward compatible with 1.0  Patch level is never considered when determining version compatibility  Patches must not introduce new functionality, only bug fixes! All Proteus plugin access includes an explicit version reference

Triple-Bonded Factory Design  Proteus Factory Registrar is the master registrar that manages one or more Plugin Archetypes  Each Plugin Archetype maintains its own Plugin Registrar that manages one or more concrete implementations of the archetype.  The Plugin Registrar is a factory that can create instances of a specific version and/or instance of the plugin archetype Proteus Factory Registrar  Plugin Registrar  Plugin Instance

Proteus Factory Registrar  E ntry point into the Proteus plugin architecture  Registrar is solely responsible for being the authoritative registrar for all known Plugin Archetypes  Access to the Proteus Factory Registrar is implicit through an injected delegate: IPluginRegistrar pluginRegistrar = delegate.getPluginRegistrar(NAMESPACE);

a priori Archetype Knowledge  Applications must have a priori knowledge of the plugin archetypes they intend to support  Application is designed against a specific archetype interface version  Remember, archetype is defined by a namespace and version  Java SE Service Provider Interface ServiceLoader architecture used to dynamically locate and enumerate plugin archetypes instances  Archetypes are declared in the.jar manifest according to Java SE by defining their fully qualified class within a text file defined by Java SE SPI architeture: META-INF/services/org.proteusframework.spi.ProteusRegistrarFactory

Plugin Registrar  Plugin Registrar is the authoritative registrar for a specific Plugin Archetype.  Specific plugin instances can be be created by version  Proteus embraces Java Generics Version ver = new Version(1); MyInterface plugin = pluginRegistrar.createPlugin(ver, MyInterface.class);

Dynamic Plugin Discovery  Plugin Archetypes require a priori knowledge programmed into the application  Concrete instances of a plugin archetype have no such requirement; discovered dynamically by Java SE by searching the CLASSPATH for.jar manifest entries META-INF/services/org.proteusframework.pluigin.spi.MyPlugin

Plugin Architecture Review  The Proteus Factory Registrar manages a collection of Plugin Archetypes  A Plugin Archetype Registrar Factory creates a singular Plugin Registrar  A Plugin Registrar manages a collection of homogenous Plugin Instances  A Plugin Instance provides a specific configurable concrete plugin

Defining a Plugin Archetype

Archetype Package Structure  Interfaces  Defines one or more versions of a plugin’s interface  Registrar  Plugin Archetype Registrar Factory that collects concrete instances of the archetype and stands ready to instantiate specific plugin implementation versions  SPI  Abstract plugin factory extended by concrete instances  Plugin Archetype Registrar Factory delegates construction of the plugin instance here  META-INF/services  How a plugin archetype is declared within a Proteus Application

Archetype Definition  By and large boilerplate code  Anticipate implement a mvn plugin so that a plugin can be created via mvn archetype:archetype command  Decide on a namespace  Implement one or more plugin interface versions  Link the interfaces to semantic versions within the VersionCollection

Concrete Plugin Structure

Plugin Factory Implementation

Version Implementation  Proxy Interface unused by concrete plugin implementations  Concrete plugin extends the actual version interface; the plugin instance is explicitly dependent upon the Plugin Archetype.jar public class Version1Impl extends AbstractStandardPlugin implements ISampleVersion1  Specific Version  Each plugin is tied to a specific version explicitly be the versioned interface it implements from the plugin archetype

Bootstrap a Proteus Application  Create a main class that extends AbstractRuntimeEngine public class SampleApplication extends AbstractRuntimeEngine  Create an instance of either a StandardProteusApplication or ExtendedProteusApplication IProteusApplication myApplication = new StandardProteusApplication();  Instantiate the runtime engine IRuntimeEngine myRuntimeEngine = new SampleApplication();

Bootstrap a Proteus Application  Inject the runtime engine into the application myApplication.setRuntimeEngine(myRuntimeEngine);  Start the application myApplication.startApplication();  Formally launch the application in the run() method public void run() {runningFlag = true;... }

Application Configuration  Standard Proteus applications can easily separate out their configuration from the actual runtime implementation  Use of IConfigurationLoader provides an abstraction on IProteusApplication between configuration and storage  Java SE deployment will differ from an Android deployment

Plugin Instantiation  Get version 1 interface from the default plugin provider  Default can be defined during runtime engine configuration (e.g..properties file) MyExpectedVersion1Interface example1 = pluginRegistrar.createPlugin(new Version(1), MyExpectedVersion1Interface.class);

Plugin Instantiation  Get version 1 interface from a specific concrete plugin INamespace pluginNS = new Namespace(”com.foo", “FooRegistrar"); IVersionDescriptor vd = new VersionDescriptor(pluginNS, new Version(1, 0)); MyVersion1Interface example2 = pluginRegistrar.createPlugin(vd, MyVersion1Interface.class);

Application Shutdown  Resource cleanup requires that the engine be shutdown propertly  Accomplished with a single call: myApplication.stopApplication();