Seminar "Component and Aspect Engineering" WS2003 CORBA Component Model Aleksej Palij, palij@informatik.uni-bonn.de.

Präsentation zum Thema: "Seminar "Component and Aspect Engineering" WS2003 CORBA Component Model Aleksej Palij, palij@informatik.uni-bonn.de."—  Präsentation transkript:

1 Seminar "Component and Aspect Engineering" WS CORBA Component Model Aleksej Palij,

2 Inhalt Motivation Übersicht des CORBA Komponentenmodels (CCM)
Konzepte Abstraktes Model Container Model Implementationsmodel Entwicklung Packaging Model Deployment Model Alternativen im Überblick Zusammenfassung

3 CORBA Component Model (CCM)
Ist: ein verteiltes komponentenorientiertes Model Technologie für den Einsatz von binärem ausführbarem Code, der in verschiedenen Sprachen implementiert wurde Erster umfassender Komponenten-Standard Ermöglicht: Definition von Komponenten und ihrer Interaktionen Generische Implementierung von Komponentenverwaltung: Erzeugung, Aktivierung, Deaktivierung… CORBA Services: Sicherheit, Persistenz, Verteilten Transaktionen, Ereignissen Interoperabilität mit Enterprise Java Beans (EJB)

4 Motivation plug-and-play von CORBA-Objekten
einfache Integration mit anderen objektorientierten Technologien, insbesondere Java und EJB klare Kommunikationsschnittstellen zwischen CORBA-Objekten externe Konfiguration der Anwendung (nicht in Objekten versteckt) Befreiung der Objekten von Nicht-funktionslogik Berücksichtigung von Installationszeiten

5 Inhalt Motivation Übersicht des CORBA Komponentenmodels (CCM)
Konzepte Abstraktes Model Container Model Implementationsmodel Entwicklung Packaging Model Deployment Model Alternativen im Überblick Zusammenfassung

6 Abstraktes Komponentenmodel
Beschreibt: Was eine Komponente den anderen Komponenten anbietet Was eine Komponente von den anderen Komponenten braucht Welche Arten der Zusammenarbeit werden zw. den Komponenten benutzt Synchronous via operation invocation Asynchronous via event notification Welche Komponenteneigenschaften konfigurierbar sind Welche Manager für die Komponenteninstanzenverwaltung verantwortlich sind (z.B. home) Ermöglicht den Komponentendesignern es zu bestimmen, wie die CORBA-Komponenten bei den anderen Komponenten und Klienten gesehen werden

7 Was ist eine CORBA-Komponente?
“component” ist ein neuer CORBA-meta-typ Interface Definition Language (IDL) Bietet Features von Komponenten an Single inheritance supports multiple interfaces Jede Komponenteninstanz wird von einem eindeutigen Komponenten-home erzeugt und verwaltet “component” ist ein neuer CORBA-meta-typ Erweiterung des Objektes (um einige Beschränkungen) Hat ein Interface, und eine Objektreferenz

8 Component Features auch „ports“ genannt
Attributes = konfigurierbare Eigenschaften Facets = Interfaces der angebotenen Operationen Receptacles = Interfaces der benötigten Operationen Event sources = erzeugte events Event sinks = konsumierte events Navigation und Introspektion Navigation from any facet to component base reference with CORBA::Object::get_component() Navigation from component base reference to any facet via generated facet-specific operations Navigation and introspection capabilities provided by CCMObject Via the Navigation interface for facets Via the Receptacles interface for receptacles Via the Events interface for event ports auch „ports“ genannt

9 Eine CORBA-Komponente
Component reference type CORBA Component OFFERED facets REQUIRED receptacles Jetzt nicht nur angebotene Services (wie bei JavaBeans), sondern auch benötigte Services und konfigurierbare Eigenschaften. Behandlung von Exceptions von attributes Fecetsdefinition ist der beste Weg für einen Designer mehrfache Sichten/Rollen zu modelieren, Um die Bedürfnisse von allen Klienten zu erfüllen Receptacles mit mehrfachen Referenzen Sehr interesant ist Event model – im technischen Sinne hat man viel zur Auswahl: list of listners, event channel, multicast Structure introspection – findFactory, von Komponente zu Container? Abstractes model ist flach (eine Ebene) – Komposition wird nicht als eine Komponente gesehen, weil die Facets co-located sind. event sinks event sources attributes

10 Komposition CORBA Component CORBA Component CORBA Component CORBA
Akzent wird auf die Schnittstellen zu den anderen Komponenten gesetzt Graphische Bearbeitung von „ports“ ist möglich: Verbindung von „facets“ mit „receptacles“ Verbindung von „event sources“ mit „event sinks“ Configurierung von „initial attributes“ Das Ziel: Applikationszusammenstellung anstatt –entwicklung CORBA Component CORBA Component CORBA Component

