Part.1. Execution Environment for Distributed Computing

Execution Environments for Distributed Computing

Part 1.DistributedComputing

Basics

EEDC

34330

Master in Computer Architecture, Networks and Systems - CANS

2

Background

� A good background– Distributed Systems

• an introductory course on principles for Distributed Systems.• http://www.ac.upc.edu/distributed-systems

– Scalable Distributed Systems • an advanced course on Scalable Distributed Systems.

– Learn the fundamental concepts, operation and design guidelines, patterns and methods for developing software systems with good scalability and predictability, and the evaluation of scalable and Internet-scale systems.

• http://www.ac.upc.edu/en/scalable-distributed-systems-sds

� Excellent teachers in the area:– Leandro Navarro: http://personals.ac.upc.edu/leandro/– Jordi Guitart: http://personals.ac.upc.edu/jguitart/

3

Content

Part 1. Distributed Computing Basics (review concep ts)

1.1.Distributed Systems Overview (review)

1.2.Distributed Computing Communication (review)

1.3. XML basics(review)

1.4. Web Services basics (review)

1.5. REST versus POST (Homework 2)

1.6.Service Level parameters (review)

1.7. Distributed Systems become complex systems


1.1 Distributed

SystemsOverview

EEDC

34330



1.1 Distributed

SystemsOverview

EEDC

34330


deprecated?:-)

6

The Rise of Distributed Systems

� Computer hardware prices falling, power increasing– If cars the same, Rolls Royce would cost 1 dollar and get 1

billion miles per litre

� Network connectivity increasing– Everyone is connected with fat pipes

� It is easy to connect hardware together

� First definition: a distributed system isa collection of independent computers that appears to its users as a single coherent system.

7

Distributed Systems

� Wikipedia:� “Distributed computing is a method of computer

processing in which different parts of a program ru n simultaneously on two or more computers that are communicating with each other over a network”.

– Is a type of parallel computing• “Parallel” usually describes a set of processes running in the same

machine

– Some particular communication mechanisms are required for distributed computing:

• RPC, sockets, soap, rest, http, mapreduce, OpenMP, MP, pregel, CompSs,……………

8

Distributed Systems

� Different targets:– Scientific // Numerical distributed computing

• Parallelism to reduce computation time• Examples: MPI, CompSs

– Commercial distributed computing• Increase availability, functionalities, service level guarantees,• Examples: Distributed computing models, Application servers (N-

tier)…

9

Transparency in a Distributed System� Different forms of transparency in a Distributed Sy stem

Transparency Description

AccessHide differences in data representation and how a resource is accessed

Location Hide where a resource is located

Migration Hide that a resource may move to another location

RelocationHide that a resource may be moved to another location while in use

ReplicationHide that a resource may be shared by several competitive users

ConcurrencyHide that a resource may be shared by several competitive users

Failure Hide the failure and recovery of a resource

PersistenceHide whether a (software) resource is in memory or on disk

10

Software Concepts (old concepts?)

� DOS (Distributed Operating Systems)� NOS (Network Operating Systems)� Middleware - preliminary vision

System Description Main Goal

DOSTightly-coupled operating system for multi-processors and homogeneous multicomputers

Hide and manage hardware resources

NOSLoosely-coupled operating system for heterogeneous multicomputers (LAN and WAN)

Offer local services to remote clients

MiddlewareAdditional layer top of NOS implementing general-purpose services

Provide distribution transparency

11

Distributed Operating Systems (old view?)

� But no longer have shared memory– Provide message passing– Can try to provide distributed shared memory

• But tough to get acceptable performance

12

Network Operating System (old view?)

� OSes can be different (Windows or Linux)

13

Network Operating System (old view?)

� Typical services: rlogin, rcp– Quite primitive way to share files

� Can have one computer provide files transparently for others: e.g. NFS

14

Middleware: the solution?� A distributed system organized as “middleware”.

– the middleware layer extends over multiple machines.

� Users can interact with the system in a consistent way, regardless of where the interaction takes plac e.– Middleware may be “part” of application in practice.

15

Middleware� Positioning middleware

– Network OS not transparent. – Distributed OS not independent of computers.�Middleware can help

� Much middleware built in-house to help use networked operating systems – distributed transactions, – better communication,– RPC,– …

� Unfortunately, many different standards

16

Distributed System?

� Evolution of Computing Systems

CentralizedSystems

Distributed Systems

Client

Server Systems

17

Definitions for Distributed System?

A distributed system is a collection of independent computers that appears to its users as a single coherent system

– Heterogeneous computers – vendors/OS should be able to interoperate– Communication should be hidden– Should be easy to expand and scale– Should be permanently available (even though parts of it are not)

Machine A Machine B Machine C

Distributed Applications

Middleware Services

OS, e.g.Windows XP

OS, e.g.Mac OS

OS, e.g.Linux

Network

18

Taxonomy for Distributed Systems

� Taxonomy is based on following factors:1.Resource Discovery2. Resource Availability3. Resource Communication

1. Resource Discovery :Mechanism for discovering resources on a distributed system?

2. Resource Availability :Scalability – do resources scale with network?

19


3. Resource Communication :Two basic types:– Brokered Communication (centralized):

• communication is passed through a central server -resources do not have direct references to each other.

– Point to point (decentralized -peer to peer): • a direct connection between the sender and the receiver.

20


� Centralized vs descentralized

Equal Peers, communication is supposedto be even i.e. each provider is also aserver of information and each node hasan equal number of connections

CentralServer

True Peer to Peer

Many to one relationshipbetween users and the central server and therefore this can be considered centralized communication

21


- Clients (i.e. users) use their webbrowser to navigate web pages onone or more web sites.- Web site is static to particulardomain

• Discovery: Centralized, DNS• Availability: available or not• Communication: centralized tothe particular web server

WebServer

� Centralized example: A web server

22

Client-Server Computing


Server

• Client initiates communications

• Client issues request to a server

• Server replies or performs some service

Peer-to-Peer Computing

• Any participant can initiate communication

• Any device can generate a request

• Any device may provide a response

� Summary: Client-Server vs Peer-to-Peer

23


Centralized DecentralizedHybrid

Centralized systems -typically, client/server based systems

Decentralized systems - Peer to Peer (P2P)

Hybrid – combinations of the 2 extremes e.g. brokered architecture

� Overview

24

Middleware Systems

offers the Execution Environment

– are comprised of abstractions and services to facilitate the design , development, integration and deployment of distributed applications in heterogeneous networking environments.

– Middleware components are of crucial importance for new systems and architectures because of their impact on the quality of the service offered by the application.

25

Middleware Definition?

� RFC2768: (IETF)– Def 1: those services found above the transport (I.e. over

TCP/IP) layer set of services but below the application environment (i.e., below application-level APIs)

– Def 2: a reusable, expandable set of services and functions that are commonly needed by many applications to function well in a networked environment.

26


� RFC2768: (IETF)– Def 1: those services found above the transport (I.e. over

TCP/IP) layer set of services but below the application environment (i.e., below application-level APIs)

– Def 2: a reusable, expandable set of services and functions that are commonly needed by many applications to function well in a networked environment.

