CS514: Intermediate Course in Operating Systems Professor Ken Birman Ben Atkin: TA Lecture 16 Oct....
-
date post
18-Dec-2015 -
Category
Documents
-
view
217 -
download
0
Transcript of CS514: Intermediate Course in Operating Systems Professor Ken Birman Ben Atkin: TA Lecture 16 Oct....
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.
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)
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