Lehrstuhl für Software-Technologie Komponentenmodelle Volker Gruhn Lehrstuhl für Software-Technologie Universität Dortmund volker.gruhn@uni-dortmund.de http://ls10-www.informatik.uni-dortmund.de +49 231 755 2782

By 1999, component software will be the dominant method of new application development Gartner Group 1997

Einordnung komponentenbasierte Entwicklung Objektorientierte Modellierung führt zu einer großen Menge an Klassen, Objekten, Beziehungen. Auf dieser kleinteiligen Ebene ist es schwierig, sinnvolle Wiederverwendungs-Einheiten zu finden. Deshalb gibt es die Bestrebung, eng zusammengehörende Klassen zu größeren Wiederverwendungseinheiten zusammenzufassen.

Gliederung Einleitung Teil I - Motivation, Grundlagen, Beispielanwendung Motivation für komponentenbasierte Softwareentwicklung Migration zu komponentenbasierten Anwendungsarchitekturen Vorstellung der Beispielanwendung

Teil II - Die Umsetzung der Szenarien DCOM-Szenario Gliederung Teil II - Die Umsetzung der Szenarien DCOM-Szenario JavaBeans/CORBA-Szenario JavaBeans/Enterprise-JavaBeans-Szenario Teil III Vergleich und Ergebnisse Zusammenfassender Vergleich

Einleitung Komponentenbasierte Anwendungsentwicklung (cbd) Vorteile gegenüber traditioneller prozeduraler, aber auch objektorientierter Softwareentwicklung: Anwendungen sind leicht aus vorgefertigten Bausteinen (Komponenten) zusammenzusetzen. Komponenten werden von spezialisierten Komponentenentwicklern zur Verfügung gestellt. Wiederverwendung der Komponenten durch strikte Kapselung

Etablierung von Standards - sogenannter Komponentenmodelle: Einleitung Etablierung von Standards - sogenannter Komponentenmodelle: DCOM JavaBeans Enterprise JavaBeans Vor- und Nachteile der Komponentenmodelle werden aufgeführt durch theoretische Erörterungen durch Beispielanwendungen

Begriffsdefinitionen Definition für den Komponentenbegriff: »Eine Komponente ist ein Stück Software in binärer Form, das eine kohärente Funktionalität bietet. Die strikte Kapselung der Implementierung und die damit verbundene ›Black Box‹-Wiederverwendung führt zu einer gewissen Eigenständigkeit der Komponenten und ermöglicht somit eine lose Kopplung zwischen der Komponente und ihrer Umgebung. Die angebotene Funktionalität wird mittels einer oder mehrerer Schnittstellen beschrieben. ...

Begriffsdefinitionen ... Es wird zwischen dem Begriff Komponente, der die statische Beschreibung einer Komponente (vergleichbar mit der Klasse im objektorientierten Paradigma) bezeichnet, und dem Begriff Komponenteninstanz (vergleichbar mit dem Objekt im objektorientierten Paradigma) unterschieden. Eine Komponenteninstanz kann über eine persistente (vgl. Persistenz) Identität verfügen, so dass sie auch über die Lebensdauer des sie erzeugenden Prozesses hinaus eindeutig referenziert werden kann.

Definition Komponentenmodell: Begriffsdefinitionen Eine Komponente ist immer für die Verwendung innerhalb genau eines konkreten Komponentenmodells ausgelegt. Definition Komponentenmodell: »Ein Komponentenmodell legt einen Rahmen für die Entwicklung und Ausführung von Komponenten fest, der strukturelle Anforderungen hinsichtlich Verknüpfungs- bzw. Kompositions- möglichkeiten (Komposition) sowie verhaltensorientierte Anforderungen hinsichtlich Kollaborationsmöglichkeiten an die Komponenten stellt. Darüber hinaus wird durch ein Komponenten- modell eine Infrastruktur angeboten, die häufig benötigte Mechanismen wie Verteilung, Persistenz, Nachrichtenaustausch, Sicherheit und Versionierung implementieren kann.«

Begriffsdefinitionen Jede Komponente unterstützt eine oder mehrere Schnittstellen, über deren Operationen man auf die Dienste einer Komponenteninstanz zugreifen kann. Eine Operation umfasst lediglich die Signatur, eine Methode implementiert eine Operation mit einem passenden Funktionsrumpf.

Metamodell der zentralen Begriffe: Begriffsdefinitionen Metamodell der zentralen Begriffe:

TEIL 1 Motivation, Grundlagen, Beispielanwendung 1 Motivation für komponentenbasierte Softwareentwicklung 2 Migration zu komponentenbasierten Anwendungsarchitekturen 3 Beispielanwendung

1 Motivation für komponentenbasierte Softwareentwicklung 1.1 Flexible Verteilung und Anwendungsnähe 1.2 Die Legostein-Metapher 1.3 Migration zu komponentenbasierten Softwaresystemen 1.4 Grundbegriffe der komponentenbasierten Softwareentwicklung

1 Motivation für komponentenbasierte Softwareentwicklung Wiederverwendung / Ende der dauerhaften Neuentwicklungen Ansatz zu Überwindung von Anwendungsstau Prinzip der Abstraktion Konzentration auf Geschäftslogik Nicht auf Persistenz, Transaktionen, etc. Notwendige Voraussetzungen Komponentenentwickler und Anwendungsentwickler Unterstützende Systeme, z.B. Middleware, Applikationsserver

Grundlage ist das Komponentenmodell Motivation Grundlage ist das Komponentenmodell eine Vereinbarung, wie Komponenten aussehen sollen Angebot von Querschnittsservices Namenskonventionen Entscheidung, welches Komponentenmodell verwendet wird prägt den gesamten Entwicklungsprozess Kompatiblität mit den Entwicklungswerkzeugen Eignung Softwareintegrationsaufgaben Auswahl des konkreten unterstützenden Middleware-Systems Auswahl eines Frameworks

Zielsetzung dieser Vorlesung Motivation Zielsetzung dieser Vorlesung Überblick über gängige Komponentenmodelle Kenntnis der Kriterien zum Vergleich von Komponentenmodellen Stärken und Schwächen der einzelnen Komponentenmodelle, sodass situationsspezifisch ein passendes Komponentenmodell gewählt werden kann

1.1 Flexible Verteilung und Anwendungsnähe Motivation 1.1 Flexible Verteilung und Anwendungsnähe Technische und betriebswirtschaftliche Argumente, die auf zwei Tendenzen zurückzuführen sind: Flexible Verteilung In den letzten Jahrzehnten zunehmende Verteilung von Softwaresystemen aus monolithischen und intern nicht strukturierten Systemen wurden two-tier und multi-tier Systeme weitere Aufweichung in Systeme, die aus einer Reihe von Bausteinen bestehen können flexibel verteilt werden sind über vordefinierte Arten von Beziehungen zusammengesetzt

Motivation

Anwendungsnahe Bausteine Motivation Anwendungsnahe Bausteine Ziel: Bereitstellung von Abstraktionen, die für den Anwendungsentwickler relevant sind Grundlage für zahlreiche Innovationen in der Softwareentwicklung

Motivation

Zwei Grundprobleme der Softwareentwicklung Motivation Zwei Grundprobleme der Softwareentwicklung Vom knappen Fachwissen zur Software Konflikt: Fachwissen in den Köpfen einiger weniger Fachleute im Gegensatz zu Anwendern, die die eigentliche Verarbeitungslogik nicht kennen Das knappe Wissen über Funktionalität muss schnell in neue Anwendungen umgesetzt werden und optimalerweise mehrfach verwendet werden können

Zwei Grundprobleme der Softwareentwicklung Motivation Zwei Grundprobleme der Softwareentwicklung Technik dominiert Fachlichkeit Konflikt: Funktionale Anforderungen und ihre Umsetzung gehen unter in technischen Details Problem: Anwendungsentwickler müssen sich um technische verursachte Probleme kümmern (passende Transaktionsmodelle, geeignete Datenstrukturen, Algorithmen, Softwarestrukturen)

Motivation Betriebswirtschaftliche Argumente für die komponentenbasierte Entwicklung Plattformübergreifende Nutzung Vermeidung von Mehrfachentwicklung oder systemtechnisch bedingter Portierungsaufwände Möglichkeit des Zukaufs von Komponenten und Integration in existierende Softwarelandschaften Einfache Integration miteinander

Verkauf von eigenentwickelten Komponenten Motivation Verkauf von eigenentwickelten Komponenten Fokussierung der Entwicklungsaufwände Teile von Softwaresystemen können dazugekauft werden (Finanzbuchhaltungssysteme, Personalbuchhaltungssysteme) Entwicklungskonzentration auf Bestandteile, die dem Wettbewerb zuträglich sind Unterstützung flexibel anpassbarer Geschäftsprozesse Integration von Services in Prozesse

Verwirklichung dieser Ziele Motivation Verwirklichung dieser Ziele Anstrebung einer Reihe untergeordneter technischer Ziele: Strukturvorteile objektorientierter Softwaresysteme auf der Ebene des „Programmieren im Großen“

Angestrebte Komponenteneigenschaften Motivation Angestrebte Komponenteneigenschaften Wohldefinierter Zweck Kontextunabhängigkeit Portabilität und Programmiersprachenunabhängigkeit Ortstransparenz Trennung von Schnittstelle und Implementierung Selbstbeschreibungsfähigkeit

Angestrebte Komponenteneigenschaften Motivation Angestrebte Komponenteneigenschaften Sofortige Einsatzbereitschaft (plug&play) Integrations- und Kompositionsfähigkeit Wiederverwendbarkeit Konfigurierbarkeit, Anpassbarkeit Bewährtheit Binärcode-Verfügbarkeit

Die Legostein-Metapher Motivation Die Legostein-Metapher Idee der komponentenbasierten SE: Komplette Anwendungen bauen unter Verwendung von Bausteinen, die Teile der Anwendungslogik sind. Diese Bausteine sind wie Legosteine - stellt sich die Frage nach den passenden Bausteinen ... Je spezialisierter Bausteine sind, desto geringer die Chance für Wiederverwendung Können sie wiederverwendet werden, ist das von großem Nutzen

Wiederverwendung - Häufigkeit und Nutzen: Motivation Wiederverwendung - Häufigkeit und Nutzen:

Wiederverwendung entsteht nicht von alleine! Motivation Wiederverwendung entsteht nicht von alleine! Wiederverwendung entsteht nicht adhoc! Wiederverwendung erfordert eine Investitionsentscheidung! Wiederverwendung erfordert ein Budget!

Wiederverwendung erfordert eine geeignete Infrastruktur, die folgendes leisten muss: Mechanismen für die Zur-Verfügung-Stellung wiederverwendbarer Komponenten Klassifikation wiederverwendbarer Komponenten gemäß mehrerer Kriterien und Suche nach Komponenten gemäß dieser Kriterien Aufbauen der Klassifikationssysteme Klassifizieren und Wiederauffinden der Komponenten und Teilsysteme Export von Komponenten in andere Verwaltungssysteme und Import aus anderen Systemen in das eigene Archiv Berichte über die Klassifikationssysteme und über die Komponenten mit ihren Klassifikationen Überprüfung von Dokumentationsstandards Protokollierung der tatsächlichen Wiederverwendung

