Distributed Objects and Middleware Spring System

1
Distributed Objects and Middleware Spring System
2
Background

• What are objects?
• Why objects?
• How do you distinguish object-oriented design
  versus procedural design?
• Pros and cons of object-orientation?
• Where to apply object-orientation?
• Spring Kernel is one instance of applying object
  orientation in the design of the kernel
• Key point If object-orientation is good at the
  kernel level it should be good at higher levels
  as well!

3
Issues in Large system software

• Cost of maintenance
• Difficulty of building distributed, multithreaded
  applications
• Difficulty of supporting (soft) real-time
  constraints for certain applications (e.g. media)
• Unified naming scheme
• Security concerns in a networked setting

4
How do you innovate in OS?

• Better implementation of accepted OS technology
  (i.e. Unix in case of a company like Sun)
• Brand new system the provides capabilities not
  available in standard OSs
• Spring approach
• Be different but
• Innovate where it makes sense
• Make sure third party vendors will develop
  software against the new APIs
• Preserve all the good things in standard OS
• Use object orientation for all of the reasons
  discussed

5
Flexibility Vs. Standards Vs. Performance
Conundrum

• Good performance on a variety of platforms
• Memory protection, VM, and mapped file systems
• Standard services (network protocols,
  interoperability)
• Windows, GUI, and other end user look and feel

6
Spring Choices

• Strong interfaces
• What is exposed but not how
• Naturally leads to object orientation
• Open, flexible, and extensible
• Naturally leads to microkernel based approach
• Naturally leads to IDL to avoid being tied to a
  particular language for all the system components
• OMGs IDL since IDL compilers implemented by
  several third party software vendors

7
IDL Compiler?

• Language specific header file from IDL
  description
• Client side stub code
• Server side stub code
• IO interface in IDL

Interface_io raw_data read(in long size)
raises (access_denied, alerted, failure,
end_of_data) void write(in raw_data data)
raises (access_denied, alerted,
incomplete_write, failure, end_of_data)
8
Objects in Spring

• Server based objects
• Automatic stub generation
• Client and server in same address space
• By pass kernel optimization (via subcontracts)

9

• Serverless objects
• Entire object state copied into the client
  application

10
Subcontract

• Mechanism to hide the runtime behavior of an
  object from the interface
• Example
• A singleton implementation
• A replicate implementation
• Client does not know or care
• More later.

11
Overall system
Micro kernel
12
Nucleus

• Springs microkernel
• Manages processes and IPC
• Abstractions
• Domains
• Container for threads and doors
• Threads
• Door
• An entry point in a domain
• Represented by PCstate (e.g. ptr to a C obj)
• Possessor gets to make invocations on target
  domain
• Can be passed around from domain to domain (a
  software capability)

13
Domain, doors, and door tables
Private to each domain
14
Object invocation

• Nucleus involved in door calls
• Server thread allocated in target domain
• Control transferred to the server thread
• On return called thread deactivated and the
  calling thread reactivated
• Fast cross address space calls via doors
• 11 usec on SPARC2

15
Cross machine Object Invocation

• Invocation mechanism extended by network proxies
• Each proxy potentially different protocol
• Transparent to the client and server
• Door id network handles in the proxies
• Network handles not easily forgeable

16
Springs security model

• Access control lists
• Checked at runtime
• Software capability
• Object reference serves as a capability
• Uses nucleus door as part of its rep gt not
  easily forged
• Points to front object (non-spring obj)
• Whatever server defines an object to be
• Can be passed around
• E.g. user wants to print file foo

17
Secure object invocation
Front object checks the ACL before letting the
invocation proceed
18
Virtual Memory

• Per-machine Virtual Memory Manager
• Mapping, sharing, protection, transferring, and
  caching of local memory
• Clients
• Address space object
• Virtual address space of a spring domain
• Memory object
• Abstraction of memory (e.g. can be a file) that
  can be mapped into address space

19
Address space and memory objects
An address space is a linear range of addresses
with regions mapped to memory objects. Each
region is mapped to a (part of) a memory object.
Each page within a mapped region may be mapped
with read/write/execute permissions and may
be locked in memory.
20
Cache and Pager

• VMM can bind an address space object to a memory
  object
• Multiple memory objects may be equivalent (map
  the same file on disk)
• Two way connection between VMM and external pager
  for coherence of cached pages
• Pagers free to implement whatever coherence
  policy
• Spring default single writer/multiple reader

21
Pager-Cache Objects Connections
In this example, Pager 1 is the pager for two
distinct memory objects cached by VMM 1, so there
are two pager-cache object connections, one for
each memory object. Pager 2 is the pager for a
single memory object cached at both VMM 1 and VMM
2, so there is a pagercache object connection
between Pager 2 and each of the VMMs.
22
File system

• File object interface
• Inherits from memory object and IO object
• They can be memory mapped
• They can be read/written
• SFS
• Disk layer implements Unix semantics
• Coherency layer provides single writer/multiple
  writer coherence semantics

23
Naming

• Unified naming architecture for all objects
• Files, devices, users, services, etc.
• Frees clients from having to deal with difference
  naming conventions for different resources
• Frees services from having to invent a naming
  scheme (if they choose not to)
• Context
• An object that contains name to object
  associations
• An object can be unnamed as well!
• Name space
• A graph of contexts
• Context and name spaces are first class objects
• Directly manipulable

24
Unix Emulation

• Runs as user level code
• Implements only Unix specific features not
  directly supported by Spring
• Inherits all other features from Spring
• No modification to base Spring system

25
Spring and its aftermath

• Solaris MC (stands for multi-computer)
• Grew out of Spring effort