• Like
Open/Closed Software - Developing freemium application using Spring Framework
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

Open/Closed Software - Developing freemium application using Spring Framework

  • 97 views
Published

Speaker: Frederic Simon …

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.

Published in Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
97
On SlideShare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
7
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Open/Closed Software Developing a freemium application with Spring © 2013 SpringOne 2GX. All rights reserved. Do not distribute without permission.
  • 2. Your Speaker ● Fred Simon – – ● Chief Architect, JFrog @freddy33 github.com/freddy33
  • 3. Agenda ● History of a freemium application ● OSS base of the architecture ● Reloadable ● Commercial Addons ● Layers... More layers! ● Testable
  • 4. 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
  • 5. OSS is the base ● The core engine for all – UI, – Spring TX – Spring Security – Transactional VFS – Security
  • 6. Architecture ● Based on Spring and IoC from the start ● Highly modular ● SaaS => No static members! ● A spring context (and Wicket application) is the app
  • 7. Reloadable Beans ● Artifactory Configuration => Spring Beans configuration ● Reloading beans ● No singletons ;-)
  • 8. 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)
  • 9. Version Converter Matrix ● I like Enums (See the extended Enums ;-) ● Branches are hard ● Keeping it Modular (Reloadable Beans)
  • 10. 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
  • 11. Extending the UI ● ● Using Wicket dynamic loading Addon provides HTML and Java code for extended page/panel
  • 12. 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
  • 13. More Layers... ● The HA and Online SaaS versions ● Just more addons
  • 14. Tests are everything ● Your software is defined by your tests
  • 15. Users Plugins ● Extensible Software – Entry/Exit points – Listeners – Interceptors – Extra REST API and Scheduled Jobs
  • 16. Unit Tests ● Unit tests for each module – Spring Config with classpath filters ● Testing conversion ● Stabbing with Easymock
  • 17. 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
  • 18. Higher Tests ● Integration tests for REST, Replication and HA – Running multiple web servers – For multiple databases – Backward and Forward compatibility