Reporting zum Zwecke der Identifikation von Komponenten, die aus der Wiederverwendungsinfrastruktur entfernt werden können Integration mit dem eigentlichen Software-Prozeß! Eine weitere unterstützende Maßnahme ist die Benennung des obersten Wiederverwenders. Der Wiederverwender erörtert die Chancen der Entwicklung wiederverwendbarer Komponenten und ihrer Wiederverwendung. Er sorgt dafür, daß die geeignete Infrastruktur bereitsteht und verbessert diese kontinuierlich. Er sorgt für einen geeigneten Füllungsgrad (ggf. durch den Zukauf von Komponenten). Er mißt er den Grad der Wiederverwendung.

Eine wichtige organisatorische Maßnahmen ist die Etablierung eines Incentive-Systems: Belohnung für die Bereitstellung einer wiederverwendbaren Komponente, die auch tatsächlich wiederverwendet wird. Belohnung für die Wiederverwendung einer Komponente. Belohnung für die Verbesserung einer wiederverwendbaren Komponente. Noch mehr als an andere Komponenten sind an wiederverwendbare Komponenten die folgenden Anforderungen zu stellen: Allgemeinheit Qualität Dokumentation Zuverlässigkeit / Robustheit / Korrektheit

Auch hier zeigt sich: die Entwicklung wiederverwendbarer Komponenten ist eine Investition in die Zukunft. Sie amortisert sich nur bei aufeinander folgenden, klar definierten Software-Prozessen. Das heißt: Wiederverwendung ist erst ab einer gewissen Reife des Software-Prozesses möglich (frühestens ab Stufe 2 CMM).

Die „Formel 3“ [Big94] Software muß dreimal entwickelt werden, bevor sie wirklich wiederverwendbar entwickelt werden kann. Bevor die „Früchte der Wiederverwendung geerntet“ werden können, muß Software dreimal wiederverwendet werden. Folglich: der Einstieg in die Wiederverwendung erfordert eine bewußte und investive Management-Entscheidung, oder noch mal: Wiederverwendung fällt nicht vom Himmel!

Kosten/Nutzen-Relation der Wiederverwendung [Bal96]

Potentielle Hindernisse bei der Einführung der Wiederverwendung [Kau97] ökonomisch fehlendes Commitment unklare Geschäftsstrategie Investitionshöhe fehlende Nutzungs und Verwertungsrechte organisatorisch im Prozeß nicht vorgesehen Verantwortung nicht zugewiesen fehlender Katalysator fehlende Infrastruktur soziologisch Not-invented-here-Syndrom Widerstand gegen Veränderungen Existenzängste („Re-Use ist ein Jobkiller“) Selbstverständnis des Entwicklers/ geändertes Rollenbild technisch fehlende Erfahrung mit praktischen Anwendungen mangelndes Know-How Schwächen im Software-Engineering- Prozeß fehlende Tools

Der Zweck der Wiederverwendung kann die Wiederverwendung innerhalb eines Produktes sein die Wiederverwendung innerhalb einer Produktfamilie (also innerhalb einer Menge von Varianten und Versionen des geleichen Produktes) sein die Wiederverwendung innerhalb der Software-Prozesse eines Unternehmens sein die Wiederverwendung über Unternehmensgrenzen hinweg sein

Wiederverwendung nach Anwendungsbereich Unterscheidung zwischen vertikaler Wiederverwendung (gleicher Anwendungsbereich) und horizontaler Wiederverwendung (anwendunsgbereichunabhängige Basisbausteine). geplanter (als Bestandteil des Software-Prozesses) und ungeplanter Erstellung wiederverwendbarer Komponenten Ungeplante Wiederverwendung erfordert den Einsatz von Re-Techniken) (vgl. Rolle Wartungsexperte)

Arten der Wiederverwendung Unterscheidung zwischen white-box-Wiederverwendung (wiederverwendbare Komponenten werden getestet, bevor sie wiederverwendet werden) und bei geringer Reife der Wiederverwendungsinfrastruktur black-box-Wiederverwendung (wiederverwendbare Komponenten werden unmittelbar übernommen). unbedingt anzustreben, weil nur dann das Aufwandsargument vollständig greift. erst ab einer konsolidierten Wiederverwendungskultur möglich.

Evolutionäre Verbesserung der Wiederverwendung Stufe 1: Ad-Hoc-Wiederverwendung: der eine tut´s, der andere nicht. Stufe 2: Wiederverwendung verfügbarer Software: aus dem existierenden Fundus von Software wird systematisch ausgesucht. Stufe 3: Entwicklung für Wiederverwendung: die Entwicklung versucht, wiederverwendbare Komponenten zu erstellen. Stufe 4: Verwendung von Domänenmodellen, statistische Steuerung des Prozesses: die Abstraktion der wiederverwendbaren Komponenen erreicht das Niveau der Anwendung, der Grad der Wiederverwendung wird gemessen Stufe 5: Organisationsweite Ausrichtung auf Wiederverwendung: Wiederverwendung prägt Kalkulation, Methoden, Verfahren, Prozesse

Komponentenbasierte Softwaresysteme mit verschiedenen Komponentenarten Motivation Komponentenbasierte Softwaresysteme mit verschiedenen Komponentenarten eigenentwickelte Komponente zugekaufte Wrapped

Migration zu komponentenbasierten Softwaresystemen Motivation Migration zu komponentenbasierten Softwaresystemen Neue Software und neue Vorgehensmodelle können nur schrittweise eingeführt werden Geeignet hierfür sind evolutionäre und architekturzentrierte Migrationsstrategien Existierende Software wird Stück für Stück durch Komponenten ersetzt Neuentwicklungen: wiederverwendbare Komponenten

Grundbegriffe der komponentenbasierten Softwareentwicklung Motivation Grundbegriffe der komponentenbasierten Softwareentwicklung Definitionen: »Components are software units that are context independent both in the conceptual and the technical domain.« [12] »A component denotes a self-contained entity (black-box) that exports functionality to its environment and may also import functionality from its environment using well-defined and open interfaces. In this context, an interface defines the syntax and semantics of the functionality it comprises (i.e., it defines a contract between the environment and the component). Components may support their integration into the surrounding environment by providing mechanics such as introspection or configuration functionality.« [59]

Motivation »Eine Softwarekomponente ist ein Baustein mit vertraglich spezifizierten Schnittstellen und nur ausdrücklichen Kontextabhängigkeiten. Eine Softwarekomponente kann unabhängig verwendet werden und leicht mit anderen Komponenten integriert werden.« [61] »Eine Komponente ist ein Stück Software, das klein genug ist, um es in einem Stück zu erzeugen und pflegen zu können, groß genug ist, um eine sinnvolle Funktionalität zu bieten und eine individuelle Unterstützung zu rechtfertigen sowie mit standardisierten Schnittstellen ausgestattet ist, um mit anderen Komponenten zusammenzuarbeiten.« [27]

Motivation Eine Komponente realisiert bestimmte Funktionalitäten, die sie nach außen in Form von Services bekannt macht: Services können von anderen Komponenten benutzt werden mehrere logisch zusammengehörende Services können in Form einer Schnittstelle gruppiert werden ein Service kann auch in mehreren Schnittstellen vorkommen

Motivation Komponenten werden zunächst auf der fachlichen Ebene (Geschäftsobjekte - business objects) beschrieben: Fachliche Beschreibungen identifizieren logisch eng zusammenhängende Anwendungsteile Produktbaustein Trarif Vertrag Lokation

Erst mal zu einem groben Objektmodell Motivation Erst mal zu einem groben Objektmodell

Vergröberung eines Objektmodells zu fachlichen Komponenten Motivation Vergröberung eines Objektmodells zu fachlichen Komponenten Produkt/Tarif Objekt Lokation Vertrag Schaden / Leistung Partner Versicherungs- Vertrag Vertrieb Buchhaltung

Von den fachlichen Komponenten zu technischen Komponenten Motivation Von den fachlichen Komponenten zu technischen Komponenten

Technische Komponenten (Softwarekomponenten) Motivation Technische Komponenten (Softwarekomponenten) sind Bestandteile der lauffähigen Software Realisierung gemäß eines Komponentenmodells Zusammenspiel wird in der softwaretechnischen Architektur festgelegt müssen mit Infrastruktursystemen (Middleware, Datenbank, Betriebssystem) interagieren Zusammenspiel wird in der systemstechnischen Architektur festgelegt

Applikationsserver mit Geschäftsobjekten Motivation Unterscheidung von Client-Komponenten / Server-Komponenten Client-Komponenten realisieren Benutzungsoberflächen Server-Komponenten realisieren die Geschäftsobjekte Direktgeschäft Außendienst Innendienst Web Browser und Applets Java Anwendung Web Server Applikationsserver mit Geschäftsobjekten (GO) GO

Trend bei Client-Komponenten Motivation Trend bei Client-Komponenten Fat clients (zweite Hälfte der 80er) Thin clients (90er) Ultra thin clients (zweite Hälfte der 90er) Browser-basierte Clients (aktuell) Und entsprechende Anforderungen an Client-Komponenten und Client- Komponentenmodelle!

Geschäftskomponenten werden bereits im Systementwurf identifiziert Motivation Geschäftskomponenten werden bereits im Systementwurf identifiziert dienen als Bausteine der komponentenbasierten Architektur Komponenten auf Geschäftsobjektebene kapseln ganze Geschäftsobjekte und realisieren die Geschäftslogik implementieren ganze Transaktionen des unterstützten Geschäftes oder große Teile daraus sind anwendungsabhängig sind einzeln ablauffähig

Motivation Das Zusammenspiel von Komponenten, Komponentenmodellen, Frameworks und Middleware-Systemen Komponentenmodell konkrete Komponenten Framework Entwicklungswerkzeuge komponentenbasierte Anwendungen Middleware müssen zueinander passen werden benutzt für sind Grundlagen Grundlage betrieben in Software architektur

Funktionalitäten von Middleware-Systemen Motivation Funktionalitäten von Middleware-Systemen Datentransfer Kommandoübermittlung (synchroner und asynchroner Aufruf) Empfang von Anfragen Vermeidung von Verklemmungen Etablierung und Beendigung von Kommunikationskanälen

Infrastrukturaufgaben: Motivation Infrastrukturaufgaben: Nachrichtenempfang und Aktivierung der zugehörenden Objekt-Methoden Verwalten der Objekt-Lebenszyklen (erzeugen, aktivieren, ändern, löschen, deaktivieren) Namensdienst zur Identifikation der Objekte Kontrolle der Zugriffe auf die Objekte Persistenzmanagement (automatische Synchronisation mit Persistenzspeicher) Objekt-Relationales Mapping (Abbildung der Objekte auf relationale Strukturen) Transaktionsmanagement (Sicherstellen der ACID-Eigenschaften von Operationen auf Objekten) inklusive verteilte Transaktionen

