Einsatz offener Standards im ALMA Projekt Einsatz offener Standards im ALMA Projekt Heiko Sommer European Southern Observatory (ESO) Software Technology.

Präsentation zum Thema: "Einsatz offener Standards im ALMA Projekt Einsatz offener Standards im ALMA Projekt Heiko Sommer European Southern Observatory (ESO) Software Technology."—  Präsentation transkript:

1 Einsatz offener Standards im ALMA Projekt Einsatz offener Standards im ALMA Projekt Heiko Sommer European Southern Observatory (ESO) Software Technology Forum 2002 Fachforum Datenaustausch mit XML 19. November 2002

2 Software Technology Forum 2002 - Heiko Sommer (ESO) 2 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

3 Software Technology Forum 2002 - Heiko Sommer (ESO) 3 ESO Headquarters, GarchingVery Large Telescope, Chile ALMA Antennen (Simulation)

4 Software Technology Forum 2002 - Heiko Sommer (ESO) 4 ALMA Software Schwerpunkt offene Standardtechnologien Absichten der Softwarearchitektur Welche Standardtechnologien? Warum? Warum andere nicht? Wann durch Eigenentwicklungen ergänzt? Wie werden sie eingesetzt?

5 Software Technology Forum 2002 - Heiko Sommer (ESO) 5 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)

6 Software Technology Forum 2002 - Heiko Sommer (ESO) 6 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

7 Software Technology Forum 2002 - Heiko Sommer (ESO) 7 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)

8 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

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

10 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

11 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

12 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

13 Software Technology Forum 2002 - Heiko Sommer (ESO) 13 CORBA + Container/Component container Comp CORBA ORBs Services lifecycle interface: init() run() restart() Comp functional interface: observe() container service interface: getComponent(other) Logger getLogger() other ACS services Manager deployment configurations

14 Software Technology Forum 2002 - Heiko Sommer (ESO) 14 CORBA + Container/Component por. container tight container Comp CORBA, ACS services Comp functional interface is intercepted by container Tight vs. Porous Container container manages start-up, remoting, …, but exposes the components functional interface directly

15 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

16 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

17 Software Technology Forum 2002 - Heiko Sommer (ESO) 17 XML value objects Kommunikation Warum Value Objects? Weniger Remote Calls/Netzbelastung, daher Performanzgewinn Laufzeitentkoppelung der Rechner erhöht Ausfallsicherheit Subsystem2 Logik obj.getFoo() Subsystem1 obj.getFoo() transport by value value object remote object

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

19 Software Technology Forum 2002 - Heiko Sommer (ESO) 19 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

20 Software Technology Forum 2002 - Heiko Sommer (ESO) 20 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.

21 Software Technology Forum 2002 - Heiko Sommer (ESO) 21 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

22 Software Technology Forum 2002 - Heiko Sommer (ESO) 22 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.

23 Software Technology Forum 2002 - Heiko Sommer (ESO) 23 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.

24 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

25 Software Technology Forum 2002 - Heiko Sommer (ESO) 25 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 a1 a4 a2 XML Doc 1 schema A imports schema B XML Doc 2 schema B b1 a3 b3 b2 ref_b1 reference by ID

26 Software Technology Forum 2002 - Heiko Sommer (ESO) 26 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)

27 Software Technology Forum 2002 - Heiko Sommer (ESO) 27 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.

28 Software Technology Forum 2002 - Heiko Sommer (ESO) 28 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++)

29 Software Technology Forum 2002 - Heiko Sommer (ESO) 29 XML Binding Beispiel: Schemaauszug für Scheduling Block <xsd:element name="PhaseCalTarget" type="sbl:TargetT" minOccurs="0 maxOccurs="unbounded"/> <xsd:element name="PointingCalTarget" type="sbl:TargetT" minOccurs="0 maxOccurs="unbounded"/>

30 Software Technology Forum 2002 - Heiko Sommer (ESO) 30 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() {…} }

31 Software Technology Forum 2002 - Heiko Sommer (ESO) 31 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

32 Software Technology Forum 2002 - Heiko Sommer (ESO) 32 XML Binding Organisation der Namespaces mehrere zusammengehörende Value Objects werden in einem Schema gebündelt ein solches Schema bekommt einen eigenen XML Namespace ( ) z.B. Alma/ObsProject das Schema kann auf verschiedene Files mit gleichem NS verteilt werden ( ) Vorteil: Castor bildet XML NS auf Java Packages ab, so dass die zahlreichen generierten files übersichtlicher in verschiedenen Packages liegen

33 Software Technology Forum 2002 - Heiko Sommer (ESO) 33 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

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

35 Software Technology Forum 2002 - Heiko Sommer (ESO) 35 container Comp Transparente XML Integration Datenaustausch container Comp XML Comp Flat-XML API seen from outside Transparent-XML API implemented by component Mapping code layer XML Mit CORBA allein nicht möglich, daher Zwischen- schicht mit Java Reflection bzw. Codegenerator (kann als Teil des Containers betrachtet werden)

36 Software Technology Forum 2002 - Heiko Sommer (ESO) 36 Transparente XML Integration Codegenerierung am Beispiel Java IDL-XML code generator XML-Java binding: ObsProject -> alma.data.ObsProject Transparent-XML IF... alma.data.ObsProject getObsProject() IDL compiler typedef xmlstring ObsProject; … ObsProject getObsProject() IDL IF Flat-XML IF... String getObsProject() mapping code return getObsProject.marshal()

37 Software Technology Forum 2002 - Heiko Sommer (ESO) 37 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

38 Software Technology Forum 2002 - Heiko Sommer (ESO) 38 Details Some Diagrams well look at if theres enough time left...

39 Software Technology Forum 2002 - Heiko Sommer (ESO) 39 Architektur Diagramm XML Ware- house file Datamodel APIs C++ containerJ container Comp CORBA, ACS services Comp XML IDL ORBs, deployment configs value object lifecycle interface Comp functional interface: IDL, binding classes functional interface: IDL, flat XML

40 Software Technology Forum 2002 - Heiko Sommer (ESO) 40 Transparente XML Integration CORBA view Operations IF (Flat-XML) SkeletonStub SkeletonImpl (mapping) inherits implements Transparent- XML IF Servant delegation implements Proxy (mapping) delegation Client Component I get that IF from my container - dont care about remote or local calls use me to get XML as a string CORBA remoting

41 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