Design of Distributed Systems Programming of Interactive Systems Lecture 3

1
Design of Distributed Systems Programming of
Interactive Systems Lecture 3

• Fredrik Kilander
• Wei Li

2
Agenda

• RMI
• Jini (Dynamic Service Discovery)
• Overlay Networks
• Web naming scheme
• Data Representation (XML)
• Web Service
• System Architecture
• Perspectives on interactive systems

3
Binding a Client to a Server
2-15
Endpoint IPPort
(server, endpoint) pairs
Client-to-server binding in DCE (distributed
computing environment 1990-)
4
Java RMI

• Clients get the service location directly from
  the registry
• RMI Registry is known to both RMI Client and RMI
  Server

http//download.oracle.com/javase/tutorial/rmi/TOC
.html
Register(Service Binding)
Lookup
2
3
1
Client
5
stub
4
5
Passing Object by Value or Reference (RMI)

• 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

Interface Method void Play()void Play (String
filename)void Play (MP3Selector mps)
Machine A
Machine B
proxy2
Interface Method void Play ()void Play (String
filename)void Play (MP3Selector mps)
Media Player
Skeleton
Three cases1) Play () without parameters. //
only method name will be sent
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)
http//java.sun.com/developer/onlineTraining/rmi/R
MI.html
6
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
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
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
Jini

• Two 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
Jini

• Two 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)

Multicast
Client
Unicast
Local Area Network
Lookup service
Firewall
Internet
Lookup service
11
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
Jini (Discover a service)
(2) Retrieve a registrar object from LUS
(1) Multicast/Unicast to connect to LUS
(3) Search service using registrar
(4) Retrieve a service object (proxy)
13
JINI

• 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.

(LookupService)
(2)
(4)
(1)
(3)
(5)
http//jan.netcomp.monash.edu.au/java/jini/tutoria
l/Jini.html http//www.jini.org
14
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
Jini dead service
Lookup service
Service
Client
Service registers a service object
Client queries LuS
LuS returns a lease
LuS return service object
Service renews lease
Service crashes
Client tries to call service
Client gets RemoteException
Lease expires LuS discards the service object
Client discards the service object
16
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
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
Web naming scheme

• Uniform Resource Identifiers (URI) come in two
  forms
• URL Uniform Resource Locator
• URN Uniform Resource Name

19
Uniform Resource Locators
Common schemes
Name Used for Example
http HTTP http//www.cs.vu.nl80/globe
ftp FTP ftp//ftp.cs.vu.nl/pup/minx/README
file Local file file/edu/book/work/chp/11/11
telnet Remote login telnet//flits.cs.vu.nl

• Often-used structures for URLs.
• Using only a DNS name.
• Combining a DNS name with a port number.
• combining an IP address with a port number.

20
Uniform Resource Names
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).

21
Locating URL (Name Resolving)

• Domain Name System (HostName -gt 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 Es IP
User host
22
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.

lt?xml version"1.0" ?gt ltnote xmlnsnotehttp//t
v.com/note.xmlgt ltnotetogtTovelt/notetogt
ltnotefromgtJanilt/notefromgt ltnoteheadinggtRemind
erlt/noteheadinggt ltnotebodygtDon't forget me
this weekend!lt/notebodygt lt/notegt
23
Data Representation /XML (2)

• It is the reader applications 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.

Output text
Input XML
XSLT processor
XSL transformation rules
24
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
Overlay Networks

• Examples
• P2P networks (Content-oriented network/P2P file
  sharing, SIP)
• Naming auto-generate UUID and register
• Routing JXTA Rendezvous etc

26
Web Services

• XML 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
Clients/Servers Architecture

• General interaction between a client and a server.

1.25
28
Three-tiered C/S model

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

1-28
29
Multitiered Architectures

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

1-29
30
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

31
Perspectives on interactive systems
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

33

• 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)

34

• 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

35

• 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

36

• 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
To build interactive systems tools are needed

• Communication methods and protocols
• Programming languages
• Runtime environments

38
Desirable properties of tools

• Hardware independence
• Cell phones
• PDAs
• 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

39
Desirable properties of tools

• Hardware independence
• Cell phones
• PDAs
• 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
40
Desirable properties of tools

• Hardware independence
• Cell phones
• PDAs
• 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
Host system vmWare, C..
Language system Java, Python, elisp
41
Analysis of Java, Python, C
Java
Python
C
yes
yes
yes
Hardware independence OS independence Computer
communication Security
yes
yes
no
yes
yes
yes
yes
yes
no
42
Analysis of Java, Python, C
Java
Python
C
yes
yes
yes
Hardware independence OS independence Computer
communication Security
yes
yes
no
yes
yes
yes
yes
yes
no
43
To reflect upon

• interaction implies communication
• choose tools that enable and simplify
  communication (e.g. C i Windows)
• make abstract communication (t ex XML-RPC, SIP,
  SOAP)

44

• Other considerations
• asyncronous communication
• object-oriented programming
• mobile code
• the agent metaphor
• launch and maintenance
• code distribution
• version management

45
End