Date: Mon, 04 Nov 1996 23:45:54 GMT Server: NCSA/1.5 Content-type: text/html Last-modified: Mon, 06 May 1996 23:58:23 GMT Content-length: 13364 Computing with Distributed Objects

Computing with Distributed Objects

Steven Fought


Talk Sources


Object Oriented Programming Review

Objects are individual sets of data coupled with related procedures used to access and alter those data.

Important features:

Encapsulation
Data are hidden behind methods
Polymorphism
Objects can be interchangeable, but different
Inheritance
Objects can be extended and altered, but remain interchangeable with the older models

Related features:


OpenDoc

OpenDoc is a Compound Document programming model:


OpenDoc Frameworks

Two competing drawing frameworks:

OpenDoc Development Framework
From Apple. No rendering facilities. Instead, prebuilt editor parts are subclassed
OpenDoc Framework
From IBM. Built on OpenClass, a cross-platform rendering library. Currently available for OS/2 and Windows, Mac and AIX later.

Clearly, rendering is currently an OpenDoc weak-point.


OpenDoc Compound Documents

Document shells are used to interact with documents. They:


Bento: OpenDoc Persistent Storage

Bento is used to store compound documents.


OpenDoc Data Transfers

Persistent references are recursively located within parts to determine what to copy.

Copy links push new data to other documents when they are updated.


Scripting and Extensions

Part editor superclasses are designed so that part operations can be scripted

A semantic-level event system extends the OS event model

Standardized and registered extra interfaces to parts called Extensions are also possible.


OLE/COM

OLE is not based strictly on the object model:


OLE Interfaces

Interfaces are called through vtables laid out in MS Visual C++ format.

Programmers using compilers with different vtables must currently lay out OLE tables by hand.

In-process servers are implemented as DLLs loaded into the process' address space

Local servers are contacted using MS Lightweight RPC


More on Interfaces

All client/server communication starts with the IUnknown interface

New interfaces are discovered with the QueryInterface method of IUnknown

This allows multiple interfaces to be supported via aggregation


OLE features

OLE has features similar to OpenDoc

In addition the storage architecture supports locked regions, and commit/revert transactions (the product currently does not).


Monikers

Monikers are aliases for other objects, including:

In OLE, nested data are handled with monikers


OLE Compound Documents

Container
An application with some main purpose (e.g. Word) that can contain servers
Server
A smaller program that is either loaded into the address space or through LRPC that allows editing of some sub-document

Pixelmaps of sub-documents are cached to allow document display without full server activation.


OCXs

OCXs or ``OLE Custom Controls'' are Microsoft's replacement for Visual Basic controls, and are more generally applicable to OLE.

Their purpose is to provide a standard architecture for most servers.

Each consists of an in-process server aggregated with an automation server (which allows scripting).

Biggest weakness: OCXs cannot be containers.


CORBA overview: The Common Object Request Broker Architecture

Distributed Objects: Distributed computing with object-oriented principles

CORBA objects can exist anywhere on a network

Their location is transparent to other objects

The Object Request Broker (ORB) marshals communication between objects

Object interfaces are defined in a PL-independent Interface Definition Language (IDL)


CORBA History

CORBA spec is controlled by the Object Management Group (OMG), a consortium of over 500 companies

CORBA 1.0 was published in 1990 and specified the compliant behaviors of individual ORBs

CORBA 2.0 was published in 1996 and specified interoperability between ORBs, as well as updating other aspects of the spec

Five sub-specifications on different standardized services ORBs must implement have been issued. Three exist in RFC form.


Interface Definition Language

The IDL completely specifies communication between a client and server

The client/server relationship is arbitrary, and is generally linked to the initiating object

The IDL defines:

Modules:
sets of class descriptions grouped into one namespace
Interfaces:
sets of method invocations. Like a class definition with no implementation
Operations:
the CORBA term for methods
Data types:
include simple types short, long, unsigned short, unsigned long, float, double, char, boolean, and octet, and constructed types enum, string, struct, array, union, sequence and ``any.'' Aggregate types can be constructed with typedefs