Kapitel 2: Migration zu komponentenbasierten Anwendungsarchitekturen Um komponentenbasierte Entwicklung erfolgreich einzuführen, muss eine Zielsoftwarelandschaft identifiziert werden, müssen die benötigten Werkzeuge ausgewählt und ausprobiert werden, müssen Mitarbeiter geschult werden, müssen die unterschiedlichen Arten von Architekturen identifiziert und definiert werden.

Migration 6 Auswahl von Produkten 7 Pilotprojekte 5 Definition/Anpassung des Entwicklungsprozesses 1 Ist -Analyse 2 Definition fachliche Architektur 3 Definition softwaretechnische Architektur 8 Einführung 4 Definition systemtechnische

Konkret muss die Ist-Analyse folgende Ergebnisse erarbeiten: Migration 1 Ist-Analyse Konkret muss die Ist-Analyse folgende Ergebnisse erarbeiten: Identifikation und Beschreibung der existierenden Anwendungssysteme Aspekte zu diesen Anwendungssystemen Geschäftsvorfälle wesentliche Objekttypen (Geschäftsobjekte) Programmiersprachen, etc. Beziehungen zwischen bestehenden Systemen Benutzt-Beziehungen Qualifizierung der gefundenen Beziehungen Identifikation der systemtechnischen Infrastruktur Analyse existierender Architekturvorgaben

Migration Aus den genannten Ergebnissen heraus lassen sich Aussagen darüber treffen, welche Schnittstellen zur Einbindung von Altanwendungen notwendig sind; welche Anwendungen gut sind, welche besser nicht weiter eingesetzt werden; welche Anwendungen in mehreren, verschiedenen Geschäftsprozessen genutzt werden und damit automatisch Kandidaten für zukünftige Komponenten sind;

Migration welche Anwendungen von mehreren Anwendungen aufgerufen werden und dadurch ebenfalls zu Kandidaten für Komponenten werden; welche Abhängigkeiten zwischen den Altanwendungen bestehen, um damit Risiken und Seiteneffekte einer komponentenbasierten Neuentwicklungen zu verdeutlichen; wann welche bestehenden Softwaresysteme abgelöst werden können und in welchem Zeit- und Kostenintervall die Ablösung durch ein neues System am wirtschaftlichsten ist.

Ist-Analyse mit Hilfe eines strukturierten Fragebogens Migration Ist-Analyse mit Hilfe eines strukturierten Fragebogens Die Struktur wird genutzt für eine Auswertungsdatenbank Hauptaugenmerk liegt auf fachlichem Teil administrative Daten (verantwortliche Personen) systemtechnische Daten (Rechner, Betriebssysteme, Netzwerke...) und softwaretechnischem Teil (Programmiersprache, Entwicklungswerkzeuge)

Migration Weitere Möglichkeit der Auswertung: grafische Darstellung der Aufrufbeziehungen Name der Anwendungssysteme und Zuordnung zu Anwendungsbereichen (nicht unbedingt Organisationseinheiten); Direkte Aufrufbeziehungen (Call-Schnittstelle) zwischen Anwendungen und die Aufrufrichtung; Aufrufbeziehungen, die keiner konkreten Anwendung zugeordnet werden können, sind den Anwendungsbereichen zugeordnet; Qualifizierung des Aufrufs in Bezug auf die Datenmanipulation (create, read, update) über diese Schnittstelle bzw. hinsichtlich der Nutzung eines Unterprogramms; Reine Datenflussbeziehungen unter Angabe des verwendeten Mediums (Datei, Datenbank, etc.) mit der Flussrichtung.

2 Definition der fachlichen Architektur Migration 2 Definition der fachlichen Architektur Notwendig: fachliche Basis - Beschreibung der Geschäftsobjekte mit Hilfe eines UML-Klassendiagramms Das Objektmodell dient zur Abgrenzung des Wirkungsbereichs der einzelnen Anwendungen Identifikation von Komponenten Ergebnis: Spezifikation von Komponenten und Abhängigkeiten

Beispiel für eine ACDL-Spezifikation einer Komponente Migration Beispiel für eine ACDL-Spezifikation einer Komponente Beispiel für eine ACDL-Spezifikation einer Komponente Komponente Ort Identifikatorfachlich K-02 Verantwortlicher Dirk Platz, adesso Komponenten-Objektmodell Komponenten der fachlichen Klassen Version 1.7 Komponente Komponenten Rolle Server Verwendete Komponenten- Aufrufende Komponenten (fachlichK-03, Objekt), (fachlichK-04, SchadenLeistung), Komponentenspezifikation (fachlich-08, Vertrag) Service LokationsVerwaltung Service-Identifikator fachlichS-02 Kurzbeschreibung Beschreibt alle für eine Versicherung Service sinnvollen Orte und Streckenangaben. Langbeschreibung Es wird ein Ort, eine Strecke oder eine Route und deren Beziehungen zueinander beschrieben. Service-Funktion Ein Ort kann eine postalische Adresse oder eine . . . . . . . Service-Funktion PostalischeAdresseErzeugen Kurzbeschreibung Eine postalische Adresse anlegen. Langbeschreibung Die Stammdaten einer postalischen Adresse werden angelegt, indem über die . . . . . . . Komponentenrealisierung Service-Funktion PostalischeAdresseLiefern Kurzbeschreibung Eine postalisch ....... Interface Methode

3 Definition der softwaretechnischen Architektur Migration 3 Definition der softwaretechnischen Architektur Die softwaretechnische Architektur legt die Komponenten der Softwarelandschaft fest. Komponentenschnitt: welche Komponenten realisieren den Funktionsumfang der einzelnen Anwendungssysteme und welchen Datenhaushalt umfasst eine Komponente Für jede Komponente muss festgelegt werden, welche Dienste sie anderen Komponenten außerhalb der Architektur anbieten

Definition der softwaretechnischen Architektur Migration Definition der softwaretechnischen Architektur In Ergänzung der fachlichen Architektur werden softwaretechnische Prinzipien und nicht-funktionale Anforderungen berücksichtigt! Prinzipien: Typische nicht-funktionale Anf. Striktheit und Formalität Performanz Strukturierung Integrierbarkeit Modularität Skalierbarkeit Abstraktion Robustheit Änderbarkeit Allgemeinheit Inkrementalität

Definition der softwaretechnischen Architektur Migration Definition der softwaretechnischen Architektur Konkrete Ergänzungen der softwaretechnischen Architektur, um Anbindung an Oberflächen Anbindung an Persistenzschicht Wrapper / Integrationskomponenten Normalierung / Denormalisierung Entwurfsmuster

4 Definition der systemtechnischen Architektur Migration 4 Definition der systemtechnischen Architektur legt die Ablaufumgebung für jede Komponente fest neue Komponenten sind oft nur dann ablauffähig, wenn der Zugriff auf existierende Funktionalitäten gewährleistet ist. Typische Bestandteile der systemtechnsichen Architektur: Rechner, Netzwerk, Betriebssysteme, DBMSe, Kommunikationsprotokolle, Middleware Zusammenspiel der systemtechnischen Aspekte muss im Rahmen der Architekturdefinition überprüft und nachvollziehbar dokumentiert werden!

5 Anpassung des Entwicklungsprozesses Migration 5 Anpassung des Entwicklungsprozesses Entwicklungsprozesse müssen auf die Erfordernisse der komponentenbasierten Entwicklung angepasst werden: Ein Gesamtsystem wird als eine Menge von Komponenten angesehen, die identifiziert, spezifiziert und meistens im Vergleich zur bisherigen Entwicklungspraxis weitgehend unabhängig entwickelt werden. Diese Menge setzt sich zusammen aus Geschäfts- und Infrastrukturkomponenten mit der eigentlichen Geschäftslogik, die durch die Architektur vorgesehen sind, und Client-Komponenten, die die Benutzerschnittstelle mit der Dialogsteuerung enthalten. Die Architekturdefinitionen müssen in einzelnen, klar definierten Entwicklungsaktivitäten verbindlich berücksichtigt werden.

Übersicht Systementwicklung Migration Übersicht Systementwicklung Systemanalyse Systementwurf Systemintegration Überleitung in die Nutzung SE 4-7: Client- Komponentenentwicklung Zusammenbau der Komponenten zum Gesamtsystem Server- Unabhängige Entwicklung von Server-Komponenten Beschreibung des Systems aus Anwendersicht Zerlegung des Systems in Komponenten, Spezifikation der Leistungen der Komponenten von Client- Komponenten

Aufgaben der Entwicklungsphasen: Migration Aufgaben der Entwicklungsphasen: Systemanalyse: Das Ziel dieser Aktivität ist es, die Anforderungen an das Softwaresystem aufzunehmen und unter anderem mittels UML zu dokumentieren. Grundlage ist die als Ziel definierte Anwendungsarchitektur, denn es muss festgestellt werden, welche Bestandteile der angestrebten Anwendungsarchitektur im Rahmen des konkreten Projektes abgedeckt werden können.

Systementwurf: Migration Das Ziel dieser Aktivität ist es, das in den Anwenderforderungen beschriebene System in Server-Komponenten (für die Geschäftslogik) und Client-Komponenten (für die Benutzerschnittstellen und die Dialogsteuerung) zu zerlegen. Als Grundlage und Vorgabe dienen dabei das Objektmodell, der Komponentenschnitt und die Komponentenbeschreibungen der softwaretechnischen Architektur. Weiterhin werden die Anforderungen an das Gesamtsystem den einzelnen Komponenten zugewiesen. Es wird beschreiben, wie die einzelnen Komponenten im Verlauf von Geschäftsvorfällen miteinander interagieren. Außerdem werden die einzelnen Dienste, die die Komponenten anbieten spezifiziert.

Komponentenentwicklung: Migration Komponentenentwicklung: Das Ziel dieser Aktivität ist es, die einzelnen durch den Systementwurf identifizierten und spezifizierten Komponenten weitgehend unabhängig voneinander zu entwickeln. Die Entwicklung einer Komponente hängt ganz wesentlich davon ab, ob es sich um eine Client-Komponente mit um eine Server-Komponente handelt. Bei der Entwicklung selbst ist das gewählte Komponentenmodell von entscheidender Bedeutung. Das Ergebnis der Komponentenentwicklung sind vollständig entwickelte Server- und Client-Komponenten des Systems.

Überleitung in die Nutzung: Migration Systemintegration: Das Ziel dieser Aktivität ist es, die entwickelten Client- und Server- Komponenten zu einem Gesamtsystem zusammenzufügen. Überleitung in die Nutzung: Das Ziel dieser Aktivität ist es, das fertig entwickelte und integrierte System zum Einsatz in die Produktion zu bringen. Dazu ist es in der Regel erforderlich, die Komponenten an den jeweiligen Standorten zu installieren. Außerdem müssen die Altdatenbestände migriert werden. Danach kann abschließend der tatsächliche produktive Betrieb des Systems aufgenommen werden.