� EEDC approximation:– Software “glue” between two apps/layers/….

27


� Middleware refers to the software which is common t o multiple applications and builds on the network transport services to enable ready development of new applications and network services.

� Middleware typically includes a set of components such as resources and services that can be utilized by applications either individually or in various subs ets.– Examples of services: Security, Directory and naming, end-to-end

quality of service, etc.

28

Middleware Definition?� Middleware?

� OMG’s CORBA ?– defines a middleware standard.

� Java 2 enterprise edition (J2EE) ?– is a middleware specification.

� Hadoop?– is a middleware framework of the MapReduce programming model.

JVM

OS

Middleware

Application

Hardware

MIDDLEWARE

29

Middleware Definition?� Conclusion:

– Middleware is a somewhat overloaded term

� For this course:– Generally speaking, middleware provides software services for

application programs INCLUDING the basic operating system and networking services above the resources.

Operating Systemand Networking Services

Software services

Application Programs

Resources

30


� Goal is to simplify development effort and increase application functionality and robustness– Allow code to run across different platforms– Provide higher level abstractions of services

� Example of “traditional” functions– Messaging– Distributed object management– Directory services– Location services– User-defined and composite data types– Remote procedure calls (RPC)– Alternate communication abstractions– …

31

Middleware: Layered architecture

� Solving such a problem is not an easy task.� Middlewares as many other software have a layered

architecture.M

iddl

ewar

e

Operating system

Host infrastructure middleware

Distribution middleware

Common middleware services

Domain-specific middleware services

Applications

Hardware devices

Thank you to F. Zyulkyarov and R. Ferrer

[1] Richard E. Schantz , Douglas C. Schmidt, Research Advances in Middleware for Distributed Systems, Proceedings of the IFIP 17th World Computer Congress -TC6 Stream on Communication Systems: The State of the Art, p.1-36, August 25-30, 2002.

32

Benefits of middleware

� Increasing focus on integration rather on programming.– Middlewares allow for connecting separate pieces of software

despite their location.

� Increased viability of open systems architectures a nd open-source availability– Openly defined middlewares motivate the creation of additional

technologies on top of them.

� At last, they enable a new software market of distributed solutions.

33

Some challenges for middleware today

� Middlewares have not completely solved the «distributed heterogeneous computing» problem.

� Standartizing domain-specific middleware services– Domain-specific middleware is tightly tailored to the domain and the

components cannot be reused in building simillar domain-specific applications.

– Challenges for Openness• Openness facilitates• interoperability, portability, extensibility, adaptivity

34


� Challenges for Scalability– The system will remain effective when there is a significant

increase in number of resources, number of users, etc.

� Providing end-to-end Quality of Service (QoS) over the whole system.– And special attention require quality service as “TREC” in this

course

� Resource allocation and management for embededdistributed applications.

35


� But also issues like– Better failure tolerance– Better integration– Better adaptivity to highly dynamic environments– Lack of good system engineering and tools “middleware-aware”– …– …– …– …– …

36

Summary: Middleware systems

� offers an Execution Environment

� are comprised of– abstractions and services

– to facilitate the design , development, integration and deployment of distributed applications

– in heterogeneous computing systems.

37

Divide and Conquer paradigm!: Layers

� Breaking up the complexity of systems by designing them through layers and services

– Layer: a group of related functional components

– Service: functionality provided to the next layer.

Layer 1

Layer 2

Layer N

(services offered to above layer)

…

38

Middleware: can be a layered architecture

� Divide and Conquer paradigm!– Middlewares as many other software have a layered

architecture.M

iddl

ewar

e

Operating system





Applications

Hardware devices

Thank you to F. Zyulkyarov and R. Ferrer from BSC

39

� Encapsulates the running OS services– Concurrency and low level process and

task management.– Communication.

� e.g. high level distributed programming models.– Allows for applications to be developed

as if they were not distributed, by means of some sort of remote invocation.

Mid

dlew

are

Operating systemHost infrastructure middlewareDistribution middlewareCommon middleware servicesDomain-specific middleware servicesApplications

Hardware devices

[1] Richard E. Schantz , Douglas C. Schmidt, Research Advances in Middleware for Distributed Systems, Proceedings of the IFIP 17th World Computer Congress - TC6 Stream on Communication Systems: The State of the Art, p.1-36, August 25-30, 2002.

Mid

dlew

are


Hardware devices


40

� Provide a rich set of services that turn out to be common across all distributed applications, namely– Transaction support– Security services– Database connection– ...

� Tailored to the requirements of particular domains– Telecommunications– E-commerce– Aerospace– ...

Mid

dlew

are


Hardware devices


Mid

dlew

are


Hardware devices

41

� Along the course we will see different examples for each layer


Mid

dlew

are

Operating system





Applications

Hardware devices

42

The world of …

Example: Real Time middleware, Embeddedmiddleware, …

� In RT systems, it doesn’t matter how fast you can p erform an action, the important thing is that you must finish it befo re a deadline.

� However, we can relax deadline-constraints a little ...:– Hard Real-Time:

• Operations must be concluded before a deadline. E.g.: air-bag, ABS, defence systems, etc.

– Soft Real-Time:• Operations must be concluded most of the time before a deadline.

E.g.: Telepizza gives your money back if they can’t deliver your pizza before 30 minutes. Applying RT methodologies they can upper-bound maximum losses.

Thank you to Ismael Gómez Miguelez

43

Primary Characteristics:– Optimization: In contrast with general-purpose computers, they can be

highly optimized in performing one task.• Underlying OS overhead must be minimum.• Limited resources (CPU, memory, etc.)

– Reliability: They are expected to run continuously for years without errors.

• We must avoid dynamic memory, system can’t be just “rebooted”. E.g. space systems, pacemaker, etc.

• System shut down may incur in large money losses or even death. E.g. telephone switches, funds transfer, elevator controls, etc.

Embedded Systems:

“They are special-purpose computer systems designed to perform one or a few dedicated functions.”

http://en.wikipedia.org/wiki/Embedded_system


The world of …

44

The world of …

… and

Distributed Real-Time Embedded (DRE) Systems� They are Real-Time Embedded systems executed in

multiprocessor environments (sometimes heterogeneou s)

� Main challenges:– Real-Time Scheduling in distributed heterogeneous processors is a

NP-hard problem.

– Predictable latencies and jitter on all system services and procedures

– QoS

– Optimality and reliability


Reference: Middleware for real-time and embedded systems Communications of the ACM . Volume 45 , Issue6 (June 2002) Pages: 43 - 48 Year of Publication: 2002 ISSN:0001-0782 http://delivery.acm.org/10.1145/510000/508472/p43-schmidt.pdf?key1=508472&key2=4239626321&coll=GUIDE&dl=GUIDE&CFID=25423637&CFTOKEN=92900699

45

� Considering a layered architecture to ease the explanation

Focus of this course: Middleware

Applications

Middleware

Hardware

…Web Services

…

Aplication Server

…

Web server

Or Programming Models frameworks

…

Java Virtual Machine

Operating System

Virtualization layer

…


1.2 DistributedComputing

Communication

EEDC

34330


4747

Distributed Computing Communication?� Origins?

