Docsity
Docsity
Prepare for your exams
Prepare for your exams

Study with the several resources on Docsity

Earn points to download
Earn points to download

Earn points by helping other students or get them with a premium plan

Guidelines and tips
Guidelines and tips
Sell on Docsity
Sell on Docsity
Docsity AI
Docsity AI
Log inSign up

Prepare for your exams

Study with the several resources on Docsity

Find documents

Prepare for your exams with the study notes shared by other students like you on Docsity

Search for your university

Find the specific documents for your university's exams

Docsity AINEW

Summarize your documents, ask them questions, convert them into quizzes and concept maps

Explore questions

Clear up your doubts by reading the answers to questions asked by your fellow students

Earn points to download

Earn points by helping other students or get them with a premium plan

Share documents
download point icon20 Points

For each uploaded document

Answer questions
download point icon5 Points

For each given answer (max 1 per day)

All the ways to get free points
Get points immediately

Choose a premium plan with all the points you need

Study Opportunities

Choose your next study program

Get in touch with the best universities in the world. Search through thousands of universities and official partners

Community

Ask the community

Ask the community for help and clear up your study doubts

Free resources

Our save-the-student-ebooks!

Download our free guides on studying techniques, anxiety management strategies, and thesis advice from Docsity tutors

Component Object Model (COM) and Interfaces - Prof. William Pugh, Study notes of Programming Languages

University of MarylandProgramming Languages
Prof. William Pugh

The component object model (com) is a language and operating system independent architecture for creating, deploying, and upgrading software components. It uses interfaces to define interactions between components, allowing for versioning and avoiding name clashes. Com supports multiple interfaces per component and uses reference counting for managing object lifetimes. The basics of com, interfaces, and related concepts such as hresult, queryinterface, and smart pointers.

Typology: Study notes

Pre 2010

Uploaded on 07/30/2009

koofers-user-icm-1
koofers-user-icm-1 🇺🇸

10 documents

1 / 10

Toggle sidebar

This page cannot be seen from the preview

Don't miss anything!

bg1
1
COM - Component Object Model
Component Object Model
•Language independent
•OS independent (in theory)
•Way to allow components to be designed,
deployed, upgraded
– Need to interact with code written after you
were deployed
Immutable interfaces
•Interact through interfaces
–No direct access to fields
– Interfaces must never be changed
– Interfaces assigned a GUID
• avoid name clashes
• allow versioning by assigning a new GUID
COM
•A binary compatibility standard
–interface pointers
IStream Method 1
Method 2
Method 3
Method 4
Multiple interfaces
•Components can implement multiple
interfaces
•Different interfaces may correspond to
different entry points to object
–C++ multiple inheritance
– adaptors
Multiple interfaces
IStream Method 1
Method 2
Method 3
Method 4
IPrint Method 1
Method 2
Method 3
Method 4
pf3
pf4
pf5
pf8
pf9
pfa

Partial preview of the text

Download Component Object Model (COM) and Interfaces - Prof. William Pugh and more Study notes Programming Languages in PDF only on Docsity!

COM - Component Object Model

Component Object Model

  • Language independent
  • OS independent (in theory)
  • Way to allow components to be designed, deployed, upgraded - Need to interact with code written after you were deployed

Immutable interfaces

  • Interact through interfaces
    • No direct access to fields
    • Interfaces must never be changed
    • Interfaces assigned a GUID
      • avoid name clashes
      • allow versioning by assigning a new GUID

COM

  • A binary compatibility standard
    • interface pointers

IStream (^) Method 1 Method 2 Method 3 Method 4

Multiple interfaces

  • Components can implement multiple interfaces
  • Different interfaces may correspond to different entry points to object - C++ multiple inheritance - adaptors

Multiple interfaces

IStream (^) Method 1 Method 2 Method 3 Method 4 IPrint (^) Method 1 Method 2 Method 3 Method 4

Interfaces in COM

  • Similar to interfaces in Java
    • no variables
  • Interfaces have a 128 bit Unique ID
    • immutable, never changed, no collisions
  • In writing COM code, always use interfaces pointers/references

Reference counting

  • COM objects are reference counted
    • each object keeps track of the number of pointers to it
  • When ref count goes to zero, element deletes itself
  • Cycles can be a problem
  • Remembering where to put all increments and decrements can be a problem

Each interface counted separately

  • Each entry point/interface to a COM object is ref counted separately - allows an adaptor to be garbage collected

IUnknown

  • All COM interfaces must extend IUnknown
    • HRESULT QueryInterface(const IID& iid, void ** ppv)
    • ULONG AddRef() // inc ref count
    • ULONG Release() // dec ref count

Query interface

  • Like a C++ dynamic cast
    • Do you support this interface?
    • If so, give me back a pointer of that kind
      • incrementing the ref count for that interface
    • Else, signal failure

QueryInterface rules

  • You always get the same IUnknown
  • You can get an interface if you got it before
  • You can get the interface you have
  • You can get back to where you started

Implementing QueryInterface

STDMETHODIMP QueryInterface(const IID& iid, void **ppv) { if (iid == IID_IUnknown || iid == IID_IFoo) ppv = static_cast<Foo>(this); else if (iid == IID_IBar) *ppv = static_cast<Bar *>(this); else { *ppv = null; return E_NOINTERFACE; } reinterpret_cast< IUnknown >(ppv)->AddRef(); return S_OK; }

