Overwiew COM

HA: 10 Fragen – Was ist eine COM-Komponente? DLL Factory Factory Pattern Interface CLSID Query Interface Aggregation Inner class 1.) Static View – Classical (h-File in C++) 2.) Dynamic View – Communication  OO-Server mit Events  EVENT 3.) Event-Data-System  DATA (werden im Blackboard Pattern angelegt) HA: 10 Fragen – Was ist eine COM-Komponente?

(D)COM = Distributed Component Object Model Inhalte: Basisinterface, Extension Interface Pattern, Reference Counting, Broker Pattern, Factory Pattern COMponent: - box mit Inteface (Design by contract)  Interfaces können hinzugefügt werden  box-spoon-plot - abgeschlossene Funkionalität - Modul - entspricht einer Klasse, Reuseability (= Wiederverwendbarkeit) - Implementierung austauschbar, loading on demand - wie Klassenbibliothek nutzbar - remote nutzbar - load balancing - Design for Integration - unabhängig von Programmiersprache - Interface Description Language (idl)  CORBA, DCOM Softwarebus: CORBA = Common Request Broker Architecture COM = Objectoriented Middleware + Synchrone Communication (+ Asynchrone Communication) Softwarebus

BasisInterface IUnknown: interface IUnknown { BasisInterface IUnknown: interface IUnknown { virtual HRESULT __stdcall QueryInterface (const IID iid, void **ppr) = 0; virtual ULONG__stdcall AddRef () = 0; virtual ULONG__stdcall Release () = 0; } Bemerkung: a.) #define interface struct (class mit public members) b.) __stdcall (Pascal Aufrufkonvention, Methode räumt Stack vor Return auf; normalerweise räumt der Caller den Stack auf) c.) #define STD Method CALL TYPE __stdcall d.) HRESULT 32-Bit-Wert (Bit 1= Severity, Bit 2-16=Facility, Bit 17-32= Return Code Interface-Implementierung in C++: interface IX { public: virtual void Fx1()=0; virtual void Fx2()=0; } interface IY { public: virtual void Fy1()=0; virtual void Fy2()=0; } --------- class CA : public IX, IY { virtual void Fx1() {...} Implementierung (h, cpp) .... }  Trennung Interface und Implementierung  Schnittstellenvererbung, keine Implementierungsvererbung  Vererbung  vtable wird vom Compiler generiert Inheritance – Implementierungsdetail  ATL nested class (Aggregation, MFC)

Broker-Pattern (Sequenzdiagramm): IX Virtual  virtual function table: pIX vtbl pointer Zweistufiger Mechanismus: 1.) look up in vtable (Funktionszeiger) 2.) function call mit Funktionszeiger IDispatch  vtable ausimplementieren für z.B. VBasic Fx1 &Fx1 &Fx2 Fx2 Enthält Zeiger auf Memberfunktionen Broker-Pattern (Sequenzdiagramm): Client ClientProxy Broker Stub(ServerProxy) Server Call Server Send Request Pack Data Find Server Find Server Channel Call Service UnPack Data Run_Service Pack Data Return UnPack Data Result

IX IY IX IY CX CY CX CY Query Interface: Marshaling (PackData): Datenstruktur  „Bytewurst“ Unmarshaling (UnpackData): Daten werden wieder entpackt Parameter-Classification: in  out  inout  sind Bestandteil von idl Query Interface: CA fachliche Klasse vtable Server Query Interface AddRef Release Fx Query Interface AddRef Release Fx Client Vtbl-Pointer pIx HRESULT QueryInterface (const IID &iid, void ** ppv) IUnknown IX IX IY IX IY IY CX CY CX CY IUnknown IUnknown Componente Componente

Unterstützt Interface ein Interface IX? HRESULT QueryInterface (IID, IDPtr) - 32 Bit - S_OK - E_NOINTERFACE - Makro: SUCEEDED, FAILED Bsp.: void foo(IUnknown *pI) { Ix * pIx=NULL; HRESULT hr=pI QueryInterface(IID_IX, (void**)&pIX); if(SUCEEDED(hr)) { pIx  Fx(); } } IUnknown Implementierung für QueryInterface, Add Ref, Release Class Factory Implementierung für QueryInterface, Add Ref, Release Class Factory Implementierung für fachliche Klasse IX Unterstützt Interface ein Interface IX? ja nein hr S_OK *ppv != 0 hr E_NOINTERFACE *ppv = 0

