ACS extended ACS as the framework for the ALMA data flow system ALMA Antennen (Simulation) Unrealistisches ALMA Szenario… und was ESO bislang so gebaut hat…weil wir gleich von Architektur reden… Adapted from slides for “Software Technology Forum 2002” - Heiko Sommer (ESO)

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 Bei ALMA wurde in Abwandlung des UP zwischen Technischer und Fachlicher Architektur unterschieden. Adapted from slides for “Software Technology Forum 2002” - Heiko Sommer (ESO)

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) vollautomatische Ablaufsteuerung Ueberwachung durch Admin/Operator Adapted from slides for “Software Technology Forum 2002” - Heiko Sommer (ESO)

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 Technically, a container is a specific kind of framework as opposed to a collection of libraries. It will perform some tasks transparently. Adapted from slides for “Software Technology Forum 2002” - Heiko Sommer (ESO)

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, log-levels, ...) aus zentralen Repositories vollautomatische Ablaufsteuerung Ueberwachung durch Admin/Operator Adapted from slides for “Software Technology Forum 2002” - Heiko Sommer (ESO)

Extending ACS Manager other CORBA ACS services ACS for Data Flow Systems Java, no C++ Macros and memory management no Properties/Characteristics ACS for Control Systems you’ve seen it... COB Comp Activator COB ACS Container Comp vollautomatische Ablaufsteuerung Ueberwachung durch Admin/Operator CORBA ORBs Services Manager deployment configurations other ACS services Adapted from slides for “Software Technology Forum 2002” - Heiko Sommer (ESO)

CORBA + Container/Component container service interface: getComponent(other) Logger getLogger() functional interface: observe() lifecycle interface: init() run() restart() Comp container Comp vollautomatische Ablaufsteuerung Ueberwachung durch Admin/Operator Manager deployment configurations other ACS services CORBA ORBs Services Adapted from slides for “Software Technology Forum 2002” - Heiko Sommer (ESO)

CORBA + Container/Component Tight vs. Porous Container functional interface is intercepted by container container manages start-up, remoting, …, but exposes the component’s functional interface directly Comp Comp Comp vollautomatische Ablaufsteuerung Ueberwachung durch Admin/Operator por. container tight container CORBA, ACS services Adapted from slides for “Software Technology Forum 2002” - Heiko Sommer (ESO)

XML value objects Kommunikation Warum Value Objects? Weniger Remote Calls/Netzbelastung, daher Performanzgewinn Laufzeitentkoppelung der Rechner erhöht Ausfallsicherheit remote object transportby value value object Subsystem2 Logik obj.getFoo() Ausfallsicherheit beim Abschalten (z.B. für SW Update) eines Teilsystems ist gerade während des Aufbaus (immerhin einige Jahre) wichtig. obj.getFoo() Subsystem1 Adapted from slides for “Software Technology Forum 2002” - Heiko Sommer (ESO)

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 Ausfallsicherheit beim Abschalten (z.B. für SW Update) eines Teilsystems ist gerade während des Aufbaus (immerhin einige Jahre) wichtig. Adapted from slides for “Software Technology Forum 2002” - Heiko Sommer (ESO)

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 vollautomatische Ablaufsteuerung Ueberwachung durch Admin/Operator Adapted from slides for “Software Technology Forum 2002” - Heiko Sommer (ESO)

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. vollautomatische Ablaufsteuerung Ueberwachung durch Admin/Operator Adapted from slides for “Software Technology Forum 2002” - Heiko Sommer (ESO)

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 vollautomatische Ablaufsteuerung Ueberwachung durch Admin/Operator Adapted from slides for “Software Technology Forum 2002” - Heiko Sommer (ESO)

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. vollautomatische Ablaufsteuerung Ueberwachung durch Admin/Operator Adapted from slides for “Software Technology Forum 2002” - Heiko Sommer (ESO)

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. vollautomatische Ablaufsteuerung Ueberwachung durch Admin/Operator Adapted from slides for “Software Technology Forum 2002” - Heiko Sommer (ESO)

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 b2 a1 reference by ID vollautomatische Ablaufsteuerung Ueberwachung durch Admin/Operator a4 ref_b1 b1 b3 XML Doc 1 schema A imports schema B XML Doc 2 schema B Adapted from slides for “Software Technology Forum 2002” - Heiko Sommer (ESO)

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) vollautomatische Ablaufsteuerung Ueberwachung durch Admin/Operator Adapted from slides for “Software Technology Forum 2002” - Heiko Sommer (ESO)

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 vollautomatische Ablaufsteuerung Ueberwachung durch Admin/Operator Adapted from slides for “Software Technology Forum 2002” - Heiko Sommer (ESO)

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++) vollautomatische Ablaufsteuerung Ueberwachung durch Admin/Operator Adapted from slides for “Software Technology Forum 2002” - Heiko Sommer (ESO)

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” </xsd:sequence> </xsd:extension> </xsd:complexContent> </xsd:complexType> </xsd:element> vollautomatische Ablaufsteuerung Ueberwachung durch Admin/Operator Adapted from slides for “Software Technology Forum 2002” - Heiko Sommer (ESO)

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() {…} } vollautomatische Ablaufsteuerung Ueberwachung durch Admin/Operator Adapted from slides for “Software Technology Forum 2002” - Heiko Sommer (ESO)

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 vollautomatische Ablaufsteuerung Ueberwachung durch Admin/Operator Adapted from slides for “Software Technology Forum 2002” - Heiko Sommer (ESO)

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 vollautomatische Ablaufsteuerung Ueberwachung durch Admin/Operator Adapted from slides for “Software Technology Forum 2002” - Heiko Sommer (ESO)

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 vollautomatische Ablaufsteuerung Ueberwachung durch Admin/Operator Adapted from slides for “Software Technology Forum 2002” - Heiko Sommer (ESO)

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. vollautomatische Ablaufsteuerung Ueberwachung durch Admin/Operator Adapted from slides for “Software Technology Forum 2002” - Heiko Sommer (ESO)

