ms_com1_2

7/30/2019 MS_COM1_2

1/12

Chapter 1: Introduction to COMThis chapter provides an overview of current software development and describes why some of thesetechniques may be useful, but fall short of providing the necessary component communication, versionmaintenance, and location transparency. The Component Object Model (COM) addresses some of these

constraints.

At the end of this chapter, you will better understand how to use COM to develop component software.Although this material is presented from a C++ and MicrosoftWindowsperspective, the basic principlesare true for the design of large, distributed, object-oriented systems.

ObjectivesAfter completing this chapter, you will be able to:

List and explain the problems that confront component software developers today.

List and explain attempted solutions to traditional component software development.

Explain the drawbacks of various solutions to component software development.

List the solutions that COM provides for component software development problems.

7/30/2019 MS_COM1_2

2/12

2 Chapter 1: Introduction to COM

Notes

Traditional Software DevelopmentSoftware designers and developers are faced with a number of challenges. Customers demand high-quality software with large feature sets, but the competitive environments in which software developmentoccurs are forcing increasingly shorter delivery times.

In this section, you will look at the traditional approach to software development and its associated

problems.

This section includes the following topics:

The Traditional Approach

Problems with the Traditional Approach

The Traditional ApproachOne solution to the challenges of software development is to separate the functionality of a large,monolithic application into smaller components.

Traditionally, developers have used libraries of functions as a way of accessing the functionality of acomponent. These libraries implement functions through an application programming interface (API).

Reuse of these functions is as simple as learning the semantics of the API and linking to the library.

The following illustration shows how you can use a component from any vendor by calling it through astandardized API:

An example of a standardized API is the Microsoft Open Database Connectivity (ODBC) API. Manysoftware vendors have implemented the ODBC API in their database drivers. Even with fairly widespreadadoption of the ODBC API, interoperability is still challenging because implementation differences canoccur from one vendor to another.

7/30/2019 MS_COM1_2

3/12

Chapter 1: Introduction to COM 3

Notes

Problems with the Traditional ApproachThe traditional approach of using APIs to access the functionality of a software component has itsdrawbacks. These drawbacks include evolution of the API, versioning, component communication, and theimplementation language.

Evolution of the APIThe evolution of an API is a problem for both the API creator and software vendors who want to add valueby extending an API.

Any changes made to an API by its creator can potentially break existing applications. Changes made toextend the API can result in inconsistent implementations.

VersioningAdvertising and maintaining different versions of the API can also be problematic. As an API creator, howcan you force a developer to check for the correct version?

Component CommunicationEnabling components to communicate with each other is challenging, especially if different developershave created the components.

Implementation LanguageThe programming language you use for creating components greatly impacts how the components willcommunicate through an API. For example, if you create components in C++ and export classes from alibrary, it can be challenging to use C or Visual Basicto create the client of the component.

Problems of Traditional Software DevelopmentProgrammers have used a variety of object-oriented programming techniques to try to solve problemsassociated with traditional software development.

In this section, you will examine the problems associated with using object-oriented programmingtechniques for developing components, and learn about a specific object-oriented programming solution tothese problems.


Object-Oriented Techniques

Limitations of Using C++

Example of Converting a Class to a Component

Component Implementation

7/30/2019 MS_COM1_2

4/12


Notes

Object-Oriented TechniquesOne of the first attempts of developing components was to apply object-oriented techniques.

Object-oriented analysis and design enables application designers to approach software developmentfrom a higher level of abstraction.

Viewing an application as a collection of objects (which have attributes and behaviors) that interact witheach other enables a software developer to more effectively model the problem and create a correctsolution. An object design is also more comprehensible than a series of algorithms.

Object-oriented design, on its own, is not sufficient to handle the complexity of modern softwaredevelopment.

Limitations of Using C++When using C++ as the language for applying object-oriented techniques to your component developmentefforts, you should consider the following in-process and out-of-process server issues.

In-Process Server IssuesWhen developing an in-process server for component use, consider the following:

When adding methods or data to a base class, the size of the derived class data or the VTBL layoutchanges. You have to recompile all classes below the base class.

When deriving from a base class, there is no way to distinguish why or how that base class is beingused. Perhaps the implementation is needed by the derived class. Perhaps the base class containsonly pure virtual functions, in which case it's the interface of the base class, not its implementation, thatis of importance to the derived class. C++ does not provide an easy way to make this distinction clear,and can result in the semantic integrity of the base class being corrupted.

