Proteus Framework

1. Proteus Framework Redefining the plugin

2. 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

3. 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?

4. 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

5. OSGivs 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 Archetypesthat define a class of service, and core Java SE’s Service Provider Interface (SPI) architecture

6. 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

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

8. 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.

9. 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

10. Versions: First Class Citizens • Semantic Versioning • http://semver.org • 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

11. 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 Registrarthat 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

12. Proteus Factory Registrar • Entry 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: IPluginRegistrarpluginRegistrar = delegate.getPluginRegistrar(NAMESPACE);

13. 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 InterfaceServiceLoader 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

14. 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);

15. 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

16. Plugin Architecture Review • The Proteus Factory Registrar manages a collection of Plugin Archetypes • A Plugin ArchetypeRegistrar Factory creates a singular Plugin Registrar • A Plugin Registrar manages a collection of homogenous Plugin Instances • A Plugin Instanceprovides a specific configurable concrete plugin

17. Defining a Plugin Archetype

18. 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

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

20. Concrete Plugin Structure

21. Plugin Factory Implementation

22. 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

23. Bootstrap a Proteus Application • Create a main class that extends AbstractRuntimeEngine public class SampleApplicationextends AbstractRuntimeEngine • Create an instance of either a StandardProteusApplication or ExtendedProteusApplication IProteusApplicationmyApplication = new StandardProteusApplication(); • Instantiate the runtime engine IRuntimeEnginemyRuntimeEngine = new SampleApplication();

24. 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; ... }

25. 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

26. 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);

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

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