Adapted from slides for Software Technology Forum 2002 - Heiko Sommer (ESO) 1 ALMA Antennen (Simulation) ACS extended ACS as the framework for the ALMA

Adapted from slides for “Software Technology Forum 2002” - Heiko Sommer (ESO) 1

ALMA Antennen (Simulation)

ACS extended

ACS as the framework for the ALMA data flow system


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


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)


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



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


Extending ACS

Activator

CO

B

CORBAORBs

Services

CO

B

other ACS

services

Manager deployment

configurations

ACS Container

Com

p

Com

p

ACS for Control Systems

you’ve seen it...

ACS for Data Flow Systems

Java, no C++ Macros and memory management

no Properties/Characteristics



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



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


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


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



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



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.



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



“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.


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.


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



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)



Anmerkungen zu den IDs• ID wird einmalig durch Factory zugewiesen• ID wird redundant verschlüsselt im XML Dokument

gehalten, um Änderungen auszuschließen


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

• Momentan Castor (Java), bald auch Rachet (C++)


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>


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() {…}

}


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


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


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


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.


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 durch selbstgeschriebenen Codegenerator (kann als Teil des Containers betrachtet werden)


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()


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


Details

Some Diagrams we’ll look at if there’s enough time left...


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


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

Documents

Adapted from slides for Software Technology Forum 2002 - Heiko Sommer (ESO) 1 ALMA Antennen (Simulation) ACS extended ACS as the framework for the ALMA