OSGi goes Mainframe - Modulwelten

Transcrição

OSGi goes Mainframe
- Modulwelten
managen
Orientation in Objects GmbH
Weinheimer Str. 68
68309 Mannheim
Version: 1.1
www.oio.de
[email protected]
Ausgangssituation
• Bestehende Großrechner-Anwendung
–
–
–
–
Mehr als 20 Jahre Produktionserfahrung
Mehr als 20 Kundeninstallationen
Sehr kosteneffizienter Betrieb (near zero administration)
ASP möglich
• Zugriff über Terminal-Clients
– Bis zu 4-stellige Benutzerzahlen pro Installation
– Effektive praxiserprobte Benutzerführung
• Große Menge Business-Logik, die nicht mal schnell in Java
reproduziert werden kann
– >100 Personenjahre Entwicklungsaufwand
– >10^6 lines of code
© 2010 Orientation in Objects GmbH
OSGi goes Mainframe - Modulwelten managen
2
Das ist doch einfach!?!
Rich-Client
Remote-Zugriff
Großrechner
3
Gliederung
• Problemstellung
• Lösungsansätze
• Praktische Umsetzung
•
•
•
•
Migration
Integration
Update
Qualitätsmanagement
4
Logischer Modulaufbau des Produktes
Invoice
Master
data
...
...
...
Legacy - Programme
Migrationsvision nach Java (1)
Invoice
Master
data
...
...
...
Legacy - Programme
Migrationsvision nach Java(2)
Invoice
Master
data
...
...
...
Legacy - Programme
Invoice
Master
data
...
...
...
Legacy - Programme
Invoice
Master
data
...
...
...
Legacy - Programme
Gliederung
• Problemstellung
•
•
•
•
Migration
Integration
Update
10
Modularisierung...
“A module is a self-contained component of a system, which has a
well-defined interface to the other components; something is
modular if it includes or uses modules which can be interchanged as
units without disassembly of the module. Design, manufacture,
repair, etc. of the modules may be complex, but this is not relevant;
once the module exists, it can easily be connected to or
disconnected from the system.“
Legacy Module (LGM)
• Vergleichbar mit Dokumentenbasierten Webservices
– Also keine direkte Abbildung Serviceschnittstelle (mit mehrere
Methoden) auf Legacy Programm möglich
– Eine Schnittstelle im „Java“ Sinn würde immer auf mehrere Legacy
Programme zeigen
– Hinter LGMs verstecken sich Legacy Programme
– LGMs werden speziell für die Java Anwendung bereitgestellt und
werden von keinem anderem verwendet
LGM1
Legacy1
Legacy2
12
OSGi - Open Services Gateway initiative (I)
• Kein JavaEE Standard
– Definiert von OSGi Alliance
• Mitglieder z. B. IBM, Nokia und Oracle
• http://www.osgi.org
• Komponentenmodell
– Anwendung wird in „bundles“ unterteilt
– Bundles können einzeln verwaltet werden
• install/start/stop/uninstall/update
OSGi - Open Services Gateway initiative (II)
• Sichtbarkeitsregeln für Bundles
– Definition von Im- und Exports
• Eintrag in META-INF/MANIFEST
• Abhängigkeitsverwaltung zwischen Bundles
– Auflösung von Abhängigkeiten zur Laufzeit
– Versionsinformationen vorhanden
• „SOA in a JVM“
– Service Registry verwaltet Dienste
OSGi Service Platform
• Ausführungsplatform für OSGi Bundles
–
–
–
–
Lightweight Container
Containerdienste
Lifecyle für Bundles
Standalone oder Embedded einsetzbar
• OSS Implementierungen
– Equinox (http://www.eclipse.org/equinox/)
– Apache Felix (http://felix.apache.org/)
– Knopflerfish (http://knopflerfish.org/)
Gliederung
• Problemstellung
•
•
•
•
Migration
Integration
Update
16
Update-Strategie
• Legacy (Ist)
– Update einzelner Großrechner-Programme
– Update von abhängigen Programmen
– Pflege der Abhängigkeiten durch Entwickler
• Java (Soll)
–
–
–
–
Modul-weise Updates
Inkrementelle Client Updates wegen Netzwerk-Last
Synchrone Updates Großrechner & Rich Client
Hotfix-Fähigkeit
17
Updatestrategie des Legacy-Produktes
Änderung
Änderung
LGM01
LGM01
Änderung
LGM02
Bugfix
Änderung
LGM03
Kunderelease
Entwicklung im „Trunk“
Kundenfix ergeben sich aus
Änderungen in den Abhängigkeiten
18
Gliederung
• Problemstellung
•
•
•
•
Migration
Integration
Update
19
Probleme bei der Implementierung des Konzeptes
• Versionen von Großrechner-Services und Client-Artefakten
zuordnen
• Reproduzierbarkeit von Builds
20
Gliederung
• Problemstellung
•
•
•
Service Granularität
Dependency Management
Silokonzept
21
Java Anbindung Schritt 1: monolithische
Mittelschicht
RCP
01
RCP
02
RCP
03
monolithische Mittelschicht
LGM01
Legacy01
Legacy02
LGM02
Legacy03
Legacy04
LGM03
Legacy05
Legacy06
22
Schritt 2: modulare Mittelschicht
RCP
01
RCP
02
RCP
03
Mittelschicht
Modul 01
Mittelschicht
Modul 02
Mittelschicht
Modul 03
LGM01
Legacy01
Legacy02
LGM02
Legacy03
Legacy04
LGM03
Legacy05
Legacy06
23
Schnittstelle zwischen Legacy und Java definieren
Java
Legacy
Schnittstellendefinition
- Infrastruktur
- Operationen
- Datenstrukturen (DOM)
- Metadaten
24
Service-Schnittstellen
• Statt einzelne LGMs anzusprechen jetzt Services ansprechen
• Services werden gemeinsam (Lieferant und Kunde) definiert
– Service-Anbindung durch Lieferant
– Service-Implementierung durch Kunde
• Abhängigkeiten werden beim Kunden verwaltet (keine implizite
Abhängigkeiten durch „Frontend“ mehr)
25
Schritt 3: Mittelschicht
RCP
01
RCP
02
RCP
03
Mittelschicht
Modul 01
Mittelschicht
Modul 02
Mittelschicht
Modul 03
Service01
Service02
Service03
LGM01
Legacy01
Legacy02
LGM02
Legacy03
Legacy04
26
Rückwärtskompatibilität in Services
• Methoden (Funktionen) in Services sind Veröffentlicht und werden
weder
– in der Signatur
– noch in der Funktionalität geändert
• Es dürfen jederzeit neue Methoden (Funktionen) hinzugefügt
werden
• Notwendige Änderungen in der Signatur oder Funktionsweise einer
Methode (Funktion) werden durch hinzufügen neuer Methoden
realisiert.
– Die „alten“ Methoden werden in der Schnittstelle als „deprecated“
gekennzeichnet und werden evtl. bei dem nächsten Release entfernt.
– Das Legacy Team muss das „deprecaten“ von Methoden (Funktionen)
kommunizieren.
27
Gliederung
• Problemstellung
•
•
•
Silokonzept
28
Java Mittelschicht Legacy-Anbindung
• Führt zu Abhängigkeitsgraph „außerhalb“ des Legacy Systems
• Je nach Ausführung werden unter Umständen mehr oder weniger
Abhängigkeiten gebildet:
– Eine monolithische Mittelschicht bindet alle verwendete Legacy Module
zusammen
– Eine modulare Mittelschicht bindet unter Umständen nicht alle Legacy
Module zusammen
• Best case: Gruppierung der LGMs durch Backend führt zu wenigen
Abhängigkeiten
• Worst case: monolithische Mittelschicht...
29
Abhängigkeit zwischen Legacy Programmen
A
B
C
D
E
F
G
H
I
•
Einzelne Legacy Programme sind
abhängig voneinander
•
Eine Programm Aktualisierung
bedingt weitere Aktualisierungen
•
Pflege aller vorhandenen
Abhängigkeiten in Tabelle nötig
•
Größenordnung hängt von Anzahl
der Programmen ab
A benötigt: D
B benötigt: E
C benötigt: D benötigt: E benötigt: F
usw.
Abhängigkeit zwischen Legacy und Java
Programmen
A
B
C
D
E
F
G
H
I
A
B
C
D
E
F
G
H
I
•
Legacy funktioniert
•
Gleiches gilt für die Java Seite!
Minimaler Update-Set bei Abhängigkeit zwischen
Legacy Programmen
A
B
C
D
E
F
G
H
I
A
B
C
D
E
F
G
H
I
•
Legacy und Java Programme sind
ebenfalls voneinander abhängig
•
Legacy Änderung bedingt nun
Java Änderungen (eventuell
zyklisch!)
Minimaler Update-Set bei Abhängigkeit zwischen
Legacy und Java Programmen
A
B
C
D
E
F
G
H
Abhängigkeitspflege wird
komplexer und fehleranfälliger
•
Fehlen von Services führt zu
vielen kleinen Programmen
•
Kleinste Fehler bei Pflege der
Abhängigkeiten potenzieren sich
I
A
B
C
D
E
F
G
H
I
•
Java Dependency Management
•
•
Legacy Bausteine werden
möglichst gleich groß in Java
Plugins zugeordnet und
umgesetzt
Neue Dependencies werden über
Java zu Rückkopplung ins Legacy
führen
•
Vorteile:
– theoretisch die Fortsetzung der
bisherigen Arbeitsweise in Java
•
Nachteile:
– Java Startup und Buildzeiten sehr
langsam
– Entwicklungskosten steigen mit
der Zahl der Plugins
– Hoher QM Aufwand und hohe
Fehleranfälligkeit
– Hohes Risiko das MittelschichtsDependencies zu doch größeren
Updates führen
– entsprechende Versionsverwaltung existiert nicht
World without Java
HEAD
Legacy01
V3
Legacy03
V2
Bugfix an Legacy03
nötig
--> V2 Legacy03
--> kein Deployment
von V3 Legacy01 nötig
Legacy04
Legacy02
Legacy05
Legacy06
35
Vermittlung der Dependency durch Java vs.
Legacy
Java vs.
Legacy
1.0
1.0
Legacy01
Legacy03
Legacy04
Legacy02
Legacy05
Legacy06
36
Direkte Mittelschicht-Dependencies zwischen Java
und LGM Programm
Legacy01
Legacy03
LGM02 Dep
LGM01 Dep
Legacy04
Legacy02
LGM03 Dep
LGM03 Dep
Legacy05
Legacy06
LGM03 Dep
37
Was eigentlich alle zu allen bindet...
Legacy01
Legacy03
LGM02 Dep
LGM01 Dep
Legacy04
Legacy02
LGM03 Dep
LGM03 Dep
Legacy05
Legacy06
LGM03 Dep
38
Gliederung
• Problemstellung
•
•
•
Silokonzept
39
Silo Definition
RCP
01
RCP
02
RCP
03
Mittelschicht
Modul 01
Mittelschicht
Modul 02
Mittelschicht
Modul 03
Service01
Service02
Service03
LGM01
Legacy01
Legacy02
LGM02
Legacy03
Legacy04
40
Wiederverwendbare gemeinsame Services
RCP
01
RCP
02
RCP
03
Utility
Modul 01
Mittelschicht
Modul 01
Mittelschicht
Modul 02
Mittelschicht
Modul 03
Utility
Service01
Service01
Service02
Service03
LGM01
Legacy01
Legacy02
LGM02
Legacy03
Legacy04
41
Dependency zu wiederverwendbarem Service
RCP
01
RCP
02
RCP
03
Utility
Modul 01
Mittelschicht
Modul 01
Mittelschicht
Modul 02
Mittelschicht
Modul 03
Utility
Service01
Service01
Service02
Service03
LGM01
Legacy01
Legacy02
LGM02
Legacy03
Legacy04
42
Gliederung
• Problemstellung
•
•
•
Laufzeitarchitektur
Buildmanagement
Releasemanagement
43
Client
WIN 32/64
Actions
Eclipse RCP
OSGi
Applicationframework
Deployment
Databinding
Customview
Standardview
Remote Proxy
JSE 6
Middletier
Remote Proxy
SOAP Proxy
Transferobjekt Assembler
OSGi
Logging
Business Logic - POJOs
Security
Service Implementierung
Transactions
Spring Container
Stateless Services Fassade
Hibernate
JTOpen
JDBC
JSE 6 / JEE 5
Legacy Host
Used OSGi - Layers
•
•
Komplettes Life Cycle Management
Classloader separation
INSTALLED
STARTING
start
RESOLVED
ACTIVE
stop
UNINSTALLED
STOPPING
46
als Rich Client
PlattformGmbH
©Eclipse
2010 Orientation
in Objects
46
Gliederung
• Problemstellung
•
•
•
Laufzeitarchitektur
Buildmanagement
Releasemanagement
47
Componentbuildservice
ComponentMetaData
1
Component Build Service
3
Component
Repository
2
Source
code
Repository
48
Ansätze im Java/OSGi-Umfeld
• Buildwerkzeuge
– PDE Build
– Ant mit Sigil/Bundlor/BND
– Maven
• Artefakt-Management
– OSGi Bundle Repository (OBR)
– p2
– Ivy
• IDE
– Integration mit Build- und Artefakt-Management
– Start und Test der Anwendung ohne Build/Deploy Zyklus
49
Gliederung
• Problemstellung
•
•
•
Laufzeitarchitektur
Buildmanagement
Releasemanagement
50
Herausforderungen
• Deployment
– p2
– Webstart
• Metatadaten Management
– Pflege der MANIFEST.MF durch Entwickler
– Generierung der MANIFEST.MF
• Verknüpfung von Java Silos und Legacy Services
51
QM Infrastruktur
Automatisierte
Tests
Component
Repository
Component
Build Service
CI
Server
Source
Code
Repository
automatisierte
Codeanalysen
Issuetracker
Stagingsystem
QM-Infrastruktur
• Hoher Integrationsgrad birgt Qualitätsrisiko
– daher automatisierte Integrationstest als Regression
• Verbesserung der Codequalität durch gezielte Massnahmen nach
Messungen
– Integration von Codemetriken in den Buildprozess
• Zusammenfassung in Continuous Integration Server
• bei größeren Customizings birgt Datenbasis des Kunden ebenfalls
Qualitätsrisiko
– Einsatz eines Staging Systems
• Dokumentation der Auswirkungen von Entwicklungsaktivitäten
– Kopplung von Issuetracker und Sourcecode Repository
– Analyse und automatisierte Überwachung
? ? ?
?
?
Fragen ?
Weinheimer Str. 68
68309 Mannheim
www.oio.de
[email protected]
54
Vielen Dank für ihre
Aufmerksamkeit !
Weinheimer Str. 68
68309 Mannheim
www.oio.de
[email protected]

OSGi goes Mainframe - Modulwelten

Transcrição

Documentos relacionados

viel (un-)sinn in sachen risikomanagement

PhotoArt Portfolio Vol. 4 - Development Cooperation

UML 2.1 Referenz

Sprachaufnahmetechnik Tipp 68

UML 2.4.1 Referenz

und Designmarkt in Ettlingen/Karlsruhe

Seminar „Internet der Dinge“

Objektbeschreibung herunterladen

Stefan Reinecke: Hollywood goes Vietnam: Der Vietnamkrieg im

King Air B200 von Aeroworx