Balconies, Patios, Terraces, and Bridges. Architectural approaches for moving legacy Java applications to OSGi - Tim Bond

  • 1,914 views
Uploaded on

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 …

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.

More in: Technology , Education
  • 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
1,914
On Slideshare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
81
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. Bridges, Foundations, and Duplexes:Architectural Approaches to OSGiadoptionTim BondPrincipal Security ArchitectSoftware AG21 Sept 2011 OSGi Alliance Marketing © 2008-2010 . 1 PageCOPYRIGHT © 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 AnalyticsIntegration 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. BalconyRun 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 balconyQuick winGood for developmentbut . . . .Does not help create a platformDoes not solve library complexity
  • 14. Rebuild foundation?
  • 15. Logging svc Config agent Deployment agent Servlet Proxy bundle Scheduler UserManager ART Etc. Etc. WmRoot WmPublicJVM 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 DuplexJVM / 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) RelationalBroker 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 loadingLegacy libraries (internal and external) aren’t designed with modularity in mind. Require code changesSolutions:Pass around ClassLoader or use TCCLBuddy-ClassloaderDynamicImport-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)
  • 25. Jaranalyzer custom output
  • 26. Package level deps with Lattix
  • 27. Source code search
  • 28. Thank you . . .