Warum Value Objects?

Einsatz offener Standards im
ALMA Projekt
Heiko Sommer
European Southern Observatory (ESO)
Software Technology Forum 2002
Fachforum “Datenaustausch mit XML”
19. November 2002
ALMA Projekt
Chile, Atacamawüste (5000 m): 64 Radioantennen
weltweit leistungsstärkstes Radioteleskop
Europa und USA/Canada als gleichberechtigte Partner
$ 600 Mio (Software 5%)
Fertigstellung 2006 - 2011, Betrieb ~50 Jahre
Software Technology Forum 2002 - Heiko Sommer (ESO)
2
ALMA Antennen (Simulation)
“Very Large Telescope”, Chile
Software Technology Forum 2002 - Heiko Sommer (ESO)
ESO Headquarters, Garching
3
ALMA Software
Schwerpunkt offene Standardtechnologien
•
•
•
•
•
•
Absichten der Softwarearchitektur
Welche Standardtechnologien?
Warum?
Warum andere nicht?
Wann durch Eigenentwicklungen ergänzt?
Wie werden sie eingesetzt?
Software Technology Forum 2002 - Heiko Sommer (ESO)
4
ALMA Software
grobe Unterteilung
• geschäftsprozeß-ähnliche Datenverarbeitung mit
Webanbindung
– Erstellen und Reviewing von Observing Projects
– Dynamisches Scheduling
– Aufwendige Operator/Admin Software
• Control-Software (Echtzeit)
– Steuerung von Antennen, Receivern, Correlator, …
• Meßdatenverarbeitung (high performance)
• Datenspeicherung
– Objektpersistenz
– Meßdaten 1 TB/Tag
– unzählige Monitordaten (timestamped)
Software Technology Forum 2002 - Heiko Sommer (ESO)
5
ALMA Software Entwicklung
Projektsituation
• kleine Teams, weltweit verteilt, selbst innerhalb der
Subsystem-Teams
• oft ALMA-Engagement <50% pro Entwickler
• uneinheitliche Softwarekenntnisse und
Entwicklungskulturen
• langer Entwicklungs- und Nutzungszeitraum
• technisch stark unterschiedliche Anforderungen an
einzelne Subsysteme
Software Technology Forum 2002 - Heiko Sommer (ESO)
6
ALMA Software Entwicklung
Projektsituation (2)
• Prozess: bislang erfolgreiche Hinwendung zu
“Agile” in einem traditionellen “Wasserfall-Umfeld”
– Subsystem Leads Treffen mit CRC-ähnlichem Kartenspiel
zur Konsolidierung der Interfaces
– direkter Kontakt und persönliches Training waren
entscheidend für die Akzeptanz eines einheitlichen
Programmiermodells
• Aufteilung in “funktionale” und “technische”
Architektur (Zusammenfassung der zahlreichen
architectural views im Unified Process)
Software Technology Forum 2002 - Heiko Sommer (ESO)
7
Anforderungen an die Techn. Architektur
• Unabhängigkeit der Subsysteme (build und run)
• Verteilung der Software über viele Rechner mit
unterschiedlichen Betriebssystemen
• Einheitliche Verwendung “zukunftssicherer”
Technologien
• Preiswerte Standards, z.B. Open Source
• Leichte Benutzbarkeit für alle Entwickler
• Speziallösungen integrieren
• stufenweise Inbetriebnahme der Software
• Erweiterbarkeit für neue fachliche Anforderungen
und Technologien
Software Technology Forum 2002 - Heiko Sommer (ESO)
8
Architektur: Kernelemente
• Auf CORBA aufbauendes leichtgewichtiges
Komponentenmodell
• Entkoppelung der Subsysteme durch “Object by
Value” Kommunikation mittels XML
• Persistenz mittels XML (außer Meßdaten)
• XML Schema als verbindliche Datendefinition
• XML binding classes für typsicheren Datenzugriff
• Elemente der technischen Architektur werden als
Framework den Entwicklern zur Verfügung gestellt:
“Alma Common Software” (ACS)
Software Technology Forum 2002 - Heiko Sommer (ESO)
9
CORBA + Container/Component
Warum CORBA?
• Ausgereifte Middleware mit nützlichen Services
(Notification, Streaming, …)
• für alle derzeit relevanten und wohl auch für
zukünftige Programmiersprachen (Java, C++,
Python, ???) kostenlos erhältlich
• echtzeittauglich (ACE+TAO)
• IDL + OCL (+ value objects) als minimaler Vertrag
zwischen Subsystemen
Software Technology Forum 2002 - Heiko Sommer (ESO)
10
CORBA + Container/Component
Warum Container/Component Modell?
• Technische Belange zentral regeln und vor
Entwicklern verstecken
– Deployment, Start-up
– Auswahl und Konfiguration der verschiedenen ORBs; hier
ist CORBA allein eindeutig zu kompliziert.
– Auswahl der CORBA Services, Verbindung mit eigenen
systemweiten Services (Error, Logging, Konfiguration, …)
– Vereinfachter Zugriff auf andere Komponenten und
Resourcen zur Laufzeit
• Weitere heute noch nicht vorhersehbare Dinge
können transparent eingehängt werden
Software Technology Forum 2002 - Heiko Sommer (ESO)
11
CORBA + Container/Component
ALMA Container-Components
• Eine Komponente ist ein spezieller CORBA servant
– Implementiert Lifecycle Interface (Aufruf durch Container)
– Benutzt Container Interface
– Nach außen hin: IDL functional interface
• Direkt ansprechbare Komponenten halten keinen
client-state, können aber als Factory für “stateful”
Objekte dienen
• Container besorgt sich sämtliche Daten zur
Systemkonfiguration (component-autoloading, loglevels, ...) aus zentralen Repositories
Software Technology Forum 2002 - Heiko Sommer (ESO)
12
CORBA + Container/Component
container service
interface:
functional
interface:
lifecycle
interface:
init()
run()
restart()
Comp
observe()
Comp
getComponent(other)
Logger getLogger()
container
CORBA
Manager
ORBs
Services
deployment
configurations
Software Technology Forum 2002 - Heiko Sommer (ESO)
other
ACS
services
13
CORBA + Container/Component
Tight vs. Porous Container
container manages
start-up, remoting, …,
but exposes the
component’s functional
interface directly
tight container
Comp
Comp
Comp
functional interface is
intercepted by container
por. container
CORBA, ACS services
Software Technology Forum 2002 - Heiko Sommer (ESO)
14
CORBA + Container/Component
Warum nicht EJB Container für Java Komp.?
• Pro: etablierter Standard, keine Eigenentwicklung,
kooperiert mit CORBA
• ALMA Komponenten sind meist stateless. Sie
bearbeiten value objects oder backend systems.
Daher Stateless Session Beans (oder Message
Driven Beans für asynchronen Zugriff)
• Leistungen des EJB Container für SLSBs lediglich:
– Instanz-Pooling
– daraus folgend auch automatische Threadsicherheit
Software Technology Forum 2002 - Heiko Sommer (ESO)
15
CORBA + Container/Component
Warum nicht EJB Container für Java Komp.? (2)
• Anpassung von EJB Container schwierig
– für transparente Integration der XML value objects
– für zentrale Administration des Gesamtsystems
(bestehende Eigenentwicklung)
• Integration mit CORBA nicht trivial
– Interface Beschreibungen als IDL
– Exceptions
– Services
• Freie Verfügbarkeit von EJB Application Servern
erscheint ungewisser als bei CORBA ORBs
Software Technology Forum 2002 - Heiko Sommer (ESO)
16
XML value objects
Kommunikation
Warum Value Objects?
• Weniger Remote Calls/Netzbelastung, daher
Performanzgewinn
• Laufzeitentkoppelung der Rechner erhöht
Ausfallsicherheit
transport
by value
remote
object
value object
obj.getFoo()
Subsystem1
Software Technology Forum 2002 - Heiko Sommer (ESO)
Logik
Subsystem2
17
XML value objects
Welche Daten als Value Objects?
• Persistente Objekte, z.B. “User”,
“ObservingProject”, “CorrelatorConfig”
• zusätzlich einige weitere Typen, die “umsortierte”
Sichten auf persistente Value Objects darstellen
• einfache Parameter können IDL Datentypen
bleiben
• Listen von Value Objects nicht als eigenständige
VO definieren, sondern mittels CORBA sequences.
Software Technology Forum 2002 - Heiko Sommer (ESO)
18
XML value objects
Kommunikation
XML als Format für Value Objects
Bei Verwendung von CORBA und verschiedenen
Programmiersprachen wären CORBA valuetypes
das einzige alternative Standardformat.
Vergleich:
• XML auch für Persistenz der Daten geeignet
• XML auch für nicht-CORBA-Transport
– http oder email zum Einsenden von ObsProjects
– Remote Administration
Software Technology Forum 2002 - Heiko Sommer (ESO)
19
XML value objects
Kommunikation
XML als Format für Value Objects (2)
• XML Schema bietet strengere Deklaration und
damit mächtigere automatisierbare Validierung
• CORBA valuetypes nicht ausreichend von ORBs
unterstützt
• XML “von Hand” manipulierbar. Besonders wichtig
bei stufenweiser Inbetriebnahme der Software.
Software Technology Forum 2002 - Heiko Sommer (ESO)
20
XML value objects
Kommunikation
Warum Trennung von Daten/Funktionalität
durch XML Value Objects? (“Anti-OO”)
• Trennung der Subsysteme (gleiche Idee wie bei
Web Services)
– Logische Entkoppelung: Absprachen zwischen allen Teams
nur über Datenstrukturen
– verteilte Funktionalität (teilweise redundant) erfordert
Absprache nur zwischen weniger Partnern
– Technische Trennung: Implementierungen der
Funktionalität in verschiedenen Programmiersprachen
Software Technology Forum 2002 - Heiko Sommer (ESO)
21
XML value objects
Kommunikation
“Rechtfertigung” der Trennung von Daten/
Funktionalität durch XML Value Objects (2)
• Verschiedene ALMA Subsysteme operieren recht
unterschiedlich auf denselben Daten. Ein
einheitliches Objektmodell über Subsysteme
hinweg brächte oft nur geringe Vorteile.
• Umfangreiche Operationen auf den Daten, die in
mehreren Subsystemen benötigt werden, werden
als “stateless” Komponenten (Services)
implementiert.
Das Value Object wird dem Service zugespielt und
verändert wieder abgeholt.
Software Technology Forum 2002 - Heiko Sommer (ESO)
22
XML value objects
Persistenz
• Nur ein Serialisierungsformat für Datenaustausch
zwischen Komponenten und für Persistenz der
Daten in der Datenbank
– Schnellere Entwicklung
– Geringere Anzahl an Technologien (Zuverlässigkeit)
• Einfaches lokales Speichern
– auf Astronomen-Laptop
– allgemein während der Entwicklung (Archiv noch nicht
fertig…)
• XML schema kann zur Beschreibung des
Datenmodells dienen, selbst wenn keine XML
Datenbank verwendet wird.
Software Technology Forum 2002 - Heiko Sommer (ESO)
23
CORBA + Container/Component
Warum nicht Web Services?
• CORBA IIOP effizienter als HTTP
• Fehlende Optimierung im selben Adressraum
– entweder alle Aufrufe ueber Web Service layer
– oder verschiedene Interfaces: Client-Komponente muss
wissen, ob die Server-Komponenten local oder remote ist
(Objektreferenz oder XML), keine Transparenz mehr
• XML marshalling für alle Paramter (unperformant)
– mit CORBA koennen wir entscheiden, welche Daten XML
Value Object oder CORBA struct sind
Software Technology Forum 2002 - Heiko Sommer (ESO)
24
XML value objects
Datenstrukturen
Wie werden komplexe Strukturen abgebildet?
• Gruppierung in verschiedene xml schemas
• Referenzierung
– innerhalb eines Schemas: als Kind-Element
– über Schemas hinweg: durch eine ID
a2
a3
a1
a4
ref_b1
b2
reference
b1
by ID
XML Doc 1
schema A imports schema B
Software Technology Forum 2002 - Heiko Sommer (ESO)
b3
XML Doc 2
schema B
25
XML value objects
Datenstrukturen
Feste Portionierung der XML Daten durch das
Schema-Design und Entkoppelung über IDs
• verhindert unsinnigen Transport kompletter
Datenbäume, oder komplizierten automatischen
Nachlade-Mechanismus
• ist vor allem dann sinnvoll, wenn meistens
ähnliche Sichten auf das Datenmodell benötigt
werden (bei ALMA erfüllt)
• die Applikationen müssen sich selber um die
Referenzierung zwischen XML Dokumenten
kümmern (beim Erzeugen und Nachladen)
Software Technology Forum 2002 - Heiko Sommer (ESO)
26
XML value objects
Datenstrukturen
Anmerkungen zu den IDs
• ID wird in einer Singleton Factory erzeugt, die an
die Datenbank gekoppelt ist.
• die Applikationskomponente bittet ihren Container,
ein neu erzeugtes Value Object mit einer frischen
ID zu versorgen.
• ID wird redundant verschlüsselt im XML Dokument
gehalten, um spätere Änderungen auszuschließen.
Software Technology Forum 2002 - Heiko Sommer (ESO)
27
XML Binding
Beschreibung, Vorteile
• Java/C++ Klassen werden vom Binding Framework
gemäss unserer XML Schemas generiert
– Teil des Software Buildprozesses
• Typsichere get()/set() Methoden statt generischem
Zugriff
– auf Binding Classes basierende Value Objects sind daher
garantiert aktuell
– sonst Compilefehler (statt Laufzeitfehler)
• Parsen und Validierung sind im Binding Class Code
enthalten, dadurch potentiell performanter als
generische Methoden
• Castor (Java), evtl. XML Object Link (C++)
Software Technology Forum 2002 - Heiko Sommer (ESO)
28
XML Binding
Beispiel: Schemaauszug für “Scheduling Block”
<xsd:element name="SchedBlock">
<xsd:complexType>
<xsd:complexContent>
<xsd:extension base="prj:ObsUnitT">
<xsd:sequence>
<xsd:element name="SchedBlockEntity" type="sbl:SchedBlockEntityT"/>
<xsd:element name="ObsProjectRef" type="prj:ObsProjectRefT"/>
<xsd:element name="SchedBlockImaging" type="prj:ImagingProcedureT"/>
<xsd:element name="ObsProcedure" type="sbl:ObsProcedureT"/>
<xsd:element name="ObsTarget" type="sbl:TargetT" maxOccurs="unbounded"/>
<xsd:element name="PhaseCalTarget" type="sbl:TargetT" minOccurs="0”
maxOccurs="unbounded"/>
<xsd:element name="PointingCalTarget" type="sbl:TargetT" minOccurs="0”
maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
</xsd:element>
Software Technology Forum 2002 - Heiko Sommer (ESO)
29
XML Binding
Beispiel: Castor Binding Class für “Scheduling Block”
package alma.entity.xmlbinding.schedblock;
public class SchedBlock
extends alma.entity.xmlbinding.obsproject.ObsUnitT
implements java.io.Serializable
{
// just a few of the generated methods
public void addObsTarget(TargetT vObsTarget) {…}
public java.util.Enumeration enumerateObsTarget()
{…}
public
alma.entity.xmlbinding.obsproject.ImagingProcedureT
getSchedBlockImaging() {…}
}
Software Technology Forum 2002 - Heiko Sommer (ESO)
30
XML Binding
Verwendung der Binding Classes
Programmiermodelle
• Binding Classes direkt verwenden
– triviale Funktionalität in Helper Klassen
– andere Funktionalität in Services
• Wrapping oder Subclassing
– Funktionalität und Daten zusammen
– klare Strukturvorgabe für weniger erfahrene Entwickler
• separates Objektmodell relativ unabhängig von
Binding Classes
– Mapper code verwendet Binding Classes für XML De-/
Serialisierung.
– Empfohlen für erfahrene Entwickler und entsprechend
komplexe Subsysteme
Software Technology Forum 2002 - Heiko Sommer (ESO)
31
XML Binding
Organisation der Namespaces
• mehrere zusammengehörende Value Objects
werden in einem Schema gebündelt
• ein solches Schema bekommt einen eigenen XML
Namespace (<xsd:import …>) z.B.
“Alma/ObsProject”
• das Schema kann auf verschiedene Files mit
gleichem NS verteilt werden (<xsd:include …>)
• Vorteil: Castor bildet XML NS auf Java Packages
ab, so dass die zahlreichen generierten files
übersichtlicher in verschiedenen Packages liegen
Software Technology Forum 2002 - Heiko Sommer (ESO)
32
XML Binding
Erfahrungen mit dem Castor-XML Binding Framework
• http://www.castor.org/
– open source Projekt von Exolab
– nur Castor-XML, nicht JDO und andere features
• Leistungsspektrum
– entscheidend: xml schema statt DTD
– einige wenige Schemakonstrukte werden nicht
unterstützt; bislang kein Problem für ALMA
– derzeit etwas langsame Weiterentwicklung
• Zuverlässigkeit
– weniger häufig genutzte features teilweise fehlerhaft
– funktionierende features blieben bislang auch stabil
• Selbsthilfe: patches werden dankbar akzeptiert
Software Technology Forum 2002 - Heiko Sommer (ESO)
33
Transparente XML Integration
Fachliche Interfaces von Komponenten sollen
“native binding classes” statt “flat XML”
enthalten.
• Komponenten und ihre Clients müssen dann nicht
explizit XML Parameter parsen/serialisieren
– weniger Code schreiben
– kein Kontakt mit XML bei Berührungsängsten
• Optimierung durch Container:
kann binding object durchreichen (ohne de-/
serialising), falls “client-” und “server-”
Komponenten im selben Adressraum sind.
Software Technology Forum 2002 - Heiko Sommer (ESO)
34
Transparente XML Integration
Datenaustausch
Mit CORBA allein nicht möglich, daher Zwischenschicht mit Java Reflection bzw. Codegenerator
(kann als Teil des Containers betrachtet werden)
Flat-XML API seen
from outside
XML
XML
container
Software Technology Forum 2002 - Heiko Sommer (ESO)
Comp
Comp
Transparent-XML
API implemented
by component
Comp
Mapping code
layer
container
35
Transparente XML Integration
Codegenerierung am Beispiel Java
IDL IF
typedef xmlstring
ObsProject;
…
ObsProject
getObsProject()
IDL
compiler
Flat-XML IF
...
String
getObsProject()
mapping code
“IDL-XML”
code
generator
XML-Java binding:
“ObsProject” ->
alma.data.ObsProject
Software Technology Forum 2002 - Heiko Sommer (ESO)
return
getObsProject.marshal()
Transparent-XML IF
...
alma.data.ObsProject
getObsProject()
36
Transparente XML Integration
Bemerkungen
• Transparente XML-de/serialisierung auch dann,
falls beide Komponenten in verschiedenen
Sprachen implementiert sind
• Intern alles CORBA: sicheres remoting
• Kein Zwang: sowohl Client- als auch ServerKomponente können jederzeit direkt auf CORBA
aufsetzen
– falls es keinen code generator für eine bestimmte Sprache
gibt
– um einen speziellen Parser einzusetzen oder das XML
ungeparst durchzureichen
Software Technology Forum 2002 - Heiko Sommer (ESO)
37
Details
Some Diagrams we’ll look at if there’s enough time
left...
Software Technology Forum 2002 - Heiko Sommer (ESO)
38
Architektur Diagramm
functional interface:
IDL, flat XML
value
object
XML
J container
IDL
Comp
Comp
XML
Comp
functional
interface:
IDL, binding
classes
lifecycle
interface
C++ container
CORBA, ACS services
Datamodel APIs
XML
Warehouse
file
Software Technology Forum 2002 - Heiko Sommer (ESO)
ORBs,
deployment
configs
39
Transparente XML Integration
CORBA view
Operations IF
(Flat-XML)
use me to get
XML as a string
CORBA remoting
Stub
implements
Skeleton
inherits
TransparentXML IF
delegation
SkeletonImpl
(mapping)
implements
delegation
Proxy
(mapping)
calls
Client
Component
Software Technology Forum 2002 - Heiko Sommer (ESO)
Servant
I get that IF from my
container - don’t care
about remote or local
40
CORBA + Container/Component
Warum nicht Web Services?
• CORBA IIOP effizienter als HTTP
• Fehlende Optimierung im selben Adressraum
– entweder alle Aufrufe ueber Web Service layer
– oder verschiedene Interfaces: Client-Komponente muss
wissen, ob die Server-Komponenten local oder remote ist
(Objektreferenz oder XML), keine Transparenz mehr
• XML marshalling für alle Paramter (unperformant)
– mit CORBA koennen wir entscheiden, welche Daten XML
Value Object oder CORBA struct sind
Software Technology Forum 2002 - Heiko Sommer (ESO)
41