Similar to white pages. Trading: Locating components b

1
CS551 Object Oriented Middleware (VI)Advanced
Topics (Chap. 8-10 of EDO)

• Yugi Lee
• STB 555
• [phone]
• yugi_at_cstp.umkc.edu
• www.cstp.umkc.edu/yugi

2
Locating Distributed Objects (chap 8)

• Avoid using physical locations for locating
  components!
• Naming
• Locating components by external names
• Similar to white pages
• Trading
• Locating components by service characteristics
• Similar to yellow pages

3
Location Common Principles

• Object-oriented middleware uses object references
  to address server objects
• We need to find a way to get hold of these object
  references without assuming physical locations
• A name is a sequence of character strings that
  can be bound to an object reference
• A name binding can be resolved to obtain the
  object reference

4
Location Common Principles

• There may be many server objects in a distributed
  object system
• Server objects may have several names
• Leads to large number of name bindings
• Name space has to be arranged in a hierarchy to
  avoid
• Name clashes
• Poor performance when binding/resolving names
• Hierarchy achieved by naming contexts

5
Common Principles Naming Contexts
UEFA
England
Germany
Cup Winners
2. Liga
First
1. Liga
Premier
Lautern
Manchester United
QPR
Bochum
South End United
1.FC Kaiserslautern
Man United
BVB
Bayern
Chelsea
6
Common Principles Name Server Behaviour

• Name bindings are managed by name servers
• Not every server object needs a name
• Server objects may have several names (aliases)
• Name servers must store bindings persistently
• Name servers should be tuned towards efficiently
  resolving name bindings
• Name server may itself be distributed

7
Limitations of Naming

• Limitation of Naming in all approaches Client
  always has to identify the server by name.
• Inappropriate if client just wants to use a
  service at a certain quality but does not know
  from who
• Automatic cinema ticketing,
• Video on demand,
• Electronic commerce.

8
Trading

• Locating objects in location transparent way
• Naming simple but may not be suitable when
• clients do not know server
• there are multiple servers to choose from
• Trading supports locating servers based on
  service functionality and quality
• Naming White pages
• Trading Yellow Pages

9
Trading Characteristics

• Trader operates as broker between client and
  server.
• Enables client to change perspective from who?
  to what?

Trader
2query
1export
3invoke
Exporter
Importer

• Similar ideas in
• mortgage broker
• insurance broker
• stock brokerage

10
Trading Characteristics

• Common language between client and server
• Service types, Qualities of service
• Server registers service with trader.
• Server defines assured quality of service
• Static QoS definition
• Dynamic QoS definition.
• Clients ask trader for
• a service of a certain type, at a certain level
  of quality
• Trader supports
• service matching
• service shopping

11
Trading Policies

• Depending on constraint and available services, a
  large set of offer might be returned by a query.
• Trading policies are used to restrict the size of
  the matched offers
• Specification of an upper limit
• Restriction on service replacements
• Restriction on modifiable properties (these might
  change between match making and service requests)

12
Federated Traders

• Scalability demands federation of traders
• A trader participating in a federation
• offers the services it knows about to other
  traders
• forwards queries it cannot satisfy to other
  traders
• Problems
• Non-termination of import
• Duplication of matched offers

13
Distributed Object Life Cycle (Chap 9)

• Distributed object life cycle different from
  local object life cycle
• Creation
• Where to create an object
• Migration
• Where to copy/move an object to
• How to resolve heterogeneity in data and object
  code representation
• Deletion
• Garbage collection does not work

14
The Lifecycle
copy
move
available
unavailable
create
delete
15
Creation Client Programmers View

• Clients might wish to create objects on remote
  machines
• Achieved by factories
• Factory is an object that creates other objects
• Abstract factory hides creation details
• Remote machines have to be identified in a
  location transparent way
• Achieved by factory finders
• Administrators should be able to decide where to
  create new objects
• Policies are implemented using FactoryFinder
  objects.

16
Creation Server Programmers View

• Server Programmer implements factories
• Factories need to register objects with
  object-oriented middleware through middleware
  interface
• CORBA ORB Interface
• COMs SCM
• Java RMI/Registry
• Type-specific factory
• determines activation policy
• may wrap generic factory

17
Creation Administrators View

• Administrators need to provide factory finders
  that implement creation policies
• Factory finders need to be locatable by
• Naming or
• Trading
• Factory and factory finder implementations
  registered with middleware, e.g.
• CORBA Implementation Repository
• COM Windows Registry
• Java/RMI RMI Registry

18
Migration

• Objects may have to be moved or copied to other
  hosts because of
• Discontinuation of hosts
• Load balancing
• Migration
• transparent to client programmer
• not transparent to server programmer because of
  need to inherit from LifeCycleObject, implement
  copy/move operations

19
Migration Administrators View

• Migration operations are often initiated by
  administrators
• Request of copy/move operation through some
  administration tool
• Administrator needs to take same responsibilities
  as for object creation, i.e.
• Provide factory finder
• Make factory finder locatable
• Register factories and factory finder with
  middleware

20
Deletion Client Programmers View

• Implicit deletion
• Deletion is performed by garbage collector when
  object is not referenced
• More expensive due to reference counting
• Cannot be used if reference counting is not
  possible
• Can ensure referential integrity to some extent

• Explicit Deletion
• Deletion is requested by some client object when
  client assumes object is obsolete
• No overhead for reference management
• Can be used when reference counting cannot be
  performed
• No guarantees about referential integrity can be
  made

21
Deletion Administrators View

• Deletion of instances vs. deletion of types
• Instances
• Remove reference from location service
• May trigger garbage collection if location
  service held last reference
• Types
• Remove factory finders from location service
• Remove object, factory and factory finder from
  implementation repositories/registries
• Remove object and factory type definition of from
  interface repository/type library

22
Whats Missing Replication

• Copies made by life cycle service are separate
  and do not evolve together
• Life cycle service cannot be used for replication
  of stateful server objects
• Replicated objects reflect each others state
  changes and hence evolve together
• Replication used for
• load balancing
• fault-tolerance

23
Composite Objects Design

• Consist of atomic objects
• Control life cycle of atomic objects
• Use UML class diagrams for modelling of composite
  objects

24
When is Composition?

• The following questions can be used to validate
  an object composition model
• If a composite object migrates, can all its
  components migrate, too?
• If a composite object is deleted, is it ok to
  remove all its components?
• Can this component object migrate without
  deleting the composition relationship?

25
Composite Object Lifecycle

• Apply lifecycle operations to root nodes
• All nodes that are in transitive closure of
  containment relationship will be
  copied/moved/deleted
• All relationships internal to that closure will
  be copied/moved/deleted
• All objects that are connected to these nodes
  will be copied/moved/deleted

26
Object Persistence (Chap 10)

• Persistence is the ability of an object to
  survive the lifetime of the process in which it
  resides.
• Persistence is relevant for stateful server
  objects.
• The state needs to be retained between object
  deactivation and object activation

27
How to achieve Persistence?

• Storing object state on persistent datastore
  before de-activation
• Upon activation, load object state from
  persistent datastore
• Persistent storage can be
• File system
• Relational Database
• Object-Database
• Flash-RAM

28
Transparency of Persistence

• Persistence should be transparent to users and
  designers of client objects (Using a Persistent
  State Service)

Client Objects
Server Objects
Datastore Objects
Client Interface
Persistence Interface