Presentation 3: Designing Distributed Objects. Ingeniørhøjskolen i Århus Slide 2 af 32 Outline Assumed students are knowledgeable about OOP principles.

Slides:



Advertisements
Similar presentations
Threads, SMP, and Microkernels
Advertisements

Database Architectures and the Web
Programming Paradigms and languages
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 12Slide 1 Software Design l Objectives To explain how a software design may be represented.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 9 Distributed Systems Architectures Slide 1 1 Chapter 9 Distributed Systems Architectures.
Distributed Objects and Remote Invocation
Tam Vu Remote Procedure Call CISC 879 – Spring 03 Tam Vu March 06, 03.
Threads, SMP, and Microkernels Chapter 4. Process Resource ownership - process is allocated a virtual address space to hold the process image Scheduling/execution-
© Chinese University, CSE Dept. Distributed Systems / Distributed Systems Topic 2: Distributed Software Engineering Using CORBA Dr. Michael R. Lyu.
PZ13B Programming Language design and Implementation -4th Edition Copyright©Prentice Hall, PZ13B - Client server computing Programming Language.
Distributed components
Introduction To System Analysis and Design
Advanced Comm. between Distributed Objects 1 Advanced Communication Among Distributed Objects  Outline  Request synchronization  Request multiplicity.
Tutorials 2 A programmer can use two approaches when designing a distributed application. Describe what are they? Communication-Oriented Design Begin with.
1 SWE Introduction to Software Engineering Lecture 23 – Architectural Design (Chapter 13)
Object Oriented System Development with VB .NET
CS 501: Software Engineering Fall 2000 Lecture 16 System Architecture III Distributed Objects.
Scripting Languages For Virtual Worlds. Outline Necessary Features Classes, Prototypes, and Mixins Static vs. Dynamic Typing Concurrency Versioning Distribution.
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
C++ Training Datascope Lawrence D’Antonio Lecture 11 UML.
Communication in Distributed Systems –Part 2
1 Chapter 4 Threads Threads: Resource ownership and execution.
Chapter 51 Threads Chapter 5. 2 Process Characteristics  Concept of Process has two facets.  A Process is: A Unit of resource ownership:  a virtual.
Objektorienteret netværkskommunikation Presentation: Architectures for Distributed Systems.
Chapter 2 Architectural Models. Keywords Middleware Interface vs. implementation Client-server models OOP.
Networked File System CS Introduction to Operating Systems.
11 1 Object oriented DB (not in book) Database Systems: Design, Implementation, & Management, 6 th Edition, Rob & Coronel Learning objectives: What.
B.Ramamurthy9/19/20151 Operating Systems u Bina Ramamurthy CS421.
Threads, Thread management & Resource Management.
Programming in Java Unit 2. Class and variable declaration A class is best thought of as a template from which objects are created. You can create many.
CS 390- Unix Programming Environment CS 390 Unix Programming Environment Topics to be covered: Distributed Computing Fundamentals.
CS551 - Lecture 17 1 CS551 Object Oriented Middleware (VI) Advanced Topics (Chap of EDO) Yugi Lee STB #555 (816)
Introduction To System Analysis and Design
New features for CORBA 3.0 by Steve Vinoski Presented by Ajay Tandon.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 14 Slide 1 Object-oriented Design.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 20 Slide 1 Critical systems development 3.
Collaborate Lesson 4C / Slide 1 of 22 Collaborate Knowledge Byte In this section, you will learn about: The EJB timer service Message linking in EJB 2.1.
CS 501: Software Engineering Fall 1999 Lecture 12 System Architecture III Distributed Objects.
08 - StructuralCSC4071 Structural Patterns concerned with how classes and objects are composed to form larger structures –Adapter interface converter Bridge.
Presentation 3: Designing Distributed Objects. Ingeniørhøjskolen i Århus Slide 2 af 14 Outline Assumed students are knowledgeable about OOP principles.
Architecture View Models A model is a complete, simplified description of a system from a particular perspective or viewpoint. There is no single view.
CSI 3125, Preliminaries, page 1 SERVLET. CSI 3125, Preliminaries, page 2 SERVLET A servlet is a server-side software program, written in Java code, that.
Objektorienteret Netværkskommunikation (ITONK1) CORBA Introduction.
Presentation 3: Designing Distributed Objects. Ingeniørhøjskolen i Århus Slide 2 af 16 Outline Assumed students are knowledgeable about OOP principles.
© Oxford University Press 2011 DISTRIBUTED COMPUTING Sunita Mahajan Sunita Mahajan, Principal, Institute of Computer Science, MET League of Colleges, Mumbai.
Embedded Real-Time Systems Processing interrupts Lecturer Department University.
Threads, SMP, and Microkernels Chapter 4. Processes and Threads Operating systems use processes for two purposes - Resource allocation and resource ownership.
Two New UML Diagram Types Component Diagram Deployment Diagram.
1 CS 501 Spring 2002 CS 501: Software Engineering Lecture 15 System Architecture III.
Lecture 5: RPC (exercises/questions). 26-Jun-16COMP28112 Lecture 52 First Six Steps of RPC TvS: Figure 4-7.
Topic 4: Distributed Objects Dr. Ayman Srour Faculty of Applied Engineering and Urban Planning University of Palestine.
Object Interaction: RMI and RPC 1. Overview 2 Distributed applications programming - distributed objects model - RMI, invocation semantics - RPC Products.
DISTRIBUTED SYSTEMS Principles and Paradigms Second Edition ANDREW S
Chapter 3: Process Concept
Prof. Leonardo Mostarda University of Camerino
Object-Oriented Analysis and Design
Object-Oriented Network Communication (OOMI)
CS551 UML for Distributed Objects (Engineering Distributed Objects)
3. Distributed Systems – Architecture Models Part 1
Inventory of Distributed Computing Concepts and Web services
DISTRIBUTED COMPUTING
Operating Systems Bina Ramamurthy CSE421 11/27/2018 B.Ramamurthy.
Inventory of Distributed Computing Concepts
Lecture 4: RPC Remote Procedure Call CDK: Chapter 5
Outline Review of Quiz #1 Distributed File Systems 4/20/2019 COP5611.
Lecture 7: RPC (exercises/questions)
Chapter 13: I/O Systems.
Presentation transcript:

