Title: Multi-threaded and Distributed Programming
1Multi-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
2Distributed Object Communications (part 2)
- REVIEW
- Synch vs. Asynch
- MOM
- Data marshalling
- Java Serialization
- XML
3ATM
- 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?
4Ordering 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?
5Talking 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
6Finding 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
7Getting 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.
8Invoking 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
9Receiving 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
10CORBA
- 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
11CORBA (cont.)
12CORBA (cont.)
13Remote 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.
14RMI (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 )
15Messaging
- 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
16Messaging (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
17Messaging 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
18Messaging 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
19Messages 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 )
-
20Messages 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 ) - ...
21Messages 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 ) -
- ...
22Web-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?
23Maintaining 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)
24Talking to Distributed Databases
- N-tier architecture
- Client
- Web Server
- Application server
- Database server
- Use standard database abstractions
- Connections
- ODBC and JDBC
25Stock 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?
26Google 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?
27Web 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
28Web Services
- Finding Services - UDDI
- Describing Services - WSDL
- Invoking Services SOAP
- Both RPC and messaging
29Finding Services - UDDI
- Universal Description, Discovery and Integration
- A way for clients to find web services
- Not being used very much, yet
30Describing 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)
31Invoking 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
32Web 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.