UNIT 5:

COM

Component Object Model (COM)

Defini on:
Component Object Model (COM) is a binary-interface standard developed by Microso in 1993. It
facilitates interprocess communica on and dynamic object crea on across different programming
languages, making it a founda onal technology for many Microso frameworks.

Key Features of COM:

1. Language Neutrality:

o COM uses an Interface Defini on Language (IDL) to describe the interfaces of

components.

o This ensures that components are not ed to specific programming languages or

pla orms.

2. Server Types:
COM supports three types of servers for implemen ng components:

o In-Process Server:

 Implemented as a Dynamic Link Library (DLL).

 Executes within the same process space as the applica on.

 Commonly referred to as Ac veX controls.

 Low performance overhead due to its process proximity.

o Local Server:

 Executes in a separate process space on the same machine.

 Communica on occurs via a high-speed interprocess communica on protocol.

 Higher overhead compared to in-process servers.

o Remote Server:

 Executes on a remote machine.

  Uses Distributed COM (DCOM) for communica on over Remote Procedure Calls
(RPCs).

 Highest overhead among server types due to network latency.

3. Loca on Transparency:

o COM abstracts server loca on (in-process, local, or remote) from client applica ons.

o Once a COM object instance is obtained, the interac on remains consistent regardless of
server type.

Strengths of COM:

1. Mature Ecosystem:

o Thousands of Ac veX controls and pre-built components are available for rapid
applica on development.

o Strong integra on with tools like Visual Basic and Visual C++.

2. Advanced Services:

o COM supports Microso Transac on Service (MTS) and Microso Message Queuing
Service (MSMQ), enabling enterprise-level mul er system development.

3. Development Accelera on:

o Development tools and frameworks make it easier to build sophis cated applica ons
quickly.

4. Enterprise Capabili es:

o COM is well-suited for mul - er systems and complex business applica ons.

Weaknesses of COM:

1. Pla orm Limita ons:

o COM is heavily ed to the Windows pla orm.

o Limited support for non-Windows systems like UNIX and mainframes.

2. Java Integra on:

 o COM usage in Java is dependent on the Microso Java Virtual Machine (JVM), which is
not supported on non-Windows pla orms.

3. Vendor Lock-In:

o Heavy reliance on Microso as the sole vendor for COM can deter businesses from
commi ng to the technology due to lack of portability.

Architecture of COM:

1. Client-Server Interac on:

o The client interacts with the server through a proxy interface provided by COM.

o The server's implementa on details remain abstracted, ensuring flexibility and

compa bility.

2. Communica on Mechanisms:

o In-process: Direct method calls to the DLL.

o Local: High-speed interprocess communica on.

o Remote: DCOM and RPC-based communica on.

Use Cases of COM:

1. Front-End Applica ons:

o Building GUI-based applica ons with rich user interac ons using Ac veX controls.

2. Enterprise Systems:

o Development of mul er business applica ons with transac onal support.

3. Dynamic Object Interac on:

o Facilita ng run me interac on between so ware components.

Limita ons and Future Considera ons:

 As so ware development has evolved, newer technologies like .NET Framework and cross-
pla orm solu ons have supplanted COM in many scenarios.
  However, COM remains relevant for legacy systems and scenarios requiring deep integra on
with Windows-based pla orms.

COM Data Types and Mappings

COM (Component Object Model) supports a variety of data types for cross-language interoperability.
These types map to corresponding types in .NET and other languages to ensure consistency and ease of
use. Below is a summary:

COM to .NET Type Mappings

COM Data Type COM Reference Type .NET Framework Type

bool bool* System.Int32

char, small char*, small* System.SByte

short short* System.Int16

long, int long*, int* System.Int32

hyper hyper* System.Int64

unsigned char, byte unsigned char*, byte* System.Byte

wchar_t, unsigned short wchar_t*, unsigned short* System.UInt16

unsigned long, unsigned int unsigned long*, unsigned int* System.UInt32

unsigned hyper unsigned hyper* System.UInt64

COM Data Type COM Reference Type .NET Framework Type

float float* System.Single

double double* System.Double

VARIANT_BOOL VARIANT_BOOL* System.Boolean

void* void** System.IntPtr

HRESULT HRESULT* System.Int16 or System.IntPtr

SCODE SCODE* System.Int32

BSTR BSTR* System.String

LPSTR, char* LPSTR* System.String

LPWSTR, wchar_t* LPWSTR* System.String

VARIANT VARIANT* System.Object

DECIMAL DECIMAL* System.Decimal

DATE DATE* System.DateTime

GUID GUID* System.Guid

CURRENCY CURRENCY* System.Decimal

IUnknown* IUnknown** System.Object

IDispatch* IDispatch** System.Object

SAFEARRAY(type) SAFEARRAY(type)* type[]

COM Data Type Mapping Across Languages

VB C/C++ Delphi C# .NET VB .NET
COM Type Java Mapping
Mapping Mapping Mapping Mapping Mapping

