Modern Operating Systems

1
Modern Operating Systems

• Lecture 8/9
• Distributed Computing CORBA

2
From Mainframe Applications...
Terminal Access
Mainframe Data and Applications
3
...to Client/Server Applications...
Windows Client
Mac Client
Oracle, DB2, MS SQL, Informix, Sybase, etc.
Unix Client
Fat Client
Back-end Data
4
to Multi-tier DistributedApplications
Application Server
WindowsClient
Middle-Tier ServicesBusiness Processes
BrowserClient
JavaClient
Oracle, DB2, MS SQL, Informix, Sybase
MobileClient
Middle Tier(NT/Unix)
Thin Client
Back-end Data
5
Enterprise Computing

• Enterprises have a variety of computing platforms
• Unix, 95/98/NT, AS/400, VMS, Macintosh etc.
• Enterprises write applications in a variety of
  programming languages
• C, C, Java, COBOL, Basic, Perl, Smalltalk, etc.
• Enterprises need an open architecture to support
  the heterogeneous environment

6
Object-Oriented Computing for the Enterprise

• Enterprise applications are being written in
  terms of objects - reusable components that can
  be accessed over the enterprise network
• CORBA supplies the architecture for distributed
  applications based on open standards

7
Distributed Application Advantages

• Scalability
• Server replication
• Thin, heterogeneous clients
• Re-usability
• Partitioned functionality easy updating of
  either clients or servers

8
Competing Technologies for Distributed Objects

• Open standards based solutions
• Java, CORBA, EJB, RMI, IIOP, JTS/OTS, JNDI,
  JDBC,, Servlets, JSP, Java Security
• The All-Microsoft solution
• COM, COM, ActiveX, Visual C, MTS, ASP, IIS,
  etc.
• Other proprietary solutions
• Message oriented middleware (MOMs - MQSeries,
  etc.)
• TP monitors

9
TP Monitors, Web Front-Ends

• Quickly extends an existing application for
  access from the web
• Client context maintained by server

• Limited to single process, single machine
• Not object oriented or truly distributed
• Jolt server consumes an additional process
• Jolt client classes must be either pre-installed
  or downloaded

10
COM/DCOM, COM

• Rich, well-integrated platform
• Object-oriented
• Web client access via
• ActiveX controls COM/DCOM
• Active Server Pages, HTTP and IIS
• Distributed - as long as its Windows

• NT only
• Firewall issue
• Limited flexibility
• Security

11
CORBA vs. Ad-hoc Networked Applications

• Technical considerations
• CORBA/EJB implementations have integration with
  object databases, transaction services, security
  services, directory services, etc.
• CORBA implementations automatically optimize
  transport and marshalling strategies
• CORBA implementations automatically provide
  threading models

12
CORBA vs. Ad-hoc Networked Applications

• Business considerations
• Standards based
• Multiple competing interoperable implementations
• Buy vs. build tradeoffs
• Resource availability
• software engineers
• tools

13
CORBA

• Product of consortium - Object Management Group
  (OMG) with more 800 members.
• Accepted proposals for the various specifications
  put forth to define
• Communications infrastructure
• Standard interface between objects
• Object services
• Developed the spec for the Common Object Request
  Broker Architecture (CORBA)

14
CORBA Design Goals

• Transparency
• The programming language
• The hardware platform
• The operating system
• The specific object request broker
• The degree of object distribution
• Open Architecture
• Language-neutral Interface Definition Language
  (IDL)
• Language, platform and location transparent
• Objects could act as clients, servers or both
• The Object Request Broker (ORB) handles
  interaction between client and object

15
CORBA Design Goals

• Transparency
• Language - can be used by any programming
  language for which there is an IDL mapping.
• Hardware platform - independent of processor data
  type formats
• Operating system - not embedded in O/S, does not
  rely any O/S specific APIs.
• Object request broker - ORBs can be implemented
  by any vendor, ORBs should be able to interface
  to each other. Not tied to one vendor.
• Degree of object distribution - all objects may
  be local or remote or any combination. May be
  provided by in-process server or process based
  server.or
• Objects can act as clients, servers or both.

16
CORBA Objects

• OMG definition - encapsulated entity with an
  immutable distinct identity whose services are
  accessed only through well defined interfaces.
• Binary components on various hosts that remote
  clients can access via method invocation.
