Multi-threaded and Distributed

computerharpyΛογισμικό & κατασκευή λογ/κού

2 Δεκ 2013 (πριν από 3 χρόνια και 9 μήνες)

63 εμφανίσεις

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


MOM


Data marshalling


Java Serialization


XML

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?

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

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

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.

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 Application
Apparent Method Invocation
Client's Local
ORB
Server's Local
ORB
IIOP
Actual Data Path
CORBA (cont.)

ORB
DII
Stubs
ORB
Object Adapter
Skeleton
Client
Server
Services
Services
IIOP
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 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

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
Databases


N
-
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 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?

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


Web Services


Finding Services
-

UDDI


Describing Services
-

WSDL


Invoking Services


SOAP


Both RPC and messaging


Finding Services
-

UDDI


Universal Description, Discovery and
Integration


A way for clients to find web services


Not 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/execre
port.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/webser
vicefaqs.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.