11 Attribute zentraler Schlüssel für die erfolgreiche Wiederverwendbarkeit sind für die Konfiguration von Komponenten gedacht z.B., optionales Verhalten, Modalität, Ressourcenhinweise, usw. die Auslösung von Exceptions möglich Zugreifbar via “accessors” und “mutators” Konfiguration visuell via Property-Sheet-Mechanismus in Assembly oder Deployment Umgebung Bei “homes” oder während der Implementationsinitialisierung Danach möglicherweise nur lesbar Modalität – die Art und Weise wie etwas ausgefuehrt wird

12 Facets “Distinct named Interfaces” bieten die Funktionalität der komponentenbasierten Anwendung für die Klienten an Jede “facet” enthält eine Sicht der Komponente, entspricht einer Rolle, bezüglich deren ein Klient die Komponente ansprechen kann Eine “facet” representiert die Komponente selbst, nicht einen getrennten Teil davon Facets besitzen unabhängige Objektreferenzen

13 Receptacles “Distinct named connection points” für die Operationsaufrufe der anderen Komponenten Enthalten eine oder mehrere Referenzen Konfiguration statisch während der Initialisierungs- oder Assembly-Phase Wird dynamisch zur Laufzeit verwaltet um Interaktionen mit Klienten oder anderen Komponenten anzubieten (z.B. “callback”)

14 Events mit „push“-Mechanismus
Notification channel “named connection points” Event sources Publishers (“multicast”) Emitters (“unicast”) Event sinks Akzeptieren events vom bestimmten Typ Unterscheiden nicht zw. Verbindungen(emits) und Subscriptions(publishes) source emits sink publishes sink sink sink Publishers – direkte Verbindungen zw. Komponenten und Klienten Emitters – sollen zur Konfigurationszwecken benutzt Event model – im technischen Sinne hat man viel zur Auswahl: list of listners, event channel, multicast

15 Component Home Verwaltet einen eindeutigen Typ von Komponenten
“home” ist ein neuer CORBA Meta-Typ Wird instanziiert wenn die Komponente in Betrieb genommen wird Ansprechbar via HomeFinder Verwaltet einen eindeutigen Typ von Komponenten Mehrere Home-Typen können den gleichen Komponententyp verwalten Aber eine Instanz von einer Komponente wird nur von einer Home-Instanz verwaltet (z.B. erzeugt oder gelöscht) Home ist ein neuer CORBA Meta-Typ Home Definition ist verschieden von der Komponenten-Definition Home ist aber wie eine Komponente ansprechbar Hat eine eigene Objekt-Referenz Hat ein Interface (wofür  Lebenszyklusmanagement), Wird instanziiert wenn die Komponente in Betrieb genommen wird

16 HomeFinder Home Home Finder
HomeFinder ermöglicht die Ermittlung der Referenz zum gewünschten Home Interface eines Komponententyps Alle Homes können hier registriert werden (nicht automatisch) resolve_initial_reference(”ComponentHomeFinder”); Liefert HomeFinder Home Home Finder Container CORBA Component