Remote procedure call (RPC)

� The idea of RPC goes back at

least as far as 1976, when it was described in RFC 707.

� It is a technology that allows a computer program to cause a subroutine or procedure to execute in another address space (commonly on another computer on a shared network) without the programmer explicitly coding the details for this remote interaction.

(from wikipedia)

RPC

4848

Current “RPC”?

� Some basic forms• Sockets• http• Web Services (WS)• (CORBA is not considered in this course)• ...

� Sockets supports http, and http suports WS !!!!

49

Distributed Systems Communication

� Basic concepts of Distributed Computing Communication: Sockets, Http, WS

� Review concepts:– Principles of app layer protocols– Web and HTTP– DNS– Socket programming with TCP– Socket programming with UDP– Building a Web server

Slides partially extracted from: Computer Networking: A Top Down Approach Featuring the Internet, 2nd edition. Jim Kurose, Keith Ross Addison-Wesley.

50

Distributed Systems comm. across network

� Distributed Systems communicating across network using sockets

� process sends/receives messages to/from its socket

process

TCP withbuffers,variables

socket

host orserver

process


socket

host orserver

Internet

controlledby OS

controlled byapp developer


51

Addressing processes:

� For a process to receive messages, it must have an identifier– Every host has a unique 32-bit IP address

� Identifier includes both the IP address and port numbers associated with the process on the host.– Example port numbers:

• HTTP server: 80• Mail server: 25• …


52

What transport service does an app need?

Data loss� some apps (e.g., audio) can tolerate some loss� other apps (e.g., file transfer, telnet) require 10 0%

reliable data transferTiming� some apps (e.g., Internet telephony, interactive

games) require low delay to be “effective”Bandwidth� some apps (e.g., multimedia) require minimum

amount of bandwidth to be “effective”� other apps (“elastic apps”) make use of whatever

bandwidth they get

53

Web and HTTP

First some jargon� Web page consists of objects� Object can be HTML file, JPEG image, Java applet,

audio file,…� Web page consists of base HTML-file which includes

several referenced objects� Each object is addressable by a URL� Example URL:

www.someschool.edu/someDept/pic.gif

host name path name

54

HTTP overview

HTTP: hypertext transfer protocol� Web’s application layer protocol� client/server model

– client: browser that requests, receives, “displays” Web objects– server: Web server sends objects in response to requests

� HTTP 1.0: RFC 1945� HTTP 1.1: RFC 2068

PC runningbrowser

Server runningWeb server


55

HTTP overview (continued)

Uses TCP:� client initiates TCP

connection (creates socket) to server, port 80

� server accepts TCP connection from client

� HTTP messages (application-layer protocol messages) exchanged between browser (HTTP client) and Web server (HTTP server)

� TCP connection closed

HTTP is “stateless”� server maintains no

information about past client requests


56

HTTP connections

Nonpersistent HTTP� At most one object is

sent over a TCP connection.

� HTTP/1.0 uses nonpersistent HTTP

Persistent HTTP� Multiple objects can be

sent over single TCP connection between client and server.

� HTTP/1.1 uses persistent connections in default mode


57

Non persistent HTTP

Suppose user enters URL www.someSchool.edu/someDepartment/home.index

1a. HTTP client initiates TCP connection to HTTP server (process) at www.someSchool.edu on port 80

2. HTTP client sends HTTP request message (containing URL) into TCP connection socket. Message indicates that client wants object someDepartment/home.index

1b. HTTP server at host www.someSchool.edu waiting for TCP connection at port 80. “accepts” connection, notifying

client

3. HTTP server receives request message, forms response message containing requested object, and sends message into its socket

time

(contains text, references to 10

jpeg images)


58

Non persistent HTTP (cont.)

5. HTTP client receives response message containing html file, displays html. Parsing html file, finds 10 referenced jpeg objects

6. Steps 1-5 repeated for each of 10 jpeg objects

4. HTTP server closes TCP

connection.

time


59

HTTP request message

� HTTP request message:– ASCII (human-readable format)

GET /somedir/page.html HTTP/1.1Host: www.someschool.edu User-agent: Mozilla/4.0Connection: close Accept-language:fr

(extra carriage return, line feed)

request line(GET, POST,

HEAD commands)

headerlines

Carriage return, line feed

indicates end of message


60

HTTP request message: general format


61

HTTP response message

HTTP/1.1 200 OK Connection closeDate: Thu, 06 Aug 1998 12:00:15 GMT Server: Apache/1.3.0 (Unix) Last-Modified: Mon, 22 Jun 1998 …... Content-Length: 6821 Content-Type: text/html

data data data data data ...

status line(protocol

status codestatus phrase)

headerlines

data, e.g., requestedHTML file


62

HTTP response status codes

200 OK– request succeeded, requested object later in this message

301 Moved Permanently– requested object moved, new location specified later in this

message (Location:)

400 Bad Request– request message not understood by server

404 Not Found– requested document not found on this server

505 HTTP Version Not Supported

In first line in server->client response message.A few sample codes:

63

Trying out HTTP (client side) for yourself

1. Telnet to your favorite Web server:

Opens TCP connection to port 80(default HTTP server port) at www.eurecom.fr.Anything typed in sent to port 80 at www.eurecom.fr

telnet www.eurecom.fr 80

2. Type in a GET HTTP request:

GET /~ross/index.html HTTP/1.0 By typing this in (hit carriagereturn twice), you sendthis minimal (but complete) GET request to HTTP server

3. Look at response message sent by HTTP server!


64

DNS: Domain Name System

Internet hosts, routers:– IP address (32 bit) - used for addressing datagrams– “name”, e.g., www.ac.upc.edu - used by humans

map between IP addresses and name ?

65

DNS: Domain Name System

Domain Name System:� distributed database implemented in hierarchy of many name

servers� application-layer protocol host, routers, name servers to

communicate to resolve names (address/name translation)– note: core Internet function, implemented as application-layer

protocol– complexity at network’s “edge”

66

DNS name servers

Why not centralize DNS?� single point of failure� traffic volume� distant centralized

database� maintenance

doesn’t scale!


67

DNS: Root name servers

� contacted by local name server that can not resolve name� root name server:

– contacts authoritative name server if name mapping not known– gets mapping– returns mapping to local name server

b USC-ISI Marina del Rey, CAl ICANN Marina del Rey, CA

e NASA Mt View, CAf Internet Software C. Palo Alto, CA

i NORDUnet Stockholm

k RIPE London

m WIDE Tokyo

a NSI Herndon, VAc PSInet Herndon, VAd U Maryland College Park, MDg DISA Vienna, VAh ARL Aberdeen, MDj NSI (TBD) Herndon, VA

root name servers worldwide


68

Simple DNS example

host surf.eurecom.frwants IP address of gaia.cs.umass.edu

1. contacts its local DNS server, dns.eurecom.fr

2. dns.eurecom.fr contacts root name server, if necessary

3. root name server contacts authoritative name server, dns.umass.edu, if necessary

requesting hostsurf.eurecom.fr

gaia.cs.umass.edu

root name server

authorititive name serverdns.umass.edu

local name serverdns.eurecom.fr

