Vorlesung Donnerstags, bis Uhr, HZ ÜbungsbläNer (Programmieraufgaben) Unterlagen / InformaRonen

Transkript

1 Komponenten Einführung Organisatorisches 2+1 SWS Vorlesung Donnerstags, bis Uhr, HZ ÜbungsbläNer (Programmieraufgaben) Klausur Februar 2014 Unterlagen / InformaRonen hnp://tamdhu.uni- trier.de/asysob studip 1

2 SoWwareentwicklung Wer hat schon eigene SoWware entwickelt? Umfang? Projektgröße in Anzahl Entwickler? Wer hat schon fremde SoWware (wieder)verwendet? Not invented here syndrom? Umfang? Wie wurde SoWware (wieder)verwendet? Code Scavenging? Bibliothek? Komponenten? Frameworks? Ganze ApplikaRonen verklebt? hnp:// SOFTWARE ENGINEERING 2

3 SoWware Engineering 1968 NATO SoWware Engineering Conference Geburt des Forschungsgebiets SoWware Engineering Erkennen einer SoWwarekrise SoWwarekrise Entwicklung großer und zuverlässiger Systeme in einer kontrollierten und kosteneffekrven Form schwierig bis unmöglich SoWware Reuse Zentraler Ansatzpunkt zur Überwindung der Krise 2012 ProblemaRk immer noch nicht befriedigend gelöst 3

4 SoWware Reuse Reusing exisirng sowware arrfacts during the construcron of a new sowware system (Krueger) Artefakt mehr als nur Sourcecode Architekturen Sourcecode Daten Entwürfe (Designs) SpezifikaRonen DokumentaRon Abschätzungen (EsRmates) Human Interfaces Pläne Anforderungen (Requirements) Tesrälle Prozesse Techniken des Reuse Hochsprachen Design- und Code- Scavenging Komponenten SoWwareschema Generatortechniken DeskripRve Entwicklungssprachen TransformaRonssysteme Frameworks 4

5 Bewertungskriterien AbstrakRon Wie werden die wiederverwendbaren Einheiten beschrieben? Wie wird von den unwesentlichen FaceNen abstrahiert bzw. von was kann abstrahiert werden? SelekRon Lokalisierung, Vergleich und Wahl eines wiederverwendbaren Artefakts Spezialisierung Hohe Wiederverwendbarkeit bei generalisierten Artefakten Spezialisierung nach erfolgter SelekRon IntegraRon der ausgewählten Komponenten in ein vorhandenes bzw. zu entwickelndes System SOFTWARE REUSE 5

6 Reuse Ausgangspunkt Entwicklungsprojekte sind keine einmaligen Ereignisse von Code Frameworks Komponenten Produkramilien von Erfahrungen Gemeinsame Sprache: UML Entwurfsmuster guter SoWwarestrukturen Erweiterte SoWwareprozesse (z.b. CMM) Frameworks und Komponenten Komponenten Hohe Qualität der Einzelkomponente erreichbar (Experten) Mehraufwand amorrsiert sich durch Reuse Hoher Verbreitungsgrad (COM, EJB,.NET, CORBA) Framework Von Experten geschrieben Hohe Qualität Je spezifischer die Anwendungs- domäne, desto besser Mehraufwand amorrsiert sich durch Reuse 6

7 Produkramilien Abfolge von ähnlichen Produktentwicklungen Isolierung der variablen Produktanteile Einzelprojekt- übergreifender SoWwareprozeß Ergänzend zu Frameworks und Komponenten Variabler Anteil Fixer Anteil Gemeinsame Sprache Graphische NotaRon mit wohldefinierter SemanRk VielfälRge Diagramme StaRsch Strukturbezogen Dynamisch Ablauyezogen Hoher Einarbeitungs- aufwand Phasenspezifische Diagramme 7

8 Design PaNern Wörter, Grammatik Satzlehre Fertige Texte Programmiersprache Design Pattern Programme Direkte Umsetzung in Form einer Code- Bibliothek nicht möglich StruktureigenschaWen der Anwendung Verteilt sich über mehrere Codestellen Einheitliche Bezeichung und Beschreibung Standardwerke, z.b. Gamma et al. Process Improvement ReflekRon durch alle Beteiligten Verbesserungen über mehrere Projekte hinweg Anpassung bzw. Änderung der Prozesse OpRmieren und Ergänzen von Metriken Erfahrungsdatenbanken wünschenswert Beispiele Capability Maturity Model (CMM), Spice, Six Sigma, Es gibt auch krirsche SRmmen 8