Things to note

  • If you support 100 interfaces, cascaded if statements are going to get expensive - can’t use case statements (UIID’s aren’t ints) - could use custom hashtable
  • Separate ref counts
    • could put call to AddRef in each branch
    • would eliminate reinterprete_cast
    • but would increase code size

I want everything

  • Why can’t I ask
    • what is the list of all of the interfaces you support?
  • What would you do with the list of all interfaces a component supports?
  • Can use component categories

Component categories

  • Assigned a GUID
  • Corresponds to a set of interfaces
    • If a component is registered as members of a category
    • instances of that component support all of those interfaces
    • will still need to use QueryInterface to move between interfaces

Categories in Java

  • Just define a Mega-interface
    • An interface that extends all of the interfaces in the category
    • Ask if class/component implements that
    • Can use reference of Megainterface type to invoke all methods from any interface in category
    • No casting needed

Component reuse

  • How to reuse components?
    • Base class (implementation inheritance)
    • Containment (have as a member)
      • Delegation - Some methods get directly forwarded
      • Adapter - Some methods get translated
    • Aggregation

Aggregation

  • Say I have a component Bar
    • which uses a component Foo
  • Foo implements the IFoo interface
  • Bar also implements the IFoo interface
    • by handling things off to its Foo
  • Could handle by delegation
    • but that adds an additional level of indirection

Using Aggregation

  • When someone asks a Bar for its IFoo interface - just hand them a reference to your Foo - handles all IFoo function calls
  • But what if you invoke QueryInterface on the IFoo reference and ask for an IBar interface?

Bar

Delegation/Forwarding

Foo

IUnknown

IFoo

IUnknown

IBar

inner

Bar

Aggregation

Foo

IUnknown

IFoo^ outer

IUnknown

IBar

inner

Supporting aggregation

  • You must be able to be told that you have an outer component
  • Calls to QueryInterface should be routed to your outer component
  • Reference counts are a little tricky
    • cycle could prevent stuff from being collected

Automation/IDispatch interfaces

  • Can ask a interface which methods it supports, and invoke those methods
  • Visiual Basic example Dim Bullwinkle As Object Set Bullwinkle = CreateObject(“TalkingMoose”) Bullwinkle.PullFromHat 1, “Rabbit”
  • Look for method “PullFromHat”
    • guess that it takes a LONG and a BSTR

Marshalling/Serialization

  • COM allows objects to be marshalled
    • same as Serialization in Java
  • Need to give extra data in IDL file
    • IDL = interface definition language

Example IDL for Marshalling

  • interface IY : IUnknown { HRESULT fCount([out] int * sizeArray); HRESULT fArrayIn([in] int sizeIn, [in, size_is(sizeIn) int arrayIn[]); HRESULT fArrayOut([in] int maxSize, [in, size_is(maxSize)] int arrayOut[], [out] int * sizeOut); }

COM Threads

  • Free threads
    • similar to Java threads, must use explicit synchronization
  • Apartment threads
    • COM objects can be grouped into an apartment
    • Each apartment has a designated thread

Apartment threads

  • Single thread for entire apartment
  • Call from a free thread, or from a different apartment, are marshalled - like a RMI call - Apartment thread must have a message loop to receive and dispatch calls

Apartment threads

  • Simple synchronization model
    • backwards compatible with WIN32?
  • Similar to having a single synchronization object for an entire set of components
  • Still have potential problems such as deadlock

Servers in COM

  • COM objects don’t have to be local
    • can make a remote call (like Java RMI)
  • A COM object can be
    • in process
    • in process, different apartment
    • same machine, separate process
    • different machine

Advantages of COM servers

  • Seg fault only kills one process
  • OS services can be provided as COM services

Java Beans

  • A Java-based Software component technology - not the only way to do components in Java
  • A Java Bean is a reusable software component that can be manipulated visually in a builder tool

Visual builder tools

  • No, not a text editor
  • Used to combine and customize existing components, not write from scratch
  • What can be customized?
  • What can be attached?

Design patterns

  • Could allow you to view and change any fields of a component - Doable using reflection - But a bad idea - could make inconsistent changes, change fields that aren’t a part of public interface
  • Set of design patterns to define how to customize Java Beans

Design patterns

  • Very hot buzz word
    • some actual substance
  • A common/standard way of doing something - can’t be captured by standard forms of OO reuse

Why reuse design patterns?

  • Sometimes, because the pattern is a really cool and wonderful idea
  • But mainly, so that when another programmer looks at your code - They will instantly see what idea you are trying to implement

Event Adapters

  • Easy to construct event adapters
    • For example, an adapter that receives temperatureChanged events, and generates temperatureIncreased and temperatureDecreasedEvents

Bound properties

  • Can set things up so that changes to bean property are indicated by an event - events are a subtype of java.beans.PropertyChangeEvent - Listeners implement PropertyChangeListener - One Listener for all change events on the bean - may optionally support listeners for specific properties

Constrained Properties

  • Listeners can veto property changes
    • Listener throws PropertyVetoException
    • set method throws …

Builder tools

  • Example: Sun’s BeanBox
  • Can create instances of beans
  • Modify their properties
    • Default mechanism
    • Special code for manipulating bean
  • Attach Listeners, create adapters, ...

Serialization and Persistence

  • OK, so we can manipulate Java Beans in a builder tool
  • Doesn’t help if we can’t distribute the beans
  • Serialize the beans
  • application loads beans from Serialized form