1

23

45

6


69

Socket programming

Socket API� introduced in BSD4.1 UNIX,

1981� explicitly created, used,

released by apps � client/server paradigm � two types of transport

service via socket API: – unreliable datagram – reliable, byte stream-

oriented

a host-local, application-created,

OS-controlled interface (a “door”) into which

application process can both send and

receive messages to/from another

application process

socket

Goal: learn how to build client/server application that communicate using

sockets


70

Socket-programming using TCP

Socket: a door between application process and end-end-transport protocol (UCP or TCP)

TCP service: reliable transfer of bytes from one process to another

process


socket

controlled byapplicationdeveloper

controlled byoperating

system

host orserver

process


socket

controlled byapplicationdeveloper

controlled byoperatingsystem

host orserver

internet


71

Socket programming with TCP

Client must contact server� server process must first

be running� server must have created

socket (door) that welcomes client’s contact

Client contacts server by:� creating client-local TCP

socket� specifying IP address, port

number of server process� When client creates

socket : client TCP establishes connection to server TCP

� When contacted by client, server TCP creates new socket for server process to communicate with client– allows server to talk with

multiple clients– source port numbers used

to distinguish clients (more in Chap 3)

TCP provides reliable, in-ordertransfer of bytes (“pipe”) between client and server

application viewpoint

72

Sockets with TCP

socket()

bind()

listen()

accept()

read()

write()

SERVIDOR

socket()

connect()

write()

read()

CLIENT

73

3. Sockets with UDP

socket()

bind()

sendto()

recvfrom()

HOST 2

socket()

bind()

recvfrom()

sendto()

HOST 1

74

Socket programming with TCP

Example client-server app:1) client reads line from

standard input ( inFromUserstream) , sends to server via socket ( outToServerstream)

2) server reads line from socket3) server converts line to

uppercase, sends back to client

4) client reads, prints modified line from socket (inFromServer stream)

outT

oSer

ver

to network from network

inF

rom

Ser

ver

inF

rom

Use

r

keyboard monitor

Process

clientSocket

inputstream

inputstream

outputstream

TCPsocket

Clientprocess

client TCP socket

75

Client/server socket interaction: TCP

wait for incomingconnection requestconnectionSocket =welcomeSocket.accept()

create socket,port=x , forincoming request:welcomeSocket =

ServerSocket()

create socket,connect to hostid , port=xclientSocket =

Socket()

closeconnectionSocket

read reply fromclientSocket

closeclientSocket

Server (running on hostid ) Client

send request usingclientSocketread request from

connectionSocket

write reply toconnectionSocket

TCP connection setup

76

Example: Java client (TCP)

import java.io.*; import java.net.*; class TCPClient {

public static void main(String argv[]) throws Exception {

String sentence; String modifiedSentence;

BufferedReader inFromUser = new BufferedReader(new InputStreamReader(System.in));

Socket clientSocket = new Socket("hostname", 6789);

DataOutputStream outToServer = new DataOutputStream(clientSocket.getOutputStream());

Createinput stream

Create client socket,

connect to server

Createoutput stream

attached to socket

77

Example: Java client (TCP), cont.

BufferedReader inFromServer = new BufferedReader(newInputStreamReader(clientSocket.getInputStream()));

sentence = inFromUser.readLine();

outToServer.writeBytes(sentence + '\n');

modifiedSentence = inFromServer.readLine();

System.out.println("FROM SERVER: " + modifiedSentence);

clientSocket.close();

} }

Createinput stream

attached to socket

Send lineto server

Read linefrom server

78

Example: Java server (TCP)

import java.io.*; import java.net.*;

class TCPServer {

public static void main(String argv[]) throws Exception {

String clientSentence; String capitalizedSentence;

ServerSocket welcomeSocket = new ServerSocket(6789);

while(true) {

Socket connectionSocket = welcomeSocket.accept();

BufferedReader inFromClient = new BufferedReader(newInputStreamReader(connectionSocket.getInputStream()));

Createwelcoming socket

at port 6789

Wait, on welcomingsocket for contact

by client

Create inputstream, attached

to socket

79

Example: Java server (TCP), cont

DataOutputStream outToClient = new DataOutputStream(connectionSocket.getOutputStream());

clientSentence = inFromClient.readLine();

capitalizedSentence = clientSentence.toUpperCase() + '\n';

outToClient.writeBytes(capitalizedSentence); }

} }

Read in linefrom socket

Create outputstream,

attached to socket

Write out lineto socket

End of while loop,loop back and wait foranother client connection

80

Socket programming with UDP

UDP: no “connection” between client and server

� no handshaking� sender explicitly attaches IP

address and port of destination to each packet

� server must extract IP address, port of sender from received packet

UDP: transmitted data may be received out of order, or lost

application viewpoint

UDP provides unreliable transferof groups of bytes (“datagrams”)

between client and server

81

Client/server socket interaction: UDP

closeclientSocket

Server (running on hostid )

read reply fromclientSocket

create socket,clientSocket = DatagramSocket()

Client