9 Werkzeugunterstützung Tools sind unersetzlich geworden DramaRsche Steigerung der Effizienz bei hoher Qualität Moderne Werkzeuge unterstützen höhere Ebenen (z.b. Design PaNern) Refactoring Hoher Einarbeitungsaufwand notwendig Wiederverwendung von Erfahrung A fool with a tool is srll a fool INHALTE 9

10 Übersicht Gängige Komponentenansätze COM Corba Enterprise Java Beans (EJB).NET Framework Berührungspunkte zu verteilten Systemen KommunikaRonsbedarf zwischen Komponenten Architekturkonzept für verteilte Anwendungen Service- OrienRerung (SOA) Web Services (XML- Technologien) REST Referenzen Charles W. Krueger SoWware Reuse ACM CompuRng Surveys, Vol. 24, No. 2, pp

11 Komponenten CORBA Common Object Request Broker Architecture (CORBA) Standard der Object Management Group (OMG) 1991 CORBA CORBA 2.0 seit ca CORBA 3.0 OMG Herstellerübergreifendes KonsorPum Gegründet 1989 von 11 Mitgliedern Aktuell mehr als 600 Mitglieder Ziele Verteilte Anwendungen mit objektorienperten Methoden ObjektorienPerte SoWwarebausteine (Komponenten) SchniXstellenstandards für verteilte Büroanwendungen Zurückgehende Bedeutung TelekommunikaPonsbereich WissenschaWliche Systeme (z.b. CERN, Genf) 1

12 Au]au Eigene CORBA- IDL Language- Bindings für alle gängigen Sprachen Manche Lösungen diskussionswürdig ORB = Object Request Broker Open Source - Lösungen vorhanden Beispiele: MICO (Uni Frankfurt), ORBit in Gnome IDL Compiler IDL Compiler Caller OS Dynamic Interface Stubs ORB IIOP ORB Stub OA Callee OS IDL CORBA- IDL mit Abstand mächpgste SchniXstellenbeschreibung... der Vergangenheit Basistypen Zahlen, Strings, Benutzerdefinierte Typen Strukturen, Arrays, Interfaces und OperaPonen Module 2

13 Basistypen Typ Werteraum Größe short bis Bit long bis Bit unsigned short 0 bis Bit unsigned long 0 bis Bit float IEEE single precision 32 Bit double IEEE double precision 64 Bit char ISO Latin-1 8 Bit string ISO Latin-1 (kein Variabel NUL) boolean TRUE oder FALSE./. octet Bit any Zur Laufzeit identifizierbarer Typ Variabel Benutzerdefinierte Typen Konstanten Eigene Namen typedef short Year; Aufzählungen enum Farbe { rot, gelb, gruen }; Zuweisung bespmmter Zahlenwerte nicht erlaubt Strukturen (wie überall) Unions union Mitarbeiter switch (Hackordnung) { case Professor: unsigned short mtbn; case Mitarbeiter: unsigend long sws; }; 3

14 Benutzerdefinierte Typen (contd.) Arrays typedef Pixel Farbe[3]; Typedef muß deklariert werden Sequenzen Variabel- langer Vektor Unbegrenzt: typedef sequence<pixel> Zeile; Begrenzt: typedef sequence<pixel,100> Zeile; Sequenzen von Sequenzen sind möglich Rekursive Datenstrukturen struct Knoten { long wert; sequence<knoten> kinder; } Interface CORBA- Beschreibung einer SchniXstelle Bestandteile Konstanten und TypdefiniPonen ExcepPons AXribute (Data Members) OperaPonen (FuncPon Members) Keine geschachtelte Interfaces möglich DirecPonal AXribute in Parameter wird vom Client zum Server gesendet out Parameter wird vom Server zum Client gesendet inout Paramter wird vom Client zum Server gesendet. Der resulperende Wert wird nach Beendigung der OperaPon an den aufrufenden Client zurückgesendet 4

15 OperaPonen OperaPonsdefiniPon Ergebnistyp OperaPonsname 0 oder mehr ParameterdeklaraPonen Overloading nicht erlaubt (keine gleichen OperaPonsnamen) Keine anonymen Typen als Parameter oder Ergebnis: sequence<long> get_longs(); // Fehler J typedef long Zahl; sequence<zahl> get_zahlen(); // Erlaubt EinwegoperaPonen typedef sequence<octet> bytestream; oneway void send ( in bytestream data ); Keine out und inout Parameter, void Return ExcepPons Modellierung von Fehlern Beispiel exception Failed {}; exception RangeError { unsigned long supplied_val; unsigned long min_permitted_val; unisgned long max_permitted_val; } OperaPonen verwenden raises- Ausdruck: void set_value ( in unsigned long v ) raises( RangeError, Failed); Keine Ableitung bei ExcepPons erlaubt 5