IDL example

module MyAnimals
{
  interface Dog: Pet, Animal
  {
    attribute integer age;
    exception NotInterested (string explanation);

void Bark(in short how_long) raises (NotInterested);

void Sit(in string where) raises (NotInterested); } }

Attributes provide automatic get/set operations.


Object Request Brokers

ORBs are also called ``object buses''

All requests to other objects go through the ORB

An ORB is not a single process or a set of processes, it is a set of services and protocols

ORBs can be compared with plumbing


ORBs: Client side

Client IDL stubs
which pack up information and transport it to the server, and are created by the IDL compiler
Dynamic Invocation Interface (DII)
which allows run-time binding of object interfaces
Interface Repository APIs
are stored in a run-time database, allowing the DII to discover object methods
ORB Interface
which provides a few commonly needed services, such as converting object reference objects to strings


ORBs: Server side

Server IDL stubs
created by the IDL compiler
Dynamic Skeleton Interface (DSI)
is the server-equivalent of the DII, allowing it to receive non IDL-marshaled requests
Object Adapter
provides a runtime environment for CORBA objects, including assigning IDs (object references), instantiation, and message passing
Implementation Repository
provides a place to store administrative data, including the location of executable servers
ORB Interface
provides a few commonly needed services (same as client side)


Steps in creating a CORBA service

  1. Create your IDL definitions
  2. Precompile to create interface skeletons
  3. Add server implementation code
  4. Compile

The compile will add APIs to the Interface Repository, create client IDL stubs and executable server objects, and register the executable with the Implementation Repository

When a client opens a connection to the server, the Object Adapter will check the Implementation Repository for a compatible executable, and instantiate it


Dynamic Invocations

To allow interface discovery, a client can dynamically invoke object methods with the DII

The steps are:

  1. Obtain the method description
  2. Create argument list
  3. Create the request
  4. Invoke the method using RPC, Send/Receive, or Datagram, depending on the method description

Library routines are provided to aid in this process


More on Object Adapters

Object Adapters

The OA is effectively an inherited interface, although it can be implemented in procedural languages

Standardized Basic Object Adapters (BOAs) are provided for the common cases: shared server, unshared server, server-per-method, and persistent server


Common Object Service Specifications

A number of standardized services have been established, and more are being worked on. These are grouped together in Common Object Service Specifications (COSSs)

COSS1:
Life Cycle, Naming, Persistence, Event Notification (1993)
COSS2:
Transactions, Concurrency Relationships, Externalization (1994)
COSS3:
Security, Time (1995)
COSS4:
Query, Licensing, Properties (1995)
COSS5:
Trader, Collections Change Management (1996)

I will discuss some of these in the following slides


Naming, Events, Life Cycle and Trader

Naming:
A standardized hierarchical name service designed to encapsulate other services such as DCE CDS, ISO X.500, and Sun NIS+
Trader:
Provides a way of finding the object most suited to a task based on some set of criteria
Life Cycle:
Allows the creation, copying, deleting, and moving of objects. Also allows relationships between objects to be defined in terms of graphs
Events:
Allows semantic level events to be defined and distributed


Transactions and Concurrency

The Transaction Object allows nested Commit/Abort style transaction to be defined. The object interface is inherited by objects that support transactions

The Concurrency service includes locking facilities to allow mutual exclusion and synchronization


Persistence and Object Databases

The Persistence object allows seamless access to one or two level stores

The implementation is complex, but three basic interfaces are provided:

The latter can be used for two-level stores such as relational databases and filesystems


Notes on CORBA

ORBs from different vendors are only compatible if they implement half-bridges to a reference protocol that runs on top of TCP/IP (CORBA 2.0)

ORB vendors have great flexibility in determining transport, packaging, and server calling mechanisms

The flexibility is intended to encourage high performance systems

Performance varies widely by implementation and relative object location


Interesting Issues