Introduction

CORBA

Distributed COM

Sections 9.1 & 9.2

Corba & DCOM John P. Daigle
Department of Computer Science Georgia State University

05.16.06

Introduction

CORBA

Distributed COM

Outline
1 2

Introduction CORBA Overview Communication Processes Naming Other Design Concerns Distributed COM Overview Naming Fault Tolerance & Security

Introduction

CORBA

Distributed COM

Outline
1 2

Introduction CORBA Overview Communication Processes Naming Other Design Concerns Distributed COM Overview Naming Fault Tolerance & Security

Introduction

CORBA

Distributed COM

CORBA and DCOM

CORBA CORBA stands for Common Object Request Broker Architecture. Specication Developed by the Object Management Group (UML Authors) The essence of CORBA is separation of interface from implementation (from OMG web site) DCOM Distributed Component Object Model Microsoft Technology

Introduction

CORBA

Distributed COM

What are these things?

CORBA and DCOM are Distributed Object Based Systems

Introduction

CORBA

Distributed COM

Outline
1 2

Introduction CORBA Overview Communication Processes Naming Other Design Concerns Distributed COM Overview Naming Fault Tolerance & Security

Introduction

CORBA

Distributed COM

Object Model
Client machine Client application Static IDL proxy Dynamic Invocation Interface Client ORB Local OS ORB interface Object adapter Server machine Object implementation Skeleton Dynamic Skeleton Interface ORB interface

Server ORB Local OS

Network

ORB Object Request Broker: the Core of a CORBA system, enables communication between objects and their clients. IDL Interface Denition Language provides a precise syntax for describing methods and parameters, static Dynamic Invocation Interface Runtime tool for clients to construct an invocation request at runtime.

Introduction

CORBA

Distributed COM

Interface, services
Interface & Implementation Repository Interface Repository Stores all interface denitions IDL compiler assigns a repository identier to each interface on compilation Standardized to IDL syntax Implementation Repository Stores all information needed to implement objects. Closely coupled to OS and ORB (which is non standard) CORBA Services Conceptually, CORBA services are the operating system of the CORBA distributed platform. Services are general purpose Services are independent of application

Introduction

CORBA

Distributed COM

List of CORBA services (p. 500)

Service Collection Query Concurrency Transaction Event Notication Externalization Life cycle Licensing Naming Property Trading Persistence Relationship Security Time Description Facilities for grouping objects into lists, queue, sets, etc. Facilities for querying collections of objects in a declarative manner Facilities to allow concurrent access to shared objects Flat and nested transactions on method calls over multiple objects Facilities for asynchronous communication through events Advanced facilities for event-based asynchronous communication Facilities for marshaling and unmarshaling of objects Facilities for creation, deletion, copying, and moving of objects Facilities for attaching a license to an object Facilities for systemwide naming of objects Facilities for associating (attribute, value) pairs with objects Facilities to publish and nd the services an object has to offer Facilities for persistently storing objects Facilities for expressing relationships between objects Mechanisms for secure channels, authorization, and auditing Provides the current time within specied error margins

Introduction

CORBA

Distributed COM

Object Invocation Models

How does the client connect to an object?

Request Type Snychronous Failure Semantics At-most-once Description Caller blocks until a response is returned or an exception is raised Caller continues immediately without waiting for any response from the server Caller continues immediately and can later block until response is delivered

One-way

Best effort delivery

Deferred Synchronous

At-most-once

Introduction

CORBA

Distributed COM

Event & Notication Services

Push event to consumers Consumer Event channel Consumer Supplier Supplier Supplier

Push Model Objects wait passively to be informed when an event occurs.

Ask suppliers for new event Consumer Event channel Consumer Supplier Supplier Supplier

Pull Model Objects poll the event channel to check for events. Both models are inherently unreliable, and neither allows ltering of messages.

Introduction

CORBA

Distributed COM

Messaging Service
CORBA also provides a more reliable communication method for persistent communication. This is an object oriented communication service.
Client application 1. Call by the application Client proxy Client ORB 2. Request to server Callback interface 4. Call by the ORB 3. Response from server

Callback model: application driven, application supported

Introduction

CORBA

Distributed COM

Messaging Service
CORBA also provides a more reliable communication method for persistent communication. This is an object oriented communication service.
Client application 1. Call by the application Client proxy Client ORB 2. Request to server Polling interface 3. Response from server 4. Call by the application

Polling Model: application driven, ORB supported

Introduction

CORBA

Distributed COM

Interoperability

GIOP There is a need in CORBA for different ORBs on different platforms to be able to communicate. GIOP General Inter-ORB protocol: must run on top of an existing transport protocal, such as TCIP.

Introduction

CORBA

Distributed COM

Clients
One unique aspect of client software in CORBA is the idea of an interceptor, which allows client side software to be modied as needed by modifying the input or output, rather than the software itself.
Client application Client proxy Request-level interceptor Client ORB Message-level interceptor Local OS To server

