Slide 1 © Ingeniørhøjskolen i Århus ITONK1 CORBA & ICE Introduction.
Presentation 3: Designing Distributed Objects. Ingeniørhøjskolen i Århus Slide 2 af 32 Outline...
-
Upload
annabel-carr -
Category
Documents
-
view
215 -
download
0
Transcript of Presentation 3: Designing Distributed Objects. Ingeniørhøjskolen i Århus Slide 2 af 32 Outline...
Presentation 3:Designing Distributed Objects
Ingeniørhøjskolen i ÅrhusSlide 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 ÅrhusSlide 4 af 32
A Brief History of Objects
Simula-67Information Hiding
Smalltalk
C++Eiffel
Java
CORBACOM
OOAD
UML
Sun ONC
DCE
Programming LanguagesDistributed Systems Software Engineering
Time
1970
1980
1990
DCOMSOAP
UML Representations for Distributed Object Design
Ingeniørhøjskolen i ÅrhusSlide 6 af 32
Use Case Diagrams !
TrainerPlan Training
Schedule
ManagerNational Soccer
Association
Determine LeagueGames
PlayerPrint Personal
Schedule
actor
use case
system boundary
Emmerich does not use activation arrow
system
need to implement!
Ingeniørhøjskolen i ÅrhusSlide 7 af 32
Sequence Diagrams – dynamic models
BvB:Team Teddy:Player Stefan:Player
bookGoaliesbook()
book()
:Output
printTrainingPlan
Tony:Trainer
asynchronousmessage
(remote) procedure
call
lifelineobjectactivation
synchronousMessage
ObjectName Type
objectdeletion
Name is purecoincidence
Ingeniørhøjskolen i ÅrhusSlide 8 af 32
Class Diagrams – static models !
Team
-name:string
+bookGoalies()
coaches 1..*
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
1 1..*uses
plays in
1 11..16
has1
*
privatepublic
protected
class nameattributes
operations
association
generalizationaggregation
composition
dependency
cardinality
need to implement!
Ingeniørhøjskolen i ÅrhusSlide 9 af 32
Packages - decoupling
SoccerClubs
LeagueManagement
NationalTeam
Middleware
Collections of Classes that workClose together, but Decoupled from otherPackages
need to implement!
Ingeniørhøjskolen i ÅrhusSlide 10 af 32
Object Diagrams – instances relationships
name = “Tottenham Hotspurs”
spurs:Team
stefan:Player
name = “Stefan Freund” role = DefenderNumber=4
name=“Jürgen Klinsmann”role=ForwardNumber = 18
klinsi:Player
Object
AttributeValue
Object TypeObject Name
AttributeName
Link
Ingeniørhøjskolen i ÅrhusSlide 11 af 32
in team
State Diagrams – instances state and transitions
healthy
in match
injured
/injury
/recovered
reserve
playing /swap/swap
/exercise
freetraining
/finish
[!in_squad]/play
[in_squad]/play
/finish
state compositestate
indicatesdefaultstate
transition
action during transition
condition
Ingeniørhøjskolen i ÅrhusSlide 12 af 32
Parallel State Composition
in team
on transfer list
Player
happy
/unsatisfaction
/resign
/sign_contract
concurrentthreads
finalstate
Ingeniørhøjskolen i ÅrhusSlide 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 ÅrhusSlide 14 af 32
Sample Object
klinsi:Player
name = “Jürgen Klinsmann”role = ForwardNumber = 18
Ingeniørhøjskolen i ÅrhusSlide 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 ÅrhusSlide 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 ÅrhusSlide 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 ÅrhusSlide 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 ÅrhusSlide 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 ÅrhusSlide 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 ÅrhusSlide 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 ÅrhusSlide 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 ÅrhusSlide 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 ÅrhusSlide 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 ÅrhusSlide 26 af 32
Activation/Deactivation (cont’d)
BvB:Team
bookGoalies
Tony:Trainer
objectactivated
objectDeactivation-Might need to serialize to maintain state
Ingeniørhøjskolen i ÅrhusSlide 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 ÅrhusSlide 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 ÅrhusSlide 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 ÅrhusSlide 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 ÅrhusSlide 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 ÅrhusSlide 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