16 AXribute Beispiel interface Thermostat { readonly attribute short istwert; attribute short sollwert; }; AXribute sind keine Data Member! Obiges ist äquivalent zu interface Thermostat { short get_istwert (); short get_sollwert (); void set_sollwert ( in short t ); } Module Au]au von Namensräumen module X { typedef short t; }; module Y { X::t v; }; EigenschaWen Module gleichen Namens können wieder geöffnet werden 6

17 Inheritance Interface- Inheritance interface Base { }; interface Child : Base { }; Inkl. Polymorphie wie in C++ u.ä. Ggf. implizite Ableitung vom Basistyp Object Leere Interfaces sind erlaubt Abgeleitete Interfaces können Typen, Konstanten und ExcepPons redefinieren Kein Overloading MulPple Inheritance erlaubt (ohne MehrdeuPgkeiten) IDL C++ Mapping Vergleichsweise direkt, da C++ mächpger ist Basic Types, Enums, Konstanten gleich (ggf. Namensergänzung) Strings werden char * Wrapperklassen z.b. für Strings (String_var) Aus Sequences werden spezifische Vektorklassen Module werden Namespaces Interface = abstrakte Klassen interface IF { long f (); } class IF : public virtual CORBA::Object { public: virtual CORBA::Long f () = 0; } 7

18 IDL Java GrundfunkPonalität über Package org.omg.* siehe auch C:\java\j2sdk1.4.1_01\docs\index.html Ansonsten Generierung der Java- Mappings vergleichbar C++ Aus einem IDL- Interface X wird Java- Interface X für Client (Signature Interface) Java- Interface X_OperaPons für Server (OperaPons Interface) Object Management Architecture (OMA) Application Objects Common Facilities Vertical Common Facilities Horizontal Common Facilities - User Interface - Information Management - Systems Management - Task Management Object Request Broker (ORB) Common Object Services - Naming - Externalization - Persistence - Events - Live Cycle - Transactions - Properties - Query - Concurrency - Relationships - Collections - Time - Security - Change - Trader - Licensing 8

19 Common Object Service SpecificaPon (COSS) GülPg für alle CORBA- konformen Plaxormen Naming ExternalisaPon Export von Zuständen in flache Dateien Persistenz DauerhaWe Objektzustände Events Weiterleitung asynchroner Ereignisse Einrichtung von Event Channels Lifecycle Unterstützung des Objekt- Lebenszyklus FunkPonen: Erzeugen, Löschen, Kopieren, Verlagern,... COSS contd. TransacPons 2 Phase- Commit- Protokoll Flache und geschachtelte TransakPonen ProperPes AXribut/Wert- Paare für Objekte speichern und abfragen Query SQL- Abfragen Concurrency Verwaltung und Realisierung von Locks Nutzung u.a. bei TransacPon Services RelaPonships Gruppierung von Objekten FunkPonen: Erzeugen, Traversieren,... 9

20 COSS contd. (2) CollecPons Time Security Change Management Trader Licensing? CORBA ORB Client Object Implementation Interface Repository Impl. Repository DII Dynamic Invocation Interface Client IDL Stubs ORB Interface Static Skeletons Dynamic Skeleton Invocation Object Adapter Object Request Broker Core 10

21 Methodenaufrufe SchniXstellenspezifikaPon über IDL ObjektorienPert Sprachbindungen für C, C++, Smalltalk, Java, Cobol,... Aufruf Zielobjekt Aufrufparameter Eventuell Rückgabewerte, ExcepPons AufrufsemanPk Synchroner AuWrag (vgl. RPC) Asynchroner AuWrag Asynchrone Meldung Klassisch stapsche SchniXstellen (Stubs) Dynamische SchniXstellen Object Adapter Steuert FunkPonen des Server- Objekts AkPvierung des Objekts bei eingehendem Request AuthenPfizierung des Aufrufers Zuordnung Objektreferenzen zu Instanzen Registrierung des Server- Objekts Lebensdauer des Server- Objekts Basic Object Adapter (BOA) Standardadapter Extremfall ORB und BOA Laufzeitbibliothek in der Anwendung Leistung mit Unterprogrammaufruf vergleichbar Neue Basisarchitektur für Betriebssysteme? 11

