© 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