Warum Value Objects?

ACS extended
ACS as the framework for
the ALMA data flow system
ALMA Antennen (Simulation)
Adapted from slides for “Software Technology Forum 2002” - Heiko Sommer (ESO)
1
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
Adapted from slides for “Software Technology Forum 2002” - Heiko Sommer (ESO)
2
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)
Adapted from slides for “Software Technology Forum 2002” - Heiko Sommer (ESO)
3
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
Adapted from slides for “Software Technology Forum 2002” - Heiko Sommer (ESO)
4
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”
Komponenten dienen
– recht willkürliche Einschränkung zur Vereinheitlichung
• Container besorgt sich sämtliche Daten zur
Systemkonfiguration (component-autoloading, loglevels, ...) aus zentralen Repositories
Adapted from slides for “Software Technology Forum 2002” - Heiko Sommer (ESO)
5
Extending ACS
ACS for Data Flow
Systems
ACS for Control Systems
Java, no C++ Macros and
memory management
you’ve seen it...
Activator
Comp
Comp
COB
COB
no Properties/Characteristics
ACS Container
CORBA
Manager
ORBs
Services
deployment
configurations
other
ACS
services
Adapted from slides for “Software Technology Forum 2002” - Heiko Sommer (ESO)
6
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
other
ACS
services
Adapted from slides for “Software Technology Forum 2002” - Heiko Sommer (ESO)
7
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
Adapted from slides for “Software Technology Forum 2002” - Heiko Sommer (ESO)
8
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
Logik
Subsystem2
Adapted from slides for “Software Technology Forum 2002” - Heiko Sommer (ESO)
9
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 arrays
Adapted from slides for “Software Technology Forum 2002” - Heiko Sommer (ESO)
10
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
Adapted from slides for “Software Technology Forum 2002” - Heiko Sommer (ESO)
11
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.
Adapted from slides for “Software Technology Forum 2002” - Heiko Sommer (ESO)
12
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
Adapted from slides for “Software Technology Forum 2002” - Heiko Sommer (ESO)
13
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.
Adapted from slides for “Software Technology Forum 2002” - Heiko Sommer (ESO)
14
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.
Adapted from slides for “Software Technology Forum 2002” - Heiko Sommer (ESO)
15
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
b3
XML Doc 2
schema B
Adapted from slides for “Software Technology Forum 2002” - Heiko Sommer (ESO)
16
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)
Adapted from slides for “Software Technology Forum 2002” - Heiko Sommer (ESO)
17
XML value objects
Datenstrukturen
Anmerkungen zu den IDs
• ID wird einmalig durch Factory zugewiesen
• ID wird redundant verschlüsselt im XML Dokument
gehalten, um Änderungen auszuschließen
Adapted from slides for “Software Technology Forum 2002” - Heiko Sommer (ESO)
18
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
• Momentan Castor (Java), bald auch Rachet (C++)
Adapted from slides for “Software Technology Forum 2002” - Heiko Sommer (ESO)
19
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>
Adapted from slides for “Software Technology Forum 2002” - Heiko Sommer (ESO)
20
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() {…}
}
Adapted from slides for “Software Technology Forum 2002” - Heiko Sommer (ESO)
21
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
Adapted from slides for “Software Technology Forum 2002” - Heiko Sommer (ESO)
22
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
Adapted from slides for “Software Technology Forum 2002” - Heiko Sommer (ESO)
23
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
Adapted from slides for “Software Technology Forum 2002” - Heiko Sommer (ESO)
24
Transparente XML Integration
Fachliche Interfaces von Komponenten sollen
“native binding classes” statt “flat XML”
enthalten.
• Komponenten 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.
Adapted from slides for “Software Technology Forum 2002” - Heiko Sommer (ESO)
25
Transparente XML Integration
Datenaustausch
Mit CORBA allein nicht möglich, daher Zwischenschicht durch selbstgeschriebenen Codegenerator
(kann als Teil des Containers betrachtet werden)
Flat-XML API seen
from outside
XML
XML
container
Adapted from slides for “Software Technology Forum 2002” - Heiko Sommer (ESO)
Comp
Comp
Transparent-XML
API implemented
by component
Comp
Mapping code
layer
container
26
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
return
getObsProject.marshal()
Transparent-XML IF
...
alma.data.ObsProject
getObsProject()
Adapted from slides for “Software Technology Forum 2002” - Heiko Sommer (ESO)
27
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
Adapted from slides for “Software Technology Forum 2002” - Heiko Sommer (ESO)
28
Details
Some Diagrams we’ll look at if there’s enough time
left...
Adapted from slides for “Software Technology Forum 2002” - Heiko Sommer (ESO)
29
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
Adapted from slides for “Software Technology Forum 2002” - Heiko Sommer (ESO)
ORBs,
deployment
configs
30
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
Servant
I get that IF from my
container - don’t care
about remote or local
Adapted from slides for “Software Technology Forum 2002” - Heiko Sommer (ESO)
31