CS514: Intermediate Course in Operating

SystemsProfessor Ken Birman

Ben Atkin: TALecture 16 Oct. 19

Object orientation

• Primary issue:– Making a system flexible enough to handle

multiple types of clients– Permitting easy interoperation between

computing systems

• Questions to consider– Specifications (CORBA/COM IDL, XML)

• Microsoft’s .NET strategy

– Interoperability framework• CORBA or COM, Java “JINI”

– System services and “standards”

System Layers

• CORBA and Jini and COM: high-level architectures that talk about objects

• Underneath one finds RPC mechanisms, like DCE and RMI

• RMI (for Jini) is sophisticated:– All actions are treated as Java method

invocations on objects– In consequence, user can easily define new

marshalling mechanisms, or use new network transport protocols

– Not clear how widely used this will be

Corba: The Common Object Request Broker Architecture

• Role of an architecture for distributed computing: standardize system components so that developers will know what they can count on

• Corba also standardizes the way that programs interact with one another and are “managed”

• Model used is object oriented

Brief history of architectures

• Interest goes back quite far• ANSA project often identified as first to

look seriously at this issue: “Advanced Network Systems Architecture;” started around 1985

• Today, DCE and Corba are best known, but Sun uses ONC and Microsoft’s OLE2 will soon be the most important one of all

Roles of an architecture

• Descriptive: a good way to “write down” the structure of a distributed system

• Interoperability: two applications that use the same architecture can potentially be linked to each other

• Ease of development: idea is that architecture enables development by stepwise refinement

• Reliability: modularity encourages fault-isolation

Kinds of architectures

• Enterprise architecture– describes how people interact and use information

• Network information architecture– describes information within the net and relationships

between information sources, uses of info– I.e. UML: Universal Modeling Language

• Distributed application architecture: the application itself, perhaps at several levels of refinement– CORBA or COM

• Data scheme: information about fields present in an object or datum– CORBA IDL, XML, relational database schema…

Architecture can “hide” details

• Architecture may talk about the “distributed name server” as a single abstraction at one level, but later explain that in fact, this is implemented using a set of servers that cooperate.

• Data schema can say “this is a building” but smart user might learn that “it has a Groehe faucet in the kitchen”

• This perspective leads us to an object oriented perspective on distributed computing

Recent trends?

• Make “everything” accessible – use XML to standardize means of publishing object scheme– Lacks “type” information– But very flexible

• Also, provide just-in-time compilation for various platforms– Idea originated with Java JIT– But also being used in MSFT .NET for their new

language, C#– Anywhere, anytime execution capability

Distributed objects

• An object could be a program or a data object

• A program object can invoke an operation on some other kind of object if it knows its type and has a handle on an instance of it.

• Each object thus has: type, interface, “state”, location, unique handle or identifier, and perhaps other attributes: owner, age, size, etc.

Distributed objects

Object references or “handles”

Distributed objectshost a

object storage server

host b

Building an object

Code for theobject

INTERFACE

• Develop the code

• Define an interface

• Register the interface in “interface repository”

• Register each instance in “object directory”

Using an object

• Import its interface when developing your program object

• Your code can now do object invocations• At runtime, your program object must

locate the instance(s) of the object class that it will act upon

• Binding operation associates actor to target

• Object request broker mediates invocation

Invocation occurs through “proxy”

Proxy

client: obj.xyz(1, 2, 3)

Stub

xyz(1,2,3)

Invocation occurs through “proxy”

Proxy

client: obj.xyz(1, 2, 3)

Stub

xyz(1,2,3)

RPC mechanism:

RMI, DCE…

What about XML

• XML: extensible markup language– XML schema: the “pure XML” content of the

object

• Think of XML as extreme HTML • Current trend is to represent fields in

arbitrary data objects using XML schemas– Yields a kind of polymorphic type system– Purely syntactic – yet when viewed as an

interface definition, subsumes IDL

Location transparency

• Target object can be in same address space as client or remote: invocation “looks” the same (but error conditions may change!)

• JIT idea makes it easier…• Objects can migrate without informing

users• Garbage collection problem: delete

(passive) objects for which there are no longer any references

