design of d istributed s ystems programming of interactive system s lecture 3

Design of Distributed Systems

Programming of Interactive Systems Lecture 3

Fredrik Kilander

Wei Li

11/2/2006 Distributed System Support for Ubiquitous computing

2/32

Agenda

• RMI

• Jini (Dynamic Service Discovery)

• Overlay Networks– Web naming scheme– Data Representation (XML)

• Web Service

• System Architecture

• Perspectives on interactive systems


3/32

Binding a Client to a Server

Client-to-server binding in DCE

(distributed computing environment 1990-)

2-15

Endpoint= IP+Port

(server, endpoint) pairs


4/32

• Clients get the service location directly from the registry

• RMI Registry is known to both RMI Client and RMI Server

Java RMI

Client

Register(Service Binding)

Lookup

stubService

stub

RMI Registrystub

51

2 3

4

http://download.oracle.com/javase/tutorial/rmi/TOC.html


5/32

Passing Object by Value or Reference (RMI)

proxy1MediaPlayerController

SkeletonMedia Player

Interface Method:

void Play ();void Play (String filename);void Play (MP3Selector mps);

Interface Method:

void Play();void Play (String filename);void Play (MP3Selector mps);

Three cases:1) Play () without parameters. // only method name will be sent

“http://myhost/a.mp3”

2) Play (“http://myhost/a.mp3”) // send filename as a copied object (value/copy)

3) Play (mps) { // send the copy of proxy2 play(mps.getLatestMP3()) // (reference to MP3Selector) }

Skeleton

Machine C

MP3Selector

proxy2proxy2Machine A Machine B

“http://myhost/a.mp3”

• The object to send to another machine has to be Serializable.

• The object to send has to have the class definition in the classpath of the receiving side

• Setup security policy file

http://java.sun.com/developer/onlineTraining/rmi/RMI.html


6/32

Java Jini

• Jini is a technology for building service- oriented architectures.

• Jini defines a programming model which exploits and extends Java technology.

• Jini is a generally stable, fault-tolerant, scalable, dynamic, and flexible solution.


7/32

Java Jini

• Services discover lookup servers and register with multiple properties

• Clients discover lookup servers and query them for services

• Discovery with multicast (LAN) or unicast (WAN)


8/32

Java Jini

• RMI: registry is co-located with the service

• Jini: lookup services can be anywhere

• RMI: client must know the registry host

• Jini: clients discover lookup services

• RMI: service found by name

• Jini: service found by name, attributes and interfaces


9/32

JiniTwo ways to connect to a Lookup Service:• Multicast to discover local lookup services automatically (i.e. previously unknown)• Unicast to connect to a lookup service on a known host (e.g., remote subnet)


10/32

JiniTwo ways to connect to a Lookup Service:• Multicast (1-M) to discover local lookup services automatically (i.e. unknown)• Unicast (1-1) to connect to a lookup service on a known host (e.g. on a remote subnet)

FirewallLocalAreaNetwork

Internet

Multicast

UnicastClient

Lookup service

Lookupservice


11/32

Jini (Registering a Service)

(1) Multicast/Unicast to discover the LUS

(2) Retrieve a registrar object from the LUS

(3) Use registrar to send a service object to the LUS


12/32

Jini (Discover a service)

(2) Retrieve a registrar object from LUS

(3) Search service using registrar

(1) Multicast/Unicast to connect to LUS

(4) Retrieve a service object (proxy)


13/32

JINI

http://jan.netcomp.monash.edu.au/java/jini/tutorial/Jini.html

http://www.jini.org

(LookupService)

2) Dynamic Service Discovery:

• Multicast to discover local lookup service automatically

• Unicast is used for a service to register from a remote subnet

1) Simplified Running Environment:

• Only one Jini lookup service is necessary in a local Jini network (local subnet). RMI and RMIRegistry is optional.

(2)

(1)(3

)

(4)

(5)

http://jan.netcomp.monash.edu.au/java/jini/tutorial/Jini.html

http://www.jini.org/

http://www.jini.org/


14/32

Jini distributed garbage collection

• Leases (time-delimited promises)

• Example:– A service registers a service object on the

lookup server in return for a lease– The service must renew the lease every five

minutes (”I am still here”)– When the lease expires the LUS deletes the

service object from its database


15/32

Jini – dead service

ServiceLookupservice

Client

Service registersa service object

LuS returns a leaseClient queries LuS

LuS return service object

Service crashes

Service renews lease

Client tries to call service

Client getsRemoteException

Lease expiresLuS discards theservice object

Client discards theservice object


16/32

Middleware and Openness

In an open middleware-based distributed system, the protocols used by each middleware layer should be the same, as well as the interfaces they offer to applications.

Early Binding: Language, Interface.


17/32

Overlay Network Based on MOC & Socket

• Sockets gives a simple abstraction for message transfer over network

• With sockets one can construct a new abstract network over the underlying IP network

• Prerequisites:– New address schema (Naming) and its– Name resolution mechanism (routing)


18/32

Web naming scheme

• Uniform Resource Identifiers (URI) come in two forms:–URL: Uniform Resource Locator

–URN: Uniform Resource Name


19/32

Uniform Resource Locators

Often-used structures for URLs.a) Using only a DNS name.b) Combining a DNS name with a port

number.c) combining an IP address with a port

number.

NameUsed for

Example

http HTTPhttp://www.cs.vu.nl:80/globe

ftp FTPftp://ftp.cs.vu.nl/pup/minx/README

fileLocal file

file:/edu/book/work/chp/11/11

telnetRemote login

telnet://flits.cs.vu.nl