Definition der organisatorischen Konsequenzen Migration Definition der organisatorischen Konsequenzen Neu zu entwickelnde Komponenten werden mit bereits existierenden kombiniert -> Entwicklung nicht allein für ein einziges Projekt -> Gewährleistung, dass die Entwicklung nicht dem Zeit- und Kostendruck eines einziges Projektes unterliegt Problemlösung: Entwicklung der projektspezifischen Komponenten von der Entwicklung der projektübergreifenden Komponenten organisatorisch trennen

6 Auswahl von Werkzeugen Grundlage: Migration 6 Auswahl von Werkzeugen Grundlage: Kriterienliste Gewichtung Explizite Identifikation der KO-Kriterien Zeitliche Rahmen Ausführliche Untersuchung einer Shortlist von Kandidaten Zielsetzung: Transparente und nachvollziehbare Entscheidungen unter sich schnell ändernden Rahmenbedingungen Und immer dran denken: Technologiezentriertheit ist ein grundlegendes Risiko!

Folge: Entscheidungsrisiken werden so minimiert Migration 7 Pilotprojekte Alle wesentlichen Entscheidungen sollten in Pilotprojekten überprüft werden Ziel: Vor einer breiten Einführung den Architekturrahmen weiterentwickeln und das Vorgehensmodell anpassen Folge: Entscheidungsrisiken werden so minimiert

Wichtige Eigenschaften von Pilotprojekten: Ernsthaftigkeit: Migration Wichtige Eigenschaften von Pilotprojekten: Ernsthaftigkeit: Kandidaten für Pilotprojekte sollten nicht hochkritisch sein, um den Spielraum, der für die Überprüfung und eventuell Anpassung von Auswahl- und Technologieentscheidungen vorhanden sein muss, zu erzielen. Dennoch sollte das Projekt ein Mindestmaß an Geschäftskritikalität besitzen. Die Ergebnisse, die in »Spielprojekten« erzielt werden, finden oft nicht die Akzeptanz, die für eine unternehmensweite Verbreitung notwendig ist. Solche Projekte werden auch häufig vorzeitig gestoppt, ohne dass Aussagen über die Technologieentscheidungen getroffen werden können.

»Coached« Anwendung von Architekturrahmen und Vorgehensmodell: Migration »Coached« Anwendung von Architekturrahmen und Vorgehensmodell: »Coached« bedeutet, dass Pilotprojekte nicht einfach mit den Entscheidungen allein gelassen werden, sondern dass zu jeder Entscheidung ein »Coach« definiert wird, der dem Entwicklungsteam bei der Fragen und Problemen zur Verfügung steht. Das Coaching geht dabei bis hin zur konkreten Anleitung bei der Anwendung der ausgewählten Technologien. Dieser Aspekt ist besonders wichtig, da neue Technologien häufig gerade wegen des Mangels an Support während der Einführungsphase scheitern.

Migration Zielorientierung: Oft werden neue Technologien in Pilotanwendungen überprüft, ohne dass ganz klar ist, welcher Art die Aussagen nun sind, die getroffen werden sollen. Die Ziele, die in den Pilotanwendungen verfolgt werden müssen deshalb klar definiert und eingegrenzt werden. Schließlich ist es sehr einfach, ein Pilotprojekt mit Ansprüchen zu überfrachten. Dagegen ist es oft möglich, die unterschiedlichen Ziele auf mehrere Pilotprojekte zu verteilen.

Migration Beispiele für Ziele, die im Zusammenhang mit der Einführung komponentenbasierter Softwareentwicklung in Pilotprojekten untersucht werden, sind: Überprüfung der nicht-funktionalen Qualitätsziele (Performanz, Robustheit, Wartbarkeit); Überprüfung von Produktivität und Zuverlässigkeit des Softwareprozesses; Überprüfung der Anwendbarkeit des Vorgehensmodells durch Entwickler.

Umsetzen des neuen Prozesses (inklusive der neuen Organisation) Migration 8 Einführung Umsetzen des neuen Prozesses (inklusive der neuen Organisation) Risiko-Management Klare Projektstrukturen (inklusive klarer Eskalationswege) Unterstützung durch das Top-Management

Kapitel 3: Vorstellung der Beispielanwendung Projektplanung: Management Resource Planning Tool (MRPT) soll Transparenz schaffen: Wer arbeitet derzeit in welchem Projekt? Wie ist es um den Projektfortschritt einzelner Projekte bestellt? Wie liegen einzelne Projekte in der Zeit? Wie entwickelt sich die Ressourcen-Auslastung?

Projektübergreifende Ressourcenplanung berücksichtigt: Beispielanwendung Projektübergreifende Ressourcenplanung berücksichtigt: Die Verfügbarkeit der Ressourcen/Mitarbeiter Geplanter Urlaub der Mitarbeiter Geplante Projektunterbrechung Die Fähigkeiten beziehungsweise die Ausbildung der Mitarbeiter (Skills) die „Ortsansässigkeit“ der Mitarbeiter

Use-Case-Diagramm der Beispielanwendung DefineProject Structure AcceptChanges «extend» «extend» ViewToDoList «extend» «extend» ResourcePlanning VetoChanges Manager Developer «extend» EnterAbsenceTime DecideOnPro- jectAcceptance TimeRecording Controlling «extend» TimeAdjustment

DefineProjectStructure: Beispielanwendung DefineProjectStructure: dient der Definition der Projektstruktur. Dazu zählt die hierarchische Vorgangsstruktur mit Vorgängen, Teilvorgängen und Meilensteinen, deren Vorgänger-Nachfolger-Beziehungen sowie etwaige zeitliche Nebenbedingungen. Eine Option ist der Import eines Projektplans aus einem Projektplanungswerkzeug wie z.B. MS-Project

Beispielanwendung ResourcePlanning: Hier kann die manuelle Ressourcenzuordnung vorgenommen werden. Zentrales Werkzeug dabei ist ein Gantt-Diagramm, in das Vorgänge (»Tasks«) aus der Projektstruktur, die als Baum oder Tabelle angezeigt wird, per Drag&Drop eingefügt werden können, um auf diese Weise den Vorgang einer Ressource einem Zeitintervall zuzuordnen. Die nachfolgende Abbildung skizziert dieses Gantt-Diagramm: Die Zeilen sind Ressourcen zugeordnet, die Spalten repräsentieren die Zeitachse. Durch eine geeignete Farbgebung kann die Projektzugehörigkeit der einzelnen Tasks visualisiert werden.

Gantt-Diagramm für projektübergreifende Ressourcenzuordnung Beispielanwendung Gantt-Diagramm für projektübergreifende Ressourcenzuordnung KW 16 KW 17 KW 18 Müller Task1 Task14 Task14 Task15 Task1 Meier Task5.3 Task5.3 Task16 Schmidt Urlaub Task16

Beispielanwendung DecideOnProjectAcceptance: bietet Unterstützung bei der Entscheidung, ob beziehungsweise wann ein neues Projekt angenommen werden kann. Es wäre denkbar, dazu wiederum das Gantt-Diagramm zu verwenden. Controlling: Dieser Anwendungsfall beinhaltet diverse Auswertungen und Statistiken hinsichtlich Projektfortschritt, Ressourcenauslastung und dergleichen. ViewToDoList: Die vom Manager im Gantt-Diagramm durchgeführten Ressourcenzuordnungen bewirken eine Änderung der persönlichen »ToDo«-Liste eines Mitarbeiters (Akteur »Developer«). Diese Liste kann vom Mitarbeiter eingesehen werden und die Änderungen können akzeptiert (Use Case »AcceptChanges«) oder zurückgewiesen (Use Case »VetoChanges«) werden.

VetoChanges: dient der Zurückweisung von geplanten Änderungen. Beispielanwendung TimeRecording: Mitarbeiter verbuchen die von ihnen geleisteten Stunden unter Bezug auf einen Task. Bei Bedarf wird zusätzlich der Use Case »TimeAdjustment« durchgeführt. TimeAdjustment: Wenn sich im Projektverlauf herausstellt, dass man den Soll-Aufwand für einen Task über- oder unterschätzt hat, so kann der geschätzte verbleibende Restaufwand erfasst werden. EnterAbsenceTime: Verwaltung von Abwesenheitszeiten, wie zum Beispiel Urlaub. AcceptChanges: Neue Aufgaben, die einem Mitarbeiter übertragen werden, oder Änderungen an bestehenden Plänen, können akzeptiert oder zurückgewiesen werden. Ersteres erledigt dieser Use Case, Letzteres übernimmt »VetoChanges«. VetoChanges: dient der Zurückweisung von geplanten Änderungen.

Priorisierung und Auswahl der Use Cases Beispielanwendung Priorisierung und Auswahl der Use Cases Dreh- und Angelpunkt der Anwendung ist der Use Case »ResourcePlanning« Um die Anwendung mit Testdaten versorgen zu können, wird der Anwendungsfall »DefineProjectStructure« ebenfalls berücksichtigt. Eine Umsetzung der Use Cases, die den Akteur »Developer« betreffen, hätte eine zusätzliche grafische Benutzeroberfläche erfordert und damit den Implementierungsaufwand unnötig erhöht. Die Anwendungen können auf mehreren Rechnern simultan gestartet und eingesetzt werden.

Analysemodell der Beispielanwendung

Die zentrale Klasse ist der Vorgang (»Task«). Beispielanwendung Die zentrale Klasse ist der Vorgang (»Task«). Sie bildet zusammen mit der Klasse »CompositeTask« das Composite-Pattern [24], so dass beliebig tief geschachtelte Hierarchien von Vorgängen und Untervorgängen ermöglicht werden. Ein Task verwaltet drei Zeitspannen: Die Eigenschaft »durationEstimated« erfasst den geschätzten Aufwand einer Aufgabe, in »durationAccumulated« werden die bereits geleisteten Aufwände kumuliert. Ist abzusehen, dass der verbleibende, geschätzte Restaufwand von der Differenz der beiden vorgenannten Werte abweicht, so kann in »durationRemainingEstimated« der aktualisierte Schätzwert für den Restaufwand vermerkt werden.

Beispielanwendung Die Vorgänger-Nachfolger-Relation zwischen Tasks wird durch die verschiedenen spezifischen Ausprägungen der Klasse »TaskLink« modelliert. Eine Instanz der Klasse »EndBeginTaskLink« fordert beispielsweise, dass die Nachfolger-Aufgabe erst begonnen werden darf, wenn die Vorgänger- Aufgabe abgeschlossen ist. Über das Attribut »interval« kann ein zusätzlicher zeitlicher Abstand zwischen den beiden Aufgaben modelliert werden. »ResourceAssignment« ist das Bindeglied zwischen einem Vorgang und der ihm zugeordneten Ressourcen. Hier wird der Termin und die Dauer einer Ressourcenzuordnung verwaltet; ihr Zustand (vorgeschlagen, akzeptiert, zurückgewiesen) geht aus dem Attribut »state« hervor. Etwaige terminliche Beschränkungen können mittels der Spezialisierungen der Klasse »DateConstraint« eingebracht werden.

