Clients and Servers

1
Clients and Servers

• Clients
• Portable, either static (stub) or dynamic (DII)
• Multithread for responsiveness (callbacks)
• Server issues
• scalability
• Many clients Multithreading
• Many servants Object Adapter
• support for persistent objects
• maintenance
• portability

2
Server Scalability

• Many clients concurrently connected
• multithreaded ORB
• Many servants supported (many IORs)
• either factory generated copies representing the
  same interface, or servants for different
  interfaces
• cant all be resident in memory
• object activation

3
Multithreaded Servers

• ORB itself is multithreaded. Typically three
  thread policies (ORB dependent)
• single-threaded
• thread per connection
• thread per request (also pooling)
• The application programmers (writes servant
  code) responsibility
• Write thread safe servants
• No need for explicit multithreaded servants
  (except callbacks)

4
Safe Multithreading

• Is the servant thread safe?
• Counter example (sum is shared data)
• Fix by
• choose a single-threaded ORB (via a POA policy)
• synchronize access to shared data (make the
  increment() method synchronized )
• How do you ensure Database consistency for your
  3-tier assignment?
• Factory generated servants only called by one
  single-threaded client may be OK

5
Maintenance and Portability

• Maintenance
• Distributed garbage collection
• Graceful shutdown
• Portability
• CORBA 2.0 underspecified in this area (BOA)
• Portable Object Adapter (POA)

6
Persistent Objects

• A persistent object is one for which the IOR is
  valid for longer than the lifetime of the server
  process that created it. Usually it has state.
• Distinguish
• Servant - the implementation in memory
• The object reference
• Must be able to manage these separately

7
Object and Servant Lifecycle
Object Existent
Servant Incarnated
Object Non-existent
Object Non-existent
Activate Object
Deactivate Object
Servant Etherealized
8
The Illusion of Persistence

• server receives a request with a given IOR
• check to see if the servant representing this IOR
  is incarnate -- it is actually etherealized
• get the Object ID from the IOR (hidden in the
  Object key part of the IOR)
• access a database or filestore using this key to
  obtain the state of the object
• activate the object by incarnating the servant
  with the correct state
• dispatch the method request as usual

9
Requirements for Persistence

• The server must be able to control object
  activation by incarnating and etherealizing the
  servant
• Server must be able to access stored state of the
  object using information in the IOR

10
Object Activation

• Necessary to support
• many servants (too many to be all in memory)
• persistent objects (activate on demand)
• The Object Adapter is a layer between ORB and
  servants that manages activation
• The Object Adapter also
• manipulates IORs
• dispatches requests to the correct servant
• reduces the ORB complication

11
Object Adapters

• A layer between ORB and skeletons/DSI
• Basic Object Adapter (BOA)
• CORBA 2.0, underspecified (deliberately)
• Not part of Java mapping
• Java mapping includes connect, disconnect, that
  do not require an OA. Transient objects only.
• Portable Object Adapter (POA)
• CORBA 2.3
• New, so few ORBs implement it