Lec 7_ 8 Distributed Objects and Remote Invocation - ECEE

Document Sample
Lec 7_ 8 Distributed Objects and Remote Invocation - ECEE Powered By Docstoc
					 Multi-threaded and Distributed
 Programming –
 How Distributed Programs
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)
 Synch vs. Asynch
 Data marshalling
 Java Serialization
 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
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
 CORBA Name Service
Getting The Object You Want
 Askthe 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
 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
 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
 Have to translate to/from IDL
 IIOP not firewall friendly
CORBA (cont.)

 Client Application   Apparent Method Invocation   Server Application

                         Actual Data Path

   Client's Local                                   Server's Local
       ORB                                              ORB
      CORBA (cont.)
       Client                                Server

DII    Stubs    Services          Services
                                              Object Adapter

        ORB                IIOP              ORB
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” );
 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 –
   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 &
   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 {
  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(
 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
 How does the site avoid treating each as a
  special case?
 How does the site perform adequately?
    Maintaining a Shopping
 Http is a stateless protocol
 Session state must be implemented somehow
   Cookies
          Hunks of information the server leaves on the client
     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
 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
 How does the client know what happens without
Google Search Service
 Must  be easy to program clients for
 Clients can be written in one of many
 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
Web Services
 Finding Services - UDDI
 Describing Services - WSDL
 Invoking Services – SOAP
 Both RPC and messaging
Finding Services - UDDI
 Universal Description, Discovery and
 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
       A brief, high-level overview of some of the important
        business motivations for web services.
       A overview of the technologies involved in web services, and
        why they make web services different from other distributed
        computing technologies.
       An interesting and opinionated editorial that raises some of
        the important political and business-related issues around
        web services, XML and the Internet.

Shared By:
xiaohuicaicai xiaohuicaicai