• How object implemented is completely transparent
  to client.
• O/S, language, compiler ..
• Client does not need to know where object is or
  which O/S it runs under.
• Interface defined by IDL.

17
OMG Interface Definition Language

• Client must know interface offered by object
  before invoking an operation
• Objects interface
• operations
• types of data that can be passed to/from
  operations
• Object interface defined using IDL.

18
Language Mappings

• Specifies how IDL translated into different
  programming languages.
• Language support varies between suppliers of
  ORBs.
• Example - C
• Interfaces mapped to classes
• Operations mapped to member functions of classes
• Object references map to the operator-gt function

19
A CORBA ORB(Client)
Interface Repository
Object Request Broker Core (IIOP)
Protocol Stack
Network
20
A CORBA ORB(Server)
21
General Request Flow
Request
Object Adaptor
Server ORB Core
Client ORB Core
Network
22
General Request Flow

• Client makes request and server receives and acts
  on it.
• Flow
• 1. Client makes request using static stubs (IDL)
  or Dynamic Invocation Interface (DII) into ORB
  core linked to process.
• 2. Client ORB transmits request to ORB core
  linked with server.
• 3. Server ORB core dispatches request to object
  adapter (OA) that created target object.
• 4. OA dispatches request to servant (class
  instance in C) that implements target object
  using static skeletons or Dynamic Skeleton
  Interface (DSI).
• 5. Servant returns response to client.

23
Interface Repository

• Produced by IDL compiler.
• Distributed database containing machine readable
  version of IDL defined interfaces.
• Contains information describing
• Operations supported by server
• Parameters to operations
• Used for dynamic invocation of operations
• Clients can query repository to find out how to
  invoke operation at run-time.

24
ImplementationRepository

• Used client ORB to locate servers for requested
  class/operation.
• Run-time repository
• classes supported by server
• instantiated objects IDs

25
Object Request Broker - ORB

• Transports a client request to a local or remote
  object and returns the result. Implemented as
• a set of client and server side libraries
• zero or more daemons in between, depending on ORB
  implementation
• ORB transparently activates objects that are not
  running.
• Provides
• Static method invocation - defined at
  compile-time
• Dynamic method invocation - find objects at
  run-time

26
Operation Invocation

• Static invocation
• Client IDL stubs and server IDL skeletons created
  from IDL
• Compiler knows at compile time name and
  parameters of operations - strong typing.
• Dynamic invocation
• Operation invocation built at run-time.
• No compile info - weak typing
• Requires access to Interface Repository service
  to build request
• contains details of interfaces and types
• generated from IDL

27
Object Adapter (OA)

• An abstract specification
• Part of the server-side library - the interface
  between the ORB and the server process
• Once server registers with ORB, listens for
  client connections and requests
• Maps the inbound requests to the desired target
  object instance - makes the operation call and
  handles return data
• Real OAs
• Basic Object Adapter (BOA)
• requires proprietary extensions to be useful
• Portable Object Adapter (POA)
• Permits server-side ORB-neutral code

28
IIOP - Internet Inter-ORB Protocol

• General Inter-ORB Protocol (GIOP)
• Abstract protocol, specifies transfer syntax and
  message formats.
• IIOP - implementation of GIOP using TCP/IP
• Developers dont need to learn IIOP
• the ORB handles this for them
• Specifies common format for
• object references, known as the Interoperable
  Object Reference (IOR)
• Messages exchanged between a client and the object

29
Request Invocation

• Clients manipulate objects by asking its ORB to
  send message to object via server ORB.
• How does client uniquely identify object?
• Client needs object reference before sending
  messages.
• Object reference - handle that uniquely
  identifies target object.

30
Client Invokes Operation via Object Reference

• Client ORB
• Locates target object
• Activates server application if not running
• Transmits arguments for call to object
• Activates instance for object if necessary
• Instance could be generated by factory object if
  used.
• Waits for request to complete
• Returns out and inout parameters and return value
  to client.
• Returns an exception if call fails
• All this is transparent to client!

31
Request Invocation Characteristics

• Location transparency
• Client does not know or care whether target
  object is local to its own address space, in a
  different process on the same machine or in a
  process on a different machine.
• Server transparency
• Client does not need to know which server
  implements which objects.
• Language independence
• Implementation language for client and sever
  objects can be different.
