Upload
wieland-boness
View
104
Download
1
Embed Size (px)
Citation preview
Einsatz offener Standards im Einsatz offener Standards im ALMA ProjektALMA Projekt
Heiko SommerEuropean Southern Observatory (ESO)
Software Technology Forum 2002Fachforum “Datenaustausch mit XML”
19. November 2002
Software Technology Forum 2002 - Heiko Sommer (ESO) 2
ALMA Projekt
Chile, Atacamawüste (5000 m): 64 Radioantennenweltweit 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) 3
ESO Headquarters, Garching“Very Large Telescope”, Chile
ALMA Antennen (Simulation)
Software Technology Forum 2002 - Heiko Sommer (ESO) 4
ALMA SoftwareSchwerpunkt 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) 5
ALMA Softwaregrobe 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) 6
ALMA Software EntwicklungProjektsituation
• 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) 7
ALMA Software EntwicklungProjektsituation (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) 8
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) 9
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) 10
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) 11
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) 12
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, log-levels, ...) aus zentralen Repositories
Software Technology Forum 2002 - Heiko Sommer (ESO) 13
CORBA + Container/Component
container
Com
p
CORBAORBs
Services
lifecycleinterface:init()run()restart()
Com
p
functionalinterface:observe()
container serviceinterface:getComponent(other)Logger getLogger()
other ACS
services
Manager deployment
configurations
Software Technology Forum 2002 - Heiko Sommer (ESO) 14
CORBA + Container/Component
por. containertight container
Com
p
CORBA, ACS servicesC
omp
Com
p
functional interface is intercepted by container
Tight vs. Porous Container
container manages start-up, remoting, …,but exposes the component’s functional interface directly
Software Technology Forum 2002 - Heiko Sommer (ESO) 15
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) 16
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) 17
XML value objectsKommunikation
Warum Value Objects?• Weniger Remote Calls/Netzbelastung, daher
Performanzgewinn• Laufzeitentkoppelung der Rechner erhöht
Ausfallsicherheit
Subsystem2Logik
obj.getFoo()
Subsystem1
obj.getFoo()
transportby value
value objectremoteobject
Software Technology Forum 2002 - Heiko Sommer (ESO) 18
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) 19
XML value objectsKommunikation
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) 20
XML value objectsKommunikation
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) 21
XML value objectsKommunikation
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) 22
XML value objectsKommunikation
“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) 23
XML value objectsPersistenz
• 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) 24
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) 25
XML value objectsDatenstrukturen
Wie werden komplexe Strukturen abgebildet?• Gruppierung in verschiedene xml schemas• Referenzierung
– innerhalb eines Schemas: als Kind-Element – über Schemas hinweg: durch eine ID
a1a4
a2
XML Doc 1schema A imports schema B
XML Doc 2 schema B
b1
a3
b3
b2
ref_b1reference
by ID
Software Technology Forum 2002 - Heiko Sommer (ESO) 26
XML value objectsDatenstrukturen
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) 27
XML value objectsDatenstrukturen
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) 28
XML BindingBeschreibung, 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) 29
XML BindingBeispiel: 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) 30
XML BindingBeispiel: 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) 31
XML BindingVerwendung 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) 32
XML BindingOrganisation 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) 33
XML BindingErfahrungen 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) 34
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) 35
containerC
omp
Transparente XML IntegrationDatenaustausch
container
Com
p
XMLC
omp
Flat-XML API seen from outside
Transparent-XML API implemented
by component
Mapping codelayer
XML
Mit CORBA allein nicht möglich, daher Zwischen-schicht mit Java Reflection bzw. Codegenerator (kann als Teil des Containers betrachtet werden)
Software Technology Forum 2002 - Heiko Sommer (ESO) 36
Transparente XML IntegrationCodegenerierung am Beispiel Java
“IDL-XML”code
generator
XML-Java binding:“ObsProject” ->
alma.data.ObsProject
Transparent-XML IF
...alma.data.ObsProject
getObsProject()
IDL compilertypedef xmlstring
ObsProject; …
ObsProjectgetObsProject()
IDL IF
Flat-XML IF...
StringgetObsProject()
mapping code
returngetObsProject.marshal()
Software Technology Forum 2002 - Heiko Sommer (ESO) 37
Transparente XML IntegrationBemerkungen
• 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 Server-
Komponente 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) 38
Details
Some Diagrams we’ll look at if there’s enough time left...
Software Technology Forum 2002 - Heiko Sommer (ESO) 39
Architektur Diagramm
XML Ware-house file
Datamodel APIs
C++ containerJ containerC
omp
CORBA, ACS services
Com
p
XML
XML
IDL
ORBs, deploymentconfigs
value object
lifecycleinterfaceC
ompfunctional
interface: IDL, binding classes
functional interface: IDL, flat XML
Software Technology Forum 2002 - Heiko Sommer (ESO) 40
Transparente XML IntegrationCORBA view
Operations IF(Flat-XML)
SkeletonStub
SkeletonImpl(mapping)
inherits
implements
Transparent-XML IF
Servant
delegationimplements
Proxy(mapping)
delegation
Client Component
I get that IF from mycontainer - don’t care about remote or local
calls
use me to getXML as a string
CORBA remoting
Software Technology Forum 2002 - Heiko Sommer (ESO) 41
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