22 Object Adapter SchniXstelle zwischen Skeleton und ORB Verwaltet Objekte Instanziierung, Lebenszyklus, Binden an ImplemenPerung, etc. Nicht existent InakPv AkPv Bereit Nutzer erzeugt Nutzer akpviert Object Adapter verkörpert Object Adapter? Warum nicht im ORB? Austauschbare Komponente Ziel ORB möglichst klein halten µorb BOA Basic Object Adapter Single- Threaded (MulP- process) POA Portable Object Adapter Single- oder MulPthreaded DefiniPon von Objektgruppen etc. Ab CORBA 2.3 ersetzt der POA den BOA Skeletons sind Object Adapter spezifisch à Entscheidung bereits beim Kompilieren des IDL- Files! 12

23 ORB- 2- ORB- KommunikaPon Proprietäres ORB- Protokoll in CORBA 1.x Inter- ORB- Protokollstandard Server Object General Interoperability Protocol (GIOP) TCP/IP- basierte ImplemenPerung zwingend vorgeschrieben (IIOP) OpPonal: Environment Specific IOP (ESIOP) Z.B. DCE Common IOP (DCE CIOP) Half Bridge ORB 2 Inter-ORB-Bridge Client Object ORB 1 Half Bridge Objektreferenzen Schlüsselkonzept der Transparenz Zugriff auf Methoden x- >method(); Objektreferenzen über Adreßräume hinweg? Referenz auf Proxy- Objekt idenpsche SemanPk Referenzen sind global eindeupg! können als Argumente übergeben werden! sind interoperabel! à IOR 13

24 Interoperable Object Reference IOR Enthält IP und Port des zuständigen ORB ID des Object Adapters EindeuPge ID des Objekts Kann als String repräsenpert werden Woher erhält Client eine IOR? Einfachste Methode à File im gemeinsamen FS Namensdienste COSS Naming Abfragen der IOR via global eindeupgen Namen Referenz auf Naming- Service? IOR: c3a f f6e3a312e c d e e352e ad ff f f6e00696e c c CCM CORBA Component Model Bestandteil der IDL (CIDL) basic component (= EJB) extended component Sogenannte Ports definieren InterakPonsmöglichkeiten Facets: KomponentenfunkPonalität Receptables: Übernahme von Objektreferenzen Event Sources Event Sinks Komponenten haben ein Home und überhaupt sieht alles irgendwie nach EJB aus J CCM in der Praxis nicht weit verbreitet 14

25 RelaPonen zwischen OMG DefiniPon Languages OMG IDL 2.x ObjektorienPerte InterakPon Datentypen, Interfaces und WerXypen OMG IDL 3.0 KomponentenorienPerte InterakPon Component types, Homes und EvenXypen OMG PSDL Persistent state definipon [Abstract] storage types and homes OMG CIDL Component implementapon descrippon ComposiPons and segments OMG IDL 2.x extends OMG PSDL extends extends OMG IDL 3.0 extends OMG CIDL CCM User Roles Component designers Component clients ComposiPon designers component implementapon designers Component implementers Component packagers Component deployers Component end- users 15

26 Vom CORBA Component Design zum Packaging Component Designer OMG IDL, PSDL & CIDL Local server-side OMG IDL implements Component Executor Code Component Implementer OMG IDL PSDL & CIDL Compiler Stubs, Skeletons Programming Language Tools Client-side OMG IDL refers to XML Component Descriptor describes Binary Component Component Client Component Packager The CCM Big Picture designers implementer IDL/CIDL File User's Code Programming Language Tools Home Proper<es Component Proper<es IDL/CIDL Compiler Stubs, Skeletons Implementa<on Default Proper<es CORBA Component Package Component Descriptor User written file Compiler Generated files Packaging Tool packager CORBA Component Package sogpkg Descriptor Assembly Tool CORBA Component Package assembler Component Assembly Package Deployment Tool Assembly Descriptor deployer 16

27 Bemerkungen Standards, Standards, Standards, CORBA- Architektur inkl. IIOP: 1150 Seiten C++ Language Binding: 184 Seiten Java Language Binding: Seiten CORBA CCM: 434 Seiten War einmal technisch anspruchsvoll, aber andere Ansätze haben überholt Sinnvoll einsetzbar bei Verknüpfung von Legacy SoWware Verbreitet im Telekomumfeld Rückzieher Aus CORBA in KDE wurde DCOP CORBA paßt sich an ( und wird noch komplexer) Unterstützung und Anbindung an COM+ Unterstützung für WSDL und SOAP (.NET) Literatur Advanced CORBA Programming with C++ Michi Henning, Steve Vinoski Addision Wesley, 9. Auflage, 2004 Middleware für verteilte Systeme Arno Puder, Kay Römer Dpunkt Verlag, 1. Auflage

