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

CS551 - Lecture 171

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

Yugi Lee

STB #555(816) 235-5932

[email protected]

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


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)


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


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


The LifecycleThe Lifecycle

unavailableunavailable

copycopy movemove

createcreate deletedelete

availableavailable


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.


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


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


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


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


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


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


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


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


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?


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


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


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


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

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

Documents

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