CS551 - Lecture 17 1 CS551 Object Oriented Middleware (VI) Advanced Topics (Chap. 8-10 of EDO) Yugi Lee STB #555 (816) 235-5932

Slides:



Advertisements
Similar presentations
What is RMI? Remote Method Invocation –A true distributed computing application interface for Java, written to provide easy access to objects existing.
Advertisements

Distributed Systems 1 Topics  What is a Distributed System?  Why Distributed Systems?  Examples of Distributed Systems  Distributed System Requirements.
GridRPC Sources / Credits: IRISA/IFSIC IRISA/INRIA Thierry Priol et. al papers.
Objektorienteret Middleware Presentation 2: Distributed Systems – A brush up, and relations to Middleware, Heterogeneity & Transparency.
Distributed components
Semantic description of service behavior and automatic composition of services Oussama Kassem Zein Yvon Kermarrec ENST Bretagne France.
Distributed Systems Architectures
CORBA Case Study By Jeffrey Oliver March March 17, 2003CORBA Case Study by J. T. Oliver2 History The CORBA (Common Object Request Broker Architecture)
OOP in Java Nelson Padua-Perez Chau-Wen Tseng Department of Computer Science University of Maryland, College Park.
CS490T Advanced Tablet Platform Applications Network Programming Evolution.
CS 501: Software Engineering Fall 2000 Lecture 16 System Architecture III Distributed Objects.
Advanced Topics COMP163: Database Management Systems University of the Pacific December 9, 2008.
7M701 1 Class Diagram advanced concepts. 7M701 2 Characteristics of Object Oriented Design (OOD) objectData and operations (functions) are combined 
Designing Distributed Objects 1 Distributed Objects  Objective  Understand the difference between local and distributed objects and how to correctly.
EEC-681/781 Distributed Computing Systems Lecture 3 Wenbing Zhao Department of Electrical and Computer Engineering Cleveland State University
II. Middleware for Distributed Systems
Practical Issues of RPCCS-4513, D-Term Remote Procedure Call Practical Issues CS-4513 Distributed Computing Systems (Slides include materials from.
C++ Training Datascope Lawrence D’Antonio Lecture 11 UML.
Communication in Distributed Systems –Part 2
Naming Names in computer systems are used to share resources, to uniquely identify entities, to refer to locations and so on. An important issue with naming.
Object-oriented design CS 345 September 20,2002. Unavoidable Complexity Many software systems are very complex: –Many developers –Ongoing lifespan –Large.
Sharif University of Technology Session # 7.  Contents  Systems Analysis and Design  Planning the approach  Asking questions and collecting data 
Data Access Patterns. Motivation Most software systems require persistent data (i.e. data that persists between program executions). In general, distributing.
Common Object Request Broker Architecture (CORBA) CS-328.
1 J2EE Components. 2 Application Servers relieve the programming burden for business distributed components. They provide support for system level services.
Understanding the CORBA Model. What is CORBA?  The Common Object Request Broker Architecture (CORBA) allows distributed applications to interoperate.
Ceg860 (Prasad)L6MR1 Modularity Extendibility Reusability.
1 Chapter 10: Data Abstraction and Object Orientation Aaron Bloomfield CS 415 Fall 2005.
1 Introduction to Middleware. 2 Outline What is middleware? Purpose and origin Why use it? What Middleware does? Technical details Middleware services.
New features for CORBA 3.0 by Steve Vinoski Presented by Ajay Tandon.
Introduction to dCache Zhenping (Jane) Liu ATLAS Computing Facility, Physics Department Brookhaven National Lab 09/12 – 09/13, 2005 USATLAS Tier-1 & Tier-2.
CORBA IS 8030 – Integrated Computing Environments Dr. Hoganson CORBA Common Object Request Broker Architecture Published by Object Management Group (OMG)
Dynamic Invocation Interface Alternative to using IDL stubs Object cannot distinguish between the two. How is DII different for the programmer?
RMI remote method invocation. Traditional network programming The client program sends data to the server in some intermediary format and the server has.
Prepared By Prepared By : VINAY ALEXANDER ( विनय अलेक्सजेंड़र ) PGT(CS),KV JHAGRAKHAND.
CSC 480 Software Engineering Lecture 18 Nov 6, 2002.
An information and monitoring system for static and dynamic information about grid resources, applications, networks … RDBMS Servlet aware of API during.
Distribution and components. 2 What is the problem? Enterprise computing is Large scale & complex: It supports large scale and complex organisations Spanning.
CS551 - Lecture 15 1 CS551 Object Oriented Middleware (IV) Dynamic Requests (Chap. 6 of EDO) Yugi Lee STB #555 (816)
COMP3190: Principle of Programming Languages
Common Object Request Broker Architecture (CORBA) The Common Object Request Broker Architecture (CORBA) is a specification of a standard architecture for.
CS 501: Software Engineering Fall 1999 Lecture 12 System Architecture III Distributed Objects.
CS551 - Lecture 11 1 CS551 Object Oriented Middleware (III) (Chap. 5 of EDO) Yugi Lee STB #555 (816)
Design and Implementation of a Rationale-Based Analysis Tool (RAT) Diploma thesis from Timo Wolf Design and Realization of a Tool for Linking Source Code.
Database Management Systems (DBMS)
CS451 - Lecture 2 1 CS451 Lecture 2: Introduction to Object Orientation Yugi Lee STB #555 (816) * Acknowledgement:
Presentation 3: Designing Distributed Objects. Ingeniørhøjskolen i Århus Slide 2 af 14 Outline Assumed students are knowledgeable about OOP principles.
A facilitator to discover and compose services Oussama Kassem Zein Yvon Kermarrec ENST Bretagne.
Tom Meyer, Iowa State SCT/Pixel Online Workshop June, 2001 CORBA Common Object Request Broker Architecture.
Introduction to Active Directory
Component Patterns – Architecture and Applications with EJB copyright © 2001, MATHEMA AG Component Patterns Architecture and Applications with EJB Markus.
CS551 - Lecture 12 1 CS551 Object Oriented Middleware (IV) Dynamic Requests (Chap. 6 of EDO) Yugi Lee STB #555 (816)
Presentation 3: Designing Distributed Objects. Ingeniørhøjskolen i Århus Slide 2 af 16 Outline Assumed students are knowledgeable about OOP principles.
1 CS 501 Spring 2002 CS 501: Software Engineering Lecture 15 System Architecture III.
Topic 4: Distributed Objects Dr. Ayman Srour Faculty of Applied Engineering and Urban Planning University of Palestine.
Databases and DBMSs Todd S. Bacastow January 2005.
Java Distributed Object System
Common Object Request Broker Architecture (CORBA)
What is RMI? Remote Method Invocation
Distribution and components
Knowledge Byte In this section, you will learn about:
Data, Databases, and DBMSs
Component--based development
Bina Ramamurthy Chapter 9
Bina Ramamurthy Chapter 9
Outline Announcements Lab2 Distributed File Systems 1/17/2019 COP5611.
Bina Ramamurthy Chapter 9
Outline Review of Quiz #1 Distributed File Systems 4/20/2019 COP5611.
Java Remote Method Invocation
Presentation transcript:

CS551 - Lecture 17 1 CS551 Object Oriented Middleware (VI) Advanced Topics (Chap of EDO) Yugi Lee STB #555 (816)

2 CS551 - Lecture 17 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

3 CS551 - Lecture 17 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 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 CS551 - Lecture 17 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 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 CS551 - Lecture 17 Cup Winners Cup Winners 1.FC Kaiserslautern 1.FC Kaiserslautern Premier First Man United Chelsea QPR South End United South End United England Germany 1. Liga 2. Liga BVB Bayern Bochum Lautern UEFA Manchester United Manchester United Common Principles: Naming Contexts

6 CS551 - Lecture 17 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 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 CS551 - Lecture 17 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. 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 CS551 - Lecture 17 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 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 CS551 - Lecture 17 Trading 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 Importer 1:export 2:query 3:invoke

10 CS551 - Lecture 17 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 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 CS551 - Lecture 17 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) 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 CS551 - Lecture 17 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 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 CS551 - Lecture 17 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

14 CS551 - Lecture 17 The Lifecycle unavailable copy move create delete available

15 CS551 - Lecture 17 Creation: 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.

16 CS551 - Lecture 17 Creation: 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

17 CS551 - Lecture 17 Creation: 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

18 CS551 - Lecture 17 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 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 CS551 - Lecture 17 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

20 CS551 - Lecture 17 Deletion: 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

21 CS551 - Lecture 17 Deletion: 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

22 CS551 - Lecture 17 What´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

23 CS551 - Lecture 17 Composite 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: ClubTeamPlayer 1 * 1 * 11 consists of >has > Game

24 CS551 - Lecture 17 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?

25 CS551 - Lecture 17 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 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 CS551 - Lecture 17 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

27 CS551 - Lecture 17 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

28 CS551 - Lecture 17 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