28 Komponenten OLE, COM, DCOM und COM+ MicrosoEs erster Komponentenansatz Verwickelter Enstehungsprozeß Noch immer kein allgemein definierter Standard DraE, As is Nur aus Gründen der RückwärtskompaSbilität bedeutungsvoll Hohe Verbreitung GUI- Bereich, Charts, Markt 1

29 Der Komponentenmarkt 2

30 3

31 COM+ Entwicklungsschri\e Clipboard 1987 Object Linking and Embedding (Compound Documents) In-Place Activation OLE 1992 OLE MS Distributed Transaction Coordinator 1996 OSF DCE RPC 1992 COM 1995 MS Transaction Server 1996 DCOM 1996 MS Message Queue Server 1997 COM NET Windows DNA DNA = Distributed internet ApplicaSon Architecture 3- Tier Ansatz Tools Clients Thin Clients... Rich Clients Firewall Databases Legacy Systems External Apps Presentation Business Logic System Services Data 4

32 Component Services COM Interface- based Programming Basic Component FaciliSes DCOM RemoSng Architecture Distributed Component Services COM+ Load Balancing In- memory Database Object Pooling Queued Components Event Model MTS TransacSon Services Resource Pooling Role- based Security AdministraSon Just- in- Sme AcSvaSon Basics Binärer Komponentenstandard ImplemenSerungssprache unbessmmt Komponente realisieren Interfaces Interface = Schni\stellenbeschreibung Abstrakte C++- Klasse mit virtuellen FunkSonen vtbl definiert Schni\stelle Minimal IUnknown: Elementarmethoden jeder Komponente IClassFactory: Komponentenerzeugung 5

33 IdenSfikaSon von Komponenten Interfaces besitzen eine GUID 128 Bit Zufallszahl z.b. IUnknown { C } Erzeugung über API: CoCreateGuid() Erzeugungstool: guidgen.exe Registry = Namensdienst guidgen.exe Erzeugung eigener GUIDs Hinreichend zufällig Bestandteile Aktuelles Datum Aktuelle Uhrzeit Fortlaufende Clock Sequence (persistent) Inkrementeller Zähler (hochfrequente Abfragen) MAC- Adresse der Netzkarte (geht aber auch ohne) 6

34 IUnknown interface IUnknown { typedef [unique] IUnknown *LPUNKOWN; HRESULT QueryInterface ( [in] REFIID riid, [out, iid_is(riid)] void **ppvobject ); ULONG AddRef (); } ULONG Release (); IClassFactory interface IClassFactory: IUnknown { HRESULT CreateInstance ( [in, unique] IUnknown *punkouter, [in] REFIID riid, [out, iid_is(riid)] void **ppvobject); } HRESULT LockServer ( [in] BOOL flock ); 7

35 ERSTE COM- SCHRITTE Beispiel Aufgabe Übertragung von n ganzen Zahlen Komponente bildet die Summe Schri\e Interface definieren Header- Dateien generieren Komponente implemenseren Client programmieren Registry- Eintrag 8

36 1. Interface USlity- Projekt in Visual Studio Interface Isum.idl: import "unknwn.idl"; [ object, uuid(1e10c200-e306-11d3-a557-b6eee489ca00) ] interface ISum : IUnknown { HRESULT AddElements ( [in] int nelem, [in, size_is(nelem)] int *elements, [out] int *sum ); }; 2. MIDL ausführen Mehrere Dateien werden generiert Bedeutung: C++- Version des Interfaces GUID- DefiniSonen Proxy- Stubs für enternte Server 9

37 3. Komponente implemenseren Jedes Interface der Komponente muß implemensert werden Ableitungen von den abstrakten Basisklassen Pure virtual funcsons implemenseren Virtuelle FunkSonen müssen immer wieder implemensert werden (Binärstandard) Sum.cpp 4. Client programmieren IniSalisierung des Komponentenzugriffs Iunknown- Interface über GUID erfragen Downcast zum gewünschten Interface Komponente benutzen Explizites Reference- CounSng beachten Client.cpp 10

38 5. Registry- Eintrag HKCR/CLSID/{GUID} REMOTING 11