Dynamic versus static invocation

• Dynamic occurs when program picks the object it will invoke at runtime. More common, but more complex

• Static invocation occurs when the program and the objects on which it acts are known at compile time. Avoids some of the overhead of dynamic case but is less flexible

Orbix IDL for a grid object

// grid server example for Orbix// IDL in file grid.idlinterface grid { readonly attribute short height; readonly attribute short width;

void set(in short n, in short m, in long value);

long get(in short n, in short m);};

Grid “implementation class”

// C++ code fragment for grid implementation class#include “grid.hh” // generated file produced from IDLclass grid_i: public gridBOAImpl { // This is a “Basic object

adapter” short m_height, m_width; long **m_a;public: grid_i(short h, short w); // Constructor virtual ~grid_i(); // Destructor virtual short width(CORBA::Environment &); virtual short height(CORBA::Environment &); virtual void set(short n, short m, long value,

CORBA::Environment &); virtual long get(short n, short m, CORBA::Environment &);};

Enclosing program for server

#include “grid_i.h”#include <iostream.h>

void main() { grid_i myGrid(100,100); // Orbix objects can be named but this example

is not CORBA::Orbix.impl_is_ready(); cout << “server terminating” << endl;}

Server code to implement class

#include “grid_i.h”grid_i::grid_i(short h,

short w) { m_height = h;

m_width = w; m_a = new long* [h]; for (int i = 0; i < h; i+

+) m_a[i] = new long

[w];}

Server code to implement class

#include “grid_i.h”grid_i::grid_i(short h, short

w) { m_height = h; m_width

= w; m_a = new long* [h]; for (int i = 0; i < h; i++) m_a[i] = new long

[w];}grid_i::~grid_i() { for(int i = 0; i <

m_height; i++) delete[ ] m_a[i]; delete[ ] m_a;}

Server code to implement class

#include “grid_i.h”grid_i::grid_i(short h, short w) { m_height = h; m_width = w; m_a = new long* [h]; for (int i = 0; i < h; i++) m_a[i] = new long [w];}grid_i::~grid_i() { for(int i = 0; i < m_height; i++) delete[ ] m_a[i]; delete[ ] m_a;}

short grid_i::width(CORBA::Environment &){ return m_width;}short grid_i::height(CORBA::Env... &){ return m_width;}short grid_i::set(short n, short m, long value..){ m_a[n][m] = value;}short grid_i::get(short n, short m, ...){ return m_a[n][m];}

Client program

#include “grid.hh”#include <iostream.h>void main() { grid *p = grid::_bind(“:gridSrv”); // Assumes

registered under this name cout << “Grid height is “ << p->height() << endl; cout << “Grid width is “ << p->width() << endl; p->set(2, 4, 123); // set cell (2,4) to value 123 cout << “Grid(2,3) is “ << p->get(2,3) << endl; p->release();}

Our example is unreliable!

• Doesn’t check for binding failure• Doesn’t catch errors in remote

invocation... also illustrates potential problems:

neglecting to delete resources properly, or to release references, can cause system to “leak” resources and eventually fail

Notions of reliability in Corba

• Security/authentication• Catch error and “handle it”• Transactional subsystem (for

database applications; will see this in future lectures)

• Replication for high availability (also will revisit)

Despite these options, reliability is a serious problem with Corba

• Hard to use error catching mechanisms• Easy to leak resources• Transactional mechanisms: costly,

mostly useful with databases, can be complex to use

• Replication mechanisms: more transparent but also expensive unless used with sophistication

Error handling example

TRY { p = grid::_bind(“:gridSrv”); } CATCHANY { cout << “Binding to gridSrv object failed” << endl; cout << “Fatal exception “ << IT_X << endl; } TRY { cout << “Height is “ << p->height() << endl; }

CATCHANY { cout << “Call to get height failed” << endl; cout << “Fatal exception “ << IT_X << endl; } .... etc ....

Sets of objects

• Can notify Orbix that a service can be accepted from any of a set of servers

• Orbix will find one and bind to it• But later, what if that server fails?

Orbix can assist in rebinding to another, but how will application get back to the “right state” if that server might not have given identical data

