Distributed Systems UQC003H3

1
Distributed Systems UQC003H3

• OMG CORBA
• Object Location, Creation
• Access

2
The Interoperable Object Reference IOR

• An Object Reference uniquely identifies a local
  or remote object instance.
• Clients can only invoke an operation on an object
  if they hold a reference.
• Object references can be converted into strings
  and transmitted to a receiver where they can be
  converted back to a reference to invoke
  operations on that object.

3
Passing Object References Around

• CORBA applications do this all the time
• Name service, Trader do it
• Pass an object reference as a CORBA parameter
• Stringify is another way to do it
• Essential to every CORBA application

4
IOR Object Reference Semantics

• A CORBA Object Reference has semantics very
  similar to C pointers-
• Dangle
• Nil
• They are opaque, that is application code is
  not allowed to look inside a reference or make
  assumptions about its internals. It is this
  feature which provides language protocol
  transparency.

5
IOR Anatomy
An Object Reference
Used as an index into the IFR to return IDLs at
run-time.
Specifies GIOP protocol address
Identifies the object adapter that
accepts request for this particular object
NOTE A reference can contain multiple protocol
object key fields
6
Interface Repository ID

• Can be described using two formats -
• Use IDL names - IDLCERN/CRISTAL/workengine/1.0
  is a valid repository ID for the interface
  workengine where 1.0 indicates major minor
  versions.
• Use DCE UUIDs - DCE700dc50001122ceaa9f7654321
  is a repository ID which is generated by current
  date,clock time, network card ID and high
  frequency counter.

7
Transient Persistent IORs

• A transient IOR continues to work only for as
  long as it is associated server process remains
  available. Once the server shuts down the
  reference becomes permanently non-functional.
• A Persistent IOR continues to denote the same
  CORBA object even if the server shuts down and is
  restarted on another machine.

8
Binding Using a Transient Reference
IDLthisobject1.0 Milly1903 OA6, obj_523
IOR
An IIOP request or locate request message is
constructed using the given IOR
Milly
IIOP request (IN params)
Port 1903
servant
OA6 obj520 obj523 obj542 obj610
IIOP reply(return params)
Part of active object map
9
Binding Persistent IORs

• A persistent CORBA object and its corresponding
  IOR have a life cycle quite independent of that
  of its servant.
• The servant is created and destroyed when the
  server starts shuts down.
• Embedding, hostname, port number in an IOR is not
  an option. A server that wants to create
  persistent references must be registered with the
  implementation repository.

10
Registering with the Implementation Repository
The adapter name and command columns of the table
are populated by some administrative when the
server is installed. The implementation
repository runs at a well known address.
11
Binding Using a Persistent Reference
Client
IDLthisobject1.0 IMR1903 OA7, obj_523
1
4
5
6
Milly
3
IMR _at_1903
2
12
Object Migration

• When an object migrates the implementation
  repository must provide forwarding information.
• If the object migrates to a new domain then it
  must be registered in the new implementation
  repository as well as all repositories in the
  past.
• All objects associated with a POA must migrate
  together because an implementation repository
  uses POAs to find server.

13
Garbage Collection of Persistent Objects

• In general it is impossible to know when CORBA
  objects are no longer required. Object references
  can be stringified and stored and expected to be
  valid in the future. (Pacific Ocean Problem)
• However if too many persistent objects are left
  behind over time object garbage can accumulate to
  a point where performance is compromised.
• CORBA does not offer automatic garbage
  collection, it is left to application developers.

14
OBJECT CREATION

• Factories are objects that create other objects.
• To create an object, a client must
• possess an object reference for a factory and
• issue an appropriate request on the factory.
• A factory is just an object
• Has an IDL interface, implemented in some
  language
• Created as a normal part of application
  development

15
MOVING / COPYING
CLIENTS VIEW
THERE
LifeCycleObject
HERE
SOMEWHERE

• Client issue a copy/move request on a
  LifeCycleObject.
• Client passes the LifeCycleObject a Factory
  Finder.
• Clients indicate to LifeCycleObject to create
  copies or migrate within the scope of the Factory
  Finder.
• Copy assumes that the LifeCycleObject, the
  Factory Finder and the newly created object can
  all communicate via the ORB.

16
USING THE FACTORY FINDER

• LifeCycleObject uses the factory finder to find
  an appropriate factory over there.
• LifeCycleObject and factory enagage in private
  protocol to implement the move/copy.

17
LIFECYCLE INTERFACE
interface FactoryFinder Factories
find_factories(in Key factory_key)
raises(NoFactory) interface LifeCycleObject
LifeCycleObject copy(in FactoryFinder there,
in Criteria the_criteria) raises(NoFactory,
NotCopyable, InvalidCriteria, CannotMeetCriteria)
void move(in FactoryFinder there, in Criteria
the_criteria) raises(NoFactory, NotMovable,
InvalidCriteria, CannotMeetCriteria) void
remove() raises(NotRemovable) interface
GenericFactory boolean supports(in Key k)
Object create_object( in Key k, in Criteria
the_criteria) raises (NoFactory, InvalidCriteria,
CannotMeetCriteria)
18
COM-CORBA Interworking

• Motivation
• DCOM/COM /OLE/ActiveX are widely used for
  desktop integration of PC applications
• Compound documents
• Visual Basic / Visual C User Interfaces.
• OMG has little support for compound documents and
  visual user interfaces as yet.
• DCOM/COM is weak on support for distribution.
• CORBA was designed to support distribution.
• Java/Enterprise Java already work with OMG

19
CORBA-COM Interworking Specification

• Goal provide transparent bi-directional mapping
  between COM/OLE and CORBA.
• Adopted specification was submitted by consortium
  of 11 ORB vendors.
• Most of them have COM/OLE Interworking
  implemented in their ORB products.
• Adopted in March 1996.
• Microsoft decided not to be involved in this
  effort but rather pursue its own distributed
  object environment (DCOM).

20
Interworking Architecture
Object System A
Object System B
Bridge
objref in A
objref in B
target object implementa- tion in B
View in A of target in B
21
Architecture Instantiations
22
CORBA COM Mapping

• Enables COM Clients to access CORBA objects
• Fairly straight-forward mapping
• IDL atomic types map closely to COM primitives
• Constructed types also map closely
• CORBA object references map to COM interface
  pointers
• Inherited CORBA interfaces may be represented as
  multiple COM interfaces
• CORBA attributes mapped to set and get
  operations in COM.