39 Architekturen Inproc- Server Komponente als DLL im Client FunkSonsaufrufe Hohe Performance Server Komponente als EXE auf Client- Rechner Zugriff über Proxy- Objekte Surrogate: Spezifische DLL- Container COM- Laufzeitumgebung: MTS Remote Server Komponente auf enterntem Rechner (meist in lokalem MTS) Zugriff über Proxy- Objekte Marshalling, RPC ISum: Local Server Expliziter Aufruf eines lokalen Servers: hr = CoCreateInstance(CLSID_ISum, NULL, CLSCTX_LOCAL_SERVER, IID_IUnknown, (void **) &punknown); sta\ hr = CoCreateInstance(CLSID_ISum, NULL, CLSCTX_INPROC_SERVER, IID_IUnknown, (void **) &punknown); Es geht aber auch transparent Zuerst nach Inproc- Server schauen Dann nach lokalem Server Dann ggf. enternter Server 12

40 Wir verlassen die Prozeßgrenzen RPC = Remote Procedure Call Argumente in Nachricht verpacken Nachrichtenübertragung an den Server Auf Antwortnachricht warten Ergebnis an den Aufrufer zurückgeben Marshalling und Unmarshalling MIDL generiert die notwendigen RouSnen automassch Proxy = Client- Seite Stub = Server- Seite Verankerung der Proxy- und StubrouSnen in Registry Im Beispiel Relevante GUIDs für das Beispiel: Interface ISum Komponente CoSum (CLSID)

41 Zusätzlicher Schri\ ProxyStub- DLL erzeugen BenöSgt werden die von MIDL erzeugten Dateien: dlldata.c ISum_i.c ISum_p.c ProxyStub- DLL registrieren 14

42 Registryeinträge für lokalen Server und AppID 15

43 Mögliche AppID- Schlüssel AccessPermission AcSvateAtStorage AuthenScaSonLevel DllSurrogate LaunchPermission LocalService RemoteServerName RunAs ServiceParameter (bei gesetztem LocalService) dcomcnfg.exe 16

44 Security ACL innerhalb des Systems (vgl. Windows NT) Im Verteilungsfall in Anlehnung an OSF DCE AuthenSzitätsprüfung, wenn 0: Default (Systemdefinierter Standard 1-6) 1: None 2: Connect 3: Call 4: Packet 5: Packet Integrity: Test auf Paketveränderung 6: Packet Privacy: Inkl. Verschlüsselung AUTOMATION 17

45 Interfacevarianten StaSscher Zugriff Interface der gewünschten Komponente bekannt Zugriff über generierte Schni\stellenbeschreibung Überprüfungen zur Übersetzungszeit Dynamischer Zugriff Interfacebeschreibung liegt in Form einer Type Library vor Erfragen der Schni\stelle Dynamischer Methodenaufruf Keine Überprüfungen zur Übersetzungszeit Vgl. ReflecSon(Java), Dynamic Interfaces (Corba) Beim Zugriff über VB, VBA oder Java notwendig Dynamische Interfaces AutomaSon Schni\stelle IDispatch KombinaSon aus stasschem und dynamischem Interface möglich 18

46 IDispatch [ ] object, uuid( c ), pointer_default(unique) interface IDispatch : IUnknown { typedef [unique] IDispatch * LPDISPATCH; HRESULT GetTypeInfoCount( [out] UINT * pctinfo ); HRESULT GetTypeInfo( [in] UINT itinfo, [in] LCID lcid, [out] ITypeInfo ** pptinfo);... IDispatch(2) HRESULT GetIDsOfNames( [in] REFIID riid, [in, size_is(cnames)] LPOLESTR * rgsznames, [in] UINT cnames, [in] LCID lcid, [out, size_is(cnames)] DISPID * rgdispid ); [local] HRESULT Invoke( [in] DISPID dispidmember, [in] REFIID riid, [in] LCID lcid, [in] WORD wflags, [in, out] DISPPARAMS * pdispparams, [out] VARIANT * pvarresult, [out] EXCEPINFO * pexcepinfo, [out] UINT * puargerr ); 19

47 IDispatch(3) [call_as(invoke)] HRESULT RemoteInvoke( [in] DISPID dispidmember, [in] REFIID riid, [in] LCID lcid, [in] DWORD dwflags, [in] DISPPARAMS * pdispparams, [out] VARIANT * pvarresult, [out] EXCEPINFO * pexcepinfo, [out] UINT * pargerr, [in] UINT cvarref, [in, size_is(cvarref)] UINT * rgvarrefidx, [in, out, size_is(cvarref)] VARIANTARG * rgvarref ); } ACTIVE TEMPLATE LIBRARY 20