Presentation 3: Designing Distributed Objects

Ingeniørhøjskolen i Århus Slide 2 af 32 Outline Assumed students are knowledgeable about OOP principles and UML … … but a ultra short introduction to some of the UML Representations for Distributed Object Design used by Emmerich will be given –to make sure you understand Emmerich –because you will need to use this in your assignment! Local vs. Distributed Objects –How do local and distributed objects differ

Evolution of Object Technology

Ingeniørhøjskolen i Århus Slide 4 af 32 A Brief History of Objects Simula-67 Information Hiding Smalltalk C++ Eiffel Java CORBA COM OOAD UML Sun ONC DCE Programming LanguagesDistributed SystemsSoftware Engineering Time DCOM SOAP

UML Representations for Distributed Object Design

Ingeniørhøjskolen i Århus Slide 6 af 32 Use Case Diagrams ! Trainer Plan Training Schedule Manager National Soccer Association Determine League Games Player Print Personal Schedule actor use case system boundary Emmerich does not use activation arrow system need to implement!

Ingeniørhøjskolen i Århus Slide 7 af 32 Sequence Diagrams – dynamic models BvB:TeamTeddy:PlayerStefan:Player bookGoalies book() :Output printTrainingPlan Tony:Trainer asynchronous message (remote) procedure call lifeline object activation synchronous Message Object Name Type object deletion Name is pure coincidence

Ingeniørhøjskolen i Århus Slide 8 af 32 Class Diagrams – static models ! Team -name:string +bookGoalies() coaches 1..* Player -name:string -role:Position -Number:int +book() +transfer(p:Player) Club -noOfMembers:int -location:Address Trainer -name:string Organization #name:string works for 11..* uses plays in has 1 * private public protected class name attributes operations association generalization aggregation composition dependency cardinality need to implement!