VARIANT_BOOL Boolean boolean VARIANT_BOOL WordBool bool Boolean

 VB C/C++ Delphi C# .NET VB .NET
COM Type Java Mapping
Mapping Mapping Mapping Mapping Mapping

double Double double double Double double Double

float Single float float Single float Single

long Long int long Integer int Integer

short Integer short short SmallInt short Short

BSTR String java.lang.String BSTR WideString string String

DATE Date double DATE TDateTime System.DateTime Date

IDispatch* Object java.lang.Object IDispatch* Dispatch Object Object

IUnknown* Interface Variant IUnknown object Object Object

VARIANT Variant Variant VARIANT OleVariant Object Object

CY/CURRENCY Currency long CY Currency decimal Decimal

Notes:

 COM types like BSTR and VARIANT enable flexible data exchange between systems and are
widely used in COM programming.

 Dynamic mappings ensure that COM components can seamlessly interact with a variety of
languages and pla orms while maintaining data integrity.

 Developers should refer to language-specific documenta on for precise implementa on.

Proxies, Stubs, and Skeletons in COM and CORBA

Proxies, stubs, and skeletons are mechanisms that enable seamless remote method invoca on (RMI) in
distributed systems, such as those based on COM (Component Object Model) and CORBA (Common
Object Request Broker Architecture). They allow developers to invoke methods on distributed objects as
if they were local, simplifying the development of distributed applica ons.

Key Components
 1. Client Stub (COM Proxy/CORBA Stub)

o A client-side mechanism that acts as a surrogate for the remote object.

o Encapsulates the complexi es of remote communica on, making the object appear local
to the client.

o Handles marshaling (packing method calls and arguments into a message).

2. Server Stub (COM Stub/CORBA Skeleton)

o A server-side mechanism responsible for receiving and unpacking messages from the
client.

o Handles unmarshaling (extrac ng the method call and arguments from the received
message).

o Invokes the appropriate method on the actual server object.

3. Communica on Bus

o The run me system (COM or CORBA) that manages the transport of messages between
the client and server stubs.

Steps in Remote Method Invoca on

1. Method Invoca on

o The client invokes a remote method, which is intercepted by the client stub.

2. Marshaling

o The client stub packages the method name, arguments, and other relevant data into a
message.

3. Message Transmission

o The client stub sends the message to the server stub via the communica on bus.

4. Unmarshaling

o The server stub unpacks the message and extracts the method call and arguments.

5. Server Method Execu on

o The server stub invokes the method on the actual object on the server.
 6. Result Packaging

o The server stub packages the method's return value and any out parameters into a
message.

7. Result Transmission

o The server stub sends the result message back to the client stub via the communica on
bus.

8. Result Delivery

o The client stub unpacks the result message and returns the output to the client
applica on.

Benefits

1. Transparency: Developers can invoke methods on remote objects without needing to handle
communica on details.

2. Automa on: Stub and skeleton genera on from IDL reduces manual coding and errors.

3. Pla orm Neutrality: CORBA supports mul ple pla orms, enabling cross-pla orm interac on,
while COM is Windows-centric.

------------------------------------------------------------------------------------------------------------------------------------------

Marshalling
Marshalling in Component Object Model (COM) refers to the process of packaging and unpackaging data
so it can be transmi ed between different contexts, such as between processes or across machines. It is
a cri cal concept in distributed systems and COM programming, enabling communica on between COM
objects that are not located in the same memory space.

Key Concepts of Marshalling in COM:

1. Purpose:

o Allows COM objects to communicate across different process boundaries, threads, or

machines.

o Ensures data integrity and proper func oning of method calls when the caller and the
callee are in different contexts.

2. Proxy and Stub:

 o Proxy: Represents the remote object in the client's context. It acts as an intermediary
and forwards the method calls to the actual object.

o Stub: Resides in the server's context and unpacks the data received from the proxy to
execute the actual method on the object.

3. Marshalling Process:

o Converts complex data structures (e.g., parameters or return values of method calls) into
a serialized format.

o Transmits the serialized data through an inter-process communica on (IPC) mechanism

or network.

o The receiving end unmarshals the data back into its original form to process the method
call.

4. Standard Marshalling:

o Provided by COM through its standard proxy and stub.

o Developers don't need to implement custom marshalling for most COM objects as COM
handles it automa cally.

5. Custom Marshalling:

o Used when standard marshalling does not meet the requirements (e.g., for op miza on
or handling special data types).

o Requires implemen ng the IMarshal interface to control how objects are marshalled and
unmarshalled.

6. Types of Marshalling:

o In-process Marshalling: Communica on between objects within the same process.

o Cross-process Marshalling: Communica on between objects in different processes on

the same machine.

o Remote Marshalling: Communica on between objects across different machines.

7. Example Scenario:

o A client applica on invokes a method on a COM object located in a different process.

o The proxy serializes the method call arguments.

o The stub receives the serialized data, deserializes it, and executes the method.
 o The return value is serialized and sent back to the proxy, which deserializes it for the
client.

