Survey
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
Distributed Objects Distributed Objects (Background) The message-passing paradigm is a natural model for distributed computing, in the sense that it mimics inter-human communications. It is an appropriate paradigm for network services where processes interact with each other through the exchanges of messages. However, the abstraction provided by this paradigm does not meet the needs of the complexity of sophisticated network applications. Message passing requires the participating processes to be tightly-coupled throughout their interaction and the processes must be in direct communication with each other. The message-passing paradigm is data-oriented. Each message contains data marshalled in a mutually agreed upon format, and is interpreted as a request or response according to the protocol. The receiving of each message triggers an action in the receiving process. This is inadequate for complex applications involving a large mix of requests and responses (can become too difficult to manage and is overwhelming). 1 Distributed Objects The Distributed Object Paradigm The distributed object paradigm is a paradigm that provides abstractions beyond those of the message-passing model. As its name implies, the paradigm is based on objects that exist in a distributed system. In object-oriented programming, supported by an object-oriented programming language such as Java, objects are used to represent an entity significant to an application. Each object encapsulates: the state or data of the entity (in Java, such data is contained in the instance variables of each object); the operations of the entity, through which the state of the entity can be accessed or updated. This abstraction model allows us to hide some complexity and interact with entities that are at a higher level and hence somewhat closer to the real world. 2 Distributed Objects Object Representation (Example) public class DatagramMessage { // class to use during UDP based communication private String message; private InetAddress senderAddress; private int senderPort; public void putVal(String message, InetAddress addr, int port) { this.message = message; this.senderAddress = addr; Each object instantiated from this class contains three state this.senderPort = port; data items: } public String getMessage( ) { return this.message; } public InetAddress getAddress( ) { return this.senderAddress; } public int getPort( ) { return this.senderPort; } } // end class a message, the sender’s address, and the sender’s port number. In addition, each object contains three operations: a method putVal, which allows the values of these data items to be modified, a getMessage method, which allows the current value of the message to be retrieved, and a getAddress method, which allows the sender’s address to be retrieved. 3 Distributed Objects Local Objects vs. Distributed Objects Local objects are those whose methods can only be invoked by a local process, a process that runs on the same computer on which the object exists. A distributed object is one whose methods can be invoked by a remote process, a process running on a computer connected via a network to the computer on which the object exists. Message Passing versus Distributed Objects Compared to the message-passing paradigm, which is data-oriented, the distributed objects paradigm is action-oriented: The focus is on the invocation of the operations, while the data passed takes on a secondary role. Although less intuitive to human-beings, the distributed-object paradigm is more natural to object-oriented software development. 4 Distributed Objects The Distributed Object Paradigm In a distributed object paradigm, network resources are represented by distributed objects. To request service from a network resource, a process invokes one of its operations or methods, passing data as parameters to the method. The method is executed on the remote host, and the response is sent back to the requesting process as a return value. A process running in host A makes a method Host A Host B client process method call object state data item object operation call to a distributed object residing on host B, passing with the call data for the parameters, if any. The method call invokes an action performed by the method on host B, and a return value, if any, is passed from host B to host A. A process which makes use of a distributed object is said to be a client process of that object, and the methods of the object are called remote methods (as opposed to local methods, or methods belonging to a local object) to the client process. a distributed object 5 Distributed Objects An Archetypal Distributed Objects System object registry object client object server client proxy server proxy runtime support runtime support network support network support physical data path logical data path A distributed object is provided, or exported, by a process, here called the object server. A facility, here called an object registry, must be present in the system architecture for the distributed object to be registered. To access a distributed object, a process –an object client – looks up the object registry for a reference[1] to the object. This reference is used by the object client to make calls to the methods. Logically, the object client makes a call directly to a remote method. In reality, the call is handled by a software component, called a client proxy, which interacts which the software on the client host that provides the runtime support for the distributed object system. [1]A reference is a “handle” for an object; it is a representation through which an object can be located in the computer where the 6 object resides. Distributed Objects Distributed Object Activity (Server Side) The runtime support is responsible for the inter-process communication needed to transmit the call to the remote host, including the marshalling of the argument data that needs to be transmitted to the remote object. A similar architecture is required on the server side (to that of the client side), where the runtime support for the distributed object system handles the receiving of messages and the un-marshalling of data, and forwards the call to a software component called the server proxy. The server proxy interfaces with the distributed object to invoke the method call locally, passing in the un-marshalled data for the arguments. The method call results in the performance of some tasks on the server host. The outcome of the execution of the method, including the marshalled data for the return value, is forwarded by the server proxy to the client proxy, via the runtime support and network support on both sides. 7 Distributed Objects Distributed Object Systems/Protocols The distributed object paradigm has been widely adopted in distributed applications, for which a large number of mechanisms based on the paradigm are available. Among the most well known of such mechanisms are: Java Remote Method Invocation (RMI), Common Object Request Broker Architecture (CORBA) systems, Distributed Component Object Model (DCOM)/.NET/WCF Mechanisms that support the Simple Object Access Protocol (SOAP). Remote Method Invocation (RMI) is a Java object-oriented implementation of the Remote Procedure Call model. Using RMI, an object server exports a remote object and registers it with a directory service. The object provides remote methods, which can be invoked in client programs. Syntactically: A remote object is declared with a remote interface The remote interface is implemented by the object server. An object client accesses the object by invoking the remote methods associated with the objects using syntax provided for remote method invocations. 8 Distributed Objects Directory service The Java RMI Architecture object client object server stub skeleton supports the interface with the application program maps the platform-independent stub/skeleton layer to the platform-dependent transport layer; carries out remote reference protocols remote reference layer remote reference layer transport layer transport layer sets up, maintains, and shuts down connections; and carries out the transport protocol logical data path physical data path 9 Distributed Objects Java Remote Method Invocation(RMI) Java provides a form of RPC called Remote Method Invocation(RMI), that allows objects to communicate via their methods regardless of their location. Data transfer is handled by object streams automatically. To create a class that will be remotely accessible, you must define an interface which declares those methods that you wish to make public. A stub and skeleton are then generated automatically using Java reflection. The final setup involved in using RMI is that the remote object must be registered with the Object Registry (naming service) that allows clients to access them. When a client wishes to make calls to a remote object, it must first look up the object in the Object Registry. This returns a remote reference to the object which immediately informs the object that it has a remote client. Once the client has the stub, it has all the information necessary to invoke methods of the remote object. The skeleton then makes the actual method call on the remote object; the return value is finally sent back from the skeleton to the stub, which then returns the result to the client. 10 Distributed Objects Defining the Java RMI remote Interface An interface must be written for the remote object, defining all methods that should be public. The interface must extend java.rmi.remote (an interface which identifies that a reference is to a remote object). For example: import java.rmi.*; public interface MyRemote extends Remote { public Object myMethod (String s) throws RemoteException; } Implementing the Java RMI RemoteObject The remote object must implement any of the remote interfaces that it wishes to Java Reflection is used to created the support. For example stubs dynamically at run time. public class MyRemoteImpl implements MyRemote{ When an object registers itself with the public MyRemoteImpl () { registry, it specifies a name by which it public Object myMethod (String s) { is to be referenced. Remote clients can return s; contact the registry and locate the object based on this name. } } Java Reflection makes it possible to inspect classes, interfaces, fields and methods at runtime, without knowing the names of the classes, methods etc. at compile time. It is also possible to instantiate new objects, invoke methods and get/set field values using reflection. 11 Distributed Objects Testing and Debugging an RMI Application 1.Build a template for a minimal RMI program. Start with a remote interface with a single signature, its implementation using a stub, a server program which exports the object, and a client program which invokes the remote method. Test the template programs on one host until the remote method can be made successfully. 2.Add one signature at a time to the interface. With each addition, modify the client program to invoke the added method. 3.Fill in the definition of each remote method, one at a time. Test and debug each newly added method before proceeding with the next one. 4.After all remote methods have been thoroughly tested, develop the client application using an incremental approach. With each increment, test and debug the programs. Note. All this can be done on your own local machine before running it across the network. 12 Distributed Objects Comparison of the RMI and the Socket APIs The remote method invocation API is an efficient tool for building network applications. It can be used in lieu of the socket API in a network application. Some of the tradeoffs between the RMI API and the socket API are as follows: The socket API is closely related to the operating system, and hence has less execution overhead. For applications which require high performance, this may be a consideration. The RMI API provides the abstraction which eases the task of software development. Programs developed with a higher level of abstraction are more comprehensible and hence easier to debug. 13 Distributed Objects XML-RPC XML-RPC is a spec and a set of implementations that allow software running on disparate operating systems, running in different environments to make procedure calls over the Internet XML-RPC is designed to be as simple as possible, while allowing complex data structures to be transmitted, processed and returned Languages include: C/C++, Java, Perl, Python, Frontier, Lisp, PHP, Microsoft .NET, It's remote procedure calling uses HTTP as the transport and XML as the encoding. Uses existing protocols (HTTP) and a well established framework (XML). XML-RPC is a protocol that works over the Internet. An XML-RPC message is an HTTP-POST request. The body of the request is in XML. A procedure executes on the server and the value it returns is also formatted in XML. 14 Distributed Objects XML-RPC Request (Example) • POST /RPC2 HTTP/1.0 User-Agent: Frontier/5.1.2 (WinNT) Host: erne.dyndns.com • Content-Type: text/xml Content-length: 144 <?xml version="1.0"?> <methodCall> <methodName>examples.name</methodName> <params> <param> • <value><i4>41</i4></value> </param> </params> </methodCall> • The payload is in XML, a single <methodCall> structure. The <methodCall> must contain a <methodName> sub-item, a string, containing the name of the method to be called. The string may only contain identifier characters, upper and lower-case A-Z, the numeric characters, 0-9, underscore, dot, colon and slash. It's entirely up to the server to decide how to interpret the characters in a methodName. For example, the methodName could be the name of a file containing a script that executes on an incoming request. It could be the name of a cell in a database table. Or it could be a path to a file contained within a hierarchy of folders and files. If the procedure call has parameters, the <methodCall> must contain a <params> sub-item. The <params> sub-item can contain any number of <param>s, each of which has a <value>. 15 Distributed Objects Summary The distributed objects paradigm is at a higher level of abstraction than the message-passing paradigm. Using the paradigm, a process invokes methods of a remote object, passing in data as arguments and receiving a return value with each call, using syntax similar to local method calls. In a distributed object system, an object server provides a distributed object whose methods can be invoked by an object client. Each side requires a proxy which interacts with the system’s runtime support to perform the necessary IPC. Among the best-known distributed object system protocols are the Java Remote Method Invocation (RMI), .NET/WCF, Common Object Request Broker Architecture (CORBA) , XML-RPC and Simple Object Access Protocol (SOAP). An even higher architectural layer of software abstraction (encapsulating distributed objects) can be constructed using Service Component Architecture (SCA) or Service Oriented Architecture (SOA). 16