Ingeniørhøjskolen i Århus Slide 9 af 32 Packages - decoupling Soccer Clubs League Management National Team Middle ware Collections of Classes that work Close together, but Decoupled from other Packages need to implement!

Ingeniørhøjskolen i Århus Slide 10 af 32 Object Diagrams – instances relationships name = “Tottenham Hotspurs” spurs:Team stefan:Player name = “Stefan Freund” role = Defender Number=4 name=“Jürgen Klinsmann” role=Forward Number = 18 klinsi:Player Object Attribute Value Object TypeObject Name Attribute Name Link

Ingeniørhøjskolen i Århus Slide 11 af 32 in team State Diagrams – instances state and transitions healthyin match injured /injury /recovered reserve playing /swap /exercise free training /finish [!in_squad] /play [in_squad] /play /finish state composite state indicates default state transition action during transition condition

Ingeniørhøjskolen i Århus Slide 12 af 32 Parallel State Composition in team on transfer list Player happy /unsatisfaction /resign /sign_contract concurrent threads final state

Ingeniørhøjskolen i Århus Slide 13 af 32 Object Has a unique identifier. May have many different references that refer to the object. Has a set of attributes whose names denote values. References may denote –equal objects –identical objects Is encapsulated by operations. May raise particular exceptions.

Ingeniørhøjskolen i Århus Slide 14 af 32 Sample Object klinsi:Player name = “Jürgen Klinsmann” role = Forward Number = 18

Ingeniørhøjskolen i Århus Slide 15 af 32 Attributes Attributes have a name and a type. Type can be an object type or a non-object type. Attributes may or may not be modifiable by other components. Attributes correspond to one or two operations (set/get).

Ingeniørhøjskolen i Århus Slide 16 af 32 Exceptions Service requests in a distributed system may not be properly executed. Exceptions are used to explain reason of failure to requester of operation execution. Operation execution failures may be –generic or –specific. Specific failures may be explained in specific exceptions.

Ingeniørhøjskolen i Århus Slide 17 af 32 Operations Operations have a signature that consists of –a name, –a list of in, out, or inout parameters, –a return value type, and –a list of exceptions that the operation can raise.

Ingeniørhøjskolen i Århus Slide 18 af 32 Operation Execution Requests A client object can request an operation execution from a server object. Operation request is expressed by sending a message (operation name) to server object. Server objects are identified by object references. Clients have to react to exceptions that the operation may raise.

Local versus Distributed Objects

Ingeniørhøjskolen i Århus Slide 20 af 32 Motivation You all have experience with designing local objects that reside in the run-time environment of an OO programming language such as: –C++ –C# –Java Designing distributed objects is different! In the next section we will –Explain the differences. –Try to avoid some serious pitfalls

Ingeniørhøjskolen i Århus Slide 21 af 32 Local vs. distributed Objects Differences between local and distributed objects in: –References (to objects) –Activation/Deactivation –Migration –Persistence –Latency of Requests –Concurrency –Communication –Security

Ingeniørhøjskolen i Århus Slide 22 af 32 Object Lifecycle If we look at local vs distributed objects lifecycles we see that: –OOPL objects reside in one virtual machine. From creation to deletion –Distributed objects might be created on a different machines Not possible to use OOPL’s creation operators Need to design features for it Should be independent of server location –Distributed objects might be copied or moved (migrated) from one machine to another To avoid overloading of a server This will not happen with local objects –Deletion by garbage collection does not work in a distributed setting. To difficult to maintain referential integrity –Lifecycle needs attention during the design of distributed objects. We will visit Life Cycle closer in Chapter 9