17 CCM – IDL Beispiel Philosopher component Philosopher PhilosopherHome {
attribute string name; // The left fork receptacle. uses Fork left; // The right fork receptacle. uses Fork right; // The status info event source. publishes StatusInfo info; }; home PhilosopherHome manages Philosopher { factory new(in string name); Philosopher left right info Name = X

18 Inhalt Motivation Übersicht des CORBA Komponentenmodels (CCM)
Konzepte Abstraktes Model Container Model Implementationsmodel Entwicklung Packaging Model Deployment Model Alternativen im Überblick Zusammenfassung

19 Container Model Auch „Execution Model“ genannt
Beschreibt die Execution-Umgebung von Komponenteninstanzen Basiert hauptsächlich auf Portable Object Adaptor Automatische Aktivierung / Deaktivierung Optimisierung des Resourcenverbrauchs Bietet vereinfachte Interfaces für CORBA Services Security, transactions, persistence und events Benutzt callbacks für Instanzenmanagement Leere Container für user-definierte Frameworks

20 Container Architecture
l i e n t Home Extended OMG IDL external API Container CORBA Component Callback API Internal API POA ORB Transaction Security Persistency Notification

21 Was ist ein Component Container?
Server Runtime Environment Versorgung und Verwaltung von Resourcen für Komponenten-Instanzen Servant/component life time (memory consumption) CORBA Object Services (COM) kapselt ein oder mehrere POAs ein Verwaltet ein Typ von Komponenten entity, process, session, service, EJBsession, EJBentity, Empty server’s runtime environment for component implementation. Container implementations provide event services to components and their clients. The container is responsible for configuring the mechanism and determining the specific quality of service and routing policies to be employed when delivering events.

22 Komponententypen Service Session Process Entity stateless
Component Category Service Session Process Entity CORBA usage model stateless conversational durable Container Type Session Entity EJB type - Session Entity The component (life cycle) category is the combination of the container API type (i.e., the server view) and the external API types (i.e., the client view). The container API type is a framework made up of internal interfaces and callback interfaces used by the component developer. These are defined using the new local interface declaration in IDL for specifying locality-constrained interfaces. The container API type is selected using CIDL, which describes component implementations. The CORBA usage model defines the interactions between the container and the rest of CORBA (including the POA, the ORB, and the CORBA services) - is controlled by policies that specify distinct interaction patterns with the POA and a set of CORBA services. stateless - which uses transient object references in conjunction with a POA servant that can support any ObjectId. conversational - which uses transient references in conjunction with a POA servant that is dedicated to a specific ObjectId. durable - which uses persistent references in conjunction with a POA servant that is dedicated to a specific ObjectId.

23 Inhalt Motivation Übersicht des CORBA Komponentenmodels (CCM)
Konzepte Abstraktes Model Container Model Implementationsmodel Entwicklung Packaging Model Deployment Model Alternativen im Überblick Zusammenfassung

24 Implementationsmodel
Component Implementation Framework – CIF Beschreibt die Implementierungsstruktur und Persistenzzustand einer Komponente Component Implementation Definition Language (CIDL) Erleichtert die Imlementierung von Komponenten Es muss “nur” Business Logic implementiert werden kein port management, navigation, component life cycle etc. Komposition (von Artefakten) ist das zentrale Konzept Verwaltet Segmentierung und Persistenz Generiert Skeletons Das Ziel ist die Generierung von nicht-funktionalem Teil und Implementierung vom funktionalen. Umgesetzt mit Hilfe von Component Implementation Framework (CIF), das beschreibt, wie die funktionale und nicht-funktionale Teile interagieren sollen. Komposition (von Artefakten) ist das zentrale Konzept Eine Aggregateinheit, die alle Artefakte beschreibt, die für die Implementierung von einer Komponente und ihres Home notwendig sind Verwaltet “Segmentation” und “Persistency” We coin the term executor (e.g.-ZEK-yoo-tor) to indicate the programming artifact that supplies the behavior of a component or a component home. artifact or programming artifact to denote what may conveniently be thought of as a class, and likewise, the term skeleton to denote a generated abstract base class that is extended to form a complete implementation class. Implementations generated by a CIDL compiler are called executors. Executors contain the aforementioned auto-generated implementations and provide hook methods (Gamma, 1994) that allow component developers to add custom component-specific behavior.

25 Component Skeleton Generierung
composition <category> <composition_name>{ home executor <home_executor_name> { implements <home_type> ; manages <executor_name>; }; IDL 3 CIDL Component executor Functional Java / CIF Compiler Functional XML –> technische Beschränkungen, die während der Deployment-Phase erfüllt werden müssen. Skeleton -> verwaltet die nicht-funktioale Logik einer Komponente: implementiert IDL2 mapping – structural introspection, discovering ports, connectivity management: receptacles, event sources usw. Non functional IDL 2 XML User written Generated

26 Inhalt Motivation Übersicht des CORBA Komponentenmodels (CCM)
Konzepte Abstraktes Model Container Model Implementationsmodel Entwicklung Packaging Model Deployment Model Alternativen im Überblick Zusammenfassung

27 Packaging model Pakete (ZIP) enthalten: Softwarepaket <softpkg>
XML-Descriptor Andere (Pakete, Libraries) Softwarepaket Komponentenpaket Komponenten-Assembly-Paket <softpkg> <pkgtype> <title> <author> <description> <licence> <idl> <propertyfile> <implementation> </softpkg> Main Elements of Software Package Descriptor: Komponentenimplementierungen können zusammengepakt und verteilt werden. Ein Paket, im allgemeinen, besteht aus einem oder mehreren Beschreibern und einer Reihe von Dateien. A CORBA Component Package enthält eine oder mehrere Implementierungen von einer Kompnente. Das Paket kann auf einem Rechner installiert oder zusammen mit den anderen Komponenten gruppiert werden um eine Assembly zu bilden. Eine Component Assembly ist eine Gruppe von miteinander verbundenen durch ein Aassembly-Package representierten Komponenten. Component Package ist eine Spezialisierung von einem allgemeinem Ssoftwarepaket. Das representierte hier Softwareverpackungsschema, könnte für die verpackung von beliebigen Softwareeinheiten benutzt werden. Component- und Assembly-Pakete sind als Input für ein Deployment tool. CORBA Component Descriptor wird hauptsächlich aus CIDL generiert Container Policies müssen hinzugefügt werden *.ccd Component Assembly-Pakage Assembly descriptor Home-, Komponenteninstanzen, Verbindungen Ein oder mehrere Softwarepakete Property-Descriptor (default attributes)

28 XML Descriptors Überblick
Software Package Descriptor (.csd) CORBA Component Descriptor (.ccd) Component Assembly Descriptor (.cad) Component Property File Descriptor (.cpf) Software Package Descriptor (.csd) Beschreibt den Inhalt von component software package Listet eine oder mehrere Implementation(en) auf CORBA Component Descriptor (.ccd) Technisch Information wird hauptsächlich aus CIDL generiert Etliche Container-Policies werden von User ausgefüllt Component Assembly Descriptor (.cad) Beschreibt initial virtual configuration homes, component instances, and connections Component Property File Descriptor (.cpf) name/value Paare zur Konfiguration von Attributen

29 Component Packaging IDL User Code Compiler Generated Code Shared
Library or Executable IDL/CIDL Compiler Component Descriptor Component Package .zip Packaging Tool Default Properties

30 Component Assembly Instance Creation Port Connections Component
Package Component Package Assembly Archive .aar (ZIP) Assembly Tool Component Package Properties DeploymentTool ...

31 Inhalt Motivation Übersicht des CORBA Komponentenmodels (CCM)
Konzepte Abstraktes Model Container Model Implementationsmodel Entwicklung Packaging Model Deployment Model Alternativen im Überblick Zusammenfassung

32 Deployment model (1) Zuordnung – Definierung von „execution sites“
Eine Applikation kann mehrmals instanziiert werden ComponentInstallation AssemblyFactory Assembly Basierend auf einen Assembly-Descriptor und User Input, Deployment Tool installiert und aktiviert Component Homes und Instanzen; es konfiguriert Komponenteneigenschaften und verbindet Komponente zusammen via Interface und Event Ports, so wie es in Assembly-Descriptor definiert ist. KomponentInstallation Singleton, installiert Komponentenimplementierungen AssemblyFactory Singleton, erzeugt Assembly Objekte Assembly Representiert eine Assembly Instantiierung Koordiniert das Erzeugen und die Destruktion von Component Assemblies und Komponenten

33 Deployment model (2) Server Activator Component Server Container
Instanziierung von Komponenten Konfiguration von Komponenten ServerActivator Singleton bei host, erzeugt ComponentServer Objekte ComponentServer Erzeugt Container Objekte Container Installiert CCMHome Objekte

34 The Component Deployment Process
AssemblyFactory «instantiates» Assembly ServerActivator «instantiates» Deployment Tool ComponentServer «instantiates» Container «instantiates» CCMHome «instantiates» ComponentInstallation CCMObject

35 Inhalt Motivation Übersicht des CORBA Komponentenmodels (CCM)
Konzepte Abstraktes Model Container Model Implementationsmodel Entwicklung Packaging Model Deployment Model Alternativen im Überblick Zusammenfassung

36 CCM vs. EJB, COM und .NET Ähnlichkeiten mit EJB CORBA Komponenten
werden von homes erzeugt und verwaltet laufen im Container werden von Komponentenserver-Applikation gehostet Ähnlichkeiten mit COM Hat mehrere input und output Schnittstellen Sowohl synchrone Operationen als auch asynchrone Nachrichten Navigations- und Introspektionsfähigkeiten Ähnlichkeiten mit .NET Framework Können in verschiedenen Programmiersprachen geschrieben werden Können zum Zweck der Verteilung verpackt werden

37 Aber mit CCM… Die CCM Applikationen sind „wirklich“ verteilt
Sie können auf mehreren verteilten Knoten gleichzeitig eingesetzt und ausgeführt werden. Eine CORBA Komponente kann von mehreren Klassen implementiert werden

38 Vergleich von CCM mit EJB
Aspect EJB CCM Availability Many products OpenCCM, MICO Connections Java Bean to implement Four kinds of ports Pragramming Java Any language Packaging JAR + XML ZIP + OSD Deployment Single server Multiple servers Runtime Container generation Container configuration Use Today Tomorrow Ausgeblendet!!! Wird später bei EJB Vortrag gebraucht.

39 Zusammenfassung component (definiert via IDL) home, HomeFinder
Attribute, Ports, Navigation, Introspektion home, HomeFinder Container Typen: Session, Entity Komponententypen entity, process, session, service, EJBsession, EJBentity, Empty Implementierung (CIF,CIDL) Verpackung (XML-Descriptors) Verteilung

40 Open Source Implementierungen
OpenCCM from LIFL & ObjectWeb Java on ORBacus 4.1 & OpenORB 1.2.1 MicoCCM from FPX & Alcatel C++ on MICO FreeCCM from Humboldt University C++ on ORBacus 4.1

41 Fragen?

42 Vielen Dank!