Advantages:

 Transparency: Allows developers to call methods on remote objects as if they were local.

 Encapsula on: Hides the complexi es of communica on and data conversion.

Challenges:

 Performance overhead due to serializa on and deserializa on.

 Complexity in custom marshalling implementa ons.

----------------------------------------------------------------------------------------------------------------------------------

Introduc on to Client/Server Architecture

 Purpose: Client/server architecture separates the processing of persistent storage and data
retrieval from other applica on func onali es. This enables:

1. Efficient data management: Persistent data is stored and managed separately.

2. Security and reliability: Centralized data storage enhances security.

3. Performance benefits: Server-side management improves performance.

Early Client/Server Systems

 Characteris cs:

o Heavy clients: Clients handled significant processing tasks.

o Centralized database: Persistent data was stored in rela onal databases managed by
servers.

o Communica on via SQL: Clients used SQL to interact with the database.

 Challenges:

o SQL's nonprocedural nature led to transferring large datasets to clients for processing,
causing network conges on.

o Client-side processing required substan al computa onal power.

2-Tier Architecture

 Defini on:

o Two dis nct layers:

1. Client Tier: Handles applica on logic and user interface.

2. Data Tier: Manages persistent data using a database.

 Limita ons:

o Clients needed significant processing capabili es.

o Storing business logic on clients made scalability and maintenance challenging.

3-Tier Architecture

 Introduc on:

o To address the limita ons of the 2- er system, processing was divided further into three
ers:

1. Client Tier: Focuses solely on presenta on (UI/UX).

2. Middle Tier: Manages business logic and applica on processing.

3. Data Tier: Responsible for data storage and retrieval.

  Advantages:

o Performance: Middle- er processing is closer to the database, reducing data transfer

overhead.

o Scalability: Adding middle- er servers accommodates more clients.

o Independence: Client applica ons are decoupled from the database, making them
easier to update or replace.

o Centralized Business Logic: Business rules are easier to manage and enforce.

N-Tier Architecture

 Defini on:

o An extension of the 3- er system, where the middle er is further subdivided into

mul ple services, each ac ng as a separate er.
  Example: Web-Based Applica on:

o Tier 1: Client er, implemented via a web browser for presenta on.

o Tier 2: Middle- er distribu on mechanism using a web server.

o Tier 3: Business logic processing via server-side scripts.

o Tier 4: Data er for database storage.

 Benefits:

o Distributed Workload: Tasks are divided across mul ple computers or servers.

o Flexibility and Modularity: Easier to manage, maintain, and scale individual services.

Understanding COM Interface Pointers

In the Component Object Model (COM), an interface pointer is a cri cal concept that facilitates
interac on between clients and COM objects. Here's a detailed breakdown of the informa on provided:
What is an Interface Pointer?

 An interface pointer refers to an instance of an interface implementa on, essen ally poin ng to
a func on table (commonly called a vtable in COM terminology).

 This func on table contains pointers to the methods defined in the interface, allowing clients to
invoke those methods through the pointer.

Key Features of COM Interface Pointers

1. Func on Tables (vtable):

o Each COM interface is associated with an array of func on pointers, where each pointer
refers to a method implementa on.

o Objects suppor ng mul ple interfaces have separate func on tables for each interface
they implement.

2. Access Mechanism:

o If a client has access to an interface pointer, it can invoke any method defined in the
interface through the corresponding func on table.

3. Globally Unique Interface Iden fiers (IIDs):

o Every COM interface is uniquely iden fied at run me by an interface iden fier (IID), a
specific type of Globally Unique Iden fier (GUID).

o Clients can query objects to check if they support a specific interface by using its IID,
ensuring precise interac on.

What a COM Interface Is (and Is Not)

1. A COM Interface Is Not a C++ Class:

o While C++ can be used to implement an interface as a class, this is purely an

implementa on detail.

o The COM interface specifies behavior at the binary level, enabling language
independence.

o Different classes can implement the same interface in varied ways while remaining
compa ble with COM's binary standards.
 2. A COM Interface Is Not an Object:

o A COM interface represents a related group of methods, forming a communica on

contract between clients and objects.

o The object itself can be implemented in any programming language, provided it adheres
to the interface's binary specifica on.

3. Strongly Typed:

o Each interface is iden fied by its unique IID, avoiding naming conflicts and ensuring
robust type checking.

4. Immutable:

o COM interfaces cannot be modified once defined. Adding, removing, or altering

methods requires defining a new interface with a new IID.

o This immutability guarantees that old interfaces remain func onal and free of conflicts
with new ones.

Benefits of COM Interface Design

 Interoperability: Allows seamless communica on between components wri en in different

languages.

 Robustness: Strong typing and immutability prevent conflicts and ensure compa bility.

 Flexibility: Objects can implement mul ple interfaces or different implementa ons of the same
interface.

 Extensibility: New func onality can be added by crea ng new interfaces without disrup ng
exis ng systems.

SIMILARITIES AND DIFFERENCE OF COM AND CORBA