Balconies, Patios, Terraces, and Bridges. Architectural approaches for moving legacy Java applications to OSGi - Tim Bond
•
0 likes•1,711 views
OSGi is a great platform for building new applications, but what if you have 250.000 lines of legacy Java code that uses custom classloaders, dynamic invocation, and complex resource loading techniques? There are many approaches to moving such a product to OSGi. This talk will explore the approaches Software AG evaluated while moving their flagship integration platform from plain old Java to OSGi as well as challenges encountered as part of the move.
Report
Share
Balconies, Patios, Terraces, and Bridges. Architectural approaches for moving legacy Java applications to OSGi - Tim Bond
- 1. Bridges, Foundations, and Duplexes: Architectural Approaches to OSGi adoption Tim Bond Principal Security Architect Software AG 21 Sept 2011 OSGi Alliance Marketing © 2008-2010 . 1 Page COPYRIGHT © 2008-2011 OSGi Alliance. All Rights Reserved All Rights Reserved
- 2. Agenda • OSGi evolution @ Software AG • Architecture approaches • Challenges • Tooling COPYRIGHT © 2008-2011 OSGi Alliance. All Rights Reserved
- 3. Company profile • Founded in 1969 • ADABAS / Natural / Tamino • Acquired webMethods in 2007 • Acquired IDS Scheer in 2009 • Achieved 1B Euro in 2010 • Acquired Terracotta in 2011 Page 3 OSGi Alliance Community Event 2011© 2008-2011. All Rights Reserved
- 4. So why a common platform?
- 5. …many issues
- 6. Why a common platform? Platform evolved over time and via acquisitions 6 runtime servers + more embedded runtimes 5 different startup scripts 3 SOAP stacks 5 logging components 4 web containers hundreds of third party libraries etc.
- 7. Big picture • Process Engine webMethods history here Assets Assets Asset Task Engine Management Governance Rules Engine Assets webMethods Broker EntireX Broker CentraSite Mediator Assets Assets Assets Analytics Integration Server My webMethods Optimize ApplinX Server Cognos webMethods
- 8. Why a common platform (& OSGi!) Common startup scripts Common Configuration Deployment Shared services Shared components Build system Flexible architecture
- 9. Integration Server .NET Adapter Tomcat PKG PKG PKG Technical Services Business Services Process Models PKG PKG PKG Rule Engine Task Services Process Engine Admin Services PKG PKG PKG PKG Package Manager Auditing Security Service Validation Transactions Threading Caching Infrastructure Statistics Logging Server Core SOAP XML Protocol & EDI Flat File HTTP/S JMS Transport FTP/S SMTP/POP3 ESB Integration Server
- 10. Architecture approaches • Balcony (application package) • Duplex (side-by-side) • Bridge (fun with classloaders)
- 11. Balcony Run OSGi as application package Image credit foto3116: http://www.flickr.com/photos/29385617@N00/2297575310/in/photostream/
- 12. Scheduler “Balcony” UserManager Adapter RT Etc. Etc. JVM IS launcher WmRoot IS server core WmPublic Logging svc Config agent Package manager Deployment agent Service registry Service layer Servlet WmOSGI OSGi framework
- 13. Problems with balcony Quick win Good for development but . . . . Does not help create a platform Does not solve library complexity
- 15. Logging svc Config agent Deployment agent Servlet Proxy bundle Scheduler UserManager ART Etc. Etc. WmRoot WmPublic JVM Package manager IS server core OSGi framework Equinox launcher Service registry WS library Security
- 16. Foundation • Worked (mostly) • But . . . • How to move forward? • Significant packaging changes • Difficult to patch due to “fat jar” issue (more on that later)
- 17. Logging svc Config agent Deployment agent Servlet Service layer Duplex JVM / service Scheduler equinox OSGi + custom hooks UserManager ART Etc. Etc. WmRoot IS server core WmPublic Package manager IS proxy bundle / classloader bridge Service registry
- 18. Service bridge in practice Adapter OSGi local call Adapter (XML+topic) Source Event Server Event Adapter JMS JMS Dis- Input Trigger Trigger Service patcher Source SQL SQL Client Group Adapter Query Query JMSConnection JMSDestination Alias Sink Sink jms.send Adapter Call jms.send Adapter via InvokeManager (XML) Relational Broker Integration Server OSGI Bundles
- 19. Issues / Challenges / Struggles • “Common lib” • Import-Dynamic:* and Buddy classloading • Fat JARs • Build systems • Preserving legacy behaviour
- 20. Common lib • Multiple products install and share single directory of third party and internal jar files • Who uses what? • What version is it? • Can I update it? • While running? • Need repository!
- 21. The fat jar • Legacy code “solution” • Wrap everything up, export all packages • There’s even an eclipse plugin . . . • Masks modularity issues
- 22. Class and resource loading Legacy libraries (internal and external) aren’t designed with modularity in mind. Require code changes Solutions: Pass around ClassLoader or use TCCL Buddy-Classloader DynamicImport-Package: * Boot delegation
- 23. Build / dependency systems • Ant (6.000 line build files) • Many factions solutions • PDE/Eclipse • maven • ivy • bnd + bndtools • With different views on Compile vs Test vs Runtime • Moving to “build-by-convention” approach with artifactory/jenkins/gradle/bnd
- 24. Tooling • jaranalyzer (kirkk.com) • Lattix • Structure 101 • OpenGrok (source code search)
- 26. Package level deps with Lattix
- 30. Thank you . . .