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

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

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)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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.

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.

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

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.

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

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

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)

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

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

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

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

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

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

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

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

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

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

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.

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

Open Source Implementierungen OpenCCM from LIFL & ObjectWeb Java on ORBacus 4.1 & OpenORB 1.2.1 http://www.objectweb.org/OpenCCM/ MicoCCM from FPX & Alcatel C++ on MICO http://www.fpx.de/MicoCCM/ FreeCCM from Humboldt University C++ on ORBacus 4.1 http://sourceforge.net/projects/cif

Fragen?

Vielen Dank!