• Implementation independence
• Client does not know how server implements
  object.
• Architecture independence
• CPU architecture hidden from client
• Operating system
• Server could be implemented under UNIX, NT or
  real-time OS.
• Protocol independence
• Client does not know how messages are sent to
  object.

32
Object References

• Only way to access an object
• Also called Interoperable Object Reference (IOR)
• Distributed computing equivalent of a pointer
• Analogous to C class instance pointers
• class name
• void amethod()
• ....
• name pname new name
• ....
• pname-gtamethod()
• Object References are opaque
• Implementation - not real pointers!

33
Reference Acquisition

• Published by server somehow.
• Return a reference as result of invoking an
  operation
• Advertise reference in well-known service
• Naming Service, Trader Service
• Convert object reference to string and write to
  file
• Transmit object reference using out-of-band
  mechanism
• Email
• Web page
• Result of invoking an operation is the normal
  way.
• Others used to get first object reference.

34
Interoperable Object Reference (IOR)

• Repository ID - used to locate detailed
  description of interface in Interface Repository
• Endpoint Info - info required to make physical
  connection to server, includes
• protocol
• address data - IP/port if IIOP is used (TCP)
• or
• address of implementation repository that
  contains location of server

35
Interoperable Object Reference (IOR)

• Object key - includes object identifier
• Used by server Orb/OA to identify target object
  in sever for each request
• Server creates identifier when server creates
  object reference
• IORs can be converted from raw reference to
  string form, and back
• Stringified IORs can be stored and retrieved by
  clients and servers using other ORBs

36
Interoperable Object Reference (IOR)

• A stringified IOR
• IOR010000000e00000049444c3a48656c6c6f3a312e300000
  0001000000000000003000000001010000100000003132382e
  3130302e3130302e313032008a040000100000000000000006
  a33c37c0aa080000000000

37
Simple Example

• IDL
• interface Add
• short add(in short a, in short b)
• Server implements operation add()
• Client uses remote object to add two numbers

38
Simple Example - Server

• Create/initialise ORB and BOA
• Create implementation object and tell ORB about
  it
• Save object reference as string in file for
  client
• Run implementation

39
Simple Example - Client

• Create/initialise ORB
• Read in IOR from file for add object
• Convert string version of IOR to object reference
• Read in two numbers
• Invoke add operation on add object
• Print result

40
CORBA Services

• Collection of system-level services with IDL
  specified interfaces.
• Provide functionality required by most
  distributed applications.
• Effectively augment functionality of ORB.
• Independent of application domain.
• Designed according to principle
• A service does only one thing but does it well!

41
CORBA Services

• Naming Service
• Allows local or remote objects to be located by
  name.
• Event Service
• Allows objects to dynamically register/unregister
  their interest in specified events. Object will
  be notified when event occurs.
• Many more including
• Trader, Life Cycle, Persistence, Transaction,
  Query, Security

42
Naming Services

• Maps human readable names to object references.
• Given a name the service returns an object
  reference.
• Object reference can be used to invoke operations
  on object.
• Objects referenced by compound name
• Sequence of names forming a hierarchical naming
  tree
• Analogous to directory structure

43
Naming Services
context name
simple name
44
Naming Services

• Advantage over stringified references
• Client uses meaningful names instead of
  stringified object references.
• Old version of object can be replaced by new
  version by updating Name Service entry IOR for
  object.
• Solves problem of getting initial references to
  objects.

45
Event Services

• Allows objects (consumer) to dynamically register
  and unregister interest in events occurring in an
  object
• Event - occurrence in an object (supplier) of
  interest to one or more objects
• signal a change of state of object, typically
  data
• Notification - message sent to notify event
  occurred
• Two ways of handling events
• Event channel - standard CORBA object
• Point-to-point
• Two models - push and pull

46
Push Style
Event house is on fire
Oh the house is on fire
Event Channel
Consumer
Supplier
Consumer
Push
Push
Object Request Broker
Event channel handles pushes to consumers
47
Pull Style
Event house is on fire
What is happening?
Event Channel
Consumer
Supplier
Consumer
Pull
Pull
Object Request Broker

• Event channel handles pull from supplier.
• Event manages suppliers consumers.

48
Point-to-Point
Push
Object Request Broker

• Disadvantage
• Supplier must keep track of all consumers.
• Consumer must keep track of all supplier.