Distributed Systems Principles and Paradigms Chapter 10 (version - - PDF document

▶
distributed systems
SMART_READER_LITE
LIVE PREVIEW

Distributed Systems Principles and Paradigms Chapter 10 (version - - PDF document

Feb 13, 2023 325 likes •639 views

Distributed Systems Principles and Paradigms Chapter 10 (version April 7, 2008 ) Maarten van Steen Vrije Universiteit Amsterdam, Faculty of Science Dept. Mathematics and Computer Science Room R4.20. Tel: (020) 598 7784 E-mail:steen@cs.vu.nl,

slide-1
SLIDE 1

Distributed Systems

Principles and Paradigms

Chapter 10

(version April 7, 2008)

Maarten van Steen

Vrije Universiteit Amsterdam, Faculty of Science

  • Dept. Mathematics and Computer Science

Room R4.20. Tel: (020) 598 7784 E-mail:steen@cs.vu.nl, URL: www.cs.vu.nl/∼steen/

01 Introduction 02 Architectures 03 Processes 04 Communication 05 Naming 06 Synchronization 07 Consistency and Replication 08 Fault Tolerance 09 Security 10 Distributed Object-Based Systems 11 Distributed File Systems 12 Distributed Web-Based Systems 13 Distributed Coordination-Based Systems

00 – 1 /

slide-2
SLIDE 2

Remote Distributed Objects (1/2)

  • Data and operations encapsulated in an object
  • Operations are implemented as methods, and

are accessible through interfaces

  • Object offers only its interface to clients
  • Object server is responsible for a collection of
  • bjects
  • Client stub (proxy) implements interface
  • Server skeleton handles (un)marshaling and ob-

ject invocation

Server machine Object Client machine Proxy Same interface as object Interface State Method Client invokes a method Network Skeleton invokes same method at object Marshalled invocation is passed across network Client OS Server OS Server Skeleton Client

10 – 1 Distributed Object-Based Systems/10.1 Architecture

slide-3
SLIDE 3

Remote Distributed Objects (2/2)

Compile-time objects: Language-level objects, from which proxy and skeletons are automatically gener- ated. Runtime objects: Can be implemented in any lan- guage, but require use of an object adapter that makes the implementation appear as an object. Transient objects: live only by virtue of a server: if the server exits, so will the object. Persistent objects: live independently from a server: if a server exits, the object’s state and code remain (passively) on disk.

10 – 2 Distributed Object-Based Systems/10.1 Architecture

slide-4
SLIDE 4

Example: Enterprise Java Beans

What is it: Java object hosted by special server that allows for different means of calling the object by re- mote clients.

Local OS Network Server kernel JMS JNDI JDBC RMI EJB EJB EJB Container Server Services

10 – 3 Distributed Object-Based Systems/10.1 Architecture

slide-5
SLIDE 5

Types of EJBs

  • Stateless session bean: Transient object, called
  • nce, does its work and is done. Example: exe-

cute an SQL query and return result to caller.

  • Stateful session bean: Transient object, but main-

tains client-related state until the end of a session. Example: shopping cart.

  • Entity bean: Persistent, stateful object, can be

invoked during different sessions. Example: ob- ject maintaining client info on last number of ses- sions.

  • Message-driven bean: Reactive objects, often

triggered by message types. Used to implement publish/subscribe forms of communication.

10 – 4 Distributed Object-Based Systems/10.1 Architecture

slide-6
SLIDE 6

Globe Distributed Objects (1/2)

Observation: Most distributed objects are not dis- tributed at all: state is kept at a single node. Alterna- tive: Globe objects, which are physically distributed across multiple machines.

Local object Distributed shared object Process Interface Network

10 – 5 Distributed Object-Based Systems/10.1 Architecture

slide-7
SLIDE 7

Globe Distributed Objects (2/2)

Note: To make DSOs generic, we need to separate function from distribution support:

Control subobject Replication subobject Semantics subobject Communication subobject Communication with other local

  • bjects

Same interface as implemented by semantics subobject

Note: replication subobject essentially decides how and when the local semantics subobject will be in- voked.

10 – 6 Distributed Object-Based Systems/10.1 Architecture

slide-8
SLIDE 8

Processes: Object Servers (1/2)

Servant: The actual implementation of an object, some- times containing only method implementations:

  • Collection of C or COBOL functions, that act on

structs, records, database tables, etc.

  • Java or C++ classes

Skeleton: Server-side stub for handling network I/O:

  • Unmarshalls incoming requests, and calls the ap-

propriate servant code

  • Marshalls results and sends reply message
  • Generated from interface specifications

Object adapter: The “manager” of a set of objects:

  • Inspects (as first) incoming requests
  • Ensures referenced object is activated (requires

identification of servant)

  • Passes request to appropriate skeleton, following

specific activation policy

  • Responsible for generating object references

10 – 7 Distributed Object-Based Systems/10.2 Processes

slide-9
SLIDE 9

Processes: Object Servers (2/2)

Local OS Request demultiplexer Object adapter Object's stub (skeleton) Server with three objects Server machine Object adapter

Observation: Object servers determine how their ob- jects are constructed

10 – 8 Distributed Object-Based Systems/10.2 Processes

slide-10
SLIDE 10

Example: Ice

Important: Ice aims at simplicity, and achieves this partly by putting policies into the middleware.

main(int argc, char* argv[]) { Ice::Communicator ic; Ice::ObjectAdapter adapter; Ice::Object

  • bject;

ic = Ice::initialize(argc, argv); adapter = ic->createObjectAdapterWithEndPoints ( "MyAdapter","tcp -p 10000");

  • bject

= new MyObject; adapter->add(object, objectID); adapter->activate(); ic->waitForShutdown(); }

Note: Activation policies can be changed by modify- ing the properties attribute of an adapter.

10 – 9 Distributed Object-Based Systems/10.2 Processes

slide-11
SLIDE 11

Client-to-Object Binding (1/2)

Object reference: Having an object reference allows a client to bind to an object:

  • Reference denotes server, object, and communi-

cation protocol

  • Client loads associated stub code
  • Stub is instantiated and initialized for specific ob-

ject Two ways of binding:

  • Implicit: Invoke methods directly on the refer-

enced object

  • Explicit: Client must first explicitly bind to object

before invoking it

10 – 10 Distributed Object-Based Systems/10.3 Communication

slide-12
SLIDE 12

Client-to-Object Binding (2/2)

Distr_object* obj_ref;

  • bj_ref = ...;
  • bj_ref->do_something();

Implicit

Distr_object* obj_ref; Local_object* obj_ptr;

  • bj_ref = ...;
  • bj_ptr = bind(obj_ref);
  • bj_ptr->do_something();

Explicit Some remarks:

  • Reference may contain a URL pointing to an im-

plementation file

  • (Server,object) pair is enough to locate target ob-

ject

  • We need only a standard protocol for loading and

instantiating code Observation: Remote-object references allow us to pass references as parameters. This was difficult with

  • rdinary RPCs.

10 – 11 Distributed Object-Based Systems/10.3 Communication

slide-13
SLIDE 13

Remote Method Invocation

Basics: (Assume client stub and server skeleton are in place)

  • Client invokes method at stub
  • Stub marshals request and sends it to server
  • Server ensures referenced object is active:

– Create separate process to hold object – Load the object into server process – ...

  • Request is unmarshaled by object’s skeleton, and

referenced method is invoked

  • If request contained an object reference, invoca-

tion is applied recursively (i.e., server acts as client)

  • Result is marshaled and passed back to client
  • Client stub unmarshals reply and passes result to

client application

10 – 12 Distributed Object-Based Systems/10.3 Communication

slide-14
SLIDE 14

RMI: Parameter Passing (1/2)

Object reference: Much easier than in the case of RPC:

  • Server can simply bind to referenced object, and

invoke methods

  • Unbind when referenced object is no longer needed

Object-by-value: A client may also pass a complete

  • bject as parameter value:
  • An object has to be marshaled:

– Marshall its state – Marshall its methods, or give a reference to where an implementation can be found

  • Server unmarshals object. Note that we have now

created a copy of the original object.

  • Object-by-value passing tends to introduce nasty

problems

10 – 13 Distributed Object-Based Systems/10.3 Communication

slide-15
SLIDE 15

RMI: Parameter Passing (2/2)

Local object O1 Copy of O1 Remote object O2 Local reference L1 New local reference Remote reference R1 Remote invocation with L1 and R1 as parameters Copy of R1 to O2 Machine A Machine B Machine C Client code with RMI to server at C (proxy) Server code (method implementation)

Note: Systemwide object reference generally contains server address, port to which adapter listens, and lo- cal object ID. Extra’s: Information on protocol between client and server (TCP , UDP , SOAP , etc.) Question: What’s an alternative implementation for a remote-object reference?

10 – 14 Distributed Object-Based Systems/10.3 Communication

slide-16
SLIDE 16

Object-Based Messaging

Messaging facilities: reliable asynchronous and per- sistent method invocations:

Client proxy Callback interface Client RTS Client application

  • 2. Request to server
  • 4. Call by the RTS
  • 1. Call by the

application

  • 3. Response from server

Client proxy Polling interface Client RTS Client application

  • 2. Request to server
  • 1. Call by the

application

  • 3. Response from server
  • 4. Call by the

application

10 – 15 Distributed Object-Based Systems/10.3 Communication

slide-17
SLIDE 17

Object References (1/2)

Observation: In order to invoke remote objects, we need a means to uniquely refer to them. Example: CORBA object references:

Repository identifier IIOP version Host Port Object key Components Profile ID Tagged Profile Object identifier Adapter identifier Other server- specific information Profile Interoperable Object Reference (IOR)

10 – 16 Distributed Object-Based Systems/10.4 Naming

slide-18
SLIDE 18

Object References (2/2)

Observation: It is not important how object refer- ences are implemented per object-based system, as long as there is a standard to exchange them between systems:

Object system A Object system B Object server Interoperable references (Half) gateway

Solution: Object references passed from one RTS to another are transformed by the bridge through which they pass (different transformation schemes can be implemented) Observation: Passing an object reference refA from RTS A to RTS B circumventing the A-to-B bridge may be useless if RTS B doesn’t understand refA

10 – 17 Distributed Object-Based Systems/10.4 Naming

slide-19
SLIDE 19

Globe Object References

Important: Globe references are location indepen- dent, in contrast to CORBA’s IORs. Stacked address: Stack of addresses representing the protocol to speak:

Field Description Protocol ID Constant representing a (known) protocol Protocol addr. Protocol-specific address

  • Impl. handle

Reference to a file in a repository

Instance address: Contains all that is needed to talk in a propritary way to an object:

Field Description

  • Impl. handle

Reference to a file in a repository Initialization string Used to initialize an implementation

10 – 18 Distributed Object-Based Systems/10.4 Naming

slide-20
SLIDE 20

Synchronization

Issue: Client stubs hide many of the interactions with

  • bjects, which may not always be a good idea:

Object Object Process Process Lock

  • Unlock

(a) (b)

Other problem: Should we have server-side or client- side synchronization:

  • Server: Problems when client crashes
  • Clients: Problems when clients at different ma-

chines need to synchronize Java: Clients at same machine are automatically syn- chronized; those from different machines are not.

10 – 19 Distributed Object-Based Systems/10.5 Synchronization

slide-21
SLIDE 21

Consistency and Replication

Observation: Objects form a natural means for real- izing entry consistency:

  • Data are grouped into units, and protected by a

synchronization variable (i.e., lock)

  • Synchronization variables adhere to sequential

consistency (i.e., values are set atomically)

  • Operations of grouped data can be nicely grouped:
  • bject

Problem: What happens when objects are replicated? One way or the other we need to ensure that opera- tions on replicated objects are properly ordered.

10 – 20 Distributed Object-Based Systems/10.6 Consistency and Replication

slide-22
SLIDE 22

Replicated Objects

Problem: We need to make sure that requests are

  • rdered correctly at the servers and that threads are

deterministically sheduled:

Middleware Local OS Threads

  • Unordered requests

Totally ordered requests Middleware Local OS Threads Thread scheduler Deterministic thread scheduling Unordered requests Object Computer 1 Computer 2 T1

1

T1

2

T2

1

T2

2

Observation: We are dealing with nasty issues here. Simplicity may dictate completely serialized (i.e., single- threaded) executions at the server.

10 – 21 Distributed Object-Based Systems/10.6 Consistency and Replication

slide-23
SLIDE 23

Replicated Invocations (1/2)

Active replication: Updates are forwarded to multi- ple replicas, where they are carried out. There are some problems to deal with in the face of replicated invocations:

Client replicates invocation request All replicas see the same invocation Object receives the same invocation three times Replicated object A B1 B2 B3 C

10 – 22 Distributed Object-Based Systems/10.6 Consistency and Replication

slide-24
SLIDE 24

Replicated Invocations (2/2)

Solution: Assign a coordinator on each side (client and server), which ensures that only one invocation, and one reply is sent:

Coordinator

  • f object B

Result Coordinator

  • f object C

(a) (b) Client replicates invocation request B1 B1 B2 B2 B3 B3 C1 C1 C2 C2 A A Result

10 – 23 Distributed Object-Based Systems/10.6 Consistency and Replication

slide-25
SLIDE 25

Fault Tolerance

Observation: Nothing really new to report – object systems handle fault tolerance as you would expect them to do. Example: CORBA uses special interoperable object group references to allow a client to access replicas:

Repository identifier IIOP ver. IIOP ver. Host-1 Host-N Port-1 Port-N Object key-1 Object key-N Components Components Profile ID Profile ID TAG PRIMARY TAG BACKUP Other group- specific information Other group- specific information Profile-1 Profile-N Interoperable Object Group Reference (IOGR)

10 – 24 Distributed Object-Based Systems/10.7 Fault Tolerance

slide-26
SLIDE 26

CORBA FT: Architecture

Replication manager Object group manager Property manager Middleware/RTS Object Interceptor Replication Reliable multicasting Logging & Recovery Log To other replicas Client or

  • bject server

10 – 25 Distributed Object-Based Systems/10.7 Fault Tolerance

slide-27
SLIDE 27

Security

When objects can (also) be moved/copied around: We need to consisder three different security aspects:

  • Secure binding: is the binding between client

and object authorized?

  • Secure invocation: is the bounded client autho-

rized to invoke a specific method?

  • Platform security: is the object protected against

the underlying platform and vice versa? Example: For Globe we have the following public/private key pairs:

  • Object key: Owner of the private key can set ac-

cess rights for users and replica servers.

  • Replica key: Used to make sure that a replica

server is hosting an object.

  • User key: Associated with every user.

10 – 26 Distributed Object-Based Systems/10.8 Security

slide-28
SLIDE 28

Globe security

sig(O, {R,U,D, }) User certificate U: K+

Alice

K+

Alice

sig(O, {U, }) Replica certificate K+

Repl

K+

Adm

K+

Repl

sig(O, {R, }) K+

Adm

00 00 1 111 0 U:01 00 1 1 111 1 D:1

  • 11 00

111 0 R: 11 11 111 0 R: Administrative certificate (c) (b) (a)

  • User certificate: U[i] = 1 iff user is allowed to

invoke method Mi.

  • Replica certificate: R[i] = 1 iff replica is allowed

to execute Mi.

  • Administrative certificate: U[i] = 1 iff a user

certificate for Mi may be issued. Same for R[i].

10 – 27 Distributed Object-Based Systems/10.8 Security

slide-29
SLIDE 29

Secure Method Invocation

Check user permissions Request secure channel Find suitable replica Establish secure channel Encrypt/sign network packet Decrypt & authenticate request Authorize request Execute

  • peration

3 2 4 8 9 11 12 13 10 7 1

Request invocation

5 6

Marshall request Pass request to channel Client-side stub Server-side replica Security

  • bject

Security

  • bject

Control

  • bject

Control

  • bject

Repl.

  • bject

Repl.

  • bject

Comm.

  • bject

Comm.

  • bject

Semant.

  • bject

Unmarshall Pass request

1: Application issues an invocation request. 2: Control subobject checks user permissions; security object should have valid user certificate. 3: Request is marshaled and passed on. 4: Replication subobject requests middleware to set up secure channel to suitable replica. 5: Security object initiates a replica lookup.

10 – 28 Distributed Object-Based Systems/10.8 Security

slide-30
SLIDE 30

Secure Method Invocation

Check user permissions Request secure channel Find suitable replica Establish secure channel Encrypt/sign network packet Decrypt & authenticate request Authorize request Execute

  • peration

3 2 4 8 9 11 12 13 10 7 1

Request invocation

5 6

Marshall request Pass request to channel Client-side stub Server-side replica Security

  • bject

Security

  • bject

Control

  • bject

Control

  • bject

Repl.

  • bject

Repl.

  • bject

Comm.

  • bject

Comm.

  • bject

Semant.

  • bject

Unmarshall Pass request

6: Security subobject sets up secure channel with its peer. The replica must prove it is allowed to carry out the re- quested invocation. 7: Request is passed on to comm. subobject. 8: Comm. subobject encrypts and signs the request. 9: Request is decrypted and authenticated. 10: Request is passed to server-side repl. subobject.

10 – 29 Distributed Object-Based Systems/10.8 Security

slide-31
SLIDE 31

Secure Method Invocation

Check user permissions Request secure channel Find suitable replica Establish secure channel Encrypt/sign network packet Decrypt & authenticate request Authorize request Execute

  • peration

3 2 4 8 9 11 12 13 10 7 1

Request invocation

5 6

Marshall request Pass request to channel Client-side stub Server-side replica Security

  • bject

Security

  • bject

Control

  • bject

Control

  • bject

Repl.

  • bject

Repl.

  • bject

Comm.

  • bject

Comm.

  • bject

Semant.

  • bject

Unmarshall Pass request

11: Authorization takes place; user certificate from client-side stub has been passed to replica to verify that request can be carried out. 12: Request is unmarshaled. 13: Operation can be executed.

10 – 30 Distributed Object-Based Systems/10.8 Security