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
- The Essential Distributed Objects Survival Guide (R. Orfali, D. Harkey, J. Edwards, Wiley)
- Usenet news
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:
- Early and late binding
- Frameworks
OpenDoc
OpenDoc is a Compound Document programming model:
- Documents are divided into parts
- Parts consist of typed data in persistent store, and an associated
part editor
- Part editors are subclassed from a 60 method superclass that is
standard over all implementations (not all methods need to be overloaded)
- Many parts can nest within other parts
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:
- Create a session object (which provide parts with information
and manage geometries)
- Retrieve documents from storage
- Dynamically bind and load part editors
- Dispatch events and manage global document data
Bento: OpenDoc Persistent Storage
Bento is used to store compound documents.
- A system of structured files and references between files.
- No concurrent multiuser access (currently)
- Internal versioning system (Drafts)
- Persistent references (32 bit IDs) used to identify individual parts
OpenDoc Data Transfers
- Drag and Drop
- Clipboard (cut/copy/paste)
- Copy links
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:
- Interfaces are not individually instantiated, and therefore have no
unique associated state
- Inheritance is not supported. Instead, aggregation is available
- Object location is not transparent. Communications mechanisms
differ depending on the environment of the object (in-process, local servers,
remote servers)
- Remote servers are currently unimplemented (might be in NT 4 beta)
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
- Scripting and automation support
- Data transfer via drag-and-drop, clipboard and linking (through change
advisories)
- Compound documents
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:
- Files
- Items (within files)
- Anti monikers (which negate previous monikers)
- Pointers (to volatile storage)
- Composite (groups of monikers)
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
- Create your IDL definitions
- Precompile to create interface skeletons
- Add server implementation code
- 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:
- Obtain the method description
- Create argument list
- Create the request
- 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
- Registers server classes with the IR
- Instantiates new objects
- Manages object references
- Broadcasts the presence of object servers
- Handles incoming client calls
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 Direct Access (DA) protocol provides direct access to
persistent data using a Data Definition Language
- The ODMG-93 protocol provides access to object from C++ using
ODMG's DDL
- The Dynamic Data Object protocol is used to define a structure
that contains all the data for an object
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
- Parallelism
- Breaking applications into smaller objects that cooperate increases
potential parallelism
- Objects designed to work across networks will be forced to exploit
concurrency to avoid excessive blocking
- Programming Languages
- The smaller size of objects encourages inter-procedural analysis
- All new languages can use existing object components