Invocation request

Introduction

CORBA

Distributed COM

Object References
Important: In CORBA, it is essential to distinguish specication-level and implementation-level (object references Specication level: An object reference is considered to be the same as a proxy for the referenced object having an object reference means you can directly invoke methods; there is no separate client-to-object binding phase Implementation level: When a client gets an object reference, the implementation ensures that, one way or the other, a proxy for the referenced object is placed in the clients address space Conclusion: Object references in CORBA used to be highly implementation dependent: different implementations of CORBA could normally not exchange their references.

Introduction

CORBA

Distributed COM

Interoperable Object References

Because object references are implementation dependent, CORBA requires a way to package object references to allow them to be universally understood.
Tagged Profile Interoperable Object Reference (IOR) Repository identifier Profile ID Profile

IIOP version

Host

Port

Object key

Components

POA identifier

Object identifier

Other serverspecific information

ProleID Field The part of the tagged prole that contains the complete information needed to invoke the object.

Introduction

CORBA

Distributed COM

Interoperable Object References

Because object references are implementation dependent, CORBA requires a way to package object references to allow them to be universally understood.
Tagged Profile Interoperable Object Reference (IOR) Repository identifier Profile ID Profile

IIOP version

Host

Port

Object key

Components

POA identifier

Object identifier

Other serverspecific information

ProleID Field The part of the tagged prole that contains the complete information needed to invoke the object.

Introduction

CORBA

Distributed COM

Interoperable Object References

Because object references are implementation dependent, CORBA requires a way to package object references to allow them to be universally understood.
Tagged Profile Interoperable Object Reference (IOR) Repository identifier Profile ID Profile

IIOP version

Host

Port

Object key

Components

POA identifier

Object identifier

Other serverspecific information

ProleID Field The part of the tagged prole that contains the complete information needed to invoke the object. IIOP version The version Number for this prole

Introduction

CORBA

Distributed COM

Interoperable Object References

Because object references are implementation dependent, CORBA requires a way to package object references to allow them to be universally understood.
Tagged Profile Interoperable Object Reference (IOR) Repository identifier Profile ID Profile

IIOP version

Host

Port

Object key

Components

POA identifier

Object identifier

Other serverspecific information

ProleID Field The part of the tagged prole that contains the complete information needed to invoke the object. Host Location of this object (for example, an IP or DNS)

Introduction

CORBA

Distributed COM

Interoperable Object References

Because object references are implementation dependent, CORBA requires a way to package object references to allow them to be universally understood.
Tagged Profile Interoperable Object Reference (IOR) Repository identifier Profile ID Profile

IIOP version

Host

Port

Object key

Components

POA identifier

Object identifier

Other serverspecific information

ProleID Field The part of the tagged prole that contains the complete information needed to invoke the object. Object Key Server specic information for demultiplexing incoming requests to the appropriate object.

Introduction

CORBA

Distributed COM

Interoperable Object References

Because object references are implementation dependent, CORBA requires a way to package object references to allow them to be universally understood.
Tagged Profile Interoperable Object Reference (IOR) Repository identifier Profile ID Profile

IIOP version

Host

Port

Object key

Components

POA identifier

Object identifier

Other serverspecific information

ProleID Field The part of the tagged prole that contains the complete information needed to invoke the object. Components Additional information such as security information.

Introduction

CORBA

Distributed COM

The CORBA Naming Service

Essence: CORBAs naming service allows servers to associate a name to an object reference, and have clients subsequently bind to that object by resolving its name Observation: In most CORBA implementations, object references denote servers at specic hosts; naming makes it easier to relocate objects Observation: In the naming graph all nodes are objects; there are no restrictions to binding names to objects: CORBA allows arbitrary naming graphs Observation: There is no single root; an initial context node is returned through a special call to the ORB. Also: the naming service can operate across different ORBs

Introduction

CORBA

Distributed COM

Fault Tolerance
Remember that replication is the key to fault tolerance. Interoperable Object Group Reference
Interoperable Object Group Reference (IOGR) Repository identifier Profile ID Profile-1 Profile ID Profile-N

IIOP ver.

Host-1

Port-1

Object key-1

Components

IIOP ver.

Host-N Port-N

Object key-N

Components

TAG PRIMARY

Other groupspecific information

TAG BACKUP

Other groupspecific information

Note: IOGRs have the same structure as IORs; the main difference is that they are used differently. In IORs an additional prole is used as an alternative; in IOGR, it denotes another replica.

Introduction

CORBA

Distributed COM

Security
Essence: Allow the client and object to be mostly unaware of all the security policies, except perhaps at binding time; the ORB does the rest. Specic policies are passed to the ORB as (local) objects and are invoked when necessary:
Client application Set of client-specific policy objects Set of object-specific policy objects Object implementation

Security service

Policy object Policy object

Policy object Policy object

Security service

Security service Client ORB Local OS

Security service Server ORB Local OS

Set of relevant ORB security services

Network Invocation

Examples: Type of message protection, lists of trusted parties.

Introduction

CORBA

Distributed COM

Outline
1 2

Introduction CORBA Overview Communication Processes Naming Other Design Concerns Distributed COM Overview Naming Fault Tolerance & Security

Introduction

CORBA

Distributed COM

Acronyms
COM Component Object Model OLE Object Linking & Embedding Active X Everything that isnt COM
ActiveX Documents Grouping (Controls) Document linking In-place editing Drag and drop Scripting

OLE

Embedding

Interprocess data transfer COM Persistent storage

Persistent references

Object activation

Core COM library

Introduction

CORBA

Distributed COM

Object Model

Interfaces are Binary, essentially, a DCOM interface is a collection of pointers to implementations of methods. Each interface is typed, and therefore has a globally unique interface identier A client always requests an implementation of an interface:
Locate a class that implements the interface Instantiate that class, i.e., create an object Throw the object away when the client is done

The DCOM equivalent to the Interface Repository is the type library

Introduction

CORBA

Distributed COM

DCOM Services
CORBA Collection Query Concurrency Transaction Event Notication Externalization Life cycle Licensing Naming Property Trading Persistence Relationship Security Time DCOM/COM+ ActiveX Data Objects None Thread concurrency COM+ Automatic Transactions COM+ Events COM+ Events Marshaling utilities Class factories, JIT activation Special class factories Monikers None None Structured storage None Authorization None Windows 2000 Distributed Transaction Coordinator Active Directory Active Directory Active Directory Database access Database access SSL, Kerberos None

Note: COM+ is effectively COM plus services that were previously available in an ad-hoc fashion

Introduction

CORBA

Distributed COM

Communication
Object invocations: Synchronous remote-method calls with at-most-once semantics. Asynchronous invocations are supported through a polling model, as in CORBA. Event communication: Similar to CORBAs push-style model:
Supplier Event class object Consumer m_event

Interface containing m_event

Event object

Consumer m_event

Invocation is stored Event store

Invocation is passed to consumer

Object implementing m_event

Messaging: Completely analogous to CORBA messaging.

Introduction

CORBA

Distributed COM

Processes
Client side processes in DCOM are generally handled as if all objects are running locally. Passing object references between machines requires passing unique ID information, location, and other binding information. The wrapping is done by the proxy:
Process A Client application Client proxy Proxy (un)marshaler Marshaled client proxy Process B Client application Proxy (un)marshaler Client proxy

Binding information Object stub

Same binding information Object

Object server

Introduction

CORBA

Distributed COM

Monikers

DCOM Objects are Temporary To accommodate objects that can outlive their client, something else is needed. A Moniker is a persistent reference, a hack to support real objects A moniker associates data (e.g., a le), with an application or program Monikers can be stored A moniker can contain a binding protocol, specifying how the associated program should be launched with respect to the data. 1 2 3 4 5 6 7 Client Moniker SCM Class object Moniker Object Moniker Calls BindMoniker at moniker Lookup CLSID and tell SCM to create object Loads class object Creates object, returns int. pointer Instructs object to load previously stored state Loads its state from le Returns interface pointer of object to client

Introduction

CORBA

Distributed COM

Active Directory
A worldwide distributed directory service, but one that does not provide location transparency. Basics: Associate a directory service (called domain controller) with each domain; look up the controller using a normal DNS query:

DNS

1. Ask for host address of domain controller in a given domain

2. Requested address

3. LDAP query Client 4. LDAP reply Domain controller

Domain controllers can be grouped into trees and forests, and indexed at that level.

Introduction

CORBA

Distributed COM

Fault Tolerance

Automatic transactions: Each class object (from which objects are created), has a transaction attribute that determines how its objects behave as part of a transaction:
Attr. value REQUIRES_NEW REQUIRED SUPPORTED NOT_SUPPORTED DISABLED Description A new transaction is always started at each invocation A new transaction is started if not already done so Join a transaction only if caller is already part of one Never join a transaction (no transaction support) Never join a transaction, even if told to do so

Note: Transactions are essentially executed at the level of a method invocation.

Introduction

CORBA

Distributed COM

Declaritive Security I
DCOM Security is based on roles. The registry keeps an access control list for its entries, specifying the access privileges for each group.
Auth. level NONE CONNECT CALL PACKET PACKET_INTEGRITY PACKET_PRIVACY Description No authentication is required Authenticate client when rst connected to server Authenticate client at each invocation Authenticate all data packets Authenticate data packets and do integrity check Authenticate, integrity-check, and encrypt data packets

Delegation: A server can impersonate a client depending on a level:

Impersonation ANONYMOUS IDENTIFY IMPERSONATE DELEGATE Description The client is completely anonymous to the server The server knows the client and can do access control checks The server can invoke local objects on behalf of the client The server can invoke remote objects on behalf of the client