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

Distributed Object Communications (part 2)

REVIEW :Synch vs. AsynchMOMData marshallingJava SerializationXML

ATMATM “Teller” object works with “Account”Teller object is local to the ATMAccount object is in some process back at

the bankHow do they talk to each other?

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?

Talking to Remote ObjectsFinding the object you wantGetting a reference to the object Invoking methods on the objectReceiving resultsDifferences from talking to local objects

Finding The Object You WantRequires a naming or directory serviceFinding 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

Getting The Object You WantAsk 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 stubThe stub supports the same interface as the

actual remote object Stub and Skeleton classes are usually

machine generated, using a program such as RMIC.

Invoking Methods on the Object Client talks to the stub Stub’s job

Specifies the method to execute Marshalls the parameters Sends method ID and parameters to the skeleton

Skeleton’s job Unmarshalls parameters Calls the actual object

Receiving Results Skeleton’s job

Receives results from the actual object Marshalls the results Sends results to the stub

Stub’s job Unmarshalls the results Passes them back to the client

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 vendor’s CORBA tools are interoperable

Have to translate to/from IDL IIOP not firewall friendly

CORBA (cont.)

Client Application Server ApplicationApparent Method Invocation

Client's LocalORB

Server's LocalORB

IIOP

Actual Data Path

CORBA (cont.)

O R B

D II S tubs

O R B

O bject A dapter

S ke le ton

C lien t S erver

S ervices S ervices

IIO P

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.

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_Skeleton.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” );

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

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”

Messaging – Point to PointOne consumer

Usually owns the queueMany producersProcess 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

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

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 Command’s 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 ); }}

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

...

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

} }

...

}

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?

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)

Talking to Distributed DatabasesN-tier architecture

Client Web Server Application server Database server

Use standard database abstractions Connections ODBC and JDBC

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?

Google Search ServiceMust be easy to program clients forClients can be written in one of many

languagesLow support overhead for GoogleHow do you make the service simple,

easy, and universal?

Web ServicesUses Simple Object Access Protocol

(SOAP) as common representationSOAP is expressed in an XML dialectAll information is transmitted as stringsUses HTTP as the request-reply

protocol

Web ServicesFinding Services - UDDIDescribing Services - WSDL Invoking Services – SOAPBoth RPC and messaging

Finding Services - UDDIUniversal Description, Discovery and

IntegrationA way for clients to find web servicesNot being used very much, yet

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)

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

Web Services Reading List http://www.oreillynet.com/pub/a/webservices/2002/04/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/02/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.