Multithreaded and Distributed Programming How Distributed Programs Communicate

1
Multi-threaded and Distributed Programming
How Distributed Programs Communicate

• ECEN 5053 Software Engineering of
• Distributed Systems
• University of Colorado

Distribute Systems Concepts and Design, 4th ed.
Coulouris, Dollimor and Kindberg,
Addison-Wesley, 2005
2
Distributed Object Communications (part 2)

• REVIEW
• Synch vs. Asynch
• MOM
• Data marshalling
• Java Serialization
• XML

3
ATM

• ATM Teller object works with Account
• Teller object is local to the ATM
• Account object is in some process back at the
  bank
• How do they talk to each other?

4
Ordering Pizza

• Should you call or drive?
• Can you email or fax the order?
• If you call, do they have an answering machine?
• How do you get their phone number?
• Or should you just cook pizza at home?
• If its delivered, do you wait for them to ring
  the doorbell, or do you walk to the curb once
  every minute?

5
Talking to Remote Objects

• Finding the object you want
• Getting a reference to the object
• Invoking methods on the object
• Receiving results
• Differences from talking to local objects

6
Finding The Object You Want

• Requires a naming or directory service
• Finding hosts on the Internet Domain Name
  System (DNS)
• You give it a URL
• DNS gives you an IP address
• RMI Registry - java.rmi.Naming
• JNDI
• CORBA Name Service

7
Getting The Object You Want

• Ask the server that has the object to send it to
  you
• Identify it by some sort of key
• The server sends you a proxy or stub
• The stub supports the same interface as the
  actual remote object
• Stub and Skeleton classes are usually machine
  generated, using a program such as RMIC.

8
Invoking Methods on the Object

• Client talks to the stub
• Stubs job
• Specifies the method to execute
• Marshalls the parameters
• Sends method ID and parameters to the skeleton
• Skeletons job
• Unmarshalls parameters
• Calls the actual object

9
Receiving Results

• Skeletons job
• Receives results from the actual object
• Marshalls the results
• Sends results to the stub
• Stubs job
• Unmarshalls the results
• Passes them back to the client

10
CORBA

• Object interfaces are defined in CORBA Interface
  Description Language (IDL)
• CORBA interface compiler for a specific
  language/OS/platform creates code to marshall and
  unmarshall objects
• Not all vendors CORBA tools are interoperable
• Have to translate to/from IDL
• IIOP not firewall friendly

11
CORBA (cont.)
12
CORBA (cont.)
13
Remote Method Invocation (RMI)

• In CORBA, the Broker is called the ORB in RMI,
  it is called the RMIRegistry.
• RMI also makes use of machine-generated Stubs and
  Skeletons, which together encapsulate the code
  for marshaling data (in this case using Java
  serialization). Stubs are client-side Proxies
  Skeletons are server-side Adapters.
• RMI also uses a Naming service, for clients to
  find remote services.

14
RMI (cont.)

• Consider an example, a MessageHandlingRMI
  service.
• 1) Define a remote interface IMessageHandlerRMI
  (extends java.rmi.Remote).
• 2) Create a server-side class to implement the
  interface MessageHandlerRMI (extends
  java.rmi.server.UnicastRemoteObject) .
• 3) Run rmic MessageHandlerRMI to create
  MessageHandlerRMI_Stub.class MessageHandlerRMI_S
  keleton.class.
• 4) Run rmiregistry on the remote host to start
  the Broker.
• 5) Put all the class files in the right places.
• 6) Run java MessageHandlerRMI on the host the
  main() method calls Naming.rebind( Message
  Service, new MessageHandlingRMI())
• 7) The client gets a local interface for
  communicating with the remote service
• IMessageHandlingRMI service (IMessageHandlingRMI
  ) Naming.lookup( RMI_HOST_NAME Message
  Service )

15
Messaging

• Asynchronous
• Messages are passed between them on queues
• Queues are provided by MOM
• Producers put message on queues
• Consumers get messages off queues
• Can poll for messages (not common)
• Can be notified when messages arrive
• Assign listeners to the queue
• Can be made to appear synchronous to client

16
Messaging (cont.)

• Durable subscriptions
• If the receiver is not running, the queue will
  deliver the messages when the receiver comes back
• Persistent queues
• All messages that are put on the queue are also
  saved to a database
• Listeners
• Methods that wait to receive messages from queues
• Separate thread owned by the receiver process
• When a message arrives, the listener is woken
  up

17
Messaging Point to Point

• One consumer
• Usually owns the queue
• Many producers
• Process that wants to send a message to the
  receiver puts a message on the receivers input
  queue
• Point-to-Point messaging can also be done with
  technologies other than MOM

18
Messaging Publish/Subscribe