Implementierung von Query Interface: IUnknown IUnknown IUnknown Query Interface AddRef Release Query Interface AddRef Release ULONG Ix Iy Bemerkung: Cast „über nächste Nachbarn“ *ppv = static_cast <IUnknown*>(static_cast <Ix*>(this)) (nicht eindeutig als Mehrfachvererbung) CA :public: private  private protected  public public  public a.) Query Interface b.) vTable-Mechanismus IUnknown Interface IX : IUnknown { /*...*/ } Interface IY : IUnknown { /*...*/ } class CA: public IX, public IY { /*...*/ } IX IY

HRESULT __stdcall CA::QueryInterface (const IID &iid, (void. ) ppv); { HRESULT __stdcall CA::QueryInterface (const IID &iid, (void **) ppv); { if(iid == IID_IUnknown) { *ppv = static_cast<Ix*>(this); } else if(iid == IID_IX) { *ppv = static_cast<Ix*>(this); } else if(iid == IID_IY) { *ppv = static_cast<Iy*>(this); } else { *ppv = NULL; return E_NOINTERFACE; } static_cast<IUnknown*>(*ppv)AddRef(); return S_OK; } a.) if-cascades substitution by hash tables b.) Code: - Client wünscht Interface Ix, Iy, IUnknown - Client wünscht anderes Interface - Reference Counting - Casting ändert Wert des ppv-Zeigers Virtual Function Table QueryInterface AddRef Release Fx CA:this IX vtblpointer IY vtblpointer Instance Data (IX*)CA:this QueryInterface AddRef Release Fx (IY*)CA:this

Eigenschaften von Query Interface: 1.) QueryInterface ist symmetrisch pIx  QI(IID_Y, ...)  pIy : QI(IX)IY pIy  QI(IID_X, ...)  pIx : QI(QI(IX)IX)IX 2.) QueryInterface ist transitiv pIx  QI(IID_Y, ...)  pIy pIy  QI(IID_Z, ...)  pIz 3.) QueryInterface ist reflexiv pIx  QI(IID_X, ...)  pIx ÜA: Identität des Interface-Zeigers Frage: Wann gehören pIx und pIy zur gleichen Komponente? Wie kann man rausfinden, ob zwei Interface-Zeiger zur gleichen Komponente gehören? IUnknown IX IY IZ

Reference Counting:  Lifetime Control Regeln: 1.) Call AddRef before Return  Bsp.: QI, CreateInstance 2.) Call Release when you are done 3.) Call AddRef after assignment Garbage Collection  delete this mit Bedingung m_mRef=0

Klassifikation von Klassen: 1.) Nicht-modale Klassen Klassen besitzen keine Beschränkung hinsichtlich der Aufrufreihenfolge ihrer Methoden. Bsp.: class DateTime set(), get(), compareEqual(), ... 2.) Unimodale Klassen Beschränkung der Aufrufreihenfolge (Design by Contract) ihrer Methoden, aber unabhängig vom Zustand (Attributinhalt). Bsp.: class Ampel rotesLichtEin(), gelbesLichtEin(),... 3.) Quasimodale Klassen Beschränkung der Aufrufreihenfolge ihrer Methoden ausschließlich basierend auf den aktuellen (State Change in der State Chart) Zustand. Bsp.: class Stapel push()  wenn der Stapel gefüllt kann nichts mehr draufgelegt werden 4.) Modale Klassen Beschränkung der Aufrufreihenfolge (State Change in der State Chart) hinsichtlich ihrer Methode und ihrer Zustände (Attributbelegung). Attribute Methode Stateless Objects und State Objects Unimodal call sequence of methods from design by contract Quasimodal State Chart Bind Recovery Find Recovery