Ingeniørhøjskolen i Århus Slide 23 af 32 Object References References to objects in OOPL are usually pointers to memory addresses –sometimes pointers can be turned into references (C++) –sometimes they cannot (Smalltalk,Java) References to distributed objects are more complex –Location information (which server, how to communicate) –Security information (now not anymore a protected process) –References to object types (might differ – which server is in control – adminstrators forgetting to synchronize) èReferences to distributed objects are bigger (e.g 40 bytes with Orbix small footprint) – èAs opposed to 4 bytes for 32 bit references on OOPL VM’s èand possible up 400 if security is tightly integrated èTo virtual memory consuming for clients holding references

Ingeniørhøjskolen i Århus Slide 24 af 32 Latency of Requests Performing a local method call requires a couple of hundred nanoseconds. An object request requires between 0.1 and 10 milliseconds. –And possible more depending on the network –And the size of the objects èInterfaces of distributed objects need to be designed in a way that –operations perform coarse-grained tasks –do not have to be requested frequently Therefore: –Be vary of turning everything into objects –Use Façade patterns instead – and decouple

Ingeniørhøjskolen i Århus Slide 25 af 32 Activation/Deactivation Objects in OOPL are in virtual memory between creation and destruction. This might be inappropriate for distributed objects –They are bigger than local objects (take up more space) –Combined with sheer number of objects … –Results in problems with capacity of server (virtual memory) –Also: objects might not be used for a long time –And: some hosts might have to be shut down without stopping all applications Distributed object implementations are –brought into main memory (activation) –discarded from main memory (deactivation)

Ingeniørhøjskolen i Århus Slide 26 af 32 Activation/Deactivation (cont’d) BvB:Team bookGoalies Tony:Trainer object activated object Deactivation -Might need to serialize to maintain state

Ingeniørhøjskolen i Århus Slide 27 af 32 Activation/Deactivation (cont’d) Several questions arise –Explicit vs. implicit activation (transparent for the programmer) –When to deactivate objects Need to persist the state –Association between objects and processes –How to treat concurrent requests Even across servers Who decides answers to these questions? –Designer –Programmer –Administrator –Middleware – but designer must provide persistence facilities

Ingeniørhøjskolen i Århus Slide 28 af 32 Persistence Stateless vs. statefull objects Statefull objects have to save their state between –object deactivation and –object activation onto persistent storage Can be achieved by –externalization into file system –mapping to relational database –object database To be considered during object design Statefull objects are more expensive to make redundant –Need to replicate more between servers More of this in chapter 10

Ingeniørhøjskolen i Århus Slide 29 af 32 Parallelism Execution of OOPL objects is often –Sequential in a process –concurrent (with multi-threading or multi processor) Distributed objects execute in (true) parallel –Same object might reside on more than one computer –How to maintain concurrency across computers? –See Chapter 11 ; ) or the Concurrency Course

Ingeniørhøjskolen i Århus Slide 30 af 32 Communication Method invocations of OOPL objects are synchronous –Because it is fast and performant –But it does block the calling object Though not for long Alternatives for distributed objects: –synchronous requests Nice – but not always performant due to latency Blocks the calling object for to long –oneway requests –deferred synchronous requests –asynchronous requests Who decides on request –Designer of server? –Designer of client? More on this in Chapter 7

Ingeniørhøjskolen i Århus Slide 31 af 32 Failures Distributed object requests are more likely to fail than local method calls –More points of failures Server(s) Client Network Different request reliabilities are available for distributed objects –Exactly-once semantics to demanding on latency –Instead At-most-once – only tries once – but inform of failing (Exception) Clients have an obligation to validate that servers have executed request –Meaning: has to check for exceptions –Need to use transactions (all or nothing) – with roll back capabilities More on this in Chapter 7

Ingeniørhøjskolen i Århus Slide 32 af 32 Security Security in OO applications can be dealt with at session level –Only need to authenticate the user at process/session start OOPL Objects do not have to be written in a particular way. –Security lies in one process (maybe more tasks) For distributed objects: –Who is requesting an operation execution? –How can we know that subject is who it claims to be? –How do we decide whether or not to grant that subject the right to execute the service? We need to use secure connections and object level security –How can we prove that we have delivered a service so as to make the requester pay –Answers in chapter 12 – and the Course dDistSik