Скачать презентацию ACS extended ACS as the framework for the Скачать презентацию ACS extended ACS as the framework for the

dadecedb327e2103f48eaca4ab0c4037.ppt

  • Количество слайдов: 31

ACS extended ACS as the framework for the ALMA data flow system ALMA Antennen ACS extended ACS as the framework for the ALMA data flow system ALMA Antennen (Simulation) 19. November 2002 1

Anforderungen an die Techn. Architektur • Unabhängigkeit der Subsysteme (build und run) • Verteilung 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 19. November 2002 2

Architektur: Kernelemente • Auf CORBA aufbauendes leichtgewichtiges Komponentenmodell • Entkoppelung der Subsysteme durch “Object 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) 19. November 2002 3

CORBA + Container/Component Warum Container/Component Modell? • Technische Belange zentral regeln und vor Entwicklern 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 19. November 2002 4

CORBA + Container/Component ALMA Container-Components • Eine Komponente ist ein spezieller CORBA servant – 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 19. November 2002 5

Extending ACS for Data Flow Systems ACS for Control Systems Java, no C++ Macros Extending ACS for Data Flow Systems ACS for Control Systems Java, no C++ Macros and memory management you’ve seen it. . . Activator ACS Container CORBA Manager ORBs Services 19. November 2002 Comp COB no Properties/Characteristics deployment configurations other ACS services 6

CORBA + Container/Component container service interface: functional interface: lifecycle interface: init() run() restart() CORBA CORBA + Container/Component container service interface: functional interface: lifecycle interface: init() run() restart() CORBA ORBs Services 19. November 2002 Comp observe() Comp get. Component(other) Logger get. Logger() container Manager deployment configurations other ACS services 7

CORBA + Container/Component Tight vs. Porous Container container manages start-up, remoting, …, but exposes CORBA + Container/Component Tight vs. Porous Container container manages start-up, remoting, …, but exposes the component’s functional interface directly tight container Comp functional interface is intercepted by container por. container CORBA, ACS services 19. November 2002 8

XML value objects Kommunikation Warum Value Objects? • Weniger Remote Calls/Netzbelastung, daher Performanzgewinn • 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. get. Foo() obj. g et. Foo Subsystem 1 19. November 2002 () Logik Subsystem 2 9

XML value objects Welche Daten als Value Objects? • Persistente Objekte, z. B. “User”, XML value objects Welche Daten als Value Objects? • Persistente Objekte, z. B. “User”, “Observing. Project”, “Correlator. Config” • 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 19. November 2002 10

XML value objects Kommunikation XML als Format für Value Objects Bei Verwendung von CORBA 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 Obs. Projects – Remote Administration 19. November 2002 11

XML value objects Kommunikation XML als Format für Value Objects (2) • XML Schema 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. 19. November 2002 12

XML value objects Kommunikation Warum Trennung von Daten/Funktionalität durch XML Value Objects? (“Anti-OO”) • 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 19. November 2002 13

XML value objects Kommunikation “Rechtfertigung” der Trennung von Daten/ Funktionalität durch XML Value Objects 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. 19. November 2002 14

XML value objects Persistenz • Nur ein Serialisierungsformat für Datenaustausch zwischen Komponenten und für 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. 19. November 2002 15

XML value objects Datenstrukturen Wie werden komplexe Strukturen abgebildet? • Gruppierung in verschiedene xml 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 a 2 a 3 a 1 a 4 ref_b 1 b 2 reference b 1 by ID XML Doc 1 schema A imports schema B 19. November 2002 b 3 XML Doc 2 schema B 16

XML value objects Datenstrukturen Feste Portionierung der XML Daten durch das Schema-Design und Entkoppelung 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) 19. November 2002 17

XML value objects Datenstrukturen Anmerkungen zu den IDs • ID wird einmalig durch Factory 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 19. November 2002 18

XML Binding Beschreibung, Vorteile • Java/C++ Klassen werden vom Binding Framework gemäss unserer XML 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++) 19. November 2002 19

" src="http://present5.com/presentation/dadecedb327e2103f48eaca4ab0c4037/image-20.jpg" alt="XML Binding Beispiel: Schemaauszug für “Scheduling Block” " /> XML Binding Beispiel: Schemaauszug für “Scheduling Block” 19. November 2002 20

XML Binding Beispiel: Castor Binding Class für “Scheduling Block” package alma. entity. xmlbinding. schedblock; XML Binding Beispiel: Castor Binding Class für “Scheduling Block” package alma. entity. xmlbinding. schedblock; public class Sched. Block extends alma. entity. xmlbinding. obsproject. Obs. Unit. T implements java. io. Serializable { // just a few of the generated methods public void add. Obs. Target(Target. T v. Obs. Target) {…} public java. util. Enumeration enumerate. Obs. Target() {…} public alma. entity. xmlbinding. obsproject. Imaging. Procedure. T get. Sched. Block. Imaging() {…} } 19. November 2002 21

XML Binding Verwendung der Binding Classes Programmiermodelle • Binding Classes direkt verwenden – triviale 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 19. November 2002 22

XML Binding Organisation der Namespaces • mehrere zusammengehörende Value Objects werden in einem Schema 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/Obs. Project” • 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 19. November 2002 23

XML Binding Erfahrungen mit dem Castor-XML Binding Framework • http: //www. castor. org/ – 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 19. November 2002 24

Transparente XML Integration Fachliche Interfaces von Komponenten sollen “native binding classes” statt “flat XML” 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. 19. November 2002 25

Transparente XML Integration Datenaustausch Mit CORBA allein nicht möglich, daher Zwischenschicht durch selbstgeschriebenen Codegenerator 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 19. November 2002 container Comp Transparent-XML API implemented by component Comp Mapping code layer container 26

Transparente XML Integration Codegenerierung am Beispiel Java IDL IF typedef xmlstring Obs. Project; … Transparente XML Integration Codegenerierung am Beispiel Java IDL IF typedef xmlstring Obs. Project; … Obs. Project get. Obs. Project() IDL compiler mapping code “IDL-XML” code generator XML-Java binding: “Obs. Project” -> alma. data. Obs. Project 19. November 2002 Flat-XML IF. . . String get. Obs. Project() return get. Obs. Project. marshal() Transparent-XML IF. . . alma. data. Obs. Project get. Obs. Project() 27

Transparente XML Integration Bemerkungen • Transparente XML-de/serialisierung auch dann, falls beide Komponenten in verschiedenen 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 19. November 2002 28

Details Some Diagrams we’ll look at if there’s enough time left. . . 19. Details Some Diagrams we’ll look at if there’s enough time left. . . 19. November 2002 29

Architektur Diagramm functional interface: IDL, flat XML value object XML IDL Datamodel APIs XML Architektur Diagramm functional interface: IDL, flat XML value object XML IDL Datamodel APIs XML Warehouse 19. November 2002 file J container Comp XML Comp functional interface: IDL, binding classes lifecycle interface C++ container CORBA, ACS services ORBs, deployment configs 30

Transparente XML Integration CORBA view Operations IF (Flat-XML) use me to get XML as Transparente XML Integration CORBA view Operations IF (Flat-XML) use me to get XML as a string CORBA remoting Stub implements Skeleton inherits Transparent. XML IF delegation implements Proxy (mapping) delegation calls Client Component 19. November 2002 Skeleton. Impl (mapping) Servant I get that IF from my container - don’t care about remote or local 31