Common schemes


20/32

urn : isbn : 0-13-349945-6

• Three parts: Scheme : Name space identifier : Name of resource

• The name space identifier determines the syntactic rules for the third part. The third part may have different structure depending on the name space identifier. So URNs are not publicly resolveable.

• In contrast to URLs, URNs are location-independent which means URNs usually are not related to any specific entity (only used as a name space).

Uniform Resource Names


21/32

Locating URL (Name Resolving)

• Domain Name System (HostName -> IP)– Each computer has to be

assigned an IP address and DNS server IP address manually or through DHCP server.

– DNS Request (nslookup) sends the hostname to the specified DNS server.

– The DNS server returns the IP if it knows it, otherwise, the request is forwarded to upper-layer DNS server.

Record of E’s IP

User host


22/32

Data Representation / XML (1)• Extensible Markup Language

(XML) is a standard format for interchanging structured documents.

• XML is designed to describe data

• HTML was designed to present data.

• Anyone can use XML to define data in any tree-based structure.

• To be able to distinguish different structures, XML Name Spaces are used to enable different structures of data to co-exist in one document.

<?xml version="1.0" ?> <note xmlns:note=“http://tv.com/note.xml”> <note:to>Tove</note:to> <note:from>Jani</note:from> <note:heading>Reminder</note:heading> <note:body>Don't forget me this weekend!</note:body> </note>


23/32

Data Representation /XML (2)

• It is the reader application’s responsibility to understand (parse) the elements in the XML document.

• Extensible Stylesheet Language Transformations (XSLT) is a language for converting XML document from one structure to another.

• XSLT is one way to help the interoperation between distributed systems using different standards.

XSLT processorInputXML

Outputtext

XSL transformationrules


24/32

Data Representation /XML (3)• XML is self-describing• XML treats all data as text• Significant memory overhead• Examples:

–XML-RPC–JXTA messages–Web Service, SOAP


25/32

Overlay Networks

• Examples:– P2P networks (Content-oriented network/P2P

file sharing, SIP)– Naming: auto-generate UUID and register – Routing: JXTA Rendezvous etc


26/32

Web ServicesXML Web services are the fundamental building

blocks in the move to distributed computing on the Internet, it takes the ideas and principles of the Web and apply them to enable computer-computer interactions (B-to-B transactions):

• SOAP (Simple Object Access Protocol): provides a simple and lightweight mechanism for exchanging structured and typed information using XML:

• WSDL (Web Services Description Language): describing service information including message contents, service location, communications protocol (IDL).

• UDDI (Universal Discovery Description and Integration): for registering Web services so that potential users can find them easily (service yellow pages/directory service).

• programming-language neutral

SOAP


27/32

Clients/Servers Architecture

1.25

• General interaction between a client and a server.


28/32

Three-tiered C/S model

• The general organization of an Internet search engine into three different layers

1-28


29/32

Multitiered Architectures

• Alternative client-server organizations (a) – (e).

1-29


30/32

Conclusion

• Distributed System technologies:– Procedure- and object-based communication– MOM and socket– Naming and resolution– Overlay networks– XML, Software architecture

• Today– Service-Oriented Architecture (cloud computing)– Dynamic service access (late binding)– Open standards– Still ’standards wars’: e.g. HTML5 video, Android

versions

Perspectives on interactive systems


32/32

Contents

• Interactive systems from a user perspective

• Interactive systems from a systems perspective

• Desirable properties of tools

• Analysis of Java, Python, C#

• Other considerations

Interactive systems from a user perspective

•Supports cooperation between, and in, groups of users•CSCW, Wiki, Facebook, Twitter, Second Life, Blue Mars•Interactive spaces

•Supports shifting modalities and forms of interaction•WWW•Cell phones, PDA•Voice, gesture and tactile interfaces (wii, iPhone)

Interactive systems from a user perspective

•Supports mobility and distance•Users moving in the real world•Users moving between different systems

•Supports interaction with resources in the environment•File sharing (transparent document management)•Useful devices, sensors

Interactive systems from a systems perspective

•Distributed systems•Hierarchy: Client-Server, Peer-to-peer, open/closed•Computer communication issues

•Transport, interaction protocols, security

•Heterogenous systems and general interoperability•Hardware•Operating systems•Programmering languages•Software versions

Interactive systems from a systems perspective

•Exotic hardware•Cell phones, sensors, RFID, micronets

•Dynamics•The availability of resources; users, clients, services•Establishing and maintaining interaction sessions


37/32

To build interactive systems tools are needed

• Communication methods and protocols

• Programming languages

• Runtime environments

Desirable properties of tools

Hardware independence•Cell phones•PDA:s•Wearable computers (laptops)•Server computers

OS independence•Linux/Unix/OS X•Symbian/Android•Windows family

Computer communication•Remote Procedure Call (RPC) •TCP/IP, Serial ports, USB, FW





Virtualization





Virtualization

Host system:vmWare, C++..

Language system:Java, Python, elisp

Hardware independence

OS independence

Computer communication

Security

Analysis of Java, Python, C#

Java Python C#

yes yes yes

yes yes

yes yes*

yes yes*

no*

yes

no


43/32

• interaction implies communication

• choose tools that enable and simplify communication (e.g. C# i Windows)

• make abstract communication (t ex XML-RPC, SIP, SOAP)

To reflect upon …


44/32

• Other considerations:– asyncronous communication– object-oriented programming– mobile code– the agent metaphor– launch and maintenance

• code distribution• version management


45/32

End

design of d istributed s ystems programming of interactive system s lecture 3

Documents