• One or more producer
• One of them, or central service, owns the queue
• Many consumers
• Consumers subscribe to topic queues
• Consumer is usually not interested in every
  message published on the topic queue
• Specifies filters on messages
• Specify the local listener to call when a
  qualifying message is published

19
Messages Commands

• A common design in distributed systems is for the
  client to send messages to the server, where
  the message contains a Command.
• Message is a subclass of java.util.Hashtable, so
  it can contain arbitrary information as key-value
  pairs (everything of interest must implement
  Serializable).
• Messages have one required key KEY_COMMAND,
  whose value indicates the name of the concrete
  Command subclass. Other entries in the Hashtable
  specify the rest of the Commands parameters.
• class Message extends Hashtable implements
  java.io.Serializable
• public final static String KEY_COMMAND
  command
• public final static String KEY_ERROR error
• public Message( String commandClassName )
• put( KEY_COMMAND, commandClassName )

20
Messages Commands (cont.)

• Message request new Message( COMMAND_RENT_VIDEO
  )
• request.put( KEY_CUSTOMER, customer )
• request.put( KEY_VIDEO_NAME, Java Junkies )
• Message reply RMIProxy.sendMessage( request )
• String transactionCode (String) reply.get(
  KEY_TRANS_CODE )
• ...

21
Messages Commands (cont.)

• public class RentVideoCommand implements ICommand
  
• public void execute( Message request, Message
  reply )
• try
• Customer c (Customer)request.get(
  KEY_CUSTOMER )
• String vid (String)request.get(
  KEY_VIDEO_NAME )
• String verificationCode rentVideo( c, vid
  )
• reply.put( KEY_TRANS_CODE, verificationCode
  )
• catch( Throwable t )
• reply.put( KEY_ERROR, Video NOT rented! "
  t )
• ...

22
Web-Based Travel Site

• The site must maintain a shopping cart for the
  client, remember his preferences, etc.
• One remote service, the site, must collaborate
  with several other remote services, the airline
  and hotel reservation systems
• How does the site avoid treating each as a
  special case?
• How does the site perform adequately?

23
Maintaining a Shopping Session

• Http is a stateless protocol
• Session state must be implemented somehow
• Cookies
• Hunks of information the server leaves on the
  client machine
• URL rewriting
• Session information is encoded in the URL string
  sent between the client and server
• Can use protocol other than HTTP (Java w/ XML)

24
Talking to Distributed Databases

• N-tier architecture
• Client
• Web Server
• Application server
• Database server
• Use standard database abstractions
• Connections
• ODBC and JDBC

25
Stock Trading System

• Client processes must be able to subscribe to
  trades and changes in price of specific
  securities
• Subscriptions are maintained when client or
  server system is restarted
• If client is not running, notices to which it
  subscribes are saved for it
• System sends asynchronous notices to subscribers
• How does the client know what happens without
  polling?

26
Google Search Service

• Must be easy to program clients for
• Clients can be written in one of many languages
• Low support overhead for Google
• How do you make the service simple, easy, and
  universal?

27
Web Services

• Uses Simple Object Access Protocol (SOAP) as
  common representation
• SOAP is expressed in an XML dialect
• All information is transmitted as strings
• Uses HTTP as the request-reply protocol

28
Web Services

• Finding Services - UDDI
• Describing Services - WSDL
• Invoking Services SOAP
• Both RPC and messaging

29
Finding Services - UDDI

• Universal Description, Discovery and Integration
• A way for clients to find web services
• Not being used very much, yet

30
Describing Services - WSDL

• Web Services Definition Language
• For defining the interfaces for a web service
• Names of methods
• Types and order of parameters
• Types of return values
• URL of service
• Writing WSDL
• Do it once, when service is defined
• Annoying and error-prone to do by hand
• Several free generating packages available
• GLUE (The Mind Electric)
• IBM Web Services Toolkit (IBM Alphaworks)

31
Invoking Services - SOAP

• Simple Object Access Protocol
• Runs over HTTP
• A Standard for XML messaging
• Writing SOAP
• Do it every time a service is requested
• REALLY annoying and error-prone to write by hand
• Good tools are available
• Apache SOAP
• AXIS
• Visual Studio .NET

32
Web Services Reading List

• http//www.oreillynet.com/pub/a/webservices/2002/0
  4/12/execreport.html
• A brief, high-level overview of some of the
  important business motivations for web services.
• http//www.oreillynet.com/pub/a/webservices/2002/0
  2/12/webservicefaqs.html
• A overview of the technologies involved in web
  services, and why they make web services
  different from other distributed computing
  technologies.
• http//www.xml.com/pub/a/2002/04/24/taglines.html
• An interesting and opinionated editorial that
  raises some of the important political and
  business-related issues around web services, XML
  and the Internet.