Out-of-Process Server IssuesWhen developing an out-of-process server for component use, consider the following:

As you debug and improve a component, you cannot guarantee the size of the C++ objects that

constitute the component. A client may be dependent on a particular component size. The client of theclass and the library implementing the class can thus become out of synch.

Even if the size of the class has not changed, adding virtual functions to a class can cause the clients ofnewer versions of a class to stop if they use an older version of the class.

In C++, encapsulation is by convention and cannot be enforced, so there isn't a good way to guaranteethe integrity of a class. Bugs in an out-of-process server are almost impossible to track down.

7/30/2019 MS_COM1_2

5/12


Notes

Example of Converting a Class to a ComponentTo illustrate how to rewrite a class for use as a component that was originally created with object-orientedtechniques, consider this example of a string class:

class String {

public:

short getLength();private:

char data[256];

} ;

An instance of this version will either waste space, or be inadequate for all strings. You then might modifyit like this:

class String {

public:

short getLength();

private:

char *data;

short len;

} ;

Any clients that are dependent on the size of the class will be broken by this modification and would needto be recompiled. Besides changing its data members, there are other changes you might make to theclass that can affect an object's size. For example, you might add a virtual function that translates thestring into another language, like this:

class String {

public:

virtual String Translate(short localeID);

short getLength();

private:

char *data;

short len;

} ;

Now that the class has a VTBL, each object must have a VPTR, which adds four bytes to the size. Again,any clients that are dependent on a particular size will be broken.

In another attempt to improve the string class, you can isolate clients from any modifications to dataimplementation. You can then move the data portion of the string class to its own class. Finally, you canadd a pointer to that class, making it the sole data member of the string class. It will look like this:

class String {

public:

virtual String Translate(short localeID);

short getLength();

private:

StringImpl *pImplData;

} ;

7/30/2019 MS_COM1_2

6/12


Notes

This version of the class is much better; however, it still gives clients an object with a specific size. Withthis version, you are close to providing a string class with only functions.

In a final attempt at improving the string class, you make all functions pure virtual. You are simplypublishing an interface for a string class that looks like this:

class String {

public:

virtual String Translate(short localeID) = 0;

virtual short getLength() = 0;

} ;

All of the virtual functions from our string class example are pure, making the class abstract. Currently,clients are not dependent on the size of an object or layout. A client will have only an interface pointer; thedata representation is completely hidden. The creation of objects in this manner is a major concept ofCOM.

Component ImplementationTo create an instance of an abstract class, you define a private implementation hierarchy whose classesare derived from the published abstract classes.

Creating an Instance of an Abstract ClassBecause you do not want these implementation classes to be visible outside of the component, you canprovide a function that creates instances of the derived classes, but returns a pointer to the base class, asshown in the following example code:

class String // What the world sees

{

public:



};

class StringImp : public String // Inside the library

{

public:

virtual String Translate(short localeID) {}

virtual short getLength() {}

};

String * CreateString() // Exported from the library

{

return new StringImp;

}

7/30/2019 MS_COM1_2

7/12


Notes

A client obtains a pointer to a String object by calling the CreateString function, as shown in the followingexample code:

void ClientFunction()

{

String * pString;

pString = CreateString();

short length = pString->getLength();...

}

The client never sees the StringImp class, nor does the client call the new operator. The client is awareonly of the VTBL of the String interface.

Interface EvolutionThis model for deriving from abstract classes can be used for multiple levels of derivation to change aninterface without changing the base class.

To add new functionality to an interface, you derive new classes from the abstract hierarchy. You can thenuse dynamic_cast to allow for safe casting up and down the derivation tree.

The following example code shows how the String2 class can change an interface:

class String2 : public String

{

public:



virtual void ConvertToUpperCase() = 0;

};

class StringImp : public String2

{

public:

virtual String Translate(short localeID) {}

virtual short getLength() {}virtual void ConvertToUpperCase() {}

};

7/30/2019 MS_COM1_2

8/12


Notes

An existing client can continue to use this new object because the client only knows about the methods ofthe String class, which are still supported. Using the dynamic_cast operator, a new client can determineif a method is supported, as shown in the following example code:

void NewClientFunction()

{

String * pString;

pString = CreateString();short length = pString->getLength();

// Everything is the same as older client up to this point

// Verify new server capabilities

String2 *pString2;

pString2 = dynamic_cast pString;

if (NULL != pString2)

pString2->ConvertToUpperCase();

...

}

