CS514: Intermediate Course in Operating Systems Professor Ken Birman Ben Atkin: TA Lecture 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 objects host a object storage server host b

Building an object Code for the object INTERFACEINTERFACE 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.idl interface 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 IDL class 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 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 void main() { grid *p = grid::_bind(“:gridSrv”); // Assumes registered under this name cout height() << endl; cout width() << endl; p->set(2, 4, 123); // set cell (2,4) to value 123 cout 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() << 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?