Example to think about

• Bond pricing server in a trading setting• Clients download information on bond

portfolio• Server provides callbacks as prices

change, allows clients to evaluate hypothetical trades

• Switching from server to server may be very hard due to “state” built up during execution of the system prior to a failure

Roles of the Corba ORB

• Glues invoking object to target objects• ORB sees object invocation• Looks at object reference. If in same

address space, uses procedure call for invocation

• Else communicates to object RPC-style, location transparent

• Reports errors if invocation fails

Invocation occurs through “proxy”

Proxy

client: obj.xyz(1, 2, 3)

Stub

xyz(1,2,3)

Object Request Broker (ORB)

ORB-to-ORB protocol: IOP

• Allows invocation to be passed from one ORB to another, or one language to another

• Implication: Corba application running in Orbix from Iona can invoke DSOM server built by user of an IBM system!

• Runs over TCP connection, performance costs not yet known but likely to be slow at first

ORB can also find objects on disk

• Life-cycle service knows how to instantiate a stored object (or even to create an object as needed)

• User issues invocation, ORB notices that object is non-resident, life-cycle-service brings it in, invocation occurs, then object becomes passive again

• Raises issues of persistence, unexpected costs!

Some other Corba services

• Clock service maintains synchronized time

• Authentication service validates user id’s

• Object storage service: a file system for objects

• Life cycle service: oversees activation, deactivation, storage, checkpointing, etc.

• Transactions and replication services

Event notification service

• Alternative to normal binding and invocation

• Application registers interest in “events”

• Data producers publish events• ENS matches events to subscribers• Idea is to “decouple” the production of

data from the consumption of data. System is more extensible: can always add new subscribers

ENS model

produces IBM quote

consumes IBM quote

produces DEC quote consumes DEC

and IBM quotes

ENS manages a pool of events

ENS example

• Events could be quotes on a stock• Each stock would have its own class of events• Brokerage application would monitor stocks

by registering interest in corresponding event classes

• Notice that each application can monitor many types of events!

... decoupling of data producer from consumer seen as valuable form of design flexibility

Corba challenges and issues

• Much easier to “specify” services than to implement them. Some specifications may be seen as poor as implementations finally emerge

• Reliability a broad problem with architecture• Hard to use Corba half-way: frequently need to employ

technology everywhere or not at all• Hidden costs: a simple operation may invoke a

massive mechanism. Programmer must be careful!

COM and DCOM

• Microsoft’s object oriented environment– COM for local invocations– DCOM for remote ones

• Much like CORBA• But Microsoft “cuts” across the

architecture at a higher level

COM and DCOM

• CORBA says little about specific services• COM and DCOM standardize

– ODBC: database/spreadsheet interfaces– Active X: interfaces for being an object

within a document– Directory interfaces: for objects that might

reside in directories

• Effect is to standardize things like cut, paste, print, copy, move…

COM and DCOM

• COM also allows collections of objects to be created– E.g. application contains a

spreadsheet and a set of powerpoint slides

– Applications like Outlook are built this way

• Goal is to reuse large chunks of functionality in standard ways

COM and DCOM

• COM interfaces: a bit like a “type system” for a distributed programming language

• But mechanisms aren’t taken quite far enough to be a full-fledged type system

Jini and RMI

• Idea here is similar• But everything is an object

– Even an object reference or a protocol is an object

• This allows a designer to hand out, for example, an object reference that says “use multicast to talk to me”

• A powerful idea but not yet widely used

• People raise some concerns– Technology seems quite slow– “I seek you” (ICQ) mechanism is weird

.NET and Biztalk

• XML trends make it attractive to use XML as a “lingua franca” for letting arbitrary objects to talk one another

• XML is purely syntactic– But can view it as describing interfaces, like an

IDL

• .NET: a world of XML objects + JIT for C# language

• Biztalk: idea is that XML schemas are published and system automates translations for interoperability

Summary

• The world is object oriented!• But objects alone don’t give

– Reliability– Security– Scalability

• Interoperability will promote wide use of distributed computing

• Can we step into the gap with reliability solutions for the new world?