View
224
Download
0
Category
Tags:
Preview:
Citation preview
CS551 - Lecture 171
CS551 Object Oriented Middleware (VI)Advanced Topics (Chap. 8-10 of EDO)
Yugi Lee
STB #555(816) 235-5932
yugi@cstp.umkc.edu
www.cstp.umkc.edu/~yugi
2CS551 - Lecture 17
Locating Distributed Objects (chap 8)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
• 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
3CS551 - Lecture 17
Location: Common PrinciplesLocation: 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
• 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
4CS551 - Lecture 17
Location: Common PrinciplesLocation: 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
• 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
5CS551 - Lecture 17
Cup
Winners
Cup
Winners
1.FC
Ka
iser
slau
tern
1.FC
Ka
iser
slau
tern
Pre
mie
rP
rem
ier First
First
M
an
Uni
ted
M
an
Uni
ted
Chelsea
Chelsea
QP
RQ
PR
South End
United
South End
United
EnglandEnglandGermany
Germany
1. L
iga
1. L
iga 2. Liga
2. Liga
BV
BB
VB
Bayern
Bayern B
ochu
mB
ochu
m
LauternLautern
UEFAUEFA
Manchester
United
Manchester
United
Common Principles: Naming ContextsCommon Principles: Naming Contexts
6CS551 - Lecture 17
Common Principles: Name Server BehaviourCommon 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
• 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
7CS551 - Lecture 17
Limitations of NamingLimitations 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.
• 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.
8CS551 - Lecture 17
TradingTrading
• 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
• 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
9CS551 - Lecture 17
Trading CharacteristicsTrading Characteristics
• Trader operates as broker between client and server.• Enables client to change perspective from ´who?´ to
´what?´
• Trader operates as broker between client and server.• Enables client to change perspective from ´who?´ to
´what?´
• Similar ideas in:– mortgage broker
– insurance broker
– stock brokerage
• Similar ideas in:– mortgage broker
– insurance broker
– stock brokerage
Exporter
Trader
Importer1:
expo
rt
1:ex
port
2:query
2:query
3:invoke3:invoke
10CS551 - Lecture 17
Trading CharacteristicsTrading 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
• 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
11CS551 - Lecture 17
Trading PoliciesTrading 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)
• 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)
12CS551 - Lecture 17
Federated TradersFederated 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
• 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
13CS551 - Lecture 17
Distributed Object Life Cycle (Chap 9)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
• 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
14CS551 - Lecture 17
The LifecycleThe Lifecycle
unavailableunavailable
copycopy movemove
createcreate deletedelete
availableavailable
15CS551 - Lecture 17
Creation: Client Programmer’s ViewCreation: Client Programmer’s 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.
• 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.
16CS551 - Lecture 17
Creation: Server Programmer’s ViewCreation: Server Programmer’s View
• Server Programmer implements factories• Factories need to register objects with object-oriented
middleware through middleware interface– CORBA ORB Interface– COM’s SCM– Java RMI/Registry
• Type-specific factory– determines activation policy– may wrap generic factory
• Server Programmer implements factories• Factories need to register objects with object-oriented
middleware through middleware interface– CORBA ORB Interface– COM’s SCM– Java RMI/Registry
• Type-specific factory– determines activation policy– may wrap generic factory
17CS551 - Lecture 17
Creation: Administrator’s ViewCreation: Administrator’s 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
• 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
18CS551 - Lecture 17
MigrationMigration
• 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
• 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
19CS551 - Lecture 17
Migration: Administrator’s View Migration: Administrator’s 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
• 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
20CS551 - Lecture 17
Deletion: Client Programmer’s ViewDeletion: Client Programmer’s 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
• 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
• 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
21CS551 - Lecture 17
Deletion: Administrator’s ViewDeletion: Administrator’s 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
• 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
22CS551 - Lecture 17
What´s Missing: ReplicationWhat´s 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 other´s state changes and hence evolve together
• Replication used for– load balancing – fault-tolerance
• 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 other´s state changes and hence evolve together
• Replication used for– load balancing – fault-tolerance
23CS551 - Lecture 17
Composite Objects: DesignComposite Objects: Design
• Consist of atomic objects
• Control life cycle of atomic objects
• Use UML class diagrams for modelling of composite objects:
• Consist of atomic objects
• Control life cycle of atomic objects
• Use UML class diagrams for modelling of composite objects:
Club Team Player1 * 1 *
1 1 consists of >has >
Game
24CS551 - Lecture 17
When is Composition?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?
• 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?
25CS551 - Lecture 17
Composite Object LifecycleComposite 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
• 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
26CS551 - Lecture 17
Object Persistence (Chap 10)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
• 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
27CS551 - Lecture 17
How to achieve Persistence?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
• 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
28CS551 - Lecture 17
Transparency of PersistenceTransparency of Persistence
• Persistence should be transparent to users and designers of client objects (Using a Persistent State Service)
• 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
Recommended