Embed Size (px)
DESCRIPTION
Speaker: Frederic Simon Developing freemium which involves OSS is not a trivial task. From one side, you need to prevent premium code from working in your free modules, and do it gracefully - without errors and performance degradation. From other side, your OSS core must be easily accessible to the premium modules. Partial public availability of the code and unified continuous delivery process for two different versions of the product is also challenging. In this talk we’ll showcase Artifactory, which successfully combines OSS and Pro versions by heavily relying on flexible dependency injection mechanics, available in Spring. We will talk about developing, building, testing and releasing hybrid freemium application and will review the existing approaches, discussing pros and cons of each of them.
Citation preview
© 2013 SpringOne 2GX. All rights reserved. Do not distribute without permission.
Open/Closed Software Developing a freemium application with Spring
Your Speaker
● Fred Simon
– Chief Architect, JFrog
– @freddy33
● github.com/freddy33
Agenda
● History of a freemium application
● OSS base of the architecture
● Reloadable
● Commercial Addons
● Layers... More layers!
● Testable
Artifactory History
● 2006: The OSS version
● 2008: First “professional” OSS version
● 2009: The SaaS version then the Pro
● 2012: Bintray
● 2013: The 3.0 version
● 2013: The HA version
OSS is the base
● The core engine for all
– UI,
– Spring TX
– Spring Security
– Transactional VFS
– Security
Architecture
● Based on Spring and IoC from the start
● Highly modular
● SaaS => No static members!
● A spring context (and Wicket application) is the
app
Reloadable Beans
● Artifactory Configuration => Spring Beans
configuration
● Reloading beans
● No singletons ;-)
Converter Manager
● Since 2.0 (2009) drop the war
– DB auto-update
– Configuration schema and default change
● Config, Logback, Mimetypes
– Directory structure changes
● 3.0 (2013)
Version Converter Matrix
● I like Enums (See the extended Enums ;-)
● Branches are hard
● Keeping it Modular (Reloadable Beans)
Addons Manager
● Addons are pure interfaces <=> features
– Multiple implementations
– One manager that from classpath + license load the correct addon
● Each addon has:
– META-INF/addon.properties
– Addon.xml (Spring beans)
– Many annotated spring beans
Extending the UI
● Using Wicket dynamic loading
● Addon provides HTML and Java code for extended
page/panel
REST API
● Jersey
– All resources in the OSS version in a single jar
● Because of IBM WebSphere ;-(
– Jersey actually load all path correctly
– Jersey annotation parsing 60% of load time!
● => Reflections
● Jersey Spring integration use the Addon Manager
More Layers...
● The HA and Online SaaS versions
● Just more addons
Tests are everything
● Your software is defined by your tests
Users Plugins
● Extensible Software
– Entry/Exit points
– Listeners
– Interceptors
– Extra REST API and Scheduled Jobs
Unit Tests
● Unit tests for each module
– Spring Config with classpath filters
● Testing conversion
● Stabbing with Easymock
Versions Integration Tests
● For each version
– Make sure the classpath are accurate (Maven hell ;)
– Adding new functionality tests from the previous base
● Testing remote HTTP calls: MockServer
– Slow network
– Broken sockets
– Basic HTTP response codes and headers
Higher Tests
● Integration tests for REST, Replication and HA
– Running multiple web servers
– For multiple databases
– Backward and Forward compatibility