KAPITEL 4: DCOM-Szenario 4. 1 COM Übersicht 4. 2 Übergang zu DCOM 4 KAPITEL 4: DCOM-Szenario 4.1 COM Übersicht 4.2 Übergang zu DCOM 4.3 Anwendung auf das Beispiel

KAPITEL 4. 1: COM Übersicht. 4. 1. 1 Historie. 4. 1. 2 Was ist COM. 4 KAPITEL 4.1: COM Übersicht 4.1.1 Historie 4.1.2 Was ist COM 4.1.3 Schnittstellen 4.1.4 Referenzzählung 4.1.5 Erzeugen von Komponenteninstanzen 4.1.6 GUID 4.1.7 IDL 4.1.8 Automation 4.1.9 Komponentenkategorien 4.1.10 Versionierung 4.1.11 Containment und Aggregation 4.1.12 Komponenten-Server 4.1.13 Nebenläufigkeit 4.1.14 Persistenz 4.1.15 Monikers 4.1.16 Verbindungspunkte 4.1.17 ATL

COM stellt einen gewachsenen Standard dar. Die Umsetzung der Szenarien 4.1. COM Übersicht COM stellt einen gewachsenen Standard dar. Neben funktionalen Erweiterungen und Überarbeitungen gab es in der Vergangenheit verwirrende Namensänderungen. Haupteinfluss hat das Paradigma des dokumentenzentrierten Arbeitens. Verbunddokumente gestatten dem Anwender, verschiedene Dokumentbestandteile unterschiedlicher Herkunft in einem Gesamtdokument zu vereinen. Die Bearbeitung findet in dem Gesamtdokument statt. (Beispiel: Excel-Spreadsheet eingebettet in ein Word-Dokument) Technologie nannte Microsoft »Object Linking and Embedding (OLE)« und basierte in der ersten Fassung auf »Dynamic Data Exchange (DDE)«

Die historische Entwicklung von COM COM-Übersicht Die historische Entwicklung von COM

COM-Übersicht Da OLE 1 schwierig zu programmieren war und eine schlechte Performanz hatte wurde 1993 COM ins Leben gerufen. OLE 2 basierte nun auf COM - diese Technologie ging in ihrer Funktionalität über OLE hinaus. COM wurde nun in vielen Bereichen eingesetzt, fälschlicherweise jedoch oft als OLE benannt. Folge: OLE wurde zum Sammelbegriff für COM- Technologien benutzt und nicht mehr als Akronym für »Object Linking and Embedding«.

COM-Übersicht 1996 wird ActiveX eingeführt, welches auch Gebrauch von den COM-Technologien machte. OLE bekommt wieder seine alte Bedeutung, ActiveX wird zum neuen Sammelbegriff für COM-basierte Technologien. Mitte 1996 wird Windows NT 4.0 fertiggestellt und damit das Distributed COM (DCOM) eingeführt. COM öffnet sich nun verteilten Anwendungen. Für den Klienten einer Komponente bleibt es (fast) transparent, ob er auf eine Komponente zurückgreift, die lokal oder einem anderen Rechner liegt.

Verbesserung durch »Visual Basic Custom Controls« (VBX) COM-Übersicht Eng verwoben mit der Entwicklung des COM ist der Werdegang der sogenannten »Controls«. »Windows SDK Custom Controls« dienen der Wiederverwendung von Bedienelementen für Dialogfenster. Beschränkung: sie können nur in C oder C++ entwickelt werden. Verbesserung durch »Visual Basic Custom Controls« (VBX) Beschränkung: nur 16-Bit-Architektur, nur Intel-Plattformen, Simulationen von Methoden durch Action Properties

1993/94 werden die Nachteile der VBX behoben: COM bildet die Basis. COM-Übersicht 1993/94 werden die Nachteile der VBX behoben: COM bildet die Basis. Controls sind 32-Bit-fähig und können in verschiedenen Container-Typen eingesetzt werden. Neuer Name: OLE Controls 1996 entsteht die OCX-´96-Spezifikation (OLE Custom Controls) »fensterlose« Controls bessere Performanz

OCX werden in »ActiveX Controls« umbenannt. COM-Übersicht OCX werden in »ActiveX Controls« umbenannt. OCX und ActiveX Controls stimmen im wesentlichen überein,letztere werden lediglich für Internet-Einsätze optimiert. Andere Firmen beginnen mit der Portierung für andere Plattformen (z.B. Solaris, HP/UX, OS/390, Digital Unix, OpenVMS) und Microsoft selbst liefert eine Portierung für Mac OS.

Einige Mechanismen werden ins Betriebssystem verlagert. COM-Übersicht Aktueller Stand der Entwicklung: COM+ als integraler Bestandteil von Windows 2000 Komponenten-Entwicklung wird in Java, Visual Basic und Visual C++ möglich. Einige Mechanismen werden ins Betriebssystem verlagert.

COM ist ein Komponentenmodell von Microsoft. Was ist COM? 4.1.2 Was ist COM? COM ist ein Komponentenmodell von Microsoft. COM ist eine Spezifikation für die Erstellung von COM- Komponenten. Diese sind interoperabel und dynamisch austauschbar und können als »Black Box« wiederverwendet werden. Es ist gleichgültig, in welcher Programmiersprache eine COM-Komponente entwickelt wird. Sie muss lediglich ein spezielles binäres Format aufweisen.

Was ist COM? COM vereinheitlicht Techniken, die das Ziel haben, auf existierende Funktionalität zurückzugreifen (z.B. Aufrufe von Betriebssystem- funktionen oder Kommunikation über ein Netzwerk). COM standardisiert den Zugriff auf das Dienstangebot einer Softwarekomponente und erreicht damit Interoperabilität zwischen Komponenten. COM definiert eine Vielzahl von Schnittstellen, auf denen die Kommunikation mit einer Komponente basiert. Eigene Schnittstellen können definiert werden. COM enthält ein »Application Programming Interface« (API) in Form der »COM-Library«.

Im COM-Umfeld wird eine Operation durch ihren Schnittstellen 4.1.3 Schnittstellen Eine Schnittstelle fasst eine Menge von normalerweise zusammengehörigen Operationen zusammen. Eine Operation ist die abstrakte Beschreibung einer Funktion - zunächst ist also kein Code mit ihr assoziiert. Im COM-Umfeld wird eine Operation durch ihren Namen, die Anzahl und Art der erwarteten Übergabeparameter, den Typ des Rückgabewertes sowie einige Zusatzinformationen beschrieben.

Schnittstellen Beispiel: Definition der COM-Schnittstelle IUnknown in Microsofts Interface Definition Language (IDL) interface IUnknown { HRESULT QueryInterface( [in] REFIID riid, [out, iid_is(riid)] void** ppvObject ); ULONG AddRef( ); ULONG Release( ); }

IUnknown weist drei Operatoren auf: QueryInterface, AddRef und Release Schnittstellen Beispiel: Definition der COM-Schnittstelle IUnknown1 in Microsofts Interface Definition Language (IDL) IUnknown weist drei Operatoren auf: QueryInterface, AddRef und Release QueryInterface erwartet zwei Parameter: Einen Eingabeparameter ([in]) und einen Ausgabeparameter ([out]) REFIID ist eine Typdefinition für eine Referenz auf einen Interface Identifier (IID), ein 16-Byte-Wert, der eine Schnittstelle weltweit eindeutig kennzeichnet. Der zweite Parameter ist ein Zeiger auf einen void-Zeiger, der angibt wo das Ergebnis vom Typ void* abgelegt werden soll. Der Operationsrückgabewert ist vom Typ HRESULT, ein 32-Bit-Wert, der den Erfolg oder Misserfolg des Funktionsaufrufs anzeigt.

Schnittstellen Eine COM-Komponente kann beliebig viele solcher Schnittstellen implementieren. Es ist unerheblich, ob dies Standard-COM-Schnittstellen oder selbst definierte Schnittstellen sind. Die Implementierung von IUnknown ist allerdings für jede COM-Komponente obligatorisch. Komponentenschnittstellen werden grafisch mit einer Notation dargestellt, die auch Einzug in die »Unified Modeling Language« (UML) gefunden hat.

Grafische Darstellung einer Komponente mit Ihren Schnittstellen ProjectPlanner IUnknown IPersistFile IPersistStorage IProjectPlanner

Schnittstellen Ein Klient besitzt keinen direkten Verweis auf eine Komponenteninstanz, sondern er kann nur über »Schnittstellenzeiger« mit einer Komponente interagieren. Über einen Schnittstellenzeiger kann ein Klient alle Operationen dieser Schnittstelle aufrufen, die dann von der Komponente implementiert werden. Direkter Zugriff auf etwaige Instanzdaten ist nicht möglich, eine Komponente stellt sich also dem Klienten als »Black Box« dar.

Die Benutzung von IUnknown::QueryInterface Schnittstellen Die Benutzung von IUnknown::QueryInterface ProjectPlanner IUnknown IProjectPlanner Klient 1. Klient benutzt IUnknown-Schnittstellenzeiger, um mit Aufruf von QueryInterface(IID_IProjectPlanner) einen Zeiger auf IProjectPlanner zu erfragen. 2. Komponente liefert IProjectPlanner-Zeiger zurück. 3. Klient kann nun Opera- tionen von IProjectPlanner aufrufen.

Schnittstellen - Wie gelangt ein Klient an einen Schnittstellenzeiger? Die Umsetzung der Szenarien Schnittstellen - Wie gelangt ein Klient an einen Schnittstellenzeiger? Bei der Erzeugung einer neuen Komponenteninstanz, erhält der Klient den IUnknown-Schnittstellenzeiger dieser Instanz. Über die Operation QueryInterface von IUnknown kann der Klient die Komponente befragen, ob sie diejenige Schnittstelle unterstützt, die er durch die im ersten Parameter übergebene IID spezifiziert hat. Positiver Fall: Der entsprechende Schnittstellenzeiger wird im zweiten Parameter zurückgeliefert und der HRESULT-Rückgabewert signalisiert Erfolg. Negativer Fall: Der Klient erhält den HRESULT-Rückgabewert >E_NOINTERFACE<, der anzeigt, dass die gewünschte Schnittstelle nicht von der Komponente angeboten wird - der Schnittstellenzeiger wird auf NULL gesetzt.

Jede COM-Schnittstelle muss von IUnknown erben, direkt oder transitiv. Schnittstellen Jede COM-Schnittstelle muss von IUnknown erben, direkt oder transitiv. Somit ist sichergestellt, dass jede COM-Komponente die drei Operatoren von IUnknown unterstützt und diese auf jedem Schnittstellenzeiger aufgerufen werden können. COM sieht ausschließlich die Schnittstellenvererbung vor, eine Implementationsvererbung (wie bei C++) ist nicht möglich. Code-Wiederverwendung wird mit anderen Mitteln erreicht (Containment und Aggregation, vgl. 4.1.11)

