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.
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
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
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