COM/DCOM & COM+ Qisheng Hong Yani Mulyani Paul Visokey.

COM/DCOM & COM+

Qisheng HongYani MulyaniPaul Visokey

Outline

The Component Object Model - COMDCOMCOM+

What is COM?Build software from parts, not from scratch

A framework for creating and using components Both a specification and an implementation Makes software easier to write and reuse Provides widest choice in services, tools,

languages, and applications Evolved from Object Linking and

Embedding technology Foundation in OLE Version 2, 1995

Isn’t COM about “Objects”?

No … COM sets out to solve system software problems that arise when hooking up randomly evolving combinations of binaries

Benefits stem from its design an an integration and deployment architecture for software components

Yes … from the perspective of these new kinds of objects, also called “components”

COM is about clients communicating with objects COM based applications can be constructed using

language-independent components

COM Architecture

The ModelThe “ORB”The Services

COM Fundamental PrinciplesWhat the designers of COM were striving for...

Binary components Any programming language Any location (in-process, cross-process, cross-

machine) No centralized authority

Object orientation Interoperability Reusability

Simplest model possible Enable extensibility, maintainability and adaptability Multi-tier architecture

The Component Object Model (COM)

Components, Components, Components Code reuse and off-the-shelf components Language independent notion of an object

Rigorous Encapsulation at the binary level

Black box -- no leakage of implementation details All object manipulation through strict interfaces

Polymorphism Define several different behaviors for a single object via multiple interfaces per class “Discoverable”: QueryInterface()

COMObject

IUnknown

IRobot

IDispatch

The Component Object Model (COM)

Standard API Binary structure for the interface between client and

object Compilers support Microsoft’s COM binary structure

- language independence The point of contact is the run-time binary

representation OS acts as central registry for objects

Applications only know the function of the objectWire-level standard for

location transparency

OOD and COMTable 1: Differences in design considerations between OOD and COM

Differences in design considerations between OOD and COM

Object-Oriented Design Assumptions Added COM Considerations

Objects typically packaged in the same application (module) as client code

Objects and clients typically in separate modules, both .EXEs and .DLLs

Objects and clients run in a single process Objects and clients may run in different processes and on different machines

Class (implementation) inheritance Interface inheritance (no implementation inheritance)