Die Komponenten müssen ein bestimmtes binäres Format haben. Schnittstellen Die Komponenten müssen ein bestimmtes binäres Format haben. Es ist dabei ein Format gewählt worden, welches sich mit einem C++-Compiler generieren läßt. Dabei handelt es sich um die vtable, eine Tabelle in dem die Adressen der virtuellen Methoden einer Klasse verwaltet werden. Darum wird eine COM-Komponente in C++ typischerweise als Klasse modelliert und sie erbt von allen gewünschten Schnittstellen (Mehrfachvererbung) und implementiert die geerbten abstrakten Methoden.

C++-Deklaration der ProjectPlanner-Komponente Schnittstellen C++-Deklaration der ProjectPlanner-Komponente class CProjectPlanner : public IProjectPlanner, public IPersistFile, public IPersistStorage { public: HRESULT __stdcall QueryInterface(const IID& iid, void** ppv); //... };

Speicherstruktur der ProjectPlanner-Komponente Schnittstellen Speicherstruktur der ProjectPlanner-Komponente CProjectPlanner Zeiger auf IProjectPlanner-vtable Zeiger auf IPersistFile-vtable Zeiger auf IPersistStorage-vtable Instanz-Daten von CProjectPlanner QueryInterface AddRef Release addProject removeProject ... IProjectPlanner GetClassID IsDirty IPersistFile IPersistStorage vtable

Schnittstellen Die vtable unterteilt sich logisch in mehrere Segmente, in denen die Funktionszeiger der verschiedenen Schnittstellen verwaltet werden. Vor den eigentlichen Instanzdaten für die Attribute der Komponentenklasse werden Zeiger auf die verschiedenen Segmente im Speicher abgelegt. Diese Zeiger entsprechen den Werten, die man in C++ erhält, wenn eine Typkonvertierung (cast) der Komponentenklasse auf eine der Basisklassen/Schnittstellen durchführt. Einem Klienten, der per QueryInterface um eine Schnittstellenzeiger bittet, wird der Wert dieses Zeiger übermittelt.

C++ Deklaration der ProjectPlanner-Komponente Die Umsetzung der Szenarien C++ Deklaration der ProjectPlanner-Komponente Bemerkenswert ist, dass die IUnknown-Methoden mehrfach in der vtable auftreten, da die Schnittstellenklasse IUnknown nicht virtuell beerbt wird. Also weist jeder Schnittstellenzeiger die Fähigkeiten von Iunknown auf. COM erfordert eine eindeutige Assoziation zwischen Komponenteninstanz und IUnknown-Schnittstellenzeiger. Eine Nachfrage des IUnknown-Schnittstellenzeigers liefert in allen Schnitstellen einer Komponenteninstanz immer den gleichen Wert. Diese Invariante ermöglicht es zu entscheiden, ob zwei Schnittstellenzeiger auf dieselbe Komponente verweisen.

Referenzzählung 4.1.4 Referenzzählung Neben QueryInterface weist IUnknown noch zwei weitere Operationen auf: AddRef und Release. Diese werden verwendet, um einen Referenzzähler-Mechanismus zu implementieren. Benutzt ein Klient eine Komponenteninstanz bzw. eine ihrer Schnittstellen, muss er AddRef aufrufen um damit die Komponenteninstanz einen internen Referenzzähler inkrementiert. Wird die Schnittstelle nicht mehr benötigt, sollte dies durch einen Aufruf von Release anzeigen, um den Referenzzähler wieder zu dekrementieren.

Beispiel für QueryInterface und Referenzzählung HRESULT save(IProjectPlanner+ planner) { IPersistFile* file = NULL, Hresult hr = planner ->QueryInterface( IID_IPersistFile, (void**)&file ); if (SUCCEEDED(hr)) // AddRev wurde bereits auf file abgerufen hr = file->IsDirty(); if (SUCCEEDED(hr) && (hr != S_FALSE)) // Speichern... }; // angeforderter Schnittstellenzeiger wird nicht mehr benötigt file->Release(); return hr;

4.1.5 Erzeugen von Komponenteninstanzen Referenzzählung 4.1.5 Erzeugen von Komponenteninstanzen Der Entwickler einer COM-Komponente ist verpflichtet, neben der Komponente auch eine dazugehörige Class Factory zur Verfügung zu stellen. Diese hat die Aufgabe, auf Anforderung eine neue, nicht- initialisierte Instanz der entsprechenden Komponente zu erzeugen. Die Class Factory ist eine normale COM-Komponente, muss allerdings die Schnittstelle IClassFactory unterstützen.

Die Schnittstelle IClassFactory Referenzzählung Die Schnittstelle IClassFactory interface IClassFactory : IUnknown { HRESULT CreateInstance( IUnknown* PUnkOuter, REFIID riid, void** ppvObject ); HRESULT LockServer([in] BOOL fLock); \\ Referenzzählung für Fabrik }

Dies wird durch die COM-Bibliothek gelöst. Referenzzählung Nachdem geklärt ist, wie eine Komponenteninstanz erzeugt wird, stellt die Frage, wie man an die dazu benötigte Fabrik gelangt. Dies wird durch die COM-Bibliothek gelöst. Analog zu den Schnittstellen jeder Komponente werden weltweit eindeutig sogenannte CLSID (Class Identifier) zugeordnet. Die COM-Funktion GoGetClassObject erwartet unter anderem eine solche CLSID als Parameter und liefert die passende Fabrik. CLSID ist das maschinenlesbare Pendant zu den lesbaren Schnittstellennamen.

Die COM-Funktion GoGetClassObject Referenzzählung Die COM-Funktion GoGetClassObject HRESULT __stdcall GoGetClassObject( const CLSiD& clsid, DWORD dwClsContext, CONSERVERINFO* pServerInfo, const IID& iid, void** ppv );

Referenzzählung Eine Fabrik kann neben der obligatorischen IClassFactory- Schnittstelle noch weitere beliebige Schnittstellen unterstützen. Mit welcher Schnittstelle man arbeiten möchte, kann man über den IID-Parameter von GoGetClassObject steuern. Damit GoGetClassObject anhand einer CLSID die entsprechende Komponente instanziieren kann, sind einige Information in der Registrierungsdatenbank (registry) von Microsoft Windows zu hinterlegen. GoGetClassObject gewählt dem Klienten weitgehende Kontrolle über die Instanziierung einer Komponenteninstanz. Mit Hilfe der Funktion GoCreateInstance kann man mühselige Arbeit verkürzen (Fabrik ermitteln, damit Instanz erzeugen, Fabrik später freigeben)

Die COM-Funktion GoCreateInstance Referenzzählung Die COM-Funktion GoCreateInstance HRESULT __stdcall GoCreateInstance( const CLSID& rclsid, IUnknown* pUnkOuter, DWORD dwClsContext, const IID& riid, void** ppv );

Referenzzählung Die bisher nicht genannte Operation LockServer der Schnittstelle IClassFactory dient der Referenzzählung der Fabriken. Fabriken werden vom normalen Referenzzähler ausgeschlossen und immer bei Beendigung eines Out-Of-Process-Servers freigegeben (vgl. 4.1.12). Ein Klient, der eine Referenz auf eine Fabrik besitzt, kann die Terminierung eines Servers durch den Aufruf von LockServer(TRUE) unterbinden, damit die Referenz nicht ungültig wird. Wird die Fabrik nicht mehr benötigt, wird dies durch LockServer(FALSE) kundgetan.

4.1.6 Weltweit eindeutige Bezeichner - GUID Die Interface Identifier (IID) und Class Identifier (CLSID) wurden bereits als Beispiele für die Globally Unique Identifier (GUID) genannt. GUID-Werte werden weitergehend zur Kennzeichnung weiterer COM-Elemente gebraucht (Beispiele: Komponentenkategorien oder Typenbibliotheken).

4.1.6 Weltweit eindeutige Bezeichner - GUID COM ist auf eine weltweit eindeutige Identifizierung angewiesen, damit diese GUID-Werte immer korrekt sind, werden sie durch einen Algorithmus lokal auf dem Rechner erzeugt. Ein GUID-Wert setzt sich aus 128 Bits zusammen: 48 Bits kennzeichnen den Rechner, mit dem die GUI erzeugt wurde. 60 Bits enthalten einen Zeitstempel (der die 100- Nanosekunden-Intervalle seit dem 15.10.1582 zählt). 4 Bits enthalten die GUID-Versionsnummer. 16 Bits werden anhand der Systemzeit berechnet (um Eindeutigkeit bei schnell hintereinander erzeugten GUID-Werten sicherzustellen).

Programmierer können auf die COM-Funktion GoCreateGuid zurückgreifen. Microsoft Visual C++ enthält zwei Hilfsprogramme, um GUID-Werte generieren zu lassen: UUIDGEN.EXE (Kommandozeilen-Programm) GUIDGEN.EXE (grafische Bedienoberfläche) Programmierer können auf die COM-Funktion GoCreateGuid zurückgreifen.

IDL 4.1.7 IDL GUID-Werte ermöglichen eine eindeutige Identifizierung von Schnittstellen. Wo wird beschrieben, welche Operationen eine Schnittstelle aufweist? COM macht hier keine Vorgaben, ein Komponenten- Entwickler kann also selber bestimmen, in welcher Form eine Schnittstelle dokumentiert wird. Notwendig ist lediglich die Information, um das Format der vtable ableiten zu können.

IDL - Beschreibung von Schnittstellen In der Regel wird die Interface Definition Language (IDL) zur Beschreibung von Schnittstellen und den sie implementierenden Komponenten benutzt. Da CORBA ebenfalls eine IDL besitzt, spricht man auch von der MIDL (Microsoft IDL) und OMG IDL, um die beiden Sprachen voneinander zu unterscheiden.

MIDL-Auszug für die ProjectPlanner-Komponente (1/2) [ object, uuid(67359BB5-2874-11D3-00C04FEDFA33), dual, helpstring(“IProjectPlanner-Schnittstelle“), pointer_default(unique) ] interface IProjectPlanner : IDispatch { [id(1)] HRESULT addProject( [in] ITask* project, [in] short r, [in] short g, [in] short b ); [id(2)] HRESULT removeProject([in] ITask* project), [propget, id(3)] HRESULT ProjectCardinal ([out, retval] short *pVal);

MIDL-Auszug für die ProjectPlanner-Komponente (2/2) HRESULT get_ProjectAt([in] short index, [out, retval] ITask* *pVal); // ... }; [ uuid(67359BB6-2874-11D3-831D-00C04FEDFA33), helpstring(“ProjectPlanner Class“) ] coclass ProjectPlanner { [default] interface IProjectPlanner; interface IPersistStorage; interface IPersistFile;

Aufgaben der IDL-Dateien Dokumentation von Komponenten und Schnittstellen Automatisches Generieren der Proxy und der Stub Kompilieren in so genannte Typbibliotheken

4.1.8 Automation und die IDispatch-Schnittstelle Automation bezeichnet eine Technik, die den Zugriff auf COM- Komponenten erlaubt, ohne zur Compile-Zeit Kenntnis über die Binärstruktur der zu nutzenden Komponenten zu haben. Im Gegensatz zum direkten Zugriff über zB Header-Dateien Eine Komponente, die Automation unterstützt, implementiert die von IUnknown abgeleitete Schnittstelle IDispatch, welche einen dynamischen Operationsaufruf gestattet. Eine solche Komponente bezeichnet man auch als Automation Server. Klient wird Automation Controller bezeichnet

Automation Ein Automation Controller übergibt dem Automation Server einen oder mehrere Operationsnamen in der IDispatch Operation GetIDsOfNames. Dieser erhält für jede Operation eine so genannte DISPID (als 32- Bit-Integer) zurück, sofern die entsprechende Operation von der Komponente unterstützt wird. Unter Angabe einer DISPID kann eine entsprechende Operation über die IDispatch-Operation Invoke aufgerufen werden. Diese Operationen bezeichnet man als Dispinterface (Dispatch Interface). Typüberprüfung findet zur Laufzeit statt, dadurch entstehen Performanznachteile. Außerdem ist die Implementierung des Automation Controllers aufwendiger.

Arbeiten mit dem Dispatch Interface Automation Arbeiten mit dem Dispatch Interface Die Operationsparameter müssen an Invoke in varianten Strukturen (VARIANT) verpackt übergeben werden. Elementare Datentypen werden unterstützt, Strings müssen als BSTR übergeben werden. Insbesondere stehen die Schnittstellenzeiger IUnknown und IDispatch zur Verfügung.

Automation Dispinterface-Aufrufe haben eine schlechte Performanz - bedingt durch das Ein- und Auspacken der Parameter. Wichtig für Automation-konforme Dispinterfaces: Eine Operation darf nur einen einzigen [out,retval]- Rückgabeparameter aufweisen, und dieser muss der letzte Parameter einer Operation sein.

MIDL-Auszug für die ProjectPlanner-Komponente (1/2) Automation MIDL-Auszug für die ProjectPlanner-Komponente (1/2) [ object, uuid(67359BB5-2874-11D3-00C04FEDFA33), dual, helpstring(“IProjectPlanner-Schnittstelle“), pointer_default(unique) ] interface IProjectPlanner : IDispatch { [id(1)] HRESULT addProject( [in] ITask* project, [in] short r, [in] short g, [in] short b ); [id(2)] HRESULT removeProject([in] ITask* project), [propget, id(3)] HRESULT ProjectCardinal ([out, retval] short *pVal);

MIDL-Auszug für die ProjectPlanner-Komponente (2/2) Automation MIDL-Auszug für die ProjectPlanner-Komponente (2/2) [id(4)] HRESULT get_ProjectAt([in] short index, [out, retval] ITask* *pVal); // ... }; [ uuid(67359BB6-2874-11D3-831D-00C04FEDFA33), helpstring(“ProjectPlanner Class“) ] coclass ProjectPlanner { [default] interface IProjectPlanner; interface IPersistStorage; interface IPersistFile;

Automation Neben Dispinterface und IDispatch kann ein Automation-Server auch die “normalen” vtable-Schnittstellen veröffentlichen. Die Gesamtschnittstelle wird auch als duale Schnittstelle bezeichnet. Duale Schnittstellen erfordert eine Typbibliothek, damit Klienten schneller und sicherer auf ihre vtable-Schnittstelle zugreifen können.

Die Struktur einer dualen COM-Schnittstelle Automation Die Struktur einer dualen COM-Schnittstelle Zeiger auf IProjectPlanner-vtable QueryInterface AddRef Release addProject removeProject ... IUnknown vtable GetTypeInfoCount GetTypeInfo GetIDsOfNames Invoke IDispatch IProjectPlanner Delegation

4.1.9 Komponentenkategorien Problem: Klient möchte eine Operation einer Komponente aufrufen, weiss aber nicht welche Komponente sie umsetzt. Dazu müsste der Klient alle verfügbaren Komponenten instaziieren und QueryInterface aufrufen. Lösung: Komponentenkategorien. Komponentenkategorien erleichtern den Austausch von Komponenten zur Laufzeit und das Hinzufügen von neuen Komponenten.

Komponentenkategorien Eine Kategorie wird durch eine GUID namens Category Identifier (CATID) identifiziert, sie repräsentiert eine oder mehrere Schnittstellen. Eine Komponente kann bekannt geben, welche Kategorien sie verbindlich unterstützt. Eine Komponente kann Kategorien auflisten, die im Gegenzug ein Klient unterstützen muss, damit dieser die Komponente beherbergen kann -> zB Call-Back

Komponentenkategorien Diese Informationen werden unter den Schlüsseln »Implemented Categories« und »Required Categories« unter den CLSID-Einträgen der Komponente in der Registry-Datenbank abgelegt. Eine Instanziierung einer Komponente für Tests ist nicht erforderlich. Der Component Category Manager gestattet die Verwaltung und Abfrage dieser Informationen über die Schnittstellen ICatRegister und ICatInformation.

Problem nicht nur bei langlebigen Systemen: Versionierung COM lässt keine Versionierung zu! (»Implicit Contracts«) Nach der Freigabe einer Schnittstelle darf sie nicht mehr verändert werden Reihenfolgebedingungen dürfen nicht verletzt werden.

Mit der oben dargestellten Methode realisiert COM auch Polymorphie. Versionierung Möchte man eine Komponente erweitern, erfordert dies eine neue Schnittstelle mit einer neuen IID. Die Koexistenz von bereits existierenden Klienten und Anwendungen, wird durch die lose Kopplung zwischen Komponenten und dem QueryInterface-Mechanismus ermöglicht. Ein Klient, der auf die neue Funktionalität angewiesen ist, erlangt den dafür nötigen Schnittstellenzeiger über die neue IID. Existierende Klienten bleiben aber von den Änderungen völlig unberührt. Mit der oben dargestellten Methode realisiert COM auch Polymorphie.

4.1.11 Containment und Aggregation COM unterstützt keine Implementationsvererbung zwischen Komponenten, weil diese eine Komponente eng an die Implementierung einer anderen Komponente bindet. (»fragile base class«) Dafür bietet COM ein alternatives Vererbungskonzept: Schnittstellenvererbung. Komponente muss also eigene Schnittstellen und geerbte Schnittstellen implementieren.

COM bietet zwei Techniken zur Code- Wiederverwendung: Containment und Aggregation Allerdings ist Implementationsvererbung auf Programmiersprachenebene möglich. ActiveX Template Libary (ATL) bietet zahlreiche Template-Klassen, die entsprechende Funktionaltäten zur Vererbung bereitstellen. COM bietet zwei Techniken zur Code- Wiederverwendung: Containment Aggregation

"Containment" (im Sinne von Delegation) um Implementierungen wiederzuverwenden Client äußeres Objekt inneres Objekt A B

Struktur einer Komponente bei Containment Containment und Aggregation Struktur einer Komponente bei Containment Äußere Komponente Interface 1 Interface 2 Innere Komponente Interface 3 Klient

Containment und Aggregation Die äußere Komponenteninstanz erzeugt die innere Komponenteninstanz. Äußere Komponenteninstanz ist alleiniger Klient der inneren. Bei der Implementierung der inneren Komponente müssen keine Vorkehrungen getroffen werden. Jede Komponente kann als innere Komponente im Sinne von Containment dienen. Sonderfall bei Unterstützung der gleichen Schnittstelle durch äußere und innere Komponenteninstanz (-> Delegation)

Struktur einer Komponente bei Aggregation Containment und Aggregation Struktur einer Komponente bei Aggregation Interface 1 äußere Komponente Interface 2 Interface 3 innere Komponente delegated unknown  non-delegated unknown Referenzzählung der inneren Komponente (wird delegiert an äußere Komponente)

Containment und Aggregation Spezialfall von Containment, dient zur Vermeinung von Containment-Kaskaden. Klient kann direkt auf die innere Komponenteninstanz zugreifen durch Schnittstellenzeiger, damit kann die innere Komponenteninstanz nicht von der äußeren kontrolliert werden. Aggregration ist transparent für den Klient. Innere Komponente muss vorbereitet sein (d.h. nicht alle Komponenten sind aggregierbar). Implementierung der inneren Komponente aufwendig, da COM-Grundregel: 1. Jeden Schnittstellenzeiger kann man über jeden Schnittstellenzeiger ermitteln. 2. Jede Komponente hat einen eindeutigen IUnknown-Schnittstellenzeiger.

"Containment" funktioniert mit allen COM-Objekten Containment und Aggregation "Containment" funktioniert mit allen COM-Objekten Aggregation funktioniert nur mit solchen Objekten, die als "innere" Objekte entwickelt worden sind (Referenzzähler, Funktionieren von QueryInterface) äußeres Objekt bietet nur Schnittstelle A und IUnknown inneres Objekt bietet Schnittstelle B und IUnknown wegen der Aggregation wird Schnittstelle B nach außen sichtbar wenn ein Client QueryInterface auf der Schnittstelle B aufruft, dann sollte hiervon der Zähler des äußeren Objekts betroffen werden, aber wie soll das innere Objekt Kenntnis von der Schnittstelle A haben? Lösung: ein inneres Objekt delegiert alle Aufrufe an IUnknown an die äußeren Objekte, hierzu muss ein inneres Objekt wissen, wie es aggregiert ist.

Komponenten-Server 4.1.12 Komponenten-Server COM sieht zwei „Verpackungsbehälter“ vor, in denen COM-Komponenten den späteren Klienten zur Verfügung gestellt werden können: Dynamic Link Library (DLL) das ausführbare Modul (EXE-Format) Beherbergen diese Formate COM-Komponenten, spricht man von COM-Servern.

Server-Registrierung / -Verwaltung Komponenten-Server Prinzipielle Struktur eines COM-Servers COM-Server Komponente X Fabrik für X Komponente Y Fabrik für Y Server-Registrierung / -Verwaltung

Komponenten-Server Ein COM-DLL-Server muss die folgenden vier Einsprungpunkte (exportierte Funktionen) unterstützen: DllRegisterServer: Diese Funktion speichert in der Windows- Registierungsdatenbank, welche Komponente in welcher DLL untergebracht ist. DllUnregisterServer: Dies ist das Gegenstück zu oben genannter Funktion. DllGetClassObject: Diese Funktion gibt eine Schnittstellenzeiger auf die zur spezifizierten CLSID zurück. DllCanUnloadNow: Diese Funktion gibt dem Laufzeitsystem Auskunft, ob die DLL aus dem Hauptspeicher entfernt werden kann.

Ein COM-EXE-Server kann keine Funktionen wie eine DLL exportieren. Komponenten-Server Ein COM-EXE-Server kann keine Funktionen wie eine DLL exportieren. Eine (De-) Registrierung erfolgt über Kommandozeilenargumente (/RegServer bzw. /UnRegServer) Ein COM-EXE-Server ist im Vergleich zu einer DLL aktiv, somit kann dieser sich selbst terminieren, wenn seine Dienste nicht mehr benötigt werden. Eine COM-Server-DLL bezeichnet man als In-Process-Server, da der Code der DLL in den Adressraum des aufrufenden Prozesses eingeblendet wird. Ein EXE-Modul läuft in einem separaten Prozess, darum nennt man dies einen Out-of-Process-Server. Befindet sich ein Out-of-Process-Server auf dem gleichen Rechner wie der Prozess des Klienten, bezeichnet man ihn als Local Server, ansonsten wird er Remote Server genannt.

Marshaling und Demarshaling Komponenten-Server Marshaling und Demarshaling Der Zugriff auf einen In-Process-Server ist einfach, da keine Prozessgrenzen überwunden werden. Wird auf einen Out-of-Process-Server zugegriffen, ist Marshaling und Demarshaling notwendig. Marshaling bezeichnet das Verpacken der Operationsparameter für den Transport über Prozessgrenzen. Demarshaling ist der Vorgang des Auspackens beim Empfänger. Diese Vorgänge werden in den Stub und den Proxy verlagert. Stub und Proxy werden als DLL implementiert, da sie direkten Zugriff auf Komponentendaten benötigen. Ortstransparenz durch Stub und Proxy.

Ortstransparenz durch Stub und Proxy Komponenten-Server Ortstransparenz durch Stub und Proxy Klienten-Prozess Klient Proxy für X Server-Prozess Stub für X Kompo- nente X LPC oder RPC

Proxy- bzw. Stub-DLL - Drei Wege: Komponenten-Server Proxy- bzw. Stub-DLL - Drei Wege: Standard Mashaling: Generierung durch MIDL-Compiler aus der IDL-Beschreibung einer Komponente in passende DLLS für Proxy und Stub TypeLib Mashaling: Demarshaling der Parameter benötigte Metainformationen werden aus der Typbibliothek entnommen Custom Marhalling: Man kann das Marhaling bzw. Demarshaling vollständig selbst in die Hand nehmen.

Die COM-Funktion GoCreateInstance Komponenten-Server Die COM-Funktion GoCreateInstance HRESULT __stdcall GoCreateInstance( const CLSID& rclsid, IUnknown* pUnkOuter, DWORD dwClsContext, const IID& riid, void** ppv );

Die CLSCTX-Konstanten Komponenten-Server Die CLSCTX-Konstanten typedef enum tagCLSCTX {   CLSCTX_INPROC_SERVER  = 1,   CLSCTX_INPROC_HANDLER = 2,   CLSCTX_LOCAL_SERVER   = 4,   CLSCTX_REMOTE_SERVER  = 16 } CLSCTX;

COM stützt sich auf die im Betriebssystem verfügbaren Threads. Nebenläufigkeit 4.1.13 Nebenläufigkeit inter-concurrency: Zugriff von mehrere Threads auf eine Komponenteninstanz. intra-concurrency: Bereitstellung der Komponenteninstanzen in mehreren Threads. COM stützt sich auf die im Betriebssystem verfügbaren Threads. Ältere COM-Komponenten sind nicht Thread-sicher, Kompatiblität durch Unterstützung des Apartment Model

Entwickler ist zuständig für die Thread-Sicherheit. Nebenläufigkeit Apartment Model Single-threaded Apartment (STA): Komponenteninstanz verfügt über einen Thread, Aufrufe von außen werden in eine Warteschleife eingereiht. Implementierung einfach, aber Performanzverlust durch Marshaling/Demarshaling für Aufrufe über Apartmentgrenzen hinweg. Multithreaded Apartment (MTA): mehrere Threads in einem Apartment zusammengefasst, direkter Zugriff auf die Komponenteninstanz. Entwickler ist zuständig für die Thread-Sicherheit.

CoInitialize: Standartmäßig STA. Nebenläufigkeit Apartment wird durch Aufrufen des entsprechende COM- Bibliotheksfunktions initialisiert CoInitialize: Standartmäßig STA. CoInitializeEx: Erlaubt die Spezifikation des Threading- Modells durch einen zusätzlichen Parameter. Bei In-Process-Server geschieht die Initialisierung über die Registrierungsdatenbank, da COM-Server schon die Initialisierung vorweg genommen hat. Im Gegensatz zu Out-of-Process-Server muss ein In- Process-Server das gleiche Threading-Model wie der Klient verwenden.

Persistenz muss explizit vom Entwickler übernommen werden. Persistenz gestattet Instanzen, ihren Zustand auf einem nichtflüchtigen Speichermedium abzulegen (z.B. Datenbank). Komponenteninstanz kann Prozess überleben und in einem anderen rekonstruiert werden. Persistenz muss explizit vom Entwickler übernommen werden. Clients müssen die Persistenz verwalten.

Persistenz Structured Storage, für Kontrolle und Steuerung stehen IPersist*-Schnittstellen zur Verfügung. Structured Storage aus OLE motiviert. Verbunddokument besteht aus mehreren, voneinander unabhängigen Komponenteninstanzen.

Persistenz Structured Storage Datei Stream Root Storage Storage

Storages und Streams sind gewöhnliche COM- Komponenten. Die Umsetzung der Szenarien Storages und Streams sind gewöhnliche COM- Komponenten. IStorage und IStream sind die die dazugehörigen Schnittstellen. Direct Mode: sämtliche Änderungen werden sofort abgespeichert. Transacted Mode: Änderungen werden zwischengespeichert und erst bei einem Commit persistent. Revert: Änderungen können verworfen werden (Rollback)

IPersist-Schnittstellen Persistenz IPersist-Schnittstellen IPersistStream: Verwaltung der Persistenz einer Kompontente IPersistStreamInit: fügt eine weitere Operation hinzu, Initialisierung eines Objektes IPersistStorage: Verwlatung der Daten in einem Storage statt in einem Stream IPersistFile: Repräsentation der Schnittstellen zu einer normalen Datei („flat file“)

Persistenz IPersistPropertyBag: wird von ActiveX-Controls unterstützt. Das eigentliche Laden und Speichern der Daten übernimmt der Klient. IPersistMemory: Binärer Datenaustausch über einen gemeinsamen Speicherbereich von Klient und Komponenteninstanz. IPersistMoniker: Wie IPersistFile, doch die Instanzdaten werden über einen Dateinamen (Moniker) referenziert.

Ein Moniker ist eine COM-Komponente mit der Schnittstelle IMoniker Monikers 4.1.15 Monikers Durch Moniker können Komponenteninstanzen eindeutig benannt und später referenziert werden. Moniker assoziieren eine spezifische Komponenteninstanz mit einem Namen. Ein Moniker ist eine COM-Komponente mit der Schnittstelle IMoniker Wichtigste Operation ist die BindToObject Ein Moniker kann selbst persistente Daten enthalten, zB Name der Datei, in der der Zustand des Objektes abgespeichert ist.

"D:\Projekte\COM\Projektplan.ppl" Monikers Ablauf beim Binden einer File-Moniker-Referenz Klient File Moniker "D:\Projekte\COM\Projektplan.ppl" 1. BindToObject D:\Projekte\COM\Projektplan.ppl 2. Ermittlung der CLSID ProjectPlanner IMoniker IPersistFile 3. CoCreateInstance 4. Load(“D:\...\Projektplan.ppl“) 5. IProjectPlanner-Zeiger wird zurückgeliefert IProjectPlanner

Die Instanz fungiert dann als „Lieferant“ (Moniker Provider) Monikers Weitere Moniker-Typen: Item Monikers oder Composite Monikers, die für OLE relevant sind. Monikers können direkt von einem Klienten erzeugt werden - werden aber häufiger von der Komponenteninstanz generiert. Die Instanz fungiert dann als „Lieferant“ (Moniker Provider) Kreierung wie gewohnt über CoCreateInstance oder CreateFileMoniker Einbindung erfolgt idR synchron. Jedoch ist auch asynchrones Einbinden möglich über die Schnittstelle IBindStatusCallback.

Lösungsansatz: bidirektionale Kommunikation Verbindungspunkte 4.1.16 Verbindungspunkte Was tun, wenn z.B. der Server den Klienten über Änderungen seines Zustands notifizieren möchten (anstatt - wie bisher umgekehrt)? Lösungsansatz: bidirektionale Kommunikation

Verbindungspunkte Bidirektionale Kommunikation mit Referenzzyklus: Beide Komponenteninstanzen blockieren gegenseitig die Freigabe der jeweils anderen Instanz (Referenzzyklus) Die Folge „Memory Leaks“ - Performanz- und Stabilitätsprobleme aller Prozesse auf dem Rechner.

Server- Komponenteninstanz Verbindungspunkte Vermeidung von Referenzzyklen bei bidirektionaler Kommunikation: Server- Komponenteninstanz Klient IX IY Subkomponente

Sämtliche Aufrufe werden an den eigentlichen Klienten delegiert. Verbindungspunkte Sämtliche Aufrufe werden an den eigentlichen Klienten delegiert. weak reference auf die IY-Schnittstelle (Bezeichnung für Schnittstellen, deren Besitzer keinen AddRef-Aufruf (und damit keinen Release-Aufruf) ausführt. Referenzzyklus wird daher vermieden. Unterstützung jeder weiteren Schnittstelle erfordert die Duplizierung dieser Struktur, evtl. wird nur ein Klient unterstützt, Vermischung der Server-Schnittstelle mit Verwaltungsoperationen.

Connectable Objects Generische Lösung für bidirektionale Kommunikation. Serverkomponente publiziert beim Klienten benötigte Schnittstelle (source). Serverkomponente muss Schnittstelle IConnectionPointContainer unterstützen. Für jeden Outgoing Interface muss die Serverkomponente eine Verbindungspunkt-Instanz mit der Schnittstelle IConnectionPoint liefern können.

Verbindungspunkte Connectable Objects Zentrales Element: Verbindungspunkte - eine generische Lösung für bidirektionale Kommunikation [   uuid(67359BB6-2874-11D3-831D-00C04FEDFA33),   helpstring("ProjectPlanner Class") ] coclass ProjectPlanner {   [default] interface IProjectPlanner;                     interface IPersistStorage;                     interface IPersistFile;   [default, source] interface IProjectPlannerClient; };

Einrichten eines Verbindungspunktes Server- Komponenteninstanz IUnknown Klient 1. QueryInterface( IConnectionPointContainer) IConnection- PointContainer 2. FindConnectionPoint (IID_Ixyz) Connection Point für xyz IConnectionPoint 3. Advise 3.1. QueryInterface(Ixyz) Sink für xyz Ixyz Notifizierungen