Create, address (hostid, port=x,send datagram request using clientSocket

create socket,port=x , forincoming request:serverSocket = DatagramSocket()

read request fromserverSocket

write reply toserverSocketspecifying clienthost address,port number

82

Example: Java client (UDP)

send

Pac

ket

to network from networkre

ceiv

ePac

ket

inF

rom

Use

r

keyboard monitor

Process

clientSocket

UDPpacket

inputstream

UDPpacket

UDPsocket

Output: sends packet (TCP sent “byte stream”)

Input: receives packet (TCP received “byte stream”)

Clientprocess

client UDP socket

83

Example: Java client (UDP)


class UDPClient { public static void main(String args[]) throws Exception {

BufferedReader inFromUser = new BufferedReader(new InputStreamReader(System.in));

DatagramSocket clientSocket = new DatagramSocket();

InetAddress IPAddress = InetAddress.getByName("hostname");

byte[] sendData = new byte[1024]; byte[] receiveData = new byte[1024];

String sentence = inFromUser.readLine(); sendData = sentence.getBytes();

Createinput stream

Create client socket

Translatehostname to IP

address using DNS

84

Example: Java client (UDP), cont.

DatagramPacket sendPacket = new DatagramPacket(sendData, sendData.length, IPAddress, 9876);

clientSocket.send(sendPacket);

DatagramPacket receivePacket = new DatagramPacket(receiveData, receiveData.length);

clientSocket.receive(receivePacket);

String modifiedSentence = new String(receivePacket.getData());

System.out.println("FROM SERVER:" + modifiedSentence); clientSocket.close(); }

}

Create datagram with data-to-send,

length, IP addr, port

Send datagramto server

Read datagramfrom server

85

Example: Java server (UDP)


class UDPServer { public static void main(String args[]) throws Exception

{

DatagramSocket serverSocket = new DatagramSocket(9876);

byte[] receiveData = new byte[1024]; byte[] sendData = new byte[1024];

while(true) {

DatagramPacket receivePacket = new DatagramPacket(receiveData, receiveData.length);

serverSocket.receive(receivePacket);

Createdatagram socket

at port 9876

Create space forreceived datagram

Receivedatagra

m

86

Example: Java server (UDP), cont

String sentence = new String(receivePacket.getData());

InetAddress IPAddress = receivePacket.getAddress();

int port = receivePacket.getPort();

String capitalizedSentence = sentence.toUpperCase();

sendData = capitalizedSentence.getBytes();

DatagramPacket sendPacket = new DatagramPacket(sendData, sendData.length, IPAddress,

port);

serverSocket.send(sendPacket); }

} }

Get IP addrport #, of

sender

Write out datagramto socket

End of while loop,loop back and wait foranother datagram

Create datagramto send to client

87

Building a simple Web server

� handles one HTTP request

� accepts the request� parses header� obtains requested file

from server’s file system

� creates HTTP response message:– header lines + file

� sends response to client

� after creating server, you can request file using a browser (e.g. IE explorer)

� see text for details


1.3 XML basics

EEDC

34330


89

What is XML?

� XML is not a language, it is actually a set of synt ax rules for creating semantically rich markup languages in a particular domain.– In other words you apply XML to create new languages!

� Any language created via the rules of XML, like MathML, is called an application of XML.

� A markup language’s primary concern is how to add semantic information about the raw content in a document.

� So, a key principle of XML is that the markup is separate from content .

Source: Mark Baker UPC PhD Course 2007

90


Well formed and Valid

� The XML specification defines two levels of conformance for XML documents: well formed and valid.

� Well-formed documents are mandatory , while validity is optional .

� A well-formed document compiles with all the WC3 syntax rules of XML – like naming, nesting, and attribute quoting:– This guarantees that an XML parser can parse the document

without error.

� A valid XML document references and satisfies a schema:– A schema is a separate document whose purpose is to define the

legal elements, attributes, and structure of an XML document.

91

XML Example

� XML is a language used to represent structured documents or data electronically:• Note that order is important, but whitespace is not.

� Here is an example:

<Article ><Headline >Direct Marketer Offended by Term 'Junk Mail' </ Headline ><authors >

<author > Joe Garden</ author ><author > Tim Harrod</ author >

</authors ><abstract >Dan Spengler, CEO of the direct-mail-marketing fir m Mailbox

of Savings, took umbrage Monday at the use of the t erm "junk mail."</abstract ><body type="url" > http://www.theonion.com/archive/3-11-01.html </ body >

</Article >


92

XML by example

<?xml version "1.0" ?><CML>

<MOL TITLE="Water" ><ATOMS>

<ARRAY BUITLIN="ELSYM" > H O H</ARRAY></ATOMS><BONDS>

<ARRAY BUILTIN="ATID1" >1 2</ARRAY><ARRAY BUILTIN="ATID2" >2 3</ARRAY><ARRAY BUILTIN="ORDER" >1 1</ARRAY>

</BONDS></MOL>

</CML>


93

XML examples

<?xml version="1.0" ?><rooms >

<room name="Red"><capacity>10</capacity><equipmentList>

<equipment>Projector </equipment></equipmentList>

</room><room name="Green ">

<capacity>5</capacity><equipmentList /><features> <feature>No Roof </feature> </features>

</room></rooms >


94

Application Architectures

XMLrepository

XML processing applications

HTML

VoiceXmlWML

PDF

Postscript


95

What are XML Technologies?

� Xpath – for identifying subsets of a document, used in XSL , Xquery and other XML-based languages.

� DTDs and XML Schema – for describing a dialect of XML.

� Xquery – language for querying XML documents.� SOAP – for making remote procedure calls over

XML:– SOAP is extremely important!


96

History of XML

� eXtensible Markup Language (XML):– Started by W3C in 1996,standardized in 1998.– Inherits many features from SGML:

• Simpler,• Smaller specification,• Stricter.

– Adopted and influenced by many outside of 'document' community.


97

Begin TagsEnd Tags

Tags

Attributes

<?xml version "1.0" ?>

<CML><MOL TITLE="Water" > <ATOMS> <ARRAY BUILTIN="ELSYM" > H O H</ARRAY>

</ATOMS><BONDS><ARRAY BUILTIN="ATID1" >1 2</ARRAY><ARRAY BUILTIN="ATID2" >2 3</ARRAY><ARRAY BUILTIN="ORDER" >1 1</ARRAY>

</BONDS></MOL>

</CML>

Parts of an XML document

Declaration

AttributeValues


98

XML and Trees

� Tags give the structure of a document.

� They divide the document up into Elements, starting at the top most element, the root element.

� The stuff inside an element is its content – content caninclude other elements along with ‘character data’ (CDATA).

CML

MOL

ATOMS BONDS

ARRAY ARRAY ARRAY ARRAY

HOH 12 23 11

Root element

CDATA sections


99

XML Examples

<?xml version="1.0" ?><rooms ><room name ="Red"><capacity >10</capacity ><equipmentList ><equipment >Projector </equipment >

</equipmentList ></room ><room name ="Green"><capacity >5</capacity ><equipmentList /><features >

<feature >No Roof </feature ></features >

</room ></rooms >


100

Rules for Well-Formed XML

� XML requires a document to obey the following rules:– There must be one element that contains all others.– All tags must be balanced.

<BOOK>...</BOOK>

<BOOK />

– Tags must be nested properly:<BOOK> <LINE> this is OK </LINE> </BOOK>

<LINE> <BOOK> this is </LINE> definitely NOT </BOOK> OK

– Text is case-sensitive so:<P> this is not ok, even though we do it all the

time in HTML!</p>


101

More Rules for Well-Formed XML

� The attributes in a tag must be in quotes:– < ITEM CATEGORY=“Home and Garden” Name=“hoe-matic

t500”>

� Comments are allowed:– <!– They are done just as in HTML… -->

� Must begin with:– <?xml version=‘1.0’ ?>

� Special characters must be escaped: the most common are :– < " ' > &

• <formula> x < y+2x </formula>• <cd title="" music">

� An XML document that obeys these rules is Well-Formed. Source: Mark Baker UPC PhD Course 2007

102

From Mark Baker UPC PhD Course 2007

DTD – Document Type Definition

� A DTD is a schema for Xml data� Xml protocols and languages can be standardized

with DTD files� A DTD says what elements and attributes are

required or optional– Defines the formal structure of the language

103From Mark Baker UPC PhD Course 2007

DTD – An Example<?xml version='1.0'?><!ELEMENT Basket (Cherry+, (Apple | Orange)*) >

<!ELEMENT Cherry EMPTY><!ATTLIST Cherry flavor CDATA #REQUIRED>

<!ELEMENT Apple EMPTY><!ATTLIST Apple color CDATA #REQUIRED>

<!ELEMENT Orange EMPTY><!ATTLIST Orange location ‘Florida’>

--------------------------------------------------------------------------------<Basket>

<Apple/>

<Cherry flavor=‘good’/>

<Orange/>

</Basket>

<Basket>

<Cherry flavor=‘good’/>

<Apple color=‘red’/>

<Apple color=‘green’/>

</Basket>


DTD - !ELEMENT

<!ELEMENT Basket (Cherry+, (Apple | Orange)*) >

� !ELEMENT declares an element name, and what children elements it should have

� Wildcards:– * Zero or more– + One or more

Name Children

105


DTD - !ATTLIST

<!ATTLIST Cherry flavor CDATA #REQUIRED>

<!ATTLIST Orange location CDATA #REQUIREDcolor ‘orange’>

� !ATTLIST defines a list of attributes for an element

� Attributes can be of different types, can be requir ed or not required, and they can have default values.

Element Attribute Type Flag


DTD –Well-Formed and Valid<?xml version='1.0'?><!ELEMENT Basket (Cherry+)>

<!ELEMENT Cherry EMPTY><!ATTLIST Cherry flavor CDATA

#REQUIRED>--------------------------------------------------------------------------------

Well-Formed and Valid<Basket>

<Cherry flavor=‘good’/></Basket>

Not Well-Formed<basket>

<Cherry flavor=good></Basket>

Well-Formed but Invalid<Job>

<Location>Home</Location></Job>


What is XML Schema?

� XML Schema is a definition language that allows you to constrain conforming XML documents to a specific vocabulary and hierarchical structure.

� The things you want to define in your language are element types , attribute types , and the composition of both into composite types (called complex types ).

� XML Schema is analogous to a database schema, which defines the column names and data types in database tables.

� XML Schema became a W3C Recommendation (synonymous with standard) on May 5, 2001.


What Is XML Schema?

� Both the schema document and the instance document use XML syntax (tags, elements, and attributes).

� This was one of the primary motivating factors to replace DTDs, which did not use XML syntax.

� Having a single syntax for both definition and instance documents enables a single parser to be used for both.

� Referring back to our database analogy, the databas e schema defines the columns, and the table rows are instances of each definition.

109


Advantages of XML Schemas

� XML Schemas are more advanced than DTDs:– Enhanced datatypes,– Can roll your own datatypes,– Written in the same syntax as instance documents,– Object-oriented-ish,– Can express sets,– Can specify element content as being unique (keys on content)

and uniqueness within a region,– Can define multiple elements with the same name but different

content,– Can define elements with no content,– Can define substitutable elements.

110


What Do Schemas Look Like?� An XML Schema uses XML syntax to declare a set of

simple and complex type declarations: – A type is a named template that can hold one or more values:

• Simple types hold one value, • Complex types are composed of multiple simple types.

� So, a type has two key characteristics: a name and a legal set of values .

� A simple type is an element declaration that includ es its name and value constraints.

� Here is an example of an element called author that can contain any number of text characters:– <xsd:element name=”author” type=”xsd:string” />

� The preceding element declaration enables an instance document to have an element like this:– <author> Mark Baker </author>

111


What Do Schemas Look Like?� Notice that the type attributed in the element

declaration declares the type to be xsd:string:– A string is a sequence of characters.

� There are many built-in data types defined in the XML Schema specification.

� If a built-in data type does not constrain the valu es the way the document designer wants, XML Schema allows the definition of custom data types.


XML Schemas are Extensible

� XML Schemas are extensible, just like XML, because they are written in XML.

� With an extensible schema definition you can:– Reuse your schema in other schemas,– Create your own data types derived from standard

types,– Reference multiple schemas from the same document.


episodes.xsd

<?xml version="1.0" encoding="UTF-8"?><xs:schema xmlns:xs ="http://www.w3.org/2001/XMLSchema "

elementFormDefault ="qualified "><xs:element name="action " type ="xs:string "/><xs:element name="dialog ">

<xs:complexType ><xs:simpleContent >

<xs:extension base="xs:string "><xs:attribute name="speaker " type ="xs:string “ use=" required "/>

</xs:extension ></xs:simpleContent >

</xs:complexType ></xs:element ><xs:element name="episode ">

<xs:complexType ><xs:choice maxOccurs ="unbounded ">

<xs:element ref="dialog "/><xs:element ref="action "/>

</xs:choice ></xs:complexType >

</xs:element ></xs:schema >

keywordsmust useSchemanamespace

<xs:element> used to declare elements

Elements and Attributes with textualdata become type xs:string

The type of an elementis given by its contentor by the type attribute


Predefined Simple Types

� Both Elements and Attributes have Types .� You can specify a predefined simple type or make

your own.� XML Schema has a lot of built-in data types. � Here are the most common types:

– xs:string– xs:decimal– xs:integer– xs:boolean– xs:date– xs:time


Using Specific Simple Types

� Using type “integer” for the zip, ensures that no alpha-numeric characters are put in it (what about non-US countries!?):

<?xml version="1.0" encoding="UTF-8"?><xsd:schema xmlns:xsd ="http://www.w3.org/2001/XMLSchema " ><xsd:element name="Address ">

<xsd:complexType ><xsd:sequence ><xsd:element name="Street " type ="xsd:string "/><xsd:element name="Apartment " type ="xsd:string "/><xsd:element name="Zip" type ="xsd:integer "/>

</xsd:sequence ></xsd:complexType >

</xsd:element ></xsd:schema >


Default and Fixed Values

� Simple elements can have a default value OR a fixed value declared.

� A default value is automatically assigned to the el ement when no other value is specified.

� In the following example the default value is 42:

<xs:element name=“LifeAndUniverse" type="xs:integer" default=“42"/>

� A fixed value is also automatically assigned to the element; however, the XML file cannot specify another value.

� In the following example the fixed value is 42:

<xs:element name=“LifeAndUniverse" type="xs:integer" fixed=“42"/>

117


Attributes

<xs:element name="dialog "><xs:complexType ><xs:simpleContent ><xs:extension base="xs:string" ><xs:attribute name="speaker"

type ="xs:string " use=" required "/></xs:extension >

</xs:simpleContent ></xs:complexType >

</xs:element >

…

The attribute declarationis part of the type ofthe element.


Attributes

<xsd:element name="cartoon "><xsd:complexType >

<xsd:sequence ><xsd:element ref="character " minOccurs ="0"

maxOccurs ="unbounded "/></xsd:sequence ><xsd:attribute name="name" type ="xsd:string " use=" required "/><xsd:attribute name="genre " type ="xsd:string " use=" required "/><xsd:attribute name="syndicated " use=" required "><xsd:simpleType ><xsd:restriction base="xsd:NMTOKEN ">

<xsd:enumeration value ="yes"/><xsd:enumeration value ="no"/>

</xsd:restriction ></xsd:simpleType >

</xsd:attribute ></xsd:complexType >

</xsd:element >

Attribute list is partof the type of the element.

Default is given by the “use” attribute.

If an attribute type is more complicated than a basic type, then we spell out the type in a type declaration.


1.4 Web

services basics

EEDC

34330


120

Web Services?

� Web Services are encapsulated, loosely coupled contracted functions offered via standard protocols where:– Encapsulated – implementation of the function is never seen

from the outside– Loosely coupled – changing the implementation of one

function does not require change of the invoking function– Contracted – there are publicly available descriptions of the

function’s behavior, how to bind to the function, and its input and output parameters

121

Web Services Components

� XML – Extensible Markup Language

� SOAP – Simple Object Access Protocol

� WSDL – Web Services Definition Language

� UDDI – Universal Discovery Description Integration

UDDI

WSDL

SOAP

XML

HTTP FTP SMTP

Web

Ser

vice

s

XML normally carried using HTTP

122

Introduction to Web Services

� Microsoft coined the term “Web services” in June 2000, when the company introduced Web services as a key component of its .Net initiative, – A new vision for embracing the Internet in the development,

engineering and use of software.

� As others began to investigate Web services, it became clear that the technology could revolutionis e distributed computing.

� Now, nearly every major vendor is marketing Web services tools and applications and Web services ar e radically changing IT architectures and partner relationships.


123


� Web services encompass a set of related standards that can allow any two computers to communicate and exchange data via a network, such as the Internet.

� The primary standard used in Web services is the Extensible Markup Language (XML) developed by the World Wide Web Consortium (W 3C).

� Developers use XML tags to describe individual pieces of data, forming XML documents, which are text-based and can be processed on any platform.


124


� XML’s portability and its rapid adoption throughout the industry made it the obvious choice for enablin g cross-platform data communication in Web services.

� XML provides the foundation for many core Web services standards:1. SOAP, 2. WSDL, 3. UDDI,

� Almost every type of business can benefit from Web services such as:– Expediting software development, – Integrating applications and databases, – Automating transactions with suppliers, partners, and clients.


125


� SOAP (was originally called the Simple Object Access Protocol) is an XML vocabulary that lets programs on separate computers to interact across a network (via RPC).

� WSDL (Web Services Description Language) is another XML vocabulary that lets developers describe Web services and their capabilities in a standardized format.

� UDDI (Universal Description, Discovery and Integration) is a framework that defines XML-based registries where businesses can publish information about themselves and the services they offer.


126

Web Services

1. Client queries registry to locate service.

2. Registry refers client to WSDL document.

3. Client accesses WSDL document.

4. WSDL provides data to interact with Web service.

5. Client sends SOAP-message request.

6. Web service returns SOAP-message response.

WSDL Document

UDDIRegistry

WebService

Client

1

2

3

4

5

6


127

XML Messaging: SOAP

� SOAP 1.1 defined:– An XML envelope for XML messaging:

• Headers + body.

– An HTTP binding for SOAP messaging:• SOAP is “transport independent”.

– A convention for doing RPC,– An XML serialization format for structured data.

� SOAP Attachments adds:– How to carry and reference data attachments using in a MIME

envelope and a SOAP envelope.

128

What is SOAP?

� SOAP is a lightweight protocol for exchange of information in a decentralized, distributed environment using XML.

129

SOAP over HTTP

POST /StockQuoteProj/servlet/rpcrouter HTTP/1.0Host: localhost:9081Content-Type: text/xml; charset=utf-8Content-Length: 469SOAPAction: ""

<?xml version='1.0' encoding='UTF-8'?>

<SOAP-ENV:Envelopexmlns:SOAPENV=“http://schemas.xmlsoap.org/soap/enve lope/”xmlns:xsi="http://www.w3.org/2001/XMLSchema-instanc e"

xmlns:xsd="http://www.w3.org/2001/XMLSchema">

<SOAP-ENV:Body><ns1:getQuote

xmlns:ns1=“http://tempuri.org/StockQuoteService”><symbol xsi:type="xsd:string">IBM</symbol>

</ns1:getQuote></SOAP-ENV:Body>

</SOAP-ENV:Envelope>

The SOAP envelope as the HTTP payload

The HTTP header

130

SOAP Endpoint Reference

POST /servlet/rpcrouter HTTP/1.1

Host: www.messages.com

Content-Type: text/xml; charset="utf-8"

Content-Length: nnnn

SOAPAction: ""

<SOAP-ENV:Envelope

xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/env elope/"

<SOAP-ENV:Body>

<ns1: getMessage xmlns:ns1="urn:NextMessage"

SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/ soap/encoding/">

<UserID xsi:type="xsd:string">JDoe</UserID>

<Password xsi:type="xsd:string">0JDOE0</Password>

</ns1:getMessage>

</SOAP-ENV:Body>

</SOAP-ENV:Envelope>

85.34.235.95 80 /servlet/rpcrouter/getMessage

131

Web Services Description Language

� WSDL provides functional description of network services: – IDL description,– Protocol and deployment details,– Platform independent description,.– Extensible language.

� A short history:– WSDL v1.0, 9/2000,– WSDL v1.1 submitted to W3C 3/2001,– A de facto industry standard.

132

WSDL Structure

� portType:– Abstract definition of a service

(set of operations)

� Multiple bindings per portType:– How to access it– SOAP, JMS, direct call

� Ports– Where to access it

Service

Port(e.g. http://host/svc)

Binding(e.g. SOAP)

Abstract interface

portType

operation(s)

inMesage outMessage

Port

Binding

133

Using WSDL

� As extended IDL: WSDL allows tools to generate compatible client and server stubs:– Tool support for top-down, bottom-up and “meet in the middle”

development.

� Allows industries to define standardised service interfaces.

� Allows advertisement of service descriptions, enables dynamic discovery and binding of compatible services:– Used in conjunction with UDDI registry

� Provides a normalised description of heterogeneous applications.

134

Summary: Core technologies used for WS

� XML� SOAP

– Simple Object Access Protocol – a framework for exchanging XML-based information in a network – the currently most hyped XML/Web service technology

� WSDL – Web Service Description Language – an XML-based language for describing network services – WSDL descriptions of capabilities and locations of services – like an interface description language for Web services – communication using SOAP or direct HTTP

� UDDI – Universal Description, Discovery, and Integration– provides a registry mechanism for clients and servers to find each other – uses SOAP for communication


1.4 REST

VersusSOAP

(Homework)

EEDC

34330


136

REST OR SOAP?

� I am seeing a lot of new web services are implemented using a REST style architecture these days rather than a SOAP one.

� Imagine that you are Roy Fieldinghttp://www.ics.uci.edu/~fielding/

137

REST OR SOAP?

� Why Use "REST" Architecture for Web Services?

You can use 2 minutes5

138

Elevator Pitch

� An elevator pitch summary used to quickly and simply define a product, service, or organization and its value proposition.

� The name "elevator pitch“ reflects the idea that it should be possible to deliver the summary in the time span of an elevator ride, or approximately thirty seconds to two minutes.

139

Investors

Your classmates are very important investors

capture the attention of a potential investor!

140

INDIVIDUAL HOMEWORK 2

Procedure for delivering1. Find the information 2. Choose your argumentation3. Build the presentation

– 3 minutes, ONLY!– FREE template, FREE number of slides

4. Upload the presentation on to slideshare (or similar)

5. Link your presentation to EEDC students website– Find the correct post and include a comment with the link the

presentation

6. Check that everything is ok before the deadline

141

Procedure for presenting homework

1. Prepare the presentation and bring it to the class with your «pendrive» or similar– Optionally you could use the uploaded presentation

2. three students will have the opportunity for take th e elevator– The students will be chosen at random

3. After the presentation investors will choose the must convincing presentation

142

2n homework: SOAP vs REST

� Delivery deadline: – Monday 05/03/2012 at 11:00am

� Presentation: – Monday 05/03/2012 at 12:00am ( class room)


1.6 ServiceLevel

Parameters

EEDC

34330


144

Some BASIC BASIC concepts

� Performance measurements– Load:

• Clients “using” an application at a particular time• Client life-cycle is (web example):

– Page request• 1 HTML page -> X requests for static/dynamic content

– “Think time” while the page is read

• The aggregate load for a large number of clients results in spikes

– Type of load:• Active clients:

– Issuing requests

• Concurrent clients:– Active clients + clients connected but not issuing requests at the

moment

– Peak load: Maximum number of concurrent clients observed

145


� Throughput:– Number of “services”/jobs performed in a period of time– Can be measured in different units, depending of the level of

abstraction• Responses / second• Sessions completed / second• ...• Jobs/second• …

– Units are know as…• Hits/sec• Transaction rate• Page rate• …

146


� Performance measurement: Throughput curve

Load

147


� Response time:

– Time required to process a request

– Covers the period of time in between the time the request is issued and the time when the response is received by the client

– Commonly, in ms units

148


149

Example: The cost of Security

� SSL encryption protocol phases:• Connection establishment, with the associated key generation

if necessary• Reusing of previously generated encryption keys

� Connection establishment can be accelerated:• Key generation (full handshake)• Key reusing (resumed handshake)

� Cost:• Full handshake: 200ms• Resumed handshake: 20ms

(Pentium Xeon a 1,4Ghz)

150


� Performance impact can be easily calculated

• 5 full handshakes/sec and CPU if the cost is 200ms!!

151


� Workarounds:• Dedicated hardware (SSL-offload, asymetric multiprocessors)• Admission control

• resumed-handshakes first!

• Set-up the server to increase the throughput in terms of sessions/sec

• Big impact in the system performance!• Caution: what if we decrease the server TCP timeout?

152

Embracing Failure

� As more systems encompass ever-increasing numbers of components, even a small fault rate on individual processors will generate multiple faults across the components, stopping long-running applications in their tracks.– 1000s of core,– 2+ Gbytes Memory per core,– Caching problems,– File systems,– Networks,– Operating Systems,– Middleware– Applications – algorithms.– ...

Source: Mark Baker

153

Availability

� Reliability is all to do with the probability that the system will function correctly and is usually measured by the MTBF.

� Availability is simply defined as the percentage of time over a well-defined period that a system or service is available for users.– is simply the time an item is able to operate as a ratio to the time

in service

154

Example

155

Classifying Systems According to Availability

156

Measuring Availability

Availability:

Unavailability:

MTTRMTTF

MTTF

+=A

MTTRMTTF

MTTR

+=U

� MTTF: mean time to failure

� MTBF: mean time between failures

� MTTR: mean time to repair

157

Improving Availability

� Reduce frequency of failures� Reduce time to recover from failures:

– Time to detect failures– Time to diagnose failures– Time to determine possible solutions– Time to correct the problem.

� In general, it is easier and less costly to reduce MT TR than to increase MTTF.

158

Availability Example

� A Web site is composed of 2 Web servers, one application server, and one database server. Historical data shows that the application server i s rebooted every 20 days on average. If the system administrator takes 10 minutes to reboot the machine, what is the application server availabilit y?

159

Availability Example

� Solution– MTTF = 20 days = 2 * 24 * 60 = 28,800 min– MTTR = 10 min– A = MTTF / (MTTF + MTTR)

28,800 / (28,800 + 10) = 99.965%

� What if the system administrator were able to cut reboot time in 20%?

– A = 28,800 / (28,000 + 8) = 99.972%

� Later we will come again over failure and self-heal ing


1.7

Distributed Systems become complex systems

EEDC

34330


161

Today parameters:Trust + Risk + Eco + Cost

� Trust in the IT/Cloud ecosystem is a multifaceted aspect related to, among others, risk and security aspects, as well as perceptions and previous experiences.

� Risk corresponds to hazardous events that have a negative impact on the provision of a functionality. Thus, identifyi ng, assessing, treating, and monitoring risk is imperative for pro active operation of providers in the IT ecosystem.

� Environmental concerns reflected in upcoming legisl ation have increased the awareness of the ecological ( Eco) impact of the ICT industry. The level of ecological awareness can now be a deciding factor between competing providers. Furthermore, ris ing electricity prices may guide the execution of services to locat ions in which the requested services are provided in a more effic ient way.

� Cost aspects are necessary to balance the previous three goals. Optimizing for high trust levels between stakeholders , reduced risk, and incorporating eco-efficiency aspects is t rivial if cost is not an issue.

162

Complexity!!!!!!!!!!!!!

The current requirements present in the execution environments (middleware), with the objective of efficiently managing resources under heterogeneous workloads, have made them become a very complex component of current systems.

Shared Datacenters

Supercomputer Center

Transactional Workload

Mixed Workload

I/O intensiveWorkload

CPU intensiveWorkload . . . .

. . . .

. . . .

PervasiveComputing

163

� How to manage complexity at all levels?– Decompose into components?

• Break large, complex system into independent components• We need interfaces between the components

� Many issues and many tradeoffs– Different middleware components according different workloads

� Need a global view of systems� Complexity still reigns

– Diagnosing web application faults is very hard• Is it the network, app server, database, OS, client, …?

Complexity

164

Solution: Self-management

� Self-management is considered the solution to this complexity and a way to increase the adaptability o f the execution environments as well as their performance.

Shared Datacenters

Supercomputer Center

Transactional Workload

Mixed Workload

I/O intensiveWorkload

CPU intensiveWorkload . . . .

. . . .

. . . .

PervasiveComputing

165

Research Area: Autonomic computing

� ”Systems with selfware capabilities can automatically adapt their behavior in relation to t he configuration of the drastically changing environment and their user preferences.”

� Autonomic computing is an industry-wide effort to develop systems that configure, heal, and protect themselves

� Self-* properties

166

Predictor component

� Architecture for building self-managing systems

ResourceManager

Sensors Effectors

Managed Element

ManageabilityInterface

Sensors Effectors

Knowledge

Plan

ExecuteMonitor

Analyze

DataAction

Autonomic Manager

Models Requiredfor Real-TimePredictor component

167

Predictor component

� The adjective "real-time" – refers to a level of responsiveness that a user senses as

immediate or nearly immediate or that enables a computer to keep up with some external process.

� In this scenario the Predictor is a critical component since it is the basis for ensuring that the requirements are continuously met.– The Predictor is made of two subcomponents

• model generator : automatically constructs a performance model

• model solver is used to analyze the model.

168

Predictor component

� Different types of performance models can be used to implement the (QoS) Predictor component:– Modeling formalisms like queueing networks and analytical

solution methods shown in this course could be used.

� Real-time models has benefited from the force that has dominated change in all of computing: Speed.– Speed: faster computers, faster networks, faster storage.– One thing that this speed allows us to do in prediction is to solve

models that were previously intractable in real-time.

169

Real-time performance prediction models

� New alternatives to current real-time performance prediction models:

• Online Simulation• Machined Learning• …

– Which provide greater modeling power and expressive ness than conventional modeling formalisms like queueing networks.

MORE IN THIS COURSE!

Technology

Part.1. Execution Environment for Distributed Computing