48 ATL AcSve Template Library Teil der MFC Basiert auf STL GrundfunkSonen ImplemenSerungen für IUnknown IClassFactory IDispatch Komponenten- registrierung DLL oder EXE möglich Die Basis um ein ATL- Objekt ergänzen 21

49 Wie heißt das Kind? Und was kann die Klasse? Methode hinzufügen 22

50 KONFIGURATION 23

51 Spielarten Manuell Eingriffe in die Registry (Brrrr) Selbstregistrierende Komponenten Vorgehensweise ATL ProblemaSk Deregistrierung Dcomcnfg: Weitergehende KonfiguraSon Veränderungen an der RemoSng- Struktur dcomcnfg 24

52 Literatur Guy Eddon, Henry Eddon Inside COM+ Base Services MicrosoE Press 1999 geplanter 2. Band Inside COM+ Component Services ist immer noch nicht erschienen J 25

53 Intermezzo I Kapitel 4 Komponententechnologien Was ist eine Komponente? (c) Peter Sturm, Universität Trier 1

54 Größe? Form? (c) Peter Sturm, Universität Trier 2

55 Klare Interfaces?! Cold Space Igloos Gypsy shadowness.com Jeder versteht Jeden! (c) Peter Sturm, Universität Trier 3

56 Klassifizierungskriterien Interface- Beschreibung Festlegen auf kommunizierbare Datentypen Anbinden von Client- und Komponentencode Sich finden (Namensproblematik) Grad der Unabhängigkeit Interface- Beschreibung Eigene IDL Microsoft IDL (MIDL) im Fall vom COM CORBA ebenfalls eigene IDL Verbesserungsvorschläge? (c) Peter Sturm, Universität Trier 4

57 Kommunizierbare Datentypen Spezielle IDL Nur recht elementare Typen (MIDL, hohes Alter) Komplex und unübersichtlich (CORBA) Verbesserungsvorschläge Interface Description Code- Anbindung IDL Compiler Server Stub Client Stub.c.c RPC- Erbe sichtbar! Spezielle IDL- Compiler generieren Proxies.c Compiler (e.g. C++).c Vorteil Automatismen Nachteil Mapping auf Zielsprache Server Client Verbesserungsvorschläge? (c) Peter Sturm, Universität Trier 5

58 Sich finden Asymmetrie am Anfang Client übernimmt Initiative Server / Service / Komponente braucht Namen Namensauflösung zu Orts- und Verbindungsinformation Unabhängigkeit Heterogene Ansätze Hohe Unabhängigkeit Kleinster gemeinsamer Nenner Homogene Ansätze Deutlich flexibler und mächtiger Höhere Abstraktionen Für Entwickler besser zu verstehen Homogener Sprachansatz: Java Homogenes Typsystem:.NET (c) Peter Sturm, Universität Trier 6

59 Shopping OO- RPC (c) Peter Sturm, Universität Trier 7

60 Aus RPC wird RMI Zusätzlicher Objektbezug wird deutlicher Siegeszug virtueller Maschinen Java- Ökosystem.NET Framework JAVA RMI (c) Peter Sturm, Universität Trier 8

61 Java RMI Remote Method Invocation Java- basierte OO- Variante eines RPC Objekte inkl. Code können ausgetauscht werden Vorteil einer homogenen Sprachumgebung Sicherheitsproblematik Function Shipping Direkte Unterstützung im JDK JDK nutzt Reflection für die Generierung der Proxies Architektur RMI RMI Client RMI RMI rmiregistry RMI Server URL Protocol Web Server URL Protocol Web Server (c) Peter Sturm, Universität Trier 9