The new client also works with an older server. The new client determines whether the server supports theadded interface before calling a method of that new interface.

Ultimately, what you are doing is exporting tables of pointers to functions, or VTBLs.

Software Development with COMCOM consists of two key elements: a specification that defines a programming protocol, and a set ofservices that provides the functions for creating and exposing objects.

In this section, you will learn how COM solves some of the problems associated with using object-orientedprogramming techniques when developing components.


COM Defined

The Goals of COM

COM and ActiveX

COM DefinedCOM is a standard (or model) for the interaction of binary objects. An important feature of COM is thatobjects are precompiled, which means that the implementation language is irrelevant. If you includetokenized code (for example, the P-Code in Microsoft Visual Basic or the bytecode in Java), objects willnot necessarily be tied to a specific hardware platform or operating system.

COM is also an integration technology. Components can be developed independently, and COM providesthe standard model for integrating these components. One can think of COM as an enabling technology,rather than a solution in itself.

7/30/2019 MS_COM1_2

9/12


Notes

The Goals of COMThis topic introduces the major goals of COM. These goals are language and vendor independence,location transparency, and reduced version problems.

Language IndependenceWhen developing components, you should not need to choose a specific language.

In COM, any language can be used if it allows for calling functions through function pointers. Eveninterpreted languages are not excluded if the interpretive environment can provide these services onbehalf of the application. You can therefore develop COM component software by using languages suchas C++, Java, Visual Basic, and Visual Basic Scripting Edition (VBScript).

Location TransparencyIn addition, you should not have to know in which module and location the file system provides a service.This becomes increasingly important when specific services cannot be provided locally, if services arelate-bound, or if the process that provides these services changes location.

Just as hard-coded paths are problematic in applications, hard-coded dependence on the location ofservices can also cause errors. COM separates clients from servers, which allows servers to be moved

without impacting clients.

Vendor IndependenceConsider an example of what happens frequently in the current model for software development. A newvendor provides an ODBC driver for your database that is better than the driver provided by your currentvendor. It would be a lot of effort to port all existing code to use the new driver. The effort involved mighttempt you to keep the existing, less effective driver.

Because COM objects export only interfaces, any new object that exposes the same interfaces as anexisting object can transparently replace the existing object. Vendor independence extends not just toexternal vendors, but also internally to objects that can be easily upgraded without recompiling.

Reduced Version ProblemsCOM requires immutable interfaces. Although this specification requirement does not entirely eliminateversion problems, it greatly reduces the extent of the problem.

COM and ActiveXThe focus of Microsoft Object Linking and Embedding (OLE) 2.0 was to enable application integration atthe compound-document level. For example, a user would be able to embed or link a spreadsheet into aword-processor document.

7/30/2019 MS_COM1_2

10/12


Notes

OLE 2.0 was the first technology from Microsoft to be based on COM, as shown in the followingillustration:

Since OLE was introduced, Microsoft has released a number of additional technologies based on COM.These technologies include OLE Automation and OLE Controls, as shown in this illustration:

However, the use of the term OLE in the names OLE Automation and OLE Controls was not quiteaccurate because these technologies had nothing to do with linking and embedding.

In an attempt to resolve this confusion, Microsoft replaced the term OLE with the new term ActiveX. Theonly technologies that kept the name OLE were those that actually related to linking and embedding.

7/30/2019 MS_COM1_2

11/12


Notes

The following illustration shows the difference between ActiveX and OLE, each of which is built on COM:

7/30/2019 MS_COM1_2

12/12


Notes

Self-Check Questions1. Which one of the following is a goal of COM?

A. Enforcing development consistency by requiring all components to bedeveloped in the same language.

B. Enabling clients to be uncoupled from servers by not requiringcomponents to know the physical location of other components.

C. Tracking the version of each component so that only the correct andmost recent version is used.

D. Enabling component developers to choose either C++ or Visual Basicas their development language.

2. One of the problems with the traditional API-based approach to developing component softwareis the continuing evolution of the API. Which one of the following best describes this problem?

A. The API cannot be extended to provide additional functionality.

B. As the API evolves, the implementation language must not change.

C. Any changes made in the API by its creator can potentially breakexisting applications that use the API.

D. There are no problems with the traditional API-based approach tocomponent software development.

ms_com1_2

Documents