Single interface per object (the object's class definition)

Multiple interfaces per object

Single client per object Multiple simultaneous clients per object

1:1 relationships between clients and objects typical

Many:Many relationships between clients and objects is common

The COM Object Request Broker

The “model” is about how the technology is usedThe “ORB” is how it’s implemented

Microsoft calls it the COM Runtime

Secure Security is designed and built in. Not an option.

Inherently DistributedPluggable

Security Transports

Free! (Built-into Win32 Platforms) No separate client access license or expensive

“developer” version

Structure of the COM “ORB”

The COM Runtime

COM and Distributed COM Registry

Pluggable Security(SSPI)

NTLMKerberos

Pluggable Transports DCE

MS-RPC

TCP UDP IPX SPX HTTP ETC.ETC.

Core Services(Automation, Monikers, Storage, ComCat, Data Transfer, IR)

Components and ApplicationsComponents and Applications

Pluggable Transports

COMCOMClientClient

COM Runtime ArchitectureFlexible and extensible

Component

CO

M R

unti

me

Server MachineClient Machine

TCP, UDP

SPX,IPX

Net BUI

HTTP

CO

M R

unti

me

Proxy

Other Component

ORB

ORB

Pluggable Security Providers

COMCOMClientClient

COM Runtime ArchitectureFlexible and extensible

Component

CO

M R

unti

me

Server MachineClient Machine

DCE

NT Kerberos

SSL, Certs.

NTLM

CO

M R

unti

me

Proxy

Other Component

ORB

ORB

COM Runtime Architecture

ClientClient ComponentComponent

InprocessInprocess

COMCOMrun timerun time

providerproviderSecuritySecurity

RPCRPC

COMCOMrun timerun time

SecuritySecurityproviderprovider RPCRPC

LocalLocal

LPCLPCProtocol stackProtocol stack Protocol stackProtocol stack

DCOM network-DCOM network-protocolprotocol RemoteRemote

Accessing COM ServicesAccessing COM Services

ClientClient ComponentComponent

In the same process In the same process Fast, direct links to Fast, direct links to server libraryserver library

ClientClient ComponentComponentCOMCOM

Client ProcessClient Process Server ProcessServer Process

On the same machineOn the same machineFast, secure lightweight Fast, secure lightweight RPCRPC

Across machinesAcross machinesSecure, reliable and Secure, reliable and flexible DCE-RPCflexible DCE-RPCbased based DCOMDCOM protocol protocol

COMCOMDCERPC

ClientClient

Server MachineServer MachineClient MachineClient Machine

COMCOM ComponentComponent

COM Limitations

Lack of a common type system, each language involved in COM had its own type system. Architecture does not have perfect

knowledge of the types.

COM is hard to use. Reference counting, Microsoft IDL, Global Unique Identifiers (GUID), etc. require deep knowledge of COM specification from developers.COM is not robust enough for enterprise deployments. Services such as secure transactions, reliable communications, and load balancing are not integrated in COM.

DCOM: Multiple Network Transports

TCP, UDPTCP, UDP

IPX, SPXIPX, SPX

HTTPHTTP

Server MachineServer MachineClient MachineClient Machine

COM

QueuedQueued

ClientsClients

COM

COMCOMObjectObject

QueuedQueued

DCOM: Flexible Security

TCP, UDPTCP, UDP

IPX, SPXIPX, SPX

HTTPHTTP

Server MachineServer MachineClient MachineClient Machine

COM

ClientsClients

NT4 SecurityNT4 Security

SSL/SSL/CertificatesCertificates

KerberosKerberos

IPSECIPSEC

COM

COMCOMObjectObject

What’s next? COM+

Evolutionary step, making it even easier to build and use componentsInfrastructure in the system, not in the applicationExtensible servicesPreserves current investments in COMProvides benefits across languages and toolsLess coding, more productivity

COM+ Strategy

TransactionsTransactionsData BindingData BindingPersistencePersistenceLoad Load Balancing BalancingSecuritySecurityIn Memory In Memory Database DatabaseEvent Event Infrastructure Infrastructure

Ubiquitous Type Ubiquitous Type DescriptionDescriptionDynamic InvocationDynamic Invocation““No-Leak” No-Leak” Memory Mgmt Memory MgmtInterceptionInterception

ToolsToolsUbiquityUbiquityMarketMarketBinary StandardBinary Standard

The COM+ MODEL

COM+ is the next step in the evolution of the Microsoft® Component Object Model and Microsoft Transaction Server (MTS). COM+ handles many of the resource management tasks such as thread allocation and security. COM+ automatically makes applications more scalable by providing thread pooling, object pooling, and just-in-time object activation. COM+ protects data integrity by providing transaction support, even if a transaction spans multiple databases over a network.

The COM+ MODEL

COM+ still provides a standard library, and objects and their clients still use it.

COM+ hides calls to this library beneath the equivalent native functions in the programming language.

C++ programmers can use the standard new operator rather

than CoCreateInstance() to create a COM+ object.

COM+ developers no longer need to define interfaces using IDL. Object's interfaces defined using their programming

language's syntax.

The COM+MODEL

COM+ addresses another important but challenging problem in creating a language-independent object model: data types.

Different languages support different data types, which causes problems when passing parameters between objects written in different languages.

COM+ allows implementation inheritance between COM+ objects running in the same process. COM objects do not support constructors, but COM+ objects do. COM+ constructors even allow passing parameters,

better integrating COM+ objects and the objects used by today's most popular object-oriented languages.

COM+ Philosophy

Attribute-based Programming Write your Logic Set Attributes Runtime Does all the grungy stuff Interceptors deal with the object based on the Attributes Different Interceptors provide different extensible

services at Runtime

The key to extensible services: Interception

Key concept in “COM +” run-timeInterceptors provide automatic behavior at runtime based on the attribute set Interceptors assure that when a transactional object attempts to change data either all succeed or all fail and rollback Interception Events

Instance creation Method call and return, field access Force fail pre and post call Binding an instance to a reference Dynamically (re)define method

The Web• Easy to Deploy• Graphical UI• Dynamic

COM+ and Windows DNA For building next generation applications

The Windows PC• Rich application

services• Familiar UI for users• Consistent

management

Windows DNA

• Integrates client/server and the web

• Services that work together

• Open protocols and published interfaces

COM+ Applications

• Component-based

• Flexible and dynamic

• Built-in scalability

• Preserve current investments

• Extensible services

SummaryCOM is the most widely adopted object model in the worldCOM+ builds on the success of the Component Object ModelProvides benefits across languages and toolsLess code, more productivityExtensible services enabled by interceptionProvides the backbone to Windows DNA

Questions?