62 ... ein Interface Am Anfang war... package syssoft.rmi_example; import java.rmi.remote; import java.rmi.remoteexception; public interface Compute extends Remote { int Add ( int x, int y ) throws RemoteException; int Sub ( int x, int y ) throws RemoteException; } Ableitung von Marker- Interface Remote (leeres Interface) Erkennen RMI- zugänglicher Interfaces über Reflection Remote- Methoden werfen RemoteException Zugeständnis an mögliche Fehlerfälle in verteilten Systemen package syssoft.rmi_example.server; import java.rmi.registry.locateregistry; import java.rmi.registry.registry; import java.rmi.server.unicastremoteobject; Server import syssoft.rmi_example.*; public class Server implements Compute { } public Server() { super(); } public int Add ( int x, int y ) { return x+y; } public static void main(string[] args) { if (System.getSecurityManager() == null) { System.setSecurityManager(new SecurityManager()); } try { String name = "SyssoftCompute"; Compute engine = new Server(); Compute stub = (Compute) UnicastRemoteObject.exportObject(engine,0); Registry registry = LocateRegistry.getRegistry(); registry.rebind(name, stub); System.out.println("ComputeEngine bound"); } catch (Exception e) { System.err.println("ComputeEngine exception:"); e.printstacktrace(); } } (c) Peter Sturm, Universität Trier 10

63 package syssoft.rmi_example.client; import java.rmi.registry.locateregistry; import java.rmi.registry.registry; Client import syssoft.rmi_example.*; public class Client { public static void main(string[] args) { if (System.getSecurityManager() == null) { System.setSecurityManager(new SecurityManager()); } try { String name = "SyssoftCompute"; Registry registry = LocateRegistry.getRegistry(args[0]); Compute comp = (Compute) registry.lookup(name); } } int result = comp.add(21, 21); System.out.println(result); } catch (Exception e) { System.err.println("SyssoftCompute exception:"); e.printstacktrace(); } # Compiling, packaging, and distributing the interface javac syssoft/rmi_example/compute.java jar cvf run/compute.jar syssoft/rmi_example/compute.class cp run/compute.jar ~peter/sites 42 # Preparing the server javac - cp run/compute.jar syssoft/rmi_example/server/server.java # Preparing the client javac - cp run/compute.jar syssoft/rmi_example/client/client.java # Starting RMI registry # rmiregistry & # Running server java - cp.:run/compute.jar - Djava.rmi.server.codebase= Compute.jar - Djava.rmi.server.hostname=localhost - Djava.security.policy=run/server.policy syssoft.rmi_example.server.server & sleep 10 # Running client java - cp.:run/compute.jar - Djava.rmi.server.codebase= - Djava.security.policy=run/client.policy syssoft.rmi_example.client.client localhost (c) Peter Sturm, Universität Trier 11

64 .NET Remoting Interface (c) Peter Sturm, Universität Trier 12

65 Implementierung Server (c) Peter Sturm, Universität Trier 13

66 Client (c) Peter Sturm, Universität Trier 14

67 Komponenten Enterprise Java Beans Übersicht Java Basics RTTI und ReflecHon AnnotaHons Beans EJBs 1

68 RTTI UND REFLECTION ReflekHve Programmierung Run- Time Type InformaHon Zur Übersetzungszeit ReflecHon API Zur Laufzeit 2

69 Beispiel Generierung einer XML- Beschreibung für eine beshmmte Java- Klasse Zentrale Anlaufstelle ist die Klasse Class getdeclaredconstructors liefert Array aller definierten Konstruktoren unabhängig von der Sichtbarkeit getconstructors liefert Array der sichtbaren Konstruktoren getdeclaredfields und getfields getdeclaredmethods und getmethods... Zugriff auf ALLE sprach- relevanten Eigenscha[en eines Typs möglich package syssoft.reflection; import java.io.*; import java.lang.reflect.*; Class TalkAbout public class TalkAbout { private Class c; public TalkAbout ( Class candidate ) { c = candidate; } public void print ( PrintStream out ) { out.println("<?xml version=\"1.0\" encoding=\"utf- 8\">"); out.println("<class name=\"" + c.getcanonicalname() + "\">"); printconstructors(c.getdeclaredconstructors(),out); printdeclaredfields(c.getdeclaredfields(),out); out.println("</class>"); } private void printconstructors ( Constructor ctors[], PrintStream out ) { for (Constructor ctor : ctors ) { out.println("\t<constructor name=\"" + ctor.getname() + "\" modifiers=\"" + Modifier.toString(ctor.getModifiers()) + "\" >"); printargumenttypes(ctor.getparametertypes(),out); out.println("\t</constructor>"); } } private void printdeclaredfields ( Field fields[], PrintStream out ) { for (Field field : fields ) { out.println("\t<field name=\"" + field.getname() + "\" type=\"" + field.gettype().tostring() + "\" modifiers=\"" + Modifier.toString(field.getModifiers()) + "\" />"); } } private void printargumenttypes ( Class argts[], PrintStream out ) { for (Class arg : argts) { out.println("\t\t<type name=\"" + arg.getname() + "\" />"); } } 3