Balconies, Patios, Terraces, and Bridges. Architectural approaches for moving legacy Java...

Post on 11-Jun-2015

2.001 views 1 download

Tags:

description

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.

Transcript of Balconies, Patios, Terraces, and Bridges. Architectural approaches for moving legacy Java...

COPYRIGHT © 2008-2011 OSGi Alliance. All Rights Reserved

Bridges, Foundations, and Duplexes:

Architectural Approaches to OSGi

adoption Tim Bond

Principal Security Architect

Software AG

21 Sept 2011

OSGi Alliance Marketing © 2008-2010 .

All Rights Reserved

Page 1

COPYRIGHT © 2008-2011 OSGi Alliance. All Rights Reserved

Agenda

• OSGi evolution @ Software AG

• Architecture approaches

• Challenges

• Tooling

OSGi Alliance Community Event 2011© 2008-2011. All Rights Reserved Page 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

So why a common platform?

…many issues

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.

Big picture

• webMethods history here

webMethods

Integration Server My webMethods

Process Engine

Rules Engine

Task Engine

Assets

Assets webMethods Broker

Assets

CentraSite

Asset

Management

Governance

Mediator

EntireX Broker

Assets

ApplinX Server

Assets

Optimize

Assets

Analytics

Cognos

Why a common platform (& OSGi!)

Common startup scripts

Common Configuration

Deployment

Shared services

Shared components

Build system

Flexible architecture

Integration Server

ESB Integration Server

Protocol &

Transport

SOAP XML

HTTP/S JMS

EDI Flat File

FTP/S SMTP/POP3

Service

Infrastructure

Auditing Security

Threading Caching

Validation Transactions

Statistics Logging

Server Core

Package Manager

Admin Services

PKG Process Engine

PKG Task Services

PKG Rule Engine

PKG

Business Services

PKG

Technical Services

PKG

Process Models

PKG

.NET

PKG

Adapter

PKG

Tomcat

PKG

Architecture approaches

• Balcony (application package)

• Duplex (side-by-side)

• Bridge (fun with classloaders)

Balcony

Run OSGi as

application

package

“Balcony”

IS server core

Pa

cka

ge

ma

na

ge

r

Se

rvic

e r

eg

istr

y

Sch

ed

ule

r

Use

rMa

na

ge

r

Ad

ap

ter

RT

Etc

.

Etc

.

IS launcher

JVM

Wm

Ro

ot

Wm

Pu

blic

OSGi framework

Lo

gg

ing

svc

De

plo

ym

en

t a

ge

nt

Co

nfig

ag

en

t

Se

rvle

t

Service layer

WmOSGI

Problems with balcony

Quick win

Good for development

but . . . .

Does not help create a platform

Does not solve library complexity

Rebuild foundation?

Proxy bundle

Equinox launcher

JVM

Wm

Ro

ot

Wm

Pu

blic

OSGi framework

Lo

gg

ing

svc

De

plo

ym

en

t a

ge

nt

Co

nfig

ag

en

t

Se

rvle

t

IS server core

Pa

cka

ge

ma

na

ge

r

Se

rvic

e r

eg

istr

y

Sch

ed

ule

r

Use

rMa

na

ge

r

AR

T

Etc

.

Etc

.

WS library Security

Foundation

• Worked (mostly)

• But . . . • How to move forward?

• Significant packaging changes

• Difficult to patch due to “fat jar” issue (more on that later)

Lo

gg

ing

svc

De

plo

ym

en

t a

ge

nt

Co

nfig

ag

en

t

Se

rvle

t

equinox OSGi + custom hooks

JVM / service

Wm

Ro

ot

Wm

Pu

blic

Service layer

IS server core

Pa

cka

ge

ma

na

ge

r

Se

rvic

e r

eg

istr

y

Sch

ed

ule

r

Use

rMa

na

ge

r

AR

T

Etc

.

Etc

.

IS proxy bundle / classloader bridge

Duplex

Integration Server OSGI Bundles

Service bridge in practice

Event Server

SQL

Query

Event

Input

Service

jms.send

Source

Adapter

Sink

Adapter

JMS

Trigger

Broker

local call

(XML+topic)

Call jms.send

via InvokeManager (XML)

Source

Adapter

Dis-

patcher JMS

Trigger SQL

Query

Sink

Adapter

JMSDestination JMSConnection

Alias

Adapter

Relational

Client

Group

OSGi

Adapter

Issues / Challenges / Struggles

• “Common lib”

• Import-Dynamic:* and Buddy classloading

• Fat JARs

• Build systems

• Preserving legacy behaviour

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!

The fat jar

• Legacy code “solution”

• Wrap everything up, export all packages

• There’s even an eclipse plugin . . .

• Masks modularity issues

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

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

Tooling

• jaranalyzer (kirkk.com)

• Lattix

• Structure 101

• OpenGrok (source code search)

Jaranalyzer custom output

Package level deps with Lattix

Source code search

Thank you . . .