Transparente XML Integration Datenaustausch Mit CORBA allein nicht möglich, daher Zwischen-schicht durch selbstgeschriebenen Codegenerator (kann als Teil des Containers betrachtet werden) Flat-XML API seen from outside XML XML Mapping code layer Comp Transparent-XML API implemented by component vollautomatische Ablaufsteuerung Ueberwachung durch Admin/Operator container Comp container Comp Adapted from slides for “Software Technology Forum 2002” - Heiko Sommer (ESO)

Transparente XML Integration Codegenerierung am Beispiel Java Flat-XML IF ... String getObsProject() IDL IF IDL compiler typedef xmlstring ObsProject; … ObsProject getObsProject() mapping code return getObsProject.marshal() “IDL-XML” code generator Transparent-XML IF ... alma.data.ObsProject getObsProject() CORBA IDL enthält XML als struct/string Codegenerator erzeugt neue API aus IDL Native binding classes statt XML strings Neue structs, interfaces etc. falls XML enthalten Automatisches de/serialisieren XML-Java binding: “ObsProject” -> alma.data.ObsProject Adapted from slides for “Software Technology Forum 2002” - Heiko Sommer (ESO)

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 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 vollautomatische Ablaufsteuerung Ueberwachung durch Admin/Operator Adapted from slides for “Software Technology Forum 2002” - Heiko Sommer (ESO)

Details Some Diagrams we’ll look at if there’s enough time left... vollautomatische Ablaufsteuerung Ueberwachung durch Admin/Operator Adapted from slides for “Software Technology Forum 2002” - Heiko Sommer (ESO)

Architektur Diagramm XML IDL CORBA, ACS services Datamodel APIs file functional interface: IDL, flat XML XML value object XML functional interface: IDL, binding classes Comp lifecycle interface J container Comp C++ container Comp IDL CORBA, ACS services vollautomatische Ablaufsteuerung Ueberwachung durch Admin/Operator Datamodel APIs ORBs, deployment configs XML Ware- house file Adapted from slides for “Software Technology Forum 2002” - Heiko Sommer (ESO)

Transparente XML Integration CORBA view Operations IF (Flat-XML) use me to get XML as a string implements CORBA remoting Stub Skeleton inherits Transparent- XML IF SkeletonImpl (mapping) delegation implements delegation calls vollautomatische Ablaufsteuerung Ueberwachung durch Admin/Operator Proxy (mapping) Servant I get that IF from my container - don’t care about remote or local Client Component Adapted from slides for “Software Technology Forum 2002” - Heiko Sommer (ESO)